【プロマネ】プロジェクトって何？　ITコンサルがプロマネになった時の話

コンサルタントになってしばらくした頃の話です。いつも週何回かは終電すら間に合わずタクシーで帰宅していました。

ある日、タクシーの車中で運転手さんと「お客さんお仕事ですか？何の仕事ですか？へぇ、コンサルタント・・、大変ですね。。コンサルの方もよく乗せますけどー、この時間は官僚も多いですね。役人さんも国家公務員の方は大変そうですよ」とかそんな話をし、車中で少し眠りたかったのですが、眠れずに自宅について、風呂に入り、湯船に浸かったら寝落ちして、プログラムのバグを解消した夢をみて、「やった・・」と思って目覚めたら、あら・・風呂の中・・、のような一日がありました。

余計に疲れた体で風呂から上がり、いちど布団に入ると起きられないことが目に見えていたため、そのまま着替えてまた出社しました。当時、結婚したばかりの奥さんが眠った後に帰宅し、起きる前に出社する毎日です。「人生って何なんだろう」と思いながら、CDウォークマンで英会話のCDを聞きながら、ブツブツ電車の中でシャドーイングしながら出社していました。

コンサルタントの朝は少しゆっくりめです。そんな中でも、私は毎日、ほぼ朝一番で出社し、その日も2000年代はどこの会社でもビルの一室にあった喫煙室に向かうと、空気清浄機の奥のベンチに体を横たえたスーツの男性がいます。当時のプロジェクトのプロジェクトマネージャでした。客先で徹夜したんでしょう。ドアが開閉する音で目覚めたのか、ムックと体を起こし、こちらを向きます。

「おお、天野。メール来てると思うけど、社内研修に行ってくれ。え、海外研修がまだ？それは・・・、うーん、ともかくだな、その研修、、プロジェクト管理か？確かそうだな。必須の研修だから。仕事？うーん、、研修終わってから戻るしかないんじゃないか！」

紫煙ごしに交わした、目の下にクマをつくった男性同士の会話でした。

プロジェクトマネジメント研修にて

講師をしてくださっている先輩コンサルタントが「はい、じゃあプロジェクトの定義が分かる方？」と最初に受講者に問いかけました。「期限があることです」「目的があることです」「ユニークなことです」何人かが手を挙げて答えていました。流石、世界に冠たるコンサルティングファームだと、日々の泥沼に足を絡めとられて、まともにプロジェクトの定義だなんて哲学的な思考を巡らせたことのなかった若輩者の私は思いました。

講師の方と目が合いました。彼女は、紙の三角席札にサインペンで書かれた名前を一瞥したあと、「はい、天野さん。あなたは、プロジェクトってどういう特徴があると思う？」と聞いてきました。

予測不可能なバグが発生します
よって、計画を立てても計画通りに進みません
納期は変わらないので、みんなで死ぬほど仕事します
人が追加投入されても、キャッチアップまで時間がかかります　　　　　　　　むしろ、一時的に余計時間をとられます
なので相変わらず死ぬほど働きます
3人に1人ぐらいはメンタルに不調をきたします
私は奥さんとまともに新婚生活を送れていません

というぐらいのところで、ドッと笑いがおきました。

マネジメントスタイルとも呼べないもの

プロジェクトは大なり小なり炎上するものというのが、当時の私の考え方でした。「スケジュール？ああ、うん、最後は気合いでしょ」とよく言っていました。今考えると、最初から最後まで気合しかなかったかもしれません。仕事は丸投げされるもので、それを何とかして、それでも生き残れた奴が出世する世界だと思っていました。PMBOK日本語版は、当時は読んでも（私には）理解不可能な代物でした。

チームリーダーとして数名の管理をするぐらいまでは、それで何とかなりました。要件定義書や設計書を”てにおは”レベルまでレビューして、バグが出たら自分でデバッグし、必要であれば自分で修正して、ということが出来たからです。

そうして現場リーダーとしてそれなりの評価をしていただいた後、20名程度のプロジェクトをはじめてリードした時に、その精神論が破綻しました。「全員分は見れない・・」からです。もともとの担当領域ではなかったところは、そもそも自分が事細かにレビューするスキルすらありません。デリバリーであたふたしていると、定例の進捗報告会でお客さんから言われます「進捗はどうなっているんですか？先週と進捗%変わってませんけど？」。

（そうなんです、チームリーダーに聞いても、よくわからないんです・・）

それぞれのタスク区分ごとに、青・黄・赤と信号を模したステータスが並んでいますが、大半が黄色です。そうして唾をゴクリと飲み込んで言うわけです「はい、でも最後は何とかします！」。

プロジェクトマネージメントの重要性に気付く

「もう自分のところは終わったんで！」終電近くに、あるメンバーが席を立つと同時に発した声が聞こえます。チームリーダーは諦めたような顔でコクっとうなずきました。彼はメンバーが帰宅していったのを見計らって、私のところに「タバコ吸いに行きませんか？」と言ってきました。

「天野さん、もう納期、無理ですよ」
「そうか・・。席に戻ったら、いくつか成果物を見せてくれ」

そして実物をみて状況を悟りました。遅れをリカバリーするために、彼らは基本設計書を書いた後、詳細設計書の記述をかなり省いて開発に入っていました。単体テストはパターンが網羅されておらず、その結果、結合テストで単体テストレベルのバグが頻発し、それを修正すると、こんどはまた別の不具合が発生するという具合です。結合レベルの不具合がでると、詳細設計が省かれているので、また直接コードレベルで全てを見なければ影響がわかりません。

