社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

プロジェクト管理のキモ(進捗管理)

プロジェクト管理の中の進捗管理の説明です。

進捗管理は、プロジェクトマネージャーなら誰でもやっていることですが、難しいのは定量化です。進捗をどのように感覚ではなく数値で表すことができるか、プロジェクトマネージャーを悩ませます。

プロジェクトマネージャーがある程度中身にも踏み込んで管理できる規模のプロジェクトであれば、定量化できないものを無理して定量化する必要はありません。それだとスキルの低いプロジェクトマネージャーだと正しい進捗が分からなくなるという意見がありますが、スキルの低いプロジェクトマネージャーであれば適切な定量化なんてできないので、定量化してもしなくても結果は同じです。むしろスキルの低いプロジェクトマネージャーに難しい定量化を要求することで、無駄な時間を割かせてしまい逆効果になることの方が多いです(特にモチベーションの低下)。スキルの低いプロジェクトマネージャーの場合、その上司は心配でとにかく定量化した数値を求めたがりますが、一度プロジェクトマネージャーとして任せたのであれば、徹底して信頼してあげることの方がプロジェクトは上手くいきます。

なぜ定量化が難しいのか?それは現実に起こっていることを数字で表すことなんてできないからです。仮に無理に数字で表したとしても、それは全体の中のごく一部でしかないので、その数字で判断できることは非常に限られます。

では進捗管理で、定量化する必要はないのか?

これもまた違います。やはり進捗管理定量化した方がいいです。品質管理も同様ですが、進捗や品質の状態を数値化することで得られるメリットは、それを武器にベンダーとロジカルに交渉することができるようになることです。(ベンダーの立場であれば、発注者と交渉することができるようになる)

プロジェクトマネージャーが進捗が遅れている、あるいは品質が悪いと判断した場合、それが数値に現れているとベンダーと交渉がしやすいのです。つまりプロジェクトマネージャーが全体を把握できる規模のプロジェクトの場合、その判断は数値ではなく自分の嗅覚で判断し、その裏付けとして数値を使います。基本的に分析というものは全てこの考え方です。これはおかしいという直感に基づいて数値をこねくりまわし、直感が正しかったか、少し直感がずれていたか検証をします。そういう意味で進捗管理定量化は重要です。

1.進捗管理定量

進捗管理定量化と言えば、アーンド・バリュー・マネジメント(Earned Value Management, EVM)です。でもEVMは非常に運用の負荷が高く、ちょっとやそっとの規模のプロジェクトだと、無駄に管理の負担が大きくなるだけで効果なんてありません。実際にSier含めてEVMで進捗管理をしているプロジェクトは、ほとんどありません。感覚的には最低でも100億円を超えるプロジェクトでなければ、効果が出ないのではないでしょうか。

それなので大部分のプロジェクトでは、いろいろ試行錯誤、屁理屈をつけながら上司などの要請に応じて進捗管理定量化を行っているのが実態です。

一番楽なのは、感覚的な進捗率です。まだ20%くらいかな。そろそろ50%くらいだろう。あと少しで終わりそうなので80%くらいかな。これで許されるプロジェクトは恵まれています。20%の根拠を示せ、80%の根拠を示せ、と通常は言われてしまいます。製造工程でプログラム本数が決まっているようなケースや、テスト工程でテストの実施フェーズに入ってからの管理などは定量化しやすいのですが、要件定義や設計工程、テストケースの作成などは、そもそも成果物であるドキュメントのページ数の母数が分からないので、超感覚的に無理矢理母数を作って進捗率を管理しているフリをします。ですが、ドキュメントを作っているうちに母数も増えていき、いつまで経っても進捗率が80%のまま、という状態も良くあることです。

さらにはドキュメントの場合、作った後のレビューによる手戻りも想定する必要があるので、作成完了状態を80%として、そこまではページ数で進捗を管理して、作成が完了すると80%、レビュー完了で90%、指摘の反映が終わって100%とか定義したりもします。でも品質が悪くて指摘箇所がたくさんあると、やはりいつまで経っても80%の状態が続いたりします。

これでは進捗管理しているとは言えません。

2.進捗管理のキモ

EVMは大変な割に、実際に管理できるのは実は進捗ではなくコストの見込みです。それ以外の方法も、母数が定まらなかったり、レビューの指摘反映という終わりが見えない状態に陥ったり、定量化した進捗の数値はあてになりません。それなので大部分のプロジェクトでは、一応、進捗を定量化してはいますが、実際の管理はプロジェクトマネージャーの感覚に頼っているのが実態です。

ではプロジェクトの進捗管理は、無理なのでしょうか?

実は、「設計書100ページ中60ページ終了したので60%」とか「テストケース1000ケースのうち450ケース消化したので45%」といったパーセンテージは、進捗率ではなく完了率なのです。完了率だからいつまで経っても80%という状態が発生するのです。そして完了率だから、いつまでも80%という状態が続くことは、不思議なことではないのです。

進捗率とは、いつまでに50ページ完了して、いつまでに80ページ完了して、いつまでに100ページ完了しているという計画があって、その計画に対して進んでいるのか遅れているのかが進捗率です。母数は予定している全量ではなく、その日時点の計画上の完了数なのです。

ですが計画上の数値をページ数とかテストケース数とかにしてしまうと、結局、母数が変わってしまう問題は解決しません。ではどうするか?完了率を計画するのです。

いつまでに50%完了させる。いつまでに80%完了させる。いつまでに100%完了させる。という計画を立てれば、母数が増えても減っても計画上の完了率と実績の完了率を比較することで進捗が把握できます。

先週、計画完了率が60%で実績完了率が61%でした。今週は計画完了率が70%で実績完了率が65%でした。これは5%の遅延であることが明確です。遅延していることが把握できれば、なぜ遅延したのか追求することができます。実は祝日が多い週で計画に無理があった、とか、作成したページ数は予定通りだったけど母数を低く見積もって母数も増えたから、とか、担当者が休んでしまい予定していたページ数が仕上がらなかったから、とか。

実はこの考え方はEVMのSPIの考え方です。本当のSPIは考え方や運用が難しいですが、この「なんちゃってSPI」なら負担がかかりませんし、数値化できるので、現実のプロジェクトではとても有効な方法です。

【振り返り】

今回はプロジェクト管理の中の進捗管理の説明でした。次回は変更管理の説明をしていきたいと思います。

①.進捗管理
②.品質管理
③.コスト管理
④.課題管理
⑤.リスク管理
⑥.変更管理
⑦.コミュニケーション管理
⑧.成果物管理(文書管理)
⑨.要員管理
⑩.ステークホルダー管理
⑪.外注管理