ステップ数よりスペック数
ソフトウェアの規模は、ハードウェアの規模がそうであるように生産量ではなくスペックである。実現方式が違えば生産量の定義が変わる。そんなバカなことはない。プレス加工だろうが、鋳造だろうが、生産量の定義が変わるはずがない。ソフトウェアの規模を生産量扱いするというのは、加工方法が変われば生産量の定義が変わるというようなもの。これでは、異なる加工方法間での生産性の比較ができず、生産性の大幅な改善は期待できない。ソフトウェア開発の生産性が向上しないのも、生産量の定義が間違っていることによるものが大きい。
ソフトウェアにおける開発はハードウェアにおける設計 - 酔狂人の異説
に触発されてこのエントリを書きました。
はじめに
これまで、私はウォーターフォール型の開発プロセスを使った現場でプログラマをしてきました。
しかし、いくら設計書をちゃんと作っても、バグが無くなったり、
進捗管理を厳しくやっても、スケジュール通りに終わったりということは一度もありませんでした。
いつもプロジェクトが終盤になると残業ばかりでした。
いちおう利益は出ていたらしいので、会社から見てみれば失敗とは言えないかもしれませんが、
私にしてみれば、残業ばかりであまり品質の高くないソフトウェアしか作れないのでは、成功したとは言えませんでした。
もっと品質の高いソフトウェアを作るにはどうすれば良いか、もっと無駄を少なくするにはどうすれば良いか、いろいろな開発方法を調べて考えました。
そして、以下のやり方に問題があると考えました。
- ステップ数を主体とした見積もり、進捗管理、テストがまずい。
- テスト仕様書の作成時期が遅い。
- 仕様書の書き方や扱い方がまずい。
ステップ数について
ステップ数を管理指標として使ってはいけない
ステップ数を管理指標として使ってはいけないのは、不正確だからです。
極端な例ですが、1から10の合計を求める場合に、
- 単純に1から10まで加算していった場合
- ループを使って1から10まで加算していった場合
- 公式を使って求めた場合
のそれぞれで必要になるステップ数は大きく違います。
これだけ不正確な指標を使っていれば、見積もりも、進捗管理も不正確になってしまいます。
ましてや、プロジェクトの会計基準が工事進捗基準の場合にステップ数を使っていては、粉飾しているといわれても弁明の余地はありません。
ステップ数の代わりにスペック数を使う
ステップ数の代わりに何を管理指標に使えば正確なのか？それは、スペック数＝ソフトウェアの仕様の数です。
テスト工程では、
「ソフトウェアのコードをテストしている」のではなく、
「ソフトウェアが仕様に沿っているかテストしている」のです。
進捗管理で管理しなければならないものは、
「どの工程まで進んでいるのか」ではなく、
「そのソフトウェアが満たさなければならない仕様をどのくらい実現できているか」です。
見積もりで見積もらなければならないソフトウェアの規模は、
「ソフトウェアのコード量」ではなく、
「ソフトウェアの複雑さ」です。
ソフトウェアの複雑さはそのソフトウェアが満たさなければならない仕様の数がどのくらいあるのかで決まります。
そして、この仕様の数というのは、仕様書に詳細な実装方法を記述するというやり方では出せません。
仕様書の内容について
仕様書に詳細な実装方法を記述してはいけない
仕様書に詳細な実装方法を記述してはいけないのは、ソースコードとの二重管理になるばかりでなく、何が正しいのかがすぐに分からない形式で記述されているからです。これでは仕様書のレビューをやっても間違いが分からないし、テストや保守の役に立ません。
たとえば、ソースコードを日本語に訳したような詳細な実装方法を記述してしまうと、
最初から最後まで記述を追っていかなければ、その機能がどのように振る舞うのかは分かりません。
こんな書き方では、発注者が仕様書をレビューしてくれることは絶対にないでしょう。
仕様書には詳細な振る舞い方を記述する
ではどうすればよいか、たとえば、条件マトリクスを使うなどして、その機能が正常系、異常系を含めてどのように振る舞えばよいのかを具体的に、ヌケなく、モレなく記述すれば良いのです。
書き方は別に条件マトリクスに限りません。とにかく、具体的に、ヌケなく、モレなく記述出来ていればどのような形でもいいのです。
そうすることでソフトウェアが満たさなければならない仕様の数が明らかになります。
テスト仕様書の作成時期について
これまでの現場では、仕様書に具体的な振る舞いを記述せず、どういった機能なのか、どうやって実装するかを詳細に記述し、ソースコードの実装後にテスト仕様書でどのように振る舞うのが正しいのかを定義していました。
しかし、これは「何が正しいのか」を決めることを先延ばしにする間違ったやり方です。どうやって実装するのかを詳細に記述しただけでは何が正しいのかをきめるには不十分なのです。
何が正しいのか詳細に決まっていないのに、ソースコードを書いたらどうなるか？
そう、バグが埋め込まれるのです。
テスト駆動開発やビヘイビア駆動開発では先にテストや仕様を決めてしまうというやり方をしています。これならば、バグが埋め込まれる事も少なくなります。
やることが決まっているはずのウォーターフォールで、なぜテスト仕様の確定を遅らせる必要があるのでしょうか？
やることが決まっているなら、コードを書くよりも前にテスト仕様を確定をしてしまっても問題ないはずです。
ステップ数からテスト件数を見積もる事について
「ステップ数がこれくらいだから、テスト件数はこれくらいだろう」と見積もる現場がほとんどだったのですが、
これは逆なんじゃないでしょうか？
仕様の数が決まっていれば、それに対して使用している言語やフレームワークごとに適切なコード量があって、
仕様の数に対して、コード量が多すぎれば、冗長な書き方になっているであろうし、
仕様の数に対して、コード量が少なすぎれば、仕様を満たすためのコード量に足りていないため、
不十分な機能しか実装されていないという事が言えるのではないかと考えています。
「仕様を満たしているかチェックするためのテスト件数はこれくらいだから、適切なステップ数はこれくらい」
という話になるのが自然なように思えます。
仕様書は大事
仕様書は、 物理法則の制約がなくどのようにでも作れるソフトウェアで、何が正しいのかを決める、発注者と受注者の契約書のようなものです。
だから、どの開発方法をとるにしてもソフトウェアを作る上で最低限必要だと思っています。
また、仕様書は発注者とのコミュニケーションの際に、認識の違いをなくするために必要です。
思い違いや認識の違いがバグや無駄なコードを作る原因になっているからです。
まとめ
- ステップ数は使うな、代わりにスペック数＝仕様の数を使え
- 具体的な仕様の数が決まったら、ソフトウェアがどのくらい複雑なのかが分かる
- 通過したテストの件数でソフトウェアの進捗を管理する
- テスト工程ではコードをテストしているのではなく、ソフトウェアが仕様に沿っているかどうかをテストしている
- 仕様書にはソフトウェアがどのように振る舞うのかを詳細に記述する
- バグや無駄をなくすために、コードをかくまえに詳細に仕様を決める
- 仕様書は発注者と開発者との契約書であり、認識の違いをなくすための道具
