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

プリンシプル オブ プログラミング
第１章：前提 要約＆クイズ

公開日：
最終更新日：

本ページでは、『プリンシプル オブ プログラミング』第1章「前提」で語られる「プログラミングの変わらない３つの事実」について、要点を押さえた要約と4択クイズで整理します。

要約で全体像をつかみ → 4択クイズ（10問・全問解説付き）で理解度をチェック → 気になった箇所は解説でじっくり復習。「読む→解く→わかる」のサイクルで、プログラミング学習の土台となる前提知識をしっかり身につけましょう！

今すぐクイズに挑戦
（10問・約3分・解説つき）
プリンシプルオブプログラミング
1分で理解＆101の原則総まとめ！

第1章:プログラミングの前提をクイズで学ぶ！ 目次

  1. 第1章:プログラミングの前提をクイズで学ぶ！の要点・要約を読む(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章：良い設計の原則をクイズで学ぶ！)
  3. 前のクイズへ(第7章：現場で使える設計法則をクイズで学ぶ！)
  4. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

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

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

  • 要旨

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

  • 理由

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

  • 結論

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

  • その他（行動指針）

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

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

  • 要旨

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

  • 理由

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

  • 結論

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

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

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

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

  • 要旨

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

  • 理由

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

  • 結論

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

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

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

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

1. 【1.1．プログラミングに銀の弾丸はない⑤】
「本質的な複雑性に向き合い、偶有的な複雑性を克服する」という姿勢が重視される理由として最も適切なものはどれか？

2. 【1.2．コードは設計書である③】
「コードは設計書である」ことを前提にした適切な開発姿勢はどれか？

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

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

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

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

7. 【1.3．コードは必ず変更される③】
以下のうち、読みやすさを確保することで「変更に強くなる」理由として最も適切なものはどれか？

8. 【1.3．コードは必ず変更される②】
将来の変更に備えた設計として、特に有効とされる考え方はどれか？

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

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

次のクイズ(第2章：良い設計の原則をクイズで学ぶ！)へ

第１章：前提
採点結果

正答率：0%

-

-

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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

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

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

もちもちみかん.comとは


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

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