93: 重要な意思決定は背景情報も含めて記録しよう

Published on
December 2, 2022

概要

会社 / 組織 / 開発プロセス / プロダクト / システムアーキテクチャなど、それぞれ領域でインパクトが大きい意思決定や変更を行うときは、背景情報(解決したかった課題や取り得た選択肢など)も含めて記録するのが大事、という話をしました。

このあたり工夫されている方や企業がいらっしゃいましたら、事例を読んだり、お話伺ったりしてみたいです。

文字起こし

powered by whisper.cpp

はいみなさんこんばんは カドップFM第93回目の配信です 今日も仕事終わりに 収録しています 金曜日なので 少し いつもより開放感があるというんですかね そんな気分で収録してるんですけれども あの今日はすごく ミーティングが多くて あと自分がホスト、オーナーのミーティングも多かったので ちょっとね 頭ミーティング疲れというか そんな大した長さ、数ではないんですけど ハシリテーションって結構自分の中では 準備とかも含めて 頭のリソースを使う仕事の部類なので 夕方にそのミーティングが終わった後 ちょっとぼーっとしちゃって 休憩しちゃってました はい でも一旦落ち着いたので 少し気分転換に コミュニケーションを収録している感じですね で今日は コンテキスト、背景みたいな話をしようと思うんですけど いろんな決定とか プロダクトの変更だったり システムアーチテクチャの変更だったり に関して なんでその変更したのかっていう背景情報がすごく 重要だよねという話ですね たまたまそういう話をここ最近 会社の中でもすることが多くて 改めて 自分の考えていることを言葉で整理しておきたいなと思います なんでそういう背景情報が必要なのか重要なのかっていうと 後からわからなくなるんですよね 端的に言うと なんで例えばシステムアーチテクチャの変更だったとして なぜその変更したのか 課題は何だったのか そのために課題を解決するために選択できるアプローチとして何があったのか それぞれのアプローチをどのように比較したのか 少々は何で 短所は何で 結果 どのアプローチを採択したのかそれはなぜかみたいなことが ちゃんと 大きめの意思決定設計上の意思決定とか変更に関しては残っていないとですね 後からまたその同じ部分に対して変更しようと 何かしら改善したいっていう人がいたときに また同じ状態に戻っちゃう もしかしたらこういうことがあったから今の状態になってるかもしれないのに それを知らずに戻しちゃうみたいなことが起きるかもしれないですし さらにより良くするということに当たっても なかなかこの なんていうんですかね 今なんでこの状態になってるのかっていうのを知らないと建設的な議論がしづらい のかなと思っています 建設的な議論がしづらいというか 正解にたどり着きづらくなるんじゃないかなと思っています そもそもそういう背景の情報コンテキストの情報がわからないとあれ今ってなんでこんな風になってるんやっけ これってなんか理由があるのかなないのかな わかんないなぁもうわかんないからいいや とりあえず置いとこうみたいなことになることもすごくもったいないと思っていて 機械損失? 本当はその部分に関してもっともっとよくできるアイデアを持っている人がそのための議論を起こせなかったり行動できない みたいなことがすごくもったいないなと思うので やっぱりそのコンテキストに関する情報背景の情報ですごく大事だなと思います そのシステムアーキテクチャに関して言うときちんとデザインドキュメントっていうのを残してさっき言った背景課題選択肢 意思決定理由 まあその結果とかそういったものがちゃんと構造的にドキュメントに残すって言う ことがすごくいいことだよっていうふうによく最近 記事を記事で目にすることが増えたと思うんですけども なかなかこう 実践できてる 会社って 僕が勤めた会社はなかなか実践完全に完璧に あの できてるところはあんまなかったので なんか今いる今の会社はすごくこれから頑張っていくぞっていうフェーズなので ちょっとやっていきたいなしっかりやっていきたいなと思っています 少しそのドキュメントを書くっていうコストがかかるので全ての変更において えっと そういった情報を残すべきかっていうとそうじゃないかもしれないですけど大体の大きな変更に関しては 必ずストックされているような状況を作って 将来 仲間になってくださる かもしれない優秀な人たちがですね すぐさま入社してすぐさま 自分のこれまでの知見をもとに 自分たちの新しいプロダクトを より良いものに新しいシステムアーキテクチャをより良いものにしていくための意見が出せる フィードバック出せる議論ができるそのための 足がかりとして 背景情報コンテキスト情報をしっかり残していこうと思います でこれってその今システムアーキテクチャとかそういう話をしましたけど それだけじゃなくてプロダクトの変更点意思決定とか事業方針の変更点意思決定の内容とかもしくは 組織とか開発プロセスとか 仕組みとか何でも言えることだと思います よく 少し大昔に決まったルールがずっと運用されてて 中にもともとずっと長く会社にいる人たちはもう本当に 惰性というか習慣化されてしまっていてその存在意義を疑わずに ルールをなしているという状況があった時に 新しく会社に入ってきたメンバーが なんでこれやってるんやろなんか意味あるんかなないんかなみたいな えでもこれって無駄じゃないある非効率だからこういう方法にした方がいいんじゃない みたいなことを思うこと結構あると思うんですけど その時も より良いアプローチを 考えるためであるとかそもそもそこに対してフィードバックをするために やっぱり なんでそういうルールを作ったのかそういう組織仕組みになっているのかっていうのを 記録として残しておく背景情報コンテキスト情報として残しておくことはすごく大事だなぁと思っていて なんかきっとこういうことになっているってことは 何かしら昔なんかあったんだろうなとか なんか意味があるんじゃないかなと変に 勘ぶる疑って こう動こうせないっていうのが結構ありそうな これ経験則ですけどもありそうな感じがしていますなので システムアーシテクチャーのそういう変更履歴のコンテキスト情報だけじゃなくて 本当に会社の活動 特にインパクトがある大きめの変更意思決定に関しては 向き並み残していけるといいなと そんな風に今日ちょっと思いました どうなんですかね 技術的な意思決定も組織的な意思決定も一号的な意思決定もしっかりコンテキスト情報も含めて 記録できている会社さんってあるのかななんかどうやってるとか なんかそういう事例みたいなのがもしネット上に転がってたりとかしたら なんか呼んでみたいですし もしそういう人そういうことに取り組んでる人とお話する機会もあれば ぜひ一度お話ししてみたいなって思ったりします 正直でも めんどくさいなっていう気持ちはあるんですよね 気持ちわかるというかもしやってなかったとしてもその人の気持ちわかるっていう 僕もどっちかっていうと 頑張るかっていう風に なんだろう 覚悟をしないと書けない 記録を残せないような日もするんで どうしてもさじゃっとやっちゃいたい 課題もさじゃっと目の前から解決しちゃいたいっていう風な 引力があって なかなか長期的な未来のことを考えたストックっていうところを しっかり大事にやっていこうっていう気持ちがなかなか湧かないっていうのも 共感するというか 自分は結構そう だったりするんで 背景コンテキスト情報を 残すための残しやすい環境とか仕組み作りってどんなものがあるのかなとか それでハードルが下がったとしてもやっぱり 肝心なのは実際に 仕事をしている人の心がけみたいなところが大きいんじゃないかなと思うので みんなどうしてるんだろう オープンソースの今日教えてもらったのはChromiumの デザインドックのポータルみたいなサイトをしてもらったんですけどそこは いろいろな ものがいろいろなChromiumの各種重要な仕様とか アーティステクチャに関する意識的なログが 残ってたような気がします そうなんですよね これかな でもスナップショットしか残ってないのかな Chromiumのやつも 過去のログみたいなところはそこまで残ってないのかもしれない全部見てるわけじゃないですけど ちょっといろいろ事例を 見ていこうかなと思ってます はい こんな感じですね どんどんどんどん 最近の頭の中はいかにして情報構造化して 将来の自分とか将来の仲間含めてアクセスしやすいかつ価値があるようにどう残して いくのがいいのかっていうところと その情報自体もしっかりしつ なぜそうなったのかっていう背景情報も含めて残していくにはどうすればいいのかっていうところが 関心ごとになりつつあって でもなかなか自分でしっかりやれたことはないので どうするのがいいのかなっていうところをちょっと模索したり勉強したいなと思っている気持ちです はい 今日はそんな感じかな 今日はですね あらゆる会社の活動の意思決定とか変更内容についてコンテキスト情報背景情報を残すことの重要性について話してみました 今日の配信はこれぐらいにしようと思うんですけども また次回この配信も聞いてくださる方がいらっしゃいましたらぜひ 聞いていただきますと幸いですではここまで聞いてくださった方ありがとうございました それではまた