その６ あればいいなというドキュメントは作らない。必要最低限のドキュメントだけにする。

余裕があるスケジュールの場合はよいのだが、ソフトウェアの開発は、余裕がないことが多い。
できれば、開発中のドキュメント作成は、必要最低限のドキュメントだけにする。
あればいいなというドキュメントは、当然あったほうがよいのだが、開発途中には作成しなくても、開発に支障がないのならば、カットオーバー後にでも、ゆっくり作るべきである。

あったら、いいなというドキュメント以外になけて場いけないドキュメントはいくらでもあるはずである。そちらから作るべきである。

その５ 問題を解決することって大事

私は極端な話、進捗管理とかは誰でもできると思っている。
リーダーで一番大事な事は、問題を解決することであると思っている。

問題、課題を解決するに当たって、問題を洗い出し、
大きい問題点、あるいは全体にかかわる問題から、
先に解決してゆくことが大事である。

また、サブシステム内で閉じた課題であれば、
サブシステムリーダーに任せておけばよい。

その４ 取りまとめする人って大事

１担当の人は、その担当分のことしか、見ないことが多いので、
その狭間のことか、その全体を見る人、その全体の仕様を決めたりする人、
全体の問題解決をする人が必要である。

その人＝取りまとめする人＝サブリーダーといっても、よいのだが、
進捗管理をするだけでなく、上記のような作業をやってもらう人が必要である。
この人が結構重要で、この人には、はじめから実作業を振ることは避けたほうがよい。

問題は、あとから、あとから出てくるものだし、調整作業は馬鹿にならない工数が発生する。

その３ 見積もりって大事

プロジェクトの成功は、半分くらい見積もりにかかっているのではないかと思っている。

見積もりがうまくいったからといって、そのプロジェクトがうまくいくとは限らないが、
見積もりが、うまくいかないと、そのプロジェクトがうまくいかない可能性がぐんと跳ね上がる。

見積もりにあたって、ファンクションポイントとか、いろいろあると思うのだが、
私は、人を割り当てて、このサブシステムだったら、この人にこれくらい人をつけておけば
大丈夫。という感じで見積もっている。
あと、当然知らない人を割り当てる場合があると思うのだが、
その場合、あまり期待せず、ちょっとリスクをみて、見積もり工数も多めに
とることだろう。

その２ 体制図を描く

見積もりをするにあたって、
体制図を書くのが手っ取り早い。
体制図を書いて、
指揮系統が、１系統でなく、２系統にわたるとか、
兼任が多い場合は、うまくいかないことが多い。

しょうがない場合もあると思うが、是正するように努力すべきである。

その１ とりまとめする人間の工数も見積もりに入れる

４、５人くらいのプロジェクトだと問題ないのだが、
それ以上の、例えば、１０人程度のプロジェクトだと、中間で取りまとめる人間が必要になってくる。
私は、一人の人間が、直接面倒を見れるのは、４、５人程度だと思っている。
それ以上のプロジェクトの場合、ピラミッド形のするのがよい。
例えば、
A－B－C,D,E,F
ーGーH,I,J,K

というように、B、Gという人が必要になってくる。
これを、例えば、下記のような体制になっていると、
Aの負荷は馬鹿にならなくなり、やってられなくなってくる。

A-B,C,D,E,F,H,I,J,K

プロジェクトのうまい進め方 プロローグ

私はソフトウェアの開発の大規模プロジェクトで苦い経験をしてきた。
このような経験をしている人は少なくないと思うのだが、
歴史は繰り返すというか、反省が生かされていないというか、
馬鹿じゃないかと思うこともある。
今後、このブログで、気をつけたほうがよいことを書いてゆくので、
多少なりとも、お役に立てれば幸いです。