ID:23510さん

EMや開発責任者を歴任した後、立ち上げたDX事業部の開発組織20人のマネジメントを担当 # 時系列 - EM - 5人、2年 - スマホゲーム開発ディレクター -10人、1年 - EM - 5人、1年 - スマホゲームQA責任者 - 社内4人、外部20人、半年 - DX事業部開発責任者 - メンバー20人、4年

DX事業部は子会社の片隅で立ち上げた小さなプロジェクトだったが、大手製造業会社とのアライアンスが決まり、急遽大規模に開発体制が必要になった。 # ==過去分 # EM ## 役割 - エンジニアリングチームのマネジメント - コード/サービスの品質担保(テックリード) # 開発ディレクター ## 役割 - 各リリースタイミングごとの開発物の決定(事業責任者とのすり合わせ) - ガントチャートを利用した進行管理、遅れた場合の調整と意思決定 - リリース作業の統括(クライアント、サーバー、QA) エンジニアリングマネージャー①と兼任 # QA責任者 ## 役割 - エンジニア/QA間での認識合わせ/情報共有フローの構築 - QA計画の立案 - QA計画の実施

その後も活躍できる強いエンジニア組織を作るために下記を行なった # 組織人数、体制の構築 ## 新卒向けブランディングを徹底強化。結果その代で一番人気の配属部署に - 近年新規事業に若手から関われる部署がかなり少ないことに目をつけ、紹介資料を作り徹底訴求 - その代で鼻息荒いエンジニアにリファラルでこえをかけ徹底クロージング - その代の優秀層、インフルエンサーであったこともあり、口コミで行きたい人が増えていった ## 社内の徹底リファラルによる異動獲得 一緒に働いたことがある優秀な人リストをはじから出してもらい、端からクロージング ## 週1程度稼働の超優秀層のエンジニアを顧問で獲得 過去関わりがあった2名にフロントエンド、バックエンドそれぞれ入ってもらい、技術意思決定の後ろ盾を作った。 若手比率が高くなると想像される中で経験で裏打ちしてプロジェクトが進行できるようにした ## 業務委託採用においては、エンジニア人材エージェントを本社エージェントとは別に個別開拓 - 大手人材エージェント経由からは供給は多いが仕事力、技術力が安定せずプロジェクトリスクが大きかった - 社長や経営にエンジニアがいる小規模目な会社にアプローチをかけ開拓 - 1社はその後の急な大規模開発立上げの時に大きく寄与 # エンジニア組織の構築、運営 ## 1on1の徹底実施。人数増加に伴い育てたメンバーに対応を委譲 過去のマネージャー経験から1on1や対話力には自信があったため、それを活かす形で初期は全メンバーと1on1を継続的に実施 https://note.com/growsic/n/n94095fd0cfb4 ## メンバー向けの発信の強化、記事化 1on1や対話力には自信があったが、組織のスケールを踏まえ、3回以上アドバイスしたことはnoteにして適宜timesで発信、相談されたらurlを送る https://note.com/growsic/n/ne209c1e75593 https://note.com/growsic/n/n2a5c62a554a0 https://note.com/growsic/n/n68e0f22dada1 # ステイクホルダーとの毅然とした交渉。社外役員であっても交渉を挑む 組織が壊れる大きな要因の1つとして、QCDのいずれかが破綻しているのに、事業の意思決定に対して交渉できず、組織で歪みを無理やり飲まないといけない時である。 先方が要求する開発スコープが肥大化、スケジュール圧との板挟みになった時に、毅然と交渉を行い調整するなどした。 https://note.com/growsic/n/n2a5c62a554a0 # =====過去分 # エンジニアリングマネージャー① ## 直面の課題: ①エンジニアリングマネージャーとしての信頼確立 ②サービスの品質担保 ## 考えと対策: ### ①エンジニアリングマネージャーとしての信頼確立 #### 課題: 自分より全員10歳以上年上のエンジニアのチームでエンジニアリングマネージャーに就任。 経験の浅い若手がリーダーになったと見えていたようで、あまり信頼されている状態ではなかった。 自分がチームとして正しい意思決定を行い、遂行出来る状態を目指した。 #### 対策: ##### ・メンバーと普段から徹底的に話す マネジメント以前に、人間同士としてある程度信頼関係がある状態が必要と考えた。 ランチにたくさん行く、毎日雑談を話しかける、相手がやっているスマートフォンゲームを自分もやって話しかけに行くなど、地道に話す接点を増やし続けた。 ##### ・根拠のある意思決定の提示、間違っていなければ絶対にぶらさない 意思決定をメンバーに伝える場合は、その意思決定がなぜ妥当なのかを必ず説明するようにした。 なりでやってこなかったこと(レガシーな実装の仕方やテストを書かないなど)は、雰囲気に押されそうな曲面でも必ず断り、決めたことをやってもらうようにした。 ### ②サービスの品質担保 #### 直面の課題: ・コードの品質が低く、レビューで良くなる環境になっていない ・単体テストがほとんどない（ゆえに肥大化したメソッドが乱立している） ・本番環境で不具合/障害が頻発する コードの品質担保とサービスの品質改善を目指した。 #### 対策: ##### ・徹底的にコードレビュー デザインパターンやリーダブルコードで基本とされている内容を徹底的にコードレビューで書いた。 必要あれば席まで行って説明しにいった。 ##### ・単体テストの推進 仕組みだけは存在していたので、リファクタ時にメソッドの切り分け、テストを書くことを推進した。 「こういう風にやるのが良い」を伝えるためにも、参考になるようなプルリクを出すようにした。 ##### ・インフラ構成/実装設計の見直し 事業責任者やインフラチームを巻き込んで障害に強い設計に変えるための手順立て、工数の確保を行った。 機能開発だけで工数が一杯になていたところから、保守性の向上のための工数を取れるようにした。 # 開発ディレクター ## 直面の課題 開発ディレクターが突然不在になった後の、開発チームの再構築 ## 考えと対策 開発ディレクターはビジネス職のメンバーが担っていたが、急遽移動になり不在になった。 残ったメンバーから開発ディレクターを出す必要があり、バックエンドチームのエンジニアリングマネージャーと兼任する形で立つことになった。 兼任である以上以前のようなマイクロマネジメントを開発ディレクターとして担保することは困難。 - 自分が一番コミットするのは最上流の意思決定と全体の進行/品質担保 - 各セクションの業務は各セクションのリーダーにより移譲する 方針で進めることとした。 その分全体の進行と品質担保には強くコミットするようにした。 結果エンジニアが開発ディレクターをやっている利点も作用し、以前よりプロダクト改善開発のリリース物量が2倍以上に増え、機能開発に止まらない開発チームになっていった。 # QA責任者 ## 直面した課題 - プランナー/エンジニアとQAが連携できていない - 情報共有すらままならず、お互いに不信感がある状態 - 開発ワークフローが構築/定着されていない - QA状況がチームから見て見えてこない 状況を改善するべく、QAの責任者として入ることになった。 ## 対策 ### 徹底的に情報を集約 / 開示 - 開発物の共有 - QA必要項目/観点のすり合わせ - その後開発からQAスケジュールの確認 を行うmtgを全開発機能に対してやり直し、QA/他セクションが認識あっている状態を作った。 ### QA状況の開示 他セクションから見て欲しい情報を洗い出し、デイリーで開示できるスプレッドシートを構築。 毎朝の共有ができる状態にした ### 開発環境のフロー整理 QAを行うにあたり - 開発物の開発状況 - クライアントのビルド - サーバーの環境 - 各種データ/アセット状況 がちぐはぐなまま進行していた。 QAを開始できる状態定義を行い、全て満たしている場合QA着手を行うフローを整理した。