NRIには、たくさんのプロジェクトマネージャー（以下、PM）がいます。私もこれまで、お客様のITシステムを開発する複数のプロジェクトでPMを務めてきました。そういった経験の中で「プロジェクトマネジメントは大名行列に似ている」と常々考えるようになりました。いきなりそう言われてもわかりづらいと思いますので、説明していきたいと思います。

目に見える物理的な構造物を作るのと、システム開発には大きな違いがあります。それは”次元”です。物理的な構造物はわれわれが住んでいる三次元空間内に構築するため、成果物が目に見えます。触ることもできます。しかしシステムは、ユーザーの目に触れる操作画面や帳票こそ目に見えますが、その裏の仕組みはデジタル空間上にあり、時々刻々と変わる非常に複雑なデータ処理プロセスの組み合わせで、人間の目には見えません。システムは“N次元空間における構造物”なのです。

その全貌が目に見えないがために、お客様にとってはシステム開発中の進捗状況が分かりづらく、われわれ作り手側も目に見えない構造物であるシステムを構築するためにさまざまな困難があります。 ひとつは強烈な”イナーシャ（慣性）”の誘惑です。「あのチームの進捗がよくわからないが、きっと順調に違いない」「開発中のプログラムがお客様の要求に合っていない気もするが杞憂（きゆう）だろう、きっと満足頂けるに違いない」といった願望です。ベテランのPMであってもこの誘惑には往々にして襲われますし、そもそも自分が根拠なくそう信じてることに気づくことすら難しいこともあります。プロジェクトの渦中にいる当事者からは客観的に自分たちの状況を捉えるのが難しいうえ、「うまくいっていると信じたい」と本能的に考えてしまうのです。

これを避けるために、野村総合研究所では第三者にプロジェクトの外から客観的、定期的にプロジェクトの状況をチェックしてもらうことを大切にしており、プロジェクトが正しく運営されるように多段階のチェック機能がはたらいています。例えば、週に一度は部長に見てもらう、月に一度は組織の中のプロジェクトリスクマネジメントを担当する部署や全社のプロジェクトのリスク管理を統括する部署にチェックしてもらう。そうすることで、プロジェクトの渦中にいるPM、メンバーが自覚していない思い込みや考慮漏れを検知して是正することが可能となります。そのためにPMはできるだけ定量的なファクトデータを収集、報告して、第三者のフラットな目で客観的に評価してもらうことが肝心です。PMの思い込みを報告しても、第三者にはそれが事実なのかPMの願望なのかを見極めるのは難しいですし、外部からのチェックが十分に機能しません。

システム開発のもうひとつの難しさは、二つと似たプロジェクトがないということです。顧客がシステム投資する目的や期待する効果、顧客の予算、希望する工期、システムを導入する業務領域、選定する技術、システム導入前の環境、顧客の担当者やNRIの技術者の顔ぶれなど、すべての要素が完全に一緒というプロジェクトはまずありません。必ずどこかの要素が過去にやったプロジェクトと異なります。ですから「以前のプロジェクトでこういう手法でマネジメントしたら成功したので今回も同じ手法を使おう」と思ってプロジェクトを始めてみると、うまくいかないということが起きえます。

これを回避するには、過去の成功体験に固執しないというマインドセットをPMが意識的に持つことが大切です。プロジェクト開始当初は、恐る恐る自分がベストなやり方だと思ってる手法でマネジメントを始めてみて、うまくいけばそのまま続ける、そうでなければ別のやり方を選択するというくらい、柔軟に構えてみましょう。プロジェクトメンバーとよく話し合うのも効果的です。私の経験上、うまくいくことが多いのはメンバーの負担が少ない管理方法です。

例えば「進捗報告については前週金曜時点に完成しているプログラム本数を火曜正午までにこの資料に記入してください。それ以外の成果物やタイミングでは報告しなくてよいですよ」というやり方はメンバーの負担の少ない方法です。報告対象を具体的に限定して、さらに締め切りにゆとりがあるルーティンにすることで、メンバーも自分の仕事の予定が立てやすくなりますし、メンバーの裁量やあそびの部分を残しながらも、きっちりPMが行うべき管理が実現できます。

管理と書きましたが、PMが管理すべきことはたくさんあります。よく言われるのが”人・モノ・金”や”Q・C・D（品質・コスト・進捗）”。それらを管理する上で、もっとも大切なPMの仕事は”制御と判断”だと考えます。

車の運転にたとえて説明しましょう。まずは”制御”です。車がちょうど60キロで走るように速度メーターを見ながらアクセルをぐっと踏んだり、はずしたり、を繰り返す。運転手に入ってくるさまざまなインプット情報をもとに、最適な状態を保つように手間をかける。これが”制御”です。PMも同じようにプロジェクトの状態に関するさまざまな情報を収集して、プロジェクトが円滑に進捗するようにコントロールをします。PMが収集する情報は定量情報と定性情報の2種類に大きく分類できます。定量情報としては成果物数、テスト障害数、コスト実績、メンバーの勤務時間などがあります。定性情報とは顧客の発言、チームの雰囲気やメンバーの顔色、態度などです。定性情報も定量情報と同じくらい、PMの”制御”には重要なインプット情報になります。

次に”判断”です。今度も車の運転にたとえてみます。運転していると標識があり、この先で道が二手に分かれていることがわかりました。右へ行くか左へ行くか。時間も燃料も限られている中でどちらの道を選ぶのがいいのか。PMをやっていると日々判断の連続です。「AがいいかBがいいかどっちだ？」と迫られます。PMの判断によってはステークホルダーに迷惑をかけたり、収支に悪影響を及ぼしたり、場合によってはプロジェクトの命運を左右することもあるので、判断は非常に気が重い仕事です。そのためつい判断を先送りしたい誘惑にかられます。しかし私の経験上、先延ばしはよくないことが多いです。「拙速（せっそく）は巧遅（こうち）に勝る」という言葉がありますが、システム開発のプロジェクトマネジメントにおいてもあてはまると私は考えています。

ただしカンでAかBかを判断するのはよくありません。カンで判断したのでは顧客や社内のステークホルダーになぜその案を選んだのかが説明がつきませんし、プロジェクトメンバーからの賛同を得ることも難しいでしょう。PMは科学的に根拠を積み上げてそれぞれの案のメリット、デメリットを列挙して、どちらの案が優れているかを十分吟味した上で判断すべきです。「迅速に、ただし十分吟味して判断する」という一見矛盾したことを行うのが、重要な役目です。

PMは大名行列のツアーコンダクターです。大勢のお連れに一歩ずつ、毎日少しずつ歩いてもらってお江戸（またはお国）に近づいていく。何日かけて行くのか。費用はいくらかかるのか。途中どこに宿泊するのか。その計画を立てて、計画通りに大勢を動かす。長い道中、歩くのが遅い一団がいて日程表通りに進まなかったり、道を間違えてはぐれる一団がいたり、病気やケガをする人も出てきます。そういう数々のトラブルを一つずつ解決しながら、どうにかして目的地に期日までに予算内で、全員で到達する。実際の大名行列がその通りだったかはわかりませんが、そういうイメージが「PMと似てるなあ」と思いながら、私はPMとして働いています。

執筆者情報

水野 憲祐
1999年に野村総合研究所に入社。
入社以来、大手小売業の各種システム運用・構築の経験を積み、現在は小売業の大規模システム開発案件等に従事。専門はプロジェクトマネジメント。

DX時代のシステム導入最前線一覧ページへ

産業ITソリューションNewsletterのご登録（別サイトへ）

産業ITソリューションサイトへ