もちもちみかん0系くん
『プリンシプル オブ プログラミング』手法編を20問で学べるクイズサイト

プリンシプル オブ プログラミング
第６章：手法 要約＆クイズ

公開日：
最終更新日：

リファクタリング、テスト、デバッグなど、プロの開発に欠かせない実践的な手法を、要点要約で集中的に学びます。

要約で手法の基本を習得し、20問のクイズで実践力を確認。保守性と拡張性の高いコードを書くスキルを確立しましょう！

今すぐクイズに挑戦
（20問・約5分・解説つき）
プリンシプルオブプログラミング
101の原理・原則を読む

目次

  1. 第６章：手法の要点・要約を読む(3分)
    1. 6.1 曳光弾（Tracer Bullet Development）
    2. 6.2 契約による設計（Design by Contract）
    3. 6.3 防御的プログラミング（Defensive Programming）
    4. 6.4 ドッグフーディング（Dogfooding）
    5. 6.5 ラバーダッキング（Rubber Duck Debugging）
    6. 6.6 コンテキスト（Context）
  2. クイズに挑戦する(20問)
  1. クイズ一覧へ
  2. 次のクイズへ(第７章：法則)
  3. 前のクイズへ(第５章：習慣)
  4. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第６章：手法
～プログラマの道具箱～

6.1 曳光弾（Tracer Bullet Development）

  • 要旨：優先的に検証したい部分を先行実装し、簡易でも実環境で動くエンドツーエンドの骨格を通す。
  • 理由：動く最小構成を早期に用意すると、学習・調整・検証のサイクルが加速するため。
  • 結論：まず土台（骨格）を作り曳光弾として通す→以後は肉付けしながら目標とのズレを継続チェックし、必要に応じて軌道修正する。
  • その他（メリット・比較）：
    • メリット：
      • ユーザーフィードバックを早期に獲得（ジョハリの窓的にユーザーの盲点を可視化）。
      • プログラマの舞台を早期整備（エンドツーエンドが見えると全員が生産的に）。
      • デバッグ/テストの早期・正確化（単体完了→即統合、影響範囲の限定）。
      • 常時デモ可能なソフトウェアを確保。
      • 進捗の見える化（ユースケース単位で報告が容易）。
    • プロトタイプとの違い：
      • プロトタイプ：理解を検証するための試作。使い捨てが前提（得た知見で作り直す）。
      • 曳光弾：本物の最小コードで全体連携を示し、以後も使い続ける骨格を提供。

6.2 契約による設計（Design by Contract）

  • 要旨：「呼び出し側」と「呼び出される側」が契約（前提条件・事後条件）を取り決め、それに即して実装する。
  • 理由：契約を明確にし遵守することで、正しさ保証（過不足なし）・コードの単純化・早期発見/早めのクラッシュが可能になるため。
  • 結論：関数仕様はコメントで明示し、アサーションで契約履行をチェック（呼び出し前：前提条件／終了時：事後条件）。
  • その他（指針・注意・拡張・運用）：
    • 指針：
      • 前提条件を満たしてから呼び出す（入力検証は呼び出し側）。
      • 関数側は引数の調整を行わない（契約違反は即検出）。
      • 想定は厳格に / 確約は寛容に（受け口を増やし過ぎず、返却条件は過度に縛らない）。
    • オブジェクト指向の拡張：
      • クラス不変表明：常に成り立つ条件を保証する契約を併用。
    • アサーション運用：
      • 開発/保守専用。エンドユーザー向けメッセージではない→リリース版には含めない。
    • エラーハンドリング方針：
      • ありえない事態は早めにクラッシュし、処理を中断してけたたましく通知（被害拡大を防ぐ）。

