00:03
はい、2月27日月曜日ですね。 時刻は朝9時9分になりました。
本日も一気に寝坊してしまって遅れてしまった感じです。 申し訳ないです。はいおはようございます。memeのkeethごとくわからずです。
では本日も朝活を始めていきたいとおもいます。 本日はですけど、昨日でステイトオブシェイセンス2022を読み終わった。
まあ見終わったので、今日何を読もうかなというので、ざっと記事を探せたんですけど、今日はちょっとチーム的な話ですかね。
記事を見つけたので、これをちょっと読もうかなと思っています。 タイトルにありますけれど、「リモートカールチャーにおける技術的意思決定とアライメント」という記事ですね。
これも英語の記事なので、ちょっとちょっと翻訳しながら読んでいきたいと思いますけど、意思決定のアライメント、いわゆるコツ的なところの話が書かれているそうですね。
技術的な意思決定をリモートのチームで行うことは意外と難しくて、それぞれのメンバーが違うタイムゾーンで仕事をしている場合とかもあると思うんですけど、
その場合の非同期のコミュニケーションが強いられることになって、より一層難しくなるよねと。
この記事でその問題に対応するためには、アーキテクチャの決定規律、ADRを導入することを進めていて、ADRとはそもそも何ぞやと。
ADRの種類とかそれらがどのようなメリットがあるかについてちょっと解説してくださるというような記事だそうですね。
記事自体は2020年の12月7日の記事なんですけど、ちょっと古いとはいえ、リモートワークが全世界でコロナが発生して、
みなさんリモートワークだーっていう中で、真っ先に書かれていた漢字の記事になりますので、これちょっと気になるので読んでいこうかなと思っています。
あらゆる規模のエンジニアリング組織が日々技術的な意思決定を行っています。多くの場合、これらの決定は比較的小規模なものですよと。
個々のエンジニアまたは小規模のチームが自分たちにとって最も意味のある方法で問題を解決するんですよ。
しかし、中にはより広範囲に影響を及ぼす意思決定もあって、そのような意思決定を把握するためのプロセスを持つことが重要です。
このような決定は変化するテクノロジーとビジネスの状況に対応して、スタックやツールチェーンがどのように進化しているかというよりより深いビジョンに貢献するものです。
これはリモート環境では難しいことですけど、というのも現場のエンジニアに有効なソーシャル化チャネルの多くっていうのは、チームが国内外に分散している場合には有効ではないからですと。
非同期コミュニケーションの世界では、包括的で円滑子に優しいコラボレーションだったり、意思決定、調整、文書化ですね、ドキュメンテーションのプロセスを構築することがこれまでにより重要です。
影響力のある技術変更に伴うドキュメンテーションのニーズと採用目標を満たす方法の一つがアーキテクチャ決定記録。
このADRを採用することは、広範囲に及ぶ技術的な決定について提案し、合意を得るためのプロセスを構築することを意味しています。
スティッチフィックスという会社では、3年以上にわたって独自のADRの実践を繰り返し、その過程で多くの記録を得ましたということです。
ADR、アーキテクチャディシジョンレコーズの略ですね。意思決定の記録ですと。
03:03
アーキテクチャの決定記録というのをドキュメンテーション作っているそうですね。
これ結構大事なことですよね。特にリモートワークにおける意思決定ってちゃんと残しておかないと対面よりより意味があるというか、効果が大きいんだろうなと思ってますので。
アーキテクチャの決定記録は確かに気になりますね。
というわけで早速本文に入ってきますけど、最初のお話はADRですね。
ADRって何?というところからです。
アーキテクチャ決定記録、ADRを最初に作成するとき、それは本質的にコミュニケーションツールであるということをまず知っておくと。
それは技術的に支持に関する調整を達成するために、会話を喚起するために使用される成果物であります。
ADRが完成すると、それは単に必要な技術的決定の何を、なぜ、どのようにのコンテキストを提示する記録となります。
ADRがこれらのテーマをどのように伝えるかについて、より明確に把握するために、まずその全体的な構造を探るところから始めましょう。
意思決定に関する何を、なぜ、どのようにというコンテキストを提供する記録というのがアーキテクチャ決定記録ですね。
はい、わかりました。
あくまでこれをベースにコミュニケーションをやっていくところが、このADRの本数なんですね。
あくまでコミュニケーションツールですよ、と。
そのためにそのコンテキストというのをそこに残しておくということですね。
はい、OKです。
続いては問題の説明またはコンテキストですね。
プログラムステートメントはコンテキストのところです。
ADRというのは、まず現在の問題を簡単に説明するところから始まります。
これは明確で簡潔な問題提起と同じくらいシンプルかもしれませんが、
歴史的な要素を取り入れたり、望ましい将来の状態、例えば建築の改善の中核となる大きな目標に向かって構築することなどを伝えたりすることもできます。
この序章というのは問題空間をフレーム化し、ADRの残りの部分の基礎を築きますと。
はぁはぁ、まずは根幹となるものですね。
根幹となるとはいえ、まずは序章的にコンテキストもしくは問題の説明をしていくというところからだそうですね。
でもなるべくシンプルに簡潔に説明するところが重要だと言っています。
そうですね、コンテキストがすごい長すぎるとその瞬間から読む気が伏せますからね。
とはいえでも知らないと、どこの上に乗っかった議論なのかというところがブレブレになった瞬間意味のない議論になるのでね。
はい、でもそれは必ず重要ですよね。
で、続いてヒストリーですね。
続いて歴史ですけど、ほとんどの組織っていうのはエンジニアリングの問題を解決するために仕事のやり方だったり、特定のツール支援だったり、あるいは祝福されたパターンのセットを採用してきた。
歴史的な解決策を振り返り、その長所と短所というのを認識し、その解決策を採用するための準備をすることがとても重要でありますということですね。
06:08
では続いてフューチャーステイトですね。将来の姿、青写真的なところですね。
このセクションではADRが完全に採用されたときの世界について説明します。
具体的に呼び出すことで、現在の技術的な解決策の実施方法であったり考え方と何が違うのかというところを理解することもできます。
はぁはぁはぁ。青写真と現状との差というか、ギャップというところをここで明確にしておくということですね。
青写真というのがADRを導入した後の世界がどうなっているかというところですよね。ここがポイントだと思いますけど。
それはそもそも何かどこまでイメージできるかっていうそのクリアな度合いにもよる気はしますけどね、この辺は。
まあそういう辺はやっていくうちにどんどんクリアになってくるとか、実際に描いたものって後で多分変わってくる可能性もあったりするので微調整はどんどんしていくと思いますけどね。
そういうサイクルを回していくということだと思います。
続いて、どのような代替案を検討したのかというお話ですね。
ADRを共有してフィードバックを求めると、他のエンジニアはあなたが描いたものからインスピレーションを得てその問題を解決する方法について独自のアイデアを持っている可能性があります。
彼らのフィードバックは文章を完成させる上で非常に役に当たりますが、時にはあなたがすでに強化し排除したものに関する提案を受けることもあります。
このセクションは自分の仕事を見せるために、これらの提案に事前に対処し、それらの代替案の利点と欠点というのを文章化して、なぜその代替案を選択したのかというのを説明するのが適しています。
なるほど。ADRは個人でどんどん書き連ねていったり、どんどん残していくってことなのかな?
チームの議論の場で決まったことを記録していく気もしますけど、
個人ですでに評価してそのアイデアを排除したってものを別の人が提案することももちろんあるってことは、
個人ベースからのボトムアップ的に議論を進めていくんですかね。
その上で最終的にチームとかみんなで集まって議論を進めて意思決定をするっていうことなんですかね。
ちょっとやってないけど、そんな風に読んでて聞こえました。
他の人がこういう意思決定したりとか、他の人がこういう風な評価をして排除したみたいとか、
もしくはアグリーだったり採用したみたいなところの意思決定っていうのを全部書いておくことで、
自分がこういう仕事をしたとか、自分はこういう考えをしたんだよっていうところを残していくってことですね。
そんな色んな議論を重ねた上で、意思決定、ディシジョンのところですね。
決定事項ですけど、ADRの決定セクションに入ると、大体は伸び出しで提起された問題を解決するものになります。
これは検討中の問題に対する最も適切な解決策として著者が決定したことを明確に記述したものですと。
これ決定したものをとにかく書いていくってことですね。
これでもそれを読む限りだと、各個人が持ってきたアイデアだったり、こういうことを意思決定した決定事項だよっていう風に書き連ねをそうですけど、
09:06
チームで議論したことも一緒に書き連ねでいくんでしょうねっていう気がしました。
続いて、サンプルコードですね。
サンプルコードですけど、ADRはその組織のコードベース全体にエミュレートされた既存の作業を反映する必要があるので、
サンプルコードを提供したり、プロジェクトのリポジトリにあるファイルの差分へのリンクを貼ったりすると役に立ちます。
このような生きたコード例を示すことは、コードを読むことによって、最もよく学ぶ人々にとってあなたの解決策を明確にするのに役立ちます。
それはそう。あくまでアーキテクチャー決定なので、決定した時の理由だったり背景だったりとかのいろんなことをソースコードのサンプルであったりとか、
青写真のソースコードとかがもしあるんだったら、それを貼っておくにこしたことはないですよね。
僕ら的にはイメージ、ああこういうことねっていうのはすぐ理解できると思うので。
必要なドキュメントだったり、必要なリソースへのリンクを貼るというのはよくある話なので、
これは確かにちゃんと明確に書いてあるというのは良い話だなと思いましたね。
続いて、結果、フォローアップ、そして推奨または要求される行動というところのセクションですね。
最後にADRでは他のエンジニアに何を期待するのかというのを明確にします。
彼らはその決定を反映させるためにアプリケーションの変更を開始する必要があるでしょうか。
作業方法やツールチェーンを変更する必要があるでしょうか。
どうすれば始められるのでしょうか。
要するにADRの要件を満たすためにチームは何をする必要があるのかというのを続いて書いていくということですね。
はいはい、わかりました。
いろんなセクションを割って、最後、ADRの種類とその目的ですね。
すべてのADRが同じ目的を持ち同じ重みを持つわけではもちろんないです。
ADRには様々な種類があって、ここからそのいくつかの紹介をしたいと思いますけど、
ベストプラクティスADRと、はいはい、複数個あるんですけど、
ADRの中には広く採用されることを意図したベストプラクティスを反映しているというものもあります。
これはサービス設計の側面だったり、観測可能性だったり、
または追跡ツールを統合する標準的な方法だったり、
またはAPIプロトコルの詳細なガイダンスを含むかもしれません。
具体的な実践が何であれ、この種のADRの目標というのは、
設計と実行の一貫性を高め、エンジニアリングチームが生成するコードの一貫性と品質を向上させることです。
というので、一つ目はそのベストプラクティスADRというものでした。
広く採用されることを意図した、ベストプラクティスというものをどんどん反映したADRというのがその一つ目です。
二つ目には、ノーベルアートADRですね。
斬新なアートADRだと。アートというワードを出してくるの面白いですね。
こちらですけど、とあるチームが難しい問題に対して非常にエレガントでユニークなアプローチに到達することというのがあります。
その仕事が他のチームにも役立つと感じたら、斬新な芸術、ノーベルアートというのを
そのドキュメントとしてADRを通じて、その解決策を社会化したいと思うかもしれません。
12:00
ノーベルアートというのは、これまでにないオリジナルの行動やその他の成果物を指します。
なるほどね、そういうとてもユニークなかつエレガント、今まで聞いたことないようなものっていうところをADRにするっていうノーベルアートっていうものがあるそうですね。
この種のADRというのは、特定の課題を解決するのに有効であることが証明されている新しい方法というのを
想像的な方法で生産現場で紹介するようなものになります。
逆に言うと、より広範囲に適応できるようなものとして紹介したいところであるんですけど、
でも蓋を開くと意外とニッチなところにしか刺さらないみたいな感じも見受けられますけどね。
それどこまで一般化するかっていうところが技術だったりする可能性はありますけどね。
このノーベルアートっていうのは、エンジニアが同じ問題を異なる方法で2度解決することがないようにすることで、生産性を向上させることができます。
要は一般化ですよね。
では続いて、紹介は次で最後ですね。3つ目のADRはディレクティブADRと呼ばれるものですね。
ADRの中にはテクノロジーリーダーシップからの組織全体の指示を伝えるというものもあります。
例えば新しいフレームワークの採用、新しい言語の採用、基本的なインフラの変更などなどというところですね。
このようなADRはそれを読んだ人々がADRへの準拠が任意ではないことを理解できるように明確にラベル付けする必要がありますよと。
こっちの方がよりエンジニア組織に沿ったようなものに聞こえますね。直接的だからかもしれないですけど。
テクノロジーのリーダーシップから組織全体指示を伝えるようなADRですね。
今の弊社で言うとテックリード的な人たちとかCTOとかがそういう意思決定をしていってどんどん広めていくという感じかな。
次でフィードバックの収集と賛同の獲得というお話です。
ADRの著者っていうのは執筆プロセスのいくつかの時点でADRに関するフィードバックを求めるべきですよと。
リモートエンジニアっていうのは非同期通信を好むので、レビューとフィードバックのプロセスを設計するときはそのことを念頭に置いてください。
これはそうだよね。基本的にはリモートワークでやってるからエンジニア関係なく基本的に非同期通信でお話をしますけど、エンジニアは特に非同期のコミュニケーションを好む傾向にあるっていうのは確かにそうかもしれない。
なのでレビューとフィードバックをもし考えるのであれば、そこを念頭に置いたコミュニケーションの仕方っていうのを考えてレビューとフィードバックっていうのを求めるっていうのがいい話ですね。
続いて、フィードバックフロムサブジェクトマターエクスパートなど、とりあえず専門家によるフィードバックですね。
あなたの組織にはADRの主題領域について特別な専門知識を持つ人がいるかもしれません。このような専門家に提案する文書の趣旨とアウトラインというのを伝えて早期にフィードバックを得ることもできますよ。
ADRについての専門家というより、結局はアーキテクトと言われるエンジニアなのか、フルスタックエンジニアかわかんないですけど、というような人たちですよね。
続いてチーム間のフィードバックですね。最初のドラフトというのが完成したら自由にチームと共有してください。
ADRの最終フォーム、いわゆるADRリポジトリとして使用しているものとは別の設定で行うと良いでしょう。
15:03
Googleとかドロップボックスのペーパーで共有ドキュメントを作成すると便利かもしれません。
どのように公開するにしても、チームメイトがその文章にコメントを残せるようにはしておいてくださいねということですね。
続いては小人数でのディスカッションです。
大人数の会議では発言しづらい人も含めて、全員がADRについて質問や意見を述べることができるように、シニアエンジニアが進行役を務める、小人数制のディスカッションを行っていきます。
参加者は事前にADR案を読んで、ファシリティエーターが全員の感想や意見を流します。
ファシリティエーターは提案された、定期された懸念であったり対処すべき質問を記録する役割を担っています。
そして、これらの質問や概念をより広い公開の場でのADRの議論の場に持ち込むんですよということですね。
記録する人はファシリティエーターじゃなくてもいいんじゃないかなと思いましたね。
記録しつつファシリティエーターを務めつつ、みんなの議論を聞いて理解するって結構大変だと思うので、記録だけは別の人の方がいいんじゃないかなと思ったりしました。
続いてエンジニアリング全体へのプレゼンテーションフィードバック及び調整です。
ADRっていうのがこれらの予備的なレビュープロセスを通過したら、今度はより広いエンジニアリングチームからフィードバックを求めます。
ステージフィックスっていう会社では、フォワード・ザ・ファウンデーションと呼んでいます。
エンジニア組織全体に開かれた月例の全員参加型リモートミーティングがあって、これを通じて行うそうですね。
このミーティングでは、プロセスの仕組みに関する背景情報を含むアジェンダを作成し、ミーティングの2週間前にADRを検討するためのアジェンダを追加します。
一度に審議されたADRは2件以下になるようにしています。
なるべく少ないものを皆さんで議論しようと。
このミーティングでは、プロセスの仕組みに関する背景情報を含む、ミーティングが始まると、それぞれのADRに15から20分ほど時間を割きます。
著者はどんな問題を解決するのか、そのADRがどのような解決策を提案しているのか、など大まかな内容を簡単に話します。
そしてディスカッションに入ります。まず小グループのファシリテーターに話し合いで出てきたことを話してもらい、他の参加者からフィードバックを求めます。
このようなミーティングの主な目標の一つというのは、提示されたADRに関するフィードバックと整合性を得ることです。
採用の決定はおそらく適切なレベルのシニアエンジニアリングリーダーの責任となるため、提案された変更または革新の範囲、関連コストまたは規模に基づいて、このミーティングの範囲外である可能性とかも加味しつつ意思決定すると。
そのちゃんと範囲外であるというスコープ概念ある可能性もあるよということを念頭に置いてくださいとですね。
しかしそのフォワード・ザ・ファウンデーションでのアライメントの議論に対応して、必要に応じてADRを改定し、さらに再検討することというのが重要であると考えます。
ADRというのは会議の参加者による投票の対象にはなりませんけど、採用を成功させるためには問題提起と提案された解決策の両方について全般的に一致することがとても重要です。
ここでのキーワードはアライメントです。エンジニアの組織が大きくなるにつれ、合意形成が困難になったり不可能になったりすることも要はありますと。
18:06
私たちはADRのプレゼンテーションとそれに続くディスカッションを基本的な前提に意義を唱えるのではなく、
細部を練り上げ影響を理解するためのプロセスとして捉えることをお勧めします。
この辺はもう普通、一般的な会議とかミーティングと一緒のようなお話をしている気がしますね。
どんな仕組みだったりフレームワークとかテクニックであろうと、本質的なコミュニケーションの場というところでは一緒なのかもしれないですね。
続いて、アフターアプローバーなので、承認後ですね。
ADRが提示され、承認されましたら、検索可能で一元化され、簡単にアクセスできる場所に見つける必要がありますと。
エンジニアリングウィキにセクションを追加したりとか、GitHubに専用のリポジトリを作ったりとか、
全てのADRを簡単に検索できるGoogleドライブフォルダをセットアップすると良いでしょう。
これはそうですよね。
なるべくみんなが簡単にアクセスできるようなところに置く、数見えるところに置くというのはとても重要なことですね。
続いて、プロセスの促進ですね。
ファシリティングユーザープロセスですね。
リモート組織にADRを導入するためには、エンジニアが技術的な洞察と決定を共有する習慣を身につけるために、
進行役を務める人が必要になるかもしれません。
この人物は組織全体のチームと繋がり、他のエンジニアグループが取り組んでいることを把握できることが理想的です。
ADR採用のフィードバック収集とプレゼンテーションの段階というのは、できる限りスムーズで摩擦のないものにするようにしましょうと。
必要であれば、プロセスを書き出し、ADRリポジトリのReadMeまたはHowToセクションに追加してください。
最後に、ADRの社会化及びレビューミーティングを定期的に開設するように設定します。
人は往々にして期限があるとやる気になるものです。
ですから期限を明確にしましょう。
これは本当その通りですね。
なんだかんだ人は締め切り駆動だったりします。
続いて、成長するチームへの影響。
インパクト・オン・グローゼイング・チームズですね。
ADRを効果的に実施する主なメリットの一つというのは、サイロ化した組織の知識ですね。
知見というものを開放して普及させることが大きな点ですよと。
そりゃそうだよね。
エンジニア組織が大きくなるにつれ、どんなに社交的な開発者であっても、
エンジニア全体の少ない割合の人しか関係を築けたくなります。
つまりチームの垣根を超えてコミュニケーションを取ることが難しくなってくるのです。
これは本当そうです。
今の弊社もそのとおりになりつつあるなという感じですね。
ADRはチーム間のコラボレーションを促進する上で重要な役割を果たすことができます。
複数のエンジニアやエンジニアチームが自分のチームが抱えている問題と同じように、
同じような問題に直面することがよくありますし、
組織全体として重要な技術的検討事項について方向性を決める必要がある場合もあります。
ADRの技術的な側面についてチーム間でコラボレーションすることは、
チーム間でアイデアを出し合うための素晴らしい方法になります。
ADRのリポジトリだったりウィキっていうのは、特にリモートカルチャーにおいて、
新しいエンジニアをオンボーディングするための貴重なツールでもあります。
これもまさにそうなんですよね。
ちゃんと残しておいたりしけての理由だったり、そのリモートのカルチャーですね。
カルチャー自体をちゃんと言語化してあるっていうのは、
新しく入ってくる人たちのオンボーディングにものすごく大事なものだったりしますよね。
21:01
ADRを組織で活用するためにというところでラストですけど、
責任あるイノベーションのためのフレームワークについての記事を読んでいただければ、
ADRが技術ソリューションと実践の進化においていかに重要なステップとなり得るかがお分かりいただけると思います。
ADRは成功した実験から生まれた技術革新の社会化を支援し、
組織全体のエンジニアを開放し刺激してくれますよと。
ADRを確立することでエンジニアは組織全体のアーキテクチャの原則と価値観に一致する方法で、
より自信を持ってビジネス価値というのを提供できるようになりますよと、
言葉で締められておりました。
はい、ちょっとADR自体が、一応説明はいろいろされましたけど、
ふわっとしている感じはまだまだあるので、
具体的なADRいくつか調べて、こういう方法なんだなっていうのを見ることによって、
よりクリアになっていくと思うし、導入していきたいと思いますけど、
個人的には、この記事全体としておっしゃられている、
フィロソフィーだったりとか思想観点っていうのはものすごく共感が強くてですね、
後半がそうそうと本当にずっと思いながら読んでました。
これかなり良かったので、やっぱりエンジニアなら一度は読んでほしい記事だなと正直思いましたね。
かつ、あれですね、月一のみんなが集まる場でADRの提案をするとか、
そこでの議論を促すっていうのは、これは面白いですね。
月一の場、うちでいうと全社会みたいなのがあるんですけど、
そこで議論する、コミュニケーションを取るっていう場を設けさせてもらうっていうのは、
なかなか面白いと思いましたね。
でもそういう場がなかなかないんであれば、でもみんなに影響のあるものっていうか、
組織的な意思決定をするっていう考えでいくと、
その場は確かに当たり前ですけど、使うべきだよなっていうのを思ったりはしますし、
そういうところで広く意見を求めるのはいいかもしれないですが、
えてして、ちょっと主語大きいけど、日本人はそういう場で意見を言わなかったりする。
他の人がいたら自分の意見を引っ込めるみたいな悪臭があると思うんで、
なかなか難しいところですよね。
というので、やっぱりアンケート的に匿名性で書いてっていうふうに
指示を出すほうがいいかもしれないですけど、
とはいえ、とにかく広く意見を求めるっていうのがとても重要ではあるので、
これは確かにやったほうがいいなと思いましたね。
はい、いかがだったでしょうか。
すごく参考になりましたし、
これいきなりドーンと導入することは難しいですけど、
なんか要素的なものを取り入れつつ、やっぱりその意思決定ですよね。
アーキテクチャーって書いて、ADRはアーキテクチャーディシジョンリコースなんですけど、
アーキテクチャー以外の意思決定ですね。
いろんな意思決定、技術的なところの意思決定、
何かをやったこと、何かを選択したことっていうのがこの記事にありましたけど、
何をしなかった、採用しなかったっていう意思決定もしっかり書き残しておくって
すごく重要なことなので、この辺は残しておくことで、
その理由だったり背景っていうのは他のチームとか、
他の開発現場でも大いに活用できる、大いにあり得ると思うので、
この辺はやっぱりやっていきたいなというふうに感じましたね。
はい、ということで、じゃあ今日の朝活は以上にしたいと思います。
時間もちょっと30分超えましたので。
はい、今日はですね、レノアさんですね、ご参加いただきありがとうございました。
また明日も何か有力読んでいきますので、興味ある方は参加してみてください。
ではまた今日から1週間ですね、頑張っていけたらと思います。
24:01
そして、今日は明日でまたもう2月が終わってしまいますので、
早いですね、3月締めの会社さんも結構あると思うので、
皆さん今日からまた2月しっかり締めていただければなと思います。
では終了したいと思います。お疲れ様でした。
