外部エンジニアにドキュメントを書かせる仕組み｜稼働中に溜める運用4ステップ

「ドキュメントを書いてくださいね」と稼働中の外部エンジニアにお願いしたのに、数週間たっても何も増えていない。そんな経験はないでしょうか。優秀なエンジニアほど目の前の開発タスクで手一杯になり、ドキュメント整備は「時間ができたら」のまま後回しにされ続けます。

かといって、契約終了が見えてきたタイミングで「これまでの分をまとめて書いてください」とお願いしても、うまくいきません。本人の記憶は薄れ、書き出される内容は粒度がバラバラで、結局あとから誰も使えない——前回それで痛い目を見た、という方も多いはずです。

さらに厄介なのが、強く催促することへのためらいです。「いつ・どんな順番で・何時間かけて書いてください」と踏み込んで指示すると、業務委託契約なのに指揮命令をしている、つまり偽装請負ではないかという不安がよぎります。結果として、強く言えないまま属人化だけが進んでいきます。

この行き詰まりの正体は、外部エンジニア個人の善意やスキルの問題ではありません。「ドキュメント整備が、依頼する仕事の定義に入っていない」という、仕組みの問題です。逆にいえば、お願いや精神論ではなく、稼働中の業務フローそのものにドキュメント整備を埋め込んでしまえば、外部エンジニアは自然に書き続けるようになります。

本記事では、稼働中（契約継続中）の外部エンジニアにドキュメントを整備させ続けるための運用の仕組みを、発注者の視点で解説します。お願いが定着しない構造的な理由から、PR・スプリント・定例・検収という4つの業務フローへの組み込み方、偽装請負を避ける依頼の線引き、そして仕組みを社内に定着させる立ち上げステップまでを、非エンジニアの方がそのまま依頼に転用できる粒度で紹介します。

「書いてとお願いしても外部エンジニアのドキュメントが溜まらない」理由

最初に、なぜ口頭の「書いてください」が定着しないのかを整理します。原因を「相手のやる気」に求めている限り、いくら声をかけても状況は変わりません。原因は依頼する仕事の設計のほうにあります。

ドキュメントは「成果物の定義」に入っていないと後回しにされる

外部エンジニアにとって、報酬の対象は契約や発注で定義された成果物です。多くの場合、それは「動く機能」「修正されたバグ」であって、「その機能の説明書」ではありません。

人は限られた時間の中で、評価される仕事から先に着手します。ドキュメント整備が成果物の定義に含まれていなければ、それは「やってもやらなくても報酬は変わらない、善意の追加作業」になります。締め切りが迫れば、真っ先に削られるのは当然です。

つまり「書いてください」という口頭の依頼は、相手にとって「余裕があればやる任意作業」としか受け取られていません。やる気の問題ではなく、優先順位の構造の問題なのです。

「離脱時にまとめて」がうまくいかない理由

後回しが積み重なった結果、よくある対策が「契約終了前にまとめてドキュメントを作ってもらう」というものです。しかしこれは2つの理由で機能しません。

ひとつは記憶の劣化です。数か月前に実装した機能の細かな判断や、なぜその設計にしたのかという背景は、本人ですら正確には思い出せません。書き出されるのは、当たり障りのない概要にとどまりがちです。

もうひとつは粒度の崩壊です。日々の作業の中で都度書いていれば「この変更はこういう理由で、ここに影響する」という具体的な記録が積み上がります。ところが最後にまとめて書くと、何を詳しく書き何を省くかの基準が定まらず、章ごとに濃淡がバラバラの文書になります。読み手である後任や社内メンバーが本当に知りたい部分ほど、抜け落ちてしまうのです。

なお、契約終了前にどうしても引き継ぎ資料を作る場合に、せめて使える品質に近づけるための工夫は外部エンジニア引き継ぎドキュメントの作り方で詳しく扱っています。ただし本来は、離脱時の一発勝負に頼らず、稼働中から都度溜めておくのが最も確実です。ドキュメントは、書く対象の作業をしている「その瞬間」に書くのが最も安く、最も正確です。時間が空くほど、品質は下がり、書く側の負担だけが増えていきます。

