SiroKuro Page

詳しすぎる詳細設計書

「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。

入力：

• 「性別と身長のペア」のリスト

出力：

• 男性の平均身長」と「女性の平均身長」の差

処理概要：

1. 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する
2. 入力を受け取る
3. 入力されたリストから要素を読み込む
4. 入力されたリストの要素数だけ以下を繰り返す
   1. 要素を１つ読み込み、条件分岐する
      1. もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる
      2. もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる
   2. 次の要素を読み込む
5. 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する
6. 出力する

イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いているかはバラバラだけど、ときどきこんな風にやたらと詳細な処理概要を書いている会社もいたりする。

これを Java で実装すると、こうなる。

class Calculator {
    public double process(List<Person> input) {
        int danseiSintyo = 0, zyoseiSintyo = 0, danseiNinzu = 0, zyoseiNinzu = 0;
        for (Person p: list) {
            if (p.getSex() == Sex.MAN) {
                danseiSintyo += p.getHeight();
                danseiNinzu++;
            }
            if (p.getSex() == Sex.WOMAN) {
                zyoseiSintyo += p.getHeight();
                zyoseiNinzu++;
            }
        }
        return danseiSintyo / (double)danseiNinzu - zyoseiSintyo / (double)zyoseiNinzu;
    }
}

色々な意味でとても残念です。けど実際はこんなもんです。

実際書いてみて異様なほど書き直したい気持ちに満ちあふれているんですが、そのためには詳細設計書が異様なほどに邪魔になります。詳しすぎるんです。

この例ならばまだ救いようがありますが、詳細設計書はしばしばハードウェア的な実現方式にまで言及していたり、しかもその実現方式が実現不可能方式だったりして大いに悩むことになったりすることもありえたりするのです。

得てして、詳細設計書は詳細であるがゆえに邪魔者扱いされます。なぜ邪魔者扱いされるかといえば、システムのことを中途半端にしか指図しないからです。システムを見ているようで、実は目を瞑りながら口だけ出しているという感覚ですね。実装するには物足りず、基本仕様としては詳しすぎる、そんな役回りです。

ちなみに上記の処理概要は COBOL ならばすんなりと記述できたり。COBOL 最強説ここに爆誕。こういう詳細設計書の存在が、SIer が COBOL から離れられない一因になっていると私は考えています。

上の処理概要は COBOL で書くと一対一です。Java で書くと不恰好になります。Haskell では記述することもできません。

Haskell 向けの詳細設計書を書くならば、こんな感じかもしれません。

入力：

• 「性別と身長のペア」のリスト

出力：

• 男性の平均身長」と「女性の平均身長」の差

処理概要：

1. 引数から入力を受け取る
2. 男性のペアのみを抽出したリストを「男性だけのリスト」とする
3. 女性のペアのみを抽出したリストを「女性だけのリスト」とする
4. 「男性だけのリスト」内の身長を合計し「男性の合計身長」とする
5. 「女性だけのリスト」内の身長を合計し「女性の合計身長」とする
6. 「男性だけのリスト」の要素数を「男性の人数」とする
7. 「女性だけのリスト」の要素数を「女性の人数」とする
8. 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、結果として返す

関数型っぽいパラダイムに近づいたと思います。これなら Haskell でも書きやすいはず。

すなわち『詳細設計書が処理の中身を詳しく記述するものならば、それを実現するための方式が定めるパラダイムとのミスマッチを避ける』必要があると思っています。それらが COBOL の頃からあまり変わっていないため、SIer が未だに成長できない理由になっているのかも、しれません。

あ、ゼロ除算とかどうするんだよ、という話はもちろん枝葉末節ですよ。

追記

続きを書いてみた。

古き悪しき詳細設計書 - SiroKuro Page

Permalink | コメント(4) | トラックバック(5) | 22:24