勉強会_ものづくりの6つの原理原則_理系向け6時間_2026_05_24_石黒友季子

理系エンジニア勉強会（全6時間） ものづくりの6つの原理原則 ～ 図解で学ぶ、伝え方・事実・設計・品質の「なぜ」 ～ 対象：新卒〜中堅エンジニア（前提知識は最小限でOK） 進め方：6モジュール × 各60分（解説40分＋演習・休憩20分） 2026/05/24 面白きこともなき世を面白く 石黒友季子

00 この勉強会のねらい 個々の技術ではなく、技術の裏にある「いつでも効く考え方（原理原則）」を、図で腹落ちさせます。 丸暗記でなく「なぜそうするか」を説明できるようになる 新卒は「型」を、中堅は「型を破る判断軸」を持ち帰る 明日の設計レビュー・報告・実装ですぐ使える原則にする ※ 例題は、実際に作って動かしているツール群を題材にします（誇張なし・実装ベース）。

00 タイムテーブル（全6時間） M1 伝える技術の原則 分・形・完・格 60分 M2 事実と解釈を分ける ファクトベース報告 60分 M3 単純さの原則 道具を規模に合わせる 60分 M4 隔離の原則 境界で問題を断つ 60分 M5 壊れにくくする原則 不変条件とデータ境界 60分 M6 品質を測る原則 7工程のテスト設計 60分

00 全体マップ：6原則はどうつながるか M2 事実 M1 伝える M3 単純 良い ものづくり M6 品質 M4 隔離 M5 壊れにくさ 入口（伝える・事実）→ つくり方（単純・隔離・壊れにくさ）→ 出口（品質）。すべて中央の目的に奉仕します。

MODULE 1 伝える技術の原則 The Principles of Asking Well — 分・形・完・格 • 同じ相手（AIでも人でも）が、入力次第で全く違う成果を返す • 良い依頼に共通する4つの要素を、図で分解する • 新卒は型として、中堅はレビュー観点として使える

1-1 なぜ「伝え方」が原理原則なのか 処理（相手）が同じでも、入力（依頼）の質が出力（成果）を決める 曖昧な依頼 「いい感じにして」 同じ相手 （AI・人） 低品質・やり直し多発 VS 構造化した依頼 （分・形・完・格） 同じ相手 （AI・人） 高品質・一度で意図に近い 結論：制御できるのは入力だけ。だから「入力の質を上げる原則」を持つ価値がある。

1-2 4原則の全体図「分・形・完・格」 分 形 完 格 タスクを分解 出力の形を決める 完了条件を決める 品質の格を決める 大きい仕事は 番号で割る 器を先に渡す ゴールを先に置く 本気度を伝える

1-3 原則①「分」— 分解する 「企画書つくって」（大きすぎ・着手点不明） 分 ① ターゲッ ト 大きい仕事は 小さく割って渡す ② 課題 ③ 解決策 分割すると、各ブロックは独立して着手・確認できる → 番号で割ると、相手は迷わず順番に進める ④ 価格

1-4 原則②「形」— 形を決める 形を指定しない 形 「表形式で」と指定 担当 / 確度 / 次手 長文がだらだら返り、 粒度がバラバラ 出力の器を 先に指定する → 形（表・箇条書き・字数）を決めると粒度が揃う

1-5 原則③「完」— 完了条件 完 「どうなったら 終わりか」を置く 指示 作業 ゴールを定義しないと「3件見つけました」で止まる。 「直すところまで」と置けば最後まで到達する。 → ゴールを言うと、報告で止まらず修正まで走る 完了条件 で終了

1-6 原則④「格」— 品質の格 格 本気度・目線の 高さを指定する ラフ 標準 最上位 下書き・社内メモ 通常業務 社内SEレベル DEV環境 社外・重要顧客 商用レベル PRO環境 「社外の重要顧客向けに丁寧に」の一言で、出力の格が上がる → 相手・場面・レベルで振る舞いが切り替わる

1-7 演習①（15分） 演習 あなたが普段AIや後輩に頼む業務を1つ選び、「分・形・完・格」を1つずつ足して指示文を書き 直す。書き直し前後をペアで見せ合う。

MODULE 2 事実と解釈を分ける Separate Fact from Interpretation • 理系の文章の生命線は、再現性・測定値・証拠 • 「観測した事実」と「自分の解釈」を物理的に分ける • 結果と考察、確定原因と推定原因を混ぜない

