プロジェクトの最大のリスクは、顧客や発注者とのトラブルにある。立場が異なるステークホルダーを適切にコントロールするのが難しいからだ。解決への動きを先送りせず、“先手必勝”で毅然と対応しよう。
深まるユーザーとの対立、現場を飛び交う怒号─。あなたが関わるプロジェクトも、いつトラブルに見舞われて炎上してしまうか分かりません。本連載では、トラブル発生のメカニズムはどういうものか、そして炎上したプロジェクトをうまく鎮火するにはどうすればよいのか、解決策を解き明かしていきます。
第1回で取り上げるのは、顧客・発注者との関係によるトラブルです。多くの場合、プロジェクトの最大のリスクは顧客・発注者にあります。開発チームとは立場が違うステークホルダーたちを、適切にコントロールすることは難しいからです。
なお、分かりやすいように、ユーザーである発注者と開発者であるベンダーという構図にしていますが、ユーザー部門と情報システム部門など、社内プロジェクトの場合も考え方は同じです。
キーパーソンが退職してしまった！
泊次長は、にらみつけるようにプロジェクトマネジャー（PM）の大原晋を見た。
「今後の新商品対応を考えると、今の設計はいただけません。ちょっとしたサービス変更なら、ユーザーがパラメーターで商品設定ができるくらいでないと」
大原は、ごくりと唾を飲み込んだ。パラメーターレベルで簡易な商品対応ができるようにという要件は、理解できないわけではない。しかしその要件を実現しようとすれば、抜本的な設計の見直しになってしまう。
大原は、ためらいながらも反論した。
「しかし…。要件定義セッションでは、主力15商品に対応すればよいということでしたが」
泊次長は、動じた様子もなく答えた。
「当面はね。徐々に対応商品を増やしていきたいんですよ。リリース時は主力15商品で構わないが、拡張性は最初から組み込んでほしいと言ってるんです」
話が違うと、大原は叫びたい気分だった。パッケージの機能を生かしたスモールスタートが、そもそもの基本方針だったはずだ。商品管理の根幹部分を見直すとしたら、要件定義も全てやり直しになりかねない。
大原は首を横に振った。
「そんな話は、これまで聞いていません。遠山次長は…」
泊次長は、大原の発言を遮った。
「ご承知のように、遠山は先月末で退職しました。仮に彼が言っていなかったにせよ、これは金融機関として当然のニーズです。やっていただかなくては」
そうなのだ。理解力があって割り切りの早い遠山次長は、顧客側の責任者として理想的な相手だった。その人が、実家の事情とかで突然退職してしまうなんて。
残念ながら、今の責任者は泊次長だ。そして彼は、過去の合意事項を、ことごとく覆してくる（図1）。
泊次長は、大原の発言を待たずに続けた。
「過去の議事録は全て読み返しました。拡張性への配慮が不要とは、どこにも書いてありませんでしたよ」
油断だった。前任の遠山次長が好人物だったために、油断していた。集中して矢継ぎ早に要件定義セッションを進めてきたため、議事録の作成も新人に任せていて、ろくにチェックをしていなかったのだ。
大原には、返す言葉が見つからなかった。
