あちこちで取り上げられているみたいです。
昨年に購入しましたが、バタバタしていて
遅ればせながら、ようやく先日読みました。
http://www.firstpress.co.jp/detail_page/4903241076.html
以前のエントリで顧客にとっての「伝えるコスト」が
「作るコスト」を上回る結果、ユーザーが内製を選択
するケースが増えてくるのではないかと書きましたが
本書ではそれを『情報の粘着性』という言葉で説明を
しています。
ユーザーはプロダクトをより良く使いこなす方法や
改善すべき点などの『ニーズ情報』を数多く持って
いますが、それらはユーザー固有の利用場面や環境
などに強く依存しているため、メーカー側がそれら
『ニーズ情報』を正確に把握し、再現することには
高いコストが付きます。一方で、メーカーは自社の
プロダクトの構造を良く理解しているため、性能面
での改善や適切かつ効果的な他分野への応用などの
『ソリューション情報』を豊富に持っています。
ところが、『ニーズ情報』はユーザーに強く密着し
『ソリューション情報』はメーカー側に保持されて
います。こうしたことから「ユーザーは自身の望む
機能のみを望んでいるにも関わらず、メーカー側は
なるたけ普遍的な機能としてそれを解釈し、尚且つ
現状製品の構造にフィットさせようとする」という
ギャップが生じることになります。
そのギャップの結果、 『伝えるコスト』を掛けた割には
(頻繁に仕様打ち合わせをしたり、プロトタイピング手法
を何度も繰り返した割には)本来望んでいたものが手に入
っておらず、「これなら自社でOSSを組み合わせて作っち
ゃった方が楽だったんじゃない？」 ということになった
りするわけです。
他産業と比べて、設計と製造がほぼ一体と見なすことの
できるIT産業では『ユーザーの内製』はより容易に発生
しやすいと思われます。オープンソースソフトウエアの
普及がそれをさらに後押ししているといえるでしょう。
もちろん、だからといって商用ソフトウエアが完全消滅
したり、SIerの活躍の場が無くなってしまうということ
ではないようです。本書ではユーザーが自らイノベーシ
ョンを起こす時代におけるメーカー(提供側)が果たせる
役割として以下の三点を挙げています。
1. 製造工程に特化する
形のあるモノが存在する他産業ではユーザーが画期的な設計を
考案できたとしても、それを製造できるかどうかは別問題です。
ですが、とかくソフトウエアについてはこの障壁は低いと言わ
ざるを得ません。ユーザー側にUMLなどを使って一連の要件を
記述してもらい、それを受けてメーカー側がプログラミングを
行なうといったBTO的スタイルも不可能ではないと思いますが、
EoDなどの取り組みによってプログラミングの敷居が低くなる
傾向の中で採算を取ろうとすると、どうしてもスケールメリット
に頼ることになります。ところが、顧客から出される実装要求は
多様であることが予想されますから(OSやフレームワーク、言語
は顧客側から事前に指定される可能性がある)、それらに応える
ためには相応の投資が必要になってきますので、どうしても大手
のSIerでなければ実現は難しいのではないかと思われます。
また、製造工程に特化する際に注力する分野についても検討が
必要です。パフォーマンスやセキュリティ、コンプライアンス
といった要素はメーカー側の『ソリューション情報』が活きる
ポイントであり、顧客側では正確かつ網羅的にカバーしづらい
部分かと思います。こうした部分にフォーカスした製造工程の
サービスを提供できれば、それは顧客側にとってもメリットは
大きそうです。一方、業務アプリケーションにおけるユーザビ
リティや業務効率向上といった分野は顧客が保持する『ニーズ
情報』に強く依存しているため、製造を他者に依頼することで
得られるメリットよりも伝えるコストによるデメリットの方が
大きくなってしまう可能性があります。
またユーザーによる設計とメーカーによる製造を分離させる
ためには設計モデルと実装モデルの間の変換(メタ情報の正確な
コンバート)が必須の条件となります。幾つかのMDA対応ツール
やMicrosoftのSoftware Factoryなどでは同種の試みがすでに
始められていますが、こうした試みの成否も深く関わってくる
ものと思われます。
2. ユーザーに対してフレームワークやツールキットを提供する
本書で使われている「フレームワーク」や「ツールキット」と
いう言葉の意味に注意する必要があります。「フレームワーク」
というとプログラマの手間を省くために良く用いられるパターン
をライブラリ的に整理した半完成品を指すことがあります。
「ツールキット」というとプログラムを支援するためにコード
ヒントやスニペットが利用できる高機能エディタを想像するかも
知れません。ですが、本書で言及しているフレームワークや
ツールキットは「ユーザーが自らのニーズを満たすための成果物
のプロトタイプを試作し、それが本当にニーズを満たすかどうか
を検証できると共に、正確にそれを製造工程に伝えられるモノ」
のことを指しています。「ユーザーが自分で検証できる」という
点が非常に重要です。これまではユーザーとメーカーの間で頻繁
にやりとりしていた仕様検討の試行錯誤をユーザーの中で早期に
完結させようという試みが本書で言うところのフレームワークや
ツールキットの意味するところです。他産業ではCADによるシミ
ュレーションが発達していますが、ソフトウエアの世界では今後
発展が期待される部分でもあります。Sun Java Studio Creator
やBeehiveのようなツールでGUIを作成し、ビジネスロジックは
BPMN、詳細が必要な部分はシーケンス図などのUMLで記述し、
それらを実際にダイアグラムの上で動作させて(トークンを移動
させて)業務の流れに支障がないかをチェックするといったことが
できたら素晴らしいなと思っています。既存システムとの連携に
ついては対象システムがWSDLなどを持っていれば何らかのシミュ
レートもできるかも知れませんが、レガシーなものでは難しいと
思います。そうしたレガシーな既存システムも含めた検証を支援
するモック作成ツールみたいなものも重宝されるかも知れません。
3. 付加価値を提供する
ソリューション情報をフル活用した技術コンサルや顧客以上に
特定業界でのノウハウに精通した業務コンサルといったものは
ユーザーイノベーションの時代においても高付加価値サービス
として存続しつづけるものと思われます。
ユーザーによるイノベーション(ユーザー主導の仕様策定と設計)
やユーザーによる内製といったことを単にメーカー先細りの時代
とネガティブに捉えずにむしろ変革のチャンスと考えたいと思い
ます。そうした意味でも大変勉強になる一冊でした。
