数珠

「見出しをチェーンにしようと思ったけれど、二字熟語シリーズだからね、」
先日の日記 "定義 (id:Tommy1:20050509)" で、入力と出力を厳密に定義するべきだと書いた。しかし、「ウォーターフォール開発がうまく行かないから反復型開発が出てきた訳で、基本設計の入力と出力を厳密に定義することなんて、できないか、非効率だ。」…と反論があるかなぁ…などと思うのであるが…。まあ、そのあたりについて、もう少し細かい話を補足しておきたいと思った。

"定義" の話は全体の仕様を決定するか、しないかには関係しないことで、開発時に行う一つ一つの作業を対象としている。だから、ウォーターフォールかインクリメンタルかイテレーティブか…といったことには関係しない。

仮に仕様を細切れにして実現してゆくインクリメンタルな開発を行うとする。その仕様は仮決めでもぜんぜんかまわない。けれど「エコエコアザラク~」と呪文を唱えたらチン! とアプリケーションができ上がるはずなどなく、順を追って作業を進めてゆくことは避けられない。話題にしているのはその作業のこと。こいつの入力と出力が厳密でなければならないと主張している訳だ。

例えば、ユースケース記述を静的分析してクラス図を作成するのを第一段階とする。入力はユースケース記述、出力はクラス図で、どうなったら作業が完了するのかが作業に入る前に明確でなければならない。"完了したら終わり" ではダメだ。属性、型、操作、引数、可視性なんかの記述をするか、しないか。ユースケース記述の内容をすべて網羅するのか? それともメインフローだけ実現するのか? どうやって完了を確認するのか? そういったことを決めるのだ。どうなったら完了するのか? が大事なのだ。そもそも、静的分析だの、動的分析だの、基本設計だの、詳細設計だの…。「重要なのは名前ではない!」のだ。「表紙に題名を書くために名前があるのではない!」と声を大にして言いたい。

先の静的分析の次に、いきなり実装をするとする。この時、クラス名と関連ぐらいしか書かれていないクラス図を基にするのと、属性、型、操作、引数まで書かれているところから始めるのとでは、実装時に必要となるスキル、見る情報、作業時間はずいぶんと違う。だが、その差を気にすることなく、名前だけで予定を決めている。ユースケース記述とクラス図が合わないような状態もあるから、実際の差はもっと酷いだろう。完了の定義が曖昧だから、完了の判断にけっこう時間を費やしてしまうし、レビューもレビュワーの主観に大きく依存するから、作業時間も品質もまったく予想できない。で、どうなるか? 期日になれば見栄えを整えて、間に合ったことにしてしまうのである。犠牲になるのは内容の方だ。当然、次の工程で苦労することになるが、次の工程でも同じことが繰り返される。そして最後には誤魔化せなくなり、ついには火を吹くって寸法だ。

大事なのは期日ではなく、今、その瞬間にどう云う状態にあるのかだ。それまでの成果が信用できるのかどうかだ。そこが崩れてしまうと、納期の予想*1なんて当てにならないし、どんなものができあがるかも神のみぞ知るだ。

入力と出力を厳密に定義するのは、そんな道に踏み込まないために不可避なのだ。開発効率を上げるために、どんな改善をするにせよ、ここは絶対に手を抜いてはいけないところなのだ。

*1:予定でも予測でもないところがミソ。