エンジニアのためのドキュメント力基礎講座～構造化思考から始めよう～

2025/11/29土にパシフィコ横浜で開催される、我が愛するBacklogWorldで登壇機会をいただきました。
AI全盛の今だからこそ改めて基本に立ち返り、わかりやすく構造化されたコミュニケーションのポイントとチームワークマネジメントへの活用をお話できたらと思います。
---
📢Backlog World 2025｜招待講演
中野康雄さん（ARアドバンストテクノロジ）登壇！
「実装よりも時間がかかるのは、仕様の記述」──そんな実感ありませんか？
構造化思考で“誤解なく伝える”スキルを鍛える、ドキュメント力基礎講座です✍️
#BacklogWorld 🗓️11/29 (土)📍パシフィコ横浜

Transcript

1. エンジニアのための ドキュメント力基礎講座 ～構造化思考から始めよう～ 2025年11月29日 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo） Backlog World 2025
2. 自己紹介 2 中野康雄（51） @yasuoyasuo ＡＲアドバンストテクノロジ株式会社（ARI） 取締役 執行役員 元BacklogWorld運営（2020～2024） ➢ 略歴 1999 ITエンジニア＆コンサルタント（10年） 2009 Webサービス企画＆開発管理（2年） 2011 マネジメントコーチとして独立（1.5年） 2012 現職へジョイン ➢ 趣味 食べ歩き、筋トレ、LEGO ➢ 最近はまっていること 昭和平成の名作巡り（北の国から、白い巨塔 等）
3. （PR）仲間を絶賛募集中です！ 3 DM開放しております カジュアル面談 お待ちしております！
4. エンジニアとして必要な ドキュメンテーション力とは？ 今日のテーマ 4 元々若手向けの研修メニューであるため 経験ある皆さまにはやや釈迦に説法感がある旨 ご了承ください
5. そもそもエンジニアにとってドキュメント力って必要？ 5 →これからますます重要になると思う
6. アジャイル時代は ドキュメントは書かなくて良い ドキュメントの必要性重要性は色褪せない 合意形成や情報共有のために ドキュメントは一定数必要 6
7. プロジェクト工数の7割はドキュメント作成 7 引用： » 2019年度調査『ソフトウェアメトリックス調査2020 システム開発・保守調査』の報告資料 JUAS 一般社団法人 日本情報システムユーザー協会 https://juas.or.jp/news/topics/2823/ 実はシステム開発で プログラミングなど実装は 約 3割しかない
8. 今後AI駆動が広がれば更に重要に 8 設計 実装 テスト リリース AI Suite 選択・設計 品質・効果 レビュー 効果測定 方法の設計 非機能 テスト 効果検証 ドメイン知識 ペインポイント の理解 ビジネス効果の 設計 ユーザー体験の 設計 非機能の明確化 効果の明確化 要求分析 要件定義 AI駆動開発ツール(Cursol, Claude Code, GitHub Copilot, Devin etc) ライフサイクルの継続的な アップデート 人の領域 AIの領域 参考：https://www.creationline.com/tech-blog/chatgpt-ai/ai/71718
9. AIをさらに賢くするインテリジェンスとしてのドキュメント 9 ドキュメントの価値は フローからストックへ AIエージェント時代には 更にレバレッジがかかる 拙稿：【参加レポート】Microsoft Ignite 2025 in San Francisco｜https://qiita.com/yasuoyasuo/items/5d61c81021387ab27a3d より
10. ドキュメント作成力はキャリア構築上も資産価値が高い 10 小手先のテクニック 模倣されにくく 長期的に発揮できる競争力 誰でもできる作業 参入障壁が低いスキル 履歴書に書ける実績 プロフェッショナルな能力 短期的に築ける 長期的に築く 目に 見えない 目に 見える
11. ヌーラボさんの提唱する「チームワークマネジメント」 11 https://nulab.com/ja/teamwork-management/ https://toyokeizai.net/articles/-/877554
13. 今日のアジェンダ • ドキュメント作成に求められるスキル • 構造化思考とは？ • 構造化思考の説明と演習 • 構造化思考を効率的に進めるために • 構造化思考を踏まえたアプローチ • その他のスキル • 最後に 13
14. ドキュメント作成に求められるスキル 14
15. システム開発系ドキュメントの特徴 • 自分以外の誰かが読み、更新されることが前提とされる ➢ レビュワー ➢ 後工程の担当者 ➢ 保守担当者 ➢ AI • 抜け漏れや、読み手によって解釈が異なることは許されない ➢ 検討すべきことの抜け漏れは手戻り（工数増）につながる ➢ 解釈が異なる記述をしてしまった場合も同様 • 納期があり生産性が求められる ➢ 書き手が納得いくまで時間をかけて良いわけではない ➢ 事前に作成工数の見積りが求められる 15
16. システム開発系ドキュメントに求められること • 当たり前品質をクリアしていること ➢ 誤字脱字、最低限の体裁、表記の統一 ➢ 書くべき項目がすべて書かれている ➢ 内容が正確 • 読み手（特にAI！）にわかりやすいこと ➢ 全体構成、見出しの粒度、順序が適切 ➢ 各文章がわかりやすい ➢ 体裁が適切に「デザイン」されていること（タイトル、表紙、インデント、ページ番号など） • 生産性や作業管理性が高いこと ➢ 標準化され一定のルールがある方が書きやすく、レビューもしやすい ➢ 作成にかかるタスクが分解できている（見積りの精度が上がる） ➢ 完了までの段取りが出来ている（アウトライン化） 16
17. そもそもシステム開発とは どういった行為なのか？ まずその本質を理解することから はじめたい 効果的なドキュメンテーション力を得るために 17
18. シ ス テ ム 開 発 の 時 間 軸 システム開発の大きな流れ 要件 人間の 世界 システムの 世界 設計 実装（ソフトウェア/基盤） 要求 要望 仕様 要件 1.要望要求から要件に選別する 2.要件に対する仕様を記述する 3.仕様を満たすように設計する 4.設計通りに実装する 5.仕様＆要件の実現を確認する 18
19. シ ス テ ム 開 発 の 時 間 軸 要件は仕様化されなければ実現できない 要件 人間の 世界 システムの 世界 氏名を表示できたらいいな その他多くの要望 各ページに氏名を表示できること 各ページのヘッダ部分に 「◦◦[半角スペース]••」と表示する。 ◦◦は姓、••は名を表す。 ユーザー内 整理 QCD制約踏まえた 要求精査 各ページに氏名を表示したい 網羅的かつ 誤解を与えない 言語化 仕様の網羅的かつ誤解なき言語化が システム開発の最初の勘所 設計 実装（コード） 要求 要望 仕様 要件 • あったらいいなだよね？目的は？本当に必要？ • 個人の意見？みんなの意見？ • 要求の優先順位は？ • 予算や納期踏まえて今回どれやる？ • ページのどこ？ • どんな風に表示するの？ 参考： https://qiita.com/digdagdag/items/2808205d89344ab8a3a1 イメージ 19
20. システム開発ドキュメントの勘所 網羅的かつ 誤解なき言語化 20
21. 効果的なドキュメント作成に必要なスキル知識 構造化思考力 作文/表現技術 記述対象に 関する知識 特にここが ポイント！ 21
22. ユーザー向けドキュメントについてはどうか？ 22 エンジニアのためのドキュメントライティング / Docs for Developers and Paragraph Writing https://speakerdeck.com/nttcom/docs-for-developers-and-paragraph-writing
23. ドキュメントジャーニーは読み手理解から 23 エンジニアのためのドキュメントライティング / Docs for Developers and Paragraph Writing https://speakerdeck.com/nttcom/docs-for-developers-and-paragraph-writing
24. 読み手理解と計画立てから始めることを推奨 24 構造化思考が肝になる
25. 今回は構造化思考に 絞ってお話します 25
26. 構造化思考とは？ 26
27. 構造化思考とは？ 全体を分解したり 個別を集約することで 情報を整理する考え方 注：私の定義 27
28. 構造化思考 ２つのアプローチ １．全体を分解する ２．個別を集約する 大きなテーマを分解して整理する 思考の補助線を引き情報を整理する 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured どっちも大切 28
29. 構造化されている例 資料間の関係 ➢ 画面一覧と画面設計書 ➢ 機能一覧と各機能設計書 ➢ システム構成一覧と 構成別パラメータシート ➢ 移行全体スケジュールと 各移行作業詳細手順書 ➢ 共通仕様書と各個別仕様書 各資料内の目次構成 例：要件定義書 1. システム導入の目的と目標 2. システムの概要／システムの構想 3. システム導入後の業務フロー 4. 機能要求 5. 入力要求と出力要求 6. 品質・性能要求 7. セキュリティ要求 重複を避ける 漏れ重複ない章立て （一般例） 29
30. 構造化することのメリット（１） 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured ドキュメントを作る上で最も避けるべき「漏れとダブリ」をなくせる 30
31. 構造化することのメリット（２） 枠組みが共有できると 読み手に伝わりやすい なぜか？ 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured 31
32. 情報＝枠組み＋内容 「情報」とは「枠組み」と「内容」で構成される。 「枠組み」が共有できると「内容」を受け取りやすい。（文脈） 枠組み 内容 情報 前提事項 仕様 進め方 イメージ 画像引用：https://www.itmedia.co.jp/bizid/articles/1009/21/news058.html 32
33. 構造化のポイント 1. 上手に分ける 2. 文脈を意識する 3. 論点を見つける 33
34. 構造化のポイント（１）上手に分ける 分かる＝分ける 34
35. 「分ける」の上手下手はどこで決まるか？ 1. 漏れダブリをなくす 2. 粒感を揃える 3. 順序を整える 35
36. これを気持ち悪いと思えるか？ 春、夏、冬 野菜、肉、サンマ 昭和、平成、大正、令和 36
37. 枠組みの力を借りて情報伝達の精度を上げる 春、夏、秋、冬 野菜、肉、魚（サンマ） 大正、昭和、平成、令和 37
38. これらへの感度を上げよう 1. 漏れダブリをなくす 2. 粒感を揃える 3. 順序を整える 全体→詳細、時系列、大→小、頻出→レア、正常→異常 など 38
39. 構造化思考のポイント（２）文脈を意識する 文字列は何を伝えているのか？ 39
40. それぞれに意味がある 春、夏、秋、冬 野菜、肉、魚（サンマ） 大正、昭和、平成、令和 40 季節 食材 年号
41. こういう問題昔やりましたよね？ 問題：□に入るものを答えよ Q1：１, 2, 4, 8, □, 32, 64 Q2：J, F, M, A, M, □, J, A,・・・ 41 この問題の本質は、各Qの文脈を探すことにある
42. 文脈は理解を助けてくれる 42 文脈がない状態 文脈をつくる 文脈がある状態
43. 構造化思考のポイント（３）論点を見つける ある問題に対して答を見つけるために 考えるべきことを論点という 43
44. 今日の最重要ワード 論点 44
45. 論点とは その問いに答えるためには 何を考えるべきなのか？ どんなことを答えるべきなのか？ 45
46. 目次とはその資料の論点である 各資料内の目次構成 例：要件定義書 1. システム導入の目的と目標 2. システムの概要／システムの構想 3. システム導入後の業務フロー 4. 機能要求 5. 入力要求と出力要求 6. 品質・性能要求 7. セキュリティ要求 漏れ重複ない章立て （一般例） 46 要件定義書の論点 つまり 何を書けば 要件が定義できたと 言えるのか？
47. アインシュタインの言葉 「もし自分が死にそうな状況で、 助かる方法を考えるのに１時 間あるとしたら、最初の55分 は適切な質問を探すのに費や すだろう」 47 画像：https://honcierge.jp/articles/shelf_story/1521
48. 何かを考え、表現するときのコツ 何を伝えるべきなのか？（主題） ↓ それを伝えるためには 何を示せればよいのか？（論点） ↓ その内容 48 主題 論点1 論点2 論点X 内容1 内容2 内容X いきなり答を考えようとしない ・・・ ・・・
49. 構造化思考の演習 49
50. 構造化思考の演習 実際にやってみましょう 50
51. 構造化演習（１） 部門の飲み会の幹事を引き受けました。 参加数を最大化させられる案内文を考えたいです。 どんな項目が含まれているとよいですか？ 51
52. 構造化演習（１） 52 現実は こうかもしれないが・・・
53. 構造化演習（１）考え方（例） 53
54. 構造化演習（２） プロジェクトの振返りの意見を集めたいと思います。 依頼フォームを検討してください。 54
55. 構造化演習（2）考え方（例） ▪ 振返りで起こりがちな問題 ・誰のための振返り？ ・後半のことばかりに気になってしまい前半のことが抜け落ちる →PJ全体を見て重要なことがカバーできているか？ ・その場限り、いきあたりばったり。振り返ったあとに何か得るものがあるか？ ・評価に対する価値観の個人差はないか？（アピール型、遠慮型など） ▪振返りの目的は？ ルールや制度の変更？具体的改善活動の抽出？個人の成長？ 顧客との振返りであれば次の営業機会を探る場でもある 55
56. 演習のポイント いきなり項目を挙げはじめるのはNG 目的を果たすために 何を考えればよいかを考える （目的が指示されてなければ仮説を立てる） 56
57. 構造化思考を効率的に進めるために 57
58. 先輩達は考えた 汎用的な事柄を考え表現するのに 毎回論点から考えるのは 非効率だし品質もばらつく 58
59. そこで生まれたのが 主題と論点及びその表現方法などの 組み合わせ一式を フレームワーク/テンプレートという 59
60. いろいろあるので調べてみよう ただ過剰に頼りすぎると 思考が縛られることもあるので注意 60 フレームワークやテンプレートはあくまでも 主題を得るための論点の１つの形でしかない。 背景や文脈にのっとってテーラリング（応用）できる力が必要 フレームワークやテンプレートは 初心者には極めて効果的な手法
61. フレームワークの活用事例～振返り～ 61 » コミュニケーションの方向に着目したふりかえりの方法 - よこなのへたのよこずき https://ihcomega.hatenadiary.com/entry/2020/04/28/055258 • 「KPT （Keep/Probrem/Try） 法」でやっていた • でも過去振り返りの時間が足りなくなることが頻発 • 議論しなくてもよいことは議論しなくてもいいのでは？ • チーム(または個人) で続けたいこと • 自分 がドヤりたいこと • チームメンバー にお礼したいこと フレームワークを使うことがゴールにならないように 結果や得たい成果を常に忘れないようにしたい
62. 生成AIの活用 62 1. 次期基幹システムの方針 2. ARIの対応可能範囲 3. ERP導入の考え方 4. 過去の支援事例 5. 現在の進捗 6. 基幹システムの対象領域 7. プロジェクト体制 8. 過去の検討内容 9. システム刷新の進め方 求める論点について 出力してくれる 論点を出せる/評価できれば 生成AIをより有効に使いこなせる 悪くないけど 最適かは 状況次第 （確率論）
63. 構造化を踏まえたドキュメント作成アプローチ 63
64. 効果的なドキュメントを書くには？ 1. そのドキュメントの読み手と主題を 正しく把握する （誰のどんな問題を解決する資料なのか？） 2. その主題の論点を考える 3. 各論点について回答を深堀りし 適切に分類して、文脈構成を設計する 4. 詳細を言語化/図式化する 5. 見た目を最適化する 64 ★ 構 造 化 思 考 ★ 作 文 表 現 技 術
65. そのドキュメントの目的は明確か？ なんとなくの積み上げ ≠目的達成 65
66. ドキュメント作業に入るその前に ターゲットとなる読み手 目的や得たい成果 アプローチや論点 上司/依頼者と確認できているか？ 66
67. 仕事の進め方も同じ タスク←ゴール ゴールから考える 67
68. とりあえずまこなり社長の動画を見よう 68 https://www.youtube.com/watch?v=ArMNB_QTSXw
69. 構造化志向以外のスキルを高めるには？ 69
70. 効果的なドキュメント作成に必要なスキル知識（再掲） 構造化思考力 作文/表現技術 記述対象に 関する知識 特にここが ポイント！ 70 もちろん これらも大切
71. 今日の内容を改めて体系化して学びたい方 71 この本を 激しく推薦します！
72. 作文技術やPJ知識もめちゃくちゃ大切 参考図書やリンク集 こちら参考になれば 72 https://qiita.com/yasuoyasuo/items/1eb7298f91a44dce7abc
73. 作文技術を学ぶ上で激しくおすすめの資料 73 https://speakerdeck.com/namura/shui-gadoujian-temosoutosikashou-kequ-renaiwen-shu-shu-gong-kai-ban
74. こちらも良ければ読んでみて 74 • 用語は文書内で一貫性をもたせる • 曖昧な代名詞の利用は避ける • 受動態は避け、能動態を優先する • 強い動詞を選択する1 • 曖昧な動詞よりも意味が限定される動詞を選ぶ • 1文1メッセージ • 長い文章はリスト形式に変換する • 不要な言葉は排除する • 順序が重要な場合は番号付きリストを使用し、順序 が重要でない場合は箇条書きリストを使用する • リストを使う場合は言葉の並列性を保つ • 番号の付いたリストは命令語で始める • リストと表を適切に使う • 段落の骨子を示す良いリード文を作る • 1段落1トピックに絞る • 読み手に伝えるべきことを定義する • 読み手を意識して書く • ドキュメントの最初にそのドキュメントの重要なポイ ントを明確に示す https://qiita.com/yasuoyasuo/items/c43783316a4d141a140f
75. ドキュメントライフサイクルプロセスを学ぶには 75 エンジニアのためのドキュメントライティング / Docs for Developers and Paragraph Writing https://speakerdeck.com/nttcom/docs-for-developers-and-paragraph-writing
76. 最後に 76
77. 今日のまとめ ✓ ドキュメント作成に求められるスキル ➢ 漏れなく誤解なく言語化する ➢ 知識＋作文能力＋構造化思考 ✓ 構造化思考とは？ ➢ 「分かる」は「分ける」 ➢ 分解＋グルーピング（思考の補助線） ✓ 構造化思考の演習 ➢ いきなり手を付けず、何を考えるべきか（論点）を考える ✓ ドキュメント作成の進め方 ➢ 目的から逆算して段取りを考える 77
78. 量が質に転嫁する ドキュメントを書く機会を自ら作り ドキュメント力を鍛錬しよう 78 どの現場もあったら助かる資料は必ずあるはずです SNSやブログでも積極的に情報発信していこう
79. ドキュメントを活かすにはプロジェクトのOSを整えたい https://speakerdeck.com/yasuoyasuo/dao-falsezhen-nzhong-wokireinisurupuroziekutomanezimento 自分の失敗を 繰り返さないように マネジメント哲学を 言語化できた 多くの方に 目を通して いただきたい 道の真ん中 中野 で検索！
80. チームワークマネジメントを支えるドキュメント力 80
81. ご清聴ありがとうございました 資料は後ほど Xで共有させていただきます 懇親会でお声がけ 感想、フィードバック Xでコメント/DM いただけたら ありがたいです 81
82. エンジニアのための ドキュメント力基礎講座 ～構造化思考から始めよう～ ＜完＞ 2025年11月29日 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo） Backlog World 2025