6.3 防御的プログラミング（Defensive Programming）

  • 要旨：「だろう」ではなく「かもしれない」で考え、入力と境界を徹底的に守る。
  • 理由：不正値・想定外入力を早期に検出し対処することで、開発中のデバッグ効率と、運用中の安全性/セキュリティを高められるため。
  • 結論：バリケード戦略で汚染の侵入を防ぎ、エラー処理ポリシーを場面に応じて選択（正当性/堅牢性の優先度を明確化）。
  • その他（観点・戦略・手当）：
    • 観点：
      • 外部入力の確認（ファイル/ユーザー/ネットワーク）…許容範囲チェックとサニタイズで「想定内エラー」を検出・処理。
      • 関数引数の確認…想定外はバグ。アサーションで検出し必要なら停止（「想定外エラー」）。
    • バリケード戦略：
      • ダーティルーム（外部からの入口）→バリケード（検証/消毒）→クリーンルーム（内部モジュール）の三層で役割分担。
    • 想定内エラーの処理例：
      • 無害な値を返す（数値0/空文字/NULL）。
      • 次のデータで代用（無効レコードはスキップ）。
      • 前回値を返す（センサー読み取り失敗時など）。
      • 近い有効値に丸める（0～100の範囲外を端で代用）。
      • ログ記録のみで継続（軽微な場合）。
      • エラーを返す（状態/戻り値/例外で上位へ委譲）。
      • 共通エラー処理に委譲（集中管理、ログは露出させない）。
      • メッセージ表示（必要最小限、認証系は詳細非表示）。
      • 処理を中止（誤処理継続より停止が安全な場合）。
      • 各所で最適な方法を選択（ただし全体の一貫性に注意）。
    • 正当性 と 堅牢性：
      • 安全最優先（例：医療）は正当性＞堅牢性（誤結果により停止）。
      • ユーザー体験最優先（例：文書）は堅牢性＞正当性（落とさない）。
    • 「言語の中へ」：
      • 言語に機能がなくても、ライブラリ/マクロ等で契約や防御の考えを取り込み、表明可能な形で実装する。
    • セキュリティ補足：
      • エラー処理の不備はセキュリティホールになりやすい。入力検証・例外処理・ログ露出に注意。

6.4 ドッグフーディング（Dogfooding）

  • 要旨：自分で作ったソフトウェアを自分でユーザーとして使う。
  • 理由：開発者は無意識に障害を避けた操作（正常系偏重）をしがちで、別視点（ユーザー視点）でのみ見つかる不具合があるため。
  • 結論：ユーザーになり切って使用し、見え方の違い（ジョハリの窓）を意識してギャップを埋める。
  • その他（効果・実践）：
    • 効果：潜在バグの早期発見／本当に必要な体験価値の把握／優先順位の明確化。
    • 実践：実環境・実データ・実端末での操作／正常系だけでなく異常系・境界値の操作も行う。

6.5 ラバーダッキング（Rubber Duck Debugging）

  • 要旨：問題を誰か（ラバーダックでも可）に説明することで頭が整理され、自己発見で解決に近づく手法。
  • 理由：説明の過程で状況を理路整然と再構成するため、矛盾点や「説明できない箇所」に気づきやすい。
  • 結論：行き詰まり時は声に出して順序立てて説明する。相手は人でも物でもよい（重要なのは説明行為）。
  • その他（コツ）：
    • 再現手順→期待値→現状→差分→仮説の順に話す。
    • コード断片を読み上げ、意図と実装のズレを都度確認する。
    • 説明しながら最小再現を縮めていく。

