設計現場で使える手法をクイズで学ぶ！
第6章：手法 要約＆クイズ

要旨

理由

結論

その他（メリット・比較）

• メリット

  • ユーザーフィードバックを早い段階で集められる（ジョハリの窓的に＝自分もユーザーも気づいていないポイントが見えやすくなる）。
  • プログラマの「舞台」が早く整うので、チーム全員が全体像を見ながら生産的に動ける。
  • デバッグやテストを早く・正確に行える（小さな機能ができたら、すぐ全体に組み込んで確認できる）。
  • いつでも人に見せられるデモ用ソフトを持っておける。
  • 進捗が見えやすい（ユースケース単位で「ここまで通った」と説明しやすい）。

• プロトタイプとの違い

  • プロトタイプ…理解を確かめるための試作品。基本は使い捨てが前提で、「学び」を得たら本番コードは作り直すことが多い。
  • 曳光弾…最初から本番で使うつもりの最小コードで全体のつながりを通し、あとからも使い続ける骨格として育てていく。

要旨

理由

結論

その他（指針・注意・拡張・運用）

• 指針

  • 呼び出す側は、決められた前提条件を満たしてから呼び出す（入力チェックは基本的に呼び出し側の仕事）。
  • 呼び出される関数側は、引数をこっそり補正しない（契約違反はすぐ検出して問題に気づく）。
  • 「こうであるべき」という想定は厳しく、「こう返す」という確約は少し余裕を持たせる（受け口を増やしすぎず、返り値の条件で縛りすぎない）。

• オブジェクト指向の拡張

  • クラス不変表明（どんなメソッドを呼んでも常に成り立っていてほしい条件）も契約として決めておき、それを壊さないように実装する。

• アサーション運用

  • アサーションは開発・保守のための仕組みであり、エンドユーザー向けの丁寧なエラーメッセージではない。→ 本番リリース版ではオフにする／含めない運用が多い。

• エラーハンドリング方針

  • 「本来ありえないはず」の事態は、だらだら処理を続けず早めにクラッシュさせて、大きな音で知らせるイメージで通知する（被害が広がらないうちに止める）。

要旨

理由

結論

その他（観点・戦略・手当）

• 観点

  • 外部入力の確認（ファイル・ユーザー入力・ネットワークなど）…許してよい範囲をチェックし、サニタイズ（危険な部分を無害化）して「想定内エラー」として扱う。
  • 関数引数の確認…ここがおかしいのはプログラムのバグ。アサーションなどで検出し、必要なら処理を止める（＝「想定外エラー」）。

• バリケード戦略

  • ダーティルーム（外部からデータが入ってくる入口）→バリケード（検証・消毒をする場所）→クリーンルーム（中の安全な世界）の三段構えで役割を分ける。

• 想定内エラーの処理例

  • 無害な値を返す（0 や空文字列、NULL など）。
  • 次のデータにスキップする（壊れているレコードは読み飛ばす）。
  • 前回の値を返す（センサー読み取りに失敗したときなど）。
  • 近い有効値に丸める（0～100 の範囲外なら 0 か 100 に直すなど）。
  • 状況をログに記録するだけにして処理は続ける（軽い問題のとき）。
  • エラー状態や例外などでエラーを返し、上位に判断をゆだねる。
  • 共通のエラー処理に集めて処理する（ログ内容はそのままユーザーに見せない）。
  • ユーザーに必要最小限のメッセージを見せる（特にログインなど認証系では詳しい理由を出しすぎない）。
  • 処理を中止する（動き続けるほうが危険なとき）。
  • 場所ごとにいちばん妥当な方法を選びつつ、システム全体としては方針がバラバラにならないよう注意する。

• 正当性 と 堅牢性

  • 医療システムなど安全最優先の世界では、多少止まっても正しい結果であることを優先（正当性 ＞ 堅牢性）。
  • 文書編集ソフトなどユーザー体験最優先の世界では、多少結果があいまいでも落ちないことを優先（堅牢性 ＞ 正当性）。

• 「言語の中へ」

  • 言語に標準機能がなくても、ライブラリやマクロなどを使って契約や防御の考え方を取り込み、コードとして表現できる形で実装していく。

• セキュリティ補足

  • エラー処理が雑だと、そこがセキュリティホール（攻撃の入口）になりやすい。入力チェック・例外処理・ログの扱いには特に注意する。

要旨

理由

結論

その他（効果・実践）

• 効果：隠れていたバグを早期に見つけられる／ユーザーにとって本当に大事な体験が分かる／どこから直すべきか優先順位がはっきりする。
• 実践：実際の環境・実際のデータ・実際の端末で操作する。正常なケースだけでなく、あえて異常な操作や境界ギリギリの値も試してみる。

要旨

理由

結論

その他（コツ）

• 「再現手順 → 期待していた結果 → 実際の結果 → その差 → 仮説」の順で話してみる。
• コードの断片を読み上げつつ、自分の意図と実際の処理がズレていないかを一行ずつ確認する。
• 説明しながら最小限の再現コードになるように、問題の範囲を少しずつ縮めていく。

要旨

理由

結論

その他（活用・例・指針）

• コードの読み書きに利用

  • 階層原理（セクション／章／段落／文のように大きさで分ける）と驚き最小の原則（読んだ人が「えっ？」とならない自然な流れ）を意識して、読みやすい文脈を作る。

• 思考のツールとして利用

  • 物事はお互いに影響し合っている。背景や周辺の事情も含めて考えることで、より正確に問題を解きやすくなる。

• コンテキストと依頼作業

  • 経験豊富な人には「目的」だけ伝えれば動いてくれることが多いが、初心者には前提や手順までセットで伝える必要がある。＝経験が文脈を補ってくれる。

• コンテキストの伝達能力

  • 言葉（コンテンツ）は、文脈と一緒になって初めて意味を持つ。例として、トイレに行った子どもの「お母さん！」という一言は、状況込みで「トイレットペーパーを持ってきて」の意味になる。

• チームはハイコンテキスト志向で

  • 共通の文脈が増えるほど、説明のオーバーヘッド（余計な手間）が減り、品質も上がりやすい。
  • 新しく入ったメンバーには、「自明だと思っていること」も5W1H（いつ・どこで・誰が・何を・なぜ・どうやって）を意識して言葉にして伝える。

• コード共通化はコンテキスト志向で

  • 見た目が似ている処理でも、役割や前提が違うものは安易に共通化しない（あとで別の変更が必要になりがち）。
  • 共通化すると依存関係が増えるので、システム全体の構造と文脈をよく見てから判断する。

• プログラマのコンテキストスイッチ

  • 深く集中している状態（フロー）は中断に弱い。職場の文化として、むやみに中断しない・集中時間を尊重することを大切にする。

• 「システムシンキング」とドメイン駆動設計

  • 全体を一つのシステムとして見る考え方を、ドメインモデル中心の開発（DDD＝Domain-Driven Design）で形にする。
  • 現場の専門家と一緒にモデルを何度も更新し、言葉・図・コードをそのモデルと一体にしていく。

• フロネシスと全体最適化

  • フロネシス（状況に応じて最善を選ぶ実践的な知恵）を働かせて文脈を読み取り、ユーザー価値にとって全体としていちばん良い選択を考える。

• 「関係主義」と障害対応

  • 問題が起きたときは、コードだけでなくライブラリ・環境・他システムとの相互作用など、関係性全体の中から原因を探す。