成功したエンジニア組織施策とその裏にある導入背景
エンジニアブログや勉強会などでエンジニアの組織施策の成功事例を目にする機会があると思います。それらの施策の裏には漏れなくどろっどろの組織課題＝導入背景が存在します。
今回は一応成功したエンジニア組織の施策と、その裏にあった導入背景についてノウハウとしてまとめたいと思います。
社内エンジニア勉強会
[概要]
隔週水曜日の夕方(業務時間内)から社内向けの発表会を開催。参加は自由。登壇者は事前申し込み。オフィス内のプロジェクターでスライドを投影。
[導入背景]
プロダクト内に開発チームが複数あったのですが、チームを超えた情報の共有の機会が少なく成果の見える化が出来ていないという課題がありました。
また、技術に関する情報のアンテナが立っていない人も居て、特定のチームの技術がガラパゴス状態になっているのも散見されました。
あと、技術広報の観点から公開出来るネタがなかなか無かったこと、そもそも各メンバーが表舞台に立つという概念が無かったので、スライド作成や登壇の経験が無かったことも課題としてありました。
[導入した結果]
試行錯誤しながら5年以上継続することが出来、開発メンバーのほとんどが1回以上は登壇するような環境を作ることが出来ました。
また、エンジニアブログの執筆や社外勉強会に二の足を踏むメンバーに対して、登壇やそもそもの参加などについて心理的ハードルの低い手段を提供することにも繋がりました。
技術広報的にはエンジニアブログのネタにしたり、登壇資料をもとにしてメンバーが外部の勉強会への登壇に繋げる事もあり、結果としてはかなり上々だったと思います。
まぁ長く続くとその分マンネリ化は避けられないので適宜テコ入れをする必要はあります。。。
若手エンジニアキャリア相談ビアバッシュ
細かいことは過去ブログにしているので参照。ここではブログに書かなかったことを説明します。
[概要]
新卒1～2年目の若手と中堅エンジニアが参加し、自己紹介や今までやってきたプロジェクトについて全員がLTを実施。終わったらそのままキャリア相談という名の懇親会(飲み会)に突入。
[導入背景]
若手エンジニアが中長期のキャリアに悩んでいることが多く、マネジメント側(自分)からあれこれ助言しても決めあぐねる状況が見られました。自分のキャリアに関するイメージが薄いと短いスパンでの目標設計しか出来ないので、マネジメント側からしてみると評価が難しいことがありました。
原因として大きいのは参考にできる情報が圧倒的に少ない事なので、身近な人のナマのキャリア遍歴を効率良く情報収集する機会を作る方法を模索する中で社内イベントを開催することにしました。
[導入した結果]
中堅エンジニアのキャリア遍歴を沢山見ることで中長期のキャリアに対するイメージを持てたようで、その後の目標設定面談で幾らかスムーズに進めることが出来ました。
また、通常だと美談しか語られないキャリアについて、しくじった話を生々しく聞ける機会はなかなか無い経験だったようで、「あの人にも辛い時期があったんだなぁ、と感じて勇気が出た」というフィードバックもありました。
若手とベテランを組ませてランチや飲み会をするという企画はあるあるだと思うのですが、フォーマットを設けて効率的な情報共有をしたほうが良いと感じました。
少人数固定チーム化&リーダー廃止
細かいことは過去同じ内容で登壇したときのスライドがあるので参照。ここではスライドに書かなかったことを説明します。
[概要]
開発チームをコンテキスト毎に編成。1チームは3～4名。メンバーは基本固定。
技術責任者の技術導入などの責務とチームリーダーポジションを廃止。チーム内の合議制へ移行。プロダクトオーナーの配置。
[導入背景]
たくさんあるのですが、、、
まず開発要件に対して毎度プロジェクトを立ち上げてチーム編成を繰り返していたので運用フェーズに入った際の人員の確保が難しく、一人プロジェクトが横行して障害対応などのトラブルが多発していたこと。
次にチームリーダー(プロジェクトマネージャー)の力量によってプロジェクトの成果が大きく左右されてしまうこと、優秀なエンジニアがプロジェクトマネージャーの素質を必ずしも兼ね備えていないこと、リーダーになったエンジニアがコーディング出来なくなること。
最後に技術責任者やリーダーに課した責務によりメンバーが経験出来ない事が増え成長が阻害されてしまうこと、さらにいうとハイレイヤー人材の採用が厳しくピラミッド型組織だとスケールが難しいことがありました。
[導入した結果]
コンテキスト毎にチームをまとめたため開発～運用が安定し、特に障害対応に関するトラブルが格段に減りました。
チーム人数を減らすことによって実質のタスク量を抑えることが出来、タスクマネジメントを行っていたリーダー職を廃止、コーディングに費やせる時間を確保することが出来ました。
チーム内の合議制に移行したことで個々のメンバーの経験値が上がったため、意思決定スピードを向上させることにも繋がりました。
最終的に実施までは至らなかったですが、チームが持っているコンテキストによって開発タスクが偏る問題がありましたが、一つのコンテキストに対して複数チームを作ることで対応する予定でした。
戦略会議の議事録説明会
[概要]
週1で行っていた開発プロダクトの戦略を話し合う会議の議事録をメンバーに共有。後日議事録をプロジェクターで投影しながら説明し質問を受け付ける時間を設ける。
[導入背景]
戦略会議で決定した内容を開発タスクとして進める際、会議に出席しているメンバーと実際に開発をするメンバーの間の情報格差が問題になっていました。
例えば「開発優先度が変わって開発タスクがペンディングになった」「急にコスト削減のタスクが降ってきた」などです。
戦略会議で決定する内容は紆余曲折した末に決まる事が多く、また多くの場合複数回の会議に渡って話し合われて決定されることが多いのですが、決定事項だけ伝えると「短慮」と取られてしまうこともありました。
[導入した結果]
開発タスクが計画に移る際の背景の説明をする際に議事録を引用したりなどで比較的スムーズに事が運ぶようになりました。何より今話し合っている課題について議事録で確認しておくと将来の予測を立てられるので、「急に降ってきた」という印象は減らすことは出来たと思います。
もちろん説明を行っても全てのメンバーに納得して貰えたわけではないのですが、会議参加者と情報量を同じにすることで一定の理解と誠意は示せたのかなーと思います。なにより「やらされ仕事」はモチベーションが上がらないので。。。
最後に
さも自分一人で施策を練って実行したように書きましたが、原案はメンバーから提案してもらったものがほとんどです。
重要なのは組織の現状の課題をメンバーにオープンにすることで、組織全員で課題に向き合い、自由に提案できる環境を作ることなのかなと思います。
今回は成功した事例について書きましたが、失敗した事例のほうが数多くあるのでそれは別の記事にまとめたいと思います。
おわり