iOSチームのチーム戦略
iOSチーム開発この記事はMobility Technologies Advent Calendar 2021の1日目です。
タクシーアプリ『GO』のアプリ開発のマネージャーの日浅です。 2020年の会社統合後、iOSチームのマネージャをしていましたが、その当時、どのような考えでチーム戦略を考えていったのかを振り返っていきたいと思います。
背景
統合時の状況
2020年4月に、JapanTaxi株式会社と株式会社ディー・エヌ・エーのタクシーアプリ『MOV』などが事業統合し、株式会社Mobility Technologies（以下MoT）がスタートいたしました。
統合によりiOSエンジニアは増え、今までよりも多くの機能を作り提供できる状態となったことで期待に胸を膨らませていました。
しかしながら、コロナ禍真っ最中で統合したこともあり、フルリモート下でチームビルディングをする必要がありました。
統合時のチーム課題
文化の違う２つのiOSチームが１つになったため、共通の意識を持つことが先決だなと考えました。
そのため、まずはじめに、半期末にはチームがどのような状態になっていたいかというテーマでワークショップを行い、現在そこからどのような課題が存在するかを全員でしっかり把握することにしました。
その結果、上記の画像のように、各々のメンバーから多くの意見が出てきましたが、私たちはそれらを大きく分けて、３つの種類に分別しました。
- 組織力
- 技術的品質
- 製品品質
せっかくなので、それぞれの種類別にどのような意見が出てきたかいくつかあげてみましょう。
組織力に関しては、
- 統合前と比べて開発効率が向上している
- お互いが意識せずともフォローしあえる
- 経営的視点だけでなく、我々組織の一員としても一つになってよかったね、と思えるチームを作る
- 他社がマネしたくなる開発組織や仕組の導入
など、チームとしてお互いの心理的安全性を向上行い、また圧倒的なプロダクトを作る環境にしたいという意思が垣間見えました。
技術品質に関しては、
- 技術的な負債が明瞭になっており、グループ内で共通認識が持っている
- 負債を放置しない
- 案件が不具合なくリリースされている
- スケジュール遅延なし
など、QCDを意識した内容が多く挙げられました。
製品品質に関しては、
- 旅行カテゴリー１位にする
- ユーザが求めているアプリが開発できている
- 競合よりレビューの評価が高い
など、人数的にも今までよりもできる幅が広がったことにより、期待値の高い意見が出てきました。
私たちはこの中でまずこの半期で組織力、技術品質を向上することにフォーカスすることにしました。
と言うのも、圧倒的な製品品質を作り出すためには、それを上回る技術品質がなければ生み出すことができず、また、圧倒的な技術品質を生み出すためには、個々のエンジニアのスキルも大事ですが、チームの心理的安全性が非常に不可欠な要素だと考えたからです。
本ブログでは、この組織力向上に対して、どのようにアプローチしていったのかを書いていこうと思います。
また、技術品質に関してどのような取り組みを行なったのかは、弊社のiOSエンジニアが、MoT TechTalk #3 タクシー配車ならではの技術が盛りだくさん！iOSアプリの開発現場 とiOSDC Japan 2021の『大規模リファクタリングの極意』の登壇で語ってくれていますので、是非これらもご覧ください。
今振り返ると、このタイミングで向かうべき姿を意識することができたので、このワークショップは非常に良かったと思っています。
組織力向上のための取り組み
事業ミッションと持続可能な体制づくり
当時、事業ミッションは、『JapanTaxi』アプリと『MOV』アプリを統合した、『GO』を2020年9月にリリースすることでした。
しかしながらその後も、数多くの機能を実現したいことはわかっていたので、iOSチームの中で『GO』の開発を行うチームと技術品質を上げるチームの２チームに分ける判断をしました。
物理的にリソースを分けた理由としては、同じプロジェクトにアサインするメンバーが多くなればなるほど、心理学的にも一定の非効率さが出てしまうためと、『GO』は『MOV』をベースとして作成することが決まっていたので、リリースした後の『GO』の開発を見据えて、現在の技術的負債を明確にし、開発効率を上げることに全力で取り組んでもらいたい意図がありました。
心理的安全性を担保するための活動
チーム活動の一元管理
チーム活動に関してよくあるのは、話し合った情報が分散してしまうことが良くあります。
せっかく時間をとって議論した内容や活動記録も、その後見られることがなくなってしまえば、チームの資産とは言えません。
私たちは、Miroというオンラインホワイトボードツールで、目標設定の内容や、非定期で行なっているブレストの内容、各週の振り返りなどを一箇所に集めることにしました。
こうすることで、チームの活動の見える化に勤めると共に、意識をすることなく過去の情報が目に入るようになり、例えば、ディスカッションを行う場でも過去の情報に容易にアクセスできるようになり、話に広がりがでました。
２人体制での開発
統合前は、案件に1人をアサインすることがありましたが、心理的安全性を担保するために、原則２人をアサインすることにしました。
その結果、以下のようなメリットが生まれました。
- 常に２人での開発なので、案件の仕様の属人化を防ぐことができました。
- PR時は、もう１人がレビューするため、仕様理解にかかっていたリードタイムがなくなりました。
- 本人の希望により、新しいプロダクトへ移動したり、バックエンドの開発に移動したりすることがあるのですが、それに伴う引き継ぎがほとんど必要なくなりました。
週１でのWin Sessionの開催
技術的な情報共有も、心理的安全性を担保する上で重要な要素になってくるため、スプリントの成果を発表するWin Sessionを通じて、実際の設計や実装の相談をしたり、PRを見ながら意見を言い合う機会を設けました。
その結果、副次的に、共通コンポーネントを作成した際の情報共有であったり、設計の前段階の思考した内容のフィードバックであったり、かなり様々な内容の議論が飛び交うような場となりました。
目標設定能力と振り返り能力の向上
弊社は目標設定をOKRを採用しています。
iOSチームのチーム力向上のためにも、ある程度同じ方向を向き、お互いにサポートし合えるように個人の目標設定や振り返りを見える化をしておく必要がありました。
組織として目標設定だけ共有するのは見かけますが、私たちのチームでは個人個人の振り返り内容も、各々に了承をとった上で、共有することにしました。
と言うのも、OKRの目標設定や振り返りというのは一種のスキルが必要です。
もちろん中には振り返りが苦手なメンバーもいるので、そうなるとチームとしての方向性を合わせていく作業も、半期末の評価の際に上司にやってきた活動が適切に伝えきれなかったりと個人としても、影響が出てしまうので、お互いがお互いの振り返り内容を確認し、スキル向上ができることが大事でした。
これらの活動を実践することによって、チーム内の心理的安全性を担保することができ、無事2020年9月にタクシーアプリ『GO』のリリースができたとともに、後続案件も順次リリースすることができたと感じています。
プロダクト開発に関して課題
しかしながら、『GO』をリリースした後も、プロダクト開発において、以下のような様々な課題が出てきました。
- コミュニケーションパスが非常に多いため、コミュニケーションコストがかかる
- 毎回プロジェクトに対して各Platformから人員をアサインするため、チームのアウトプットが一定ではなく、チーム開発自体も洗練されにくい
- 同じプロジェクトで開発をしているが、各メンバー間でプロジェクトの情報量に差分がある
- PdM, エンジニア、デザイナー、QAを横断した課題解決の仕組みが乏しい
これらの課題に対してどのように立ち向かっていったか、Mobility Technologies Advent Calendar 2021の25日目で書こうと思うので、是非そちらも楽しみにしていてください。
We're Hiring!
📢 Mobility Technologies ではともに働くエンジニアを募集しています。興味のある方は 採用ページ も見ていただけると嬉しいです。
Twitter @mot_techtalk のフォローもよろしくお願いします！