強い催促が偽装請負リスクに触れる——発注者が踏み込めない構造

そして、発注者が催促をためらう最大の理由が、偽装請負への不安です。

業務委託（請負・準委任）では、受注者が発注者から独立して業務を遂行するのが原則です。発注者が「いつ・どの順番で・どれだけの時間をかけて作業するか」といった作業の進め方に細かく踏み込んで指示すると、それは指揮命令と見なされ、偽装請負と判断されるおそれがあります（厚生労働省「労働者派遣・請負を適正に行うためのガイド」、昭和61年労働省告示第37号）。

「もっとこまめにドキュメントを書いて」「毎日30分は記録の時間に充てて」といった催促は、まさに作業の進め方への指示に近づきます。発注者がこの線引きに不安を抱えていると、催促そのものをためらい、結果として何も進まないという悪循環に陥ります。

ここまでをまとめると、ドキュメントが溜まらない原因は次の3つです。

• ドキュメント整備が成果物の定義に入っておらず、後回しにされる
• まとめて書かせると記憶が薄れ、粒度も崩れて使えない
• 強い催促が偽装請負リスクに触れるため、発注者が踏み込めない

いずれも「お願いの仕方」では解決できません。次の章から、これを仕組みに置き換えていきます。

稼働中にドキュメントを整備させる仕組みの全体像

解決の方向性はシンプルです。「ドキュメントを書いてください」というお願いをやめ、「ドキュメントを成果物・受け入れ条件の一部として定義する」ことに切り替えます。

「お願い」から「成果物・受け入れ条件への組み込み」への転換

前章で見たとおり、外部エンジニアは成果物の定義に入っている作業を優先します。ならば、ドキュメント整備を最初から成果物の定義に組み込んでしまえばよいのです。

たとえば「ログイン機能を実装する」というタスクを、「ログイン機能を実装し、その仕様と影響範囲を所定の場所に記載した状態を成果物とする」と定義し直します。こうすると、ドキュメントは「余裕があればやる任意作業」ではなく、「これがないとタスクが完了したと見なされない必須要素」に変わります。

この転換のポイントは、催促をやめることです。一度「成果物の定義」として合意してしまえば、あとは「定義された成果物が満たされているか」を確認するだけで済みます。発注者は相手の作業の進め方に踏み込む必要がなくなり、後述する偽装請負リスクからも距離を置けます。

まとめて書かせるより「都度・小さく」が安く正確な理由

仕組みのもうひとつの軸が「都度・小さく」です。機能を1つ作ったら、その都度わずかな分量のドキュメントを残す。これを積み重ねるほうが、最後にまとめて書かせるよりも結果的に安く、正確になります。開発と並行してドキュメントを書き進める進め方そのものについては、ドキュメント駆動開発とはもあわせて参考になります。

理由は前章でも触れたとおりです。書いた本人がまだ詳細を覚えているうちに記録するため、内容が正確で、書く手間も小さくて済みます。1回あたりの負担が軽いので、エンジニア側の抵抗も小さくなります。

加えて、属人化リスクの観点でも有利です。都度ドキュメントが積み上がっていれば、仮にそのエンジニアが急に稼働できなくなっても、直近までの状態が文書として残っています。「離脱時にまとめて」方式は、まとめる前に離脱されたら何も残らないという致命的な弱点を抱えていますが、都度方式にはそれがありません。再調査や作り直しにかかる余計なコストを、平時のうちに小さく前払いしておくイメージです。

非エンジニアでも回せる最小構成（特定ツールに依存しない）

「仕組み」と聞くと、専用のナレッジ管理ツールを導入しなければと身構えるかもしれません。しかし、最初から高機能なツールは必要ありません。

