『プリンシプル オブ プログラミング』前提編を10問で学べるクイズサイト

AI時代の前提知識をクイズで速習！
プリンシプル オブ プログラミング 第1章：前提

公開日：
最終更新日：

AIがコードを書いてくれる時代でも、品質を左右するのは「前提（何が真実で、何が変わらないか）」です。本ページでは、『プリンシプル オブ プログラミング』第1章「前提」で語られる「プログラミングの変わらない3つの事実」を、要点を押さえた要約と4択クイズで整理します。

要約で全体像をつかみ → 4択クイズ（10問・全問解説付き）で腕試し → 迷ったところは解説で復習。「読む→解く→わかる」のサイクルで、AIに振り回されない学習と設計の土台をしっかり固めましょう。

今すぐクイズに挑戦
（10問・約3分・解説つき）
プリンシプルオブプログラミング
AI時代を生き抜く「101の設計原則」

第1章：AI時代の「前提」をクイズで速習！ 目次

  1. 第1章：AI時代の「前提」をクイズで速習！の要点・要約を読む(5分)
    1. 1.1 プログラミングに銀の弾丸はない（No Silver Bullet）
    2. 1.2 コードは設計書である（Code as design）
    3. 1.3 コードは必ず変更される（Code will be changed）
  2. クイズに挑戦する(10問)
  1. プログラミング クイズ一覧へ
  2. 次のクイズへ(第2章：AIコードを見抜く「原則」クイズ！)
  3. 前のクイズへ(第7章：AIでは制御できない「法則」クイズ！)
  4. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第１章：前提
～プログラミングの変わらぬ真実～

1.1 プログラミングに銀の弾丸はない（No Silver Bullet）

  • 要旨

    ソフトウェア（コンピュータの中で動くプログラム）開発に、「これさえ使えば全部解決」という魔法の方法（銀の弾丸）はない。

  • 理由

    ソフトウェアには、どうしても消せない４つの「難しさ」があるから。
    • 複雑性：関わる人や機能が多く、考えることがごちゃごちゃしやすい。
    • 同調整：現実の世界やルールが変わり続けるので、それに合わせてシステムも変え続けないといけない。
    • 可変性：使う人の要望や使う環境（スマホ／PC／クラウドなど）が変わると、そのたびにコードを書き直す必要がある。
    • 不可視性：建物とは違い「形」が見えず、画面の裏側の考え方や決定の履歴が、ぱっと見では分かりにくい。

  • 結論

    「銀の弾丸はない」と理解し、難しさそのものを消そうとするのではなく、少しずつ改善できる部分（設計の工夫・開発プロセス・ツールなど）を良くしていく。本当に解くべき問題に、時間とエネルギーを使えるようにする。

  • その他（行動指針）

    • 本質的な複雑さ(どうしてもなくせない難しさから)からは、目をそらさずに向き合う。
    • 偶有的な複雑さ(人や仕組みのせいで増えた難しさ)は、チームで話し合い、仕組みやルール変えることをで少しずつ減らしていく。

  • 💡AIワンポイント

    銀の弾丸を探すより、生成結果の差分レビューを短い周期で回す方が効きます。大きな一発修正より、関数単位で直してテストを刻んでください。

1.2 コードは設計書である（Code as design）

  • 要旨

    コード（プログラムの文章）は、そのまま設計図（どう作るかを書いたもの）でもある。

  • 理由

    「基本設計 → 詳細設計 → プログラミング → テスト → デバッグ」という一連の流れ全体が設計と考えられる。そして最後に手元に残るのは、設計書でもありプログラムでもあるコードだけだから。動くコードを読むと、「どんな考えで作られたか（設計）」が分かる。

  • 結論

    プログラミング ＝ 設計だと意識し、メンバー全員が「仕様（こう動いてほしいという決めごと）づくり〜実装」まで考えて行動する。できるだけ早くコードを書いて動かし、テスト（ちゃんと動くか確認する作業）を通してアイデアの良し悪しを確かめる。なぜその書き方にしたのか（Why）は、コメントや設計メモ（ドキュメント）に短く残しておく。

  • その他（実践ポイント）

    • まずは小さく動くものを作り、試す → 直す → また試すというフィードバックループ（改善をくり返す流れ）を何度も回す。
    • 「後から読む人」を意識して、コードとコメントに理由を書く。将来の自分も「別人」だと思ってコメントで説明しておく。

  • 💡AIワンポイント

    設計案をAIに文章で作らせたら、同じ場で最小の実装スケッチまで出させて挙動で確定させます。理由はPR本文に残し、次の変更時に参照できる形にします。

