|
●連載・プロジェクト管理のつぼ●
第二回 「開発作業計画」と「進捗管理」
プロジェクト管理委員会
（promgt@bolero.plala.or.jp）
■はじめに
前回の第一回では、「キモに銘じておくこと」ということで、ソフトウェア開発やシステム開発業務を進める上で重視すべき考え方や事項を五カ条にまとめご紹介した。6月号が出版されたあと、多くの先輩諸兄から貴重なご意見やコメントを頂戴した。この場をお借りしてお礼申し上げるとともに、頂戴したご意見やコメント及びそのご回答等については、ビジネスコミュニケーション社のホームページで情報共有させて頂ければと考えている。
さて、古い話であるが、1991年、ICSE’91（ACM International Conference on Software Engineering）に参加した時、Bill
Curtis先生のチュートリアルを聞く機会があり、右の言葉を教えて頂いた。Muhammed Aliの言葉をソフトウェア開発のプロジェクト管理向けに焼き直しての紹介であった。筆者の一人は、いまだにシステム開発中に、ことある毎に引用させて頂いている。
プロジェクトマネージャーの仕事はよく胃の痛くなる仕事であると言われる。プロジェクト管理の手法については教科書で勉強したが、どのように適用したらよいか分からないとご質問を受けることもある。しかし、このBill
Curtis先生の言葉にあるように、理解できない対象は管理しようがないのである。理解するためにいくら教科書を読んでもそこには限界があり、現実の経験を通し、もがき苦しむことも必要なのかも知れない。
You cannot manage what
you cannot understand,
You cannot understand what
you cannot measure,
You cannot measure what
you cannot model,
You cannot model what
you cannot imagine.
－Bill Curtis －
Float like a butterfly,
Sting like a bee,
Your hand can't hit,
what your eyes can't see,
－Muhammed Ali － |
第二回のプロジェクト管理のツボでは、開発作業計画策定と進捗管理に焦点をあて、注意しなければいけない事項や観点についてご紹介する。開発モデルにはウォーターフォール・モデルや、RUP（Rational
Unified Process）、XP（eXtream Programming）等の段階的/反復型開発モデルもあり、どの開発モデルを採用するかによって工程管理や開発の仕方は違ってくる。本稿は、どちらかと言うとウォーターフォール的な観点が強いことは否めないが、なるべく一般的な観点から、開発作業計画を作る上で、重視すべき考え方や事項についてご紹介する。
■開発作業計画策定
（１）作業対象と所用資源に着目する
マネージャーの重要な仕事のひとつに作業計画の作成・承認がある。その作業計画を作る際の重要なポイントとして下記の３点がある。
①開発物の構成要素及び開発プロセスに着目し工程を組み立てること。
②各工程を実施するための所要資源（以下リソース）を明らかにすること。
③各工程には実行フェーズに先立って必ず計画策定フェーズを設定し、計画策定フェーズにも人的リソースを割り当てること。
実際の開発作業では、本来発注者自身が行なわなければならない業務を委託先に代行してもらう場合もある。そうすることで開発管理作業を効率的に実施できる場合もあるという理由による。上記の3点は、開発作業計画を自ら作成する場合も、委託先に作成代行してもらいそれを承認する場合にも当てはまる。
委託先に開発作業計画の作成を代行してもらう場合、委託先からあがってきた開発作業計画案を、リソース裏付けの確認なしに鵜呑みにするマネージャーを時々見かける。自明であり改めて説明の必要もない事項ではあるが、これは極めて危険な行動である。開発作業計画が、仕様策定・調整、ソフト設計、デバッグ、テスト準備、ハードウェア工事、ネットワーク工事・設定、テスト、システムテスト、移行、運用試験等の工程毎に紙の上ではもっともらしく報告され、そこには疑いの余地もないように思えることがよくある。しかし、発注者側は詳細にわたりチェックしなければならない。
作業対象を開発物の構成要素と開発プロセスの両面で漏れなく拾い出すためには、プロセス資産（各種開発作業標準、チェックリスト、レビューリスト等）や過去の作業記録を参考にして、抜けや作業の並行性/同期性などに問題がないかどうかチェックする。またプロセスの中には重要な会議体（定例会議や工程終了承認会議など）を盛り込むことも忘れてはならない。
第２のポイントはリソースの裏付けを得ることである。リソースの裏付けのない計画は、単なる願望に過ぎないといっても過言ではない。ここで、リソースとは人間の工数、作業時間、作業場所、検証環境、作業用資材（例えば、試験用端末、試験用ID
、試験用のデータ類）などを意味する。作業の実行途中で何らかのリソース不足が判った場合、通常、その手当てに時間がかかることが多い。リソース不足が頻発すると、その再準備や調整に時間がかかり、致命的な問題へと発展していく。必要な量はいくらか、無理なく調達できるか、などを十分吟味した上で計画を決定する。計画策定は、「悲観的に準備し、楽観的に実施する」[１]の原則に則り、悲観的にトラブル発生なども想定して策定する。
計画の安全性を高めるには、机上シミュレーションも欠かせない。個々の作業対象に対してリソースを数値や固有名詞で割り当ててみて、作業が計画どおり進むケースやトラブルが発生するケースで、リソースが消費される姿を経験者も参加してシミュレートしてみることだ。これを何度か繰り返すと、リソースの競合回避やマージン設定の仕方が判ってくる。また、計画は書面化するとともに基本的な要素は定量化し、数字で表現しておくことがポイントである。
第３番目のポイントは、このような計画策定作業に対しても人的リソースを見積もっておくということである。頭では計画策定作業の稼動について理解していても、開発期間の短縮や工数の縮小等の理由から、計画策定に関するリソース割付が軽視されることがよくある。開発側が入れたくても、発注者側の理解が得られないという場合もある。小規模な開発においては目立たない作業かも知れないが、大規模開発になればなるほど、この計画策定作業、シミュレーション作業が重要になってくる。
（２）計画の骨子は工程実行の前に完成させる
「走りながら考える」という言い方がある。相手の出方が読めない交渉の場合などはこのような方法を採用することがあり、システム開発のマネジメントにもある種このような側面があるのは事実である。しかし、開発作業では大規模になればなる程周到な準備をしてから走り出さないと、いざ事が起こったときに、走ることも考えることも出来なくなる。計画の骨子は事前に書面化し、メンバーと共有しておくことが大切である。
実行時の狂いを小さくするために計画段階で仕事のシミュレーションを実施するが、思い通りに進まなくなるのが常で、工程の途中で計画の修正が必要になる。しかも修正を素早く行なわないと関係者の待機や関連作業との同期合わせのための時間や調整稼動がどんどん増加する。
準備を疎かにし、そのときになって一からやり始めるとマネジメントネックによる中断や迷走を引き起こす。作業計画の骨組みが出来て関係者と認識が共有できていれば実行段階での修正判断は比較的迅速・的確にできる。
（３）実施責任体制を確立する
作業対象が特定できたら、それらに対する実施責任体制（具体的なリソース（例えば、組織や個人の依頼先）の割当てと指示系統）を決める。マネージャーは自分が所管する全体計画に対して責任を負う。一方、個別要素作業の実施・管理については部下や依頼先が担当する。所謂、分業体制をとる。その分業における実施責任体制を作ることがここでの主目的になる。
実施責任体制を作るときに注意することの一つに、「よく組織図などで見かける責任者を筆頭とし階層的体系の中に名前を書くピラミッド構造の絵のようなものをいきなり書いてはいけない」がある。
表１に示すような作業対象と具体リソースとの対応表（マトリックス）が先ず必要であり、その表を使って作業対象一つずつに対して個人名などの具体リソースを割り当てる。何故、前述の「ピラミッドの絵」が向かないかというと、「ピラミッドの絵」は指揮命令系統（管理体制）を表現することを主目的にしているため、実行すべき作業対象の構造表現が不明確になり、漏れがでる危険性が存在するからである。
表1 プロジェクト体制図例
開発物の構成要素や開発プロセスの種類が多く複雑である場合や、プロジェクトの構成員が必ずしも経験豊富でない場合、プロジェクト開始時に個人や委託先の組織に対してミッションを明確に伝えることが重要となる。このような時は、構成要素や開発プロセスと、具体リソースの対応表を用いてまず責任対象を明確に説明する。その後に、「ピラミッドの絵」を使うなりして指揮命令や管理体制を示すというアプローチをとると効果があるように思う。
NEXT >>
|
|
|
