『プログラマが知るべき97のこと』に学ぶ5つの金科玉条

最終更新日: 2024年12月17日(火)

1. ご挨拶
2. 今回のトピック
3. 『プログラマが知るべき97のこと』に学ぶ5つの金科玉条
4. 最後に
5. 参考資料

1. ご挨拶

こんにちは。前回の「GitHub Actions で Working out Loud を効率化しよう！」から2ヶ月ぶりの投稿になります、@hayat01sh1da です。
ソフトウェアエンジニアとして、以下のサービスの進路・学事向け機能(e.g. アンケート配信機能、進路希望調査配信機能、面談ダッシュボード)を開発・運用・保守しています(forSCHOOL ブランドは先生の管理画面である「先生アプリ」の開発に従事)。

すっかり寒くなりましたね。
冬になり、周囲では風邪も流行り始め、会議中も喉がやられて声を出すのが辛そうなメンバーも散見されるようになりました。
皆様もくれぐれもお身体にお気をつけ下さい。

そんな寒い中ですが、私は先日都立小金井公園にて会社の部活動で BBQ を楽しんできました！
15時頃から急激に気温が下がり冷え込みましたが、良い天気でお肉も日本酒を使ったチーズフォンデュも美味しくて、最高でした。

2. 今回のトピック

とある休日、映画とプラネタリウムをはしごする合間に某書店に立ち寄り、技術書コーナーで本を物色して時間を潰していました。
その中で一際私の目を惹いたのが『プログラマが知るべき97のこと』(以下、同書)でした(後にオンライン上で無料で読めることを知りました)。
同書の内容には、普段の仕事で意識しているものの、上手く言語化できていなかった概念や、それまでの自分にはなかった着眼点や発想など、新たな学びとなる要素が含まれていました。
さすが有名な著書というだけあって、刺さる格言が数多くありました。

97(海外出身エンジニア) + 10(日本人エンジニア) = 107個の格言の中でとりわけ改めて自らの意識や行動を見つめ直し、変容するきっかけとなった教訓を、私の独断と偏見と好奇で5つ厳選して紹介させて頂きます。

3. 『プログラマが知るべき97のこと』に学ぶ5つの金科玉条

3-1. 「003. ユーザーが何をするかを観察する(あなたはユーザーではない)」 by Giles Colborne(ジャイルズ・カルバン)

この教訓の論旨は「ユーザーが求めているものを正しく把握するには、彼らの言葉を聞いて頭の中でニーズの深掘り議論を1日するよりも、たった1時間でも彼らの行動を観察した方が得策である」ということです。

自社サービスの内製開発において、サービスの提供形態が B2B, B2C, B2B2C のいずれであってもペルソナやユースケースの設定・想定、ニーズの把握は必要不可欠な作業です。
その際、どのような手法で皆さんはとりわけユーザーのニーズを突き詰めておられるでしょうか？

自社サービスを業務システムとして利用している組織の場合は Dogfooding という手法がよく使われると思います。
自分たちで作ったサービスを自分たちで実際に業務フローの中で利用する仕組み、つまり「作り手 = ユーザー」という構造が成立する訳です。
この手法を使える場合、作り手である自分たちがユーザーでもある訳なので、(IT に精通していないユーザーとは視座がやや異なる可能性はありつつも)机上の空論ではないエンドユーザーの本当のニーズを突き詰めやすくなります。
また、自組織内でフィードバックサイクルをより速く回すことができ、それによってエンドユーザーへの価値提供もより粒度高く increment できることになります。
さらにエンドユーザーへのヒアリングで意見を吸い上げればニーズが製品・サービスにより精度高く反映されるでしょう。

