もっとも「ロジック」というのも程度問題なのだけど、
少なくともプログラム言語で記述するレベルでのロジックを書くというものではありません。
いや、特定の企業ではそういう書類を（しかもプログラム前に！）書かせるように強要してきたりするけども。
参考：IEEE830-1998におけるソフトウェア仕様書（内部）の書き方
そもそも業界ではさも当然のように「外部仕様書」とか「内部仕様書」という言葉を使っていたりしますが、
あまりきっちりした定義はありません。上記でも「内部仕様書」という定義ではないわけですし。
各社の文化で独自に解釈されているのが実情ですかね。
ニュアンスとして外部/内部というのはI/O境界面からの外部/内部といった感じ。
他のチーム(別会社だったりする)とかとやり取りするために、この機能は外から見たらこんな感じ、というのが外部仕様で、
中はこう言う風に作るっていうのが内部仕様とされます。
外部仕様と言われるのは取扱説明書のようなもの。内部仕様は中の設計図のようなものというイメージで。
プログラムにおいて設計図ということはロジックじゃないの？というとちょっと違います。
そもそもロジックというのも曖昧な用語で何を指すのか胡散臭いのだけども、
IT業界だとかなり細やかなレベルでのアルゴリズムを指して使われることが多いですね。
設計書に必要なのはもっと大きなレベルでの流れであって、そのような細かいところは仕上げの話。
まずは大枠の骨格から考えるものです。
しかし「内部仕様書」という用語も定義が胡散臭いし、
「ロジック」という用語も定義が胡散臭いから、
実は「内部仕様書はロジックを書くものではない」というのは
用語の定義次第では真とも偽とも言えることだったりします。
ただ、少なくとも冒頭で述べたように「プログラム言語で記述するレベルでのロジックを書くというもの」ではありません。
自然言語でロジックを書いてはいけない
ロジックを自然言語で書くというのは、かなりナンセンスです。自然言語はロジックの記述には向きません。
プログラミング言語はそもそもがプログラムというかロジックを記述するために設計されているので、
そのロジックの記述に曖昧さが入らないよう工夫されています。
自然言語でロジックを記述してからプログラム言語に翻訳するというのは、
プログラム言語に堪能ではない人の場合には有効かもしれません。
あるいは、はるか古代、PCが貧弱で対話的なプログラミングができなかった時代なら有効だったかもしれない。
想像してみてください。
英語の通訳を雇ったら、自分の言った日本語をメモしてから英語に直して、それから現地人に語りかけたとしたならば？
一般的な感想はこうでしょう。「おまえ、それでもプロか？」
まともなプログラマならロジックを直接その言語で考えられます。
むしろ、プログラム言語のほうがロジックの記述に向いているのだから、プログラム言語で思考する方が楽だし、間違いがない。
かといってプログラマの平均的ロジック表現力は総じて低い。
自然言語で考えてから翻訳するレベルでも書けるなら駆り出さないといけないぐらいには人材不足だったりもします。
冗長は排除しよう
プログラム言語で整然と書かれたロジックを、自然言語に翻訳して冗長な文章を書かせるというのはナンセンスです。
二重化されるため、メンテナンスの手間は倍になります。そもそもちゃんと同期させるだけでも至難の業。
だいたい、ロジックが日本語に訳されていたって、プログラムが分からない人間には分からないんだから意味がない。
その翻訳は誰が読むためのもの？プログラマなら原文であるプログラム言語を読むわけです。
今時はIDEも発達しているので原文で読む方が読みやすい。
場合によっては、数式などをプログラムで実装するようなケースはあります。
しかし、その場合、自然言語で補足はあるかもしれませんが、主体ではない訳です。
この種の議論の意見の食い違いはどこから来るか？
冒頭述べたように、まずは用語の曖昧さがあります。
「うちの会社の内部仕様書では～」という局所文化を基に話をされても、
前提が根本的に違うことから文字通り話にならないことが多いですね。
また、「ロジック」という曖昧な用語も曲者です。
アルゴリズムの外観をして「ロジック」と呼んでしまえば、それは確かに仕様書に書かれてもおかしなものではありません。
「アルゴリズムの外観を書くべきだ」→「ロジックを書くべきだ」→「プログラム言語での記述の翻訳を書くべきだ」
そんな風にすり替わりが起こるので議論が混乱します。このような話題をする場合は注意しましょう。
また、特定の企業文化では自然言語でのアルゴリズム記述をしてからプログラム言語に翻訳するという過程で
システム開発をすることもあります。
その場合は企業文化として内部仕様書にロジックは記述することになるわけです。
その実例をして「書くべきだ」という人もあるいはいるかもしれない。
この議論では実績があるかどうかが問題なのではありません。
それによってなんのメリットがあり、なんのデメリットがあるかが問題なわけです。
そして、デメリットの評価の方が大きいのであれば、排除するべきだという結論になります。
投稿日時 : 2008年3月24日 1:23