みなさんこんにちは、株式会社マッチングエージェント執行役員の新居と申します。
サイバーエージェント子会社である弊社が運営する恋活サービス「タップル誕生」にて主にプロダクトマネージャー・開発ディレクターとして従事しております。
ここ数年「タップル誕生」はおかげさまで多くの方々にご支持いただき、事業を伸ばしてきました。
また事業の成長にあわせ多くの新しい仲間が参画し、振り返ると１年で２倍以上に増え総勢３０名近くの大きなチームとなりました。
今回は開発フローの側面で「１年でチームメンバーが２倍になるまでにみえた課題や取り組んだこと」についてまとめてみようと思います。
１年前はどんな感じ？
２０１５年１２月時点でチームメンバーは会社全体で１５名。うちエンジニア、デザイナーは７名ほど在籍していました。
開発フローついて一言でいえば「小さく作り、小さくリリース」、のサイクルでサービスを改善してきました。
スタートアップらしいスピード感ある開発で勢いがあった一方、
品質担保においては少し弱く、テスター１名と実装者間で起こしたテストケースに沿ってテストを行うといったやや心細いフローでした。
このフェーズまでは長期的な品質改善や検証よりも新しい機能開発に注力していました。
新メンバーが続々と参画
事業を加速させるため、２０１６年の後半より続々とエンジニア、デザイナーの参画が決まりました。１年前と比較するとエンジニア、デザイナー組織だけでみれば２倍以上に増えています。なお、新しいリードエンジニアの加入により、真っ先に取り掛かったのは技術的負債の返却です。
その時の内容はこちらの記事でご参照ください。→ https://developers.cyberagent.co.jp/blog/archives/2450/
こちらをはじめ、チーム全体で品質改善に向き合い実現していく体制が整ってきました。
開発プロセスの再構築
「開発チームが大きくなる ＝ より多くの機能をユーザーに届けることができる」
これは事業機会を創出すると同時に、必ず実現すべき我々のミッションでもあります。こちらを大前提に、改めて下記を軸に開発プロセスの見直し・再構築に取り組みました。
POINTは
メンバーが増えても…
① 品質を落とさない
② 改善速度を落とさない
こと！
①品質を落とさない
なかでも「不具合をリリースしない」体制作りは最優先で取り組んだことの一つです。
バグが事業リスクにつながることを改めて意識し、テストフローを仕組み化するなどバージョンアップを行いました。
テコ入れ前は前述の通り、実装者とテスターでチェックを完結させましたが、このフローで対応できない開発量になることを踏まえ下記にあげたようなテスト強化に少しずつ取り組んでいきました。
１.テストチームの強化
テストケース作成、オペレーション、ディレクションなど品質検証フェーズをハンドリングできるメンバーにジョインしてもらい、テストチームの体制を強化しました。
２.観点別にテストを分業化する
・改善した差分を重点的にテストするメンバー
・リリース前のリグレッションテストを行うメンバー
それぞれに固有の不具合が発生しうるため、担当を分けテストを実施し、クリティカルな不具合を早期に検出、修正期間内で改修できる体制に変更しました。
３.テストケースファースト
新機能の仕様を開発メンバーと擦り合わせるmtgではテスターにも必ず参加してもらい、仕様の把握からテストケース作成、開発者を交えた項目レビューを行い、開発前に高い精度でテストができる下準備のフローを作りました。
またテスターによる仕様のレビューが入ることで、ミスや考慮漏れなどを早期に解決できるようにもなりました。
あわせてテストケースの補強、メンテナンスは随時行い、
最新の仕様に合わせたテストを必ず実施できるフローとなりました。
上記取り組みを推進するテスターをチーム化することで、
品質強化の仕組みを一つ実現したと同時に、
エンジニアが開発に集中できる体制にもつながったと思います。
②改善速度を落とさない
チーム拡大以前は２週間のスプリントベースで計画を立て、ときに関係者のみで仕様やスケジュールを取り決めるなどで開発スピードを確保することがありました。
ですが総勢３０名近くのチームで既存機能の保全と、より大きな改善を並行し、サービス運営をしていくフェーズになると、そうはいきません。
「事業ロードマップに即して、自分たちがいつ何を改善するのか」
をサービスに関わるメンバー全員で把握できるようにし、企画に関わるプランナーから開発者それぞれに設定されている大小のゴールを明確に、いつでもゴールを目指したコミュニケーションをベースとした、確実に歩を進める流れ作りに努めました。主に実践したことは以下のようなことです。
１.開発全体のスケジューリングを一元管理
タップル誕生にはいくつかの開発ラインがあり、工程や依存関係を明確にし、各自ゴールを把握してもらえるようにしました。
２.より正確なスケジュールで健全に生み続ける
実現可能なスケジュールのもと開発を進めることでスピードは担保され、それを継続し続けることで事業は成長していきます。
実現可能なスケジュールとは、ある程度完成した仕様から見積もったもので作ることがマストです。
柔軟性でカバーしようと楽観的に捉えていると、大まかに算出された工数で期日を決めがちです。しかし後の考慮漏れから開発中に過剰なリテイクが生じることで、曖昧な要素によって決定された期日に追われ、結果チームが疲弊していく、このような事業リスクにつながります。これらを最小限に抑えるルールを加えました。
具体的には
・原則、見積もりができる状態までリリース日を決めないコミュニケーションをとる
・見積もる時間を明確に確保し、その上でスケジュールを決定する
これらを実施することで関わるメンバー全員が健全に開発し続けられる体制づくりを整えました。
（いまも模索中）
３.毎日のちょっとしたコミュニケーションを工夫する
例えば以下のような、ちょっとした日々の工夫の積み重ねがスピード改善につながることも多いと考えています。
・適切なタイミングで、適切な分量のmtgを行う
各開発段階に応じた適切なタイミングでmtgができるよう工夫しました。
作り込む期間は極力mtgを控えるなど、開発に集中できる環境づくりをエンジニア、デザイナー以外も意識しておくべきです。
また開発大詰めの段階では、必要なメンバーに絞り、毎日１０分程度の確認mtgを実施するなど、各段階にあわせた過不足のないmtgの実施を行っています。
・即レスを心がける
開発中に生じるやりとりは主にslackで行われています。
仕様確認など、それらの回答を以って開発が進む場面がしばしばあり、地味なのですがいかに即レスできるかがスピードを保つ一つの鍵と考えています。
開発に関する即レスを業務の最優先に心がけています。
最後に
事業のフェーズ、チームの規模によって最適な開発プロセスや手法は常に変化し、
私たちはその移り変わりが激しい場所にいると感じます。
チームメンバーそれぞれがポテンシャルを最大限に発揮し、
継続して成果を生み続ける開発組織であり続けるために、
「今の進め方がメンバーにとって最も妥当か」
「より良い方法が他にないか」
など常に見直す目線を持ち合わせ、必要に応じて修正を入れるなど、
改善と向き合い続けることが重要であると感じています。
事業の成長とその担い手となるメンバー両方にとって
最良の結果が生まれる体制づくりに今後も取り組み続けていきたいと考えています。