2-1 情報には「確からしさの階層」がある 下にいくほど主観的。報告では混ぜずにラベルを付ける 事実（観測した） 測定値（数えた・計った） 推測（根拠あり） 所感（主観） 見た・起きた。最も確か 数値。再現できる 未確定。根拠とセットで 感想。事実ではない

2-2 報告を4つの箱に仕分ける 事実 測定値 推測 所感 例 例 例 例 ビルドが完了した 処理 3.2秒 / 28件成功 ログにtimeout→遅延と推 定 手順が分かりにくいと感 じた 判断基準：それは「見た／測った」ことか？ それとも「自分の考え」か？

2-3 結果と考察の間に「壁」を作る（IMRAD） 結果には事実だけ。解釈は必ず考察側に隔離する 結果（Results） 考察（Discussion） • 事実・観測・数値のみ • 書き手の解釈・推論 • 「平均3.2秒だった」 • 「根拠 → 〜と考えられる」 • 解釈・原因はここに書かない • 事実ではないと明示する 壁

2-4 原因は「確定」と「推定」を分ける 証拠のないものを断定すると、調査が遠回りになる 【確定】証拠で裏付け済み 【推定】未確認・仮説 例）保存APIが500を返している 例）入力値検証の不足が （サーバログで確認） 原因と推定（未確認） 欄を物理的に分けるだけで、「断定の混入」を構造的に防げる。

2-5 誇張・主観 → 事実ベースへ言い換える つい言いがち（主観・誇張） 事実ベースの言い換え たぶん大丈夫 ○○の条件では確認済み。△は未確認 ちゃんと動いた テスト28件中28件で期待結果と一致 すごく速くなった 処理 X秒 → Y秒（Z%短縮） 完璧です 確認した範囲（列挙）では不具合なし

2-6 演習②（15分） 演習 直近で書いた自分の報告・チャットを1つ取り出し、(1)事実/測定/推測/所感に色分け、(2)誇張語 を事実表現に書き換える。

MODULE 3 単純さの原則 Match the Tool to the Problem Size • 「とりあえず流行りの道具」を疑う • 機能の中身を説明できることが力 • 賢く見えて単純、で十分な場面を見極める

3-1 道具は「規模」に合わせて選ぶ オーバースペックは、学習・保守・依存のコストを生む 小規模 × 素のJS 小規模 × 重量級FW ○ 起動・配布が軽い／読みやすい × ビルド・依存・学習コストが過剰 大規模 × 素のJS 大規模 × FW・設計 × 構造が崩れ保守不能に ○ 構造化の恩恵が上回る 対角線（規模と道具が釣り合う）が正解。釣り合わないと必ずコストになる。

3-2 「賢く見える」機能の中身を開けてみる 例：誇張語の警告機能＝AIではなく、固定リストとの照合 見え方 中身（実装） 「たぶん」「完璧」を 固定リストの単語を 賢く検出してくれる すごい機能 indexOf で含むか調べるだけ。 文脈は理解していない。 正直な限界：リスト外は見逃す／誤検知もある。でも「気づきの入口」には十分。 原則：見た目に惑わされず中身を説明できること。単純で十分なら、単純にする。

3-3 過剰設計が生む3つのコスト 学習コスト 保守コスト 依存コスト 新メンバーが理解に時間を要する 依存更新・脆弱性対応が増える 外部が壊れると自分も止まる 「動く」だけでなく「この先も無理なく保てるか」で道具を選ぶ。

MODULE 4 隔離の原則 Solve Problems at the Boundary • 独立した部品を1つに統合すると、必ず干渉が起きる • CSS汚染・名前衝突・状態リークを「境界」で断つ • iframe/srcdoc による隔離アーキテクチャを図で理解する

4-1 部品を統合した瞬間に起きる3つの干渉 CSS汚染 名前衝突 状態リーク 片方のスタイルが 相手に染み出す 同名の関数・変数が ぶつかる 片方の入力・状態が 外に漏れる これらは「コードの書き方」では根治しにくい。境界そのもので断つ発想が要る。

4-2 解決策：iframe/srcdoc で文書ごと隔離 各ツールを「独立した完全なHTML」として箱に入れる 外殻（シェル）：本棚に徹する iframe#frm-A （完全なHTML） iframe#frm-B （完全なHTML） … 全30個 文書が別 = window が別。スタイルも名前空間も状態も、境界の内側で閉じる。

