設計変更についての議論が前回はちょっと大雑把だったのですが、変更とはみたいな話も長くなりますので、仕様変更の流れで具体的な変更方法と、一般的な話を並行的に進めてみたいなと思っています。
開発途中での仕様変更が嫌われる最大の理由、言い換えれば、それをすべきではないという根本的な理由は、システムの品質が低下する可能性が高いからです。品質低下とは、バグが発生するとか、メンテナンス作業がやりにくい、処理速度が低下するなど、いろいろな指標があります。ある種のシステムに対する変更は、その部分に直接関係する部分を多くの場合は調整する必要が出てきます。そのため、単に何かを追加したり削除したりということで済みません。ということで、変更箇所が波及するのです。結果的に間接的にも含めたいろいろな部分の変更が必要となります。それらを変更すべきところ以外の箇所は以前の状態を留め、変更箇所が変更されているというのが理想なのですが、それが難しいのです。人間がプランして、人間が実施するので、漏れや失敗等が発生します。最近はそういうヒューマンエラーを最大限になくす方法はテスト手法を含めていろいろ開発されていますが、単にシステム改変以外に、改変による品質低下を防ぐための作業が、改変そのものよりも多くなるのが一般的です。仕様変更は、少なくともシステムに何か手を入れます。その結果、より良くなる、例えば気付いてなかったバグが見つかったなどの利点もあるのも確かですが、平均的には品質が落ちると言っていいのではないでしょうか。要するに、システムに要素が増えればバグの可能性も増えるということです。
仕様変更を嫌う別の見方は、これは業者目線ではありますが、コストが増えることです。時間が増加し、プランがずれることも、結果的にはコスト要因です。開発の早い段階でなら、仕様変更のコストはあまり増えず、「もうちょっと頑張れ」的な判断になってしまいますが、開発終盤や開発終了後となると、現実的にはコストはそんなに気楽な数字ではなくなります。いずれにしても、作業者は辛いです。理屈の上では、品質低下を防ぐということに尽きるのですが、例えば、機能が実装されて本格的な統合テスト（例えば人間が手順を見ながら確認するようなタイプのもの）をする前と後で変更のコストが変わってきます。テスト後だと、再度、本格的なテストをやり直すことが多いと思われます。
仕様変更を受け入れないと、顧客が望むシステムから遠ざかることになり、これはこれで難しい問題です。品質確保のためのコストは、システムに深く関わっているエンジニアでも判断が難しいですし、また実際の変更作業の負担がのしかかってくるという点では避けたいところでしょう。一方、エンジニアではない人たちは、どんな変更なら容易で、どんな変更なら困難なのかはよくわかりません。なるべく最初の仕様検討時に必要な情報は出してもらうようにしてもらう必要がありますが、ともかく、後からだと「無理かもしれない」ということをちらつかせて、最初の段階で仕様を出し切ってもらうしかありません。それでも仕様変更があった場合、納期をずらす、費用を上積みするなど、交渉をするしかありません。もちろん、開発に入る前にそうした交渉が可能な契約にしておく必要があります。業務範囲を開発前に記述するのはどうせ曖昧になるのだからと言って、契約自体を重視しない人もそこそこいらっしゃいますが、それは良くないです。完全でなくてもいいので、業務範囲を定義して、そこから外れた場合には交渉の余地を残す契約に力を注ぐべきです。交渉の結果、仕様変更は見送るということができるとしたら、それは建設的な関係が構築できたと考え、見送った仕様を別の機会に解決するようなことを共同で進められれば理想的です。
前回、納品書に出荷日がないという指摘がありました。そういう仕様変更があったときも、最終的な目標となるレイアウトの変更などとともに、表で考えるのが基本です。納品書に単に出荷日を追加したのが以下の左側のレイアウトです。まあ、こういうことだろうなとまずは思いたいですね。
この納品書で問題がないとすれば、どこに出荷日を記録すればいいでしょうか？ここでは、納品書と出荷日が１対１であることに目をつけます。販売明細と出荷日は、左のレイアウトで見る限りは別々のように見えます。つまり、出荷日は販売日と同じように扱われているという見方もできるでしょう。もちろん、顧客や商品と出荷日は関係がなさそうです。販売明細から見れば、納品書を通じて出荷日を求めることができるのですが、いわば間接的な関係になります。つまり、出荷日というデータは、納品書との１対１の関係が最も強いものとなるということで、納品書に「出荷日」フィールドを用意して、日付を１つ記録できるようにすれば、左の納品書を構成可能なデータを持つことができると言えるでしょう。
フィールドを１個増やすだけでですね。簡単ですね。FileMakerだと、数分で終わりそうです。最も、このシステムは納品書だけではないと思うので、他との調整も必要かもしれませんが、実はフィールドを１つ増やすだけというのは、そんなに大変なことでもありません。おおむね、定義の追加と、レイアウト上のオブジェクトを増やすだけです。ただ、プログラムがいろいろあって、そこにロジックがある場合はそれらを全部見直す必要がありますが、ここでは納品書という表にタッチしている部分をチェックすれば良いので、品質低下を発生しそうな要因は比較的少ないと言えます。
ですが、こうした仕様変更をしていると、またまたさらに別の担当者から、商品ごとに異なる日に出荷する場合もあるということが出てきました。それじゃあ、出荷日をカンマで区切って記述しましょうか？
これでいいのでしょうか？ 同一日に2回出荷したらどうするのでしょう？ そもそも、受注と出荷の関係はここまでには何の情報もありません。ここからは、業務、つまりワークフローを詳細に検討しないと、仕様の理解に大きく失敗する可能性がある箇所になります。「別の日に出荷されることもある」という事実は、少なくとも、１つの納品書は、複数の出荷になる場合があるということを示していると言えます。これは、見方を変えただけです。「どんな場合があるのか」をありとあらゆる角度で考えれば、結論が見えてきませんでしょうか？ この場合、１つの納品書に出荷は最低１、多い場合は2、3…と増えていくという現実が想定できるということです。
だとしたら、その納品書は何やねんということになりますが、おそらくは営業部門が単に、受注内容を記録しただけのものということになります。納品書というよりも、受注請書の方がより実態に近いと思われますが、こういった世間と違う意味なのにその社内では流通してしまっているユビキタス言語は、開発に携わる人はよくぶち当たって混乱させられた経験があるかと思います。つまり、納品書の実態は「受注」なのですが、名前を途中で変えるとこれまたややこしいことになるので、しばらくは「納品書」で行きます。
ここで、「出荷」という言葉が出てきました。そして、すでに記載したように、納品書と出荷は１対多の関係になります。そうですね、すでに説明した通り、出荷という新しい表が必要になるということをこの分析は示唆しています。つまり、このシステムには「出荷」という存在が必要になります。このような「納品書」や「商品」といったある意味まとまった１つの概念のことを「エンティティ」と呼ぶのが一般的です。まとまり方はエンティティによって微妙にあるいはドラスティックに違うとも言えます。ですが、おおむね、エンティティはシステム内の重要な概念であることが多いです。ER図的に記述すると、仕様変更により、左のものに、「出荷」のボックスを追加して右のような図になりそうだというあたりがまずは導かれたと考えます。
「出荷」と何が線で引かれるのか？ 新たに出てきた出荷をどのように扱うのか？ ということは、実際に表に展開しながらの話になります。次回に回しましょう。