見出し画像

GitLab的ドキュメント文化を組織にインストールする(実践編:スタートアップMNTSQの事例)

 会社組織にドキュメント文化をインストールすることの有用性や、GitLabのような企業がどのようにドキュメントを運用しているかを、前回記事で書いた(スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ)。今回は、私のいるスタートアップのMNTSQ(モンテスキュー、と読みます)でどのようにそれを実践しているか、実際のところどのような成果が出ているのかについて書いてみたい。

 MNTSQでは、当初からドキュメンテーションの重要性を経営メンバー全員で認識しており、社内ドキュメントをGitHub管理でメンテナンスしながら作り上げていくようにしていた。この大枠の仕組みの設計部分は弊社のデザイナーの生谷(@ikutani41)が初期に考案/メンテしたものである。デザイナー視点からこのような仕組みが設計され稼働されることは珍しいと思う。この辺については本人からもどういうことを考えながらやっていたのか今後発信があると思うのでそちらもぜひ出たらご覧いただきたい。

 やってみた現時点の感覚として、ドキュメント文化は決してGitLabのような一部の特殊な企業のみでしか運用できないわけではないと思っている。MNTSQのような日本の小規模スタートアップでも導入することが可能であり、効果を出すことができる。更に、この効果は一過性のものではなく、今後時間が経つにつれて、複利で効いてくる感触がある。

 この記事では、以下の3点について触れたいと思う。

1) 現状MNTSQ社のドキュメンテーションがどんな感じか
2) 導入してみてよかったところと悪かったところはどこか
3) 導入に関して工夫したところは

現状MNTSQ社のドキュメンテーションはどんな感じか

 MNTSQ社のドキュメント(Members Portalと呼んでいます)はGitHubリポジトリで管理されている。ドキュメントに含まれるコンテンツは「社内規則」「マスタープラン(ビジョンミッション&全社戦略)」「働き方」「オフィスの設備関連情報」「ツールの使い方」「各種業務フロー」等がある。

 基本的に全てのページはマークダウンで記載されている。メンバーが働く中で必要な情報はなるべくここに集約して管理することを目指している。GitHubのPRを出すことで変更を提案し、それをレビュワーが承認することでマージされるようになっている。

 マークダウン管理のスコープ外なのはログ系の情報だ。MTGのログ等のイミュータブル(変更されない事実)なものはGoogleドキュメントやスプレッドシート等に蓄積するようにしている。一方で、ドキュメントからリンクはされていて、追えるようになっている。

スクリーンショット 2020-03-27 16.15.07

 ドキュメントは頻繁に更新されている。例えば今月の結果をみると、11人のメンバーが合計170個のコミットしていて、37個のPRをマージしている。これは10人程度の組織にしては割と活発な部類に入るのではないかと思う。

導入してみて、よかったところと大変なところ

良かったことはこちらの通り

質問回答工数が減る。会社のメンバーは仕事をしている中で何か疑問が出たとしても、それをドキュメントの中で自力で探せるようになる。そのため、質問発生率を減らすことができる。Wiki運用だと、同じ情報が複数箇所に散らばり、それらがそれぞれ矛盾することもあるので、書かれているけど内容が信頼できない!ということが発生することもあると思う。そういったことは起きにくい。
質問されても、「ここに書いてあるよ」で終了させられる率が高まる。100%の質問を自己解決することは難しいが、質問があった場合でも、関連する情報がドキュメントに記載されていれば該当部分のURLを貼るだけで回答できるようになる。逆に、質問がされたのにドキュメントに情報が載っていない場合には、PRを出してupdateすることを検討する必要がある。
非同期的にいろんなことを決められるようになる。PRのレビューとマージのプロセスが非常に明確であるため、会議体に頼らず大小様々な意思決定をGitHub上で行えるようになる。個人的にはとても大きな変化だと思う。
小さな改善が組織的に回るようになる。たった1行のPRがちゃんと提案され、きちんとマージされるようになる。そのため、細かな改善が積み上がりやすくなる。これは会議体ベースの議論やWikiベースのメンテナンスによるオペレーションだとなかなか発生しずらいのではないだろうか。


大変なことはこちらの通り

・メンテナンス工数がかかる。これは覚悟した方がよいと思う。特に初期に記載することは多い。ただし、新しいメンバーが増える頻度が高かったり、他分野の領域もキャッチアップしなくてはいけないスタートアップにおいては、このコストを投資したとしても元はすぐにとれると思う。
・全員がGit、GitHubを使える必要がある。ここのキャッチアップ工数は見込む必要がある。分散バージョン管理の考え方をみんなが知っているわけではない。
・スピードに制約がつく。ドキュメント文化を徹底するのであれば、MTGで口頭合意してはい終わりとすることはできない。その内容を言語化し文書化しPRしレビューを経てマージする必要がある。会社のメンバーが20人以下のような少人数のベンチャーであれば、このようなPRベースの意思決定の方が遅い感覚は持つかもしれない。一方で、より大きい組織でやろうとするのであれば、むしろこちらの方が早い可能性はあると思う。

ドキュメント文化のインストールは決して万能薬ではなく、それなりのコストを要求されるものである。しかし、それでも全体として見た時にはプラスの方が多いのではないかと現時点では考えている。

導入に関して工夫したところは?

 GitBookでドキュメントの自動更新/認証/検索をできるようにする

 GitLab Handbookとは違い、MNTSQ社ではドキュメントをインターネット上にパブリックに公開することはしていない(正直ここはほとんどの企業は真似できないのではないだろうか)。そのためドキュメントの検索をGoogle検索に頼ることができない。

 また、GitHub上のUIはお世辞にも閲覧に適しているとは言い難く、検索機能は貧弱で、「メンバーが快適にドキュメントを閲覧できるようにする」ところには課題を感じていた。

 そこで、Docsify等を利用して、CIツールからS3等にマークダウンをアップロードし、各種認証をつけることを検討した。しかし、これはメンテナンスが大変だし、S3でできる認証にも簡単にできるところには限りがあるのでこの方式は見送った。

 更に探したところ、GitbookというSaaSを発見した。Gitbookを利用すると、GitHubリポジトリと自動で同期がされるドキュメントページができ、そのうえ検索機能や目次、SSO認証等が完備されている。日本語の検索もできるのでこちらを導入することにした。

スクリーンショット 2020-03-27 16.14.00

 今のところ値段がやや高い以外はとても満足して利用している。それでも、自前でドキュメント閲覧の仕組みを用意するよりメンテナンスコストを考えるとかなり安価と考えている。


ChromeやAlfredのPluginで「思い立ったら1秒で」検索できるようにする

 次に、検索へのハードルをより下げることに取り組んだ。具体的にはMacのAlfredというランチャーのプラグインを用意し、特定の文字列ですぐにgitbook内を検索できるようにした。下図は「mp 採用」でドキュメント(members portalとMNTSQ社では呼んでいる)の中を検索している様子だ。

スクリーンショット 2020-03-27 16.14.05

 また、同様のことはGoogle Chromeの設定でも可能である。URLバーを右クリックして「検索エンジンの設定」ボタンを押すと、特定のサイトに特定のクエリを投げるような設定ができるようになる。

スクリーンショット 2020-03-27 16.14.37

 これにより、思い立ったらすぐに検索ができるようになる。このような細かい検索体験の向上は個人的には重要だと思う。例えば、MTGの中で「あれってどうなってたっけ?」という話題が出た時に、検索に数十秒かかるのか1秒でできるのかで、議論のクオリティは変わると思う。検索に数十秒かかるのであれば、すぐに調べるという行為自体が行われない可能性が高まる。

GitHub講習を行いビジネスサイドのメンバーもPRを出せるようにする

 この文化を維持するための最低条件は、正直かなり高い。少なくとも社員全員がGitHubのPRを出せるようにする必要がある。エンジニアだけではなくビジネスサイドのメンバー、弊社であればリーガルチームの弁護士やパラリーガルであっても、GitHub上で議論をしていくことが必要になる。弊社ではWindows/macOS両方でGUIベースで利用できるGitクライアントのSourceTreeの使い方の講習会をしている。

スクリーンショット 2020-03-27 16.14.14

 おそらく様々な企業で、ドキュメント文化をインストールしようとする時にネックとなるのはここだと思う。ビジネスサイドのメンバーで、Gitの考え方に慣れ親しんでいる人はあまりいない。この仕組みを回すには、ドキュメントとGitHubと意思決定フローが紐づいている必要があるから、実は全社でコミットしないとあまり意味がない。

Markdown LinterをGitHub Actionsで動かすことでフォーマットを綺麗に保つ

 エンジニアにとっては馴染み深いと思うが、Linterと呼ばれるものがある。これは、自動的にソースコードやドキュメントを検査し、特定のフォーマットに整形してくれるようなものである。ソースコードでいえば、インデントを揃えたり、末尾の改行をつけたり、セミコロンの有無を統一したりしてくれる。

スクリーンショット 2020-03-27 16.14.19

 LinterのMarkdown版も存在している。MNTSQではmarkdown linterとしてremarkを利用している。これを利用すると、Markdownの記法の一貫性が保たれているか、URLのリンク切れがないかどうか等を調べて修正してくれる。GitHub Actionsを用いてPRが出たタイミングで自動でかけるようにすることで、レビュー時にMarkdownの文法チェックの工数を削減することができるようになる。(上記の画像のApply automatic changesのコミットは自動でつけられたもの)

まだまだ運用は改善途中

 いろいろ書いたものの、正直なところ、MNTSQ社においても基本的にはまだまだ手探り状態だ。どこまでをリポジトリで管理し、どこまでをどの媒体で管理するか等、いろんな議論が社内でも起きているところである。

 また今後見えてきたものがあったらnoteなどで書いてみたいと思う。

 それなりにユニークな試みだとは思うので、MNTSQのドキュメント文化や組織運営に質問や興味がある方がいれば是非お気軽にご連絡いただければと思う。逆に「こういう風にやるとうまくいくよ」というベストプラクティスに関する情報があれば、ぜひ教えてほしい。

 また、弊社では現在採用を進めているので、このようなドキュメント文化がインストールされたスタートアップで働いてみることに興味がある方がいたら、是非お気軽にご連絡ください!下記に採用参考資料を掲載します。


この記事が気に入ったらサポートをしてみませんか?