一方で、この手法が使えない組織も世の中には多く存在します。
私が所属する組織もその一例で、ペルソナが高校1-3年生の高校生と先生方なので、作り手がその製品を実際の業務フローの一環で使うことはできません(できてもせいぜいデモやモックアップで触るくらいでしょう)。
その場合、私の組織の場合は渉外担当者(営業) → プランナー → テクニカル・プロダクト・マネージャー(TPM) → 開発者の流れでエンドユーザーのニーズが伝達されます。
組織規模にもよりますが、エンドユーザーと開発者の間に存在するステークホルダーが多ければ多いほど、いわゆる「生の声」を聞くことは難しくなります。
その結果、スプレッドシートに掲載されたエンドユーザーのニーズ一覧を眺めながらの議論に終始せざるを得ないことになります。
これ自体が悪いことではなく、製品・サービスの性格によって取り得るアプローチに限界があるということです。

幸いにして、私のチームは高校生の進路・学事関連の機能開発を行っている都合上、「学事同行」という自チームが開発した機能が実際の授業の中でどのように使われているかを視察させて頂く機会が設けられています。
私はまだ参加できていないのですが、「学事同行に参加しないと誰に向けて何を提供しているのか、そしてこれから何を提供していかなければいけないのか理解できませんよ」と言われました。
そのくらい、私が携わっているサービスはエンドユーザーの行動を観察して得る情報が必要不可欠なのだということですし、机上での議論にはやはり限界があるということの裏返しでもあると思います。

「学事同行」が推奨された後、同書に触れた際にいみじくもこの教訓が上記の意義の正鵠を射ていると感じたのでピックアップしました。
どの程度記事にできるかは分かりませんが、私も参加した暁にはその学びをできる範囲で公開したいと思います。

3-2. 「005. 美はシンプルさに宿る」 by Jørn Ølmheim(ヨルン・オルムハイム)

この教訓の論旨は、以下の3つの条件が満たされると「美しい」ということです。

どのクラス・メソッド・インスタンスが何をしているかが一目瞭然である可読性が担保されている
作りがシンプルであるが故にどこを直せば良いかの特定のしやすさがある保守性が担保されている
責務や最小限で部品同士の連結のしやすさがある開発効率性が担保されている

