引き継ぎから始めるコンテキストエンジニアリング

Transcript

1. PM MEETUP 2026.08.31 引き継ぎから始めるコンテキストエンジニアリング ※本資料は登壇者個人の経験および見解に基づくものであり、所属組織の公式な見解、開発標準または業務上の判断を示すものではありません。 また、掲載内容は社外公開用に一部抽象化しています。 1
2. SELF INTRODUCTION 自己紹介 所属 株式会社ふくおかフィナンシャルグループ（FFG） システムソリューション部 銀行アプリ開発 iOSテックリード イラスト 野々上 夏葵 Nonoue Natsuki 業務 銀行アプリの機能開発・マネジメントを担当 経歴 他アプリのiOSエンジニア →FFGに中途入社 →銀行アプリ開発 iOSテックリード 2
3. CURRENT SITUATION 状況：人から人への直接的な知識移転を前提にできなかった 取り組み開始時に見えていたこと 知識の集中 従来手法の制約 特定領域の知識が一部メンバーに集中 引き継ぎ相手を前提にできない 設計判断や運用上の背景が、一部メンバーへ集中していた。 特定の相手への説明や作業伴走だけでは、 限られた条件の中で、知識を再利用可能な形へ移す必要があった。 継続的な知識継承にならないと考えた。 特定の人へ渡すのではなく、後から参照できる資産へ移す方法を考えた 3
4. THE DECISION 問題の再定義：知識の移転先を「特定の人」から「再利用可能な資産」へ 引き継ぎの前提を変えた BEFORE AFTER 普通の引き継ぎ 今回 特定の引き継ぎ相手を前提にしない 手順書を補助として、口頭説明と作業伴走で知識を渡す 人とAIが参照できる資産へ、判断の背景を残す 担当者が変わるたびに、同様の知識移転が必要になる 結果として、コンテキストエンジニアリングの 取り組みになった 新たに参加する人が、「詳しい人」だけに依存せず、資産から立ち上がれる状態を目指す 4
5. WHY MATTERS 限られた条件で、何を優先して残すのか 寄り道の結論 What：現在の実装や仕様 Why / Why not：なぜ採用したか、しなかったか コード、テスト、既存資料などから確認できる情報は、 採用されなかった選択肢や、当時の制約は 重複した再記述を避ける。 コードに残りにくい。 ただし、コードから確認できない要求・合意事項・運用条件 過去の判断を正解として固定するのではなく、 は別途記録する。 次の検討の出発点として残す →判断の背景を、特定の人へ聞かなければ分からない状態から、 後から参照・検証できる状態へ 5
6. APPENDIX 意思決定の種類： 3層の仕分け 2軸で決まる：「技術的か否か」 ×「粒度（局所か、跨ぐか）」 局所 ─ 1ファイルで閉じる 技術的 跨ぐ ─ 設計・複数ファイルに及ぶ コードコメント Architecture Decision Record（Git管理） 局所的な実装意図を、対象コードの近くに残す。 複数の実装や設計へ影響する技術判断を記録する。 コード変更時に、人やAIが併せて参照しやすい。 判断時点の前提、選択肢、採用理由、棄却理由を残す。 Decision Log（Git管理・その他ナレッジベース） 技術の外 業務、運用、スコープなど、コード外の判断を記録する。 必要に応じて、関連するコードやADRから参照できる場所に置く。 例）対応不要判断のBug・チーム体制等 記録先は、「その判断が影響する範囲」と「コード内で完結するか」で決める 6
7. APPROACH 01 やったこと①過去の設計判断を、後から記録する 決定から時間が経った後に ADRを書く 1 先にコードを掘る 2 具体物を持って聞く 3 棄却案を聞く コミット履歴・ PRコメント・コードから 「思い出してください」だけでは、当時 選ばれなかった選択肢は ADRのドラフトを先に書く。 の背景を十分に引き出しにくい。 コードに痕跡がないことが多い。 手ぶらでヒアリングに行かない。 「このPRのこの判断、当時何がありまし 同じ調査を繰り返さず、 たか」などQA表を作成し、 前提が変わった際の再検討材料にする。 被ヒアリング者の負担を意識しながら、 伺いを立てる。 7
8. DETOUR 寄り道：文書の目的を分けて考えた 今回の試行で見えた、仕様情報と意思決定記録の違い ✕ 仕様情報は、実装変更に合わせた更新が必要になる ✕ 自然言語だけでは、画面や挙動の詳細を表現しにくい場合がある ✕ 文書の目的を明確にしないと、作成・レビュー・維持の負担が増える 現在の状態を示す情報 項目 判断の背景を示す情報 例 コード、テスト、仕様、運用手順 コードコメント、 ADR、Decision Log 他の情報からの確認 内容によってはコード等から確認可能 採用しなかった案や当時の制約は復元しにくい だから文書は 今回の方針：重複した再記述を避ける 将来の検討に必要なものを優先して残す 更新・扱い 現在の状態に合わせて更新する 判断時点の記録として保持し、 変更時は新しい判断との関係を示す 限られた条件の中で、コード等から復元しにくい判断の背景を優先して記録した。 ADRは正解を固定するものではなく、次の検討の出発点として扱う。 8
9. APPROACH 02 やったこと②実作業を通じて、判断の背景を言語化する 資産の原料を採る会として設計する 知識を持つ人は、原則としてタイピングしない 指示の前に意図を言う 手を動かすのは知らない人。知識を持つ人は口だけ。速さより移転。 「3行目を変えて」ではなく「なぜそこか」から。 一番大事で、一番崩れやすいルール。 詰まったら周りが「今、何を確認していますか？」と聞く。 題材は実タスク 書記は「初めて知ったこと」だけ 練習課題ではなく、実際の開発・運用タスクを題材にする。 全部書くと破綻する。誰かが「え、そうなの？」と思った瞬間だけ記録 モブの時間がそのまま実タスクの進捗になるため、 → そのままADR・ランブック候補に。 限られた稼働条件でも実施しやすい。 運用例：一定時間ごとに操作担当を交代し、終了時に新しく分かったことを共有する 9
10. VERIFICATION 移転できたか、検証できるのか 知識移転の効果を、単一の指標で厳密に測ることは難しい そこで、回答の妥当性、情報不足が生じた場面、新たに参加した人の立ち上がりを、代理的な確認材料として用いる。 事前確認 継続 実運用で確認 ①過去の判断を用いた確認 ②情報不足が生じた場面の記録 ③新たに参加した人の立ち上がり 過去の判断課題を題材に、 既存の情報だけでは判断できず、 既存の資産を利用して、必要な情報へ到達し、 記録された背景から妥当な回答へ 追加確認が必要になった場面を記録し、 実際の判断や作業を進められるか確認する。 到達できるか確認する。 知識の不足を確認する。 現時点では検証途中であり、知識移転の成立を確認できた事例ではない 10
11. CLOSING まとめ 01 02 引き継ぎの対象を、特定の人だけでなく、 コード等から確認しにくい、判断時点の前提・選択肢・ 後から参照できる資産として考えた。 採用理由・棄却理由を優先して残した。 03 04 ADRやモブは目的ではなく、 今回の取り組みはまだ検証途中であり、 判断の背景へ後から到達するための手段として試した。 知識移転への効果を確認できた段階ではない。 11