6.6 コンテキスト（Context）

  • 要旨：周囲の状況・背景（文脈）を設計・実装・コミュニケーションに組み込み、判断の質を高める。
  • 理由：コンテキストを考慮すると、断片情報が結びつき、迷子にならずに正しい解へ到達しやすい。
  • 結論：コンテキストをモデル化して共有（例：ドメインモデル）、思考法（システムシンキング等）で掘り下げ、チームでハイコンテキストを醸成する。
  • その他（活用・例・指針）：
    • コードの読み書きに利用：
      • 「階層原理」（セクション／章／段落／文）と「驚き最小の原則」で文脈を構成。
    • 思考のツールとして利用：
      • 物事は相互依存。背景を含めて考えることで問題を正確に解く。
    • コンテキストと依頼作業：
      • 達人には「目的」だけで十分／初心者には詳細指示が必要→経験が文脈を補う。
    • コンテキストの伝達能力：
      • 言葉（コンテンツ）は文脈とセットで意味を持つ（例：トイレに行ったこどもの「お母さん！」の声＝紙が欲しい）。
    • チームはハイコンテキスト志向で：
      • 共有文脈が増えるとオーバーヘッド減・品質向上。
      • 新メンバーには自明も言語化（5W1H、順序立てた説明）。
    • コード共通化はコンテキスト志向で：
      • 役割が異なる類似処理は安易に共通化しない（別変更が必要になりがち）。
      • 共通化は依存を増やす→全体構造と文脈を見極めて判断。
    • プログラマのコンテキストスイッチ：
      • フロー状態は中断に弱い→職場文化として中断を最小化（集中時間を尊重）。
    • 「システムシンキング」とドメイン駆動設計：
      • 全体を統一的に捉える思考を、ドメインモデル中心の開発（DDD）で具現化。
      • 専門家と共にモデルを反復深化し、言語・図・コードをモデルと一体化。
    • フロネシスと全体最適化：
      • 実践的な智慧（フロネシス）で文脈を捉え、ユーザー価値へ全体最適の判断を下す。
    • 「関係主義」と障害対応：
      • コードだけでなく、ライブラリ・環境・相互作用を含む関係性に原因を探る。

プリンシプル オブ プログラミング(第６章：手法)

1. 【6.6．コンテキスト⑪】
「ドメイン」とはドメイン駆動設計において何を指すか？

2. 【6.6．コンテキスト⑤】
依頼作業で初心者に詳細な指示が必要になる理由は何か？

3. 【6.6．コンテキスト⑭】
「フロネシス」に基づく判断が求められるのはどのような場面か？

4. 【6.2．契約による設計（Design by Contract）⑩】
契約による設計の方針として正しいものはどれか？

5. 【6.3．防御的プログラミング⑰】
次のうち、防御的プログラミングの目的として最も不適切なものはどれか？

6. 【6.3．防御的プログラミング⑨】
防御的プログラミングにおいて「エラー処理関数を呼び出す」主な目的はどれか？

7. 【6.2．契約による設計（Design by Contract）⑨】
契約による設計において、アサーションはどの段階で使用されるべきか？

8. 【6.1．曳光弾（Tracer Bullet）⑩】
曳光弾アプローチにおいて、ステークホルダーにとっての大きなメリットはどれか？

9. 【6.6．コンテキスト⑩】
職場で「コンテキストスイッチを忌み嫌う文化」を作る理由は？

10. 【6.5．ラバーダッキング⑤】
問題が解決しないときに「ラバーダッキング」を試す利点はどれか？

11. 【6.4．ドッグフーディング⑤】
ドッグフーディングを効果的に実施するために重要な姿勢はどれか？

12. 【6.6．コンテキスト⑥】
ハイコンテキストなチームの利点として適切なものはどれか？

13. 【6.2．契約による設計（Design by Contract）⑦】
契約による設計で、クラスの状態が常に満たすべき条件として定義されるのはどれか？

14. 【6.1．曳光弾（Tracer Bullet）⑧】
曳光弾アプローチの第一段階として適切な行動はどれか？

15. 【6.1．曳光弾（Tracer Bullet）⑤】
曳光弾アプローチにより、バグ対応が迅速になる理由はどれか？

16. 【6.2．契約による設計（Design by Contract）⑥】
契約による設計において、「関数側で引数の調整をしない」理由として最も適切なのはどれか？

17. 【6.3．防御的プログラミング⑧】
次のうち「想定内のエラー処理」に含まれないものはどれか？

18. 【6.3．防御的プログラミング⑮】
セキュリティ面で防御的プログラミングが重要とされる理由はどれか？

19. 【6.3．防御的プログラミング③】
「関数の引数を検証する」目的として最も正しいものはどれか？

20. 【6.3．防御的プログラミング⑥】
「正当性」を重視するべきソフトウェアの例として最も適切なものはどれか？

第６章：手法の要約を読む クイズ一覧へ

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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


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

採点結果

正答率：0%

-

-
TOPへ

もちもちみかん.comとは


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

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