---
title: 勉強会_ものづくりの6つの原理原則_理系向け6時間_2026_05_24_石黒友季子
tags:  #ai駆動開発 #ai  
author: [smile_yukiko_it](https://www.docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/47QYDQ5LEP.jpg?width=480
description: 趣味枠AIコミュニティ用の資料です。
published: May 24, 26
canonical: https://www.docswell.com/s/smile_yukiko_it/5Q299M-2026-05-24-085327
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/47QYDQ5LEP.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KE4WZN95J1.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/L71YR5K2JG.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/G7WG15D2E2.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JZLPNG4E3.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YE6WM8YGEV.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GE5MZ9GXE4.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/9729R2YQJR.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/DJY4DYGY7M.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/V7NY6PGRE8.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YJ9PL3WZ73.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GJ8DXMRYJD.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LJLM83K9ER.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/47MY6D2V7W.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/P7R9P4MWE9.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/PJXQ32VV7X.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/3JK9YMQ5JD.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/LE3W9YP1E5.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/8EDKG5LK7G.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/V7PK3G23J8.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/2JVV46DNJQ.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/5EGL1NY5JL.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4JQYDQML7P.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/K74WZNV5E1.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/LJ1YR532EG.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GJWG15P272.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/4EZLPNK473.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/Y76WM8QG7V.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/G75MZ9RX74.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/9J29R2DQER.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/DEY4DY2YJM.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/VJNY6P8R78.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/YE9PL3KZJ3.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/GE8DXM2YED.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/LELM83297R.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/4JMY6D8VJW.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/PJR9P45W79.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/PEXQ32KVJX.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/3EK9YM55ED.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/L73W9YK175.jpg)

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