見出し画像

ドキュメント駆動開発で「仕事がコントロールできていない」感から抜け出す

本記事はKanmu Advent Calendar 2023の記事です。
昨日はtadas氏による、「2023年、見た映画」記事でした。映画、全然観てないなぁ… あ、「劇場版 Psycho-Pass Providence」観てました。あれは最高でしたね。

というわけで、カンムのソフトウェアエンジニアの@sho-hataです。最近は妻が寿司打にハマっており、懐かしい気分でその様子を見ています。ちょうど3年ほど前、エンジニアになる前の私も、人差し指タイピングを脱却するために毎日やっていました。センスがない私は損するスコアばかりを叩き出していましたが、比べて妻はメキメキと上達しているので、やっぱり才能ってあるんだな、と。
さて、今日の記事の内容です。それは「仕事がコントロールできていない」感から抜け出すために、ドキュメントに仕事をさせよう」という話。

「仕事がコントロールできていない」感

「この人なんか仕事がうまくいってないなぁ」と思っている人がいる。それは自分自身だ。仕事の充実感は、仕事を自分でコントロールできているかどうかに大きく影響されると思っているのだが、ソフトウェアエンジニアになって3年目、ずっとどこか"仕事がコントロールできていない感"に悩んでいた。

主語が大きくなったが、ここで想定している「仕事がうまくいっていない」の一例はこんな感じ。いずれも実体験に基づいている。

  • 想定したタスクより、想定していないタスクの量が多かった

  • 詰まっているとき、今やっているタスクが全体の工程のどこに位置しているのかパッと伝えられない

後々になって考慮していなかった事態が発生し、その埋め合わせを場当たり的にやって、また新しい問題が発生して、自分の設定した期日に遅れ...なんとも自己肯定感が下がるサイクル。これを3年間も繰り返している。

だが、やっと最近仕事がコントロールできていない感の解決策の糸口を見つけた。それは、自分の仕事をドキュメントに任せるということ。今回はそれについてつらつらと。

'あの人の仕事は本物'と言われる人の仕事

自分が所属している会社は攻殻機動隊の公安9課の如く、バリバリの実力者が揃っていて、エンジニアでなくともプログラムやSQLを書いて業務をこなしている。端的に言うと、実績あるエキスパートが集まったマッシブな組織。
そんな組織の中でも、さらに「あの人の仕事は本物」と実際に言われている圧倒的な人がいる。summerwind氏という技術イケメンなエンジニアなのだが、この人はマジで仕事ができる(こう、文章に落とすとなんだか上から目線のように見えるな… マジで尊敬している)。彼とはチームが違うので直接一緒に開発、ということはあまりないのだが、その仕事ぶりの片鱗を節々から感じ取ることができる。一つ実体験としては、彼が少し前に担当したクレジットカードの3Dセキュアに関わる機能を私が少し触るときに、彼が書いたドキュメントを読むことがあった。そのドキュメントには、開発に必要な前提から技術仕様、実装とデプロイに関する補足情報まで網羅的に書かれており、なんと読むだけで全てを理解することができた。
こういった他の人の仕事を引き継ぎでは、当時の状況についての質問を何回かラリーして、やっと全体像を把握して、そこから着手…といったように、情報の伝達に多くのリソースが割かれる。だが彼の仕事はドキュメントを読ませるだけでやってのけた。
驚くべきことに、他の人に向けたドキュメントだけでなく、自分しか見ないようなメモ書きドキュメント(弊社では自分だけのドキュメントも、積極的にesaにアップロードし閲覧できる文化がある)の内容も読みやすく、かつ充実している。

彼の圧倒的な生産性を誇るドキュメント術を盗もうと思い、直接1on1を申し込んでドキュメントをうまく書く方法を聞きにいった。このとき聞いた気になる秘訣は、なんと本人にテックブログとして書いてもらったので、ここでは説明しない。以下のブログは要チェックだ。最高すぎる。


ドキュメントに仕事をさせる

1on1で聞いた、彼がドキュメントを書くときに考えていることを実践し始めたことで、自分の書くドキュメントの質が大幅に向上したと思う。最初は、自分でそう思っているだけの自己満足だと思っていたが、チームメンバーからも良いフィードバックをもらうことが多くなりそう確信した。

ここから、途端に日々の仕事がコントロールできている感覚が生まれてくる。不思議な話だ。少し意識してドキュメントを書くだけで、仕事がコントロールできるなんてそんな訳あるのか?と思っていたのだが、実際にうまく回り始めたのだから事実である。

