基本設計書の間を縫う資料にしてほしい。
残念なことに、基本設計書の「清書」のような扱いをする人が多い。
それはつまり、同じことを「より綺麗に整えて書く」といったように。
情報の量と質が変わってないなら、無価値なんだよな。
詳細設計書が、必要なのか不要なのかを議論するつもりはない。
造詣の深さやスキル、案件の難易度、基本設計の粒度次第だから。
たとえば、「ボタンをクリックしたら検索する」処理の実装で、上流から外部設計しか来なかったときに、何を疑問に思うか？
・条件項目がwhere句に対してどんな順番で作用する？
・実装時に意識すべきインデックスがある？
・通信方式は？get/post？
・平文のjsonを戻して大丈夫？
・必要な例外処理は？
・平時の想定件数/速度は？ピーク時は？
・モダン系ブラウザだけでいい？
・想定されるデバイスと画面サイズは？
こんな感じで、詳細設計時に確認したい事項は、いくらでも挙げられる。
これをしないといけない。これが仕事だ。
ところが、外部設計を見て、その紙芝居から読み取れること、
それはつまり、
・ボタンのキャプションは”検索”とする
・表組の並びはNo、名称、日付とする
・カラーコードは○○を使う
といった、すでにある資料から読み取れる情報をあらためて書き起こすという愚行が多いことに心底驚く。
否、多すぎてもはや驚きもない。
そもそも注文時に「自分が欲しいものを言語化できないお客」がいて、そこに「疑問を持たないエンジニア」がいるということが、ごく稀な状態かと思いきや意外とそんな状況ばかりで。
それでも何回かやり直したり非効率なＱＡを繰り広げながら、
モノづくりは何とか進むし、それで「うまくいった」と錯覚してまた学習しない。
詳細設計書に何を書くかは案件次第だが、良い詳細設計というのは、基本設計の間を縫うように、隙間をパテで埋めるように作られている。
最初から隙間のない設計であれば一番良いが、それは至難。
じっくり考えれば90%を95%に、95%を97%にと精度を上げることはできるが、生産という観点ではスピードが必要で、その意味では初見の第三者が疑問をぶつけるのは重要な役割を果たす。
こういうトレーニングが、義務教育でできると良いと思う。
粗めの課題が与えられて、課題の制約条件は質問をベースに作り上げていき、対話や議論で抜け漏れをなくし、最短距離でゴールに辿りつくみたいな。
ロジカル思考ってことになるけど、それはテクニックを机上で教えるのではなくて、呼吸するように使えるところまでを実践形式で。
