PR

変更管理のトラブルの多くは、発注者と受注者の間で、仕様変更か不具合かでもめることだ。仕様変更か不具合かの区分けを迷走させないためには、基準となるベースラインを決めておく。変更を実施するかどうかの判断についても、メリットやデメリットの評価軸をそろえる必要がある。

Before
仕様なんて凍結よ!

 変更なのか、不具合なのか。プロジェクトマネジャー(PM)の田村玲奈は、沈鬱なため息をついた。

 もちろん、今に始まった話ではなくて、どのプロジェクトでも必ず問題になることだ。でも、このタイミングでは、正直言って考えること自体、煩わしい。

 担当している総務システム更改プロジェクトは、今ユーザー受け入れテスト(UAT)のフェーズに入っていた。何か問題が出てくるたびに、ユーザーから確認票による照会が入る。それはそれでよいのだが、ほぼ毎回のように論点になるのが、ここだ。

 変更なのか、不具合なのか(図1)。この問答に、玲奈は神経をすり減らしていた。一度決定していた要件や仕様を変更するなら、そのコストはユーザー企業の負担になるから、追加の見積もりが必要になる。一方不具合なら、ベンダー、受注者であるニッケイIT社の責任だ。無償で修補(修正)しなければならない。

図1 変更か不具合か?
図1 変更か不具合か?
[画像のクリックで拡大表示]

 だから、両当事者ともに真剣だ。1つひとつの項目について、調査とエビデンス探しが始まる。設計書の記述、これまでの検討経緯、要件定義セッションの流れ、RFP(提案依頼書)の記載…。

 ユーザーとの打ち合わせが、「言った、言わない」の言い合いになることもしばしばだった。要件定義セッションや基本設計セッションの議事録を持ち出して、ここで合意していると説明してみても、いや、そんなことは言っていない、言うはずがない、という話になったりする。

 交渉はきれいごとだけでは済まない。双方が譲れない局面では、時として怒号が飛び交うことにもなる。玲奈にとって、苦手な事態だった。

 そもそも今は、不具合修正とシステムテスト準備の追い込み時期だ。UATで予想以上の問題が出てきたので、横展開を含めて全て対応して、品質を確保するだけでも容易ではない。設計が誤っていたとしても、それがどういう経緯で、誰の責任だなどという追及に時間と工数を費やしたくないというのが玲奈の本音だった。

「もう仕様なんて凍結、凍結、凍結よっ」

 独り言をいいながら頭を抱えている玲奈の背後に、人の気配がした。

「おやおや、仕様凍結とは穏やかじゃないね。どうしたのかな?」

 あっと思ったがもう遅い。振り返ると、柳川グループ長が微笑んでいた。

 確か柳川さんは、「仕様凍結」という言葉が大嫌い。「ビジネスは常に変化してるんだ。凍結なんかできるわけないじゃない」というのが口癖だったはず。でも、一度口にした言葉は引き戻せない。総務システムの申請ワークフロー帳票が、容易には引き戻せないように。

 玲奈は、弱々しく笑みを返した。

「愚痴です。聞き流してください」

「ただの愚痴ならいいんだけどね」

 柳川グループ長は、キャスター付きの椅子を引っ張ってきて、玲奈の左の空き机に向かった。

「UATの終盤だよね。変更要求がたくさん出ているのかな?」

 玲奈は、思わず本音を漏らした。

「変更要求だとはっきりしているなら、まだいいんですけどね」

「ふんふん。変更なのか不具合なのか、バトルが始まったってわけか」

「はい」

 玲奈はうなずいた。すると、柳川グループ長は、とんでもないことを言い出した。

「変更か不具合かなんてことは、本当はどうでもいいんだけどね」

 柳川の暴言放言は今に始まったことではないが、玲奈はさすがに耳を疑った。

「え?でも、変更か不具合かって区別によって、大違いじゃないですか。不具合ならうちが持ち出しですぐに修正しなきゃならないんだし」

 だから、ユーザー代表の川上部長代理が大声を出しても、自分は頑張って踏みとどまっているのだ。それなのに…。

 玲奈の思いをよそに、柳川グループ長の笑みが大きくなった。

「ああ、またその誤解か。それはちょっと違うと思うよ。変更だってお金をもらうとは限らないし、不具合だからすぐ直すとも限らない」

「でも…」

 当惑する玲奈に追い打ちをかけるように、柳川グループ長は言い放った。

「それに、お金がもらえるかどうかだって、うちの会社の問題ではあるかも知れないけど、プロジェクトの問題じゃないよ。一度、検討の軸を切り替えてみたほうがいいんじゃないかな」

 この人は一体、どの軸を切り替えろと言うのだろう。そもそも、PMなら誰もが気にするはずの常識的なポイントを一蹴して、何が言いたいのか。玲奈には、答える言葉が見つからなかった。