100: アウトプットに対してドキュメントでフィードバックする

Published on
December 26, 2022

概要

知識や気づきが組織にちゃんと蓄積されるように。伝えたい内容が相手に意図した通りに伝わるように。

文字起こし

powered by whisper.cpp

皆さんこんばんは。カドッペFM第100回目の配信です。 このポートキャストは、僕ソフトウェアエンジニアのカドッペが日々仕事をする中で気づいたり考えたり感じたりしたことをゆるくお話しするような番組です。 ついに100回目の配信にたどり着きました。おめでとうございます。 今このポートキャストは、アンカーFMというプラットフォーム上で配信しているんですけれども、 前身のポートキャストが、スタンドFMというオーディオ配信プラットフォームで配信したんですね。 前身の方で大体88回くらいかな。 しばらくお休みしていて、これから100回新しいプラットフォーム上で到達できたので、 今日は何を話そうかなって悩みながら、 さっきまで配信をやめとこうかなと思ったんですけど、ちょっと話してみたいこともできたので、 一つ小話をさせていただければなと思います。 今日お話しするのは、アウトプットに対するフィードバックの返し方の話なんですけども、 ちょっと前一度やってみた時に、良いやり方っていうのを見つけまして、 それがですね、アウトプットに対してフィードバックを返す時に、ドキュメントで返すっていうのをちょっとやってみました。 どういうことかと言いますと、例えば、誰かがNotionに何かの方針を書くじゃないですか。 叩き台を作ったんで、もし何かコメントとか意見とか違和感とかあればコメントお願いしますって言われるじゃないですか。 普通にそれに対してフィードバックを返そうとすると、 ミーティングで口頭で伝えるとか、あとはNotionだったりすると、ドキュメントに対するコメント機能があるので、そこでコメントしたい場所にハイライトをつけてコメントする。 そこでディスカッションしていくみたいなやり方が普通かなと思うんですけども、 今回やってみたのはドキュメントでフィードバックを返すっていうところで、 そのレビュー対象というかフィードバック対象のアウトプットを見て、こうした方がいいんじゃないかなとか、 こういう考え方ができるともっといいアウトプットになるんじゃないかなっていうアイディアが自分の中に出てくるわけですね。

そういったものを切な的な口頭の言葉とか、ドキュメントのコメントの上に残してしまうと、なくなってしまう。 何かの表紙に消えてしまう。口頭で説明したことは相手の頭の中に残らないかもしれないですし、 そもそも伝わらないかもしれないし、間違って伝わることもありますね。 そういったコメントも、同所のドキュメントのコメントと解決済みっていうのが消えちゃう感じになりますね。 なので、しっかり自分のアウトプットを見て考えたこと、気づいたことっていうのを、 マレージとして、自分自身のためだけでなく、アウトプットをしてくれた相手だったり、未来の自分たち、あるいはチーム全体のストック情報として、 ドキュメントを書いて、そのリンクを渡してコメントするっていうのは、結構理にかなってるなぁと思ったんですね。 しっかり刹那的な情報じゃなくて、ストックされるってことと、口頭で伝えるよりも、 それは自分のコミュニケーション力の問題でもあるんですけど、 しっかり時間をかけて、ドキュメントの形で構造化して書いた方が、相手にも伝わりやすいし、理解もしやすいし、間違って伝わってしまうようなリスクも減るのかなと思います。 もちろんね、ささいなコメントとか、口頭とかコメントで返しちゃえばいいと思うんですけど、 何かしら今の自分たちがかけているナレッジなんじゃないかとか、 これはちゃんとストックしておいた方が、今後のあらゆるアウトプットに効いてくるんじゃないかとか、 そういったものを見定めて、ドキュメントとして先に作ってから、そのドキュメントをヘッドバックとして返すっていうのが、今のところですね。 以前いた会社で、似たような取り組みをやってた時があって、 サーズのプロダクトを作っている会社だと、カスタマーサポートの部署があると思うんですけど、 その時にお問い合わせが来るわけですよ。 カスタマーサポートセンターにチャットで、 「ここの作り方がわからないです。どうすればいいですか?」とか、 「ここなんか変な動きしてるんですけど、不具合ですか?」とか、 そういったいろんな人に問い合わせが日々送られてくるわけなんですけども、 その会社ではある時、お客さんはすぐ返答が欲しいのかもしれないけど、 その質問に対してチャットのテキストで、そのまま返信するのはやめようみたいな仕組みというか、 運用が発動した時があったんですね。 目的は何だったかっていうと、 お客様の問い合わせって、プロダクトをより良くする、すごくいいチャンスなわけなんですよね。 ボイスオブカスタマー、VOCって言ったりするんですかね。 なんですけど、それを、 何だろう、チャットの問い合わせを、 チャットのテキストをそのまま返してしまうことで、 プロダクトをより良くする機会を逃してしまうリスクがあるんじゃないかっていう風に捉えて、 強制的に問い合わせをプロダクト、あるいはサポートドキュメントとかそういうものもプロダクトの一部として捉えた時に、 問い合わせをいただいたことを、強制的にプロダクトにつなげるルートをまず作ってみようと、 その癖を作ろうみたいなイメージで、 チャットの問い合わせを返すんじゃなくて、 チャットテキストで、チャットメッセージでこの問い合わせの返信をするんじゃなくて、 サポートドキュメントを書き換えたり、新しく書き出す、作ってからそのリンクを渡して書いたとしようであるとか、 不具合についても、 何だろう、ワークアラウンドみたいなその、迂回策を提示するよりも、 さっさと不具合を直して、ペプロイして直しましたっていうような、 結果を持って返事をしようっていう、 そういった仕組みが一時期動いている時がありました。 以前いた会社でですね。 それをやることで、もちろんそのお客様への回答スピードっていうのは遅くなってしまうんで、 お客満足度みたいなものは下がってしまうんですけども、 運営しているチームに対するプロダクトとか、ドキュメントとかに、 ちゃんとストックするっていう癖、流れがしっかり確立できて、 いいこともあります。 その流れが確立できるタイミングで、その運用を解除して、 そんな縛りがなかったとしても、適切なプロダクトに繋げるべき、 適切な問い合わせを適切に繋げていけるっていう、 そういったことができるようになってるよねと。 なんかそういう、強制技術みたいなやり方があったんですね。 それと似てるなと、さっきのフィードバックに対してドキュメントに返すっていうのもそれと似てるなと思って。 なんでこれから、自分が何かしらのアウトプットに対して、 コードレビューもそうですし、ドキュメントとか方針とか戦略みたいなレビューもそうなんですけど、 何かしら少し大きめの考えを伝えることが必要になってきたタイミングでは、 切な的に残すコメントを伝えるんじゃなくて、 しっかりドキュメントに残して、ストックして、それを持って伝えるっていうことをやっていけたらなと思っています。 はい、こんな感じですね。 今もちょっと犬が2匹か、喧嘩しててですね。 なんか、Podcast収録し始めると最近喧嘩を始めるような気がして、 ちょっと嫌だなっていう感じなんですけど。 そういうドキュメントにして、フィードバックを返したいという気づきというか、決意みたいなものが出てきたので、 その記録として、今回第100回目の配信として喋ってみました。 100回目だからといって、スペシャルな内容ではなかったと思うんですけど、 これからも引き続きこんな感じでゆるーくお話できたらなと思います。 はい、ではここまで聞いてくださった方ありがとうございました。 はい、次回の配信もぜひお聞きください。 それではまた。