AIに優しい開発習慣をクイズで身につける!
プリンシプル オブ プログラミング 第5章:習慣
公開日:
最終更新日:
AIと共創するほど、最後に差が出るのは「習慣(毎日の当たり前)」です。本ページでは、『プリンシプル オブ プログラミング』第5章「習慣」で紹介される良いコードを書くための6つの開発習慣を、要点を押さえた要約と4択クイズで整理します。
要約で「続けるコツ」をつかみ → 4択クイズ(10問・全問解説付き)で理解度をチェック → 気になったところは解説で復習。「読む→解く→わかる」で、AIとの共創をスムーズにする人間側の型を業務に落とし込みましょう。
第5章:AIに優しい開発「習慣」クイズ! 目次
- プログラミング クイズ一覧へ
- 次のクイズへ(第6章:AIを使いこなす「手法」クイズ!)
- 前のクイズへ(第4章:AI駆動で迷わない設計の「視点」クイズ!)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第5章:習慣
~プログラマのルーティン~
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)
要旨
時期尚早な最適化(まだ必要ないのに速度だけ上げようとすること)は、かえってマイナスになりやすい。まずは良いコード(見通しがよく、変更箇所が局所化され、情報隠蔽されたコード)を書き、本当に必要になったときだけ、計測にもとづいて最適化する。理由
最適化には必ずトレードオフ(何かを得る代わりに何かを失う)があり、性能のために、読みやすさや保守性など大事な性質を失ってしまうことが多いから。結論
「測って → 直して → また測る」のサイクルで、本当のボトルネック(遅い原因の場所)を特定してから改善する。先に良い設計を整えておけば、後からのチューニングも限られた箇所だけ安全に適用できる。その他(範囲・手順・手段)
- 最適化の弊害
- 可読性の低下:最適化後のコードは、最適化前より読みづらくなりやすい。
- 品質の低下:読みづらいコードはバグを生みやすく、品質を下げる。
- 複雑性の増大:処理のつながりが複雑になり、結合度が上がって移植性(他環境への持ち運びやすさ)も落ちる。
- 保守の阻害:前提条件や「お約束」が増え、汎用性や拡張性が下がる。
- 環境間の競合:ある環境では速いけれど、別の環境では逆に遅くなる、ということが起きる。
- 作業量の増大:準備や検証が増え、結局は自分たちの仕事を増やしがち。
- まずは良いコード:情報隠蔽(内部の細かい部分を外から見せないこと)などの原則に沿って変更箇所を局所化しておけば、他の部分に影響を出さずに後から修正しやすくなる。
- コード以外の改善点:
- 鉄則(手順)
- ① 必要性を証明する(ユーザーからの指摘や、SLO(サービスの目標値)からのズレなど)。
- ② 実際に計測してボトルネックを特定する(「推測するな、計測せよ」)。
- ③ 見つけたボトルネックを最適化する(狭い範囲の修正にとどめる)。
- ④ 再計測して、本当に改善されたか確認する。
- ⑤ テストで、機能が壊れていないか(デグレードがないか)検証する。
- 手段:プロファイラ(どこに時間がかかっているかを調べるツール)を使う。例:Chrome のネットワーク/パフォーマンスタブなど。
- 最適化の弊害
💡AIワンポイント
性能チューニングでは、AI案の前提計測条件を固定します。ベンチの入力サイズと回数を揃えない比較は判断を誤らせます。関連用語(用語集で復習)
5.4 エゴレスプログラミング(Egoless programming)
要旨
エゴ(自分のプライド)をいったん横に置き、助言や指摘を歓迎して学ぶ姿勢を持つ。批評の対象は人ではなくコードとする。理由
防衛的な態度(「自分は悪くない」と守りに入ること)は、必要な改善を遠ざけてしまい、結果として品質を下げるから。結論
「十戒(エゴレスでいるための10の約束)」を心に置き、謙虚さと相手への尊重を忘れずに、継続的な改善を続ける。ただし、個性やセンスを完全に消してしまわないバランスも大切にする。その他(十戒)
- 自分も間違えることがあると素直に認める。
- 自分の書いたコード=自分そのものではないと理解する。
- 自分より上手(うわて)が必ずいることを受け入れる。
- 相談なしの全面書き直しはしない(相手の意図を聞いてから進める)。
- 自分より経験の少ない人にも敬意と忍耐を持って接する。
- 唯一変わらないのは変化そのものだと理解する。
- 本当の権威(信頼される存在)は、地位や役職ではなく知識と実績から生まれる。
- 大事だと思う点ではきちんと自分の意見を主張するが、議論に負けたときは潔く結果を受け入れる。
- 一人で部屋にこもりきりにならず、チームとコミュニケーションを取る。
- 人にはやさしく、コードにはきびしく。批評の対象は人ではなくコードであることを忘れない。
💡AIワンポイント
エゴレスの観点で、AIレビュー結果は人ではなく差分へ向けます。人格評価を排し、再現可能な指摘形式へ統一してください。関連用語(用語集で復習)
5.5 1歩ずつ少しずつ(One by One)
要旨
小さな作業を1つずつ行い、「確認してOKなら、次へ」のサイクルをくり返す(ステップ・バイ・ステップの考え方)。理由
大きな一歩をドンと踏み出すよりも、小さく確実な前進を積み重ねるほうが、最終的には品質も時間効率も良くなるから。結論
実装も思考も段階を刻んで進める。論理的なステップを順番に積み上げ、各ステップをできるだけ速く、かつ確実に終わらせる。その他(思考のコツ)
- いきなり正解を瞬時に出そうとしない。分からなくても、焦らず考え続ける。
- すぐに1つの結論へ飛びつかない。一度その結論を疑って、他の可能性も検討する。
- すでに考えたことをメモして覚えておく(同じところをぐるぐる考え続けない)。
- 書きながら考える(紙やホワイトボードなどに書き出すと、頭の中が整理される)。
- 直感もヒントとして使い、まず試してみる。ただし直感だけで決めず、あとで論理的にチェックする。
💡AIワンポイント
1歩ずつ進めるなら、AI作業も小タスク化して都度テストします。途中で逸れた時に、どの変更が原因か即特定できます。関連用語(用語集で復習)
5.6 TMTOWDI(There's more than one way to do it.)
要旨
1つの目的を達成する方法は、たいてい1つではない。できるだけ複数のやり方を用意して考える。理由
対象となるシステムも要件(求められる条件)もさまざまで、それに合わせて解き方も多様になるから。結論
与えられた指示や、今あるやり方だけをそのまま受け取るのではなく、別のやり方やもっと楽で安全な方法がないかを、いつも意識して探す。その他(指針・効果)
- まず、制約や評価基準(性能/可読性/保守性/コストなど)をはっきりさせてから、複数の案を比較する。
- プロトタイピング(試作)やスパイク(短時間の実験的実装)で、リスクの確認と学びを前倒しにする。
- その結果として、より適切で、長く使い続けられる解決策を選びやすくなる。
💡AIワンポイント
関連用語(用語集で復習)
プリンシプル オブ プログラミング(第5章:習慣)
1. 【5.2.ボーイスカウトの規則⑦】
解説: 日々の小さな改善の積み重ねが、コード全体の品質向上と保守性の向上をもたらす。
2. 【5.1.プログラマの3大美徳⑩】
プログラマの美徳としての「傲慢」の説明として最も正しいものはどれか?
解説: 「傲慢」はネガティブな意味ではなく、自分のコードに誇りを持ち、美しく保とうとする姿勢を評価する言葉である。
3. 【5.2.ボーイスカウトの規則⑩】
「不適切だと分かった時点で対処すべき」とされる理由として最も妥当なのはどれか?
解説: 不適切な状態を放置すると、依存関係や修正困難な状態が積み重なり、全体の保守性を大きく損なう。
4. 【5.5.1歩ずつ少しずつ②】
論理的思考において「すぐに結論に飛びつかない」理由として適切なものはどれか?
解説: 結論を急ぐと、他の重要な選択肢を見逃す恐れがあるため、慎重に思考する必要がある。
5. 【5.5.1歩ずつ少しずつ⑥】
論理的思考を阻害する最もありがちな誤りはどれか?
解説: すぐに正解を求める姿勢は思考のプロセスを省略し、誤解や誤答につながる危険がある。
6. 【5.5.1歩ずつ少しずつ⑨】
次のうち、「考えの積み上げ」ができていない人の特徴として最も適切なのはどれか?
解説: 直感だけで答えを出す人は、考えの積み上げをせず、ミスに気づけない危険性がある。
7. 【5.3.パフォーマンスチューニングの箴言②】
性急な最適化によって失われがちな「本来重要な何か」として最も適切なものはどれか?
解説: 最適化によってコードは複雑化しやすく、結果として読みやすさ・保守性・構造の明快さを犠牲にしがちである。
8. 【5.4.エゴレスプログラミング①】
エゴレスプログラミングにおける最も基本的な姿勢として適切なものはどれか?
解説: 「自分も間違う」ことを認める謙虚さこそがエゴレスプログラミングの出発点である。
9. 【5.1.プログラマの3大美徳①】
プログラマにとって「怠惰」が美徳とされる理由として最も適切なのはどれか?
解説: 「怠惰」は人間の手間を惜しむ気質を指し、これにより繰り返し作業を自動化・仕組み化する姿勢が評価される。
10. 【5.4.エゴレスプログラミング⑨】
「エゴを完全に捨てるとチームに貢献できなくなることがある」とされる理由は何か?
解説: エゴの完全排除は自己否定につながり、結果として主体性や創造性を失いかねないため、バランスが必要である。
参考文献・出典
- プリンシプル オブ プログラミング ~3年目までに身につけたい一生役立つ101の原理原則~
- 上田 勲(著)/秀和システム/第1版14刷/2025年/ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このサイトの運営者
経験:Webアプリ・業務システム
得意:PHP・JavaScript・MySQL・CSS
制作・運用中:フォーム生成基盤・クイズ学習プラットフォーム・htmx逆引きレシピ 等
AI時代のエンジニアタイプ診断:CSPF/とろとろみかん
詳しいプロフィールはこちら! もちもちみかんのプロフィール