自分が元々担当していた領域じゃないからわからないといって、こんなことになっている事も把握できていなかったのかと愕然としました。チームリーダーは申し訳なさそうにしていましたが、「これは全部、俺のせいだ・・」と思いました。進捗率しか見ておらず、数字でトラックすることしかしていなかったからです。その日は、帰宅するタクシーの中で客やプロジェクトメンバーに申し訳ないという感情がこみ上げ、おもわず嗚咽しました。バックミラー越しに見る、その日のタクシー運転手の方は怪訝そうな顔をしましたが、何も言わずに自宅まで送り届けてくれました。

そして家に帰りプロジェクトマネジメント研修の資料を広げて見ました。「進捗は報告者の主観を排除し、客観的に測る。そのため、定量的に・・」研修で「あたりまえだろ」と聞き流した言葉が妙に説得力をもって染みわたっていきます。「納期に遅れるかもしれない」「品質がついてきていない」見えない漠然とした恐怖感に対して、いまやらなければいけないことが資料を読み進めるごとに一つ一つクリアになっていくように感じました。

リカバリ計画を作る

それから主に土日を使って、チームリーダーたちと基本設計書まで遡って、ドキュメントごとに作成完了しているもの、レビューまで完了したものと、途中で次の工程に移ってしまったものを仕分けして、それぞれを数でだしました。さらに、バグの発生件数や重篤度の分析から、各要件・機能の単位でプライオリティをつけていきました。そして最後に、リワークが必要なもののなかから、作業の抜け漏れやレビュー不足などコンサル起因によるものか、お客様からの仕様変更要求などが引き金になっている外部起因のものを分けていきました。

こうした分析を進めるまでは、例えるなら目を瞑って全力疾走をし続けてきた状態です。それがようやく、定量的にゴールまでの距離を測り、遅れているところについての根本原因を探り、それぞれに対しての必要なリカバリを洗い出していくということを行いました。そうした分析が完了して、改めてだした現実的に必要な追加工数と工期を計算してまとめているところで、手が震えだしました。「赤字になったらどうしよう。お客さんがビジネス上で設定しているデッドラインに間に合わなかったらどうしよう。」

楽観、現実的、悲観の3つのシナリオで出した工数と工期は、あまり喜ばしい数字ではありませんでしたが、それをみながら自分もチームリーダーたちも少し顔色がよくなりました。数字としては、「当初納期は遅れるが、デッドラインは何とか守れそう」で、「コンサル起因を全部被ったときに最悪赤字だが現実的なところだとトントンぐらいで収まるか」というものでした。それでも初めて、現状が見えて、すこしホッとしました。

資料としてまとめられる状態になったところで、パートナー（部長・執行役員クラス）に電話で報告をし、「長い目でこのクライアントとのビジネスを見ているから、プロジェクトの収益は気にしすぎなくてもいい。とにかくデリバリをちゃんとしてくれ」と言ってもらいました。そして現実シナリオをベースに報告資料をまとめ、一緒にクライアントへの報告に行ってもらいました。

クライアントの瞑目

その時話したお客様は、今までのプロジェクトでの立ち振る舞いをみて自分に目を掛けてくれていたお客様でしたが、お客様起因での遅れを報告した際には「それをコントロールできなかった」責任の所在がコンサル側にもあるのではないかというポイントで議論になり、さらに、こちら起因の遅れについてはシンプルに怒られました。長い打合せが終盤に差し掛かり、そのお客さんはしばらく目を瞑り、フーッと息を吐いて「わかった。天野さんが持ってきた計画でいいよ。天野さんのことは信頼しているから、最後までやり切って」と仰っていただきました。お金の話もしていましたが眼の奥で「これで話は終わり、ここまでは譲るから、これ以上は言ってっくるな」と語っているように感じました。

教訓

幸いにも、そのプロジェクトは楽観寄りのところで着地をすることができました。これは、私が20代半ばから後半ぐらいだったころの出来事です。今でも当時の見えない不安に押しつぶされそうな恐怖感を忘れることはできません。そして、私は当時使っていたノートの一番最後のページにこれらのことを書きました。

徹底的に定量化して見える化する
数字の報告を鵜呑みにせずに現物を見る
プロジェクトが混乱しだしたら、現状と根本原因の分析を優先する

それでノートのページを閉じようとして、思い直して二つ書き足しました

人は見たい現実しか見ないものだから、不都合な現実こそ積極的にみるようにしよう
上司やクライアントには隠し事はせず、不都合な現実に対しても、その原因と自分なりの意思を加えて、勇気をもって報告しよう

プロジェクトマネジメントおたくの誕生

件のプロジェクトを完遂して、プロジェクトマネージャとしては、プロジェクトデリバリを成功させることに自信をもつようになりました。また、後には混乱したプロジェクトを途中に入って収束させること（業界用語では「火消し」）も得意になりました。さらに、プロジェクトマネージャを育てることにもやりがいを見出すようにもなりました。

これは、一人のプロジェクトマネジメントおたくが生まれた背景を書いた記事です。おたくは思います。

計画通りにいかず、不確実性があるからこそ、プロジェクトマネジメントは重要で、かつ面白い。

プロジェクトとは人類が進歩、発展するために有史以来続けてきた営みでした。今後も無数のプロジェクトが始まって、終わり、たくさんのアウトプットが生まれることと思います。プロジェクトは有期で始まりがあり、終わりがあるものですが、人類のプロジェクトの歴史は、人類が存在するいじょう終わりがありません。

40代のおたくは今日も思います。

「プロジェクトって楽しいな」