LIGのくまこと久松です。
私はプロジェクトマネージャーやエンジニアリングマネージャーの他に、T&O(Talent&Organization)コンサルを実施しており、ITエンジニア採用支援に限らず、教育・研修も提供しています。
人材が流動化している現在、予算が青天井のようなエンジニア採用強者でない限り、経験者を採用することも難しくなりました。そうなると育てる方向に意思決定することが現実的となります。
エンジニア採用の難しさや、採用の際の心構えに関して以前記事を作りましたので、こちらもぜひ参考にしてください。 エンジニア採用が難しい3つの理由。成功のポイントや事例を紹介
くま
そして今回、エンジニア向けに研修をして欲しいというオーダーをいただきまして、研修を作成・実施してきました。
研修のゴール設定
今回実施させていただいたIT企業様についてまずヒアリングを実施させていただきました。
- メンバーリスト
- 学習履歴
- スキルセット
- 職務経歴書
- 評価
- 待遇
- 入社経路・入社理由
- （居る場合は）退職理由
- 社内の状況
- 事業内容・マネタイズ
- 意思決定のプロセス
- 部署間のパワーバランス
このような前提を確認させていただいたうえで、プロジェクトメンバーに、向かって欲しい方向性についてすり合わせをしました。
BizDev研修
今回のオーダーは当初エンジニアのリーダーシップ研修だったのですが、ビジネス部門と開発部門の隙間が気になったことから双方の部門を合わせてのBizDev研修というスタイルで実施しました。
ポイントになってくるのは双方の歩み寄りです。ビジネス部門は開発部門がどのような考え方をするかに興味を持ち、開発部門も同様にビジネス部門の考え方について興味を持つことがゴールです。
私が参考にしたのが『エンジニアがビジネスリーダーをめざすための10の法則』というベイカレント・コンサルティングの方々が書かれた本です。ビジネス側から見て、エンジニアの喋り方や振る舞いをどう直して欲しいかを、一冊丸々使って書かれている本です。自分自身耳が痛いことも多くありました。そのうち逆パターンのものを書いたりしたいですね。
実際に実施したBizDev研修
今回は2時間*2日間の合計4時間の研修を実施しました。今回のクライアントはフルリモートということでしたのでDiscordを利用しました。
まず、ビジネス側と開発側を混在させたグルーピングを実施しました。この際、役職をチーム内で揃えることで活発な議論が起きることを狙いました。
ざっとした流れは下記の通りです。
- 自己紹介
- アイスブレイク（ミニゲーム）
- リーダーシップとは何か
- KPT
- 意見の多様性とストローク
- 心理的安全性
- 1on1
- 働き方・働く目的の多様化
- BizとDevの狭間
- 計画変更
- 障害報告※1
- 仮説で語り切る
- まずヒアリング
- キャリアパスにおける本研修の意味付け*2
- フィードバック
最も好評だったワークは*1の障害報告ワークでした。ビジネス側と開発側が同じチームであることから、双方の視点から観点を出し合ってもらいます。そのうえで非エンジニアを想定した経営層に対して報告書を出してもらうというものです。
私自身、インフラエンジニアが長かったので、それはそれはたくさんの障害報告をしてきました。障害対応をするためには、時系列で何が起きたのかを把握する必要があるのでそのまま報告しがちなのですが、非エンジニアから見ても嬉しいものではありません。具体的に報告して欲しい内容を中心に、「この内容で伝わるかどうか」を議論しながらまとめてもらいました。
研修を実施してみてわかったポイント
かねてよりビジネス側と開発側の間の意識の違い、というのは問題視されていました。どちらが悪いというものではなく、守備範囲の違いが問題だと考えています。
しかしここに来てリモートワークでの意思疎通が問題となっています。リモートワーク以前であれば顔を突き合わせての意思疎通や雑談もできたものの、要件のみをやりとりするチャットやビデオ会議では、予め指定されたアジェンダ以外は何も話されなくなってしまいました。
その結果起きるものが社内受託という現象です。同じ企業の社員であるにもビジネス側から開発は外部企業のように見え、開発側からビジネス側に意見の一つも言えず、やらされ感を覚えるというものです。
今回のBizDev研修はワークをふんだんに盛り込みました。今回のワークをキッカケに「普段離さない人と業務に対する考え方について話すことができた」というご意見をいただきました。
こうした悩みをお抱えの企業様につきましてもヒアリングから研修まで実施いたしますのでお気軽にお問い合わせください。
