BSA / Business Ramifications

Business Ramifications †

要約 †

• 連携する仕組みを提供すると、マーケテクトとターキテクトの両方にとって、ビジネス上の影響（困りごと）が生じる
  • うまく対処できれば成功のチャンス
  • しくじれば死活問題

詳細な議論 †

専門サービス部門 †

• ユーザーは、システム連携のための選択肢から、どれを選べばいいのか分からない
  • 技術的な選択肢が多くなると、ユーザーに提示する選択肢も膨大になる
  • 企業目標をちゃんと理解できていないといろいろなことが不安になる
    • 時間
    • コスト
    • 失敗

• ベンダーはシステム連携をお手伝いする専門サービスを提供することになる
  • マーケテクトは専門サービス部門の立ち上げを支援するべき
    • 提供するサービスの内容
    • ビジネスの枠組み
    • ライセンスモデルの枠組み
    • 価格設定
  • 会社によって干渉できる範囲は異なる
    • 例）プロダクトマネージャーが全責任を負うケース
    • 例）専門サービス部門が主体となるケース
  • 筆者のお勧めは、プロダクトマネジメントの一環として、標準的なサービス（メニュー？）を決めておくこと

• 専門サービスからの要望を開発チームに伝えることも、マーケテクトの重要な仕事の一つ

• 専門サービス部門のメンバー
  • 内部のメンバー（自社社員）
  • 外部のメンバー（パートナー会社）
• 会社の規模によって割合が違ってくる
  • 中小規模なら外部のメンバーの割合が多くなる
  • 大規模なら内部のメンバーの割合が多くなる
• 会社の戦略に基づく判断が必要になるので、マーケテクトは判断材料となるデータを提供するべき
• パートナーを採用するかどうかの判断には、ターキテクトも協力すること
  • パートナー会社の顧客企業から、彼らの作業品質をヒアリングするなど

• 専門サービスは、開発チームとユーザーの間に位置する
  • 開発チームが直接ユーザーとやりとりすることはない
  • 開発チームは専門サービスに対して、APIの使い方を説明するサンプルプログラムを提供したりする
  • （開発チームのうち、最低一人は専門サービスを支援する役割を持たせるといいらしい）

研修プログラム †

• システムの使い方を教える研修プログラム
• ユーザーの具体的な目的に合致したプログラムを用意するのが 成功するソリューション
• エンドユーザーは、一般的な使い方を教えられることに飽きている
• よく考えられた研修プログラムがあれば、ユーザーの満足度は高まるし、サポートの負担は減る

• マーケテクトは、精度の高い研修プログラムを作るために技術文書作成チーム、品質保証チーム、開発チームの間の調整役を担う
• ユーザービリティに詳しいターキテクトがいれば、研修プログラムはより優れたものになる

• 例）Adobe Photoshop の研修プログラム
  • 開発者がプラグインを書くために何をすればいいのか学ぶことができる
• エンタープライズなシステムのための研修プログラム
  • 入門から高度な使い方まで、内容がおどろくほど多方面にわたることがある
  • 数日間かかることも

• 研修プログラムの設計
  • マーケテクトはステークホルダー全員のことを考えないといけない
    • 他のシステムへ統合するように言われている開発者
    • チューニングできるようになりたいシステム管理者
    • 自分たちのソリューションを統合させたいソリューションパートナー
    • より高度なコンサルティングをサービスとして提供したいコンサルタント
  • 自分たちのシステムだけではなく、他のシステムも含まれるかもしれない
    • 単独で動いているシステムはそんなにない

• 研修資料の不備
  • ターキテクトがちゃんと見てくれれば解決できるものも多い
    • APIの説明が間違っているとか
    • サンプルプログラムが動かないとか
  • 説明がまずいと、APIを使用する開発者が適切なメンタルモデルを作れないこともある

資格認定（サーティフィケーション） †

