304 Not Modified

ものすごい大雑把に言うと、ＳＥ（システムエンジニア）はシステムに関わる通訳さんなんだと思う。SIerは顧客とエンジニアとの通訳さんで、エンジニアはSIerとプログラマの通訳さんで、プログラマはエンジニアとコンピュータの通訳さんなんだ。

と思ったのも、「数学でつまずくのはなぜか」（小島寛之）を読んだからなんだけど、初期の数学において最もつまづきやすい部分は数学的表記の部分だという。確かに、数字では理解していてもそれを共有するために言語として表現するための規則が疑問だらけだったりする。

人は自分の頭の中で完結する分にはそのままで良いのだけれど、それを誰かと共有するときに“言葉”にしなくてはならない。例えば、このブログだって私が考えていることを他の人にも知ってもらいたくて、このようにブログという形で表現している。絵描きは絵で表現するし、ミュージシャンは音楽で表現する。しかし、これらは分かってくれる人が分かってくれれば良い的な一方通行の表現だ。互いに理解し合うには言語の統一（ルール）が必要だ。

一つの開発プロジェクトにおいて、そのルールは大雑把にはスタンダードなフレームワークは存在するけれど、明確には決まっていない。そこで間を取り持つ言語となるルールが“仕様書”なんだと思う。

で、設計書の自由度について - techlogの記事に繋がるのですが、

ちなみにid:manameさんは、いまはどんな設計書を書いているんだろう。

私のプロジェクトでは、プログラムがお客さんの意図と異なった動きをした場合、それが設計書に書かれていればバグではなく、書かれていないければプログラムのバグになる。だから、仕様の面での自由度は無いようにする。しかし、プログラムの構造に影響を与えるような書き方だけはしない。特に新規プログラムの場合、設計書からプログラムの枠組みが自動生成されるのでプログラムを意識した設計書を書くように意識している。・・・まぁ、もう設計書は直接書いてなくて、レビューで係わる程度なんですけど。

私のようにスーツ側の人間としては、中身も重要ですがフォーマットも重要ですね。今のところは設計書だけでキングファイル200～300冊ありますし、それぞれが自由に書いてたらとてもじゃないけれど見切れません。「今日はどんな服着ていこうかな」という時間を節約するために学生服があるように、「設計書をどんな風に書こう」と考えて無駄な時間を使わせるのももったいないですよね。設計書の書き方規約が決まっていれば、どの設計書を開いてもどの辺に何が書かれているかすぐに想像できて設計書単体でも使いやすいものになりますから。

ちなみに、設計書とコーディングの工程で最も大事なことは、コーディング時は設計書に無いことは絶対に実装しないことだと思います。普通、考えていることを文章に書き出すというアウトプットに慣れているせいか、プログラミングにおいてもコーディングしてから設計書を書くという手順を取ってしまいがちで、また設計書を先に書いても、これは必要と思ったらついコーディング時に設計書にない部分を実装してしまいがちです。これ、一番のバグ原因ですから！

ξﾟ⊿ﾟ)ξ勘違いしないでよね！べっ、別にまなめはうすってすごいって記事で褒められたのがとってもうれしくってニヤニヤが止まらなくなったからトラックバックを送ったわけじゃないんだから。たまたま、数学の本を読んで通訳さんの話を書くのについでに便乗させてもらっただけよっ（///）

はてなブックマークに追加
はてなブックマークのコメントを参照