AI時代の前提知識をクイズで速習!
プリンシプル オブ プログラミング 第1章:前提
公開日:
最終更新日:
AIがコードを書いてくれる時代でも、品質を左右するのは「前提(何が真実で、何が変わらないか)」です。本ページでは、『プリンシプル オブ プログラミング』第1章「前提」で語られる「プログラミングの変わらない3つの事実」を、要点を押さえた要約と4択クイズで整理します。
要約で全体像をつかみ → 4択クイズ(10問・全問解説付き)で腕試し → 迷ったところは解説で復習。「読む→解く→わかる」のサイクルで、AIに振り回されない学習と設計の土台をしっかり固めましょう。
第1章:AI時代の「前提」をクイズで速習! 目次
- プログラミング クイズ一覧へ
- 次のクイズへ(第2章:AIコードを見抜く「原則」クイズ!)
- 前のクイズへ(第7章:AIでは制御できない「法則」クイズ!)
- 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
第1章:前提
~プログラミングの変わらぬ真実~
1.1 プログラミングに銀の弾丸はない(No Silver Bullet)
要旨
ソフトウェア(コンピュータの中で動くプログラム)開発に、「これさえ使えば全部解決」という魔法の方法(銀の弾丸)はない。理由
ソフトウェアには、どうしても消せない4つの「難しさ」があるから。- 複雑性:関わる人や機能が多く、考えることがごちゃごちゃしやすい。
- 同調整:現実の世界やルールが変わり続けるので、それに合わせてシステムも変え続けないといけない。
- 可変性:使う人の要望や使う環境(スマホ/PC/クラウドなど)が変わると、そのたびにコードを書き直す必要がある。
- 不可視性:建物とは違い「形」が見えず、画面の裏側の考え方や決定の履歴が、ぱっと見では分かりにくい。
結論
「銀の弾丸はない」と理解し、難しさそのものを消そうとするのではなく、少しずつ改善できる部分(設計の工夫・開発プロセス・ツールなど)を良くしていく。本当に解くべき問題に、時間とエネルギーを使えるようにする。その他(行動指針)
- 本質的な複雑さ(どうしてもなくせない難しさから)からは、目をそらさずに向き合う。
- 偶有的な複雑さ(人や仕組みのせいで増えた難しさ)は、チームで話し合い、仕組みやルール変えることをで少しずつ減らしていく。
💡AIワンポイント
関連用語(用語集で復習)
1.2 コードは設計書である(Code as design)
要旨
コード(プログラムの文章)は、そのまま設計図(どう作るかを書いたもの)でもある。理由
「基本設計 → 詳細設計 → プログラミング → テスト → デバッグ」という一連の流れ全体が設計と考えられる。そして最後に手元に残るのは、設計書でもありプログラムでもあるコードだけだから。動くコードを読むと、「どんな考えで作られたか(設計)」が分かる。結論
プログラミング = 設計だと意識し、メンバー全員が「仕様(こう動いてほしいという決めごと)づくり〜実装」まで考えて行動する。できるだけ早くコードを書いて動かし、テスト(ちゃんと動くか確認する作業)を通してアイデアの良し悪しを確かめる。なぜその書き方にしたのか(Why)は、コメントや設計メモ(ドキュメント)に短く残しておく。その他(実践ポイント)
- まずは小さく動くものを作り、試す → 直す → また試すというフィードバックループ(改善をくり返す流れ)を何度も回す。
- 「後から読む人」を意識して、コードとコメントに理由を書く。将来の自分も「別人」だと思ってコメントで説明しておく。
💡AIワンポイント
設計案をAIに文章で作らせたら、同じ場で最小の実装スケッチまで出させて挙動で確定させます。理由はPR本文に残し、次の変更時に参照できる形にします。関連用語(用語集で復習)
1.3 コードは必ず変更される(Code will be changed)
AIで差が出る ★★★★★AI核心原則
要旨
コードは一度書いて終わりではない。あとから何度も変更されるのが普通である。理由
仕様変更(「こう動いてほしい」が変わること)・バグ修正・新機能の追加が必ず起こり、サービスが使われ続ける限り、コードも変わり続けるから。また、世の中の状況や技術も変化するので、「完全に作り切って終わり」という状態にはなりにくい。結論
「コードはいずれ変わる」と最初から分かったうえで、モジュール同士をできるだけ疎結合に保ちつつ、変更に強いコードを書く。特に大事なのは読みやすさ。読みやすいコードは、理解しやすく、安心して直しやすい。その他(変更に強くするコツ)
- 関数名や変数名に、「何をしているか」が想像しやすい日本語や英単語を選ぶ。
- 1つの関数に役割を詰め込みすぎず、1つの関数=1つの仕事に近づける。
- モジュール同士のつながりを必要最小限にして、変更の影響が広がりにくい疎結合な構造を意識する。
- 自動テスト(プログラムで行うテスト)を書いて、変更しても動作が変わっていないかチェックできるようにする。
💡AIワンポイント
変更前提なら、AIへの依頼単位を小さな責務に分けるのが安全です。命名変更とロジック変更を同時にさせず、コミットを分離すると戻しやすくなります。AIは正常系だけ通して満足しやすいので、変更時は失敗系の回帰確認を先に置きます。関連用語(用語集で復習)
プリンシプル オブ プログラミング(第1章:前提)
1. 【1.2.コードは設計書である③】
解説: 動くコードによってこそ設計の妥当性が確かめられるため、できるだけ早期にコードを書き始めて検証と改善のサイクルを回すことが望ましい。
2. 【1.2.コードは設計書である⑤】
「プログラマは設計全体を担う存在である」とされる背景として最も適切なものはどれか?
解説: プログラマは単に指示通りにコードを書くのではなく、詳細設計や意図を理解しながら判断・実装する設計者としての責任を担うべき存在である。
3. 【1.1.プログラミングに銀の弾丸はない①】
ソフトウェア開発において「銀の弾丸はない」とされる理由として最も適切なものはどれか?
解説: 解説:ソフトウェアは『複雑性』『同調性』『可変性』『不可視性』といった本質的な複雑性を内包しており、それらを完全に排除することはできない。ゆえに、万能な技術(銀の弾丸)は存在しないとされている。
4. 【1.3.コードは必ず変更される①】
「コードは必ず変更される」という前提に立つとき、最も避けるべき設計姿勢はどれか?
解説: 一時的な正しさだけを優先して設計すると、将来の変更に弱くなる。「いずれ変わる」ことを前提に、変更のしやすさを重視した設計が必要である。
5. 【1.1.プログラミングに銀の弾丸はない②】
次のうち、「本質的な複雑性」として誤っているものはどれか?
解説: 「可変性」は、ソフトウェアが要求や環境の変化に応じて常に修正・進化する宿命にあることを指す。変化を避けるべき、という記述は誤りであり、「固定された仕様」は現実的ではない。
6. 【1.1.プログラミングに銀の弾丸はない⑤】
「本質的な複雑性に向き合い、偶有的な複雑性を克服する」という姿勢が重視される理由として最も適切なものはどれか?
解説: ソフトウェアにおいて、本質的な複雑性は不可避であるが、偶有的な複雑性(設計の甘さ・非効率など)は努力と改善で克服できるため、両者を区別した正しい姿勢が重要である。
7. 【1.3.コードは必ず変更される②】
将来の変更に備えた設計として、特に有効とされる考え方はどれか?
解説: 将来的にコードを読むのは他者(もしくは未来の自分)であるため、「なぜこう書いたのか」が自然に伝わるような構造と命名が重要である。
8. 【1.3.コードは必ず変更される③】
以下のうち、読みやすさを確保することで「変更に強くなる」理由として最も適切なものはどれか?
解説: 変更作業は理解から始まるため、コードが読みやすければ影響箇所や依存関係が素早く把握でき、誤修正のリスクも減らせる。
9. 【1.1.プログラミングに銀の弾丸はない③】
次のうち、「偶有的な複雑性」の例として最も適切なものはどれか?
解説: 「偶有的な複雑性」は本質的ではなく、開発体制や設計の問題によって発生する複雑さ。スキル不足や設計のまずさはこれにあたる。他の選択肢は、いずれも「本質的な複雑性」に該当する。
10. 【1.1.プログラミングに銀の弾丸はない④】
ソフトウェア開発における最も健全な姿勢として適切なものはどれか?
解説: ソフトウェア開発では、「本質的な複雑性」に正面から向き合い、「偶有的な複雑性」は地道な設計・技術努力で乗り越える姿勢が重要である。
参考文献・出典
- プリンシプル オブ プログラミング ~3年目までに身につけたい一生役立つ101の原理原則~
- 上田 勲(著)/秀和システム/第1版14刷/2025年/ISBN978-4-7980-4614-3
※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。
このサイトの運営者
経験:Webアプリ・業務システム
得意:PHP・JavaScript・MySQL・CSS
制作・運用中:フォーム生成基盤・クイズ学習プラットフォーム・htmx逆引きレシピ 等
AI時代のエンジニアタイプ診断:CSPF/とろとろみかん
詳しいプロフィールはこちら! もちもちみかんのプロフィール