全3155文字
PR

 深まるユーザーとの対立、現場を飛び交う怒号──。あなたが関わるプロジェクトも、いつトラブルに見舞われて炎上してしまうか分かりません。トラブル発生のメカニズムはどういうものか、そして炎上したプロジェクトをうまく鎮火するにはどうすればよいのか、解決策を解き明かしていきます。

 プロジェクトで最も大きなリスクの1つが、顧客・発注者との関係によるトラブルです。以下では、プロジェクトのキーパーソンが退職して大きなトラブルになりそうな事例を見ていきましょう。


 泊次長は、にらみつけるようにプロジェクトマネジャー(PM)の大原晋を見た。

「今後の新商品対応を考えると、今の設計はいただけません。ちょっとしたサービス変更なら、ユーザーがパラメーターで商品設定ができるくらいでないと」

 大原は、ごくりと唾を飲み込んだ。パラメーターレベルで簡易な商品対応ができるようにという要件は、理解できないわけではない。しかしその要件を実現しようとすれば、抜本的な設計の見直しになってしまう。

 大原は、ためらいながらも反論した。

「しかし…。要件定義セッションでは、主力15商品に対応すればよいということでしたが」

 泊次長は、動じた様子もなく答えた。

「当面はね。徐々に対応商品を増やしていきたいんですよ。リリース時は主力15商品で構わないが、拡張性は最初から組み込んでほしいと言ってるんです」

 話が違うと、大原は叫びたい気分だった。パッケージの機能を生かしたスモールスタートが、そもそもの基本方針だったはずだ。商品管理の根幹部分を見直すとしたら、要件定義も全てやり直しになりかねない。

 大原は首を横に振った。

「そんな話は、これまで聞いていません。遠山次長は…」

 泊次長は、大原の発言を遮った。

「ご承知のように、遠山は先月末で退職しました。仮に彼が言っていなかったにせよ、これは金融機関として当然のニーズです。やっていただかなくては」

 そうなのだ。理解力があって割り切りの早い遠山次長は、顧客側の責任者として理想的な相手だった。その人が、実家の事情とかで突然退職してしまうなんて。

 残念ながら、今の責任者は泊次長だ。そして彼は、過去の合意事項を、ことごとく覆してくる。

キーパーソンの退職で追加要求への対応を迫られる
キーパーソンの退職で追加要求への対応を迫られる
[画像のクリックで拡大表示]

 泊次長は、大原の発言を待たずに続けた。

「過去の議事録は全て読み返しました。拡張性への配慮が不要とは、どこにも書いてありませんでしたよ」

 油断だった。前任の遠山次長が好人物だったために、油断していた。集中して矢継ぎ早に要件定義セッションを進めてきたため、議事録の作成も新人に任せていて、ろくにチェックをしていなかったのだ。

 大原には、返す言葉が見つからなかった。


トラブルの要因

 いかがでしょうか。日常的にはあまり配慮されていませんが、異動、事故、けが、退職など、人が変わる要素は数多くあるものです。しかも外部要因に起因するため、コントロールが難しいことがほとんどです。そして、開発プロジェクトは人に依拠する部分が多いので、交替の影響は非常に大きいといえます。

 知識と経験を持ち、判断を下すのは人ですから、「誰でもよい」というわけにはいきません。人の交替や離脱は、大きなトラブルの要因になります。要件定義など、何もないところから合意を積み重ねていく上流工程では、特に属人性が高くなります。