プロダクトコードを書く際に DRY(Don't Repeat Yourself) 原則や SOLID 原則を遵守することでコードをシンプルに保つことは、「美しい」という主観的な印象以上の多大なメリットを享受できるということです。
「何を今更当たり前のことを」と思う方もいらっしゃるかも知れませんが、ふと油断すると WET(Write Every Time) なコードを書いていたり、メソッドや関数の責務が偏りすぎた設計や実装をしていたり、複雑なビジネスロジックを複雑なまま実装に落とし込んでどのクラス・メソッド・インスタンスが何の役割を果たしているのかわからなくなってしまうことは往々にしてあると思っています。
私自身に経験があるので尚更そう感じるのかも知れませんが、「当たり前と思うことほど意識することをサボると当たり前にできなくなる」ことの卑近な一例ではないでしょうか。

皆さんも、「よくあんな複雑な要件や仕様をこれほどシンプルな設計と実装に落とし込めたなぁ」と、自分が書いたコードを見てニヤニヤしたり自己陶酔することはありませんか。
同書でも「美しい」は客観的でなく主観的である、と述べられているので、上述の行為は何ら恥ずべきことではなく、むしろ可読性・保守性・開発効率性があまねく担保された実装ができた証なので、むしろ誇るべきことではないでしょうか。

私の知る限り優秀な方々はどんなに複雑な議論でも実装でも、シンプルな部品の組み合わせに分解できる能力をお持ちで、それら部品同士の境界線がどこにあるかの勘所が非常に優れているように思います。

さらにこれは Git のコミットや GitHub の Pull Request(以下、PR) にも当てはまることだと考えます。
必要な密結合部分は残しつつ、それ以外は「意味のある最小単位」を意識してコミットや PR を作ることは、実装者だけではなく、それをレビューする第三者の労力削減にも大きく役立つことになります。
コードの読み手も、「意味のある最小単位」を意識して作られたコミットや PR 上のシンプルで美しいコードは読んでいて楽しいものです。

とても主観的な話かつ文脈が大きく変わりますが、この教訓は清潔かつ機能的な部屋はおしなべてシンプルであることにとてもよく似ていると思っています。
何がどこにあって何の機能を持つかが一目瞭然の可読性、余計なものを置かないので掃除がしやすいくてレイアウト変更にも耐えうる保守性など、置き換えて考えても通用する項目がほとんどです(開発効率性の例は浮かびませんでした)。

仕事の進め方以外にも広く適用可能であることと、当たり前なことほど重要であるという観点で、開発者として常に意識すべき大切な教えであると感じたためピックアップしました。

3-3. 「008. ボーイスカウト・ルール」 by Robert C. Martin(ロバート・C・マーティン)

この教訓の論旨は「来た時よりも綺麗に、というボーイスカウトのルールに則り、コーディングに関してモジュールチェックイン時よりも必ずチェックアウト時の方が綺麗な状態にしよう」ということです。

この発想はコーディングでもプロジェクト参画時でも重要で、後の人のことをどれだけ思いやれるかだと思います。
個人的な話になり恐縮ですが、私はこれに関してとある年次メンテナンスプロジェクトで大変苦い経験をしたことがあります。

そのプロジェクトは、申し送り事項はありながらもドキュメントやジョブが整理されておらず、深刻な属人性を抱えていました。
私自身ももっと楽をしたかったですし、次年度の担当者にはより良い仕組みを作ってもらいたい思いがあったので、「今年のうちに出来るだけカイゼンの叩き台を作ろう！」と決意しました。
手作業や目検チェックはできる限りジョブにして仕組み化をしつつ、作業フローやドメイン知識をドキュメンテーションという手段で明文化しました(その時に得た知見は「社内技術ドキュメンテーションを科学する」にまとめてあるのでよろしければ読んで下さると嬉しく思います)。
運用は年を追うごとに変わる可能性があるのでドキュメンテーションは銀の弾丸にはなり得ませんが、それでもとにかく明文化をすることで無駄を可視化し、逐次的に仕組み化が進んでいけば良い、という希望的観測のもとの行動でした。

仕組み化 + ドキュメンテーションでボーイスカウト・ルール自体は守れたと思います。
しかしながら、完璧主義と負の感情に駆られ、ROI(投資対効果) が完全に意識から抜けていた、もしくは無視していたと回想します。
最小のリソースで最大限の効果を得られる行動を取ることもまた、お金を頂いてプロとして仕事をする上で重要なことだと反省しています。
まだまだ改善の余地有りですが、当時よりは「これはやる価値があるのか？」「費やすリソースと得られるメリットの損益分岐点はどこにあるのか？」「どの程度のコストを割くべきなのか？」「今すぐにやるべきなのか、後回しでも良いのか？」を自問自答するようになりました。

この経験を通し、ボーイスカウト・ルールでは以下の3点を強く意識する必要があると学びました。

自分自身が感じた「不」(不便・不都合など個人レベルの問題)や「負」(負債など組織的な問題)は後から参画する人にはなるべく残さないように行動すること。
リソースは有限なので、すべきこと・する必要のないことを決めること。
すべきことの中でも重要度・緊急度に応じてどの程度のリソースを投入するかの緩急をつけること。

「他人を思いやるとともに組織・技術的負債を decrement する」ためのボーイスカウト・ルールの遵守は大切だと思う一方で、「それは常に ROI というトレードオフが付きまとう」という一言を添えたいがためにピックアップしました。

3-4. 「066. いったんコンピューターから離れてみる」 by Burk Hufnagel(バーク・ハフネーゲル)

この教訓の論旨は「理論を司る左脳をずっと働かせることに時間を費やすことを一旦止めて、創造性を司る右脳にスイッチする時間を設ける方が良いアイデアを思いつくものだ」ということです。

これは創造性や理論が必要とされる仕事に従事している方であれば、誰もが経験があるかと思います。
私自身は、シャワーを浴びている時、そろそろ寝るかと布団に入った時にアイデアが降ってくることが多いです。
交感神経優位で左脳がずっと働いている時は1つのエラーハンドリングや適切なクラス・メソッド・インターフェース(以下、I/F) の設計で行き詰まって堂々巡りになることが多いのですが、そこから離れ休息モードになって副交感神経が優位になった時に右脳が閃きを与えてくれることが往々にしてあります。

同書に「036. ハードワークは報われない by Olive Maudal(オルヴ・モーダル)」という格言があります。
論旨は「仕事は限られた時間の中で集中して成果を出すための効率性を追求しよう」ということですが、「緩急をつけて作業しよう」とも解釈できます。
人間のフロー状態(超集中状態)は30分、集中状態は90分(大学の講義時間の理由らしいです)が限界だと言われています。
集中時は目標のみにフォーカスするため、その間は他のことが「お留守」で無防備になります。
狩猟採集民族時代はそれが命取りなため、それを回避するための本能ということらしいです。
よって、集中の「深さ」は訓練できても「長さ」はどうにもならないそうです。

ならば、この人間としての限界に無理に抗わず、むしろそれとうまく緩急をつけて付き合う方が賢明と言えます。
リラックスモードの時に良いアイデアが降ってくると何だか得した気分になれますし、反対にどんなに一生懸命集中しても良いアイデアが全く浮かばない時は凹んでしまいます。
私はリラックスが下手くそな人間なので、意識的に副交感神経が優位になる環境を作りたいと思います。

「いったんコンピューターから離れてみることで、良いアイデアが降ってきた経験をした人は沢山いそうだな」という理由でピックアップしました。

3-5. 「107. 名前重要」 by まつもとゆきひろ(Matz)

この教訓の論旨は「命名の適切さは、その機能がどの程度正しく理解・設計されたかの指標である」ということです。

この章で、Matz 氏は Ruby の機能追加において「要求は理解したしそれによるメリットも理解できるが、命名が適切でないために却下した」と述べています。
それほど、命名が大事だということを Ruby という素晴らしい言語の生みの親が仰っているのです。

命名が適切であることによるメリットは意外と看過されがちですが、不適切であるがゆえに被る以下のようなデメリットに関しては皆さんもご経験があるのではないでしょうか。

処理内容に対するメソッドの命名が杜撰なため、カプセル化されると外側から見た振舞いを命名から推測できない
不適切な命名を直したいが、呼び出し箇所が多すぎてデグレデーションの影響範囲が計り知れないため修正できない

命名に際しては、以下の3つを考慮に入れる必要があるのではないでしょうか。

文法・語法の観点で誤りがないかを辞書を参照して必ず確認する。自動詞・他動詞の区別、主語・目的語に人が来るか無生物が来るかなど、調べればすぐに解決するが、おざなりにするとそれが広く使われた際には修正が容易に利かなくなるため夙に芽を摘んでおく。
英語にそこまで精通していなくても分かるような一般的な語彙を使って命名する。よくあるクラス名・メソッド名・エンドポイント・機能名のコロケーションはまずは英語圏のサービスの中で最も近いユースケースから選ぶのが確実である。
命名は出来るだけ具体的に。抽象的な場合は色んな処理が一緒くたになっている不適当な設計である可能性があるため、具体的な命名がレベルまで「意味のある最小単位」に分解・抽出する。

一言でまとめると、クラスやメソッドの場合は「一目でそれが何の状態を保持し、どのような振る舞いをするか」、I/F であれば「一目でそれがどのようなユースケースで呼ばれ、何のデータを返却・更新・削除するか」が名前から一目瞭然であることが必要条件であると解釈できると思います。
否であれば、そもそも理解や設計が正しくされていない機能である、と言えそうです。

命名問題は最も頻繁に遭遇する機会が多いですが、永遠の難しい課題であるという認識があるため、改めてその重要性を意識するためにピックアップしました。

4. 最後に

いかがだったでしょうか？
本記事で取り上げた5つの金科玉条以外にも多くの重要な格言が同書には掲載されています。
まだ読んだことがない方は是非一度通読されることを強くお勧めします。
私自身も引き続きインプットとアウトプットの両輪を回しながら知見に血を通わせて、ソフト・ハードスキルともに向上させていきたいと思います。

次回は「GitHub Wiki 整理術 -スクリプト言語・シェル言語・GitHub Actions の活用録-(仮)」をお届けします(アドベントカレンダーには間に合わないかも知れません)。
それではまた！