「GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術」を読んで得た知見

# はじめに

情報収集していたら見かけた本で、前作『[GitLabに学ぶ 世界最先端のリモート組織のつくりかた](https://www.shoeisha.co.jp/book/detail/9784798183916)』の評価も高かったので読んでみました。

* **欲しい情報がどこにあるかわからない**
* **ドキュメント書いてもメンテされないから無駄**
* **チャットやメールより直接話した方が早い**

このように思ったり疲弊したことはありませんか。

この本はこのような課題を解決するための「ドキュメント」や「テキストコミュニケーション」の入門書です。

この記事では私が良いと思った部分の要約と私の感想を記載します。

『[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法](https://www.shoeisha.co.jp/book/detail/9784798185705)』

# 導入部分

「GitLabという組織は、世界65カ国上に2,000名を超えるメンバーが所属しているグローバルカンパニー」でありながら「あらゆる国籍や価値観、タイムゾーンに存在するメンバーのパフォーマンスを引き出すためには、**ドキュメントが鍵**である」と述べられています。

　正直日本人のみの会社でも認識合わせたり合意取るのは大変なのに、リモートかつ多国籍なんて私には想像出来ないレベルですが、GitLabはドキュメントを活用することによって高い生産性で結果を出しています。
　冒頭で述べた半ば諦めのようなドキュメントへの考えは捨てて、チャレンジしてみようと感じました。

# 第1章 世界最先端のリモート組織を支えるドキュメント

#### 「組織に発生する非効率を抑え、あらゆる状況に置かれているメンバーがパフォーマンスを発揮できるようにしています」

　そこまで言い切れるほどのドキュメントはどんなものなのだろうか、と思いました。
GitLabには「GitLab Handbook」というドキュメントが存在しており、Web検索すれば出てきます。
　このドキュメントに書かれている内容を「意思決定の基準」にしながら、この内容と実態が乖離しないように運用されています。

　そのためGitLabで働く場合「GitLab Handbook」を見れば判断基準や知りたいことが書いてあり、ここに無かったら無い状態へと集約して「信頼できる唯一の情報源」としています。

　ドキュメントが色々な箇所に散らばっていて探すのが時間かかる上に、情報が正しいかもわからないので詳しい人に聞くなんて非効率だよなと思いました。

# 第2章 ドキュメントを組織に導入する必要性

「**ドキュメントという客観的な場でお互いの情報をアウトプットして、確認し合うこと**が効果的なのです。」

　いかに人同士の認識にずれが発生し「非効率なパフォーマンス」を生んでいるかが記載されています。

* 品質、スピードどちらを優先するのか決まっていない
* チームになることで無意識のうちに「社会的手抜き」や「調整の損失」が起こる
* 「自分が感じている感覚と同じ感覚を他人も抱いているのだと錯覚」する
* 様々な「バイアス」で食い違いが起きる

　これらを解決するためドキュメントに「十分なコンテクストを提供」し、「あなたが持っている感覚や感情も含めてドキュメントにアウトプットすることで、認識の違いを乗り越えるヒントになる」とあります。※省略しますが本には個々の解決策がしっかり載ってます。

　チームでドキュメントを上記も含めて更新していくことによって、自分の考えも客観視できるし、チームとの認識合わせも出来ます。そうやって共通認識を作りチームで進めることができれば認識のズレによる非効率は減らせると思います。

# 第3章 GitLabのドキュメント・テキスト活用に関する思想とルール　

「ドキュメントにメリットを感じていない人たちにとっても、次のような視点で見てみると、実は見えないコストを払い続けていることを発見できるかもしれません。」

* 「求めている情報にたどり着けない」
* 「誰が知っているかわからない」
* 「情報を特定の人が独占することで権力に繋がる」
* 「複数の場所に存在し、それぞれ別々のことが述べられている」
* 「誰かの記憶に情報がある場合、情報を持っている人が忘れてしまう」

これは共感ができる「あるある」だと思います。私も働いている時感じることがあります。

これらとは決別し効率的に仕事をするために「ハンドブックファースト」が重要と述べられています。

　また、情報を集約しても議論になってしまうことがあるため「GitLab Valuesを公式の業務ルールとすることで議論になった場合の基準として活用するようにしています」とあります。
意思決定できる人が居なくても「GitLab Values」を見れば判断が下せれば効率良く業務が進められると思います。

# 第4章 ドキュメントの影響範囲と品質

ここら辺からドキュメントの書き方になっていきます。

* 「ドキュメントが達成したい目的を記載する」
  * 「このドキュメントを読むと何が得られるのか明確になる」
* 「対象となる読者の範囲を設定」
  * 「誰に向けて書くべきドキュメントであるかイメージが明確に持てる」
* 「情報の正確性や客観性を高める」
  * 「ファクト（事実）とオピニオン（意見）を明確に分けて記載」

　これらはテンプレート的に入れたりすることが多かったのですが、理由が詳しく載っており腑に落ちました。
　業務をする上で目的は何か、誰に対して伝えたいのか、事実と意見が混ざってないかを意識してドキュメントやテキストコミュニケーションしたいと思いました。

# 第6章 Valueを活用してライティングスキルを向上させる

「出来の良し悪しを判断するためには基準がなくてはなりません。その基準こそが **GitLab Values** です」

出来の良し悪しを判断しやすい具体的な行動指針が「GitLab Values」には用意されており、特に以下が良いと思いました。

**「１人の人間が知っていることには限界があり、まだ知らない知識がある前提で振る舞う」**

　これは言われてみればそうなんですが、意外と意識出来てないことかと思います。
聞けば5分で解決することも1人で悩むと時間を浪費してしまうことがあります。知らないことを恥ずかしがらず、素直に質問する姿勢が大切だと思います。

　また、「ドキュメントが存在していないなら、回答をもらった際に感謝の気持ちを込めて、あなたがドキュメントを作成する」と述べられています。
これは私も入社直後など困ったことはメモしておいて、新たにジョインされた方にシェアしたら喜ばれた経験があります。聞いてその場で終わりはもったいないですし、このような行動指針があるのは非常に良いと思います。

　あと「用意された理由が詳細に書かれていれば、１年後に不要と思えるものをなくしたいと思った時にコンテクストを得て判断することができるでしょう」とあります。

　これは本当に大切だと思います。記載理由が書いておらず「詳しく調べている暇も無いからとりあえずそのままの運用にしようか」という非効率が結構あります。未来で困らないようにしっかり理由を記載したいですね。

# 第7章 メッセージの組み立て方

「文章を書く上での基本的なマインドセット（考え方）」として
「イテレーションの考え方に共通する部分が多く存在します。つまり**最小限の変更でリリースして、ユーザのフィートバックを受けながら、改善を積み重ねていくやり方**です。」

共通するとありますがアジャイルと同じ考え方とまず思いました。

さらに
「作成しているドキュメントが良いか悪いか決めるのは「作成者」ではなく「読み手」なのです。」
「自分の頭の中だけで作られた正しさが本当に正しいのかは、頭の中にある限りいつまでも確証が持てません。」
と述べられていて、読み手に渡るまでに完璧を目指すことをせず、まずは叩き台を共有して「多様な視点を活用しながらドキュメントを育てていく」という部分が大事だと思いました。

　私も頑張って作ったドキュメントが色々と突っ込みを入れられると嫌だなと思いますが、異なる背景や専門性を持つ人々がいる中、一発で完璧なものを作るのはほぼ不可能なので早くフィートバックを受けた方が良いと思いました。

# 第12章 Slackのテキストコミュニケーション

「Slackはチームメンバーに向けたアナウンスやメッセージを伝えるために活用します。」

「反対に次のような目的では利用しないように注意点も紹介しています。

* 「承認を得る」
* 「決定事項の文書化」
* 「会社の公式記録やドキュメントの保管」
* 「個人情報や機密情報の共有」

　たくさんのチャンネルに分かれているチャットツールで、上記のような内容を送ってしまうと情報元が分散してしまい、情報を見つけるのに余計なコストがかかることに繋がると思います。

　ちなみにGitLabでは90日でメッセージが消える設定にしているそうです。思い切ってそのような設定にしてしまうのも有りかと思いました。

# 最後に

　全部読んだ感想ですがドキュメントを作り育てるのって、コードを書いていくのと似ていると思いました。
小さい変更のPRを作り、レビュアーが理解しやすいようにコンテクストを記載し、レビューでフィートバックを受けながら積み重ねて作っていく、重複したコードが無いように集約する...など普段コード書いている時の感覚でドキュメントも作っていけそうという気持ちになります。

　また、今回紹介した内容以外にも実際にドキュメントを書く上でのTIPSやメッセージを送る際の心構えなど約に立つ情報もあるので実践していきたいと思います！