プログラマとしてのメンタルモデルを手に入れるために「プログラマが知るべき97のこと」を読んだ

プログラマとは？

Kyo

2022.07.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。CX事業本部のKyoです。

今年の1月よりソリューションアーキテクトからサーバーサイドエンジニアにロールチェンジしました。そんな背景もあり、今回はプログラマとしての心構えに関する本とその感想を紹介したいと思います。

プログラマが知るべき97のこと

偉大なプログラマ達によるエッセイ集です。通称きのこ本とも呼ばれているとか。

人々のさまざまな思いを技術で形にするプログラマ。本書は世界中で活躍するプログラマによる97本のエッセイを収録した書籍です。プログラミングにおいてもっとも重要な事柄は何か、バージョン管理やテスティング、設計原則とコーディングテクニック、また腕を磨くための勉強法などについて、経験豊かなプログラマが自らの体験を踏まえて解説します。プログラマを勇気づけ、新たな気づきをもたらす一冊です。日本語版では、小飼弾、関将俊、舘野祐一、まつもとゆきひろ、宮川達彦、森田創、吉岡弘隆、和田卓人による10本の書下ろしを収録。

オライリー社サイトより引用

これらのエッセイはCC-by-3.0-USでライセンスされているおかげで、オンラインで無料で読めます。最高ですね。私は以下のサイトで読みました。

なぜ読んだか

冒頭お伝えしたように、今年の1月から別チームに異動しました。同じ会社内とはいえ、インフラ系部門出身の私としては開発チームとカルチャーのギャップが大きかったです。

特につらいと感じたのは「レビューや打ち合わせの際にチームメンバーが重視していることや行動原理が分かりづらい」ということでした。

この件についてメンターとの1on1を行う中で、まずはプログラマとしてのメンタルモデルを手に入れることが重要ではないか、という話になり、紹介してもらったのがこの本です。

読んでみた

一ヶ月ほどかけて97 + 10のエッセイを読みました。一気に読むことも可能だったとは思いますが、ゆっくり読むのが向いているタイプの本ではないかと思います。

途中、お気に入りをメモしながら読んでいましたが、気づけば半数以上がお気に入りになってしまいました。どれもよかったということではありますが、流石に多すぎたので20まで絞ったのが以下のリストです。その中でも特に良かった5つには⭐️をつけました。

本編

日本人プログラマによる知っておくべき10のこと

改めてお気に入りのタイトルを眺めてみると、プロのプログラマとしてあるべき姿や、どのように近づいていくか、というところに心惹かれたようです。

特にお気に入りのエッセイたち

特に良かった5つのエッセイについて、個別の感想を書きます。

超人の神話 by Ryan Brush

ソフトウェアをよく知らない人にとって、プログラマは魔法使いや超人に見えるがそんなことはない、というエッセイです。

どれほど優れたプログラマも人間であることには違いはないのです。彼らも他の人と同じように、論理的に考え、体系的に分析をしない限り、どんな問題も解決できないのです。

どれほど素晴らしいプログラマであっても、はじめから十分な知識と技術を持っていたわけではありません。最初はごく普通の人だったはずです。今は超人に見えるかもしれませんが、それは長い時間をかけて学び、自分を磨いてきたからです。賢い人が長い間、強い好奇心を持ち続けた結果、超人に見えるようになったと言っていいでしょう。

すごいプログラマも、ベースはごく普通の人で、その延長線上に超人のように見える状態がある、ということですね。言われてみれば当たり前なのですが、間近でみていると忘れがちになります。実際、現チームにジョインしたてのころ、非常に少ない情報からトラブルシュートを行なっていく様子が超人的だと感じたことがあります。

また、長い時間をかけて学び、磨く、という部分から超人への道に近道はない、という風にも読み取れます。学問に王道なし。

リスペクトは持ちつつも、彼らが特殊な人間である、とは考えるべきでないし、自分が彼らのようにになれない、とは考えるべきでないことを認識しました。別のエッセイ「1万時間の訓練」に通じるものがあります。

