#217 良い組織は良いドキュメントから始まる

こんにちは。ITベンチャーエンジニアのこへいです。

チームビルディングや組織設計において、ドキュメント整備は非常に重要です。ドキュメントに対する私見を述べさせていただいてます。

今日は、スタディサプリの事業立ち上げをされた連続起業家のShinさんのVoicyの放送が非常に参考になったので紹介させていただきます。

〇ドキュメントツールは全社で統一せよ

エンジニアはドキュメントをマークダウンで書きたいのでgithubに書く。営業はセールスフォースで顧客を管理する。など、アカウントがない人には見れない場所のドキュメントを書くことは情報共有上問題があるだけでなく、そこから分断が起き始めるため、ドキュメントツールは全社で揃えるべきとのことです。

これは弊社でもよくあることで、ビジネスサイドがセールフォース上の情報を元に議論している時には手元でその情報が見れないと蚊帳の外感が出てくるため、議論に参加しにくくなってしまいます。

またエンジニアはgithubやesaで、ビジネスサイドはGoogle Driveでドキュメントを管理することが多く、管理ツールや管理のルールが異なるとドキュメントが見つからず探すのも億劫になるため、そういう小さな面倒臭さから分断は置き始めるというのは非常にわかります。

〇忙しすぎ問題の原因はドキュメント不足

PMなどの意思決定者のスケジュールが会議で埋まる忙しすぎ問題はどこの組織でも発生するかと思います。その忙しさは実はドキュメント不足が原因の可能性があります。

というのも、ドキュメントを書く習慣がなく口頭伝達をベースとすると会議をする際に、前提の情報共有ができていないので口頭での情報共有から始まり無駄な議論が増えるため、会議の時間が伸びるという悪循環が生まれるということです。

会議のアジェンダ、会議で確認したい内容、確認内容の意思決定の根拠となる情報などなど、ドキュメントに書いて事前に共有しておけば、インプットした状態で会議が始められるため、会議の時間を有意義な議論に費やせるということです。

会議で情報共有はしてはいけない。ドキュメントを事前に読んで会議に臨み、会議では議論をせよ。といことです。

あらかじめドキュメントを作成しておくことのメリットは同じやりとりを繰り返す必要がないということです。
質問や指摘を受けた際にもドキュメントを直しておけば他の人はアップデートされた情報にリーチすることが出来ます。

私もプロダクトマネージャーとして、同じ内容を何度も色んな人に説明する必要があるものはドキュメントにしておきます。作業手順などもドキュメント化しておき、手順とセットで依頼します。ドキュメントを見ながらの作業でで詰まった点はフォローしつつ、その内容をドキュメントに反映します。
そうやって繰り返すうちにクオリティの高い手順書が出来上がります。

最初から完璧な手順書を作るのは骨が折れますが、ざっくりでもドキュメント化しておけば、そのドキュメントを成長させることができます。

〇ドキュメントを書く環境作りが大切

ドキュメントの活用には、ツールとドキュメントスキルが必要と言われます。ドキュメントスキルについてはAIツールの活用でかなりハードルが下がってきているため、ツールを整えることがドキュメント活用には効果的です。

というのも、ツールが悪ければどんなに頑張っても意味がないからです。
前述のようにgithubに大量のドキュメントを書いても、アカウントがない人からするとそのドキュメントの価値はありません。ドキュメントの内容は伝わってはじめて価値になるのです。

マークダウンで書けないから書かない、というようにドキュメントを書くハードルが高い場合も問題です。息を吐くようにドキュメントを書けるくらいハードルを下げておかないと、ただでさえ面倒くさい作業のためどんどん後回しになっていきます。

弊社ではesaというドキュメントツールを活用しています。esaは各ハードルが非常に低いのですが、構造化が弱いため参照性が非常に悪いという問題があります。
せっかくドキュメントを書いたのにそのドキュメントに到達できなければ、やはりそのドキュメントに価値はありません。

書きやすく、参照しやすく、活用される状態を作るためには、ドキュメントツールを変えるという判断も必要です。

ちなみにShinさんは「notion一択！」とnotion押しです。
notionはマークダウンもあり非常に書きやすく、構造化の自由度もあるため、参照性にも優れています。私も個人のメモツールやタスク管理ツールとして活用しているため、社内のドキュメントツールとして使うのは大いに賛成です。

また、エンジニアとしては設計周りのドキュメントはソースコードに近い所で管理したいのでgithubで管理できる方がありがたいです。githubの管理であればpull requestでドキュメントの修正内容のレビューを受けることも出来るため、ドキュメントのクオリティ担保にも繋がります。

また、弊社はgitのドキュメントをビジネスサイドも見れるようになっているので、ドキュメントの参照性的にも問題はないです。ビジネスサイドのドキュメント管理方法と合わせてなるべく統一的なインターフェイスでドキュメント管理をしたいのですが、社内のドキュメント管理方法はまだまだ設計の模索中です。
今回のShinさんの放送は非常に参考になりました。

ということで、良い組織は良いドキュメントから始まるという話でした。
最後までお読みいただきありがとうございました。