チームワークにおけるDocumentation - トレタ開発者ブログ

みなさんesa等の共有ドキュメントツール使っていますか？ドキュメントって書くのって非常に難しいですよね。いや、ただ書くのは簡単ですが、相手に伝わるドキュメントを書くのが非常に難しいですよね。

特にエンジニアの皆さんは「シンプルで美しい」みたいな様相を好むと思いますので、ドキュメントを書く際にもそういったマインドの中で書かれている方も多いかと思います。

こんなタイトルの記事を書いておきながら自分はエンジニア業を通す中で積極的にドキュメントを書いている人間かと言ったらそうではないですし、後術するノウハウを意識できているかと言ったら出来ていないと思っています。ので、その自戒も込めつつこちらの記事を執筆させていただきます。

エンジニアだけでなく、日頃チームの中で働く皆さんのご参考になれば幸いです。

ドキュメンテーションはスキルの一つ

同じ領域で仕事をしている人へのドキュメントは文脈を読んでくれるので大体は伝わります。しかし、領域外の人はそもそもの文脈を理解していないので、客観的に書かれていない文章を理解するのに頭を意外と使います。

日本人は小学生や中学生の頃から国語の授業で『この一文のときの主人公の気持ちを20文字で記載しなさい。』といった問題で訓練されているので、文脈を汲み取ろうとする文化があります。

しかし、一般的に用いられない自分の領域内の用語や単語を使っていたりすると、ドキュメントを読むのに時間が掛かってしまうこと繋がります。難しい用語や単語を一般的な用語や単語に置き換えることや、論理展開を相手の思考回路に合わせて記述していくことによってドキュメントの理解度の向上につながると考えます。

つまり、どれだけ客観的に物事を記載していくかで相手の理解度が変わっていくわけですが、今回は『意思決定』を主軸をおいたドキュメントの書き方を紹介します。

◆Prerequisite: 背景となる前提

なぜ、このドキュメントが存在するのかを背景を踏まえて明記する

このドキュメントが生まれた背景となる課題感
このドキュメントを通して何を成し遂げたいのかを記載
- 何をしないのかも記載すると絞りやすくなる
- お互いの共通認識をもつ

◆AsIs/ToBe: 現実と理想からのギャップ

理想形を作って、現実に落とし込む

理想形をつくるためにリソース（人、物、金）について言及しないで考える
理想の形から現実に落とし込むときにリソースについて言及する
- 理想と現実のギャップから課題が発見されるため、それを解決するために必要な要素を洗い出す
現実に落とし込むときは一つだけに固執せず、複数パターンを列挙して現実でのやり方を落とし込む

◆Pros / Cons: 長所と短所を理想と現実のパターンから洗い出す

パターンから長所と短所の洗い出しをする

AsIs / ToBeから洗い出された複数パターンについてPros/Consを洗い出す
人、チーム内、チーム外、プロジェクト、組織、経営の各目線を変えて長所と短所を見出す
テクニックとして、マトリクスで表記するのが見やすい

◆ToDo: ネクストアクションを決める

パターン決定ないしはパターンをいくつか絞ったことに対するTODOをまとめる

ToDoについてはコントローラブルとアンコントローラブルについて切り分けておく
時間差となるタイムラインを踏まえて重要性と緊急性を考えておく

◆気をつけること

最初から論理思考フレームワーク（MECEなど）を使うことはやめる
- フレームワークを使うと「っぽく」はなる。なるけどゴールが噛み合わなくなるので議論が収束しにくいのと納得感も生まれにくい
- なぜならば、『それはあなたの世界における思考であって、世界がわからなければそのMECEが正しいかもわからない』状態になってしまう
- つまり、世界を理解するためのドキュメントの前提となる Prerequisite が重要

まとめ

細々と書いていきましたが、まとめると冒頭にも述べた通り「どれだけ客観的に物事を記載していくかで相手の理解度が変わっていく」ということに尽きると思っています。よく言われることだと思いますが、意外とそれをどうやってやれば良いかまで体系的にまとまっているものが見当たらなかったのでこちら記事にさせていただきました。

プロダクトやプロジェクトの想起時、考えやアイデイアのブレストの際に活かしてみてはいかがでしょうか。