ここで意識したのは、以下のようなごくシンプルな方針だ。

  • 新しい開発タスクに着手する際は、まず全体像がぼやっとしている段階でも前提知識や制約条件を整理する

  • タスクを進める中で分かった情報があればどんどんドキュメントに追記する

  • 他のメンバーへの情報提供は、口頭で説明するのが必須な事項・タイミングを除き、可能な限り書いたドキュメントを読んでもらう

  • 口頭で決まったことや他の人の質問・意見をもらったら必ずドキュメントに追記する・追記してもらう

ここでの重要な点は、仕事をしているのは自分ではなくドキュメントということだ。チームメンバーとのやりとりも、ドキュメントが常に介在している。これの何が良いかというと、まず情報の共有が非常に効率的になる。ドキュメントを通してのやりとりは、口頭での説明やミーティングでのやり取りとは異なり、情報が曖昧になることがほとんどない。
また、ドキュメントは時間と場所を選ばずアクセスできるので、必要な時にいつでも情報を確認できる。このようにドキュメントを中心に置くことで、仕事の進行具合をリアルタイムで確認でき、必要に応じて素早く調整を行うことができるようになった。
さらに、ドキュメントを中心に仕事を行うことで、タスクの透明性が高まった。チームメンバーも私が何に取り組んでいるのか、どのような進捗状況なのかを一目で理解できる。これは私自身のストレスも大きく軽減される。うまくいっていないときなんて、口頭で説明すると大抵うまく伝えられないからね。

すげー人の仕事を観察すると、同じようにドキュメントに仕事をさせているように見える。ふらっと「そのことについてはこのドキュメントを読んでおくと良いですよ」とか。
つまり、仕事をコントロールするのに必要なことは、地頭の良さや難しいことをパッと判断できる瞬発力ではなく、「ドキュメントに仕事をさせる」ことだと思う。もちろん色々他にもあると思うが、当面はこれを信じてやっていこうと思う。

LLMを利用したドキュメント作成のtips

ここまでドキュメントについて述べてきたが、やはり文章を書くと言うのは億劫で面倒な作業だ。今は人間ではなく、LLMに任せる時代だろう。
ここからは自分がLLMを利用してドキュメントを書くときに思った感想やちょっとしたtipsを述べていこうと思う。進化が本当に早いので、すぐ陳腐化するかもしれないけど。

生成したアウトラインや内容に固執しない。常に情報を減らすことを意識する

よくLLMに記事のアウトラインを書かせる使い方をする。が、なまじLLMが賢すぎるので1トピックに対し網羅的な情報を吐き出してくる。これをそのままドキュメントにしてしまうと、辞書ですかと思わんばかりの情報量になってしまう。ドキュメントは「想定読者が必要な情報を最短距離で得られるようにする」もの。なるべく不要と判断した内容はバッサリ切っておいた方がいい。

図は貼り付け可能なダイアグラムツール記法で吐き出させる

私は、システムの構成図や開発タスクのリリースまでのフローチャートなど、脳内で考えたことサッとiPadなどで手書きの図を書く。その画像をマルチモーダルLLMに食わせ、「コピペ可能なmermaidの形式で書き出して」と伝えることで簡単に脳内で考えたことをドキュメントにダンプすることができる。いい時代に生まれたものだ。
自分のメモだけでなく、例えば、過去ホワイトボードに手書きで議論した写真がそのままドキュメントに貼られている、などのケースにも有効。改めてキーボードでガリガリ転記する必要はなく、LLMに書き出してもらおう。
※なお、食わせるデータには最新の注意を払い、組織のLLMガイドラインに沿った形で運用すること。

GPTに下手な図を読み込ませて、mermaidで出力してもらう
マークダウンツールに貼り付けるだけ。あんまり字が下手だとうまく読み取ってくれないが。

おわりに

カンムはリモートファーストで、非同期的な働き方を中心としている。だからこそマッチした部分も大きいのかもしれない。この記事でドキュメントファーストな仕事術に興味を持った方は、「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」と言う本がオヌヌメ。

また、カンムに少しでも興味を持たれた方は、採用ページも見てみてくださいね。

というわけで、Kanmu Advent Calendar 2023 2日目の記事でした。
ドキュメントに仕事をさせる術を突き詰めると、ドキュメントの裏で手を動かす主体が人間だろうがLLMだろうがどうでもよくなってくる気がする。
ずっと仕事を共にしていると思っていたチームメンバーが、実はLLMエージェントでした、なんてね。

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