ITの仕事に従事していれば必ず目にする”設計”という行為。
システム開発において「”設計”をしない」という事は有り得ないと思います。
システム開発以外の様々な分野においても同様で、それは”設計”がつく言葉の多さにも表れています。
設計とは何か？と問われた時、答えに含まれる範囲は負っているタスクによって様々だと思います。
車を例にとってみると、温暖化対策、排ガス規制、これらを有効に働かせる為の制度を設計する人と、
制度に従った性能を持つ車の設計、その実現に必要なパーツの設計、パーツに必要な機能と素材の設計、
全てを同じ人の頭で考える訳ではありませんよね。
でも、どの部分においても”設計をしない”という事はない訳です。
じゃあ、なぜ”設計をする”のか。”設計”とは？
”設計とはこういう行為だ”と端的に答えるのが難しいのは、前述の様に立場や状況に応じて指し示すべき範囲が異なるからでしょう。
けれど、どの階層の”設計”にも共通する事柄があります。
それは「要求・要請を満たす為の筋道である」という事。
満たすべき要件があり、それを実現する為の手段が定義され、手段によってどのような形で目的が達成されるか。
これらが、どれだけの精度で明確化され、どれだけの状況が考慮されているか。
IＴシステムの導入というのは、顧客業務に何某かの良い影響を与える事を目的にしています。
コストの削減、作業時間の短縮、情報の記録や統計、人的エラーの抑止、事故の予防、エトセトラ。
そういった「満たすべき要件」について、
- 何をどうする事でどのような結果となるか
- その結果を導く為には何が必要か
- 思うようにならない場合にどうするか
といった筋道と、その正当性を証明する事実や実証、疑問に対する解を明示する必要があるでしょう。
また、実証結果によっては当初の方向性とは異なる手段を講じる必要も生じます。
その際に「今採ろうとしている手段は要件に沿ったものか」を判断する為にも、
「そこまでの道筋はどのようになっているか」という情報が必要になります。
このように、「目指す場所に辿り着く為」の行為として、”設計”を行い、”設計”した内容を遍く記載した「設計書」が必要になるのです。
単にプログラムのコードが書いてあってその意味が説明されているだけでは十分とは言えず、
「何故？」に答える「理由」が必ず必要だと考えています。
