第６回　大規模プロジェクトの体験を通して（その１：数値管理について）

筆者は最初のプログラム開発時にサブ・リーダーを指名されましたが、作業計画（要件定義作業、設計作業、製造作業、試験作業など）が全く立てられませんでした。 開発規模が不明な状態の時に、先輩のリーダーがこれから先の作業予定を立案したことが不思議でした。とにかく先輩の立てた作業計画通りに実行していくと、途中で何回も徹夜作業を繰り返しましたが、なんとか予定の納期に開発作業が完了しました。

次のプログラム開発時には自分で上手く作業計画が立てられるようになりたいと思い、最初のプロジェクト遂行中に、全工程に渡って様々な作業の作業時間をチーム全員から取得しました。幸いなことに要件定義から最後までプロジェクトに参加したので、各種ドキュメント作成枚数とその作業時間、各工程のレビュー時間と検出バグ数、コーディングの作成行数と作業時間、各試験の項目数とテスト時間および検出バグ数、検出バグの分類など開発に必要な作業を網羅したデータを一通り収集出来ました。

このデータから開発規模１千行当りの各工程の作業時間平均値を算出して、開発規模から工程毎の作業期間とチーム要員数を求められるようにしました。最初のプロジェクトの平均作業時間数値を、次のプロジェクトでそのまま使いましたが、平均作業時間はかなり相違していました。開発業務内容、開発メンバのスキル、お客様、開発環境などのプロジェクト条件によって平均作業数値が異なるようなので、そのプロジェクトの実測値を使わないと誤差が大きくなることが分かりました。以後はプロジェクトの作業工程毎に序盤で実測したデータを使って、その作業工程完了までの作業量を予測して、最初の計画時間を補正しながら進捗管理をするようにしました。

当時は開発規模から作業計画（作業工程毎の作業時間）を立案していましたので、「開発規模見積り」と「各作業工程の規模当りの平均作業時間」は重要な数値でした。周りの様々なプロジェクトからも実測値を収集し始め、１９７０年代の後半には約５０プロジェクトの実数値が収集できました。そのデータから、開発言語（アセンブラ／ＣＯＢＯＬ）／処理形態（オンライン／バッチ）／プログラム種類（制御処理／業務処理）などの組合せパターン単位に平均作業時間が大まかに分類できることが分かり、その組合せパターン毎に基準となる平均作業時間を算出しました。筆者はプロジェクトの作業計画を立てる時の目安としてパターン毎の平均作業時間を使い、そのプロジェクトの序盤で収集した実数値で計画値を補正しながらプロジェクト・マネジメントを行うことが精度の高い数値管理方法だと確信するに至りました。

一方、メンバの心理状態が作業能率に及ぼす影響を知るために、あるプロジェクトで、作業能率に影響を及ぼす諸データを取得して統計学手法で因果関係を調べました。仕事に集中出来無い心理状態の時（悩みのある時や上司と衝突した時など）は作業能率が低く、仕事に集中できる心理状態の時（やる気のある時や爽快な時など）は、作業能率が高く、その差が数倍近くなるのに驚きました。この実験の結果、スキル差よりも心理的な要因が作業能率や作業品質に大きく影響することを認識しました。

それからは、プロジェクト管理の数値（予算管理、進捗管理、品質管理）は、そのプロジェクトのメンバあるいはチーム全体の心理状態を示すバロメータとしても上手に活用すべきだと思いました。その時にマネジメントの基本は「先ず、メンバやチーム全体の心理的状態を良い状態（モチベーションの高い状態）で維持することだ」と気が付きました。それ以後は、「各管理数値」と「メンバやチームの心理状態」の関係を常に把握して、プロジェクト・マネジメントを実施するようになりました。

