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

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

公開日：
最終更新日：

本ページでは、『プリンシプル オブ プログラミング』第１章のプログラミングの前提知識と考え方を、短時間で効率よく整理します。

要点要約で予習 → 4択クイズ（10問・全問解説）で理解度を確認 → 解説で復習。この学習サイクルで、プログラミング学習の土台をしっかり固めましょう！

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

第１章：前提 目次

  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. 次のクイズへ(第２章：原則)
  3. 前のクイズへ(第７章：法則)
  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.2．コードは設計書である③】
「コードは設計書である」ことを前提にした適切な開発姿勢はどれか？

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

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

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

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

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

7. 【1.1．プログラミングに銀の弾丸はない④】
ソフトウェア開発における最も健全な姿勢として適切なものはどれか？

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

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

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

次のクイズ(第２章：原則)へ

第１章：前提
採点結果

正答率：0%

-

-

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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

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

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

もちもちみかん.comとは


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

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