世の中的にはまだまだ「新しいもの」であるソフトウェアにまつわる活動は、メタファ（隠喩）を使って説明されることがよくある。一番多く使われるメタファは、建築にまつわるものだろう。アーキテクチャ、工程など建築由来の用語はソフトウェア業界には数多く存在し、得体のしれないソフトウェアというものへの理解の助けになっている。
一方で、プログラミングが多くの人に認知されるこの時代においては、建築というメタファは致命的な欠陥があると思う。ほとんどの人は、自分で「建築」したりしない。犬小屋ひとつ作った経験のない人が普通だ。小学校の授業でプログラミングを習ういま、プログラミングを説明する、より適切なメタファがあるはずだ。
料理とプログラミング
私は、プログラミングおよびプログラマーのメタファとして、料理および料理人を使っている。料理だったら、誰でも多かれ少なかれやったことがあり、建築よりもはるかにメタファとして使い勝手がいい。
似ているところ
料理とプログラミングには以下のように多くの類似がある。
誰でもはじめられる
プログラミングも料理も、はじめる敷居はとても低い。特別な道具がなくてもできるからだ。もちろん、凝った料理をするにはいろんな道具や調味料がいるかもしれないけど、簡単なものなら包丁もコンロも使わなくてもできる。電子レンジだけで作る料理だって立派な料理だ。
プログラミングも敷居は低い。小学生はギガたんでScratch組んでるし、Switchユーザーは「ナビつき！ つくってわかる はじめてゲームプログラミング」でゲームを作れる。自分のPCがあればそれに越したことはないけど、なくても最初の一歩は踏み出せる。
自炊なら簡単
自分で食べるものを自分で作るだけなら、料理はさほど難しくない。もちろん最初はあまり美味しくないかもしれないけど、「食べられる」レベルのものなら中学校の調理実習を受けてなくたってできる。もし失敗してるとしたら、自分には難しすぎる料理を作ってしまったんだろう。とりあえず塩コショウして炒めとけ。物足りなければ味の素振っとけ。
プログラミングも、いきなりUnityで3Dゲーム作ろうとしても失敗するのは当然だ。はじめは、ゲーム作りたいならScratchで、そうでなければPython/Rubyでスクリプト組むぐらいなら、きっとすぐにできる。
レシピがある
料理の下手なひとの最大の特徴は、「レシピ通りに作らない」らしい。何事も習得のプロセスの基本は「守破離」だ。まずはレシピ通りに作るのが上達の近道なのは間違いない。インターネット以前でもレシピ本は本屋さんの定番コーナーだし、いまではネットでいくらでもレシピを見つけられる。
プログラミングも、作りたいプログラムの例をGithubやQiitaで見つけることができる。フレームワークやライブラリを使うのであれば、公式サイトがチュートリアルやサンプルを置いてくれている。何だったらChatGPTが雛形作ってくれるかもしれない。大いに参考にしよう。
知ってるとできるは違う
自分で料理をしないのにパートナーやお店の料理に、さも自分の方が美味しいものを作れるとでも言わんばかりにケチをつける人がいる。出汁とか語り始めたら危険な兆候だ。「パラパラ炒飯にするには〜」とかも香ばしい。まず自分でやってみようよ。きっと最初は失敗するだろう。でも何度も挑戦したら上手になるから。
プログラマーも頭でっかちな人がいる。方法論を勉強するのは素晴らしいことだけど、まずは自分で実践しないと。自分で手を動かしたことで得られる情報は貴重だ。頭でっかちで自ら手を動かさないエンジニアの設計するソフトウェアは頭でっかちで重鈍なものになりがち。ひとはコードから離れては生きられないのよ…
基本が大事
中華料理人はフランス料理を作れるのか、みたいな問いがある。中華料理を和食、フランス料理をイタリアンに変えてもいい。私は、これは「できる」と思う。もちろん、食材など不慣れなところはあるだろうけど、ある程度訓練すればすぐに作れるようになるだろう。なぜなら、彼らは料理の基本ができているから。
プログラミングも、言語が違えば作法も違い、作る対象や業種が異なればプロセスも必要なスキルも違う。普段エンタープライズなシステムを作ってるプログラマがいきなりゲームエンジン書くのは難しいだろう。でも、基本ができていれば、多少作法が違っても短期間でできるようになると思う。逆に、基本ができてないプログラマは言語や業種が変わったらまったく役立たずになる。
仕事にするには「レシピ通りに作る」では足りず、その先に行くには基本が大事なのだ。
大量に作るのは大変
「自炊なら簡単」と言ったものの、作る量が多くなると簡単ではなくなってくる。1人分の料理をつくるのをパートナーとの2人分作るようにするのはあまり変わらないけれど、家族4人分となると話が変わってくる。フライパンひとつでできた料理ができなくなる。最初に作った料理が、4人目のができた頃には冷めてしまう。1人分が4人分になっただけでそれまでの方法論が通用しなくなる。ましてや、ホームパーティで10人分とか、お店を開いて200人分を作るとなると完全にプロセスが変わる。ひとりでは作れないし、段取りも重要になる。
プログラムも、大量というか、大きなものを作ろうとすると難しくなる。ひとりではなくチームで作るようになるからだ。どう分担するかはいつだって悩ましい。他人が作ったコードを改修するのも普通だし、だからこそ「わかりやすさ」も大事になる。チームでシステムを開発するのは、ひとりでプログラミングするのとは別物と思ったほうがいい。
ビジネスにするのは難しい
お店の料理を食べて「俺が作った方がうまい」みたいなことを言うひとがいる。そんなの当たり前だ。採算度外視で食材を買ってきて、新鮮なうちに好みのレシピで時間をかけて作り、できたてを食べればそれはうまいに決まってる。でもお店の料理人は、原価率を抑えないといけないし、お客さんを待たせられないし、たくさんの注文を同時に処理しなければいけない。
ビジネスで作られたプログラムも残念な質なものはたくさんある。でもそれは必ずしも残念なプログラマーによって作られただけではないかもしれない。プロジェクトの納期が極端に短かったのかもしれないし、予算がなくて何かを諦めなくてはいけなかったのかもしれないし、途中で要求が変わったのかもしれないし、当初と使われ方が変わったのかもしれない。営利企業でものを作るのはいつだって大変だ。ソフトウェアは動いてさえいれば、最低限のリスペクトは払ってもいいんじゃないかな。
似ていないところ
もちろん、しょせんメタファなので似てないところもたくさんある。それらを踏まえた上で使わないと誤解を生んでしまうのは変わらない。たとえば、以下の点はだいぶ異なるので注意が必要だ。
プログラムの品質は見えにくい
料理だったら、味と見た目なら誰でも評価できる。一方、ソフトウェアの品質はなかなか可視化が難しい。もちろんいろんな指標はあるけれど、料理のようにわかりやすいとは言えないし、それほどアテにもならない。
作ってからが長い
料理は保存食でもない限り、作ったらすぐ食べて、片付けたらそれでプロセスはおしまいだ。一方、ソフトウェアは作られてから「使う」期間が長く、そして使ってる間にどんどん変更が加えられる。何年も使われるのだからプログラミングは料理というよりレシピでしょ、という意見はわからんでもない。でも、自分でレシピを創るひとってそんなにいないよね。素直に、ここは似てない点にしておきたい。
進化が早い
IT業界は変化が早く、新しくでてきたものは基本古いものより優れている。料理だったら「伝統のレシピ」に高い価値があるが、プログラマーの使うもので古いことに価値があることはまずない。老害になりたくなければ常に新しいものを取り入れるべきだ。「おばあちゃんのレシピ」は役に立たない。
さいごに
この記事が、得体のしれないプログラマーというひとたち、およびプログラミングという活動の理解に役立てればうれしい。