管理数値が悪化すると要員の心理状態を分析して良くする対策を考え、心理状態が悪い兆候（元気が無い、休暇が多いなど）が現れると、早めに予防策を考えました。また、人間関係（お客様と主要要員、主要要員同士）も作業能率に大きな影響を及ぼすことも分かり、コミュニケーションの不得意なメンバ間には仲を取持つメンバ（接着剤のような人）を投入したり、相性の悪いメンバの片方を交代（自社要員だけでなく、場合によっては協力会社要員やお客様側のメンバを含む）したことも度々ありました。チーム全体が沈んだ雰囲気のプロジェクトには、チームの雰囲気を明るくするメンバ（ムード・メーカー）を投入しました。特に主要メンバの途中交代は、後遺症が大きいので避けたかったのですが、プロジェクトへのメリットとデメリットをクールに考えて、メリットが大きい場合にはメンバ交代を敢えて実施しました。交代させられたメンバから恨まれたこともありました。プロジェクト・マネジメントにとって、主要メンバの途中交代が一番難しい仕事でしたが、最も効果のある対策でした。

大規模プロジェクトで数値管理を上手に活用して、マネジメントするには大きな問題があります。

第一の問題は、大きいプロジェクト程、現状を示す数値がリアルタイムに収集出来なくなることです。
最初は整然と数値管理をしていても、途中から最新状態を把握できなくなるプロジェクトもありました。数値管理を徹底出来ない理由は「開発に参加した多数のＩＴ企業（メーカ、ＳＩベンダ、ソフトハウス）の管理手法が異なるために管理数値の統一化に苦労すること」、「一括請負契約では管理コストの増大を理由に細かい数値報告を拒否されること」、「せっかく数値管理を始めても問題が発生すると問題対処作業が優先されるために最新状態の管理数値が把握出来なくなったこと」など、理由は様々でした。筆者がサービス開始直前２ケ月前に応援した問題プロジェクトの例を挙げると、チームのモチベーションが極端に低下していたために、報告された管理数値が全く信用出来無い状態でした。報告数値の精度を上げるための施策を幾つか実行しても功を奏さなかったので、窮余の策として「自分の出したバグ１件を正直に報告・修正するだけで賞品（五百円相当）を出す」という奇策を実施したところ、やっと正確な数値が収集出来るようになりました。「この時期にバグを出すと、責められるのでバグを隠したい」というメンバの心理状態を感じたので、「正直に報告して早く修正した方が得する」という心理的状態を作り出すための奇策でした。勿論「バグを出した人に賞品を出なんてとんでもない」という反論がありましたが、「緊急措置として有効な方法だった」と今でも筆者は思っています。この奇策の実行により状況把握が正確になり、的確な対策が実施出来た結果、そのプロジェクトは提供機能を縮小しましたが、サービス開始時期を死守出来ました。

第二の問題は、人間の心理的状態を軽視して、機械的に要員数の増減だけでプロジェクト・マネジメントを実施することです。
モチベーションの低下したケース、コミュニケーションが悪いケースなどは、予想した要員数の追加投入では解決せずに、要員追加対策を繰り返すプロジェクトが多いのです。要員追加投入の前に、メンバやチームの心理状態をマネジメントすべきです。問題を発生したチームは沈滞した雰囲気になるので、チームにはムード・メーカーが必要になります。場合によってはチームの心理状態を沈滞させているメンバを外すことも必要です。

こうしてチームの心理状態を良くしてから、遅延した作業を回復するための要員追加策などを実施すべきです。問題は１回の対策で早期に解決することが重要です。例え追加投入要員が過剰でも、早く解決する方が結果的に得策です。最初の追加投入要員をケチった結果、解決が長引いて予算の２倍以上のコストを要したプロジェクトもありました。単純に必要スキル要員×人数＝不足作業工数の計算式のようには、問題は解決しないのです。追加要員に依頼する作業の説明をする人がネックになり、説明まで何日間も待たされる笑い話のようなロスが発生することもありました。

数値による管理は重要ですが、メンバやチームの心理状態を十分に配慮してマネジメントをすべきです。