1. 【5.2．ボーイスカウトの規則①】
「ボーイスカウトの規則」における最も基本的な行動指針はどれか？
解説： 「ボーイスカウトの規則」は、触れたコードをより良い状態にして残すという考え方を示す。
AIに優しい開発習慣をクイズで身につける！
プリンシプル オブ プログラミング 第5章：習慣
公開日：
最終更新日：
AIと共創するほど、最後に差が出るのは「習慣（毎日の当たり前）」です。本ページでは、『プリンシプル オブ プログラミング』第5章「習慣」で紹介される良いコードを書くための6つの開発習慣を、要点を押さえた要約と4択クイズで整理します。
要約で「続けるコツ」をつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になったところは解説で復習。「読む→解く→わかる」で、AIとの共創をスムーズにする人間側の型を業務に落とし込みましょう。
第5章：AIに優しい開発「習慣」クイズ！ 目次
- プログラミング クイズ一覧へ
- 次のクイズへ(第6章：AIを使いこなす「手法」クイズ！)
- 前のクイズへ(第4章：AI駆動で迷わない設計の「視点」クイズ！)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第５章：習慣
～プログラマのルーティン～
5.1 プログラマの三大美徳（Three great virtues of programmer）
要旨
怠惰・短気・傲慢を、「ダメな性格」ではなく、手戻りや手作業を減らし品質を上げるための役に立つ性格として活かす。理由
「同じ作業のくり返し」や「ムダな作業」へのイヤさが、自動化（コンピュータにまかせること）・並列化（同時に動かすこと）・プロ意識（仕事への責任感）を生み、結果として全体の時間と手間を減らし、スループット（こなせる量）と品質を高めるから。結論
自分ががんばって身体を酷使するのではなく、しくみで楽をしてコンピュータに働いてもらい、誇りを持って人に見せられるコードを作る。頭脳労働でのムリな長時間労働は避ける。その他（詳細）
怠惰
全体の作業量を減らすためなら、最初に手間をかけることをいとわない性格。- 毎回くり返す作業をマクロ化（自動操作）・生成（自動で作ること）・ツール化（専用の道具にすること）して、自動化／仕組み化する。
短気
コンピュータがゆっくり動いたりサボったりするのがガマンできない性格＝コンピュータをできるだけ効率よく使おうとする姿勢。- 仕事を小さな単位に分けて同時実行し、CPUやサーバーなどの計算資源をフル活用してスループットを上げる。
傲慢
高いプライドで美しく分かりやすいコードや設計を求める性格。- プロ意識を持ち、「他の人に見られても恥ずかしくない」成果物を作ろうとする。
注意
「根性」や外からのプレッシャーだけでは、思考のスピードは上がらない。→ 長時間労働に頼らず、しくみや自動化で問題を解決することを目指す。
💡AIワンポイント
三大美徳の実践として、AIには繰り返し作業の自動化スクリプトを優先的に作らせます。手作業を減らすほどミスと疲労が下がります。
5.2 ボーイスカウトの規則（Boy Scout Rule）
要旨
一度さわったコードは、来たときより少しだけきれいにして戻す、という習慣を持つ。理由
コードはずっとメンテナンスされていくもので、最終的な真実はソースコード（実際のコードそのもの）にある。そこで、1回1回の小さな改善を積み重ねることで、全体の品質が底上げされていくから。結論
「自分が触る前よりも、ほんの少しでも良い状態」にしてからコミット（変更の確定）することを習慣にする。その他（指針）
- 急がば回れ
- ユニットテスト（小さなテスト）を省略するのは避ける：その場は早く見えても、あとで手動テストが増えたり、変更が怖くなって結果的に遅くなる。
- 目的に合わない既存システムのムリな流用は避ける：使い方が合っていないと、後で破綻（立ち行かなくなること）しやすい。
- 不適切なライブラリ（用途が合わない部品）の放置は避ける：コードが複雑になり保守も難しくなって、どこかで破綻する。
- 小さな改善例：分かりやすい命名に変える／同じ処理の重複を減らす／関数として切り出す／コメントを整える／テストを1つ足す、など。
- 効果：保守しやすさと信頼性の向上、バグの再発（デグレード）のリスク低減、チーム全体の学びやすさの促進。
- 急がば回れ
💡AIワンポイント
ボーイスカウト規則では、AIに触れた箇所の小改善を同時提案させます。命名修正や不要分岐削除を一緒に入れると腐敗を抑えられます。
5.3 パフォーマンスチューニングの箴言（Proverb of performance tuning）
要旨
時期尚早な最適化（まだ必要ないのに速度だけ上げようとすること）は、かえってマイナスになりやすい。まずは良いコード（見通しがよく、変更箇所が局所化され、情報隠蔽されたコード）を書き、本当に必要になったときだけ、計測にもとづいて最適化する。理由
最適化には必ずトレードオフ（何かを得る代わりに何かを失う）があり、性能のために、読みやすさや保守性など大事な性質を失ってしまうことが多いから。結論
「測って → 直して → また測る」のサイクルで、本当のボトルネック（遅い原因の場所）を特定してから改善する。先に良い設計を整えておけば、後からのチューニングも限られた箇所だけ安全に適用できる。その他（範囲・手順・手段）
- 最適化の弊害
- 可読性の低下：最適化後のコードは、最適化前より読みづらくなりやすい。
- 品質の低下：読みづらいコードはバグを生みやすく、品質を下げる。
- 複雑性の増大：処理のつながりが複雑になり、結合度が上がって移植性（他環境への持ち運びやすさ）も落ちる。
- 保守の阻害：前提条件や「お約束」が増え、汎用性や拡張性が下がる。
- 環境間の競合：ある環境では速いけれど、別の環境では逆に遅くなる、ということが起きる。
- 作業量の増大：準備や検証が増え、結局は自分たちの仕事を増やしがち。
- まずは良いコード：情報隠蔽（内部の細かい部分を外から見せないこと）などの原則に沿って変更箇所を局所化しておけば、他の部分に影響を出さずに後から修正しやすくなる。
- コード以外の改善点：
- 実行環境（サーバー・OSなど）
- デプロイ／インストール設定
- ミドルウェア（データベースやWebサーバーなど）
- ライブラリ
- 連携している他のシステム
- アーキテクチャ（全体の構造・設計方針）
- 鉄則（手順）
- ① 必要性を証明する（ユーザーからの指摘や、SLO（サービスの目標値）からのズレなど）。
- ② 実際に計測してボトルネックを特定する（「推測するな、計測せよ」）。
- ③ 見つけたボトルネックを最適化する（狭い範囲の修正にとどめる）。
- ④ 再計測して、本当に改善されたか確認する。
- ⑤ テストで、機能が壊れていないか（デグレードがないか）検証する。
- 手段：プロファイラ（どこに時間がかかっているかを調べるツール）を使う。例：Chrome のネットワーク/パフォーマンスタブなど。
- 最適化の弊害
💡AIワンポイント
性能チューニングでは、AI案の前提計測条件を固定します。ベンチの入力サイズと回数を揃えない比較は判断を誤らせます。
5.4 エゴレスプログラミング（Egoless programming）
要旨
エゴ（自分のプライド）をいったん横に置き、助言や指摘を歓迎して学ぶ姿勢を持つ。批評の対象は人ではなくコードとする。理由
防衛的な態度（「自分は悪くない」と守りに入ること）は、必要な改善を遠ざけてしまい、結果として品質を下げるから。結論
「十戒（エゴレスでいるための10の約束）」を心に置き、謙虚さと相手への尊重を忘れずに、継続的な改善を続ける。ただし、個性やセンスを完全に消してしまわないバランスも大切にする。その他（十戒）
- 自分も間違えることがあると素直に認める。
- 自分の書いたコード＝自分そのものではないと理解する。
- 自分より上手（うわて）が必ずいることを受け入れる。
- 相談なしの全面書き直しはしない（相手の意図を聞いてから進める）。
- 自分より経験の少ない人にも敬意と忍耐を持って接する。
- 唯一変わらないのは変化そのものだと理解する。
- 本当の権威（信頼される存在）は、地位や役職ではなく知識と実績から生まれる。
- 大事だと思う点ではきちんと自分の意見を主張するが、議論に負けたときは潔く結果を受け入れる。
- 一人で部屋にこもりきりにならず、チームとコミュニケーションを取る。
- 人にはやさしく、コードにはきびしく。批評の対象は人ではなくコードであることを忘れない。
💡AIワンポイント
エゴレスの観点で、AIレビュー結果は人ではなく差分へ向けます。人格評価を排し、再現可能な指摘形式へ統一してください。
5.5 １歩ずつ少しずつ（One by One）
要旨
小さな作業を1つずつ行い、「確認してOKなら、次へ」のサイクルをくり返す（ステップ・バイ・ステップの考え方）。理由
大きな一歩をドンと踏み出すよりも、小さく確実な前進を積み重ねるほうが、最終的には品質も時間効率も良くなるから。結論
実装も思考も段階を刻んで進める。論理的なステップを順番に積み上げ、各ステップをできるだけ速く、かつ確実に終わらせる。その他（思考のコツ）
- いきなり正解を瞬時に出そうとしない。分からなくても、焦らず考え続ける。
- すぐに1つの結論へ飛びつかない。一度その結論を疑って、他の可能性も検討する。
- すでに考えたことをメモして覚えておく（同じところをぐるぐる考え続けない）。
- 書きながら考える（紙やホワイトボードなどに書き出すと、頭の中が整理される）。
- 直感もヒントとして使い、まず試してみる。ただし直感だけで決めず、あとで論理的にチェックする。
💡AIワンポイント
1歩ずつ進めるなら、AI作業も小タスク化して都度テストします。途中で逸れた時に、どの変更が原因か即特定できます。
5.6 TMTOWDI（There's more than one way to do it.）
要旨
1つの目的を達成する方法は、たいてい1つではない。できるだけ複数のやり方を用意して考える。理由
対象となるシステムも要件（求められる条件）もさまざまで、それに合わせて解き方も多様になるから。結論
与えられた指示や、今あるやり方だけをそのまま受け取るのではなく、別のやり方やもっと楽で安全な方法がないかを、いつも意識して探す。その他（指針・効果）
- まず、制約や評価基準（性能／可読性／保守性／コストなど）をはっきりさせてから、複数の案を比較する。
- プロトタイピング（試作）やスパイク（短時間の実験的実装）で、リスクの確認と学びを前倒しにする。
- その結果として、より適切で、長く使い続けられる解決策を選びやすくなる。
💡AIワンポイント
TMTOWDIを活かして、AIに実装案を複数出させ評価軸で選びます。可読性と運用負荷を含めて比較すると短期最適を避けられます。
プリンシプル オブ プログラミング(第５章：習慣)
1. 【5.2．ボーイスカウトの規則①】
2. 【5.1．プログラマの３大美徳⑦】
「傲慢」なプログラマの態度としてふさわしくないものはどれか？
解説： 「傲慢」は誇りと責任を持ち、人に読まれる前提で丁寧なコードを書く姿勢を指す。「他人に読ませる気がない前提で書く」のはその反対であり不適切。
3. 【5.5．１歩ずつ少しずつ⑧】
「少しずつ」「丁寧に」進める姿勢が生み出す長期的な効果は何か？
解説： 着実な作業の積み重ねが、結果的に全体の品質と信頼性を高めることにつながる。
4. 【5.1．プログラマの３大美徳⑤】
次のうち「怠惰」の具体例として最も適切なものはどれか？
解説： 「怠惰」は「楽をするための努力」を意味し、自動化やスクリプト化によって作業効率を向上させる行為が当てはまる。
5. 【5.2．ボーイスカウトの規則④】
「急がば回れ」の精神が最もよく表れている考え方はどれか？
解説： 「急がば回れ」は、一見遠回りでも、丁寧な改善やテストが長期的に見て効率的であるという考え。
6. 【5.4．エゴレスプログラミング②】
「書いたコードは自分自身ではない」という言葉が意味する最も適切な考え方はどれか？
解説： コードへの批判は、人格への攻撃ではなく、品質向上のためのフィードバックであると捉えるべき。
7. 【5.3．パフォーマンスチューニングの箴言⑦】
パフォーマンスチューニングにおける「毒をもって毒を制す」という比喩が意味するのはどれか？
解説： 複雑なコードにさらに複雑な処理を加えることで一時的に性能を上げるが、構造的には悪化することが多い。
8. 【5.1．プログラマの３大美徳①】
プログラマにとって「怠惰」が美徳とされる理由として最も適切なのはどれか？
解説： 「怠惰」は人間の手間を惜しむ気質を指し、これにより繰り返し作業を自動化・仕組み化する姿勢が評価される。
9. 【5.2．ボーイスカウトの規則③】
「ユニットテストを省略すること」によって将来的に発生しやすい問題はどれか？
解説： ユニットテストを省略すると、自動検証ができず、将来的な変更時に手作業が増えて効率が悪化する。
10. 【5.5．１歩ずつ少しずつ⑩】
「確認→次へ」のリズムを守ることで得られる最大の利点はどれか？
解説： 各作業ごとに確認を行えば、早い段階で不具合を発見し、手戻りを最小限に抑えられる。
参考文献・出典
- プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
- 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このページの著者
もちもちみかん（システムエンジニア）
社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。
経験：Webアプリ／業務システム
得意：PHP・JavaScript・MySQL・CSS
個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等
詳しいプロフィールはこちら！ もちもちみかんのプロフィール
