昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。
分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。
我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。
業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く戻せばよい。
Mackerel開発チームカイゼンの旅（振り返り・モブプロ・スキルマップなど） - Hatena Developer Blog
現代の Web アプリケーションを作るのに、「PdM、エンジニア、デザイナーの 3 人で作る」というのは難しくなっていて、そもそも 6 人とか 10 人とか 30 人とかのチームでやる場合が増えています。そうすると、変化を始めるのは勢いだけでも可能かもしれないけど、やりきるのは以前より難しくなっていませんか。
この問題を倒すのに、進め方を知っていると楽になるよね、というのが今日の主題です。
進め方 is 問題解決や意志決定、組織変革のプロセス。
例えば
- トヨタ生産方式の 5S
- 躾 が含まれている
- 問題解決の 8 ステップ
- 目標設定や計画、定着させることが含まれている
- ADR (Architecture Decision Records) や Design Doc
- 意志決定をテンプレ化し、記録を取っていく
- インセプションデッキ
- 前提を丁寧に揃える役に立つ
- DACI フレームワーク
- 意志決定に関わる人の役割を明示することで推進力を出す
- コッターの 8 段階プロセス
- 変革に当たっての 8 段階プロセス
- ADKAR モデル
- 同じく変革のための 5 段階プロセス
辺りを僕は意識しながらやっているかしら。
勢いだけでは導入することができない場合があり、そういうときはちゃんと変革をマネジメントしなければいけない、という意識で物事を進めていくと、導入できない・最後までやりきれない問題を倒しやすくなる。前提を丁寧に共有しようねとか、共有用のいいテンプレートがあるよとか、やりきるところまで含めて計画しようねとか。
横から細かい Cons を刺され続けて疲弊する場合に対しても、DACI フレームワークを使うと、「Informed ですよね？」と封じ込めることができて (というか、すべてに対応する必要は無い、Approver が判断できれば十分である、という意識に全員を持って行くことができて)、進めやすくなることもあるかもしれません。
定着までをゴールに見据えていると、外部登壇を経由して社内により効率的に広めるとか、意識を向けるための定例の場の設定とか、横展開のためにあらかじめ楔を打っておくとか、そういう動きをやっていくこともあります。
開発合宿のようなイベントを企画して、勢い MAX で乗り越えるという手段を執ることもありますね。
この話はどこに向かっているのか
- 変化が大変になっているという事実があることを認識する
- 進め方が世の中にあることを認識する
- 試しに使ってみて、馴染むものを普段使いする
というのをやっていけると、変化を起こしたり、浸透させたりするのが難しい問題に対応しやすくなる。
んだけど、その上で「丁寧に進めなければいけないことは分かっているがめんどくさい」は乗り越えられないので、こういうエンジニアのエンパワーメントを一緒にやってくれる人や、丁寧に進めなくても良いチームを一緒に作っていく人を強く募集しています。
まずはカジュアル面談からいかがでしょうか。
