「少し変更するだけだから…」。ユーザーや、仕様策定に携わるITエンジニアは、こういう言葉で、変更作業を担当するITエンジニアに、仕様変更の指示を出しがちだ。この言葉からは、「変更による影響は、軽いものだと思いたい」という、指示する側の気持ちが透けて見える。
しかし、変更の影響を軽く見てはいけない。システムは内部で深く関連し合っていて、1カ所の変更が多くの箇所に影響を及ぼすからだ。また、変更することで新たに作りこまれるバグが発生するといった、品質面での影響も考慮しなければならない。
そのため、たとえ影響が少ない場合であっても、その範囲が限定的であることを調査・確認したり、ドキュメント類を修正したりしなければならない。ユーザーや上級SEにとっては大したことがない変更でも、変更作業の担当者には大変な作業なのである。影響は、変更する上でかさむ作業量だけにとどまらない。
また、川が上流から下流に行くにつれて水かさが増えるのと同じように、ウォーターフォール型の開発では、開発・テストといった後工程になればなるほど、仕様変更の影響が大きくなる。
桁数変更の影響が他システムにまで波及
まずは、仕様策定段階で影響を見極めなかったケースを紹介しよう。若手のITエンジニアBさんが仕様策定に携わった、ある販売管理システムの開発プロジェクトでの話だ。ユーザーとの打ち合わせで、「システムの商品コード桁数が不足気味になりそうなので、商品コードの桁数を従来の仕様の20桁から、30桁に増やしてほしい」と、変更依頼を受けた。「不足気味ならば仕方がない。桁数変更くらいなら、データベースを変えるだけでなんとかなる」。Bさんはそう考えて変更を引き受けた。
しかし実際にやってみると、とんでもなく大変だった。データベースの桁数変更だけでは済まず、商品コードが表示されるすべての画面や帳票を変更しなければならないことが分かったのだ。画面の多くは30桁を表示しようとすると横幅が足りなくなり、あちこちの画面でレイアウトの見直しを余儀なくされた。
変更作業を担当するITエンジニアやプログラマから出てくる不満をとりなしつつ、なんとか画面や帳票の桁数変更の作業を完了させたBさん。「ここまでやれば褒めてもらえるだろう」と、完成した画面や帳票をユーザーに見せた。しかしBさんの予想に反し、「えっ、こんな画面じゃ使いにくくて仕方がない。これじゃ20桁に戻した方がましだよ」と、ユーザーが不満を漏らした。
さらにこのとき、商品コードは連携している他システムでも使われており、販売管理システムで30桁にすると、他システムもそれに合わせて変更する必要があることが判明した。工数がかさんでしまうことから、Bさんの桁数変更の努力は水の泡。結局、元に戻す羽目になってしまった。
Bさんのケースでの問題は、変更による影響度の調査不足に起因している。変更による作業量の増加や、変更により影響を受ける画面の規模などを調べて、ユーザーにアナウンスしていなかった。変更により他システムに対して影響が及ぶといった危険性を認識できていなかったのも大きい。
総合テストでの変更で新たなバグが多発
テスト工程に入ってからの仕様変更が大きく影響したケースとして、Dさんが仕様策定に携わったプロジェクトを取り上げる。いろいろな困難を経て結合テストまで完了し、ユーザー企業の運用環境に移って総合テストを開始したときの話である。
ユーザーが総合テストを行ったところ、実業務のデータと合わないなどの問題が見つかり、仕様変更を余儀なくされた。Dさんが変更依頼の内容を見たところ、「これくらいの変更なら何とか予定通りカットオーバーできる」と判断。開発要員を追加投入して、人海戦術で対応することにした。
ところが変更作業を進めていったところ、別のところに影響して新たなバグが多発。そのため、既に結合テストで確認済みだったモジュールを再テストしなければならなかった。設計書やマニュアルなどのドキュメントの修正も余儀なくされ、結局2か月納期を延ばさざるを得なくなった。
プロジェクト終盤の変更は、影響範囲が思った以上に大きくなる。そう理解していても、実際にそれを回避する行動を取るITエンジニアは多くない。単体テストや結合テストの段階では、「ユーザーに見せると変更が出て納期が遅れてしまう」「データのコンバージョンが大変なので、結合テストでは実稼働中の本番データを使わず、総合テストに持ち越そう」といった心理が働きがちだ。そういう後回しにする心理が、仕様変更の発生タイミングを後にずらし、影響範囲を大きくしてしまうのだ。
アジャイル開発が評価されている理由の1つは、変更のタイミングをできるだけ前に持ってくる仕組みにある。ウォーターフォール型の開発でも、変更のタイミングをできるだけ前に持っていく工夫は凝らせる。ぜひ実践してほしい。
システムインテグレータ 代表取締役社長