4-3 「境界で断つ」の効果 境界なし（同一文書に同居） 境界あり（srcdoc隔離） • CSSが互いに干渉 • スタイル混在なし • genSep が30個衝突 • 同名でも衝突なし • 状態が漏れる • 状態は箱の中で完結

4-4 図解：srcdocエスケープは順序が命 HTMLをHTML属性に入れるので、属性を壊さないよう変換する 元のHTML ... title="x" ... ① & を &amp; に （先にやる） ② " を &quot; に 属性の境界を守る srcdoc属性に格納 <iframe srcdoc="..."> 順序を逆にすると二重エスケープで壊れる。読むときブラウザが自動で逆変換する。

MODULE 5 壊れにくくする原則 Make It Hard to Break • データの流れと「外に出さない境界」を設計する • 拡張時に壊れる場所を、検証できる不変条件に変える • 注意喚起より、間違えにくい構造をつくる

5-1 データフローと「送信しない境界」 ユーザー入力 加工（整形・esc） この破線の外に出ない（外殻は通信 ゼロ） 出力欄（readonly） JSON保存／復元 例外はAPI版のみ：ユーザーが自分でキーを入れた時だけ外部へ送る（既定は送らない）。

5-2 拡張点を「不変条件」に変える ツール追加時に壊れやすい所を、機械検証できる等式にする iframe集合 = switchMode集合 = タブ集合 = 目次集合 5つの集合が完全一致 ＆ frmid と mode が食い違わない どれか1つ漏らすと「目次に出るのに開かない」等の不整合 → 集合の差分で即検出 = リサイズ集合

5-3 ツール追加の「5点セット」手順 ① 目次に項目追加 ② switchMode にトグル行 ③ タブ定義 data-mode ④ リサイズ配列に追加 ⑤ iframe本体を挿入 1セットで更新 → 直後に不変条件チェック。手作業統合を安全に回す型。

5-4 注意喚起より「混ざらない入れ物」 人は『気をつけよう』では混ぜる。構造で防ぐ 弱い：注意で防ぐ 強い：構造で防ぐ 「事実と所感は 入力欄を最初から 分けて書きましょう」 事実／所感に分ける → つい混ざる → 混ぜようがない

MODULE 6 品質を測る原則 Measure Quality in Layers • 「個別では動くのに合体で壊れる」を層で捕まえる • 単体→結合→E2E と、観点を分けて検証する • テスト結果は誇張せず、原因まで正直に切り分ける

6-1 7工程で「層を分けて」検証する ① 単体 ② 結合 ③ ホワイト ④ ブラック ⑤ 実描画 ⑥ E2E ⑦ 監査 構文・部品単位 部品間の整合 内部ロジック 外から操作 ブラウザで確認 通し操作 依存・送信境界 観点を分けるほど、どこが弱いかが具体的に分かる。

6-2 量のバランス：テストピラミッド 下ほど多く・速く、上ほど少なく・重く E2E（少・重） 結合（中） 単体（多・速） 速くて安い単体を厚く、重いE2Eは要所に絞る。

6-3 原則：テストは「正直」に切り分ける 実例：1件のNGが、ツールでなくテストコード起因だった NG：あるツールが『表示されていない』と出た 調査：判定が隠し要素を拾っていただけ。ツールは正常だった 「失敗＝バグ」と決めつけず、原因を切り分ける。正直な切り分けが信頼を作る。

6-4 「検出バグ0」が意味すること・しないこと 意味すること 意味しないこと • 設計した観点では問題が出なかった • バグが絶対に無い、ではない • 既知のバグは再発していない • 観点の外は見えていない だから観点を増やし続ける。これも「嘘なく」の態度。

6原則の総まとめ M1 伝える 分・形・完・格で入力の質を上げる M2 事実 観測・解釈を分け、誇張を排す M3 単純 道具を規模に合わせる M4 隔離 干渉を境界で断つ M5 壊れにくさ 不変条件と送信境界で守る M6 品質 層で測り、正直に切り分ける

通底するのは、ひとつ 「正直に・事実ベースで つくり、伝える」 派手な技術より、これが長く使われるものを作る土台になる。 お疲れさまでした。面白きこともなき世を面白く