開発プロセスを設計するという発想

　最近興味があること。
　それは、「開発プロセスを自由自在に設計して、運営できるか？」ということ。
　こんな本「SEの仕事を楽しくしよう」を読んでみて、色々と考えさせられる所があった。

　RUP、XP、CMM/CMMI、ソフトウェアプロダクトラインなどを聞きかじって、自分で少しだけ試してみた経験を振り返ってみて、考察してみる。

【１】新規開発と派生開発～ＩＴ業界特有の開発プロセス

　開発プロセスを勉強すると必ず「ウォーターフォール型開発よりもインクリメンタル型開発の方がいい」という文句に良く出る。
　でも、実際の現場では、ウォーターフォール型開発でもインクリメンタル型開発でも、プロジェクトを制御できていない。
　その原因は、2種類の開発プロセスがある事実を知らないことにあると思う。

　最初からスクラッチ開発する時は、小さなサイクルでウォーターフォール型開発を行う時が多い。
　最近なら、オブジェクト指向言語で作るから、オブジェクト指向開発のＭＡＸ版であるRUPをカスタマイズして開発することが多い。

　しかし、リリース後、運用保守フェーズに入ると、現実に動いているシステムに機能追加して、デグレが起きないように開発しなくてはならない。
　この時に、開発プロセスをコントロールできない時が多い。

　この本「SEの仕事を楽しくしよう」では、この時の開発プロセスを「派生開発」と呼んでいる。
　つまり、実際のプログラムから設計書をリバースして作って、機能設計するプロセスになる。
　これは、RUPやウォーターフォール型開発のような、要件定義から設計してプログラミングするというプロセスと大きく異なる。
　上からの開発ではなく、下から開発していくスタイル。
　この開発スタイルを意識しているのが、ＸＰ(eXtreme Programming)だと思う。

　ＸＰの場合、動いているプログラムがまさに正。
　設計書は不要で、インテグレーション重視。
　小さなイテレーションで開発しながら、機能追加していく。

　ＳＥは、従来の上からの新規開発と、運用保守フェーズで使われる下からの派生開発の2種類を自由自在に操る必要がある。

【２】肝は構成管理～プログラミングよりもビルド作業が重要

　ＣＶＳやSubversionへＣＩする時のコミットログを重視しないプロジェクトが多くて、僕は不満。
　コミットログは、ソース変更の意図を現した重要なログ。
　コミットログをうまく使えば、要件管理や不具合修正、機能追加の作業ステータスを確実にトレースできる。
　これは構成管理の一つに使えると思う。

　CMM/CMMIやソフトウェアプロダクトラインでは、構成管理を重視している。
　ビルド作業では、リビジョン番号を付けたモジュールを作って、リリースする。
　
　この作業を、現場のプロジェクトでは意外と意識していない。
　実際の現場では、本番リリースのモジュールと開発途中のモジュールを意識して使い分けるやり方が浸透していない気がする。
　だから、モジュールのデグレなど、品質管理が甘いように思う。

　構成管理は、開発プロセスを制御する時の肝になる技術。
　「いつまでに、どんな機能をリリースするか？」を制御する時に、必要な技術が構成管理に全て含まれている。

【３】肝は、変化を受け入れること

　「仕様変更が多くて、いつまでもプロジェクトが収束しない」という不満は良く聞く。
　その原因の殆どは、顧客の要望をSIerがコントロールできていないというマネジメントにあると思うが、技術が不足しているのも一つの原因だと思う。
　つまり、度重なる仕様変更に耐えれる技術力や運用を開発チームが持っているか？

　ＸＰ(eXtreme Programming)では、「変化を抱擁する」と言って、これを意識して使っている。
　完璧な要件定義ができないのなら、仕様変更に対し、すぐに機能追加してリリースできる技術力を持とう、と。

　そのためには、モジュールの設計が保守に強いこと、リファクタリングの技術を持っていること、テストユニットを使っていつでも回帰テストで品質を確認できること、などの技術力がいる。
　ＸＰ(eXtreme Programming)はこの辺りの技術を意識している。

　実際の現場では、仕様変更に対する準備が不足している。マネージャはその意識が少ない。
　リスク管理の一つとして、自分の中で対策を持っておくべきもの。

【４】開発プロセスもプログラミングと同じ構造を持っている

　開発プロセスをアクティビティ図で書いてみると、プログラミングと同じ構造を持っていることに気付く。

・プロセスにもプログラムと同じように条件分岐や繰り返し処理があり、作業の順序がある。

・プロセスには首尾一貫性が大事。
　つまり、InputとOutputの間を論理的に説明できるか。
　これは、プログラミングでwhatを考えているのと同じ。

・アーキテクト(又はＳＥ)とはプロセスを自由自在に設計する人であり、技術者というよりも、色んな利害関係者へシステムを説明する人であり、他者と調整する人である。

　そんなことを考えると、アーキテクト(又はＳＥ)とは、色んな利害関係者へシステムの説明責任を負う人である、と定義できる。
　だからこそ、政治力も必要になってくる。

　開発プロセスを設計することは、プログラミング技術と同じだ、と考えた方がすっきりする時があるし、その考えで一つのモデルを作ることも可能ではなかろうか？