ソースコードを使って設計するって考え方
社内でプログラミングを教えるときに「プロトタイプってのは捨てるために作るんや」ってなことを言ってもだいたいキョトンとされるか、ふーんって解った気になるけど実際には実践出来ないかのどっちかが多い。
捨てるのが嫌いな人が多いって言うか、サンクコストって言うか、無駄なものを作るのは心理的に抵抗があるって言うか。
人間には３タイプいる
- 考えてから走るタイプ
- 走りながら考えるタイプ
- 走ったあとで考えるタイプ
走ったあとで考えるってのは失敗したときに後悔しかないわけで、エンジニアとしては最もダメな感じがする。
ほんで、多くの人は、出来る出来ないにかかわらず「考えてから走り出す」もしくは「考えてから走り出したい」と強く願ってる。だけど現実的にはきちんと頭の中で考えてからってのはすごく頭が良い人じゃないと難しいと思うのな。
やっぱり誰しも解らないことは恐ろしいことだし、これからやることの段取り無いままで始めると何時間かかるのか予定たたないんで、仕事って意味ではアウトなのは理解できる。
ただ、考えてから走り始めても、途中に石ころ落ちてるかも解んないし、落とし穴が待ってるかも知らん。それ以前に人間ってのは複雑なことなんか考えられないんだから、多くの一般的な人にとって先に完璧な設計図を書くなんてことはほぼ不可能やと思うのな。
だからこそ、「走りながら考える」で行くしかない。ラベルをつけるっつーかメタファで言うと、「計画駆動」より「アジャイル方法論」って言うかね。（ちょっと誘導的かしら）
よりこっちの世界よりの言い方をすれば「作りながら考える」ってことで、この時に同時に将来の拡張性や保守性を考えてつくると一見効率良さそうに思うけど実は YAGNI なのな。
１回目に作るプロトタイプは、もっともシンプルで直観的であるのが１番良いと思う。そうなってることに大きな価値があるっつーか。
アルゴリズム的な効率も実行時性能も関係無く、正しいロジックがあるだけのシンプルなのが一番良い。
「早すぎる最適化は諸悪の根源」 by クヌース
なんだけど、ここで１点注意点があるとすれば、人間の本能的な欲求として「正しくありたい」ってのがあって、プログラマ（エンジニア全般かも）の場合には、それがより色濃く出ることがある。正しいコードを書きたいっつーか、「動くから良いじゃん」レベルの「正しくないコード」は書きたくないっつーか。
ついでに言うとロジック的に「正しい（正しく動作する）」ことと、コード的に「正しい（技術的に推奨される手法で書かれてる）」ことは似て非なることなのな。
１回目に作るプロトタイプはロジック的に正しければＯＫ、コード的な正しさはリファクタリングで修正すれば良い。
ほんで、これ（１回目に作るプロトタイプ）を一回作っとけば
- 最悪納品までに改善出来なくても少なくとも動くものがリリースできる（精神的な余裕、納期のプレッシャーからの解放）
- ソースコードを使って描いた設計図として使える（形式言語による思考の整理、自然言語で整理するのはかなり難しい）
- 作ってる最中に得た「きづき」を取り入れてより良い設計にカイゼンできる（知のフィードバック？フィードフォワード？）
１度目に作った奴は原則的に設計図でしかないと思っておけば、設計図は実際の製品じゃないので最終的には捨てることになるのは当然だと思える。
加えて、頭の中で設計をきちんと思い描いてアルゴリズムをデバッグするのは大変やけど、ソースコードで書かれた設計図ならば高性能な IDE 上で「設計自体」をデバッグすることも可能になる。
設計は自然言語でせなアカンって制約はないんだから、設計をプログラミング言語でやってもなんの問題もない。
腕組みしながらうんうん唸ってるばっかりだったり、鉛筆くるくる回しながらメモとにらめっこしたり、ため息ばかりでなにも始まらない様子を揶揄して、「まずは手を動かせ」とか「出来るエンジニアは図で考える」なんて格言がある。
けれど、先に手が動かない人にはその人の中での手が動かないなりの合理的な理由がきっとある。誰しもサボろうと思って考えてるフリをしてるわけじゃないのだ。
要するに先に考えてからやった方が効率が良いとか、過去の経験則やなんかから自分の中でやりやすいって理由がきちんとあるから手が動き出さない*1わけで、なぜ自分が「考えてから走り出そうとする」のかをきちんと整理してみるのが案外大事なことなのかも知れないと思う。
捨てるものを作るって考えは意外にハードルが高いので、ソースコードを使って設計してみると頭を切り替えてみる心理的ハードルが下がるんじゃないかな。
*1:逆に言えば何も考えて無いテキトーな人ほどやってみてアカンかったんで無駄になったってなことを積み上げるんじゃないかなあ
