[#TiDD] ソフトウェアプロセスも複雑なソフトウェアである

マイルストーン重要

プログラマの思索に掲載された「バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠」に、ショックを受けました。記事内容がどうとかではなく、記事に出てくる「彼」と,
Twitterで賛同の声があったことです。

「マイルストーン」を適切に定めるなどということは、かなり昔から、少なくとも80年代半ばまでには言われていました。いつまでに何をやるかという短期目標(一里塚)をはっきりしなければ、プロジェクトは糸の切れた「たこ」のようになってしまいます。

プログラムで言うなら、クラスや関数に分割されない一本のプログラムのようなものです。少しでもややこしいことをするならスパゲティプログラミングになってしまいます。

ソフトウェアプロセスもソフトウェアである

このように考えて、あることに気付きました。それは、オスターワイルの

「ソフトウェアプロセスもソフトウェアである」

という言葉があまり知られていないことです。SRAの記事によると1987年のICSEの基調講演で述べられた(実際はプロセスに関する国際ワークショップであるIWSPでの発表が元だと思います)。この発表は、その後のプロセスプログラミングとプロセス改善に大きな影響を与えたとして、1997年の第19回ICSEで表彰されました。

この“Software process are software too”という言葉は、多くの人のイマジネーションを刺激しました。特にプロセスのモデリング(プロセスプログラミング)の分野では、どのようにプロセス記述言語が必要であるかが議論されました。プロセスのモデリングは、本来コミュニケーションや伝達、検証、支援、自動実行などがを目的としていました。しかし、人間の実行するプロセスは、実行途中で中止、変更、分割などが生じるので、その記述言語は、どんどん複雑なものになっていきました。

プロセスの観点でソフトウェア開発を支援するはずが、開発するソフトウェアよりもプロセスの記述が複雑になっては使い物になりません。複雑な記述が可能な記述言語が発表された後、いつしかプロセスプログラミングは、話題にならなくなりました。

ソフトウェアプロセスも複雑なソフトウェアである

このような歴史を振り返ると分かることがあります。

「ソフトウェアプロセスをソフトウェアとするなら、それは複雑なソフトウェアである」

ということです。

その観点で最初の議論の戻ると、多くのことが見えてきます。最初に書いたように、全体を一つにまとめてしまうのは言語道断です。複雑なプログラムなら、細かな単位に分割して、開発が容易な形で開発しないでしょうか？同じことがプロセスにも言えます。上述のマイルストーンやWBSはそのためのものです。

さた、あなたが複雑なプログラミングをするなら、どうするでしょうか？

1. 機能的で明確な処理ならトップダウンに分割して一気に開発する
2. 技術的に不明な点があるので、段階的に開発する
3. 独立した複数のアプリケーションに分けるなど、アーキテクチャを工夫する
4. 完成したものを一つずつ確実に確認する
5. カプセル化して独立した開発を行い、うまく連携させる

それぞれ、1は外科医チームやウォータフォール、2はスパイラルモデルやアジャイル開発、3はシステム・オブ・システム、アジャイル・リリース・トレイン、スクラム・オブ・スクラムなどになるでしょう。また、チケット駆動開発なら、4はワークフロー型、5はオープン型の運用にあてはまるでしょう。

チケット駆動開発は、チケットによるプロセスのモデル化でもあります。チケット駆動開発には様々なプラクティスがありますが、プロセスプログラミングという観点で考えてみると、新しい発見があるかもしれません。

＃Clear the road for him!
＃Matthew 3:3 (New Living Translation)