定義
「ヒロシです。仕事がとってもつらかとです。」
入力、処理、出力。これ基本。…と言っても、手続き型プログラミングの話ではなく、もっと広義な話だ。材料を加工して部品を作る、部品を組み立てて製品を作る。材料を調理して料理を作る。入力、処理、出力と云う点で、みんな一緒。
さて、IT の話。以前、ハンバーガーを作るように、システムを開発しよう! みたいなのを書いていた。まとめ切れなくて、途中で放置してしまっているのだけれど、その続きみたいな位置づけの話だ。
基本設計と云う工程がある。定義済みの要件を基にして基本設計を作るあれだ。次の工程に進めば、基本設計が入力になるのだけれど、いつまでたっても「これって、基本設計とちゃうの?」ってゆー事柄が残っているのが普通だった。試験まで進んでも…だ。
なぜだろう…の話の前に、上の文章には二つの意味で基本設計が使われている。工程としての基本設計と、成果物としての基本設計なのだが、後者を基本設計書と呼びたくなかったのは、大事なのは書類ではないからだ。大事なのは中身なのだ。何が書いてあって、どう云う状態になっていればいいのか? そこが大事なのだ。ところが、この大事な部分がかなり希薄だ。なぜだろう…は、ここにつながる。
ハンバーガーが誰にでも作れるのは、材料、調理方法、そしてできあがってくるハンバーガーが明確に決まっていて、誰でもできる程度まで調理方法が絞り込まれているからだと言える。新人はパンを焼く、野菜や調味料を載せる、肉を焼くを別々に教わる*1。いずれは一通りできるようになって、全部の作業を覚えるのだけれど、店が忙しい時間帯はそれぞれ専任で作業をこなすことになる。ひたすらパンを焼き続ける人、ひたすら肉を焼き続ける人って感じだ。この一つ一つの作業も入力、出力が明確に決まっている。ハンバーガー作り全体としても、パンを焼く、肉を焼くと一つ一つの調理としても、入力、出力に矛盾がない。手続き型のプログラムは、大きな処理を小さな処理の組み合わせで、処理の入れ子として作るけれど、それと同じ感じだ。
システム開発ではこれがぜんぜんできてない。要求を分析して、要件を定義して、基本設計をやって、詳細設計をやって*2…と、流れはある。けれども、一つ一つが「何を入力して、何を出力するのか?」がめちゃめちゃいい加減だ。書類のタイトルは決まっているけれど、ここで言ってるのは中身のことだ。皮肉なことに、だから上流工程では期日に合わせて成果物を作ることができている。ある程度、それらしく見えれば、誰もダメ出ししない (できない?) からね。
ところが、実際の中身は伴っていないから、問題の先送りが起こる。詳細設計工程や実装工程で、それ以前の成果物の内容の話をしなければならないのだ。要求確認まで遡らなければならない話も少なくない。だから、コーディング工程では、上流から流れてくるいい加減な情報、足りない情報、整理されていない情報、多すぎる情報を、整理、分析、推理 (時には捏造) して、実装ができるほどのものに昇華させる、最も高度な技術が求められるのだ! …と云うのは、言い過ぎにしても、「Java が書けます。」ぐらいでは、かなり難しい仕事になってしまっているのは間違いない。
もし、実装の入力となる設計がもっと定型的で安定したものだったら、実装作業は簡単なものになる。究極的にはコンバーター的な作業に近づいていく。これは実装作業だけの話ではなく、入力、処理、出力の流れにあるものすべてだ。例えば工場の製造工程はすべて、入出力が明確になっている。口頭では「あれをやって、これをやって…」と処理内容の話になっていて気付きにくいが、どんな材料を投入して、何が出来上がるかは厳密なものだ。目に見えるから会話に上らないけれど。
システム開発も何を入れたら、何ができあがるのか? を明確にしなければならない。処理の部分に相当する「どのような作業をするのか?」は、重要ではない…と言ってしまうと、誤解を招くか。やり方は、もっとも効率の良い方法を採用する可変部分であり、入力と出力こそが定義しなければならない固定部分だと云うことだ。
"基本設計" なんてキーワードは、成果物としても工程としても厳密な定義ではない。100 人いて、100 人がバラバラのものを作るような状態で厳密とは呼ばない。誰がやっても結果が変わらないところまで詰めてこそだ。そして、その単位が小さければ小さいほど、一つ一つの処理をこなすのは簡単になり、実行できる人の裾野を広げられるのだ。
