misc.log

日常茶飯事とお仕事と

詳細設計書って、何のために?

最近この手の話題をよく見かけます。

詳細設計書とコーディング用紙と(きよくらの備忘録)
http://kiyokura.hateblo.jp/entry/2014/03/10/233519

詳細設計書、呼び方は会社や組織によってまちまちで

  • 詳細設計書
  • プログラム設計書
  • 内部設計書

等々。いずれも、ITを用いてシステムを作る上で、それを実際に作るための作成上の注意点、細かい要件、実際にコンピューターに指示を出す内容を手順としたもの、などが書かれているような細かい部分に言及した資料です*1

「ような」といったことから分かるように、実際、厳密に「こうすべき」といったルールが世界で決まっている訳ではありません。コンピューターシステムを作る側の事情を知らない人にとっては信じられないかも知れませんが、決まってないのです*2。だから、何かを作るために技術者が各社から集められて、初めて会う人たちがチームとして働く、なんて場面ではしばしば混乱が生じます。

「いつものあの資料はないのか?」
「書き方が違う」
「なんでこんな事まで書いてるの!?書きすぎでしょ?」
「資料なんて作ってる時間ないでしょ?さっさと作ろうよ」

ってな感じ。なんでこんな事になるんでしょうね。

少人数チームなら無くても何とかなる(そのときは)

少人数、といっても何人までが少人数かは難しいところですが、たとえば3人のチームで何かを作るとしましょう。3人は顔を合わせて相談できるような距離で働いている、とすると、わざわざ会話で済ませられるものを資料として残すより、さっさと相談して方針を決めて、それぞれの仕事をすれば片がつきます。

こういう場合、そのときにものを作るという目的だけであれば詳細設計書なんて資料はなくてもなんとかなります。

じゃ、無くてもいいんじゃない?

そう思いますよね。きっちりとメンバーが意思疎通してコミュニケーションを密に取って作業を進めれば、伝達漏れ、誤伝達、解釈の違いなんてことは起きるはずがありません。ほら、やっぱり詳細設計書なんて要らないじゃないですか……と思いたいところですが、そうはならないのです実際。では、詳細設計書が必要になる場面をいくつか紹介してみましょうか。

  1. 作った人が居なくなることがある。
  2. コンピュータープログラムを読めない人が内容を知る必要が有る場面が存在する。

それぞれについてちょこっと補足しましょうか…

作った人がなんで居なくなるの?

ITの世界では、派遣などで一時的にプロジェクトに参加する人が多数居ます。通称、「協力会社」「外注」「ビジネスパートナー」などです。こうした人たちを呼んで助けてもらうには、時間単位でお金を払う必要があります。従って「不要になったら居なくなる」というのが彼らの基本的な取り扱い方法です(仕事が無いのに雇っておくとどんどん出費がかさむ訳ですから)。となると、いくら密にコミュニケーションを取っていても、相手が居なくなってしまいますから、ソフトウェアの作り方やどのように作ったかという情報を書き残してもらう必要があるわけです。

なんでシステム開発なのにプログラム読めない人がいるの?

コンピューターシステムの開発に詳しくない人にしてみれば「嘘だろ?コンピューターのプロが何でプログラム分からないの?」と思うかも知れません。しかし、世の中で有名なIT系会社で、実際に「システム開発やってます」という人たち、通称「システムエンジニア(SE)」のかなりの割合が「実際に最新の開発手法を自分で手を動かして実施することなんて出来ない」のです。いや、冗談や皮肉ではなく、実際そうした「自称SE」が増えているのは事実です。彼らは下っ端と見なすプログラム作成者に適切な(笑)指示を出し、お客様からの要望を聞き、作業方針や作戦を立案する。いわば指揮官なわけですね。
ですがトラブルやバグが発見された場合には「このプログラムは一体何をしていて、どういう作りになっているのか?」が分からないと、お客さんに状況の説明も出来ないし、直すのにどれくらいかかるかの見込みも立てられません。なので、どう作ったのかを文章にしておく必要があります。

あれ?必要なのって「どう作ったか」なんじゃない?

