エンジニアリング・イネーブルメント
新人の参画や異動など、育成のタイミングが複数重なったので、メンバーそれぞれに今必要なノウハウを伝えられるように、体系立てる必要がありました。
これまでは必要そうなコンテンツを事前に準備しておき、OJTをベースにしてメンバーのスキルに合わせて、つど必要なトレーニングを組み合わせて進めてきましたが、複数人同時に、別のスタート地点から、別の役割を目指す育成には不向きです。
成果を軸にトレーニングを整理するセールス・イネーブルメントのアプローチをソフトウェア開発に適用して、メンバーそれぞれに今必要なノウハウを伝えられる状況を整えてみました。
■セールス・イネーブルメントとは
組織としての成果を出す営業社員を輩出し続ける人材育成の仕組み
●一般的な人材育成の現状
・トレーニングはやりました
が、一般的過ぎて活かせない
・OJT任せ
・成果が出ない
●育成が成果につながらない本質的な課題
・ミクロ視点
トレーニングと現場が乖離
・マクロ視点
部門間で個別最適化
・結果
これって何でやってるんでしたっけ？
やった後どうなるんでしたっけ？
●あるべき人材開発サイクル
組織として求める成果
-> 必要な行動
-> 必要な知識/スキル
-> 育成施策で知識/スキルを得る
-> 知識/スキルを活用して、行動が変わる
-> 行動が変わり、求めていた成果を達成
※Sales Enablementの体系的理解と構築の進め方 から引用
●成果起点の育成PDCAサイクルを回す
・成果・行動・知識/スキル を一気通貫でつなげる
・顧客の意思決定プロセスに営業プロセスを整合させる
・顧客の意思決定プロセスを前進させる育成プログラムを組む
※https://prtimes.jp/main/html/rd/p/000000257.000011466.html から引用
●成果が出るまでのステップ
・学習する
・学んだことを実践する・適用してみる
・効率的に動くために、学習の仕方や実践の仕方を発展させる
●セールス・イネーブルメントの構成要素
・知ることを支えるトレーニングコンテンツ
・やってみることを支えるコーチング
・効率的に動くためにすぐに使えるツール/ナレッジ
・データドリブンな活動を支えるシステム
※https://www.biz-knowledge.com/entry/sales-enablement から引用
■全体像
●適用したチームの役割
業務システムを開発する部署の中で、各システムのメンバーがDevOpsな思想に進んでいくことを支援、伴走するチームです。チームの顧客は業務システムを開発、運用するメンバー。複数の組織を支援し、それぞれに複数のプロダクトを提供しています。プロダクトの開発 / 運用以外に、PR、カスタマーサクセス、カスタマーサポート、開発プロセス全般の支援も担います。メンバーは社員と協力会社の混成で、私は協力会社としての立ち位置で参画しています。
●適用したチームのプロセス
チームをプロダクトに見立てたインセプションデッキで活動方針を整理しています。星取表でプロダクトに関わるスキルを棚卸しています。支援の施策は仮説として扱い、仮説 / MVPキャンバスを描いて、BMLループで検証を回しています。プロセスフレームワークは、DAD アドバンスド / リーンライフサイクルで、イテレーション期間は1週間です。
●全体像
■成果起点の育成PDCAサイクル
●成果・行動・知識/スキル を一気通貫でつなげる
成果
インセプションデッキのわれわれはなぜここにいるのかをミッションと捉え、計測可能なKGIを設定します。このチームでは支援先の「デリバリーパフォーマンス」と「DevOpsに関わるケイパビリティのアセスメント結果」からKGIを設定しました。
行動
VSMやサービスブループリントを描いて、担っている役割を通した価値提供プロセスを整理します。プロセスを数値化してKPIツリーにすれば、CSFの特定にも利用できますが、現状はKPIツリー化は未実施です。
知識/スキル
価値提供プロセスに必要な知識/スキルを、星取表に整理します。知識/スキルは、役割とプロセスで分類します。
・インセプションデッキ / われわれはなぜここにいるのか
業務システムの価値提供を、より楽で安全に、より早く多くする
・デリバリーパフォーマンス
・DevOpsに関わるケイパビリティのアセスメント：DevOpsCriteria
・担っている役割
・星取表
●支援先の意思決定プロセスに支援プロセスを整合させる
実施した施策から計測したデータとヒアリング結果を検証し、得た学びから、より効率的に支援するための仮説を検討します。
●支援先の意思決定プロセスを前進させる育成プログラムを組む
部署のルールや、ヒトの関係性で意思決定プロセスが異なるので、担当者との対話から見えてきた事情に合わせて、進め方を検討します。
見えてきた支援先の共通の事情と、うまく行った進め方は、型としてチームに共有します。
見えてきた支援先の個別の事情と、うまくいった進め方、得た学びは、他の人と共有するためにパターン・ランゲージなどで整理しておくと良さそうですが、現在は未実施です。
■イネーブルメントの構成要素
●知ることを支えるトレーニングコンテンツ
星取表に整理した知識/スキルごとに、参考資料を用意
説明資料や記事、スライド、書籍などを紐付けています。学習は計画に含めて、他のタスクと同列として扱っています。学習した結果はLTとして発表し、その場でフィードバックを得ます。
星取表の入力値で習熟度を表現
△ / ○ / ◎ではなく、興味なし / 興味あり / 助けがあれば遂行できる / 独力で遂行できる / 他者に教えられる で、興味と習熟度を表現できるようにしています。
役割、プロセスごとに集計して、習熟度を可視化
個人、チームでの強み弱みを把握して、それぞれに目標値を設定します。目標値との比較で、でトレーニングがうまくいったのかを判断します。
・習熟度の可視化（開発・運用領域）
●やってみることを支えるWhyの共有
はじめて担う役割のタスクは必ずモブワーク
担う役割のすべてのプロセスを経験できるタスクを選んで実施します。文化、ルール、考え方、コツの共有、関係づくりなどもありますが、実作業の中で、チームのWhyをどう判断基準に取り入れるかの共有が一番の目的です。
タスクを始めるときは目的と完了条件を揃える
どんな作業だとしても作業時間で一番割合が多くなるのは判断する時間です。判断に迷ったときの拠り所を事前に合意しておき、それでも判断が難しい場合は、すぐに会話することにしています。
あらゆる場面でチームのWhyを拠り所にする
参画時の説明、朝会 / ふりかえり などのセレモニー、タスク開始時、課題の相談中など、事あるごとにチームのWhyを判断基準として利用しています。Whyを考えることを当たり前にすることで、メンバーの誰でも「次は何をするべきか？」に自分で答えを出せる状況を目指しています。
●効率的に動くためにすぐに使えるツール/ナレッジ
モブワークの終了時に学びを書き出す
後で参照できるように、モブワーク中に共有されたノウハウの内、メンバー共通で活用できるものに絞って、タスクに書き残しています。
個人タスクの完了時に経緯を書き出す
再利用できるか見通せないものを、ノウハウに汎化する時間をとることは難しいので、時系列で実施したことをタスクに書き残しています。
再現性のあるノウハウを整理する
スプリントごとのふりかえりで、参考になった情報からナレッジをまとめるTryを挙げます。Try実施時に、価値提供のプロセスとナレッジを紐付けて整理して、必要なときに参照できるようにします。すぐに使えるノウハウを整理するのではなく、すぐに使えたノウハウをナレッジとして残していくイメージです。
・すぐに使えたノウハウをナレッジとして残す
●データドリブンな活動を支えるシステム
指標を計測する
・成果
計測可能なKGIとして決めた値
・活動
プロセスを支える各システムのデータ
タスク管理、VCS、CI、CDなど
・知識/スキル
星取表の習熟度、更新状況
ナレッジの活動網羅率
成果を上げるための施策を練る
成果、活動、知識/スキルのデータをつなげて見ることで、KGIの達成状況、成果を上げるために活動、知識/スキルをどうするべきかを検討できるようになります。検討で挙がったカイゼン案をイネーブルメントの仮説として、次の検証サイクルを回していきます。
■まとめ
イネーブルメントのアプローチは、組織が求める成果が定義できれば、あらゆる職種に適用できます。成果を軸に一貫性を持たせられるので、網羅率や習熟度などのデータマネジメントにつなげることができます。ソフトウェアエンジニアの活動は、なんらかのシステムを利用するので、計測しやすい分、物理的な活動が主体の他の職種より導入が容易です。
職種をまたいだイネーブルメントのアプローチをこちらに整理しました。
いつも応援していただいている皆さん支えられています。