これはアソビュー！ Advent Calendar 2023の6日目です🎁 今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください！
アソビューでエンジニアリングマネージャーをやっています竹内です。
以前より進行していた大規模システムリニューアルプロジェクトのプロジェクト責任者/プロジェクトマネージャー(以降PM)として携わっていました。 そして一部の機能をβ版ではありますがリリースまでこぎつけました！！！ リリースまでには様々な課題に直面しましたが、その中でも組織的な課題と実際に行った対策について書こうと思います。
はじめに
今回のプロジェクトでは開発組織立ち上げから組織をワークさせるまでがかなり大変でした。 要件定義を 1 年強行いその後開発組織を立ち上げましたが、30名強の社内でも大きなプロジェクトとなり私もこの規模は初めて担当しました。
ちなみに、要件定義や開発組織立ち上げ時については以下のブログでも書かれていますのでよければ御覧ください。
開発体制について
開発組織を立ち上げるときに以下のようなことを考え組成しました。
既存システムに携わったメンバーを中心にする
既存システムに携わってきたメンバーを中心にチームを組み、チームごとに業務委託や協力企業からの要員を新規に集め組成しました。 別チームから異動、中途採用、業務委託(フリーランス、協力企業)といったようなメンバーも多数いる状態からスタートしました。
ユーザーストーリーを大きな括りで分類しその単位ごとにチームを割り当てる
分類した結果 4 つの開発チームに割り当てることにしました。
各チームの特徴としては以下です。
- 各チーム 5-7 名
- 既にドメイン知識を保有しているメンバーは各チーム 2-3人
- それ以外は新規参画メンバー
- チーム横断で PM/PMO が 2 名
このような体制でスタートしました。
遭遇した組織的課題
開発組織を立ち上げ数ヶ月ほど経ちましたが生産性がなかなか上がってこない状況となりました。
最も大きな課題は、各チームのリーダーがメンバーマネジメントに想定以上に時間を割かざるを得ない状況になっていたことでした。
各リーダーがメンバーに要件や設計方針などを説明し期待する成果物をアウトプットしてもらうための活動が主となってしまい、重要な技術課題や設計などリーダーに期待していたことまで手が回らない状況でした。新規参画のメンバーもそれなりにいたのでなおさらです。
どんな対策をしたか
様々議論をしましたが最終的には、
- チーム内コミュニケーションコスト低減
- リーダーのマネジメント負荷軽減
このあたりが一番の課題と判断し、以下のような対策を講じチームを再編しました。
リーダーのマネジメント業務を削減
リーダーはこれまでの実績もあり特に信頼できる方たちでした。彼らにパフォーマンスを発揮してもらうにはマネジメント業務を極力させないようにし、技術課題に向き合ってもらえるようにしたいと考えました。
ただし、マネジメント業務は PM が行うこととなり PM の負荷があがることになりましたが、今回は PM/PMO が奮闘してくれたことにより乗り切れたと思います。彼らには感謝しかないです。
QA チームを開発チームと分離
これは良し悪し両面あったかなと思います。
- 良し
- 開発/QA それぞれのチーム内コミュニケーションが密になったこと
- QA チーム内で役割(テスト設計/実行など)分担できるようになった
- 悪し
- 開発/QA間コミュニケーションの難易度があがった
- 開発チームの進捗や仕様をタイムリーについていくことが難しくなった
開発/QA間コミュニケーションは会議体などを再定義し解決していきました。 仕様については PM が基本仕様をドキュメントにまとめ共有しました。ここも PM/PMO ががんばってくれました。
開発チーム再編
リーダーのマネジメント負荷軽減を目的としてチームを再編しチームの数を減らしました。 また、一部のメンバーは別の役割を設定し異動していただくこともしました。
最終的にチームとしては、
- 5 人 * 4 チーム(内 1チームは QA)
となり、開発チームとしては 20 % ほどメンバー減少となりました。 単純に人数が減ることによりスケジュール的に不安な面も感じ悩みましたが、結果的にプロジェクトとしては良かったなと思います。
スコープ変更に合わせてリーダーを PM に変更
前提としてこの対策を行う前に初期リリースのスコープを狭めています。当時の生産性を考えると期日までにリリースできないと判断したためです。
なので初期リリースに向けて推進力を上げるために、初期リリース部分を担当していたリーダーを PM とし PMO を 1人 つけた上でプロジェクト全体をハンドリングできる体制としました。 （ちなみに、このころから私は他のチームも見ることとなりこのプロジェクトでは PM のサポートするという役割に変化していきました）
ただし、前述の対策も含め PM の負荷が上がったと思います。
これをやればさらに良かったかもしれないこと
共通基盤チーム組成
リニューアルプロジェクトということもあり新しい技術にも挑戦したし、共通基盤的なタスク(ビルドやデプロイ、環境周り、非機能要件など)も数多くありました。
今回は開発チームの外にいる Tech Lead が推進し各チームにタスクを割り振るというやり方をしました。 しかし Tech Lead はこのプロジェクト専任でもないし、各チームはそれぞれのタスクをもっているため優先順位付けが難しく思うように進まなかったです。これによりプロジェクト終盤に偏り、リスクを早期に潰すということがうまくいかなかったと感じています。なので、専任チームをアサインしたほうが良かったかなと思います。
プロジェクトマネジメント強化
前述した対策の結果 PM の負荷が上がりました。開発チームに 1 PM ぐらいの体制に強化できればもう少し負荷を分散できたかなと思います。
ただし PM 間の要件の理解度/認識度をそろえるために別の施策も合わせて必要になるかと思います。
最後に
今回は大規模プロジェクトで実際に遭遇した組織的課題について紹介しました。チームがワークしているか、どこがボトルネックになっているかなどチームをよく観察したり 1on1 等で問題があるかを見つけていったりしましたが、なかなか難しかったです。このあたりを見極める力をもっとつけなければならないなと感じました。
PR
このリニューアルプロジェクトは現在進行系です。今後のアソビューを支えていくサービスに興味がありましたら、カジュアル面談からでもお気軽にお問い合わせください！ www.asoview.com
