00:05
はい、3月30日、月曜日、嘘つけ、木曜日ですね。 地獄朝9時7分になりました。すいません、昨日も一昨日もかな。
またちょっと寝坊したり、別の作業に集中していて、朝活スキップしてしまいました。ごめんなさい。 はい、おはようございます。kittsこのくわはらです。ではでは、本日も朝活を始めていきたいと思います。
本日はですけども、技術に関連するものではあるっちゃあるんですけど、今回は、すでに紹介している連載の一環として、私たちが技術的な意思決定を行うプロセスを公開します。
これの記事自体、リンク貼られてますので、興味のある人はそれを見てみてください。 このプロセスが皆様のお役に立てれば幸いです。もしかしたらご自身のプロジェクトに何かを取り入れることができるかもしれません。
というわけで、TLDRに行きたいと思いますが、これは技術的な決定を行うための一般的なオフラインであり、ルールというよりはガイドラインのセットとして受け取られるべきものです。
その目的は、効率化、適切な意見の収集、透明性の確保、賛同の可能性を高めるために役立つツールにセットを提供することです。
はい、というところでございました。ツールセットのお話になるかもしれませんね。 確かにそうですよね。メンバーとかいろんな人からも
目的とは効率化、適切な意見の収集とかをして、透明性の確保をしていくところですね。 あとは賛同の可能性を高めるために役立つところは結構いいですね。
技術を導入するために、賛同してもらえないと導入は見送られることが多いにありますし、やっぱりみんなの意見とか合意を持って導入するというのが正しいと思いますので、
そのための賛同の可能性を高めるツールセットというような話ですね。とても良さそうな感じがしますね。 まあ早速入ってみましょう。
ディシジョンメイキングなんですけど、ディターミンスコープとインパクトオブユアディシジョンですね。
意思決定の範囲ですね。 スコープ範囲とその影響範囲とかを決定しましょうってところです。
このプロセスはすべての小さな決断に適用されるものではありません。 このプロセスが適用されるべき例とガイドラインというのをいくつか紹介します。
いくつかにバーっとリストに貼られてますけど、まず一つ目は複数の人、チームにまず影響を与えるでしょうかと。
それについてはそのAPIのスキムの変更であったりとか、そのワークフローの変更であったりとかですね。タスク、プリリース、ツーリングなどですね。
また他の分野での追加作業や適用というのが発生するでしょうか。 また金銭的な影響を及ぼすでしょうか。
その変更によって追加の技術的塞いが発生したりとか、メンテナンスが必要になったりするでしょうか。
その変更によって新しいライブラリや技術の導入など、再学習への大規模な投資が必要になるでしょうか。
これを解決できる現在のソリューションがあるでしょうか、などなど。 これらの問いが浮かんでくるところですね。
今のはあくまでガイドラインですからね。これ全部満たさなきゃいけないわけじゃないですけど、一応この筆者の方ではこういうことを書いている、決めているということですね。
03:04
すぐに利用できるソリューションはなく、カスタムソリューションを導入する場合というのは、外部ソリューションの可能性を検討したことを常に確認する必要がありますよね、ということでした。
はいはい、まあそりゃそうだよねって感じですね。 まずはいわゆる影響範囲というのを決めましょうと意思決定するときは、範囲と影響を考えましょうというのが一つでした。
そのための今の問いに答えていくとか、問いをベースに考えていくというのが一つですね。 では続いてタイムボクシングですね。これは決定される内容によって大きく左右されるため、合理的なスケジュールを設定することが必要になります。
ただし決着がつかないまま放置したりとか、必要以上に長引いたりしないように決着までの期限を決めておくことも結構重要ですと。
はいまあこれ痛い言葉だなぁと思いますね、僕にとっては。 本当その通りな気がするので。
プロセスですけど今回は1から5までのリストだけがパッと貼られてますね。 一つ目はデザイントキュメントをまず作成しましょう。いわゆるテンプレート的なものですね。
しかもテンプレートのリンクも貼られているので、ちょっと見てみましょうかね。 軽く開きますけど、なるほどマークダウンで書かれたテンプレートなんですね。
どうでもこれを書き下すとテーブルになっていて、それをバーッと見ている感じですね。
ちょっとこれは後で自分の手元の方でこのドキュメント全部書き下してみたいと思いますけど。
ちょっと時間余りそうなので今日はそのままやってしまいますね。 あーなるほどなるほどいい感じですねこれ。
このテンプレートですけどマークダウンで書いたテーブル。まず最初にデザインドキュメントテンプレートと書いてますけど、放題のところですね。
まず最初にハイレベルオーバービューというのを作っていると。それがテーブル構造になっていて、レベルがまず1から2とかですね。あとセンテンスつけておいて、それについてディスクリプションを書いてくださいと。
あとそのチェンジサイズですね。変更の範囲がどれぐらいですかと。まあなんかスモール、ミディアム、ラージとかで決めていくと。
あとはアフェクティッドアプリケーションですね。アプリの影響と言いますか、効果みたいなところに近い感じがしますけど。
アプリケーションへの効果とか影響はどうですかと書いてますね。例えばワークデイとか、AGSゲートウェイとか、
そのままデザインとチェンジのことを書いていくと。あとはアフェクティッドチームズですね。チームに対しても同じようなことがありますか?みたいなところですね。
続いてオーナーを書いていくと。続いてパーティスパントディバイディングディスチェンジですね。
参加者とか関係する人たちですね。 ディバイディングじゃないですね。ドリビングでした。パーティスパントドリビングディスチェンジですね。
関係者がどういうことをしなきゃいけないということですね。変更するためにはってことですけど。 最後オブザーブズというので、いわゆる補足的なものとかですかね。
というのを書きましょう。というのがまずハイレベルオーバービューだと。ハイレベルっていうふうにつけるんですけど、マストではないらしいですね。
06:00
今までこうやってまずテーブルでガーッと書いていくと。 続いてサマリーをガーッと書いていくわけですね。
続いてプロポーズソリューションですね。解決の提案というのを書くと。まずはキーコンシデュレーションでこの解決策のコアとなるところを書いていって、
アーキテクチャーオーバービューですね。これもアーキテクチャーの概要とかをガーッと書いていくと。 ポテンシャルリスク&ドローバックスですね。手戻りとかリスクのところもちゃんと
その可能性を書いておきます。このままずっと続くんですけど、アペンディックスとかいっぱいインパクトが続くんですけど、ざっくり言うと
わかっていることとか可能性とか自分たちが考えたことの頭の中をつまびやかに書き下すみたいなところですね。それをカテゴライズして書いていくところですけど、
このテンプレート良さそうですね。これはこれで結構パックルじゃないですけど、全然使いにくいなと思いました。 これは別に今のディシジョンメイキングです。
意思決定のところの話だけではなくて、技術選定の話もそうですし、実際に機能について、アプリケーションとかシステム開発の機能開発におけるその設計の
なんかドキュメントとか、その議論するドキュメントとして残すのもこれは結構ありかもしれないですね。 かなりわかりやすくなると思います。書く文章が結構長いかもしれないですけど、これはこれでいいんじゃないかなというふうに
言いましたので、うーんと何かうまいこと導入してみたいなと僕も思いました。 じゃあ戻りますね。
はいはいはいはい。 じゃあ戻りまして、プロセスの話ですね。続きいきたいと思いますけど、まず最初はそのデザインドキュメントですね。
設計書に近いところですけどっていうのを作成しましょうと。 続いて2つ目が変更に影響を受ける全ての人に文章を確認してもらうと。
先ほどのドキュメントを影響ある人全てに読んでもらって確認してくださいということを委託する感じですね。
続いて3つ目がその提案を検討して決定を下すためのワーキンググループを結成すると。
4番はディシジョンミーティング、決定会議ですね。 会議で決定すると。最後5つ目決定結果の
さっきのドキュメントですね。設計書への記載をすると。はいはい。で終了すると。5つのプロセスを辿っていこうと。
なかなか面白いですね。でまた続いてですね、ロールズインガディシジョンメイキングプロセスと。
意思決定プロセスにおける役割っていうのを次は決めてますけど、いわゆるテーブル構造に乗ってますね。
ロールとレスポンシビリティーズっていうふうな2つに分けてます。 ロールの方は大きく3つですね、分かれています。
さっきのテンプレートの内容とほぼほぼ一緒なんですけど、ロールっていうのはまずディシジョンオーナー、イニシエイター、プロジェクトリード、モデレーターなどだと。
いわゆる引っ張る系の人?もっと抽象的になっちゃいますけども、いわゆるファシリティー側に近いですね。
人たちのことをまずある1つのロールと見てるらしいですね。 この人たちのレスポンシビリティー、いわゆる責任的なところですけど、
まずコンテキストを説明する、技術的な意味合い、大体案、トレードオフ、場合によっては実施例など、何を決定するのかを定義します。
09:01
参加募集のお知らせをします。 あと可能性があることとして、最終的に決定会議に参加するグループを選びます。
あとは他の可能性として事前に非同期で議論するためのドキュメントを整備しておきましょうと。
アーキテクチャー決定記録、いわゆるADRに文章化されていることを確認すると。
さっきのデザインドキュメントの設計者なんですけど、これADRっていうところも含まれる気がしますね。
やっぱり弊社はADRを文化として根づかせられているわけではないので、ADRをしっかり書いていくような文化にしたいなとちょっと思っておりゃしますね。
続きまして、パーティスパンツ、参加者ですね。 参加者に必要なレスポンシビリティ、責任責務というのは、意見を言うために知識をしっかり得ましょうというところでした。
最後はオプショナルですけど、オブザーバーですね。 この人たちは単純にリスン&ランですね。聞いてもらっておきましょうというのがオブザーブズですね。
ロールズインアドキュメント、ディシジョンメイキングプロセスと言いますけど、ほぼほぼファシリティとする方々がしっかり物事を進めていくというところですね。
なので、パーティスパンツとオブザーバーズはほぼほぼ何もしないなという感じがしますね。これを聞く限りだと。
パーティスパンツはちゃんと意見を言うぐらいですかね。聞いてどういうふうに思いましたかという感想ぐらいを言う。
いわゆるブラッシュアップの責務はこの人たちが担うという感じがしますけど、すべての意思決定、運用とか更新とかっていうところは準備っていうのは全部ファシリティエーターの人たちですね。
オーナーだったり、イニシエーターだったり、プロジェクトリーダーだったり、モデレーターがやりましょうというところでした。
続いて、ディシジョンオーナーですね。決定権者を決めるんですかね、これもしかして。
デフォルトでは意思決定というのはプロジェクトリードが所有し、プロジェクトリードはすべての大きな意思決定の最終責任を得ますと。
まだプロジェクトリーダーは意思決定の所有者を指定することもできます。バイアスを避けるため可能な限り意思決定権者は変更を提案する必要はない方が良いでしょうと。
まあそれはそうだよね。というところですけど、そうなんよね。
弊社みたいに、常時のいない会社だと意思決定者っていうのを決めることはなかなかないと思いますね。
最終的にみんなの合議で決める気がしますが、まあ合議で決まらないときに最後はエイヤで決めると思いますね。
最後にエイヤで決めるとしても、メンバーにもこれでいきますけどいいねって言って、何も言わない人はイエスとみなしたっていう風にみなす方が早いと思いますけど。
そうじゃない人はちゃんと意見を言ってきたりすると思うんだよね。
バッティングして物事が進まなかったら、まあやりながら改善しましょうというところでいいと思ったりしますので。
まあでも結果的に、最終的に決定した人に責任が行っちゃう気がしていて、それは僕はあんまりよろしくないなと思いますね。
みんなで決めたんだから責任はみんなにあるでしょっていうところに、僕は落としどころを決めたい感はありますが、
まあ決まらないときはやっぱり決定権者がいて、その人がガンと決めるのがいいなという気はしますけどね。
次はパーティスパンス・イザ・ディシジョンプロセスもしくはミーティングですね。
決定プロセスとはその決定会議の参加者ですね。
12:01
一般に、意思決定プロセスには次のような人々をお招待する必要があります。
決定によって影響を受ける人は少なくとも代表者でなければならないと。
テーマについて、まず専門知識をお持ちの方、あとはステークホルダー、その辺の人たちがいなきゃいけないねってことでした。
一番最初の抽象度が高いですね。決定によって影響を受ける人は少なくとも代表者でなければならない。
これは結構あれですね。抽象度高いなと思いました。
テーマについて専門知識を持っている人とか、ステークホルダーはもちろんその通りだと思いますけど。
とはいえ、意思決定ワーキンググループの参加者というのは通常4から6人で、議論を集中させ効率的に進めることができます。
影響力の大きい意思決定ではもっと多くなることもまあまあありますよね。
会社の中で全メンバーに影響するようなものとかだと、もっと多くなるのは仕方ないなという感じがしますよね。
議論に興味がある人はオブザーバーとして参加することもできます。
ただし意思決定者か何らかの理由でオブザーバーを意思決定会議から排除している場合は例外です。
例外であるべきだとも言っています。まあまあそれは仕方ないですね。
単なるガヤだったりとか、イチャモン付けの人たちだったりしたらそれは排除した方がいいですし。
逆もあると思っていて、すごく建設的なお話とかをオブザーバーの人たちが意見を出すんだったら、それは完全にパーティスパンツとして参加してくださいみたいな感じになるかもしれないですね。
まあ難しいところですけど、第三者としての目線でのお話をするというのが一つの中ではないと思っていますね。
はい、というところで、ここは難しいですね。オブザーバーの人たちにどこまで発言を許すかっていうのは会議とか場における設計だと思いますけど、
そういうのをどこまで許可するかっていうのは結構バランスが求められる気がしますね。
では続いて、ハイインパクトディシジョンですね。インパクトなる決断というところですけど、
意思決定のインパクトが非常に大きい場合、以下のようなベストプラクティスがありますと。今回4つですね。
1つ目は、より早く、より頻繁に、より多くの読者にまず称えましょう。
2つ目、ギルドのミーティングやその他のライブイベントでそのトピックを発表する。文章だけではなくてということですね。
3つ目、さらに人々が質問やコメントをすることができるドキュメントを提供する。
最後4つ目、決定会議にもっと多くのオブザーバーを参加させることができるようにするということですね。
やっぱでもオブザーバーはなんだかんだ受け入れる方がいいってことですね。
でもそれはそのハイインパクトディシジョンだからかもしれないですね。影響がでかいしインパクトもあるんだから、いろんな人の意見を先に聞いておくのがいい話ですね。
続いてコミットメントです。
トピックの中には複雑で準備が必要なものもあります。そのような場合決定言者は参加者が異なる点について議論し、自分の見解を説明できるような文章を事前に設定することで期待されます。
参加者がこれを怠るとオブザーバーとしての参加は別として決定会議に参加することができなくなります。
15:00
これにより全ての参加者に情報が提供され、そのテーマに対するコミットメントが表示されることになります。
これもこれでそうだなって感じですね。
続いてアーギュメンツですね。いわゆる論考とか考えていることですね。
建設的な議論、集団的な経験、選択肢の探求というのは実りある確かな意思決定の根源であります。その意味で全ての議論は次のようなものでなければなりません。
3つですね。
1つ目、礼儀正しい表現で述べられること。
2つ目、技術的な事実で主張をサポートする。
3つ目、それを解決するための変更基準を盛り込む。
はぁはぁはぁ、なるほどですね。
これがアーギュメンツと言われるものでした。
これもその通りだなって気はしますね。
ただ、そろそろ情報量が多くて、結局意思決定するためにめちゃめちゃいろんなものを考えたり、準備したりしなきゃいけないんじゃないかっていう気はしますけど、
大事なことなので、これを怠ったら結局、なぁなぁだったり、後でいろんなことが起きたときにこれどうだっけ、あぁだっけって立ち返るものがなくなるので、
最初はやっぱりですね、どんなものごともスタートが肝心なので、スタートでしっかりこの辺、時間をかけていろいろ準備して明記しておくっていうのがすごく大事なことだなって今、ちょっと余談ですけど思いました。
はい、スタートダッシュはもちろん大事ではあるんですよね。
走りながら何かを決めていったり、ブラッシュアップするってももちろん大事ではあるんですけど、そのダッシュをするための準備をするっていうのはやっぱり僕は大事だと思うので、
そこのバランスがむずいですよね。どこまで準備するか、いじゅんしすぎにしすぎて、スタートが遅いってなる可能性ももちろんあるんですけど、できる限り準備段階ではちゃんと時間を使いたいなっていうのは思いますね。
はい、では続いて、The Decision Making Processですね。はい、意思決定のプロセスだということです。
意思決定プロセスは、いわゆる一定の構造に従っていて、最大限の透明性というのを目指していますと。
はい、これもリスト形式でバーッと書かれてますね。はい、1、2、3、4、5、6、7、8個ですね。いきたいと思います。はい、じゃあいきますね。意思決定プロセスですけど、1つ目、すべての議論は誰にでも見える形で収集されます。
2つ目、可能であれば本当に重要な議論はすでに準備文書で特定しておいて、残りの議論は個別にリストアップしておきます。
3つ目、すべてのコメント、フィードバックに対応する。4つ目、可能であればグループでほぼ全員一致の決定を下す。これは幸せな道ですよね。
まあそうなるとはなかなか難しいと思いますけど。5つ目、3から4の大きな選択肢に焦点を当てます。
最終的には決定権者が決定しなければなりませんけど、これらの選択肢に関して自分の決定を説明しなければなりません。
注意書きとして、意思決定者は多数決に縛られることはありません。しかし多数決に逆らった場合の結果を認識し責任を取る必要ももちろんあります。
7個目、決定は常にアクションポイントに結びつかなければなりません。Aを決めたので来週はB、C、Dを実行しようみたいなことですね。
ラスト8個目、決定はやっぱり文書化されます。決定オーナーはこれに責任を持ちましょうというところでした。
18:03
これがディシジョンメイキングプロセスだと。結局ここに従う感じですね。それぞれの項目について改造度を上げているのがこの記事かなって感じがしますね。
はいじゃあ続いてリビジティングディシジョンですね。決定事項の再確認ですね。意思決定の再検討とは、古い意思決定に優先して新しい意思決定を行うことにほかなりません。
もし誰かが決定を見直す必要があると判断した場合は、元の決定の所有者またはプロジェクトリーダーに連絡する必要があります。
これはその通りだなって感じですね。では続いてコードオブコンタクトですね。コードオブコンタクト、これ行動規範って訳されるのか。
ミーティングオーナーはミーティング中に尊敬に満ちた有効的で生産的な雰囲気を維持する特別な責任を負っていますか?
そうなんや尊敬に満ちないといけないんですか。これ結構難しい。それはなくてもあくまで有効的で生産的な雰囲気を維持するってのはすごく大事だと思いますね。
これは参加者全員の仕事でもあります。参加者側にもそれを求めると。
会議中に必要であればこのことについて意識を高める責任というのが全員にあります。例えば物事が緊迫してきた時にお互いの話を聞き、妥協することの重要性を思い出させるなどですね。
確かにヒットアップした時にこういうことをするってなかなか難しいので、そういうふうに立ち返るというか一度落ち着くっていうところですね。
これを参加者もいわゆるミーティングとかの走りティーターも一緒にやっていかなきゃいけないなという感じがします。
やっぱり良い会議はみんなで作るというところですね。
でもこれ難しいんですよね。ヒットアップすると自分の考えをちゃんと通したいというか、これが正しいと思いがちになってしまうので、
ほんと他の人の意見とかでちゃんと聞かなきゃいけないとはつくづく感じました。
ラスト、じゃあコンクリチョン・結論ですね。
永続的な影響を与える判断をするのはすごく難しい。
多くの場合、複雑で深づく事実の要素があります。
ここで紹介するような構造化されたプロセスを用いることで、最適な人材が意思決定に協力し、本当に貢献することができます。
全ての決定が100%完璧であることを保証するものではありませんが、成功の可能性を高め、何よりも透明性を高めることができるのです。
これは一人や二人の人間が理由を共有することなく全てを決定するよりも、さらにずっと良いことなんですよということを結論を締められておりました。
はい、いかがだったでしょうか。
もちろんそうですね、全ての決定が100%完璧であるわけではないですけど、可能性とか精度とかっていうのをどんどんどんどん上げていくためにこういうものをやっていくのがいいんじゃないのという可能性ですね。
はい、成功の可能性というところを高めるためにはこういうものをやっていくのがいいというところでした。
まあなんかすごく共感も大きかったし、僕はその途中で見たそのテンプレートですね。
マクダムのテンプレート、僕はこれすごくいいなと思ったので、なんかこれを今後の、僕も結構その組織開発の話で仕事することが多いって冒頭に述べたんですけど、
その場の時にもこういうドキュメントを作って先に皆さんに聞いてみたりとか、ミーティングでこれどうしようかっていうのを決めていくっていうのをしっかりやっぱりやろうと、あれから始め、改めて思いました。
21:04
一応あれですね、アジェンダとか議事録のテンプレートは作ってるんですけど、そうではなくてちゃんと意思決定のためのドキュメントを作るっていうのは、ちょっと改めてハッとされた感じですね。
はい、とてもいい記事だったので皆さんもちょっと読んでみてください。ちなみにこの記事はですね、トリバゴのエンジニアの方々が多分書いてるっぽいですね。
3名で書いたらしいです。ソフトエンジニアの人とプリンシパルエンジニアの方ですね。
どっちかと言うと、サーチウェブインターフェイスをやってる人ですね。あとはフロントエンドエンジニアのリーダーの人ですね。
の3名で書いたというところでした。皆さん3人ともこのトリバゴの社員の人っぽいですね。ちゃんとツイッターとGitHubのリンクが貼られてますね。
トリバゴのエンジニアはGitHub使ってるんですね。はいはいはいはい。まあこういうの見るとやっぱり。
ソースコードとかリポジトリもなんか結構見れたりするので、まあトリバゴのソースコードが見れるわけではないでしょうけど、
そのあたりはFischer'sの方のリポジトリ、どんなものを書いてるのかって見れたりするので、この辺ちょっとまた参考に読んでみたいなと思いました。
じゃあ今日の朝活はここで終了したいと思います。結構記事としては短かったんですけど、気づいたらもう20分超えてきたので終了したいと思います。
では今日も一日頑張っていけたらなと思います。
Webではやっぱり表示されないんですけどもしかしたら。じゃあアプリか。アプリとか、あと僕のですね別のMacの端末で今朝活入ってるんですけど、
でもなんか閲覧もしかしたら他にしてる方がいらっしゃるとしたらですね、ごめんなさい。やけからずちょっと表示されなくてですね、これ何でかよくわかんないんですけど。
はい、参加していただいた方はありがとうございました。今日も一日頑張りましょう。ではお疲れ様です。
