設計のしかたを教えるのは難しい

いきなり勉強会で話すことになって、前々からやりたかった「設計のきほん」というテーマで話したが、いまいち反応が薄くて反省しているという話。

なんか巷でのバズワードや流行りの手法に振り回されずに、そもそも設計ってなんで必要なんだっけ？大切な原則、忘れちゃいけないよ？みたいな話をしたかったわけだが、聞いてくれる人がそもそもそんなにバズワードや流行りの手法に振り回されてなかった（！）のでいまいち響かなかった、ということかと解釈している。どうせわたしが「意識が高すぎる」んでしょうよ。えーん（かわいくない）。

まあ、それは私の準備というか伝え方が悪かったという話で終わりなのだが、そもそもふだん、みなさん現場で設計とかどのように教えておられるんですかね？ソースコードを書いた時にはコードレビューがあって、そこでまかなえる範囲なら指摘できるかもしれないし、設計書をちゃんと作るような開発体制の場合だと、そこで設計レビューが入るかもしれない。でもどちらにしても、一般論として教えるのってどうも疎かになったりしていないですかね？会社ごとや個別事例に対してのアドバイスはできるんだろうけど、それを一般的な原則にまで落として説明してあげてる現場がどれぐらいあるのかは本当にわからない。

あと、それ以前の話として、そもそも設計の一般論など不要で、会社で昔からきまったフォーマットの設計書があって、それを適度に慣例に従って書けばだいたいうまくいっているし、残りは臨機応変に反応すればいいんじゃない？みたいな現場の方が多いのではないかと勝手に想像している。そしてそれは大変現実的で素晴らしい、バランスの取れた現場だとも思う。

ただなあ、やっぱり、もっとうまくいく方法があるのに、同じ手間をかけるならいいソフトウェアを作りたいと思わない？楽して追加変更できるようになった方がみんなハッピーになると思わない？という心の中の声が黙ってくれない。でもまあ、その考え方自体がビジネスと相性が合うとは限らないし、「意識高い」と言われちまうんだよな〜という自虐になってしまう。特に、新規開発ならばともかく、すでに動作しているソフトウェアのリファクタリングなどが対象の場合は、余計に「動いているものは直すな」理論が勝ってしまうのよ。アーメン。

話が逸れた。たとえ現場がよりよい設計を求めていたとしても、そもそも他人に設計の方法を教えるのは難しいという話だったはず。一般的な原則については良い書籍もたくさんあるが、それをReal Worldに適用するための基準や練習方法が不足しているように感じる。わたしが知らないだけですかね。というか根本的に難しいということの証左なんですかね。これから新しい職場でぜひそういうワークショップみたいなことをしていきたいとは思いつつ、ちょうどいい見本を探している、というそれなりのキャリアを積んでしまったソフトウェアエンジニアの世迷言でした。