2009年2月10日火曜日

開発プロセスにおける妄想

特に使い道のない妄想を書いたのでblogにはっておく。

【目標】正しいアジャイル型のプロセスをもつ組織になる
【補足】アジャイルの肝は規律である!

【目標】顧客にとって本当に価値のあるシステムを構築しやすいプロセスをもつ組織になる
【補足】単純な人月の論理を顧客に押しつけないこと。顧客の満足をめざし、そこから得られるチームの喜びに執着すること。

実現するためには。。。

1.開発プロセスの標準化について

「プロセス」という上段から入ると収集がつかなくなるか本当に大切なことを見落とすことになる。なぜならプロセスは「概念」レベルだから。まずはプロジェクトを遂行する上で計画や作業の抜け漏れを防ぐために「アクティビティ」の洗い出しを優先する。

(参考までに)
 プロセス     概念。作業手順を抽象化したもの。
 └アクティビティ 論理。動きや振る舞い、活動を表す。
  └タスク    現実、物理的なもの。人やモノに結びつく。対象物が存在する。
 
 プロセスの標準化において、現時点で洗い出すものを「アクティビティ」のレベルとしたのには理由がある。
 プロセスのレベルではあまりにも抽象的すぎて営業レベルで話す分には問題がないかもしれないが、プロジェクトに適用するのは無理。そもそも抽象の度合いが強すぎて解釈が大幅にぶれる。タスクのレベルは実際のプロジェクトでないと決めることが難しく、現実のプロジェクトにおいても日々増減をするものなので、事前に決めるのには無理がある。
 
 
2.アクティビティの洗い出しについて(マッピング)

プロジェクトにおけるアクティビティは多い。そこでPMBOKの5つのプロセスと9つの知識エリアを利用してマッピングをして整理する。

<PMBOK>
http://www.netlaputa.ne.jp/~hijk/study/docs/pmbok_overview.html#AContents
 プロジェクトのプロセス
1.立ち上げのプロセス プロジェクトの次のフェーズの着手を組織としてコミットする。
2.計画のプロセス
3.遂行(実行)のプロセス
4.コントロールのプロセス 計画からの乖離を識別するために、 プロジェクトの進捗は定期的に測定する必要がある。
5.終結のプロセス
 知識エリア
統合マネジメント
スコープマネジメント
タイムマネジメント
コストマネジメント
品質マネジメント
組織マネジメント(リソース)
コミュニケーションマネジメント
リスクマネジメント
調達マネジメント

 なぜPMBOKなのか? それはPMBOKがプロジェクトの「順序」よりも扱わなければならない「事象」に重きおいているからだ。
 順序が間違っていても、扱う事象が正しければプロジェクトはいつかは終わる。逆に順序が正しくても、扱う事象が間違っていればプロジェクトは終わらない。


3.アクティビティの洗い出し(なにから手をつけるか?)

 最初にコミュニケーション、次に品質から洗い出すことをオススメしたい。もちろん理由はある。ちょっと遠回りだが説明をする。
 プロジェクトにおいて「早い、安い、旨い」の3つを実現するのは難しい。何か1つを犠牲にすれば2つは実現できる。しかし3つ全部はそれなりに考える必要があるが優先順位をつけることで打開できはずだ。
 
 「早い」
 逆の視点。遅いはどうだろうか? システム開発において遅いはあらゆる観点で罪だ。遅いは「高い」にもつながる。

 「旨い」
 品質は早いを実現する必須条件である。プロジェクトの進捗を滞らせる原因はあらゆるフェーズに潜むバグである。プログラムのバグもそうだが、プログラムのバグの元になる設計のバグ、設計のバグの元になるコミュニケーションのバグ。これらは手直しに工数を要するため結果として早さと安さを犠牲にしてしまう。
 つまり「旨い」は「早い」につながり、結果として「安い」を導き出す。3要素を高レベルで達成することを目指さないと、これから先の開発ベンダーは生き残っていくことが厳しくなってくる。
 ならば品質から着手するべきではないかと思ってしまうが、結局、品質を下げる原因になるのはコミュニケーションのエラー(バグ)だ。認識の違い、情報共有の拙さがエラーを生み出し貴重な時間を浪費することになる。また顧客が本当に必要とする価値のあるシステムにたいする要求を拾い上げる妨げにもなる。だから洗い出すべき最初のアクティビティはコミュニケーションを中心に行う必要がある。
現実のプロジェクトにおいても、品質要件や非機能要求は顧客とのコミュニケーションから生み出される。目標もはっきりしなければどの程度の品質を確保すればいいのかすらわからないはずだ。



4.モデルプロジェクトの構築

PMBOKへのマッピングが終わったらモデルプロジェクトを構築しレビューを行う。まず手始めに10~20人月程度のプロジェクトを想定してみると良い。10人月未満のプロジェクトではプロセスはそれほど大切ではなく個々人のスキルに依存する割合が高い。20人月を超えるプロジェクトはより厳格なプロセスが必要になり扱いが困難になる。10~20人月のプロジェクトをしっかり運営できるようにすることから始めるのは決して悪い話ではない。
そしてしっかり洗い出されたアクティビティがベースになっていれば、抜けや漏れがあることは考えづらい。今度は「冗長」なアクティビティを省略する作業を行う。これも「早い、安い、旨い」を高レベルで達成するために必要な手段である。


5.注意点

これらの作業を進めていく上で気をつけること。おそらくいろいろな要素が関連し合い、まとめたり洗い出したりする作業が困難になってくる時期がある。そういうときは下記の原則を思い出すこと。

・インプットとアウトプットに着目し、シンプルに考える
・正しい行動は「考える、実行する、確認する」の3つの要素でなりたっていること。迷ったらこれを思いだしシンプルに考える。

アクティビティの洗い出しを進めるとき、序盤でどれくらいの時間がかかったのか記録をしておこう。こうすることであとどれくらいで作業が完了するのか、より正確性の高い見積もりができるはずだ。





多分ね~。