最小構成は、すでに開発で使っているもので十分です。コードを管理しているリポジトリの中に説明ファイル（READMEなど）を置き、変更のたびにその変更内容の説明を残してもらう。これだけでも、エンジニアが今どこで何をしているかが文書として残り始めます。

ツールを増やすほど、エンジニアにとっては「コードを書く場所」と「ドキュメントを書く場所」が分かれ、後者がおろそかになりがちです。まずは開発の流れの中で完結する最小構成から始め、運用が回り始めてから必要に応じてNotionやConfluenceのような共有ツールへ広げていくのが現実的です。大切なのはツールの高機能さではなく、「業務フローのどこで書くかが決まっていること」です。

業務フローへの仕込み場所4選（PR・スプリント・定例・検収）

ここからが本記事の核心です。ドキュメント整備を「成果物・受け入れ条件」に組み込むといっても、漠然と契約書に書くだけでは機能しません。日々の業務フローのどこで・何を・どの状態で書かせるかを、具体的な場所に落とし込む必要があります。

非エンジニアの方でもそのまま依頼に転用できるよう、4つの仕込み場所と、それぞれで使える依頼文の例を紹介します。

PR（プルリクエスト）の受け入れ条件に組み込む

PR（プルリクエスト）とは、エンジニアが書いたコードの変更を、本体に取り込む前に提出・確認する手続きのことです。外部エンジニアが何か変更を加えるたびに、必ずこのPRを通ります。つまりPRは、変更の説明を残してもらう絶好のタイミングです。

ここに「何を書くか」のルールを受け入れ条件として組み込みます。具体的には、変更点の概要・なぜその変更をしたのか・どこに影響が及ぶか、の3点を毎回記載してもらいます。

依頼文の例は次のとおりです。

プルリクエストには、(1) 何を変更したか、(2) なぜその変更が必要だったか、(3) 影響する範囲（他の機能や画面）、の3点を記載してください。これらが記載されていることを、変更を取り込む前提条件とさせてください。

ポイントは、これを「お願い」ではなく「取り込む前提条件」として伝えることです。記載がなければ変更を取り込まない、というルールにしておけば、ドキュメントは作業の一部に組み込まれます。

スプリント／週次の成果物定義に含める

スプリントとは、1〜2週間といった短い期間を区切って開発を進める進め方のことです。週次で進捗を区切っている場合も同様に考えられます。

この期間ごとの「成果物」の定義に、ドキュメントの更新を含めます。たとえば「今週は決済機能を実装する」が成果物なら、「決済機能の仕様と運用上の注意点が所定の場所に記載されている状態」までを成果物に含めるのです。

依頼文の例は次のとおりです。

今期間の成果物には、実装した機能そのものに加えて、その機能の仕様・設定値・運用上の注意点を所定の場所に記載した状態を含めます。期間末のレビューでは、この記載も確認させてください。

ここでも、期間末に「ちゃんと書きましたか」と問い詰めるのではなく、最初に成果物の定義として合意しておくのがコツです。合意済みの定義を確認するだけなら、催促にはあたりません。

定例ミーティングのアジェンダに固定枠を置く

週次や隔週の定例ミーティングを行っている場合、そのアジェンダに「ドキュメントの差分確認」という固定枠を設けます。たった5分でも、毎回必ず「今週はどこのドキュメントが更新されましたか」を確認する時間を作るのです。

これは2つの効果があります。ひとつは、見られている前提が生まれることで、ドキュメント整備が自然に意識されること。もうひとつは、発注者自身が「今どこが更新され、どこがまだ薄いか」を把握し続けられることです。

依頼文として構える必要はなく、定例の運営ルールとして発注者側が設定すれば十分です。

定例の冒頭に「ドキュメント更新の確認」を5分の固定枠として置きます。直近で更新された箇所と、まだ整備が追いついていない箇所を共有してください。

固定枠にすることで、ドキュメントの話題が「思い出したときだけ出る話」から「毎回必ず扱う話」に変わります。

検収（受け入れ）条件にドキュメント最新化を含める

検収とは、成果物を発注者が確認して受け入れることです。マイルストーンごとや、機能リリースのタイミングで行われます。

この検収の条件に、「該当機能のドキュメントが最新であること」を明記します。動くかどうかだけでなく、それが文書として説明されているかどうかも受け入れの基準にするわけです。

依頼文の例は次のとおりです。

本件の検収（受け入れ）にあたっては、機能が要件どおり動作することに加え、該当機能のドキュメントが最新の状態に保たれていることを受け入れ条件とします。

ここで重要なのは、検収条件は「契約終了時の引き継ぎ」とは別物だという点です。引き継ぎは離脱時の最後の1回ですが、検収条件は機能を受け入れるたびに毎回発生します。日常的な受け入れの一部として組み込むことで、ドキュメントは継続的に最新化されていきます。

これら4つの仕込み場所は、どれか1つだけでも効果がありますが、組み合わせるほど抜け漏れが減ります。まずはPRの受け入れ条件から始め、運用に慣れてきたらスプリント・定例・検収へと広げていくのがよいでしょう。

偽装請負を避ける依頼の線引き

ここまで「成果物の定義」「受け入れ条件」という言葉を繰り返し使ってきました。これには明確な理由があります。ドキュメント整備の依頼が偽装請負にならないための線引きが、まさにそこにあるからです。

「成果物・受け入れ条件の指定」と「作業手順の命令」の境界

業務委託において、発注者が指定してよいのは「何を・どんな品質で納めてほしいか」という成果物・受け入れ条件です。一方で踏み込んではいけないのが、「いつ・どの順番で・どれだけの時間をかけて作業するか」という作業遂行の進め方です。後者に細かく介入すると、指揮命令と見なされ偽装請負と判断されるおそれがあります（厚生労働省「労働者派遣・請負を適正に行うためのガイド」、昭和61年労働省告示第37号）。

実際、業務委託や請負の関係では、成果物の内容や納品期限は指定できても、日々の働き方まで細かく指示すれば偽装請負にあたるとされています（出典: 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準」昭和61年労働省告示第37号）。

ドキュメント整備に当てはめると、境界は次のようになります。

• 適法な指定（成果物・受け入れ条件）: 「PRには変更点・理由・影響範囲を記載した状態を成果物とする」「該当機能のドキュメントが最新であることを検収条件とする」
• リスクのある指示（作業手順の命令）: 「毎日30分はドキュメントを書く時間に充てなさい」「午前中に必ず記録を更新しなさい」「この順番で章を書きなさい」

前者はあくまで「どんな状態を納めてほしいか」の指定です。いつどう書くかは受注者の裁量に委ねられています。後者は作業の進め方そのものへの指示であり、指揮命令に近づきます。前章で紹介した4つの仕込み場所が、すべて「成果物・受け入れ条件」の形をとっていたのは、この境界の内側に収めるためです。

書面（契約・発注書・成果物定義）にしておくと催促が指揮命令にならない理由

この線引きを実務で守る最大のコツは、ドキュメント整備の条件をあらかじめ書面にしておくことです。契約書・発注書・タスクの成果物定義のいずれかに、「成果物にはドキュメントを含む」「検収条件にドキュメント最新化を含む」と明記しておきます。

書面化しておくと、その後のやりとりが「合意済みの成果物条件を確認する行為」になります。「ドキュメントが記載されていないので、まだ成果物の条件を満たしていません」と伝えるのは、契約上の確認であって、作業の進め方への命令ではありません。

逆に、書面に何も定義がないまま「もっと書いて」「こまめに記録して」と口頭で繰り返すと、それは作業遂行への介入として指揮命令に近づいてしまいます。同じ「催促」でも、背後に書面の定義があるかないかで意味がまったく変わるのです。これが、発注者が安心して踏み込めるかどうかの分かれ目になります。

やってはいけない依頼の例・やってよい依頼の例

最後に、対比で整理します。

左側はいずれも「どんな状態を納めてほしいか」にとどまり、いつどう作業するかは受注者の裁量に委ねています。右側は作業の進め方や時間配分に踏み込んでおり、指揮命令と見なされるリスクがあります。

判断に迷ったときは、「これは納めてほしい成果物の状態の話か、それとも作業の進め方の話か」を自問してください。前者なら指定してよく、後者は受注者の裁量に委ねるべき領域です。なお、個別の契約形態や運用が偽装請負にあたるかどうかの最終的な判断は、契約内容や実態を踏まえて専門家に確認することをおすすめします。

仕組みを定着させる立ち上げステップ

仕組みは作って終わりではありません。最初の立ち上げを丁寧に行い、運用を定着させてはじめて、属人化を防ぐ資産になります。最後に、立ち上げのステップと、社内に知識を残すための工夫を紹介します。

最小構成からのスモールスタート

いきなり4つの仕込み場所をすべて導入し、立派なナレッジ管理ツールを整える必要はありません。先述のとおり、最初はリポジトリ内の説明ファイルと変更ごとの説明という最小構成から始めます。

立ち上げのステップは次のように考えると進めやすいでしょう。

1. PRの受け入れ条件に「変更点・理由・影響範囲の記載」を加えることを合意する
2. 数週間運用して、書く側・読む側の双方が慣れる
3. 慣れてきたら、検収条件・スプリントの成果物定義・定例の固定枠へと順に広げる

一度に多くを求めると、エンジニア側の負担感が大きくなり、形だけの記載に終わりがちです。小さく始めて、回り始めてから広げるほうが定着します。

置き場所と所有権は発注者側が握る

仕組みを作るうえで見落としがちなのが、ドキュメントの置き場所と所有権です。

外部エンジニアの個人アカウントや、本人しかアクセスできない環境にドキュメントが置かれていると、その人が離脱した瞬間にすべて失われます。これでは、せっかく都度書いてもらった意味がありません。

ドキュメントの保管場所は、発注者側が管理するリポジトリや共有ツールに限定してください。アクセス権限の管理も発注者側が握り、いつでも全文を閲覧・取得できる状態にしておきます。なお、こうしたアクセス権やツールの整備をはじめとする稼働開始時の環境づくりは、外部エンジニアへの情報共有体制の設計で体系的に整理しています。本来は外部エンジニアの稼働開始時にあわせて設計しておくのが理想ですが、すでに稼働中であっても、置き場所の所有権だけは早めに発注者側へ移しておきましょう。

「後任が読んで分かるか」を定期点検する

最後に、ドキュメントの質を保つための定期点検です。書かれている量が増えても、「書いた本人にしか分からない」内容では属人化は解消されません。

そこで、定期的に「このドキュメントを読んで、後任や社内の別メンバーが作業を引き継げそうか」という視点で点検します。最初の数回は、発注者自身がドキュメントを読み、分からない部分があればフィードバックして、書く粒度の目線合わせをするとよいでしょう。専門用語ばかりで意味が取れない、前提が書かれていないといった点を早めに指摘すれば、その後のドキュメントの質が上がります。

この点検を続けることで、ドキュメントは特定の外部エンジニアの個人メモから、誰が読んでも引き継げる組織の知識資産へと育っていきます。それはそのまま、「この人がいないと誰も触れない」という属人化の不安を、「仕組みで防げる」という見通しに変える過程でもあります。

外部エンジニアの活用は、優秀な人材に短期間で開発を任せられる大きな利点があります。その利点を最大限に活かしながら属人化のリスクを抑えるには、稼働中の業務フローにドキュメント整備を埋め込み、書き続けてもらう仕組みを早く作ることが近道です。お願いや精神論ではなく、成果物の定義と受け入れ条件という形に落とし込むこと——それが、発注者が指揮命令リスクを冒さずに、外部エンジニアに自然とドキュメントを残してもらうための要点です。