architecture のメリット
その時点でのチームや組織としてどうするか意思決定のためのガードレール。
何のためにこうしているのかは明示されていないといけないかつ、そのアーキテクチャに合うように意思決定が各人でできなければ意味がない。
メンバーの意思決定が組織やチームが意図するものと沿うようにする手助けをする。大枠意思決定の向きがあってれば、ソリューションもそこまでずれることはない。
チームトポロジーでもあったが、意思決定のためのコミュニケーションパスは少ないほうがいい。architecture の input をすることで意思決定がスムーズにできるようになっているのであれば十分なメリットになりうる。
意思決定がスムーズにできるのであれば、各人が素早くアウトプットを行って改善のサイクルを繰り返せるようになる。
挑戦できる環境づくり
挑戦できるということは ある程度 失敗が許容されていることだと考えられる。
ある程度が予想外に大きいものになってしまった場合がリスク。顧客の信用を失うときなど。
そのため、次の2点ができているのが好ましい
-
新しいことをやるときの影響範囲を選択できる
- フィーチャーフラグで一部にしかまず見せない
- A/B テストで不確実性を減らす
-
失敗をしてもリカバリ(ロールバック)ができる
- 不可逆な挑戦にならないようにする
- 例えば、データの巻き戻し機能など
数値で語る
数値は共通言語。すべてを計測できるようにして、残す。そしてまた数値をとって改善する。
日報を書く
-
何を決めたか
- どうして必要になったか
- 何に取り組んだか
意思決定やコミュニケーションの記録を残すことで後進の役に立つかもしれないし、現在のメンバーからリアルタイムでリアクションが来てフィードバックがもらえるかもしれない。
事業
ユーザが起こすイベントを抽出する
イベントを起こす主体はユーザー(人)とは限らない
BPMN ビジネスプロセスモデリングなどで図を書いたり、簡易的な状態遷移図を書く
KPI モデルを作り、重要項目についてダッシュボードを作る。その数値を日々見て、ダッシュボード自体も改善し続ける。
数値が見れることで、事業に沿った根拠のある意思決定の材料として使える。重要指標にフォーカスしていくことで目線がずれることはないし、改善できれば貢献の実感も得られる。
ダッシュボードの数値を包括的に知っておくことで、社長や上層部と同じ目線をみなが持てるようになる。