- 多様なバックグラウンドを持つメンバーが互いを理解し、協力して高いパフォーマンスを発揮できるチームにすること。
- メンバーそれぞれのスキルやキャリア志向に合わせた成長を支援すること。
1. 目の前のタスク、プロジェクトに追われがちになってしまうため、目線を上げるタイミングが必要だと考えた。
日々の開発に集中していると、ただタスクを完了することで精一杯になってしまい、自分たちの開発の状況の把握がうまくできなかったり、どんな価値を届けようとしているのかの意識が薄くなってしまうと感じた。
そこで四半期に一度オフサイトミーティングを開催した。この場ではオフィスから離れて、理想のプロダクトの状況を話し合ったり、自分たちの開発プロセスを一度俯瞰的に眺め暗黙のルールとなっている場所を探してWorking Agreementとして明文化したりした。チームの状況に応じてコンテンツは変更しながらチームビルディングの場として活用した
2. 強いチームを作るため、それぞれのメンバーが幸せになるために明確な目標とそれにアラインした仕事があるべきだと考えた
マネージャーとして成長支援を行なった。基本的にはメンバーのなりたい姿から具体的な短期の目標に落とし込んでいくが、キャリアを具体的に描けるメンバーの方が少ない。そういったメンバーに対しては例としてのキャリアパスをいくつか出してどれが興味あるかを聞いたり、本人が言語化できていない興味関心（例：「あの仕事、楽しそうでしたけど興味ありますか？」）を引き出せるよう努めた。その上で、本人の目指す方向性と現在のスキルレベルを考慮し、少し挑戦的な（頑張れば達成できる）タスクを意識的にアサインすることで、スキルアップと自信の獲得を支援した。
M&Aにより統合した、設立2年程度のSaaSアカウント管理サービス開発チーム（エンジニア7名：社員4名、業務委託3名）
- M&A後のチームを迅速に立ち上げ、プロダクトの成長フェーズに必要な開発スピードを実現すること。
1. 若いプロダクトだったのでとにかく機能開発のスピードを重視するべきだと考えた。
M&A統合に伴い導入された全社標準の開発プロセス（全コードレビュー必須）が、スピード重視のプロダクトフェーズに合わず、特に技術力の高い元CTOメンバーのアウトプット速度を大きく低下させてしまった。
プロダクトの成長のためには開発スピードの維持が最優先課題だと判断した。メンバーの技術力とプロダクトへの理解度に対する信頼を基に、標準プロセスへの固執はリスクと考え、上長と相談の上で、該当メンバーに限りレビュープロセスを一時的に緩和するという例外ルールを設けた。これにより、開発スピードを回復させることができた。
2. M&A前から契約している業務委託エンジニアとのコミュニケーションがスピードを遅くすると判断し、入れ替えることを判断した。
M&A直後は週10 ~ 20時間稼働の業務委託メンバーが混在し、フルタイムメンバーとの稼働時間のずれから待ち時間が発生したり、状況の把握にコストがかかっていた。また、チームとしての一体感を醸成することも課題だった。
契約更新のタイミング等を利用し、段階的に全員フルタイム稼働の業務委託メンバーへ切り替えることを関係各所と調整・推進した。結果的に全員をフルタイム稼働の業務委託に変更し、同期的コミュニケーションがスムーズになり、より抽象度の高いタスクもお願いできるようになった。
給与・労務機能開発チーム群およびSaaSアカウント管理サービス開発チーム（全6チーム、エンジニア合計約20名）。うち2チームは担当マネージャー（2名）経由での間接マネジメント。
プロダクト全体のロードマップ策定、およびそれを実現するためのエンジニア組織戦略（異動、採用）。
- 事業戦略と連携したプロダクトロードマップを実現可能な、強いエンジニア組織（チーム構成、人材）を構築・維持すること。
- 組織の将来を見据え、リーダーシップを発揮できる人材を採用・育成すること。
-管轄する全チームの状況を正確に把握し、課題に対して適切なサポートや意思決定を行うこと。
1. プロダクトロードマップ実現のため、先回りしてリーダーを任せられるエンジニアの確保、育成が必要だと考えた
プロダクトロードマップの実現に向けて組織体制を考える中で、まずチームリーダーを任せられるエンジニアを決めるところからスタートした。そして将来リーダーが不足すると判断し、段階的にポテンシャルのあるメンバーにリーダー業務を行ってもらうようにアサインを調整した。リーダー候補となり得るメンバーの発掘・育成や、メンバーのキャリア志向と必要なスキルセットを考慮した戦略的な異動・チーム再編を計画・実行した。これにより、事業目標達成とメンバーの成長機会創出の両立を目指した。
2. 組織構想を実現するためには、既存メンバーだけでは足りず、必要なスキルやリーダーシップを持つ人材を外部から獲得する必要があると考え、採用活動を行った
求める人物像を具体化したJob Descriptionを作成し、採用媒体での候補者ピックアップ、面接、オファー面談での魅力づけまで、一貫して責任を持って担当した。これにより、組織に必要な人材を的確に、かつ熱意を持って迎え入れられると考えた。
3. 各メンバーの評価を行うにあたり、各チーム、プロジェクトとその中でのメンバーの状況を積極的にキャッチアップするべきと考えた。
マネジメント範囲が拡大し、自身が直接プロジェクトに関与しなくなったことで、各チームで起きていること（進捗、課題、メンバーの状況など）の解像度が低下し、適切な判断や支援ができなくなるリスクがあった。開発責任者というロールのみであればこれでも良いが、エンジニアリングマネージャーとして各メンバーの期末評価を行うにはこの状態では良くないと考えた。
広範囲な組織を効果的にマネジメントするには、意図的な情報収集の仕組みが必要不可欠だと考えた。担当マネージャーとは週次、その他のメンバーとは隔週で1on1の時間を確保し、対話を通じて状況を把握した。さらに、自身で2週間に一度、全チームの進行中プロジェクトとその状況を書き出して整理・確認するプロセスを設け、組織全体の状況把握と課題の早期発見に努めた。