ソフトウェアは人が協力して作る - アドベントキャンドル4本目 -

前回の記事（トップダウンのWF、ボトムアップのスクラム、その成功の鍵）をまとめると、どのような方法であってもトップダウンとボトムアップのバランスが重要という事になるでしょう。WFのアンチテーゼとしてアジャイル開発が扱われ易い理由を歴史にふりかえりながら考えてみます。

ソフトウェアプロセスのはじまり

ソフトウェア工学の分野でプロセスが注目され始めたのは1980年代半ばです。ソフトウェアプロセス国際ワークショップ(IWSP)でオスターワイル(Leon J. Osterweil)氏が

“Software Processes are Software, Too”
(ソフトウェアプロセスもソフトウェアである)

という言ってプロセスプログラミングを提唱したのはこの頃です。

プログラムをプロセスのメタファにする事で、新しい世界が広がりました。プロセスをモデリングして記述すれば、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、といった事が可能であるとされました。

プロセスモデリング

モデリングをするのであれば、記述言語が必要です。そこでソフトウェアプロセスモデリングの例題（井上ほか, ソフトウェアプロセス, 共立出版, P.209）が作られ、 多くの言語が研究されました。

例題では基本的なスケジューリング、工程とそのレビュー、監視、といった基本的なプロセスの入力、出力、責任、制限、が定められたほか、成果物やスケジュールの変更などが定められました。

その中には、実行中のダイナミックな変更も示されたので、リフレクション可能な高度な言語が提案されました。

このような言語は現場のソフトウェア開発には直接役に立っているとは言えないかもしれません。しかし、CSCW(Computer supported cooperative work）、エージェントシステム、ワークフローシステムなどにその概念が活かされていると思います。

CMM(Capability Maturity Model)

IWSPではハンフリー氏もCMMの段階モデルを提案されていました。その後、それまでのソフトウェア工学の成果をCMMの段階モデルに整理して「ソフトウェアプロセス成熟度の改善」を出版されたのは1989年のことでした。

その後1990年代になって、DoD(米国防総省)が発注先の選定にCMMのレベルを利用する事になり、CMMブームが訪れました。書籍の「ソフトウェアプロセス成熟度の改善」にはプロセスモデリング、スパイラルモデル、プロトタイピングなどが含まれていました。しかし、ブームになったCMMはもともとは政府のソフトウェア開発請負業者を評価するためのツールなので、プロセス監査を中心としたものでした。

日本では古くから各企業で開発標準が定められ、メトリクスの収集、改善活動が行われていました。ソフトウェア工学の成果をより多く体系的に取り入れることのできるCMMは、日本でも改善のベンチマークや参考としてブームになりました。

アジャイル開発

2000年頃になってCMMおよびその後継のCMMIのアンチテーゼとしてちゅうもくされたのがアジャイル開発です。アジャイル開発はアジャイルソフトウェア開発宣言にあるように、従来のプロセスや計画重視ではなく、コミュニケーションや変化への対応を重視し、動くソフトウェアを協調して開発するものです。

アジャイル開発をプロセスモデリングの観点で考えると、イテレーション毎に変更点を定期的に儲ける事で、難しいと言われたプロセスのダイナミックな変更を避けていると言えます。いわば、塗り壁の目立つところにひびが入らないように、目地を付けるようなものでしょう。

アジャイル開発は、CMMのようにプロセスを管理することで標準から外れないようにするものはなく、プロセスの混乱を避ける最低限のフレームワークを定めて、人を中心としてうまく実行できるように導くものと言えるでしょう。

TSP(Team Software Process)

このように書くとCMMはあまり良くない、アジャイル開発が良いと思われるでしょう。私もTSPを知るまではそうでした。組織プロセスを改善するCMMを提唱したハンフリー氏は、チームにはTSP、個人にはPSPという枠組みを作られました。

PSPでは開発者が自律的に定量的な管理を行い、TSPでは定義されたプロセスやフレームワークを提供してチームを構築します。しかし、そこには人を重視することが書かれています。

TSPガイドブック:リーダー編 (IT Architects'Archive) を読んだときは驚きました。サーバントリーダシップのようなリーダに求められる大切な事がたくさん書かれていたからです。

この本を読んでから、CMMの見方が変わりました。かつての日本の製造現場ではQC活動が盛んでしたが、CMMのブームに乗ってしまったことでその文化を失ってしまったのだと思いました。

おわりに

仕様の変わり易いソフトウェアで、小さく始められるなら、アジャイル開発はふさわしいでしょう。しかし、仕様が安定している、あるいは、安定していない部分が局所的で、最初にそれなりの規模が求められるなら、管理が必要になります。

しかし、チームの能力を引き出すには、小規模に分割して統治しておき、チームは自律的に動けるように導くと良いと思います。

ソフトウェアは人が協力して作るものです。問題に気付きながら「言わんこっちゃない」と思うチームより、進んで情報共有できるチームが良いでしょう。

いよいよ4本目のアドベントキャンドルに灯りました。街の中はクリスマスのかざり(注参照)でいっぱいですね。最後に聖書の言葉を紹介して終わりたいと思います。

「神の国はあなたがたの間にある」(ルカ17・20-21)

良いクリスマスをお迎えください。

---

注：クリスマスのかざり

サンタクロースが聖人の名前である事は有名ですが、クリスマスツリーがカトリックでは正式な飾りでない事はあまり知られていないでしょう。 ツリーのトップにある星は当方の３人の博士を導いたベツレヘムの星にちなんだもので、Wikipediaによると元々はゲルマン民族のお祭りから来ている様です。この辺は1本目で紹介したクリスマスの起源と似て政治的ですね。