ソフトウェア開発の現場では、属人化を避けるために「なんでもドキュメント化しよう」という文化がよく見られます。
ナレッジを共有し、誰がいなくなっても困らないチームを作るという考え方自体は、合理的で正しいものだと思います。

しかし、「なんでもドキュメント化しよう」という文化は、捉え方次第では技術の習得という観点で思わぬ弊害を生むことがあります。

属人化とドキュメントのジレンマ

例えば、あるプロジェクトの環境構築の手順をまとめたドキュメントがあるとします。
そのドキュメントの内容は、何のために、どこまで詳細に書くべきでしょうか。
その線引きは、チームの方針やメンバーに求めるスキルレベルなどによって大きく異なります。

手順を細かく書けば、誰でも手順通りに作業でき、効率的に環境構築を進められます。
もし途中で問題が発生したとしても、そういったケースのトラブルシューティングの手順も記載しておけば問題ないでしょう。

しかし、そのようなドキュメントに完全に頼って環境構築を終えたメンバーは、「自走して環境構築ができた」と言えるでしょうか。
多くの場合、それは「再現できた」にすぎず、「理解して環境構築できた」とは異なります。

ドキュメントが過度に充実してマニュアルのようになると、「なぜそうするのか」を考える機会が失われます。
チーム全体がそれを当然のように良しとし、盲目的にドキュメント化を推進していると、将来的にメンバーの技術習得が課題になったり、評価と自己認識のズレや、学習意欲の低下といった問題が生じるかもしれません。

技術の習得には、思考の身体化が必要

ドキュメントは形式知を伝えるための手段としてとても有効ですが、それだけでは技術を習得することはできません。

技術を習得するということは、単に知識を得ることではありません。
知識や経験をうまく繋げ、状況に応じて適切に判断するための思考を身体化することが必要です。

開発者としてある程度経験を積むと、「この実装はなぜ気持ち悪いのか」「なぜ今はこの構成のほうが良いのか」といった、言語化しづらい感覚的な知識（暗黙知）を得て、それに基づいた判断ができるようになります。

この暗黙知は、どれだけ充実したドキュメントを読んでも得ることはできません。
仮に「なぜそうするのか」まで書かれていても、それを形式的に知るだけでは、思考の再現には至りません。

暗黙知についての有名な例えである「自転車の乗り方」（自転車の乗り方は実際に自転車に乗ることでしか知ることができず、どのように操作すれば良いかを言語化して説明することが難しい）と同じように、技術もまた、手と頭を動かし、試行錯誤するプロセスを通じてしか身につきません。
うまくいったり、うまくいかない経験のなかで生まれる感覚が、技術者としての「地力」となっていきます。

暗黙知は、文化として残す

「属人化を避けよう」というスローガンの背景には、「個人への依存を減らそう」という意図があると思います。
しかし、開発をうまく進めるための本質的な知識の多くは、個人の経験からでしか獲得できない暗黙知にあります。

本当に強いチームとは、単に手順が共有されているチームではなく、暗黙知を文化として共有できるチームです。
ドキュメントは形式知を必要な分だけ残すことに留め、設計思想、デバッグの勘所、コードの美学といった暗黙知は、ペアプロ・コードレビュー・日常的な対話などを通して受け継いでいくことが大切です。

一緒に手を動かし、考え方や価値観を自然に共有できる時間を増やすことが、結果的にチームを強くします。

終わりに

「できる」や「できるようになった」という感覚や手応えがあると、プロセスを楽しめたり、より創造的になれたりします。

今回の記事では、ドキュメント化の具体的な方法までは踏み込めませんでしたが、今後は「強いチームをつくるためのドキュメントとは何か」を意識して考えていきたいと思います！