Cloudbaseを支えるドキュメント文化
この記事で話すこと
この記事では、Cloudbaseの1つの特徴であるドキュメント文化についてお話します。 まず初めに、なぜCloudbaseではドキュメント文化が特徴として存在しているかということについて、初期のCloudbaseに遡って起源を探ります。 その後、様々な変遷を経てブラッシュアップされた現在のドキュメント文化についてご紹介します。
ドキュメントの事例をご紹介しながらになりますので、実際のドキュメントを想像していただけるのではないかと思います。
最後に現状のドキュメント文化に関する振り返りを行います。 ドキュメント文化によって得られた良い側面と課題、そして今後の展望についてお話します。
この記事を書いた人
成瀬 真（なるせ まこと）
Cloudbase株式会社 プロダクトチーム エンジニアリングマネージャー
京都大学工学部情報学科を卒業後、メルカリに入社。通知基盤のマイクロサービスの開発、グループ共通のメール配信基盤の刷新などに従事。
2022年8月よりCloudbaseにジョイン。フルマルチクラウド(AWS,GCP,Azure)人材としてセキュリティスキャンの開発やお客様との伴走を行う他、エンジニアリングマネージャーとしてCloudbaseの組織課題に向き合っている。
Cloudbase入社前
Cloudbase入社前、私は株式会社メルカリでソフトウェアエンジニアをしていました。 メルカリもまたドキュメント文化が強い組織で、当たり前のようにドキュメントを書いてディスカッションを繰り広げていました。 当時から私はドキュメント文化には以下のようなメリットがあると感じていました。
複数の選択肢についてドキュメントベースで議論することによって十分な考察が得やすいこと
意思決定の根拠を残すことによって後世の改善に役立てること
Cloudbaseのドキュメント文化の起源
そうした背景もあり、Cloudbase初期の私はまずDesign Docを残すことから始めようと提案しました。
Design Docとは、システム設計について記載したドキュメントのことで、要件を満たすために下記のようなポイントを記載しています。
どのような実装を加えるのか
どのような構成にするのか
データベースのスキーマ
当時いくつかの開発を行っていましたが、その中でも以下の2つの開発・改善について、Design Docの執筆を試みました。
当時限界が訪れていたスキャン結果のデータ構造(RDBレベル)を刷新するための議論
開発中のコードを上げることができる環境(通称lab環境)を作るための議論
これら2つは概ね2022年8月に執筆されており、これがCloudbaseのドキュメント文化の起源です。
これらの議論は前章で載せたいずれかのメリットについても満たしているものであり、この記事を作成する段階で読み直しましたが、確かに当時の意思決定を明確に思いだすことができました。
また、スキャン結果のデータ構造改革の話が再び生じた時にも、過去の議論を参照しながらなぜ今の構造になっているのかということを理解しながら議論を進めることもできました。
現在のドキュメント文化
それから1年半、Cloudbaseの状況は少しずつ変化を重ねています。 それに伴い、Design Doc以外のドキュメントが登場したり、Design Doc自体の責務が増加したりもしました。
Design Doc以外のドキュメントの登場
こちらについてはPdM大峠による開発プロセスの記事でも触れていますが、開発プロセスの中で以下の4つのドキュメントを書くようになりました。
Experimental Doc
Requirements Doc
Design Doc
QA Doc
詳しくはPdM大峠のこちらの記事を参照ください。
これは当初暗黙化されていた仕様やQAプロセス、実施すべき実験とその立証に必要なデータを明文化したもので、よりドキュメント文化が強まっていることの表れではないかと思っています。
Design Doc自体の責務の増加
プロジェクトマネジメントの進化やリリース期日の厳格化に伴い、Design Docの時点でタスクや見積もりを確定する必要性が増しました。
そのため、Design Docで実装方法を検討するタイミングに合わせてタスク出しについても行っています。
特にScannerチームのDesign Docについてはまさにこの4月からリニューアルを行なっています。 Scanner分野はその特性上100%のカバレッジを持ったスキャナーの開発がとても難しくなっています。
そこで、Design Docの執筆時点である程度のケースの洗い出しと、受け入れ基準の確定を行うようになりました。
具体的には、インターネット公開を判定するスキャナーを作る際には、「全体ではこんなケースでもインターネット公開できるかもしれないが、xxxとyyyのケースがカバーできればリリースOK」ということを、Design Docの時点で確定させています。 その他、品質についての受け入れ基準も明文化し、受け入れ基準を満たすことで機械的にリリース可能と判断することができます。
実際に品質に関しては岩井がまとめていますので、こちらも併せてご覧ください。
ドキュメントの事例紹介
振り返り
最後に、僕たちはまだまだ発展途上ですが、これまでのドキュメント文化について振り返りをしてみようと思います。
スタートアップの初期からドキュメント文化を作ると何がいいのか？
一般的に考えると、ドキュメントを書く時間を作るくらいならばコーディングに時間を割く方がアウトプットが出るのではないかと考えがちです。
しかしながら、私たちは自信を持ってスタートアップは初期からドキュメントを書くべきだと思います。
理由として、大きく2つのメリットがあると考えています。
開発から時間が経っても過去の議論に素早くアクセスできる
ドキュメント文化の啓蒙が必要ない
開発から時間が経っても過去の議論に素早くアクセスできる
根拠を持ってディスカッションしたドキュメントが組織に蓄積されていることは、資産です。 その当時の最善策として打った解決策は、その数年後に見返したとしても価値のある知見としてインプットすることができます。
現に2022年8月に執筆したドキュメントを今読んだとしても、知見を得ることができます。何か議論を始める前に過去の議論を参照することで、同じような議論の繰り返しを避けることができます。
ドキュメントを執筆してそれをベースに意思決定を繰り返していくことで、スタートアップは爆速で成長することができると信じています。
ドキュメント文化の啓蒙が必要ない
ドキュメントを書くことが初期から開発フローに組み込まれていることで、後からステークホルダーを巻き込んでドキュメント文化を形成していく必要がありません。
また、ドキュメントベースで議論ができることが採用基準に含まれていることからも、ドキュメント文化に相入れない方がチームに参画する可能性も低いため、「ドキュメントが必要かどうか」の議論をする必要が基本的にはありません。
スピードが重要なスタートアップにおいて本質的な議論に注力できることは非常に重要です。
現状の課題と今後の展望
一方で、ドキュメント文化に対する課題も存在しています。
1つ目の課題が、その膨大さです。
ドキュメントの数が多いことはとても良いことですが、その膨大さからキャッチアップコストが嵩んでしまうという課題が生じています。
ドキュメントの置き場所や対象の読者を明確にする
ドキュメントの目的(議論・発信・タタキ)を明確にする
などの対策を行っていますが、まだまだ新入メンバーには認知的負担をかけてしまうような状況が続いています。
また、その膨大なドキュメントのほぼ全てを私たちはNotionで管理していますが、検索性が低下しているという課題も存在しています。
2つ目の課題はバージョン管理です。
Design Docやその他のドキュメントは議論を経て大幅な変更をしたり、あるいは書き直したりすることがあります。そうなった場合にも、古いドキュメントが残されているケースが散見しており、その点も正しい過去の情報に行き着くことができない要因となっています。
こうした課題を抱えつつも、Cloudbaseが持つドキュメント文化はどのスタートアップにも負けない強力さを持っていると感じています。
こうしたドキュメント文化の良さを伸ばすため、正しく必要な情報に対して、最小の認知負荷でたどり着けるような改善を進めていきたいと考えています。
さいごに
さて、この記事ではCloudbaseのドキュメント文化についてご紹介してきました。
弊社では、シードフェーズからドキュメント文化が根付いている組織の中で爆速で開発を進めていただける仲間を絶賛募集中です！
初期からドキュメントが根付いていることで、今まで誰も見たことのないレベルの世界を一緒に作っていきませんか？
ドキュメント文化に少しでも興味を持ってくださった方と、お話できることを楽しみにしています！
CTOの宮川がカジュアル面談を実施していますので、ぜひ下記のリンクよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？