ITプロジェクト炎上の種は「認識のズレ」にある──3層9要素のフレームワークで見極める炎上の兆候

「基幹システム刷新プロジェクト」を例に考える、認識のズレ対処法

　すぅ氏の講演後には、学んだフレームワークを情シスの業務で応用するための実践ワークを実施。参加者には以下のシナリオを提示し、「あなただったらどうするか」を考えてもらった。

　あなたは、社内のコア業務を支える「新・基幹システム移行プロジェクト」を社内で取りまとめるプロジェクトリーダーです。現行のレガシーシステムを刷新し、業務効率化と法改正への対応を目指して、ベンダーと共に開発を進めてきました。

　しかし、リリースを3ヵ月後に控えたユーザーテストの段階で、業務部門のリーダーたちから「画面の切り替えが遅すぎて、入力に時間がかかる！元のシステムに戻して！」「前のシステムでできていた機能がいくつか削られてるんだけど！業務が回らないから追加で実装して！」とクレームが噴出します。

　ベンダーに確認すると、「要件定義の仕様通りに作っています。今からの追加やパフォーマンス改修は、予算の追加とリリースの延期（＝法改正に間に合わない）が必須です」と突っぱねられてしまいました。上司からは「法改正があるから延期はできない。業務部門をうまく説得して」と言われ、板挟みになっています。

　このシナリオでは、下図に示されたような認識のズレが生じている。まずは「ゴールのズレ」「プロセスのズレ」「期待値のズレ」の3つのうち、どのズレから対応すべきかをグループに分かれて議論してもらった。

　結果、すべてのグループが最初に対処すべきズレとして「ゴールのズレ」を選択。目標や目的が一致していない状態では、どのような対症療法を施しても根本的な解決に至らず、成果物のズレがさらに拡大してしまうという理由からだった。参加者からは、法改正に必須な最低限の機能だけをリリースし、業務部門の追加要望は第2フェーズとして後日対応していくアプローチなどが提示された。

　各グループの発表後に明かされたすぅ氏の回答も、参加者と同じくゴールのズレであった。同氏は「このプロジェクトは実質的に炎上しているが、ゴールを明確に定義し直さなければ、これからのあらゆる判断軸が定まらなくなる」と評した。

　ワークショップの後には、参加者への質問にすぅ氏が応える時間も設けられた。「自分より年上や役職の高い担当者に対して、どのように仕事を依頼しスケジュールを詰めればよいか」という若手ならではの質問を受けたすぅ氏は、自身の経験談を踏まえて次のようにアドバイスし、エールを送った。

　「私が若手時代にベテランと渡り合えた理由は、『自分がこのプロジェクトで最も現場を理解している』という自信、つまり現場業務に対する高い解像度をもっていたからだと思っています。若手リーダーが周囲を巻き込むための武器は、高度な管理能力ではなく、自ら汗をかいて得た知見だったりするので、そういった経験値を増やしていくと良いかもしれません」