プロのプログラマとは？ by Robert C. Martin (アンクル・ボブ）

プロのプログラマとはどんな存在か、をストレートかつストイックに書いてあるエッセイです。

プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度、責任感です。責任の取れないような見積りやスケジューリングは決してせず、作る製品の質にも責任を持ちます。ミスがあれば、必ず自ら対応します。他人に責任を押しつけるようなことは一切しない、それがプロです。

もう少し要素分解した内容についても書かれています。

医者や弁護士みたいなもので自らの意思でコストを払い、自らのスキルを伸ばす
自分のコードに責任を持つ（人間なので間違うことはあるが、責任を持つ姿勢が重要）
チームプレイヤーである
絶対に間に合わせのいい加減な仕事をしない

最後の「絶対に間に合わせのいい加減な仕事をしない」の心臓手術の例えはとても腑に落ちました。

たとえば、あなたがもし、心臓切開手術を受けるとします。そしてその様子を幽体離脱して上から見ているとします。医師に与えられた時間は限られています。他の仕事と違い、締め切り（deadline）を過ぎてしまえば、文字通りあなたは死んで（dead）しまいます。人工心肺を装着した状態で長時間経過すると、血球の損傷が激しくなるからです。こういう時あなたが患者なら、医師にはどう行動して欲しいでしょうか。納期に追われるプログラマのような行動を望みますか。「とにかく時間内に終わればよい」というようないい加減な仕事をして欲しいですか。あるいは「今、ちょっと治せないので、後にします」などと言って欲しいですか。

現チームではスクラムを採用しており、毎週、ゴールに追われながら仕事をしています。そうなると迫るゴールに対して、焦った仕事をしてしまう…ということも不本意ながら経験しました。そんな時にチームメンバーから「落ち着かないとプログラムは書けない」と言われたことを思い出します。

やはり、時間の無い中でも平常心を保ち、その時にでき得る最善の処置をして欲しいと思うのではないでしょうか。間に合わせの仕事ではなく、プロの仕事をして欲しいと思うはずです。

ストイックなことが書いてあります。まずは意識だけでも向けていきたいと思う一節です。

良いプログラマになるには by Pete Goodlife

スキルにある程度自信が持てるようになった頃に見直したいエッセイです。

素晴らしいアルゴリズムを考え出せる知性を持ち、プログラミング言語についての知識も十分なプログラマが、実にひどいコードを書くというのは珍しくありません。そういう人が、読むのも使うのも大変、修正するのも大変、というコードを書いてしまうことはあるのです。

ユーザーではなく、プログラマとしての面白さを追求するあまり、運用等の重要な観点が抜けてしまう。これはプログラマに限らず、技術系あるあるだと思います。過去にAWSのコンサルティングを行なっていた際に、面白い構成ですね！ただ、運用体制を作るハードルは相当高いですね…。というものをいくつか見たことがあります。

リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでもできる限り良いコードを書こうと努力をするのです。

ここは1つ前に出たアンクルボブの心臓手術の例えと同じですね。

絶えず積極的に新しい言語、イディオム、テクニックを学ぶ。ただし、学んだことをむやみには使わない。適切と判断した場合にのみ使う。

この部分、本当に大事だと思います。新しい技術を学ぶことは重要で、自分の引き出しを増やしておくことは新しい価値に繋がる気がします。一方で、技術は結局のところ、手段であって目的ではないので、目的と一致しないシチュエーションで使ってしまうのは本末転倒点ということでしょう。

ロールプレイングゲーム by 関将俊

プログラマの本能と付き合いながら、どのようにあるべき姿を目指すべきかというエッセイです。本編の97のエッセイを読んだ後に読むのが良さそうです。

おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。

私は本来「アーティスト」としてのプログラミングが大好きで、自己顕示欲を満たすために行動しています。あまり知られていない問題をちょっとおかしなやり方で解決して、自分の尊敬する人に自慢するためにプログラミングしたいのです。

プログラマの本能がストレートに書かれていて、クスッときました。共感できる人も多いのではないでしょうか。1つ前の「良いプログラマになるには」に書かれている内容ともオーバーラップします。

あなたはお仕事中、9 時から 18 時までの間だけあなたのチームの「理想のプログラマ」の役を演じます。自分の技量を超えたプログラミングを演技することはできませんが、より重要な立ち振る舞いについてなら演技できそうです。あなたの想像する「理想のプログラマ」だったら今この局面でどう振る舞うだろう、この問題に気づいたらどうするだろう、同僚のあの態度に対してどう発言するだろうと想像しながら「理想のプログラマ」を演じるわけです。

技量の演技はできなくても、立ち振る舞いなら演技できる、ということで日々の業務にも少しづつ取り入れています。本文にもあるように仕事ですからね。

プログラマが持つべき3つのスキル by 吉岡弘隆

プログラマが持つべきスキルとそれをどのように獲得するか、が書かれているエッセイです。

プログラマが持っておくべきスキルというのはいろいろありますが、あえて 3 つあげるとすれば、(1)コードを読むスキル、(2)テストをするスキル、(3)デバッグをするスキル、だと考えます。

そして、このスキルは知識の獲得と違ってインターネットの情報を読むだけでは身につきません。実際に体を動かして試行錯誤をして、時には失敗をして獲得していかないといけないのです。残念ながら、それぞれについて体系的に記述した参考書もほとんどありません。大学でも教えてくれません。ソフトウェア開発の現場で経験を積むしかないのが現状です。

この部分、本当に共感できます。異動する前に評判の良いテキストで学んでみたり、ちょっとしたものをいくつか作ってみたりしましたが、やはり現場の感覚というのは分かりづらかったです（それがこの本を読むモチベーションにも繋がる訳ですが）。

それでは、どのようにして、それぞれのスキルを身につけていけばいいのでしょうか。理想的には、職場に師匠となる人をみつけてその人の弟子になることです。しかし、現実には、そのようなことはなかなか難しいかと思います。そこでオープンソースソフトウェア（OSS）です。定番の OSS には師匠となるべきカリスマプログラマがいます。開発メーリングリストを購読すれば、ソフトウェアのバグや新機能の仕様について議論していることを見聞きできます。

その問題に対して、OSSという解答が挙げられています。言われてみれば、一人で趣味の開発をするよりも、強制的に複数人数で機能の追加・改修を行うOSSの方が実務に近いですね。また、コントリビューションするとなると、ハードルが低いとは言えないかもしれませんが、覗く分にはタダです。いつかは関わってみたいと思いつつ、遠い世界だと考えいたので目から鱗でした。

別のエッセイ、「オープンソースプロジェクトで夢を実現する」とも重なる部分があります。

そういえば弊社ブログにもこんなエントリがありましたね。