エンジニアの特性に合わせてチーム構成ープロダクト開発の効率最大化をめざす
ソフトウェア開発のエンジニアリングマネージャーとして実践している取り組みを紹介します。
エンジニアたちの特性でチーム分けしました。
全員が得意を活かせれば最大の成果に繋がると考えました。
※実際は諸事情により全員を対象にはできていません。
体制を考える前に組織の課題出し
この時に出た課題は下記の内容となりました。
やりたいこと、目指している姿がエンジニアによってちがう★
･･･技術だけを追い求める
･･･技術は商品を作る手段と考えている
･･･ハード関連に興味がある
･･･開発プロセスに興味がある
若いエンジニアが技術への興味が薄い
･･･組織を商品力に目を向けた結果、技術への興味が薄くなりました。組織が次のステップに来たと感じた現象です。
チームにレベル差がある★
･･･主にマネージメント力と問題解決力の差
チームリーダーのステップアップがない★
･･･リーダーのキャリアアップが狭き門となっている
チーム同士の助け合いやつながりが少ない★
･･･自分達で背負い込んでしまっている
(マネージャーが頑張るべきポイントかもしれません)
※ここからの話は★の付いた課題に対する内容となります
課題を踏まえて、チーム構成を考えました。
チーム構成
フォワードチーム
・プロダクトを良くすることに注力するチーム
・ユーザーニーズへの意識が高いメンバーで構成した若手中心のチームです。
ユーザーニーズを満たすための評価サイクルをより速く回すことを使命としています。
それを阻害するジョブを他の役割のチームで対応することにしました。
サポートチーム
・システムを完成させる事に注力するチーム
・フォワードチームとローテーション
評価サイクルを回しているとシステムを作り上げる時間を作る事が難しくなるため、作り込みを主で行うチームを作りました。
マネージメントチーム
・マネージメントに長けたチーム
・元チームリーダーたちで構成
彼らの経験を元に全体スケジューリングや問題解決に取り組みます。リーダーの教育も兼ねています。
今回の体制で最も重要となるチームです。
ウォーターフォールチーム
・ユーザーニーズへ直接関わらない部分を担当
ウォーターフォールで進める箇所やソフトウェア品質の管理をします。
システム
開発を5つの期間で分けています。
１.検討期
プロダクトのターゲットや方向性を決めるフェーズ
２.開発初期
プロトタイプを作っては壊し、搭載すべき機能を検討するフェーズ
３.開発中期
機能の大枠は決まり、細部のブラッシュアップを進めるフェーズ
４.開発終盤
ベータ版リリース、フィールドテストなど実際にユーザーに評価してもらいプロダクトを仕上げていくフェーズ
５.リリース後
プロダクトをリリースし、市場で発生した不具合の修正パッチをリリース
・マネージメントチームの中から検討を得意とするメンバーが検討期〜開発初期までを担当します。次にスケジューリングや課題解決が得意なメンバーが開発中期からリリース後までを担当します。
技術に長けたメンバーが、システムの設計などをフォローする形になります。
・フォワードチームは開発初期からリリース後まで入り、チームリーダーが開発のリーダーとなります。
・サポートチームは開発中期〜開発後半の繁忙期に入り、システムを作り上げる事を主とします。
マネージメントチームとフォワードチームのリーダーで搭載機能に対する技術検討を行う。
この時期にフォワードチームのメンバーは
サポートチームとして他のプロダクト開発に参画します。
プロダクトの大枠が固まった時にフォワードチームは本格的に参加していきます。
この時期にシステムの設計を固めていきます。
並行で評価サイクルを回すため、プロトタイプを作って、評価をまわします。
開発中盤でサポートチームが参画してきます。
ここで設計されたシステムの実装を進めます。
フォワードチームは余裕があればプロトタイプの合間にシステムの開発にも参加します。
これらの開発と並行でウォーターフォールチームがウォーターフォールで作り上げる箇所の開発を進めます。
フォワードチームとウォーターフォールチームとの橋渡しはマネージメントチームが行います。
※今回抽出した課題で解決できていないものは、別の機会でお話しします。
気をつけるべき事
チームリーダーとマネージメントチームの役割や権限の範囲が曖昧
常にお互いに言葉にしていく事が大事です。
曖昧にするのではなく、お互いに明確にする姿勢を持ちます。
主に1on1を活用して解決していきます。
フォワードチームがシステム全体を理解できない
サポートチームが重要な箇所を作ると
フォワードチームのメンバーが理解できないことがあります。
改造時の見積もりやリスク管理が難しくなります。
設計はフォワードチームが主に行うことと、
サポートチームが作った箇所のソースコードレビューはフォワードチームが実施します。
効果
・マネージメントの底上げができた。
・エンジニアがやりたい事に集中できるためモチベーションが上がった。
・評価サイクルを継続的に回す事ができて評価をスケジュール通りに進められた。
・チーム間の情報共有が増えて漏れが減った