1月21日土曜日に「ALWAYS 三丁目の夕日'64」が封切られ、嫁さんと観に行った。冷たい雨の降るあいにくの天気だったが、たくさんの観客が来ていた。私たちと同様、50代以上と思われる人が多かったが、隣のカップルは20代ぐらいの若い人でポップコーンをばりばりと食べ、よく笑っていた。自分たちが生まれるはるか前の物語なのに、けっこう共感できるようだった。

　さて、本論に入ろう。先月紹介した「ツルハ・モデル」のプロジェクトに続いて、音声系ネットワーク構築プロジェクトが始まった。今回の特徴は、メンバー全員が筆者とプロジェクトを一緒にするのが初めてだという点だ。まずお客様主催のキックオフミーティングに向けて、線表をはじめとする資料を作ることからプロジェクトを始めた。

　線表は左端に作業工程や作業の主体を並べ、横軸にスケジュールをとって各工程の開始から完了まで横に線を引いたものだ。プロジェクトの進捗管理が主な目的だが、それだけではない。リスク管理、トラブル予防の大事なツールであり、お客様や関連するベンダーへの依頼表でもある。線表はNTT起源の呼び方で、ガントチャートやスケジュールチャートとも呼ばれる。

　キックオフ前に線表をレビューしたが、即ダメ出しをした。線表はプロマネの基本ツールだが案外きちんと書けないものだ。今回は、線表を引くポイントと使うポイントについて述べたい。

「自社だけ」の線表は不合格

　線表を引くポイントは、（1）A3の1枚にまとめる、（2）自社だけでなくお客様や関連ベンダーの線も引く、（3）日付を明確にする、（4）アラームポイントを置く、（5）点検ポイントを置く、の5点だ。

　A3にまとめるのは、全体を見渡すためだ。詳細なスケジュールはWBS（Work Breakdown Structure）に書くが、細かすぎるため全体を把握するのには向かない。

　プロジェクトは通常、自社が受託した範囲だけでは完結しない。お客様や関連ベンダーにやってもらうことも多い。このため、プロジェクト全体を管理するには自分の線だけ引いてもダメなのだ。先のレビューで「ダメ出し」したのは自分のことしか書いてなかったからである。お客様や他社の線を引くことで、「相手に依頼する作業」を明確化できるし、自社と他社で作業の同期を取れる。今回のプロジェクトでは、他社が担当する装置とこちらの装置の相互接続があるため、接続に必要な情報を確定する期限の設定や連携して行う試験の同期が重要になる。

　「サービス判定会議」などのイベントは、たとえ半年先でも具体的な日付を明記しなければならない。あいまいに線を引いたり、「2月下旬」などと書いてはだめだ。日付を明確にすることで、それを守ろうという意識が強くなる。

トラブルを未然に防ぐ

　アラームポイントと点検ポイントはリスクを解消し、トラブルを予防するためのものだ。アラームポイントは、スケジュールに重大な影響があるイベントが確実に実行されるよう注意喚起するタイミングである。例えば「データセンター回線開通日確定4月27日」などと目印とともに書いておく。この時点で予定日に開通できることが確定していないと“黄信号”で通信事業者などに強い働きかけが必要、という意味だ。開通予定日からリードタイムを差し引いた日付がアラームポイントになる。

　点検ポイントでは、進捗、仕様、品質、予算をチェックする。ネットワークでは、基本設計レビューとサービス判定会議が重要な点検ポイントとなる。どちらも社内で実施した後、お客様とレビュー、会議を行う。基本設計レビューでは仕様を確定し、提案時の予算内で設計・構築できること、技術的な問題がないことを確認する。サービス判定会議では、試験結果に基づいて仕様通りに動作すること、品質に問題がないことを確認し、お客様にサービス開始（移行開始）の了解を得る。