設計書のミスなど開発者に負い目があると、変更管理のルールを逸脱して対応しがちだ。しかし、状況が把握されないままに変更すれば、さらなるトラブルに発展しかねない。品質管理よりも管理ルールが乱れやすい変更管理の手順確立が重要だ。

Before
メニューだけの修正のはずなのに…

「変更管理のベースラインはきちんと決めたわよね?」

 プロジェクトマネジャー(PM)の田村玲奈は、SEの里吉に厳しい顔を向けた。

 里吉は、疲れた表情で答えた。

「もちろんです。でも、この件に関しては、不具合と認めざるを得ないんです。設計書の記述が明らかに間違っているんですから。引き渡すパラメーターが違っているんで、シングルサインオンが効かないんですよ。これじゃあユーザーテストが進められないって、お客さん、キレかけてるんですから」

「だけど、まだ変更依頼票は起票されてないんでしょ?」

「変更じゃないんですって。バグですよ。これは」

 玲奈は、ぐっと怒りを飲み込んだ。身内である自社のメンバーが、いまだに変更管理の基本動作を身につけていないのだ。

「じゃあ、何を引き金に外部設計書と内部設計書を修正するの?」

 里吉は、顔をしかめた。

「問い合わせ票じゃダメですか?」

「ダメ。うちの回答だけじゃ、顧客責任者の承認が記録に残らないもの。基本設計書は納品・検収済みでしょ。もはやお客様の資産なのよ。プラチナ物産でお客様から頂いたクレーム、覚えてる?」

 里吉は、思い出した顔になった。プラチナ物産で、顧客のサーバーに格納された外部設計書の誤字を、協力会社のSEが深い考えもなく修正してしまったのだ。「移行データ」とすべきところが、「威光データ」になっているという明らかな誤字の修正だった。

 それが大問題になった。顧客の監査部門が、プロダクトのタイムスタンプを検査していて、公式なリリース日以外に発生した差し替えを見つけたのだ。顧客が管理しているファイルを、顧客の了承もなく変更したのだから、申し開きの余地はなかった。当時の開発本部長が謝罪し、再発防止策を報告することになった。

 当たり前のことだが、顧客の資産を、開発ベンダーが勝手に修正することは許されない。変更内容を、顧客の責任者が承認して初めて変更できるのだ。このあたりのルールを明確にして、ルール通りの運営をしないと、統制が取れなくなってしまう(図1)。

図1●統制の危機
[画像のクリックで拡大表示]

 里吉にしても、それぐらいのことは理解している。しかし、ユーザーテストで判明した障害と変更要求が錯綜する中で、浮足立ってしまっているのだ。何しろ、システムテスト開始まで3週間足らずしかなくて、急いで手を入れなければならないことが目白押しなのだ。

「しかし…」

 里吉は、苦しげに言った。

「手続きに手間をかけていたら修正と再検証が間に合いません。実はもう、随時変更に入っていて」

「変更依頼票も起票されていないのに?」

「だから、間に合わないんですって!」

 里吉は、顔を歪めて叫びだした。

「中谷主任も了解しているんだから、いいじゃないですか。わたしも新見さんも、急ぎのバグフィックスで手いっぱいで、起票している時間がないんですよ」

「ストップ」

 玲奈は、何とか冷静さを保ちながら、言った。

「どうして、あなたや新見さんが変更管理票を起票しなきゃならないわけ? 変更依頼なんだから、それってお客さんの中谷主任の仕事じゃないの?」

 里吉は口ごもった。

「それは…。中谷さんも時間がないっておっしゃるし、そもそもバグが多すぎるんだから、そっちで何とかしてくれなきゃ困る、と」

「変更なら、追加コストがかかることもあるのよ。プロジェクトオーナーの承認もなく作業を始めちゃって、後で否認されたらどうするの? 変更を元に戻すの?誰がそのコストに責任を負うのよ」

 里吉は、口をとがらせただけで、何も答えなかった。

「まったく」

 玲奈は、腕を組んだ。変更管理のルールは、プロジェクトで変更を可視化し、全体最適でジャッジするために定めている。アンダーグラウンドで作業を進めるわけにはいかない。そもそも、誰のせいでこうなったかという問題とは別なのだ。

「田村さぁん」

 デスクの反対側で、受話器を握った新見が叫んだ。

「中谷さんから電話です。転送します」

「お願い。654よ」

 内線番号を告げてから通話をピックアップした玲奈の眉間に、しわが刻まれた。何分か話した後で受話器を置いた玲奈は、里吉に向かってため息をついた。

「中谷さんから、昨日導入されたモジュールがおかしいって言ってきたんだけど。昨日導入って、メニューのバグフィックスだったわよね」

 里吉はうなずいた。

「そうですけど」

「メニューだけの修正のはずなのに、項目エラーのメッセージが変になってるって。心当たりある?」

「ああ、それは、メッセージIDの区分がおかしかったから、併せて修正して…」

 玲奈は、首を横に振った。

「修正、間違ってるみたいよ。それに、中谷さん、メッセージIDに手を入れるなんて聞いてないっておっしゃってるけど」

 里吉の顔から、血の気が引いた。

「その件はまだ問題管理票に記載してなかった…」

 落ち着け、と、玲奈は自分に言い聞かせた。冷静にならなければならない。ここは冷静に。

 そのとき、落ち着こうとしている玲奈にとって、一番聞きたくない声が聞こえてきた。

「おーい」

 柳川グループ長だ。入ってきたグループ長は、天真爛漫かつ場違いな笑みを浮かべたまま、言った。

「みんな殺気立っちゃって、一体どうしたの?」

 メンバーはいら立ち、顧客からきつい指摘もやってきて、不具合への対応と変更管理ルールの逸脱とで、玲奈さん、またしても危機一髪のようです(図2)。さてさて、どうしたらいいのでしょうか。そもそもこうならないように、どうしたらよかったのでしょう?

図2●品質管理と変更管理のトレードオフ
[画像のクリックで拡大表示]

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら