こんぼい氏の自己紹介

こんぼい氏:よろしくお願いします。「非同期な開発体制を支えるドキュメント文化」ということで発表します。

まず自己紹介をします。矢吹遼介と申します。Launchableという会社でソフトウェアエンジニアをやっています。インターネット上ではゴリラのアイコンで「Konboi」というIDでやっています。よろしくお願いします。

Launchableについて

はじめにLaunchableについて軽く紹介させてください。USに本社があって、Jenkinsの作者の川口さん(川口耕介氏)がSun(Sun Microsystems)の時の同僚のHarpreet(Harpreet Singh Bindra氏)と2人で創業した会社です。Predictive Test SelectionとかTest Triage、Insightなど、CI環境、テストにまつわる困りごとをテスト環境に貯まったデータを使って、良い感じに解決するSaaSを開発・運用しています。

2023年に「YAPC::Kyoto」で提供しているPythonのCLIツールを、ありがたくも紹介させていただきました。

うれしいことに、Python 3.5のサポートを昨年切ることができました。どうもありがとうございますって感じですね。

(会場笑)

笑っていただきありがとうございます。まだ2021年にEOL(End Of Life)を迎えているPython 3.6は絶賛サポート中です。

本セッションにおける“ドキュメント”と“ドキュメンテーション”の定義

今回のテーマは「WHAT YOU LIKE」ということでドキュメントに関して話すんですが、僕は昔からドキュメントに関する苦手意識みたいなものがけっこうありました。「何を書いたらいいんだ? どう書いたらいいんだ?」みたいな。

ただ、Launchableに入っていろいろドキュメントを書く中で、今は「ドキュメントを書かずにどうやって仕事を進めるんだろう?」みたいな、そういうイメージが逆に湧くぐらいになりました。

昨今はリモートワーク……。より戻しとかもあるんですが、リモートワークのTipsとして、ドキュメントの話とかが出てくるんです。「ドキュメント良いよ」って言うんだけれど、「じゃあ、どういうふうに書いてるの?」みたいな具体例は少ないなと思ったので、今回は僕たちのドキュメントを一部さらして「お好み」を紹介できればなと思っています。これをきっかけに他の会社さんの事例も出てくるとうれしいです。

この発表で出てくるドキュメントというのは、詳細設計書やAPIドキュメントのようなものではないです。どちらかというとDesign DocとかADR(Architectural Decision Records)というようなものに近いと思っています。

Launchableでは「Confluence」をドキュメントのツールとして使っています。発表内では「ドキュメント」は書かれた文章や「Confluence」のページのことを指し、「ドキュメンテーション」はそのドキュメントを書くこと、またはページを作ることを指します。

ということでちょっと前置きが長くなっちゃったんですが、始めていきます。(スライドを示して)こんな感じで進めていきます。

ドキュメンテーションを大事にしている組織的な理由

まず、なぜLaunchableがドキュメンテーションを大事にしているのかを紹介させてください。組織的な話とドキュメントの持つ力そのものの大きく2つがあると思っています。

まず、LaunchableはUS側に本社があり、開発メンバーは日本とUSにそれぞれいるんですが、アメリカの西海岸、カリフォルニアやサンフランシスコあたりは17時間、ニューヨークの東海岸とは14時間の時差があります。

日本の午前中はアメリカの夕方という感じで、タイムゾーンがかぶっている時間がけっこう限られています。なので、それ以外は日本の早朝とか夜とかにミーティングを調整しないといけず、ミーティングの調整コストがすごくかかっています。

チャットツールとして「Slack」を使っているんですが、そこで長々議論するのも、やはりある程度同じタイムゾーンにいないと進まない。こっちが夕方にレスポンスして、返ってくるのが朝みたいな、1回のリレーに1日かかるようだと、やはりなかなか難しいなと感じています。

あとは英語ですね。僕自身の問題ですが、やはりリアルタイムでガンガン議論をしてリードしていくには、まだ僕の英語のスキルではやはり難しいものがあるなと感じています。

ドキュメントを介してコミュニケーションをすることで、1回のやりとりで多くの情報を詰め込めます。あとは、昨今「ChatGPT」とか「DeepL」、「Grammarly」などのAIと言われるツールがたくさんサポートをしているので、その恩恵にあずかることができます。

リアルタイムで集まるミーティングとかデモとか、同期的に行うものに時間が割けるので、ドキュメントがけっこう根付いているのかなと思います。

ドキュメントが持つ強み

あとはドキュメントの力ということで、ドキュメントを書くことで時間を節約できます。書くコストはもちろんあるんですが、先ほど言ったように、ミーティングのコスト、スケジューリングのコスト、参加そのもののコストを減らすことができます。

関係者が多ければ多いほど、スケジューリングコストがやはり大変ですし、偉い人に見てもらうとなると、その人のスケジュールを押さえるのが大変みたいなことはけっこうあるかなと思います。

ドキュメントを書くプロセスを通して、より深く考えられるかなと思っています。書く過程で「構成をこう説明していこう」とか、論理に破綻がないかどうかを考えたり、そのプロセスを通して何度も何度も考えることによって、考えそのものが洗練されていく。

読み手もミーティング中に即レスポンスを求められるわけではないので、何回も何回も読み返すことができ、深く理解をすることができるのがドキュメントの良さです。

最後に、フィードバックが深く、さらに平等にできるというのがあると思います。例えば、会議だとすぐにリアクションしないといけないみたいな難しさがけっこうあるんですが、ドキュメントだと「そもそもこの構成が良くない」という話もあれば「考え方が良くない」とか「このワードが良くない」とか、いろいろな高度から……。ここでは「高度」と表現したんですが、いろいろな高度からフィードバックができます。

何度も言ってますが、ミーティングで、みんなが話している中だと、「苦手です」とか「ちょっと違うと思います」と言うのって、けっこう難しいじゃないですか。ですが、ドキュメントだと平等にフィードバックをすることができるので、それが強みかなと思います。

(次回につづく)