nozayasu

仕事全般/マネージメントで考えたこと

トップ > LADR を組織で運用プロセスにするまでの話 part 1

LADR を組織で運用プロセスにするまでの話 part 1

What is LADR?

Lightweight Architecture Decision Records の頭文字をとって LADR

アーキテクチャの決定事項を、背景や協議内容と共に記録する手法です 最近は、色んな組織で取り入れられるようになってきましたね

現代におけるシステムは、コミットヒストリー、アプリケーションコード、テストコード等の管理状態によって、実態そのものをドキュメンテーションとして捉えることも可能になったと考えています

しかし、それはあくまで今この瞬間の実態について、自己ドキュメンテーション化されているだけであり、なぜこのアプローチを選択するに至ったのか？については多くを語ってはくれません

この課題に対して、実態の前提条件となる技術的な意思決定情報を残すことで、システム資産の過去と現在を繋げて理解するための手引き の役割を果たす、それが LADR の運用する意義だと僕は解釈しています

今回は、 LADR を自組織にフィットさせるためにどんなアクションしてきたのかを、言葉にしようと思います

LADR 自体のメリデメや、How の話は多いなぁと思っているのですが、どのようにプロセスを作っていったのか？の話はまだ少ないなと思い、誰かの役にたてばと筆をとります

Why LADR?

まずは LADR を調べ始めたきっかけについて

生産性向上をエンジニア組織としての１つの目標と置いている中で、「良いシステム資産を構成するものとは何だろうか？」と言う問いがあり、発散していく中で以下のような意見が出てきました

長く運用する前提を考えると
システム資産には積み重なってきた理由が存在している（はず）
なぜそれが、そう存在しているのか？
not only システム的な理由 but 事業上の制約もあるだろう
それを理解できる状態にあることが、良いシステム資産に繋がるのではないか

ここから、長く運用する（事業拡大を目指す）前提でのエンジニア組織の生産性向上には、自組織のシステム資産特性を説明可能にすることが良い影響を持つと仮説を作りました

仮説を設定したはいいものの、はてさてそれを実現するためにはどんな工夫をすれば良いのか？うまくイメージを固めきれない中で、一人のエンジニアが LADR という概念を紹介してくれました

一定のフォーマットに則って技術的意思決定を記録するプロセスを確立することで、自組織のシステム資産特性を説明可能に近づけることができる

この期待値を持てたことが決め手で、 LADR やろう！エンジニア組織の文化にしよう！本格的なアクションをする判断となりました

LADR を組織として運用するぞ！合意形成はできたわけですが、それだけでは前に進みません さぁ、一歩ずつ歩んでいきましょう

作る過程の話（フェーズ 1 ）

僕の現職であるツクルバには TechBoard というリードエンジニアによる組織体が存在しています、まずこのメンバーにて LADR というものを自組織で運用するために何をするべきか？トライアルを始めます

今までない文化を作っていくためには、着実に前進させることが何よりも大事だと考えていたため、コミュニケーションを進めるために、プロジェクトメンバーの役割と議論プロセスを最初にイメージしました

  1. オーナー役とフィードバック役という形に分ける
  2. オーナー役がプロジェクト進行とファシリテートを行う
  3. オーナー役はベースとなる思考や論点や指針を持論ベースでドキュメント化して事前共有
  4. フィードバック役は MTG までに読み込み事前コメントをいれる
  5. MTG ではコメントされた内容について議論を加えて合意形成と NextAction を作る場とする

これを前提に TechBoard での LADR トライアルがスタートしました

続いてはアクションしていった順に少しだらっとなりますが、思考過程を理解してもらう意味で文章を作って行きます

LADR 運用トライアルの全体像整理

何はともあれ、ゴール設定とそこへのチェックポイントがなくてはプロジェクトは始められません

  1. LADR 運用の合意形成
  2. LADR 作成フローの整備
  3. LADR 作成（一定数こなす）
  4. LADR 評価
  5. LADR プロセス振り返り

ざっくりでもやりたいことと順序イメージを共有するところから始めます、アクションしていく中でブラッシュアップしていくことで全体像を合意、LADR 自体はやろうと合意形成済みなので早速上記ステップにおける 2 の議論へと進んでいきます

LADR 作成フローの整備

ベースとなる思考や論点や指針の持ち込み

  1. 意思決定をしたい技術を GitHub issue として作成する / by all engineer
  2. TechBoard メンバーと起案者にて issue を協議 => 判断 / by tech board and issue author
  3. 採用・不採用に関わらず、協議内容を持って LADR を作成し issue を close / by issue author

フィードバック

  • 大きな違和感はないことメンバーから言葉をもらう（参加メンバーが違和感ないという事実をすり合わせたのが大事）

合意形成

  • GitHub に LADR 専用 repo を作成する
  • issue 管理と record 管理を兼ねる
  • 起案 ➡︎ 協議 ➡︎ 記録 のフェーズと担当者

LADR 自体を各々事前調査していた ので、全員のイメージが一定近しいものだったから、スムーズだったと振り返ります

LADR 作成

ベースとなる思考や論点や指針の持ち込み

GraphQL をテーマに issue を実際に事前作成してみた結果、手を動かしたことで人によってメリデメの書き方は多様になりそうだと実感（以下のようなのを書いていった中で筆が止まった）

