失敗したエンジニア組織施策としくじりの反省
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。
説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。
組織施策プレゼン大会
※元記事がお亡くなりになっているのでWayback Machineより
[概要]
組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。
内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。
[導入背景]
エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。
メンバーが組織の未来について考える機会を作り、従来のトップダウン・アプローチに対して今後ボトムアップを適宜取り入れるための布石として、社内にあった同様の提案会議フォーマットを踏襲する形で実施を行いました。
[導入した結果]
約1ヶ月の準備期間を経て、丸一日メンバー全員を集めてプレゼン大会を実施しましたが、採択された案は全体の2～3割で、その中からさらに実行まで漕ぎ着けられたのは2～3案でした。
プレゼンされた案に対して責任者の考えを全員に説明するというのは、目線を合わせる意図での効率は良いのですが、個々人が時間をかけて準備したものを全員の前で却下&批評されるというのは精神的ダメージの大きいことです。大多数のメンバーを傷つける結果になってしまったかなと思います。
施策として採択される＝点数を稼ぐためには一定規模以上の案を作る必要があり、日頃から感じている小さな課題はどうしても見送られがちになります。また、却下された案の再提案が心理的に難しくなるなど、施策提案に対する制限が出来てしまったのも失敗だったかなと思います。
案の実効性という部分で体制が大きなファクターになるのですが、提案者が責任者に立候補するなどの役割になってしまいがちで、立候補者の力量不足を理由として案を却下したり修正するのはとても心苦しいです。とはいえ、曖昧にも出来ないので全員の前で個人を傷つける結果になってしまったかなと思います。
提案会議フォーマット自体が普段からなかなか会えない、直接話ができないようなカリスマ性のある経営者が居て初めて成り立つようなものであり、高々数十名程度の組織ではあまり意味がないものでした。
結局、普段思いついたときに気軽に意見が言えるような組織体制を整えることや、責任者自らメンバーからの情報収集に動いて適宜メンバーにフィードバックしていくのが一番だったかなと思います。
エンジニアブログ
[概要]
はてなブログ(有料版)を利用。技術や組織に関する情報発信を行う。
投稿は内容含めて自由だが、複数人によるレビューを必須とする。
[導入背景]
社内の情報を発信する雰囲気が薄く、また実績を示せれていなかったので発信をしてもよいのかどうかすら分からない状況でした。
元々あるエンジニアブログ(WordPress?)の更新が完全に止まっていて、ブログに投稿をするためのフローも不鮮明でした。そもそもブログがあることすらあまり認識されていなかったと思います。
技術広報という側面でも情報の発信が無かったのでエンジニア組織の認知度が低く、採用において興味を持ってくれた候補者の方に提供できる情報が皆無でした。
エンジニアブログをCMSを使った上で投稿のためのフローを明確にする形で再稼働させました。
[導入した結果]
最初は目新しいこともあり順調でしたが、だんだん積極的に声掛けをしないと誰も書いてくれないようになってしまいました。ブログに書くほどのネタが無い、公式ブログという心理的なハードルが高いなどが断る理由として挙げられましたが、そもそもブログ執筆自体にあまり馴染みのない人が多かったのも要因かなと思います。
メディアとして大きくないこともありPV数も少ないのでせっかく書いてくれた人のモチベーション管理も難しいという問題もありました。
また、業務時間内でのイベント参加や経費使用のセミナー参加に対してブログ投稿を義務付けていたこともあり、レビューを厳密に行ってしまっていたので書いてくれる人達のやる気を更に削いでしまっていたと思います。
途中から方向性のテコ入れを行い、レビューを意図的にゆるくしたり、記事PV数に応じて投稿者の表彰・インセンティブ付与したりしましたが、大きく盛り返すことには繋がりませんでした。
最終的に新規の投稿から親会社のエンジニアブログに移行しました。親会社のエンジニアブログのほうがメディアとして大きいこともあり、書くメンバーにより良い影響が出せると考えたためです。実際に100倍ぐらいはPVが違っていたのでもっと早めに移行しておけば・・・と反省しました。
技術広報としてのエンジニアブログのメリット・デメリット、代替案については以下の記事で触れているのでご参照下さい。
技術スキルマップ＆スキルグレード
[概要]
エンジニア毎に開発言語やミドルウェアなどのスキルマップを作成。
各スキル毎に習熟度をスキルグレードとして7段階で定義。
本人や周囲からのヒアリングやアウトプットを元に定期的に更新。
将来的に給与査定に利用するが、導入時は利用しない。
[導入背景]
プロジェクトチームを新しく作る際、個々人のスキルや習熟度を元にしてアサイン判断していたのですが、エンジニア組織の人数が増えてきて全員のスキルを都度把握するのが面倒でした。
そんな折、別組織でスキルマップ＆グレード制度を開始するとの話があり、担当者に施策をヒアリングして自組織にも適応する形で導入を行いました。
[導入した結果]
導入したのは良いのですが、運用(更新)が地獄でした。新しいメンバーが入ったり、半年に一度の更新タイミングで人数分のスキルマップの見直しが必要でした。
責任者の僕一人で完結出来ればまだ良いのですが、特定スキルでエキスパートにアウトプットを評価してもらう必要があることや、メンバーに評価できるようなアウトプットを整理してもらう必要があり、双方に多大なコストを払ってもらう必要がありました。
ただ、導入フェーズだったため給与査定には影響が無いこともあり、被評価者に更新モチベーションが無い状態で、評価者である貴重なエキスパートが疲弊するだけという結果になりました。
肝心のプロジェクトチーム編成時のスキルマップの活用についてですが、チーム全体のスキルバランスを考慮するというような場合には使えましたが、新規プロジェクトの場合は利用技術が固まっていないため有効に使えませんでした。
その後、別の要因からプロジェクトチーム制の廃止を行い、チームの固定化や少人数化を進めていたため、廃止をしました。
要因としては、施策を導入することに注力してしまい、運用フェーズのコストがイメージ出来ていない状態で全体適応してしまったことが挙げられると思います。参考にした別組織はまだ運用フェーズに入っていなかったので、似たような施策を運用している外部の企業に複数ヒアリングして実態を把握してから開始判断すればよかったなぁと反省します。
(ちなみに参考にした別組織もその後同様の理由で廃止してました)
技術目標制度&20%ルール
[概要]
給与査定において従来の事業寄りの目標とは別で、スキルに基づく技術目標を設定。参加プロジェクトに関係する技術目標以外でも問題ない。
毎週金曜日10時～15時(4h)を技術目標に対する時間にあてる。
[導入背景]
新しい技術の導入検証や既存プロジェクトの効率化を行う機会や時間を設けることが出来ず、目の前のタスクをこなすことに集中していたため、全体の技術力向上が妨げられていました。特に既存プロジェクトの場合に顕著になってしまい、メンバーから不満として挙げられていました。
ヒアリングを元に、組織として技術力向上の時間を設けること、その働きを明確に評価することをセットとして制度としてスタートさせました。
[導入した結果]
だいたい1年少しぐらい運用を行いました。当初はプラスの影響やアンケート上での高評価が続いていたのですが、徐々にマイナスの影響やアンケート結果で高評価と低評価が両方多いような状況になり、マイナスの影響が顕著になったため廃止を行いました。
エンジニアには、スキルアップをしたいマインドと事業貢献をしたいマインドの両方があると思うのですが、本施策によってスキルアップマインドだけを強力に引き出してしまう結果になりました。
スキルアップマインドが強いエンジニアにとっては天国ですが、事業貢献したいマインドが強いエンジニアにとってはあまり納得の行かない状態になってしまっていたと思います。結果エンジニアのマインドが2極化し、それを原因としたメンバーの離脱も複数ありました。
原因としては、技術目標を事業目標と切り離して設計してしまったことにより、個人のスキルアップが組織やチームとリンクしていない、もしくは非常に弱いものになってしまっていたことがあると思います。また半ば強制的に通常業務とは別の時間を確保したこともそれを助長する結果になってしまっていたと思います。
廃止後は、プロジェクト内で技術検証や効率化を業務タスク化することを定期的に働きかけたり、技術スキルアップを組織やチームへの貢献に繋げられるようにした上で事業目標に設定できるように変更しました。
エンジニア専用オフィス
[概要]
エンジニア専用のオフィス。エンジニア以外は入室不可(出入口のロック解除できない)
MTGルーム無し。オープンスペースを多めに用意。
オープンスペースには大きめのクッションなどを配置、自由に業務OK。
[導入背景]
固定電話の呼び出し音だったり、ビジネスメンバーからの口頭ベースのコミュニケーションが頻発していたため、なかなか開発に集中する環境が作れていませんでした。
会社としてエンジニアに投資する姿勢を明確に示したいこともあり、オフィスを拡張するタイミングでエンジニア専用のスペースを設ける事が決定されました。
[導入した結果]
エンジニアオフィス自体はとても快適でみんな気に入っていました。以前に比べると開発に集中しやすくなり、固定電話も無いので静かで逆に雑談しにくいぐらいの状況でした。
ただ、プロダクトチーム全体で見た場合にあまり良い結果ではなかったと思います。ビジネスメンバーの業務効率が悪化し、それ以上に見えない不満が溜まっていきました。
「集中できる場所」は必要なのですが「エンジニアを隔離するオフィス」としてしまったことで、本来ワンチームであるはずのエンジニアとビジネスチームを完全に分断してしまったことは組織の雰囲気に見えない影を落としてしまいました。
同じチーム内にも関わらず職種でオフィス待遇に差を付けてしまったこともビジネス側のメンバーの心象に悪影響があったと思います。
その後、同じフロアでビジネスチームも一緒に働くことにしました。どうなることかと思いましたが、電話の際は離れた場所に行くなどキチンと配慮してくれていました。また、ビジネスのメンバーからも集中して仕事しやすいとのことで好評でした。
職種によるワークスタイルに違いはあるとは思うのですが、職種で抽象化をせず個々人にフォーカスした最適なワークスタイルを提供する方が組織全体として見たときにフェアになったのかなと思います。
外部レビュアー契約
[概要]
社内に知見の少ない技術領域に対して、外部のレビュアーを契約。
リモートのコミュニケーションをベースとする。
Githubリポジトリを直接見てコードレビューもしてもらう。
[導入背景]
社内に知見が少ないプログラミング言語があったのですが、知見が少ない状態で組織のメインストリームに据えて複数プロジェクトを稼働させたため、プロジェクトによって書き方がバラバラで、同じプロジェクトでも前半と後半で全然違うという事態が発生していました。
運用フェーズに入り事態の収拾＝リファクタリングを始めたのですが、各メンバーの考えが統一できず、デファクトスタンダードもよくわからない状況だったため、なかなか進みませんでした。
また、当初は採用によって外部からの経験者を取り入れていく予定だったのですが、採用が困難だったため知見を取り入れることは出来ませんでした。
そんな折、前述した組織施策プレゼン大会にて提案があった施策を少しいじる形で外部レビュアーの導入を開始しました。
[導入した結果]
結論から言うと、あまり良い結果になりませんでした。
理由としては、運用フェーズに入って稼働しているシステムに手を入れるのは、社内メンバーでも難しいところ社外の方だとなおさら難しい事、さらにいうと十分に焦げ付いたシステムは外部の知見を持ってしてもどうしようもないという事があります。
外部レビュアーを入れるとしたら、新規プロジェクトやリニューアルなど能力を120％発揮出来るタイミングが最適と思います。実装フェーズにおいてもロジックを実装する前のフレームワーク的な部分の実装が一番真価を発揮する部分だと思います。
誤解がないように付け加えると、レビュアーで入ってもらった方にはとても感謝しています。スキルが非常に高い＆酷いシステムにも辛抱強く付き合ってくれる方で、レビュアーと言いつつコーディングも大量にして頂き、良い意味で金額に見合わないぐらいの貢献をしていただきました。あくまで僕が依頼するタイミングが遅かったことが原因です。
経営層向け組織横断システムレポーティング
[概要]
開発プロジェクト毎にヒアリングを行い、レポートを作成。月1で経営会議に参加し説明。
新規開発と既存運用でフォーマットは別途用意。
新規開発は、リリースまでの進行や品質に関するレビュー結果。
既存運用は、パフォーマンスやコストなどサービスに合わせた指標や、進行している大きめの開発タスクや技術的負債に関するレビュー結果。
また、プロジェクトチーム内の状態に合わせて経営陣へ人員調整やリリース延期などの進言を行う。
[導入背景]
会社内に複数の事業ドメインがあり、エンジニア組織は事業ドメイン毎に存在する形でした。とはいえ、エキスパート的な人材がどの組織にもまんべんなくいるわけもなく偏りがありました。
僕は1事業ドメイン内で複数の新規&既存プロジェクトの品質管理とサポートをしていたのですが、自分の事業ドメイン内で閉じる必要性を感じておらず、むしろ会社全体で取り組むほうが効率的だと常々感じていました。
これ以外にもいくつかの要素を束ねて、技術戦略室という技術横断組織を経営陣に提案する形でスタートさせました。
[導入した結果]
書いててデジャブがあったのですが、昔のブログに書いてますね。
* 時間がかかってみんなストレスが溜まる新規レビュー
* 当たり障りの無いことしか表現できない運用レビュー
横断組織に必要なのは信頼関係だと思いますが、この施策は信頼関係が構築できていない状態で進めるのはNGでした。強制力を働かせず、困ったときの相談を基本にして、徐々に信用を積み上げクチコミで広げていくような進め方が最適だったのかなと思います。
世の中にある横断組織は相談ベースで受け身な印象があったのですが、それが最適解だったんだなぁと今になってみると思います。
最後に
失敗した施策として記事に取り上げたものは、立案や実行を他の人が行ったものもありますが、最終的に自分が責任者として運用した施策です。施策の成否は、立案者や実行者ではなく運用フェーズの責任者が全て握っていると思っています。今でも思い出す度にしみじみと反省します。
ただ、施策において一番問題なのは失敗することよりも、誰もが失敗と感じている施策を延命させる事だと思います。失敗を失敗と認めにくい雰囲気も一役かっていると思うのですが、失敗を認めて施策を止める事や、失敗を分析して公表する事に対して周りがもっと寛大になってくれたら良いなぁと思います。
おわり