• 研修プログラムの発展形
• マーケットシェアが十分に大きければ意味がある
• マーケテクトが中心的に取り組むべき
• 検討するべき要因は次のとおり
  • エコシステム
    • プロダクトのサードパーティがたくさんいたり、プロダクトを提供するサービス事業者の技術レベルを知りたいユーザーがいたりする場合
    • 例）ハードウェアのマーケット（SANの資格を持っている会社から買いたいはず）
    • 例）情報システム連携、マネージメントのマーケット（MCSEを持っている会社は信頼できる（？））
  • 競合優位性
    • 資格を持っていると他社よりも優れていることを示すことができるので、動機付けになる
  • Currency（流行は誤訳…維持し続けることの価値、とかですね）
    • 継続的な学習を要求する資格認定プログラムがある
    • 専門性が深まると知識の有効期間が短くなりがちなので、時間を費やすつもりがないならやめたほうがよい
  • プロフェッショナル認定（制度）
    • 差別化につながる
    • 誰でも取れる認定は意味がない
  • 独立した第三者機関による資格認定
    • 研修プログラムの開発とかは別会社に任せるほうがコストの節約になる
    • 例）CISSP（セキュリティプロフェッショナル認証資格制度）
    • 特定のベンダー知識だけでなく、中立的な幅広い専門知識が必要な資格
  • アカデミックな信用
    • 大学の学位と同じように扱ってもらえる場合がある

ユーザーコミュニティ †

• マーケテクトにもターキテクトにも有益な情報源になる
  • 求められているフィーチャ、プロダクトの使われ方
  • 思いもかけないAPIの使い方
• ユーザーコミュニティを生み出すための要因は次のとおり
  • Webサイト
    • ノウハウとかを共有できる
  • メーリングリスト
    • マーケティングの領域なので、マーケティング部門が管理するべき
  • 教育素材
    • 参考資料や、APIのサンプルプログラムなどを公開する
    • 品質は重要、動かないものを提供してはならない
    • マーケテクトが関係各所（品質保証、サポート、専門サービス）と協議してコンテンツを決める
  • ユーザーカンファレンス
    • ユーザーベースによって年一回か、年に数回は開催しよう
    • 企画はマーケテクトが主導するべき
    • 運用はマーケティング部門に任せよう

使用許諾契約（License Agreement） †

• マーケテクトは使用許諾契約をレビューすること
  • 必要以上にAPIの使い方を制限する文言が無いかどうか確かめないといけない
  • （どこかの部署で）善意から追加されたとしても、ユーザーにとって迷惑になることがあるため
• インライセンス契約に使われる使用許諾契約もレビューすること
  • 権利が明確に定義されていることを確かめないといけない

コラム †

How Do I Add a Document? †

• 入社時に、Lotus Notes の使い方を3分くらいで説明されたけど全然使いこなせなかった
• 他の人は上手く利用できていて羨ましい
• 組み込みヘルプやチュートリアルはクソだ

Thanks, But I Think I’ll Build My Own User Interface †

• ユーザーインターフェイスの設計にはすごく苦労した
• ヘビーユーザーから改善案があるという問い合わせがあったので聞きに行った
• システムを利用するところを見せてくれたのだが、システムではなくExcelの流暢な使い方を見せられることになった
  • あれだけ苦労したユーザーインターフェイスはニーズに合わなかったらしい
  • 「クールなCOM APIがあるのでそれを使ってるんですよ。」

No License for Testing †

• 使用許諾契約の内容が単純すぎると、ユーザーに便利に使ってもらおうとしていたはずが、その逆になってしまうことがある
• 一つのハードウェアでのみ使用を許可するようになっていたが、APIへのアクセスは完全に自由になっていた
  • ユーザーからすると、テストするのに開発環境や検証環境にインストールしたくてもそれができない、という問題だった
• どうすれば問題を避けられたのか
  • 法務部門に、APIの使用目的を正確に理解してもらえばよかった
  • あなたのプロダクトが拡張や統合できるものであれば、開発や検証のためのライセンスが必要になるのは当たり前
  • 別ライセンスとして課金するベンダーもいるし（お勧めしない）、基本ライセンスに含まれる権利であるとするベンダーもいる
  • いずれにしても、そのような利用目的について明記しておかないといけない

担当者のつぶやき †

意外と長かった…

みんなの突っ込み †