http://itpro.nikkeibp.co.jp/article/COLUMN/20101222/355585/?ST=upper
PART1 追加メンバーは来ない、工程・タスクごとに進捗守ろう
「プロジェクトの進捗は遅れるもの」という考えはもう許されない。追加メンバーの投入やスコープダウンが難しくなったことで、工程やタスクごとに進捗を守ることが求められる。チームのマネジメントや個人の仕事を工夫し、進捗遅れを一掃しよう。
ITベンダーA社のプロジェクトマネジャーである山田氏（仮名）は2年前、システム開発の進捗遅れで、悔しい思いをした。それは、外資系のユーザー企業B社の勤怠管理システムの構築を担当したときのことだった。
このプロジェクトは当初、A社の別のプロジェクトマネジャーが担当していた。しかしB社の勤怠の業務ルールが極めて複雑なこともあり、途中からプロジェクトが進まなくなった。そこで、勤怠管理システムの構築経験が豊富な山田氏が、プロジェクトマネジャーとしてプロジェクトを引き継ぐことになった。
プロジェクトオーナーであるB社の人事部長と協議して納期を設定し直したが、要件定義を最初からやり直す必要があり、ほとんど余裕期間（バッファー）を確保できなかった。
稼働が2日遅れ人事部長が更迭
タイトなスケジュールだったにもかかわらず、山田氏は「いいシステムを構築してB社の信頼を得たい」と考え、要件定義や基本設計をじっくりと行った。その分、進捗遅れが生じた。しかし「プロジェクトの終盤に挽回すればいい」とあまり気に掛けなかった。
実際、プロジェクトの終盤になるとチーム5人が一丸となって追い込みをかけた。地方の営業所でのテストで大きなトラブルが発生したこともあり納期には間に合わなかったが、なんとか2日遅れで稼働させることができた。B社の人事部長から感謝の言葉を掛けてもらい、山田氏は手応えを感じた。
ところがしばらくして、山田氏はその人事部長が更迭されたことを知った。新システムの稼働が計画よりも2日遅れた責任を取らされたらしい。プロジェクトの事後監査で、プロジェクトオーナーである人事部長のマネジメント能力が不足している、と判断されたようだった。
この1件で山田氏は、進捗遅れに対する自らの考えの甘さを痛感した。「プロジェクトの終盤には予期せぬトラブルが起こる。納期を守るには序盤から進捗遅れを起こしてはいけない」（山田氏）。それ以来、進捗遅れを防ぐため、進捗管理や課題管理のやり方を改善するなど、プロジェクトマネジメントの工夫を積み重ねている。
人員追加やスコープダウンが難しく
2日遅れで責任者が更迭というのは極端な例だが、一般にプロジェクトの事後監査が厳しくなっており、稼働の遅れによってプロジェクトオーナーやプロジェクトマネジャーの責任が問われることがある。双日システムズの小松原 健氏（エンタープライズソリューション本部 SGソリューション部 部長）は「利用部門におけるビジネスのスピードが上がっており、少しでも早く新システムを使いたいという要望が近年ますます強くなっている」と話す。
一方で、「進捗が遅れたときに挽回するための打ち手が減り、プロジェクトマネジャーにとってハードルが上がっている」とNECの奥沢 薫氏（システム技術統括本部 主席PMO）は指摘する（図1）。例えば、プロジェクトの予算の縮減で、進捗遅れを挽回するための追加メンバーの投入が難しくなった。さらに、2次開発プロジェクトへの先送りを前提としたスコープダウン（システム機能や帳票などの削減）もできないケースが増えている。2次開発プロジェクトが本当にあるのかどうか、あったとしてもどれだけの予算がつくのかが分からないからである。
このように、今やいったん進捗が遅れると挽回するのは容易ではない。そのため、プロジェクトの全工程を通じて、工程やタスクごとに進捗を守ることが求められる。
進捗遅れを起こす三つの原因と対策
では、進捗遅れが起こる大きな原因は何か。どうすれば、進捗遅れを防ぐことができるか。
原因は、要件定義ができていない、見積もりの精度が低い、品質管理が甘い、など多岐にわたるが、取材したプロジェクトマネジャーの多くが指摘したものが三つある（図2左）。
一つ目は、進捗遅れに対するチームの意識が低いことだ。メンバー一人ひとりが「遅れるのは仕方がない」と思っているようでは、進捗遅れは防げない。そのため、チーム全体で危機感を共有し、適度なプレッシャーを掛けることが重要である。
二つ目は、進捗遅れをなかなか発見できないこと。メンバーからの進捗は「半分ぐらい進んでいます」「9割は終わった感じです」といった感覚的なものであることが多い。そのため仕掛かり中のタスクの正確な進捗状況をつかめず、タスクが完了した時点でようやくどれだけの進捗遅れなのかが判明する。これには、進捗遅れの先行指標となる情報（残業時間の増加など）を収集することが対策になる。
重要な課題が放置されること。これが三つ目の原因である。次々と発生する課題は一般に課題管理表で管理するが、その運用が形骸化することが少なくない。課題管理表をフルに活用し、迅速かつ確実に課題を解消することが求められる。
上記三つの原因への対策として、現場のプロジェクトマネジャーが実践している工夫を、次回からのPART2で詳しく見ていく。さらに本記事の別掲記事では、日立ソリューションズが実施した興味深い調査結果を紹介する。進捗遅れを起こすプロジェクトやプロジェクトマネジャーの性質が明らかにされている。
PART3では、ITエンジニアが個人で実践できる、期限を守る仕事術を取り上げる。誰しも「さまざまな作業を次々とアサインされてどれから片付けるべきか混乱した」「期限の間際に割り込み作業が入って追い込みが利かなかった」といった経験はあるだろう。これらも進捗遅れの大きな原因になる。その対策として、現場のITエンジニアの仕事術が参考になるはずだ。
最後のPART4では、異業種における進捗遅れを防ぐ仕組みを紹介する。取り上げるのは、ビル建築と宅配便である。ビル建築では完成が遅れると違約金が発生し、宅配便では荷物の遅配は信用問題になる。しかもどちらも、いったん進捗遅れが起こると挽回するのは難しいので、進捗遅れが許されない。前田建設工業とヤマト運輸を例に、進捗厳守の仕組みを見ていく。
進捗遅れを起こすプロジェクトとマネジャーの性質
どういう性質のプロジェクトおよびマネジャーだと、進捗遅れが起こりやすいのか。日立ソリューションズはこれを調べるため、過去のプロジェクトを分析した。調査を主導した同社PMOの千種実氏に、結果を報告してもらう。
筆者は日立ソリューションズのPMO（Project Management Office）に所属しており、どういうプロジェクトあるいはプロジェクトマネジャーが進捗遅れなどのリスクを抱えているのか、いつも頭を悩ませる。そこで、自社で実際に手がけたシステム開発プロジェクトから109件をサンプリングし、プロジェクトおよびマネジャーのどんな性質が、進捗（納期）遅れ、原価割れ、品質悪化と関係するのかについて分析を試みた。ここではそれらの分析結果のうち、進捗遅れとの関係を中心にお伝えしたい。
コミュニケーション力が最も影響
まずプロジェクトマネジャーの性質と進捗の関係について見ていこう。プロジェクトマネジャーのコンピテンシー（中核スキル）として当社が定めている、成果重視、チームワーク、モチベート、ユーザー志向、ネゴシエーション、コミュニケーション、オネスティ（誠実さ）という7項目について、進捗の順守/遅れとの関係の強さを分析した。その結果が図A左である。
最も数値が高かったのは、コミュニケーションである（25％）。これは、ユーザーや開発チームのメンバーなど主要なステークホルダー（利害関係者）に対し、十分に相手を理解し自分の意図を的確に伝えるスキルだ。具体的には、ステークホルダー分析を行い、会議体やメーリングリストなどの必要なコミュニケーション手段・チャネルを把握したり、コミュニケーション計画を立てて実行したりできるかどうか。このスキルの高さによって、進捗遅れが起こるかどうかが左右される。
2番目に数値が高かったのは、ネゴシエーションである（23％）。相手の反応や反発を予測し、どう対応するかというプランを考え実行するスキルを表す。相手の要望・ニーズを探り説得力のある交渉が行えるか。ときには、相手の強みに対抗したり、弱みを利用したりできるか。そういうタフな交渉力が、進捗遅れを防ぐために求められる。
ユーザー志向が進捗遅れを防ぐ
3番目はユーザー志向である（22％）。積極的にユーザーの不満や不安を把握し、その解消に努めるスキルのことだ。
単純に考えると、ユーザー志向が強いプロジェクトマネジャーは、ユーザーからの仕様変更などの要望を聞き入れて進捗遅れを起こすように思えるかもしれない。しかし分析すると、ユーザー志向の高いプロジェクトマネジャーほど進捗遅れを起こしていなかった。ユーザー志向が高いと、進捗に関しても要望に応えようと遅れないように努めるのに加え、ユーザーを深く理解するので無理な要望にノーと言えるからだと思う。
4番目のモチベートも19％と高い数値だった。進捗遅れを起こさないためには、進捗管理を徹底するだけではダメで、どれだけメンバーのモチベーションを高められるかが鍵を握るというわけだ。
なお進捗だけでなく、原価、品質についても同様の分析を行った（図A右）。原価は、進捗の結果と似ており、コミュニケーション、モチベート、ネゴシエーションが上位に入った。ただし品質の分析結果は大きく異なった。トップ3は、チームワーク、オネスティ、成果重視。基盤やアプリケーションなどで分かれたサブチームをまとめ上げ、包み隠さず情報をオープンにし、レビューやテストの結果を重要視する。品質の目標を達成できるプロジェクトマネジャーとして、そのようなイメージを描くことができる。
新技術・新製品を扱う案件に注意
プロジェクトそのものの性質項目と進捗の関係に話を進めよう（図B）。
プロジェクトの性質項目には約30個のリスク項目を用いた。そのなかで40％と圧倒的に高い数値を示したのは、新技術および最新流通製品である。次いで、プロジェクトマネジャーの自信が26％で2番目に入った。3番目は、19％の他社製品・他社接続（通常取り扱っていない製品の採用およびその製品を用いた別システムへの接続）であった。
このうち特に注目したいのは、1番目の新技術および最新流通製品と、3番目の他社製品・他社接続である。どちらも、不慣れな技術・製品を取り扱うと予期せぬことが起こり進捗が遅れる、ということを表していると思う。これは、みなさんの経験に照らしても納得感があるのではないだろうか。
また、プロジェクトのリスク項目と原価および品質の関係については、どちらもトップは、開発キーパーソンの類似開発の経験。2番目は、進捗の関係と同じく、プロジェクトマネジャーの自信だった。つまり進捗、原価、品質の三つとも、プロジェクトマネジャーの自信が2番目に入った。プロジェクトマネジャーが不安を感じるような案件はすべてがうまくいかない、というわけである。
もっとも今回の分析はサンプリング数が十分ではなかったので、緻密な分析は難しい。現在、さらに対象のプロジェクトを増やした分析を実施している。機会があれば、その結果もお伝えしたい。
分析対象は、日立ソリューションズが自社で手がけたシステム開発プロジェクト109件である。
分析に用いたプロジェクトマネジャーの性質項目は、社内のプロジェクトマネジャー認定制度で測定している七つのコンピテンシー（中核スキル）である。具体的には、成果重視、チームワーク、モチベート、ユーザー志向、ネゴシエーション、コミュニケーション、オネスティで構成される。
一方、プロジェクトの性質項目は、開始前に評価しているプロジェクトのリスク項目である。「受注内容」「システムの難易度」「システムの新規性」「開発日程」「見積内容」といった八つの領域にまたがり、合計で約30個を設定している。
これらプロジェクトマネジャーおよびプロジェクトの性質項目が、進捗・原価・品質それぞれの成功/失敗とどれだけ強く関係しているかを分析した。
実際の分析は、日立製作所の日立研究所に協力してもらった。分析手法には、「ロジットモデル」を用いた。ロジットモデルでは、ある事象の成功/不成功に対して、事象の複数の属性がそれぞれどれだけ強く関係しているかを数値として表すことができる。
日立ソリューションズ 第1プロジェクトマネジメント本部 プロジェクト推進部 部長
PART2 進捗遅れを防ぐマネジメント
進捗遅れを防ぐには、チーム全員で危機感を共有し、遅れをいち早く見つけ、課題を確実に解消していくことが重要だ。この一連のマネジメントサイクルを回すにはどうすればよいのか。進捗遅れ対策で成果を上げている現場の工夫を紹介する。
進捗遅れを防ぐ上で、プロジェクトマネジャーが果たすべき役割は大きい。たとえ優秀なメンバーが集まったとしても、マネジメント不在では、進捗遅れを防ぐのは難しいだろう。メンバーがじっくり丁寧にタスクを行えば、それによって進捗遅れが発生しかねないからである。
そこでプロジェクトマネジャーにはチーム内で進捗遅れに対する危機感を共有し、適度な緊張感・プレッシャーを生み出すことが求められる。それでも、進捗遅れは必ず起こるものである。プロジェクトマネジャーは日ごろからメンバーの様子に目を光らせ、定例会での進捗報告を待つことなく、いち早く遅れを見つけ出したい。その上で、進捗遅れの原因となる課題を確実に解消していくことも重要だ。
そこでこのPART2では、「I．危機感を共有する」「II．遅れをいち早く見つける」「III．課題を確実に解消する」という三つのテーマに分け、進捗遅れを防ぐマネジメントの工夫を紹介する。
I．危機感を共有する
進捗が遅れているのは自分だけじゃない。何とかなるだろう──。進捗遅れが常態化している現場では、メンバーがこう考えてしまうことがある。そんなときに緊張感を共有しようと、プロジェクトマネジャーが口を酸っぱくして進捗を守るように訴えても、受け流されてしまうのがオチだ。
そこでAJSの塩川康成氏（医療・産業システム事業部 医療システム部 開発グループ マネージャー）が工夫しているのは、プロジェクト全体の進捗遅れを引き起こす重要なタスクをつないだクリティカルパスの情報をチーム全体で共有することである（図1）。
「メンバーは自分の担当タスクがクリティカルパスだと分かれば、チーム全体に迷惑をかけたくない、絶対に遅れられない、と危機感を持ってくれる。そういうメンバーがいると、ほかのメンバーもそのメンバーをフォローしようとして危機感が伝播し、チーム全体に進捗を守ろうという雰囲気が醸成される」（塩川氏）という。
ただしクリティカルパスは、タスクの進捗が遅れたり挽回したりすることで変わっていく。そのたびに、どれがクリティカルパスであるかを調べるのは大きな負担になる。そこで塩川氏は、プロジェクト管理ソフトである「Microsoft Project」の分析機能を使い、自動的にクリティカルパスを表示させている。メンバー全員に日々の進捗を入力してもらう必要があるが、それ以外の手間はかからないという。
他メンバーへの影響を一目瞭然に
ウルシステムズの松井幹雄氏（シニアコンサルタント）も、塩川氏と同じように「周りに迷惑を掛けたくない」というメンバーの心理を突いて危機感を共有している。その工夫は、メンバーの担当タスクの進捗が遅れたとき、他のメンバーにどんな悪影響を及ぼすのかについて“見える化”することだ。そのために松井氏は「機能別進捗管理表」を作成している（図2）。
機能別進捗管理表では、「一括受注入力」「一括受注修正・キャンセル」といった機能ごとに、設計・開発（製造）・テスト設計という工程（タスク）の進捗を表す。遅れているタスクは、ピンクや赤の色を付けて目立たせる。設計・開発・テスト設計を経て、機能グループごとに結合テストを行う。つまり一つの機能の進捗が遅れると、それが属する機能グループ全体の結合テストが行えない。そのため機能別進捗管理表で自分の担当タスクにピンクや赤の色が付いていると、ほかの機能を担当するメンバーにも影響が及ぶことが一目瞭然である。
松井氏は、この機能別進捗管理表を週次で更新し、定例会で共有する。これによって、メンバーは「自分のせいで結合テストを遅らせたくない」という危機感を持ってくれるという。
タスクごとに余裕なしの期限を設定
メンバーにタスクをアサインするとき、余裕工数（バッファー）を削ってギリギリの納期を設定して危機感を持たせる。そんな実験的な取り組みをしているのが、TISの久木祥二氏（産業事業統括本部 サービス＆コミュニケーション事業部 サービス第1部 主査）である。久木氏は、「例えば2.5人日で終わりそうなタスクに対して、0.5人日のバッファーを割り当て3人日に設定すると、予期せぬことが起こらなくてもメンバーは0.5人日のバッファーを使い切る」という。
本来、プロジェクトのバッファーは、予期せぬことが起こったときに使うべきだ。それを各タスクに付加すれば無駄に使ってしまい、いざというときバッファーがないという状態に陥る。
そこで久木氏は2008年に携わったプロジェクトで、サブチームのリーダーに依頼し、メンバーとギリギリ達成できるかどうかという工数を相談して定めてもらい、各タスクからバッファーと思われる分の工数を削いでアサインした。削いだバッファーは共有化し、各タスクで進捗が守れなかった場合に使う。その効果は絶大で、このプロジェクトではドキュメントの改善なども併せて実施したことにより、1.6倍の生産性を実現でき、プロジェクト全体の進捗遅れも大幅に減ったという（図3）。
ただし、この工夫には難しさがある。それは、バッファーと思われる分の工数を削るといっても一律の基準はなく、どれだけ削るかが曖昧なことだ。
そのためこのプロジェクトでは、サブチームによって各タスクの予定工数をどれだけ削るかが異なった。極端に削ったサブチームでは、7～8割のタスクで予定工数をオーバーし、共有バッファーを使うことになった。「メンバーは常に予定工数をオーバーするので、予定工数内で終わらせようという意欲が薄れた」（久木氏）。このように予定工数を削り過ぎると逆効果になりかねないので、注意が必要だ。
ここ一番の「頑張ろうミーティング」
大きな問題があるわけでもないのに、チーム全体の雰囲気がピリッとせず進捗が遅れ出す。そんなときには、チーム全体にカツを入れることが必要だろう。少人数のチームであれば、特に進捗が遅れているメンバーを叱ることで、雰囲気を変えるのが一つの手だ。しかし協力会社を含む数百人規模のチームであれば、どうするか。
NTTデータの大野功氏（第一公共システム事業本部 第二公共システム事業部 第二システム統括部 システム開発担当 部長）はそんなとき、「頑張ろうミーティング」と名付けた朝礼を行う。それは次のようなものだ。
「おはようございます。NTTデータの大野です。このプロジェクトの責任者を務めております！」。朝9時半、大野氏はメンバー約100人が席に着いたオフィスのフロアの入り口付近に立ち、大声を張り上げる。プロジェクトマネジャーの話があるとだけ知らされていたメンバーは、何事かと緊張の面持ちで話に聞き入る。「プロジェクトは今まさに少しずつ遅れ出しています。このままでは、約束の納期に間に合いません。ユーザーにとって、このシステムは是が非でも納期通りに稼働しなければ困るものなのです。なぜなら…」と、大野氏が抱いている危機感を、システムの意義を交えてメンバーに伝えていく。
「できる限りのことをしますので、要望があれば何でも言ってください。納期通りにカットオーバーさせるために頑張りましょう。よろしくお願いします！」。そう言って締めくくるまで、約10分間。大野氏の気合が伝わり、雰囲気が一変するという。これをオフィスのフロアごとに繰り返していく。
いつもと違う雰囲気を演出する
大野氏は大勢の前で話すのが得意ではない。頑張ろうミーティングの冒頭は、緊張して声が震えるという。それでも大勢の前に立って話すのは、いつもと違う雰囲気を演出するためだ。
「朝からプロジェクトマネジャーが大声を上げれば、そこまでやるくらいだから本当にヤバイんだなと思ってもらえる」（大野氏）。
こうしてチーム全体で危機感を共有したら、サブチームのリーダークラスを集めた会議を開催する。この会議で、メンバーからの要望を吸い上げ、進捗遅れに対する改善活動を行うわけだ。頑張ろうミーティングですでにサブチームのリーダークラスにも危機感が伝わっているので、モチベーションが高く、改善が急ピッチで進むという。
II．遅れをいち早く見つける
「タスクの進捗率は90％です」という報告があってから、何日経っても同じ進捗率のまま──。こんな進捗報告を受けるケースは少なくないだろう。そういう進捗報告をするのは、プロジェクトマネジャーの期待に応えたいという気持ちがメンバーにあるから。だから「いくら正直に話してほしいといっても、なかなか改善しない」と、日本システムウエアの小野彰子氏（ITソリューション事業本部 フィナンシャルソリューション事業部 マネージャー）は指摘する。
かといってそうした状況を放置すれば、進捗の遅れを把握するタイミングも遅れる。そのためプロジェクトマネジャーには、いち早く進捗遅れを把握する工夫が求められる。その工夫を見ていこう。
タスクを2人日以内に細分化
日本システムウエアの小野氏は、WBSのタスクを2人日以内に細分化した上で、仕掛かり中は進捗率をゼロと見なし、完了した（製造工程であれば単体テストが終わった）時点で100％にする。これがいち早く進捗遅れを把握する工夫になるという。タスクごとの進捗をゼロか100％かでとらえるので、メンバーからの報告が正確になるからである。
タスクを細分化するのは、プロジェクトの後半である詳細設計以降の工程だ。ある画面を製造するタスクで、入力データのチェック機能を備える1個のボタンだけを切り出し、4人時のタスクとしたこともある。
このようにタスクを細分化するプロジェクトマネジャーは少なくない。豆蔵の西尾俊士氏（BS事業部 アーキテクチャグループ コンサルタント）もその1人。「タスクを細分化すれば、進捗遅れをいち早く把握できるのに加え、進捗の遅れているメンバーを別のメンバーが助けやすくなる」と西尾氏は話す。例えば半日だけ余裕のあるメンバーが、進捗の遅れているメンバーの0.5人日のタスクを代行することが可能になる。
成果物のチェックイン時刻を見る
タスクを細分化するのに加えて、進捗確認の頻度を高めることも、進捗遅れのいち早い把握に役立つ。永和システムマネジメントの木下史彦氏（サービスプロバイディング事業部 課長）は、毎日の朝会でメンバー一人ひとりがその日に行うタスクを確認した後、昼と夕方の2回にわたり進捗を確認する。
ただしプロジェクトチームの人数が多くなると、プロジェクトマネジャーが自ら頻繁に進捗を確認するのは難しくなる。電通国際情報サービスの石沢健人氏（金融ソリューション事業部 金融クライアントソリューション3部 プロジェクトディレクター）の場合、週次の定例会でサブチームのリーダーから、メンバー数十人のタスクの進捗を確認する。そのため進捗遅れの把握が、最大で6日遅れる。
そこで石沢氏は、進捗遅れをいち早く見つける工夫として、メンバー一人ひとりが構成管理ツールに成果物をチェックインした時刻を毎朝確認している（図4）。具体的には、朝出社してPCを起動すると、構成管理ツールのtracから前の晩のチェックイン時刻データを取り組み、グラフと表形式で画面に表示する。
注目するのは深夜時間帯のチェックイン件数だ。「深夜のチェックインの増加は、実質的に進捗遅れが生じ始めていることを意味する」と石沢氏。その深夜のチェックイン情報を基に、誰が遅くまで残業していたのかを把握し、声がけするなどして行き詰まっていないかどうかを探る。
メンバーの設計書を斜め読み
同様の工夫をしているのが、日立ソフトウェアエンジニアリングの池谷誠一郎氏（産業・通信システム事業部 第5システム本部 第4システム部 部長）である。池谷氏は日ごろの声がけを通じて、いつもより表情が暗かったり残業が多かったりするメンバーがいると、構成管理ツールにアクセスし、そのメンバーが作成した設計書をレビュー前の状態で目を通す。目的は、メンバーが行き詰まっていないかどうか、疲弊していないかどうかを探ることである。
といってもプロジェクトマネジャーである池谷氏には、レビュー前の設計書をじっくり見ている余裕はない。そこで、以下のように観点を絞り、数分間で一気に斜め読みしている。
- 文章が読みづらくないか（一文が長い、句読点の位置がおかしい）
- 表現が難しくないか
- 他の個所からコピーアンドペーストし、修正し忘れている個所はないか
- 図表内の注釈や説明が多すぎないか
- 図表にタイトルがあるか、不適切ではないか
- 章によって文章や図の密度が一定か
- 「検討中」などのただし書きが残っていないか
これだけの観点で設計書を斜め読みすれば、メンバーの行き詰まり具合や疲弊度合いがある程度分かり、本人と話してさらに詳しく状態を調べるべきかどうか判断が付くという。
なお池谷氏は、観点を絞って斜め読みしようとしても、ついつい設計の検討不足や細かな間違いを見つけて、詳しく読み込んでしまうことがある。そうして時間を取られるのを避けるため、斜め読みするときには観点を書いたメモをPCのモニターの脇に張り出している。
また池谷氏は構成管理ツールの履歴機能を使って前回チェックイン時との設計書の差分を確認し、差分量が少なくないか（作業が進んだかどうか）、修正個所が同じパートに偏っていないか、文章構成が大幅に変更されていないか──という観点でチェックすることもあるという。
EVMの指標でメンバー別の進捗把握
もう一つ、いち早く遅れを発見する工夫ではないが、進捗遅れにつながる問題をいち早く解決するための工夫があるので紹介しよう。
住友電工情報システムの高橋 覚氏（システムソリューション事業本部 第二システム部 第三システムグループ グループ長）らのチームでは、「EVM（Earned Value Management）」による進捗管理を行っている。EVMでは、タスクごとに工数（予定出来高）の見積もりを行い、タスクが完了するとその工数を実績出来高としてカウントし、進捗率を測る（図5）。全タスクの予定出来高の合計が100人日で、実績出来高が50人日なら、進捗率は50％である。この定量的な進捗管理をメンバー一人ひとりにも適用し、進捗遅れが発生したらただちに原因を探って対策を講じているのが特徴である。
具体的には、プロジェクトマネジャーが週次でメンバーごとに、SPI（実績出来高/予定出来高）の数値をグラフで見ていく（図5上）。SPIが1.0を下回れば進捗遅れであり、1.0以上であれば問題はない。
その際にSPIが1.0を下回る状態が続いているメンバーがいたら、メンバーの担当タスク一つひとつの進捗状況（実績）を、一覧表で確認する（図5下）。これを見ることで、メンバー本人や所属するサブチームリーダーを呼んで状況を聞く前に、原因を調べて対策を講じられる。例えば、メンバーAさんにとって難易度の高いタスクが進捗遅れの主な原因になっていた場合は、Aさんがこれから担当するタスクから難易度の高いものを外す、という具合だ。ここまで原因や対策の仮説を立ててから、Aさんや担当のサブチームリーダーと話をするので、迅速に対策を実行できるという。
III．課題を確実に解消する
進捗の遅れをいち早く見付け、そこに問題を発見したら、それを課題管理の仕組みにのせて確実に解消していくことが重要になる。ここでは、課題管理のやり方に関する現場の工夫を二つ取り上げる。
一つ目の工夫は、課題に対する対策を短時間で考えるように指示することである。この工夫を実践しているのは、ITコンサルタントであるプリベクトの北山一真氏（代表）だ。
プロジェクトチームの定例会などでメンバーに課題をアサインする際に、対策がその場で具体的に決まらないことは少なくない。そんなとき、対策を考えついたら報告するように指示してメンバーに任せてしまうと、それっきりになり、「初動が遅くなったり、課題が放置されたりする原因になる」と北山氏は指摘する（図6）。実際に従来は、1週間後の定例会で課題の状況を確認すると、「まだいい対策が考えつかない」「もう少し時間をください」と言われることがしばしばあったという。1週間が無為に経過したことで、対策が限定されることもあった。
対策立案にあえて短い期限を設定
そこで北山氏は、課題をアサインするとき、すぐに対策を考えるように指示することにした。定例会で課題をアサインした場合は、会議が終わってから1時間～3時間後を期限にする。短いように思うかもしれないが、あえてそうしているのだという。
「たとえ期限を1週間後にしても、その間に本当に集中して考えている時間は、せいぜい数十分ほど。ところが時間が経つほど、それだけの時間に見合ったいい対策が考え付かないことをメンバーが恥ずかしく思って、相談さえしてくれなくなる」（北山氏）。
そこで1時間～3時間後に期限を決めて集中して考えてもらい、その時間になったらメンバーから状況を聞く。そのとき対策が思い付いていなければ、一緒に途中まで対策を考え、また1時間～3時間後に期限を決めて最後まで対策を考えてもらう。
こうするようにしてからは、「課題への対策の初動が早くなった上に、メンバーから課題に限らず相談してもらいやすくなった」（北山氏）という。
マル秘の課題管理表で人の問題解決
二つ目の工夫は、プロジェクトマネジャーとサブチームのリーダーだけが使うマル秘の課題管理表だ。これを考案し使っているのは、エクサの月岡鉄三氏（コンサルティング推進部 担当部長 ITシニアコンサルタント）である。
マル秘の課題管理表では、主として「特定のメンバーの生産性が落ちている」といった人に関するネガティブな話題を扱う。
システム開発の現場では、メンバーのスキルや健康状態、メンバー同士の相性といったような、人に関するさまざまな問題が起こる。こうした人に関するネガティブな話題は、開発チーム全員で共有する通常の課題管理表では扱いづらい。さらにそういう話題は、プロジェクトマネジャーとサブチームのリーダーにとって特に重要だが、マネジャーとリーダーが集まる機会は限られる。そこでマル秘の課題管理表を運用することで、人に関するネガティブな話題をプロジェクトマネジャーとサブチームのリーダーが共有できるようにした。
ただし課題管理表といっても、課題を厳密に管理するのではなく、気付き情報の掲示板のようなものだ（図7）。
このマル秘の課題管理表では、例えば最近次のようなやり取りが行われた。サブチームリーダーのI氏が、若手メンバーのAさんと先輩のBさんを組ませたところ、Aさんの進捗遅れが目立つようになった、という問題を書き込んだ。これに対して、別のサブチームリーダーJ氏がアドバイスを送った。J氏によると以前、BさんにAさんを指導させたことがあったのだという。そのとき相性が悪かったので、指導役をCさんに替えた。「Cさんとはうまくいったようです。Aさんは、管理型でなく聞き上手な先輩と組ませるとよいと思います」とJ氏。このアドバイスの通り、I氏がAさんと組ませる先輩を替えたところ、Aさんの進捗遅れは大幅に改善したという。
マル秘の課題管理表では、こうした人の問題について日常的に議論が行われる。プロジェクトマネジャーである月岡氏も積極的に参加し、チームが抱えている人の問題を解決し、進捗遅れを防いでいるという。
予算に余裕があれば、プロジェクトの進捗遅れを取り戻すため、追加メンバーを投入できる。しかし製造工程やテスト工程といった終盤に追加されたメンバーが活躍し、遅れを取り戻せるとは限らない。
「追加メンバーは、3人で1人分の戦力にしかならなかった」。こう話すのは、日本ヒューレット・パッカードの前島大輔氏（通信・メディアソリューションズ開発統括本部 CMS開発第一本部 第二部 プロジェクトマネージャ）である。
多忙を極め追加メンバーを放置
前島氏は、通信会社のメールシステム開発プロジェクトのマネジャーを務める。メールシステムのセキュリティ機能を継続的に強化していくプロジェクトで、約半年に1回のペースで新機能をカットオーバーさせる。通信会社は自社の顧客に対して、新しいメールサービスの開始を事前にアナウンスしているので、開発が遅れると通信会社はお詫びを告知することになる。そのため開発チームとして、「進捗遅れは絶対に許されない」（前島氏）。
そこでプロジェクトの進捗が遅れたときは、確保しておいた予算を使い、追加メンバーを投入する。多くの場合、タイミングは終盤のテスト工程。追加メンバーは数人である。
このとき、追加メンバーは急遽投入されるので、プロジェクトの内容や実情がよく分からない。前島氏をはじめとして元からいるメンバーは追加メンバーを教育しなければならないが、「進捗が遅れたときのテスト工程ではずっと修羅場が続いているので、教育のためのまとまった時間を割けない」（前島氏）。
追加メンバーはろくに説明を受けないまま、テスト作業を行う。そのため、テストデータの作成を間違えるといった初歩的な作業ミスを犯しがちだった。そうなると、元からのメンバーによる確認作業が必要になる上に、追加メンバーのモチベーションも上がらない。「追加メンバーにとっても、元からのメンバーにとっても、ストレスのたまる状況だった」と前島氏は振り返る。
この状況を改善するため、前島氏らのチームでは「システム入門書」と呼ぶマニュアルを作成した。システムの目的、機能仕様、用語集など、プロジェクトに参加する上でメンバーにとって必要な知識を一通りまとめたものだ。
追加メンバーに自習してもらう
システム入門書を作ったことで状況を大きく改善できたという。
追加メンバーが投入されると、初日は「システム入門書」を読んで自習してもらう。その際、翌日に口頭試問を行うことを告げて意欲を高める。2日目の午前中は、前島氏らが口頭試問で、追加メンバー一人ひとりの理解度をチェックする。ある程度理解が進んでいれば、午後から実作業に投入する。もちろん前日の自習でプロジェクトの内容を十分に理解できているわけではないが、「追加メンバーは必要に応じてシステム入門書を読むことで疑問を解消できるので、安心して作業を任せられる」（前島氏）。
以前に比べると、追加メンバー1人当たりの働きは倍増し、遅れを取り戻しやすくなったという。
前島氏らのチームがシステム入門書の作成に要した工数は5人日だった。2次開発、3次開発と続くプロジェクトであれば、「システム入門書」の作成は検討に値するだろう。
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
