« Erlang勉強会#1 | トップページ | Eclipseリファクタリング・メモ »

2007/06/05

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

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

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

【1】新規開発と派生開発~IT業界特有の開発プロセス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|

« Erlang勉強会#1 | トップページ | Eclipseリファクタリング・メモ »

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/15326961

この記事へのトラックバック一覧です: 開発プロセスを設計するという発想:

» [tech]和RUP [yojikのブログロ]
開発プロセスを設計するという発想 内容そのものは、非常に同意です。ただRUPに関しては誤解があるように思う。 作成フェーズ以降のRUPにおいて開発の軸となるのは「変更要求」で、これをインプットにして実装、検証していくプロセスは、よくあるバグトラッキングのプロセス... [続きを読む]

受信: 2007/06/08 00:21

« Erlang勉強会#1 | トップページ | Eclipseリファクタリング・メモ »