そうなんですね。実際のところ、世の中で「昔からシステム開発している」人たちが思い浮かべる詳細設計書ってものは、現状だと「何を作ったか」の記録として使われる場面の方が多いのです。
冒頭に書いたブログの方もおっしゃってますが、わざわざそんなのを日本語で書いてから、それをコンピューターの言葉に置き換える、なんて作業をやるくらいなら、実際にいきなりコンピューターの言葉でプログラムを書いた方が早いわけです。そしてその方が開発期間も短縮できて、開発にかかる費用も減り、お客さんも満足、ってなるわけです。

昔はそうは行かなかったのです。そもそも昔はコンピューターの数が少ないし、各個人がコンピューターを持っていて仕事をそれで行う、なんてのはここ20年の話。だから、事前に机の上で「ペンと紙で」プログラムのようなものを書いて、十分それを練り上げてからコンピューターの前に座る、なんてやり方しかやりようがなかった。

しかし今はそうではありません。開発用のツールは、コンピューター言語の書き方を画面に出して開発者を支援してくれるし、分からない事はヘルプやWebで検索すればすぐに調べられる。実際にコンピューターを使いながら考えて、作業を進められるわけで。そもそも仕事のやり方が変わっているのですね。

もちろん、事前に決めておかないといけない情報はありますし、そうしたものは資料として事前に作るべきです。しかし、細かいところは実際にプログラムを作る人が自分で考えて、最終目標に到達する最善の手段を採用する方が効率がいいです。

何を作ったか、の記録なの?

そうですね。何を作ったのか、どういう作りでどういう風に動くのか、関係するものは何と何で、それぞれの役割は……と言った細かいことを、あとから見た人がわざわざプログラムの中身を覗かなくても分かるようにする……。それがここ10年での仕事を通して私が見た詳細設計書の実態でした。たぶん、遠からずそういう状況が各所で発生していると思います。だから、システムを作って稼働開始してから面倒を見ない人にとっては「自分たちが不要な資料をなんで……」と思うでしょうし、システムの維持を行う人にとっては「なんで設計書も残ってないの!?」となる。それが最近Webで話題に上がる「詳細設計書不要/必要各派の対立」の根底にあるものじゃないか、と私は思うわけです。

私個人の考えでは、通称「詳細設計」なるものは「事前に書くべきパート」と「後から補足するパート」に分かれるべきではないかと思ってます。「事前に書くパート」は、実際にプログラムを作る人が必要とする情報に限定。そして「後から補足するパート」は、将来的にシステムの面倒を見る人が読む説明書のような位置づけになるものとする。

そうすれば、読み手がはっきり分かり、用途もしっかりした「詳細設計書」が残せるのではないでしょうか、ね。

あ、「プログラムに動きが書いてあるなら、後から見る人はプログラムを読めばいいじゃない?」という意見もありますよね。正論です。間違いないです。ですが、同じ事を、たとえば知らない外国の言葉で書かれた文書などについても言えますか?「 同じ人間が書いたものなのだから、辞書を引いてでも内容を理解すれば読めるでしょ……」って。その辺についてはまたいずれ書こうと思います。ヒントは「読みやすく書いてあれば、知らない言語でも調べやすいでしょうけど、方言やスラングだらけの異言語だと辞書にすら載ってなかったりする」です。

若手SEのためのシステム設計の考え方―システム企画から要件定義、システム設計書の作成まで

若手SEのためのシステム設計の考え方―システム企画から要件定義、システム設計書の作成まで

*1:逆にざっくりした機能や、外見、外見上の挙動についてまとめた資料は「基本設計」とか「外部設計」などと呼ばれ、詳細設計の前に作成するもの、と一般にはされています。

*2:誰も決めようとしなかった訳ではありません。実際にそうしたルールや規約をきちんとそろえて、意思疎通と伝達、そしてやるべき事を確実にもれなく実行するための手順を記載する方法を統一しようなんて動きはたくさんありますが……なかなか普及しないのです。なぜならば「今までやってきたやり方が一番やりやすい」と皆が思っているから。理由はそれだけではありませんが、少なくとも理由の大半はそうした保守的な意見が占めていると思います。