1.3 コードは必ず変更される（Code will be changed）

AIで差が出る ★★★★★AI核心原則

  • 要旨

    コードは一度書いて終わりではない。あとから何度も変更されるのが普通である。

  • 理由

    仕様変更（「こう動いてほしい」が変わること）・バグ修正・新機能の追加が必ず起こり、サービスが使われ続ける限り、コードも変わり続けるから。また、世の中の状況や技術も変化するので、「完全に作り切って終わり」という状態にはなりにくい。

  • 結論

    「コードはいずれ変わる」と最初から分かったうえで、モジュール同士をできるだけ疎結合に保ちつつ、変更に強いコードを書く。特に大事なのは読みやすさ。読みやすいコードは、理解しやすく、安心して直しやすい。

  • その他（変更に強くするコツ）

    • 関数名や変数名に、「何をしているか」が想像しやすい日本語や英単語を選ぶ。
    • １つの関数に役割を詰め込みすぎず、１つの関数＝１つの仕事に近づける。
    • モジュール同士のつながりを必要最小限にして、変更の影響が広がりにくい疎結合な構造を意識する。
    • 自動テスト（プログラムで行うテスト）を書いて、変更しても動作が変わっていないかチェックできるようにする。

  • 💡AIワンポイント

    変更前提なら、AIへの依頼単位を小さな責務に分けるのが安全です。命名変更とロジック変更を同時にさせず、コミットを分離すると戻しやすくなります。AIは正常系だけ通して満足しやすいので、変更時は失敗系の回帰確認を先に置きます。

プリンシプル オブ プログラミング(第１章：前提)

1. 【1.2．コードは設計書である⑤】
「プログラマは設計全体を担う存在である」とされる背景として最も適切なものはどれか？

2. 【1.1．プログラミングに銀の弾丸はない①】
ソフトウェア開発において「銀の弾丸はない」とされる理由として最も適切なものはどれか？

3. 【1.1．プログラミングに銀の弾丸はない②】
次のうち、「本質的な複雑性」として誤っているものはどれか？

4. 【1.2．コードは設計書である①】
「コードは設計書である」とされる主な理由は何か？

5. 【1.2．コードは設計書である②】
「プログラミングは設計そのものである」とされる理由として適切なものはどれか？

6. 【1.3．コードは必ず変更される⑤】
変更を前提にした設計原則として、最も本質的なものはどれか？

7. 【1.1．プログラミングに銀の弾丸はない③】
次のうち、「偶有的な複雑性」の例として最も適切なものはどれか？

8. 【1.3．コードは必ず変更される①】
「コードは必ず変更される」という前提に立つとき、最も避けるべき設計姿勢はどれか？

9. 【1.3．コードは必ず変更される④】
「完璧に見えるコードでも将来は必ず変わる」という原則に基づき、開発初期から意識すべきことはどれか？

10. 【1.2．コードは設計書である④】
コードが設計書である以上、特に補足すべき内容は何か？

次のクイズ(第2章：AIコードを見抜く「原則」クイズ！)へ

第１章：前提
採点結果

正答率：0%

-

-

参考文献・出典

  • プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
  • 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん（システムエンジニア）

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験：Webアプリ／業務システム

得意：PHP・JavaScript・MySQL・CSS

個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等

詳しいプロフィールはこちら！　　もちもちみかんのプロフィール

もちもちみかん0系くん
TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
　もちもちみかん.forms
　もちもちみかん.css1
　もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます！