少人数で開発していると、いちばん静かに、いちばん深く効いてくるリスクがあります。属人化です。「この機能をなぜこう作ったのか」「この修正は何のためだったのか」が、作った本人の頭の中にしか残らない。その人が抜けた瞬間、あるいは数ヶ月後に本人自身が思い出せなくなった瞬間、開発は止まります。

この記事では、その属人化を防ぐために、課題管理ツールのタスクと、Gitのコミット・プルリクエストを1対1で結びつけた運用を、実際に回している立場から整理します。特定ツールの使い方の解説ではありません。「なぜ作ったか」を人の頭ではなく履歴に残す、開発体制の話として書きます。

筆者（馬込）は、複数の自社プロダクトを少人数で開発・運用しています。人手が限られるほど、一人が知っていることの比重が大きくなり、属人化のリスクは跳ね上がります。だからこそ、記録が本人の記憶に依存しない状態を、仕組みとして作る必要がありました。

「動くコード」だけでは、半年後の自分が困る

コードは、何を作ったかは語りますが、なぜ作ったかは語りません。

たとえば、ある条件分岐が追加されている。コードを読めば「何をしているか」は分かります。でも「なぜこの分岐が必要だったのか」「どういう課題や判断から生まれたのか」は、コードのどこにも書かれていません。それは、実装した人の頭の中にありました。

少人数だと、これが特に効きます。レビューする人も、引き継ぐ人も、そもそも数が少ない。「本人に聞けば分かる」が通用するうちは問題が表面化せず、通用しなくなった瞬間に一気に噴き出す。半年後の自分ですら、当時の判断を思い出せないことは珍しくありません。動くコードを積み上げるほど、「なぜ」の空白も静かに積み上がっていました。

判断：タスクを起点にし、コミット・PRから辿れるようにする

そこで採ったのが、タスク駆動という進め方です。開発を「コードから始める」のではなく、「課題管理ツールのタスクから始める」。そして、そのタスクを起点に、ブランチ・コミット・プルリクエストのすべてを紐づけて、履歴からいつでも「なぜ」を辿れるようにしました。私たちは課題管理にLinearを使っていますが、考え方はツールを問いません。

具体的には、1つのタスクに対して、次のように識別子（例：TASKS-123）を一貫して通します。

タスク:    TASKS-123「問い合わせフォームの送信エラー処理を改善する」
ブランチ:  work/tasks-123-form-error-handling
コミット:  fix: 送信エラーをインライン表示に変更（離脱抑制・TASKS-123）
PR:        #456（本文に TASKS-123 へのリンク）

こうしておくと、任意のコミットから「どのタスクのための変更か」が分かり、逆にタスクから「どう実装され、どこでレビューされたか」を辿れます。コード・課題・レビューが、1つの識別子で一本の線につながる。「なぜこの変更があるのか」の答えが、常に履歴の側に残るようになりました。

なぜ「可視化」が体制の話なのか

このタスク駆動は、単なる整理術ではなく、開発体制そのものを支える仕組みでした。効いてくる場面が、体制の話に直結するからです。

  • 属人化を防ぐ：判断の理由が履歴に残るため、「本人に聞かないと分からない」領域が減ります。人が抜けても、辿れる。
  • レビューが成立する：レビューする側は、コードだけでなく「何のための変更か」を前提に見られます。指摘の質が上がります。
  • 意思決定の履歴が残る：後から「なぜこの設計にしたのか」を、当時のタスクと議論から再構成できます。過去の自分の判断を、根拠つきで引き継げます。
  • 外部メンバーと協業できる：これが最も大きい。外部のエンジニアが入るとき、口頭の文脈共有には限界があります。タスクとコードが履歴で結ばれていれば、「なぜ」を人を介さず渡せる。

とくに最後の点は、少人数の内製チームが外部の手を借りるときに効きます。外部メンバーとの協業では、社内の暗黙知をどれだけ履歴に落とせているかが、立ち上がりの速さを左右します。

そして、この「外部の手」には AIコーディングエージェント（Claude Code など） も含まれます。実装の手をエージェントに任せる場面でも、「どのタスクのための変更か」「なぜそう判断したか」がタスクと履歴に残っていれば、人間はコードだけでなく意図の側からレビューでき、判断の主導権を握り続けられます。手を動かすのが人かAIかに関わらず、"なぜ"が履歴に残っている状態を保つ——タスク駆動は、AIと協業しながら属人化もブラックボックス化も防ぐための土台でもありました。並行して複数の作業を止めずに回すための作業環境の分離はgit worktreeで並行開発の切り替えコストを消す運用に、複数プロダクトをまとめて管理する前提は複数プロダクトを1モノレポで運営する構成にまとめています。

つまずき——「IDを貼るだけ」では形骸化する

正直に書くと、この運用は「識別子を貼れば効く」ものではありませんでした。つまずきどころが2つあります。

ひとつは、IDだけ貼って中身が薄いと、形骸化すること。コミットメッセージに TASKS-123 と付いていても、そのタスクに「なぜ・何を・どう判断したか」が書かれていなければ、辿った先が空っぽです。紐づけは器で、中身（判断の言語化）が伴って初めて効きます。器だけ整えて満足すると、「トレースはできるが、辿っても何も分からない」状態になります。

もうひとつは、粒度です。1コミット1タスクに厳密にしすぎると、細かい変更のたびにタスクを切る負担が増え、逆に大きすぎると1つのタスクに雑多な変更が混ざって辿りにくくなります。「後から見て意味の単位になっているか」を基準に、粒度は都度調整しました。ルールを固めすぎず、可視化という目的から外れない範囲で緩く運用するのが、少人数では現実的でした。

これは「人が増える／入れ替わる」ときに効く

タスク駆動の価値は、チームが安定しているときより、人が増える・入れ替わる・外部が入るときに跳ねます。属人化は、メンバーが固定されているうちは痛みが顕在化しません。動きが出た瞬間に、「あの人しか知らない」がボトルネックになります。

だからこそ、体制を広げる前に、記録を人の頭から履歴へ移しておくことが効きました。逆に言えば、この土台がないまま外部の手を増やすと、文脈共有のコストばかりが膨らみます。技術的な負債や属人化した実装を外部の力で解きほぐす進め方は技術的負債を外部支援で解消する方法、開発チームを外部で広げる際の考え方は開発チームを外部で拡張する方法で整理しています。可視化の仕組みは、体制を広げるための前提条件でした。

TechMateの開発体制づくり支援

私たちTechMateは、こうした「属人化を防ぐ開発プロセスづくり」から、実装の伴走までを、月単位の準委任で支援しています。タスクとコードを結ぶ可視化の設計だけでなく、外部メンバーとして入る際も、この履歴の上で「なぜ」を共有しながら手を動かします。属人化が不安な段階でも、外部の手を入れる前の体制整備からでも構いません。こちらからご相談ください。

よくある質問

Q. タスク駆動開発は、専用のツールを買わないと始められませんか？ A. いいえ。大事なのはツールより、「タスク・コミット・PRを1つの識別子で結ぶ」という運用の約束です。既存の課題管理ツールとGitがあれば始められます。私たちはLinearを使っていますが、要は「コードから“なぜ”を辿れる状態」を作ることが本質で、そのための道具は何でも構いません。

Q. コミットメッセージにタスクIDを付けるだけでは不十分ですか？ A. IDの付与は入口で、それだけでは足りません。辿った先のタスクに「なぜ・何を・どう判断したか」が言語化されていて初めて、可視化が機能します。IDは器、判断の記述が中身です。器だけ整えると、「トレースはできるが辿っても何も分からない」状態になり、属人化は解消しません。

Q. 少人数だと、こうした記録の手間は割に合いますか？ A. むしろ少人数ほど割に合います。人数が少ないと一人が知っていることの比重が大きく、属人化のリスクが高いためです。記録の手間は、人が抜けたり外部が入ったりしたときの「立ち上げコスト」を先払いしているのと同じで、少人数で人の動きが出やすいチームほど、その先払いが効いてきます。

少人数開発で怖いのは、コードが増えることではなく、「なぜ作ったか」が人の頭にしか残らないことでした。タスクを起点に、コミット・PRを1つの識別子で結び、意思決定を履歴の側に残す。ただし識別子を貼るだけでは形骸化するので、判断の言語化を伴わせる。この土台があって初めて、人が増えても・外部が入っても、開発は止まりません。

属人化を防ぐ開発プロセスづくりや、外部の手を入れる前の体制整備で迷う段階でも構いません。開発体制のご相談から、お気軽にお問い合わせください。