ソフトウェア・ファクトリ雑感
とある研究会でソフトウェア・ファクトリ(Software Factories)についての講演を聴いてきました。講演者はこの技術では日本でこの二人というべき、松本吉弘先生とマイクロソフトの萩原さん。やはり大家と言われる人たちの話は本質をついており、ソフトウェアファクトリに関して私なりの理解を整理することが出来ました。ここでは、両先生の講演で特に頭に残ったことを書き留めておきます。そういうわけで、ソフトウェアファクトリについて論理立てて網羅的に説明しているわけではありません。そのような内容を期待される場合、以下のリソースを参照ください。
なお、ここでの記述は私の理解を書いています。文章中「私」と書いてあるのは私自身であって、両先生ではありません。よって、両先生が本来言いたかったことと異なる可能性があることは、ご了承ください。
# 両先生のように本質でわかっている方は話がクリアで、特に「この技術は何が出来ないか、この方法の限界は何か」などをしっかり言及してくれるところが、技術を銀の弾丸のように言うわかってないエバンジェリストと比べて違いますね。
90年以前と90年以降のソフトウェア・ファクトリがあるんです
誤解されている方もいらっしゃる(私がそうでした)と思いますが、「ソフトウェア・ファクトリ」という言葉自身は、「OOPSLA 2004」で最初に発表された言葉ではありません。それ以前にも、90年代以前、日本のソフトウェアが非常に高品質なソフトを作るという事実とその方法論が日本の高品質な電化製品を工場で作るアプローチと発想が近い(標準化された開発手法、訓練プログラム、再利用可能なコンポーネント、厳格な品質保証、統計データを用いたプロジェクト管理手法など)ことから、その方法論は「ソフトウェア・ファクトリ」という名前で認識されていたようです(参考：ソフトウエア企業の競争戦略)。しかし、私の認識では、OOPSLA 2004で発表された"次世代開発基盤技術"としての現在のソフトウェア・ファクトリとは、「名前」と「解決方法を工場のベストプラクティスに求めた」という点では似ていますが、本質的に求めていたものが違うと考えています。90年代以前のそれは「電化製品のような高品質の追求」であり、現在のそれは「多様なシステム作成が求められる環境における範囲の経済性の追求」であるということです。
Time-to-valueのためのprosumerの時代が来た〜システムの変化/進化の迅速性のために
現在、システムは、ビジネスの変化に対応し、システムも迅速に変化/進化できなければならないといわれています。これはどのような要因によるのでしょうか？これは、日本の産業構造が変化し、GDPを支える活動が生産活動(大規模な工業製品の製造など)から消費活動（小売業、サービス業など)にシフトしたことがあげられます(これは何らかの統計情報からわかることでしょう)。たとえば、GSMの値引き競争を例に取るまでもなく、消費活動における競争や環境変化が非常にスピード感のあるものであることについて異論はないでしょう。つまり、スピード感のあるビジネスが増加し、システムにも迅速な変化/進化が求められるわけです。消費活動をサポートするシステムの変化迅速性にはTime-to-marketでだけでなくTime-to-valueが必要です。この迅速な対応に対する解決としてProsumerと言われる概念が生まれました。Prosumerとは、要するに「使いたい人(Consumer)がそれを作る(Producer)」ということですが、これがソフトウェアファクトリの本質的な目標です。なお、この「両者のコラボレーションの限りない緊密化」が、「アジャイル・セル」という発想の原点にもなっています。
Generalizationを目指す時代の終わり
ソフトウェア工学の主要な課題は、成果物の再利用を目的としたソフトウェアのGeneralizationの方法でした。もちろんこれは重要です。しかし、これからは領域特定化(domain specification)の資産化、資産利用エンジアリングへの転換が求められます。なぜでしょうか？私は、企業のシステムに求める価値がコストの削減から競争優位性の確保に変わってきたことが理由であると考えます。そもそもシステムは企業価値に貢献するものです。ビジネスの競争相手ともGeneralizationできるような情報にコスト削減の意味はあっても、どれだけの付加価値があるというのでしょうか？本来、真の企業価値を生む差別化要素は領域特定化の部分にあるはずなのです。つまり、システム利用者の目線での価値を指向する考えが開発のための工学であるソフトウェア工学にも求められてきたのです。
フィーチャ 〜 定義的特性理論の限界
フィーチャという言葉の起源を説明します。概念をモデル化するに当たり「定義的特性理論」というものがあります。これは、必要十分な定義的記述の集合によって、その概念が示すカテゴリへの所属の真理が明確に決定できるという考えです。しかし、現在この考え方の限界が指摘されています(もしかしたらRDF批判？)。そのため、「特徴的特性理論」が登場しました。この理論では、カテゴリは、特性の分布に由来する不均質な内的構造をもち、境界は不鮮明であり、確率的モデルによって識別するものであるという考えます。ここで、特性の型には、Features（定性的）、およびDimensions（定量的）があるとするものであり、これがフィーチャの由来です。フィーチャのいまいち明確でない感じは、本来そういうものであり当然のようです。
Ref: [Smith81] Smith, E.E., and D.L. Medin, Categories and Concepts, Harvard University Press (1981)
ドメインモデルとドメインアーキテクチャ
単なる定義の話。ドメインモデルは'representation of problems in domain'、ドメイナーキテクチャは'representation of solutions in domain'。へー。
可変性とは「要求変化に対する柔軟性」を意味しない
プロダクトライン/ソフトウェアファクトリといえば可変性。可変性とは、「多様性(variation)」を意味します。要件やアーキテクチャの先の見えない不明瞭な変化に対する「柔軟性」を意味しません。つまり、変化し続けるシステムに対応するためには、変化を多様性として定義でき、それをコントロールすることが大前提であることは注意しなければなりません。このような計画された多様性の定義には、それなりのコストが必要であり、プロダクトラインの導入は投資効果を考えなければ安易に導入してはならないようです。Agile開発といわれている開発手法のほうが良い場合も当然あることは念頭にいれましょう。
コンポーネントの再利用の失敗
一般にコンポーネントの再利用は難しいという言葉をよく聞きます。なぜ難しいのでしょうか。理由は、最終成果物の再利用だけを目指し、「利用コンテキストと一体化した再利用を前提としなかった」ためです。そのことは、当然研究者も気づいており、それがコンポーネントのインタフェースの定義だけの時代から、designByContractのような事前･事後条件の厳密な定義、時相論理を導入した時間的コンテキスト定義などの研究として発展しました。プロダクトラインは、本質的にその発想の流れの一環といえるかもしれません。つまり、利用コンテキストの更なる厳密な定義(およびそれによる自動化の促進)、再利用のためのプロセスの定義(再利用のやり方や、導入のための組織のあるべき姿もパッケージ化する)などが求められているのです。
フィーチャで制御せよ
プロダクトラインは提案型のシステム開発に向いています。なぜなら、フィーチャ構造を定義し制御するのは開発者でなければならないから。こうしないと、価値の高い資産を蓄積できないのです。つまり、システムの利用者の要件に何でも合わせるようなシステム開発にはプロダクトラインは向かない。利用者の意向を知るために、念密なマーケット調査は必要ですが、最終的には、利用者の要求にあわせるのでなく、「フィーチャ定義」に開発するシステムをあわせる必要があります。半カスタマイズ製品用とでもいえるでしょうか。(なるほど。確かにプロダクトライン開発は組み込み系システムに多い。この理由は、「組み込みだから」ではないのである。つまり、携帯電話や車載システムを例にすればわかるが、多様なシステムを開発するにしても、システムの仕様を制御しているのは開発者側なのである。利用者に要件をすべて聞いて携帯電話を作ることは今後もないであろう。このことは、現在の受注型SI企業での効果的なプロダクトライン開発導入を検討する上で重要な指摘だと思う。)
プロダクトラインは銀の弾丸でないし、全くの新しい技術ではない
プロダクトラインは、これですべてを解決するものではないようだ。優秀でない設計者が作ったプロダクトライン設計はやはり使えない。また、プロダクトラインは全くの新しい技術ではない。過去の再利用技術、自動化技術をまとめあげたベストプラクティス的なものである。
こんな感じです。最後は両先生に挨拶も出来、大変有意義でした。
自分の思索は眠いので書きません。最近BSCや経済話、アプリ開発のことなどいろいろ書きたいことがあるので、今後それらが有せ印された、面倒なのでこれ以上は書かないかもなあ。
