@k2works/claude-code-booster 6.6.1 → 6.8.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,66 +1,69 @@
1
- # リファレンス
2
-
3
- 開発ガイドラインやベストプラクティスのリファレンスドキュメントです。
4
-
5
- ## ドキュメント一覧
6
-
7
- ### 基本理念
8
-
9
- - [よいソフトウェアとは](./よいソフトウェアとは.md)
10
- - [ロジカルシンキング](./ロジカルシンキング.md)
11
- - [開発ガイド](./開発ガイド.md)
12
- - [開発ガイド(AI-DLC 版)](./開発ガイド_AI-DLC版.md) - 開発ライフサイクルを Inception・Construction・Operation で読み替え、各活動の AI と人の分担と AI-DLC 版ガイドへの入口を示す
13
- - [エクストリームプログラミング](./エクストリームプログラミング.md)
14
- - [AI-DLC 導入ガイド](./AI-DLC導入ガイド.md) - AWS が提唱する AI-DLC の 10 原則・成果物・フェーズ・参照実装(aidlc-workflows)と、XP ベースの開発ライフサイクル・Skills 体系への組み込み方
15
- - [AI-DLC 用語集](./AI-DLC用語集.md) - AI-DLC の用語を基本概念・成果物・フェーズと儀式・計画・実装・参照実装の区分で定義し、XP・Scrum との対応を示す
16
- - [ドキュメント構成ガイド](./ドキュメント構成ガイド.md) - 単一企業・統合戦略・複数プロジェクトのコンセプトに基づく docs/ と apps/ の構成規約
17
- - [Living Documentation導入ガイド](./LivingDocumentation導入ガイド.md) - 『Living Documentation』に基づくドキュメントの再定義と 4 原則、知識の活用・拡張・キュレーション、Living Glossary・Living Diagram、ランタイムドキュメンテーションと、本プロジェクトの成果物への適用方法
18
- - [アノテーション導入ガイド](./アノテーション導入ガイド.md) - 設計判断・意図・根拠をコード上の構造化されたアノテーションとして残す導入手順(語彙カタログ、命名・コミット規約、ツール連携と検証)
19
- - [ダイナミックキュレーション導入ガイド](./ダイナミックキュレーション導入ガイド.md) - 既存の知識から目的に必要な少数を安定した基準で自動的に選び出す導入手順
20
- - [ガイドツアー・サイトシーイング導入ガイド](./ガイドツアー・サイトシーイング導入ガイド.md) - コードの見どころ(サイトシーイング・マップ)と処理の流れ(ガイドツアー)をアノテーションから生成する導入手順
21
-
22
- ### 経営・ビジネス
23
-
24
- - [企業経営論](./企業経営論.md)
25
- - [運営管理](./運営管理.md)
26
-
27
- ### 分析・設計
28
-
29
- - [経営戦略分析ガイド](./経営戦略分析ガイド.md)
30
- - [ビジネスアーキテクチャ分析ガイド](./ビジネスアーキテクチャ分析ガイド.md)
31
- - [要件定義ガイド](./要件定義ガイド.md)
32
- - [ユースケース作成ガイド](./ユースケース作成ガイド.md)
33
- - [ユースケース作成ガイド(AI-DLC 版)](./ユースケース作成ガイド_AI-DLC版.md) - Mob Elaboration で AI が初稿を書き人が検証する手順、人と AI の契約としての記述基準、AI 生成物の検証観点
34
- - [アーキテクチャ設計ガイド](./アーキテクチャ設計ガイド.md)
35
- - [データモデル設計ガイド](./データモデル設計ガイド.md)
36
- - [ドメインモデル設計ガイド](./ドメインモデル設計ガイド.md)
37
- - [UI 設計ガイド](./UI設計ガイド.md)
38
- - [インフラ設計ガイド](./インフラ設計ガイド.md)
39
-
40
- ### 品質・テスト
41
-
42
- - [テスト戦略ガイド](./テスト戦略ガイド.md)
43
- - [非機能要件定義ガイド](./非機能要件定義ガイド.md)
44
- - [運用要件定義ガイド](./運用要件定義ガイド.md)
45
- - [コーディングとテストガイド](./コーディングとテストガイド.md)
46
- - [コーディングとテストガイド(AI-DLC 版)](./コーディングとテストガイド_AI-DLC版.md) - AI が Red-Green-Refactor を回し人が承認ゲートで全行検証する Bolt 実装フロー、AI 生成コード・テストのレビュー観点、ガードレール
47
- - [BDD導入ガイド](./BDD導入ガイド.md) - 『Living Documentation』の BDD 論に基づき、スリーアミーゴの会話・フィーチャーファイルの構造・仕様詳細・タグ・プロパティベーステストを整理し、日本語 Gherkin の書き方と Cucumber の処理系選定・インストール・ステップ定義・Red-Green-Refactor・生きたドキュメント公開までの実装手順をまとめた導入ガイド。
48
-
49
- ### 開発・運用
50
-
51
- - [リリースガイド](./リリースガイド.md)
52
- - [リリース・イテレーション計画ガイド](./リリース・イテレーション計画ガイド.md)
53
- - [リリース・イテレーション計画ガイド(AI-DLC 版)](./リリース・イテレーション計画ガイド_AI-DLC版.md) - Intent → Unit → Bolt の計画、承認ゲート駆動の検証、エントロピー評価による見積もりと進捗指標
54
- - [環境変数管理ガイド](./環境変数管理ガイド.md)
55
- - [言語別開発ガイド](./言語別開発ガイド.md)
56
- - [Java アプリケーション環境構築ガイド](./Javaアプリケーション環境構築ガイド.md)
57
- - [TypeScript アプリケーション環境構築ガイド](./TypeScriptアプリケーション環境構築ガイド.md)
58
- - [運用スクリプト作成ガイド](./運用スクリプト作成ガイド.md)
59
-
60
- ### ツール
61
-
62
- - [Codex CLI MCP アプリケーション開発フロー](./CodexCLIMCPアプリケーション開発フロー.md)
63
- - [Codex CLI MCP サーバー設定手順](./CodexCLIMCPサーバー設定手順.md)
64
- - [SonarQube ローカル環境セットアップ手順書](./SonarQubeローカル環境セットアップ手順書.md)
65
- - [Vim 操作マニュアル](./Vim操作マニュアル.md)
66
- - [OKF 導入ガイド(Open Knowledge Format v0.2)](./OKF導入ガイド_V0.2.md)
1
+ # リファレンス
2
+
3
+ 開発ガイドラインやベストプラクティスのリファレンスドキュメントです。
4
+
5
+ ## ドキュメント一覧
6
+
7
+ ### 基本理念
8
+
9
+ - [よいソフトウェアとは](./よいソフトウェアとは.md)
10
+ - [ロジカルシンキング](./ロジカルシンキング.md)
11
+ - [開発ガイド](./開発ガイド.md)
12
+ - [開発ガイド(AI-DLC 版)](./開発ガイド_AI-DLC版.md) - 開発ライフサイクルを Inception・Construction・Operation で読み替え、各活動の AI と人の分担と AI-DLC 版ガイドへの入口を示す
13
+ - [メンタルモデル構築ガイド(汎用版)](./メンタルモデル構築ガイド_汎用版.md) - 新しい技術・業務領域・学問を「使えるレベル」まで身につけるための 5 フェーズ(土台・構造抽出・練習・自動化・検証)と、落とし穴チェックリスト・心構え・適用例
14
+ - [エクストリームプログラミング](./エクストリームプログラミング.md)
15
+ - [AI-DLC 導入ガイド](./AI-DLC導入ガイド.md) - AWS が提唱する AI-DLC の 10 原則・成果物・フェーズ・参照実装(aidlc-workflows)と、XP ベースの開発ライフサイクル・Skills 体系への組み込み方
16
+ - [AI-DLC 用語集](./AI-DLC用語集.md) - AI-DLC の用語を基本概念・成果物・フェーズと儀式・計画・実装・参照実装の区分で定義し、XP・Scrum との対応を示す
17
+ - [ドキュメント構成ガイド](./ドキュメント構成ガイド.md) - 単一企業・統合戦略・複数プロジェクトのコンセプトに基づく docs/ と apps/ の構成規約
18
+ - [Living Documentation導入ガイド](./LivingDocumentation導入ガイド.md) - 『Living Documentation』に基づくドキュメントの再定義と 4 原則、知識の活用・拡張・キュレーション、Living Glossary・Living Diagram、ランタイムドキュメンテーションと、本プロジェクトの成果物への適用方法
19
+ - [アノテーション導入ガイド](./アノテーション導入ガイド.md) - 設計判断・意図・根拠をコード上の構造化されたアノテーションとして残す導入手順(語彙カタログ、命名・コミット規約、ツール連携と検証)
20
+ - [ダイナミックキュレーション導入ガイド](./ダイナミックキュレーション導入ガイド.md) - 既存の知識から目的に必要な少数を安定した基準で自動的に選び出す導入手順
21
+ - [ガイドツアー・サイトシーイング導入ガイド](./ガイドツアー・サイトシーイング導入ガイド.md) - コードの見どころ(サイトシーイング・マップ)と処理の流れ(ガイドツアー)をアノテーションから生成する導入手順
22
+
23
+ ### 経営・ビジネス
24
+
25
+ - [企業経営論](./企業経営論.md)
26
+ - [運営管理](./運営管理.md)
27
+
28
+ ### 分析・設計
29
+
30
+ - [経営戦略分析ガイド](./経営戦略分析ガイド.md)
31
+ - [ビジネスアーキテクチャ分析ガイド](./ビジネスアーキテクチャ分析ガイド.md)
32
+ - [要件定義ガイド](./要件定義ガイド.md)
33
+ - [ユースケース作成ガイド](./ユースケース作成ガイド.md)
34
+ - [ユースケース作成ガイド(AI-DLC 版)](./ユースケース作成ガイド_AI-DLC版.md) - Mob Elaboration で AI が初稿を書き人が検証する手順、人と AI の契約としての記述基準、AI 生成物の検証観点
35
+ - [アーキテクチャ設計ガイド](./アーキテクチャ設計ガイド.md)
36
+ - [データモデル設計ガイド](./データモデル設計ガイド.md)
37
+ - [ドメインモデル設計ガイド](./ドメインモデル設計ガイド.md)
38
+ - [UI 設計ガイド](./UI設計ガイド.md)
39
+ - [インフラ設計ガイド](./インフラ設計ガイド.md)
40
+
41
+ ### 品質・テスト
42
+
43
+ - [テスト戦略ガイド](./テスト戦略ガイド.md)
44
+ - [非機能要件定義ガイド](./非機能要件定義ガイド.md)
45
+ - [運用要件定義ガイド](./運用要件定義ガイド.md)
46
+ - [コーディングとテストガイド](./コーディングとテストガイド.md)
47
+ - [コーディングとテストガイド(AI-DLC 版)](./コーディングとテストガイド_AI-DLC版.md) - AI が Red-Green-Refactor を回し人が承認ゲートで全行検証する Bolt 実装フロー、AI 生成コード・テストのレビュー観点、ガードレール
48
+ - [BDD導入ガイド](./BDD導入ガイド.md) - 『Living Documentation』の BDD 論に基づき、スリーアミーゴの会話・フィーチャーファイルの構造・仕様詳細・タグ・プロパティベーステストを整理し、日本語 Gherkin の書き方と Cucumber の処理系選定・インストール・ステップ定義・Red-Green-Refactor・生きたドキュメント公開までの実装手順をまとめた導入ガイド。
49
+
50
+ ### 開発・運用
51
+
52
+ - [リリースガイド](./リリースガイド.md)
53
+ - [リリース・イテレーション計画ガイド](./リリース・イテレーション計画ガイド.md)
54
+ - [リリース・イテレーション計画ガイド(AI-DLC 版)](./リリース・イテレーション計画ガイド_AI-DLC版.md) - Intent → Unit → Bolt の計画、承認ゲート駆動の検証、エントロピー評価による見積もりと進捗指標
55
+ - [環境変数管理ガイド](./環境変数管理ガイド.md)
56
+ - [言語別開発ガイド](./言語別開発ガイド.md)
57
+ - [関数型プログラミングガイド(Kotlin 編)](./関数型プログラミングガイド_Kotlin編.md) - 純粋関数、不変データ、Either と Raise によるエラーの型表現、suspend による副作用管理、構造化並行性、イベントソーシングによるアーキテクチャ設計、プロパティベーステスト、静的解析(detekt・ktlint・PMD)のルール設定と、各章の規約を PMD のカスタムルール(14 個)にしたものまでを、Kotlin・Arrow・kotlinx.coroutines で実践する要点
58
+ - [関数型プログラミングガイド(Rust 編)](./関数型プログラミングガイド_Rust編.md) - 純粋関数、所有権と不変データ、Option と Result によるエラーの型表現、async による副作用管理、tokio による並行処理、イベントソーシングによるアーキテクチャ設計、プロパティテストと法則のテスト、clippy のルール設定(17 件を実行で確認)までを、Rust で実践する要点
59
+ - [Java アプリケーション環境構築ガイド](./Javaアプリケーション環境構築ガイド.md)
60
+ - [TypeScript アプリケーション環境構築ガイド](./TypeScriptアプリケーション環境構築ガイド.md)
61
+ - [運用スクリプト作成ガイド](./運用スクリプト作成ガイド.md)
62
+
63
+ ### ツール
64
+
65
+ - [Codex CLI MCP アプリケーション開発フロー](./CodexCLIMCPアプリケーション開発フロー.md)
66
+ - [Codex CLI MCP サーバー設定手順](./CodexCLIMCPサーバー設定手順.md)
67
+ - [SonarQube ローカル環境セットアップ手順書](./SonarQubeローカル環境セットアップ手順書.md)
68
+ - [Vim 操作マニュアル](./Vim操作マニュアル.md)
69
+ - [OKF 導入ガイド(Open Knowledge Format v0.2)](./OKF導入ガイド_V0.2.md)
@@ -0,0 +1,203 @@
1
+ # メンタルモデル構築ガイド(汎用版)
2
+
3
+ 2026-11-07
4
+
5
+ ## このガイドについて
6
+
7
+ メンタルモデルとは、実世界の事象や問題解決の手順をひとつにまとめた頭の中の枠組みで、知識を「実行できるノウハウ」に変えるものである (1, 5, 6)。本ガイドは、どんな分野にも当てはまる作り方を、5つのフェーズと2つの支え(落とし穴の点検、心構え)にまとめる。
8
+
9
+ - **対象**: 新しい技術、業務領域、学問、資格など、何かを「使えるレベル」まで身につけたい人。分野は問わない。
10
+ - **根拠**: 『使える脳の鍛え方 成功する学習の科学』の読書メモから作った「メンタルモデル構築マインドマップ」。各項目の末尾の数字は同書の章を示す。
11
+ - **特定分野への当てはめ**: 文末の「適用例」で、技術習得、業務知識、読書、試験の4場面に落とし込む。
12
+
13
+ 基本方針は3つ。
14
+
15
+ 1. **モデルは与えられるものではなく、自分で組み上げるものである。** わかりやすい説明を聞いても、自分で原則を抽出し、思い出す努力をしなければ、使えるモデルにはならない (4, 5)。
16
+ 2. **一度作って終わりではなく、作り直し続ける。** 検証で見つかった弱点を材料に、前のフェーズに戻る。古い手がかりは新しい手がかりに置き換える (4, 7)。
17
+ 3. **自分の感覚ではなく、外部のものさしで判断する。** 「わかった」「できる」という感覚は当てにならない。テスト、フィードバック、実際の結果で確かめる (5)。
18
+
19
+ ## 全体像
20
+
21
+ 構築は循環する。検証で見つかった弱点を材料に、該当するフェーズへ戻って作り直す。
22
+
23
+ ```mermaid
24
+ flowchart LR
25
+ P1[フェーズ1<br>土台を作る<br>予備知識と精緻化] --> P2[フェーズ2<br>構造を抽出する<br>原則と枠組み]
26
+ P2 --> P3[フェーズ3<br>練習で鍛える<br>想起 間隔 交互 多様]
27
+ P3 --> P4[フェーズ4<br>自動化する<br>ひとかたまりに符号化]
28
+ P4 --> P5[フェーズ5<br>検証し更新する<br>テストとフィードバック]
29
+ P5 -->|弱点を見つけて戻る| P1
30
+ S1[心構えで支える] -.-> P3
31
+ S2[落とし穴に気づく] -.-> P5
32
+ style P5 fill:#e7f1fb,stroke:#3a6fb0,stroke-width:2px
33
+ style S1 fill:#f0efec,stroke-dasharray:4 4
34
+ style S2 fill:#f0efec,stroke-dasharray:4 4
35
+ ```
36
+
37
+ 実線は構築の流れ、破線は支えを示す。心構えは練習の負荷に耐えるために、落とし穴の点検は検証を甘くしないために働く。
38
+
39
+ | フェーズ | 目的 | 主な活動 | 完了の目安 |
40
+ | --- | --- | --- | --- |
41
+ | 1 土台を作る | 既に知っていることと新しい知識をつなぐ | 全体像の把握、精緻化、具体例への当てはめ | 主要な概念を自分の言葉で説明できる |
42
+ | 2 構造を抽出する | 個々の知識を原則と枠組みにまとめる | 原則の抽出、取捨選択、類似概念の比較 | 何も見ずに全体の構造を描ける |
43
+ | 3 練習で鍛える | 判別力と応用力をつける | 想起、間隔、交互、多様、生成、省察 | 条件を変えても再現・応用できる |
44
+ | 4 自動化する | 意識せずに使える状態にする | 計画的な練習、実環境での反復 | 考える前に手が動く |
45
+ | 5 検証し更新する | 実力を客観的に測り、弱点を特定する | テスト、フィードバック、誤りの分析 | 誤りの原因を自分で説明できる |
46
+
47
+ フェーズは期間で厳密に区切らない。全体では1から5へ重心が移るが、ひとつの概念ごとに小さく回すのが普通である。
48
+
49
+ ## フェーズ1 土台を作る
50
+
51
+ モデルは既に知っていることの上にしか組み上がらない。最初の仕事は暗記ではなく、新しい知識を自分の既知と結びつける材料集めである。
52
+
53
+ - **先に全体像を置く。** 分野の範囲、主要な構成要素、それらの関係を1枚にまとめてから細部に入る。個々の知識は、より大きなコンテキストに当てはめると定着しやすい (1)。
54
+ - **予備知識の不足を先に埋める。** 土台がない状態で難しい素材に挑むと、乗り越えられない「望ましくない困難」になる。入門資料や前提となる概念を先に押さえる (1, 4)。
55
+ - **精緻化する。** 新しい概念を自分の言葉に置き換え、既に知っていることと関連づけて意味を与える。既知と結びつけば、記憶できる量に実質的な限界はない (1, 4)。
56
+ - **抽象を具体に当てはめる。** 抽象的な概念は、自分の経験や身近な事例に当てはめて理解する。自分に関わるほど学習は強化される (1)。
57
+ - **誰かに説明する。** 口に出すか、数行で書く。説明に詰まった箇所が理解の穴であり、次に埋めるべき場所になる (8)。
58
+ - **読むのは1、2回まで。** 再読は時間がかかり、記憶に残らず、理解したという錯覚を生む。読んだら本を閉じて、重要な概念は何か、既知とどう関係するかを自問する (1, 8)。
59
+
60
+ ## フェーズ2 構造を抽出する
61
+
62
+ 事実を集めるだけではモデルにならない。根本の原則を取り出し、何を残し何を捨てるかを判断して、個々のパーツの集合以上の構造にまとめる (6)。
63
+
64
+ - **重要なアイデアを読み取る。** 新しい素材から顕著な概念を抽出し、一貫した枠組みを作る。情報の羅列ではなく「これが肝だ」と言える数個の原則に絞る (1, 6)。
65
+ - **「なぜそうなるか」を規則で言う。** 個別の事例を先例として覚えるのではなく、背後にある規則を言葉にする。規則で学ぶ人は、学んだことを新しい状況に当てはめる能力に優れる (6)。
66
+ - **取捨選択する。** 新しい情報を構造に加えるか、脇によけるかを判断する。これができることが構築力であり、構築力の低い人は残す情報と捨てる情報がわからない (6)。
67
+ - **似た概念は並べて違いを書く。** 混同しやすいものは、共通点と相違点を一覧にする。種類を見分ける判別力の下地になる (4)。
68
+ - **白紙から描き出して確かめる。** 何も見ずに構造を再現し、描けなかった部分を補う。きれいにまとめたノートを眺めても構造は身につかない (2)。
69
+ - **経験を物語にする。** 何がうまくいき、何がうまくいかなかったか、次は何を試すかを振り返り、物語の形にして構造に加える (6)。
70
+
71
+ ## フェーズ3 練習で鍛える
72
+
73
+ 努力を要する想起と、条件を変えた練習が、学んだことをモデルに統合し、判別力と汎用性を持たせる (4)。どれも「やりにくい」と感じるのが正常で、その負荷が定着を生む。
74
+
75
+ | 練習法 | やり方 | 避けたいやり方 | 効果 |
76
+ | --- | --- | --- | --- |
77
+ | 想起練習 (2, 4) | 資料を見ずに記憶から呼び出す。自分にクイズを出す | 資料を読み返す。下線を引く | 思い出す努力が記憶を再統合し、反射的に呼び出せるようになる |
78
+ | 間隔練習 (3) | 少し忘れた頃に、同じ内容を複数回思い出す | 同じ日に繰り返して完璧にする | 忘れかけてから思い出すことで統合が促される |
79
+ | 交互練習 (3, 4) | 2つ以上の種類や分野を混ぜて取り組む | 1種類を習得してから次へ進む | 種類による違いを見抜く判別力がつく |
80
+ | 多様練習 (3, 4) | 条件、状況、形式を変えて同じことを行う | 同じ条件で同じことを繰り返す | 別の状況に適用できる汎用性ができる |
81
+ | 生成 (4) | 教わる前に自分で解こうとする。間違えてよい | 答えや解法を先に覚える | 解答がわかりやすくなり、長く記憶に残る |
82
+ | 省察 (2, 3) | 何が起きた、何をした、どうなった、次はどうするかを書く | やった量だけを記録する | 想起と精緻化と生成を一度に行う |
83
+
84
+ ```mermaid
85
+ flowchart TB
86
+ subgraph 練習の6要素
87
+ direction LR
88
+ R[想起] --> S[間隔]
89
+ S --> I[交互]
90
+ I --> V[多様]
91
+ end
92
+ G[生成<br>教わる前に解く] --> R
93
+ R --> F[省察<br>想起 + 精緻化 + 生成]
94
+ F -->|次はどうするか| G
95
+ ```
96
+
97
+ 運用のポイント。
98
+
99
+ - **想起は初日から始める。** 練習は構造ができてから、ではない。学んだその日から、資料を閉じて思い出す (2)。
100
+ - **できるようになっても練習箱から出さない。** 2、3回できただけで終わりにしない。習熟したものは頻度を下げるが、ゼロにはしない (3, 5)。
101
+ - **フィードバックは必ず受ける。** 想起の後に正解を確かめる。訂正されれば間違いを覚えたままにはならない。すぐより、少し遅らせたフィードバックのほうが長続きする (2)。
102
+ - **伸び悩みを失敗と読まない。** 交互練習と間隔練習は、練習中の成績が下がって見える。集中練習の好成績は習得段階の一時的な力で、定着した力ではない (3)。
103
+ - **本番と同じ条件で練習する。** 学習がどれだけ役立つかは、知識そのものより、その知識をもとにどう練習したかで決まる (3)。
104
+
105
+ ## フェーズ4 自動化する
106
+
107
+ 繰り返し使われたモデルは「ひとかたまり」に符号化され、意識しなくても働くようになる。これが専門的技能の特徴である (7)。
108
+
109
+ - **ひとかたまりにする。** 一連の判断と行動を繰り返し使うことで、脳はそれをひとつの手順として符号化し、習慣のように自動的に呼び出して応用できるようになる (7)。
110
+ - **計画的な練習を行う。** 現在の能力を少し超える部分に絞って、意図的に取り組む。だいたい楽しくなく、改善点の特定とフィードバックにはコーチや仲間の助けが要る (4, 7)。
111
+ - **一人で練習する時間を確保する。** 最高レベルの人は、他の人より一人でする計画的な練習に長い時間を割いている (7)。
112
+ - **記憶術は理解の後に使う。** 語呂合わせや記憶の宮殿は、理解した内容を整理していつでも引き出すための道具であり、学習そのものの代わりにはならない。想起を繰り返せば、やがて手がかりも不要になる (7)。
113
+ - **専門性は分野ごとに積み上げる。** 優れた実績はその専門分野に限られる。ある分野のモデルは別の分野にそのまま移らないので、新しい分野では再びフェーズ1から始める (7)。
114
+ - **遺伝ではなく練習の量と質で決まる。** 意欲、時間、続ける規律があれば、平凡な才能でも専門家になれる可能性がある (7)。
115
+
116
+ ## フェーズ5 検証し更新する
117
+
118
+ モデルの正しさは主観では測れない。外部のものさしで確かめ、弱点を見つけて作り直す (5)。
119
+
120
+ ダイナミック・テストの3ステップを繰り返す (6)。
121
+
122
+ ```mermaid
123
+ flowchart LR
124
+ T1[1 足りない部分を知る<br>実体験か筆記テスト] --> T2[2 集中的に高める<br>原因のフェーズへ戻る]
125
+ T2 --> T3[3 再テストする<br>間隔をあけて再び試す]
126
+ T3 -->|まだ足りない練習を特定| T1
127
+ ```
128
+
129
+ 1. **足りない部分を知る。** 実体験か筆記テストで、知識や技術の足りない部分を特定する。
130
+ 2. **集中的に高める。** 足りない部分について、フェーズ1から4のどこに原因があるかを判定し、そこへ戻る。
131
+ 3. **再テストする。** 間隔をあけて再び試し、何が上達したか、特に何の練習がまだ足りないかに注意を払う。
132
+
133
+ 外部のものさしの例。
134
+
135
+ | ものさし | 使い方 |
136
+ | --- | --- |
137
+ | 自分へのテスト | 資料を見ずに再現する。2、3回正解しただけで範囲から外さない (5) |
138
+ | フィードバック | 指導者は与え、学習者は自分から求める。否定的なフィードバックは普段滅多に受けられないので、意識して取りに行く (5) |
139
+ | 仲間や同僚の評価 | 経験豊富な人と一緒に働く、チームで技量を補い合う (5) |
140
+ | シミュレーション | 実環境で想定される要求や変動条件を模した訓練で、習熟度と改善点を知る (5) |
141
+ | 実際の結果 | 本番で何が起きたかを、自分の予想と突き合わせる |
142
+
143
+ - **誤りは原因で分類する。** 知らなかった、構造を見抜けなかった、似たものと混同した、思い出せなかった、手順を誤った。原因によって戻るフェーズが違う。
144
+ - **正しくできたものも点検する。** 根拠を言えずにうまくいったものは、誤りと同じ扱いにする (5)。
145
+ - **手がかりを更新する。** 忘れるのは知識ではなく、想起の手がかりである。古い手がかりを忘れて新しい手がかりを作り、過去の学びに立ち返って新しい知識と関連づけ続ける (1, 4)。
146
+ - **モデルが機能しない場面に気づく。** 既存のモデルは強力なぶん、合わない場面でも判断を押し通してしまう。合わない場面を見分ける能力そのものを育てる (5)。
147
+
148
+ ```mermaid
149
+ flowchart TD
150
+ E{誤りの原因は?}
151
+ E -->|知らなかった| B1[フェーズ1 土台]
152
+ E -->|構造を見抜けなかった| B2[フェーズ2 構造]
153
+ E -->|似たものと混同した| B23[フェーズ2 と 3]
154
+ E -->|思い出せなかった| B3[フェーズ3 練習]
155
+ E -->|手順を誤った、時間が足りない| B4[フェーズ4 自動化]
156
+ ```
157
+
158
+ ## 落とし穴チェックリスト
159
+
160
+ 出来上がったモデルは強力なぶん、見えなくなり、誤作動する。自分では気づきにくいことを前提に、定期的に点検する (5)。
161
+
162
+ - [ ] 資料を読んで「わかった」と感じただけで、何も見ずに再現していない (1)
163
+ - [ ] すらすら読めること、聞き覚えがあることを、習得したことと取り違えている (1, 5)
164
+ - [ ] わかりやすい説明を受けて、自分も最初から知っていたと思い込んでいる (5)
165
+ - [ ] 何度かできただけで、もう練習不要として外した (3)
166
+ - [ ] 学習時間や量で進み具合を測っている (1)
167
+ - [ ] 記憶に自信があることを、正確であることと取り違えている (5)
168
+ - [ ] 都合のよい結論で自分を説得している(動機づけられた推論)(5)
169
+ - [ ] 自分が習熟したことを、他人もすぐ理解できると見積もっている(知識の呪い)(5)
170
+ - [ ] 既存のモデルが合わない場面で、無理に当てはめている (5)
171
+ - [ ] 否定的なフィードバックを、取りに行かずに済ませている (5)
172
+
173
+ 能力不足の人ほど、自分の能力不足に気づかない。有能と無能の区別がつかないからである。対処法は、自分の能力を正確に測る技術を身につけること、つまりメタ認知を正確にすることである (5)。
174
+
175
+ ## 適用例
176
+
177
+ 同じ5フェーズを、場面ごとにどう当てはめるかの例。自分の場面に近いものから読み替える。
178
+
179
+ | フェーズ | 技術習得(新しい言語や設計手法) | 業務知識(新しい部署や業界) | 読書(専門書) | 資格試験 |
180
+ | --- | --- | --- | --- | --- |
181
+ | 1 土台 | 公式チュートリアルを1周し、既知の言語や手法との対応を書く | 業務の全体の流れを1枚にし、自分の経験と重なる点を探す | 目次と序章から著者の主張を予想し、既知の本と結びつける | 出題範囲と配点を1枚にし、実務との接点を書く |
182
+ | 2 構造 | 設計原則を数個に絞り、「なぜこの書き方か」を規則で言う | 判断の基準と例外を整理し、残す知識と捨てる知識を分ける | 章ごとの要点を白紙から描き、主張の構造を再現する | 論点マップを作り、論点と判断の原則と問われ方を整理する |
183
+ | 3 練習 | 資料を見ずに小さなものを作る。複数の言語や手法を交互に使う | 実際の案件で判断し、結果を省察する。異なる種類の案件を混ぜる | 読んだ数日後に要点を書き出す。別の本と交互に読む | 解説を見る前に解く。科目と形式を混ぜ、間隔をあけて解き直す |
184
+ | 4 自動化 | 定型処理を考えずに書けるまで、時間を計って繰り返す | 頻出の判断を即断できるまで、実案件で繰り返す | 自分の言葉で他人に説明できるまで反復する | 頻出論点を時間内に処理できるまで、本番条件で演習する |
185
+ | 5 検証 | コードレビュー、本番での不具合、ペアでの作業 | 上司や同僚のフィードバック、実際の結果 | 書評を書く、読書会で説明する、関連書と突き合わせる | 年度別過去問、模試、誤答の原因分類 |
186
+
187
+ 場面によって重さが変わる部分。
188
+
189
+ - **フィードバックの入手先が違う。** 技術習得と業務知識は実環境で結果が返ってくるが、読書と試験は自分で検証の場を作らないと、いつまでも「わかった気」のままになる (5)。
190
+ - **実務経験は土台にもなり、落とし穴にもなる。** 現場で作ったモデルが、新しい分野の定義や基準とずれていても気づきにくい (5)。
191
+ - **自動化の程度は目的で決める。** 試験や定型業務は即答まで持っていくが、読書で得た概念は、省察と精緻化で構造に組み込めれば十分なことが多い。
192
+
193
+ ## 心構え
194
+
195
+ モデルを作り直し続けるには、脳は変えられるという前提と、困難や失敗を材料として受け取る姿勢が要る。
196
+
197
+ - **脳は変えられる。** 学ぶたびに脳には変化が起きている。努力を要する学習は神経のつながりを作り、モデルを増やし、能力の限界を広げる (1, 7, 8)。
198
+ - **遺伝子は原材料にすぎない。** 成功は、モチベーションと自己信頼から生まれる集中力と自制心に大きく左右される。特別な遺伝子より、自制心、決意、粘り強さである (7)。
199
+ - **成長の意識を持つ。** 知能は固定されておらず、本人のやる気次第で大きく変わる。根本的な違いは、失敗の捉え方にある (7)。
200
+ - **学習を目標にする。** 成果を目標にすると、人はリスクを避けるようになる。学習を目標にすれば、難しい問題に果敢に取り組み、粘り強く頑張れる (4, 7)。
201
+ - **失敗は情報である。** 失敗は能力不足の尺度ではなく、努力の証であり、次に何を直すかを教える材料である。うまくいくこととのいかないことの違いは、失敗からしか学べないことがある (4, 7, 8)。
202
+ - **難しさを歓迎する。** 乗り越えられる程度の困難が学習を深める。難しいと感じても、間違っていると思わない (4, 6)。
203
+ - **「これがベスト」という感覚に頼らない。** 自分に合うと感じる学び方ではなく、記録された結果で方法を選ぶ (6)。