1. ユーザーエクスペリエンスへの影響
    - 処理速度（表示/インストール etc）
    - UI/UX（アニメーション/レイアウト要件 etc）
2. デベロッパーエスクペリエンスへの影響
     - デリバリー
     - 開発効率（デリバリーと同義か？）

具体的には一定の基準となる情報や判断材料となる情報を決めないと、LADR の協議に持っていく情報精度が自己満足の範囲を超えていない、この時点で issue 作成の深掘りをやめ TechBoard に持ち込む

フィードバック

  • メリデメの書き方は決まっていたほうが書きやすいが、初期に決められるんだろうか？とは感じている
  • メリデメという括りというか、意思決定者が意思決定できるための材料となる情報が盛り込まれていればOKでは？
  • もし過不足あれば issue 上でやりとりもできるはず、まずは具体で進んでいこう
  • タイムスパンのグラデーションがある気がしている
    • 未来に対する技術的意思決定に対して、最低限検討したい項目
    • 直近に対する技術的意思決定に対して、最低限検討したい項目
    • LADR 導入に対する想いとして、未来に対する意思決定も含まれているのでそこを意識できるような運用にしたい

合意形成

  • 意思決定に必要な情報を LADR issue に盛り込むこと
  • ガチガチに決めずに、走りながら深掘りする

意思決定に必要な情報を LADR issue に盛り込む 、これが結果的に採用不採用の判断基準に繋がって行きました

運用上の懸念点を認識合わせ

次に、自分が運用するとしたら懸念に思うことは？というテーマで発散させ、それぞれに回答を作りながら前に進むことを決め、まずは問いをひたすら出していきました

  • 皆にやってもらうにあたって意思決定をしたい技術の基準がないよね、どんな基準で issue にする？
  • LADR があることによって、新規技術導入までタイムラグが生まれるのでは？（issue 化してすぐ協議できるとは限らない）
  • 評価するタイミングはどうする？
  • どの範囲、どのタイミングでLADRを書く？
    • 1 プロダクト導入するごとにLADRを書く？
    • 開発チームとして広く採用しようとしたタイミングで書く？
  • Apple 等プラットフォーマーが推奨する技術は採用しない選択肢が生まれにくいが、意思決定として残す？

これは 実際に運用するタイミングで自分たちが迷わなくなること、よくある疑問点への Q&A にもなること、二つの効果を発揮してくれます

洗い出した懸念点と、意思決定に必要な情報に答えを出すことで、LADR issue 作成が可能な状態になるとし、以降はそれを議論していきます

技術的な意思決定をするための情報を議論

Q1. 意思決定できるための材料となる情報にどんなことを求める？

  • 客観性と妥当性を判断したい、それをできるだけの情報を求める
  • 採用することで何を解決することを期待しているのか？
  • 課題に対する妥当性の観点での情報
  • 保守容易性の観点での情報

Q2. フォーマットで情報をある程度引き出せるようにする？やりとりで情報を引き出せるようにする？

  • 大きい観点でのフォーマット（保守容易性を判断できる情報だしてねとか）と、リファレンスとしてサンプルの何かがあれば、それを模倣してもらえるのではないか
  • 大きめのアンケートフォームみたいになるのは嫌だ

合意形成

  • 妥当性と客観性を判断基準とする
    • 妥当性を判断できるのは、起案者と同一専門職である
    • 客観性を判断するのは、起案者と異なる専門職とする
  • LADR issue テンプレートを作成する
    • 判断に必要な土台となる情報を引き出すため、指針となる項目を最低限記載する

フェーズ 1 の決定項

それなりの必要要素が集まってきたので、一度情報を収束させます

LADR 運用フロー α 版

  1. 意思決定をしたい技術を GitHub issue として作成する / by all engineer
  2. TechBoard メンバーと起案者にて issue を協議 => 判断 / by tech board and issue author
  3. 採用・不採用に関わらず、協議内容を持って LADR を作成し issue を close / by issue author
  4. 定期（Q毎、半期毎）で LADR 棚卸し（評価）する / by tech board and issue author

判断基準

  1. 取り扱う対象と専門性が同じメンバーによる妥当性判断をする
  2. 取り扱う対象と専門性の異なるメンバーによる客観性判断をする

上記2点の基準を持って、技術的意思決定をするものとする

LADR 管理

  • GitHub に LADR 専用 repo を作成、issue 管理と record 管理を兼ねて運用する

LADR issue テンプレートの詳細度

  • 判断に必要な土台となる情報を引き出すため、指針となる項目を記載する

Next Action

  1. 議論しきれていない運用上の懸念点について認識合わせ
  2. 1を完了させて、LADR issue 作成と issue 協議を実行フェーズに移行させる

終わりに

フェーズ 1 だけでも盛りだくさんで、全く書ききれませんでした！続きのコンテンツは以下のようなものです

  • 運用上の懸念点を潰していく話
  • OKR に LADR 関連指標を設定し、実行 = 評価にすることで初期の文化形成を動かした話
  • 個別 LADR の評価フェーズの話
  • LADR プロセス全体の振り返りの話

うぅ、part 3 くらいまでいきそうだが...、と一抹の不安を覚えますが今回はこの辺で

次回は、LADR の具体例もご紹介しつつ続きを話せればと思います

chao!!👋