2017.03.22

仕様変更にも良し悪しがある

 仕様書は遅かれ早かれ必要になるもので、どうせ書かなければいけないのであれば「実行可能(executable)な仕様書」を書こう――常々そのように主張しているわけだが、私もかつては「実行可能でない仕様書」、つまり「誰かにプログラミングしてもらうための指示書」を書いていた。その頃に仕様変更が嫌われていたという話である。

 今思えば私は、どんどん仕様変更するアテにならないSEだった。フォーム項目の位置が気に入らなければ1バイト(今なら1ピクセル)の違和感があれば変更するような奴だった。何のためか。顧客満足のためと言えば聞こえはいいが、自分が生み出して社会に送り出すモノについては論理的にも視覚的にも美しくなければ許せないという強いこだわりがあったからだ。結果的に、まわりの人を困らせたし、自分の首を絞めるようなことにもなった。

 じっさいのところ、仕様書が「プログラミング指示書」であるなら、仕様変更は何にせよ悪なのである。理由は単純で、プログラマの開発工数に基本的に仕様変更のための工数が含まれていないからだ。プロジェクトとしてそのための余力は確保されていたが、ふつうは個々のタスクに付与される工数に仕様変更分は含まれない。当然、仕様変更は嫌がられるし、こまごまと仕様変更する私のような設計者はヘボとみなされる。

 その後に実装技術が発展して、プロジェクトの様相はまったく変わってしまった。「実行可能な仕様書」の書き手が設計と実装を兼任することになるので、設計・開発工数が3分の1以下になった。要員を半分にしても余力があるので、従来よりもシステムテストやデータ移行に注力できるようになった。

 仕様変更に対するスタンスも大きく変わった。かつては恐る恐る仕様変更を依頼していたし、設計担当者が残業して自分で修正することも多かった。それが今では、「本番稼働までにこのことに気づいてよかった。これでシステムはより良いものになる」という安堵感を感じながら、気兼ねなくどんどん仕様変更できるようになった。これは本当にうれしい。

 頻度が増えると、仕様変更にも良いものと悪いものがあって、それぞれの価値が異なっていることに気づく。すなわち、DB構成の基本部分(特に主キー)が変わるような変更は、どんな実装技術を前提としても多くの混乱や無駄をもたらすので「悪い仕様変更」である。そういう変更はやはり少ないほどよい。

 「良い仕様変更」とはどういうものか。「実装して動かしてみなければ気づけなかった改善課題」は、「良い」とはいえないかもしれないが、少なくとも「必要」なものとして受け入れられるべきだ。どんなに丁寧に設計しても、その種の課題は挙がってくるものなので、それらに価値を認めて受け入れるための態勢が求められる。ようするに仕様変更というものは、「修正コストの多寡」と「必要性」の2軸で評価されるべきなのである。

 私が提唱している「データモデリング&プロトタイピング」の開発スタイルは、まさに「影響甚大な仕様変更を抑え、必要性の高い仕様変更を取り入れる」ための効果的な工夫だ。これを実践するために必要な要素は、「しっかりしたDB設計スキルを持つ要員」と「先進的な実装体制(*1)」である。前者の確保は簡単ではないが、後者については有償無償の環境がいろいろあるし、自作することも今では難しくない。

 ところが実際のプロジェクトはしばしばその逆で、粗雑なDB設計にもとづく「プログラミング指示書」をExcelで書いて、人海戦術でプログラミングしていたりする。アジャイルだからと仕様書を書かずに進めるケースもある。そんな調子では「大量のコードと大量の仕様変更」に押しつぶされそうなブラックな日々が始まるだけだ。


*1.「先進的な実装体制」であるかどうかは、JavaやRubyといった汎用言語でのプログラミング量が少ないかどうかで決まる。システムの保守コストはコードまわりに偏在するのだから、何よりも可変コードの絶対量を減らすためにこそ実装技術を活用したい。

| | コメント (0) | トラックバック (0)

«「命名標準」に振り回されないために