企業では、システム導入、業務改革、新規事業、組織再編など、さまざまなプロジェクトが立ち上がります。一方で、プロジェクトは計画通りに進むとは限りません。技術の進歩や市場環境の変化が速く、生成AIの登場によって、従来の前提そのものが変わることも珍しくなくなりました。プロジェクトが難しいのは、単にやることが多いからではありません。プロジェクトには独自性と有期性があり、開始時点ですべてを正確に予測することができないからです。そのため、プロジェクトの成否を左右するのは、個々の技術だけではなく、何を目指し、どこまでやり、何を想定し、どう変化に対応するかを管理する力だと考えています。もちろん、プロジェクトマネジメントにはPMBOKなど体系化された知識があります。本稿では、それらを網羅するのではなく、霧海風が特に重要だと考えるポイントを紹介します。
そもそも、プロジェクトとは何か
プロジェクトとは、独自の製品やサービスなどを創造するために実施される、有期性の業務です。したがって、少なくとも次の4点を明確にする必要があります。
- 何を達成するのか
- いつまでに達成するのか
- 誰が担うのか
- どのような方法で達成するのか
同じシステムを刷新するというプロジェクトでも、6カ月で終えるのか、2年かけるのかによって、必要な人員や進め方、及び難易度は大きく変わります。また、プロジェクトには独自性があります。過去と全く同じ仕事を繰り返すわけではないため、必ず不確実性が生じます。例えば、環境変化によって目標や対象範囲が変わる/利害関係者の変更によって要求が変わる/採用予定の技術やサービスが期待通りに成熟していない/業績悪化によって予算が縮小する/想定した人員やチームが期待通りのパフォーマンスを発揮しない、といったことです。つまり、プロジェクトでは想定外が起こらないようにするのではなく、想定外が起こることを前提に、その影響を小さくする仕組みを組み込むことが重要です。
ゴールを明確にする
ゴールのないプロジェクトは、目的地のない航海と同じです。重要なのは、単に目標を掲げることではなく、関係者が同じ意味で理解できるようにすることです。例えば業務を効率化するという目標では、成功したのかどうかを判断できません。受注処理にかかる平均時間を30％削減するのように、何を、どの状態まで持っていくのかを明確にする必要があります。
そこで有効なのがSMARTです。
- Specific：具体的である
- Measurable：測定できる
- Achievable：達成可能である
- Result-oriented：結果志向である
- Time-bound：期限が明確である
例えば営業活動を強化するではなく、12月末までに既存顧客への提案件数を月50件から80件に増やし、新規受注額を月1,000万円まで引き上げるとすれば、達成状況を確認できます。また、最終ゴールだけを設定するのではなく、途中にマイルストーン（要石）を置くことも重要です。マイルストーンは単なる日付ではありません。要件定義完了/テスト環境構築完了のように、プロジェクトを前に進めるために必要な中間の状態を定義します。さらに、マイルストーンはプロジェクト後半に偏らせないことが重要です。序盤から一定間隔で確認ポイントを設けることで、問題を早期に発見できます。
やらないことを決める
プロジェクトでは、何をやるかと同じくらい何をやらないかが重要です。特に発注者と受注者が存在するプロジェクトでは、対象範囲について双方が異なるイメージを持っていることがあります。発注者は当然ここまで含まれていると考えている。一方、受注者はそこまでは契約範囲に入っていないと考えている。こうした認識のずれは、プロジェクトが進んでから初めて表面化します。
「以前説明したはずです」
「そんな話は聞いていません」
「そこまでやってもらえると思っていました」
という議論が始まれば、プロジェクトは一気に不安定になります。人間は、自分が理解している前提を相手も理解していると思いがちです。だからこそ、対象範囲を明文化する必要があります。そして、対象範囲を明確にするためには、プロジェクト全体を俯瞰できていなければなりません。何をやらないかを決めることは、仕事を減らすためだけではありません。限られた時間、人員、予算を、本当に達成すべき目的に集中させるための意思決定です。
リスクを早く見つける
プロジェクトには、多くの想定外が待っています。ここで整理しておきたいのが、リスク/問題/課題の違いです。リスクとは、まだ発生していないものの、発生するとプロジェクトに悪影響を与える可能性があるものです。それが実際に発生すれば問題になります。そして、その問題に対して取り組むべきテーマが課題です。例えば主要メンバーが異動する可能性があるはリスクです。実際に異動すれば問題になります。そして、代替要員の確保や引き継ぎを行うことが課題になります。重要なのは、リスクを起きてほしくないこととして隠すのではなく、起きる可能性があるものとして早い段階で認識することです。早く分かれば、対応策を考えられます。代替要員を確保する、予備のスケジュールを設ける、技術検証を先に行うなど、事前に打てる手は多くあります。逆に、リスクを見て見ぬふりをして、問題になってから対応すると、選択肢は一気に減ります。プロジェクトのリスク管理とは、問題が起きてから火を消すことではありません。火事になる前に、燃えやすい場所を見つけておくことです。
スケジュールは最短とバッファを分ける
無謀なスケジュールでプロジェクトを最後まで完遂することはできません。スケジュールの見積方法には、過去の経験から概算するトップダウン、成果物の難易度などから係数を用いて算出する方法、作業を細分化して積み上げるボトムアップなどがあります。実際には、これらを組み合わせて見積もることになります。しかし、どれだけ精緻に積み上げても、プロジェクトには不確実性があります。未確定の情報を仮説で置いて見積もる以上、想定外による遅延を完全には避けられません。そこで重要なのが、最短で完了するための工数と、想定外に備えたバッファを分けて管理することです。例えば100日で終わるという数字だけを管理するのではなく、最短90日＋バッファ10日と考えます。さらに、進捗管理では単純な達成率だけを見るのではなく、バッファをどれだけ消費したかも見ます。バッファがなくなっているのにまだ予定通りと判断してしまえば、問題への対応が遅れます。
変更を管理する
プロジェクトでは、計画を作ったらその通りに進めればよい、というわけではありません。例えばシステム導入では、要件を確定した後でも変更要求が発生します。要件定義中の見落とし、テストで発見された不具合、実務を詳しく理解/可視化されたことで判明した新しい要件など、その理由はさまざまです。最善は、変更要求に対して全部受け入れることでも全部断ることでもありません。
基本的には次のプロセスで判断します。
①文章化 変更要求を口頭だけで済ませず、メールや変更管理表などに記録します
②要望を理解する なぜ変更が必要なのか、その背景や目的を確認します
③影響を調査する 後工程への影響、追加費用、追加人員、スケジュール、品質などを確認します
④受け入れを判断する 受け入れるのか、延期するのか、代替案を採用するのかを判断します
⑤再見積もり・周知する 必要な工数やスケジュール、役割分担を改めて整理し、関係者に共有します
変更を受け入れること自体が問題なのではありません。問題なのは、変更によって発生するコストやリスクを認識しないまま、ついでにこれもと積み重ねていくことです。変更管理は、要望を不満や誤解なく打ち返したりするプロジェクトリーダーの胆力が試される場面でもあります。
企業事例から考える
弊社が支援する中でも、ゴールとスコープが明確になっていないことから来るプロジェクトの失敗が大きな要因として挙げられます。なんとなくの目指す姿の記述、なんとなくの範囲の記述。1回きりの説明。現場に聞き取りに行くと、思ってたのと違う、こういうことやらないとそもそも意味がない、といった指摘。上層部と現場との意思疎通が出来ていないことも。そして顧客企業の希望を文書化や合意のプロセスを経たりせずに口答で軽く受け入れ過ぎてしまうが故に、当初のスケジュールや範囲がなし崩し的に変化し最終的に炎上。顧客企業が理解のある人ならば、追加予算で新たに発注してくれる場合もありますが。こういったことが良く起こります。プロジェクトに関わる人の規模や範囲が大きくなればなるほど、ゴールやスコープ、変更をきちんと言語化した上で、関係者に伝わるように粘り強く何度も説明していくことが必要です。
おわりに
プロジェクトでは、計画段階ですべてを正確に予測することはできません。そのため完璧な計画を作ればよいということではありません。何を目指すのか。どこまでやるのか。何が起こり得るのか。どの程度の余裕を持つのか。変更が起きたとき、どう判断するのか。これらをあらかじめ構造化しておくことです。プロジェクト推進とは、計画書を作って、その通りに進める仕事ではありません。不確実な状況の中で、関係者の認識を揃え、問題を早期に発見し、必要な意思決定を行いながら、ゴールに向けてプロジェクトを動かし続ける仕事です。こうした人と組織を動かすプロジェクトマネジメントの重要性は、生成AIが資料の調査、コード解析などを代替していくにつれて益々高まっていくと考えます。
