こんにちは、ママ向けNo.1アプリ*1「ママリ」のアプリディレクター 齋藤です。
これは何？
アプリ開発チームを期間限定で細かいチームに分けて、うまくいかなかったことや反省点をまとめたものです。
サービス開発において、それを裏側で支えるチーム運営はどの現場においても課題はあるものと思いますが、今回は特に「チームの規模を小さくすると何に気をつけるべきか」に焦点を当ててみたいと思います。
3行まとめ 〜スモールチーム、これに気をつけるべし！〜
- リソースの代替可能性が限られる。ポリバレントな人材で戦術の幅を確保せよ
- 内向きになるな！チームの外にこそ答えはある
- 所詮スモール、できることは限られる。大きな夢を語りすぎるな
前提
スモールチームとはなにか
本記事では弊社事例として、スモールチームを以下の前提のもと進めます。
なぜスモールチームに？
組織変更前には以下の課題を抱えていたためです。
- 多くの目標を同時に追っていたため、リソースが分散していた
- プロダクトオーナー（プロダクトの責任者）に意思決定の負担が集中しすぎていた
- 意思決定後のリソースの取り合いが起きていた
私たちが提供している「ママリ」は、無料でユーザー同士がQ&Aを通じて「今のママが抱える悩みごと」を解決する場だけではなく、有料会員向けサービス「ママリプレミアム」を提供しています。
「ママリプレミアム」が提供しているサービスの中でユーザーにより便利にご利用いただくために、検索機能を提供しています。
組織変更前に抱えていた課題の前提を踏まえた上で、私たちが達成すべきことは、検索機能に魅力を感じて加入してくれるプレミアムユーザーを増やすことでした。
取り組んだこと
初動で取り組んだことを簡単に列挙します。
- 数値目標と期限の認識をあわせる。キックオフでは何より大事
- チーム発足と同時に小さいアクションプランをたくさん策定
- デイリーでの数値チェックの仕組み構築
- ロードマップを作らない代わりに初日からとにかくたくさんトライ
うまくいかなかったこと、難しかったこと
リソースの代替可能性が低い
今回のチームで最も難しい課題といえたのがこれです。
ディレクターである私はコードを書くことはできません。
チームによってはサーバーサイド専任のエンジニアが手空きになったり、データ分析用のクエリもエンジニアがかいていたりと、リソースの代替可能性が低いチームはどうしても出てきます。
スモールチームでリソースをチームに委ねる分、多価な人材が求められます。
発想がチーム課題の解決に偏った
チームが学びを経て成長していけば行くほど、チーム外のことに目を向ける機会が少なくなり、視野が狭まることが多かったように感じます。
視野を広げる時間を定期的にチームで意識して取るようにしていたものの、部分最適の思考回路に陥ることも少なくありませんでした。（これは私自身が大いに反省せねばならないところ）
ちょっとやりすぎかも？ぐらいに横断的にコミュニケーションを取っていくことをオススメします。
目標を大きくしすぎない
チームの大きさはそのままチームがこなせる仕事の大きさとほぼ比例します。
夢物語のようなビジョンを掲げて進もうとしても絵に描いた餅。
相応の目標をクリアしながら小さく成功と失敗を重ねていく胆力が求められます。
（余談）うまくいったこと
うまくいったことも多くありました。
コミュニケーションコストが下がった
mtg の時間のとりやすさや口頭コミュニケーションの増加、背景知識の共有によって削減できたコストは大きかった
PDCA が高速化
スモールチームの最大のメリットはこれ。これができないならチームを小さくする必要はないとも言える
振り返りの精度が上がった
誰が何をやっているかが把握できるので、次のアクションに繋がりやすい細やかな振り返りができるようになった
チームへの献身性が上がった
職種の垣根を超えた協力体制が構築できた
スモールチームは機動力が最大の武器です。
ユーザーに価値あるものをとどけるための機動力を実現するためのコストは先払いでしっかり払うべきです。
まとめ
スモールチームで気をつけるべきこと
- リソースの代替可能性が限られるので、複数の言語をかける人がチーム内に1人以上いた方が柔軟性が上がって戦術の幅も広がる
- チーム外とのコミュニケーションはとりすぎぐらいに取ったほうが良い
- 小さいチームではできる業務の範囲が限られる
スモールチームでうまくいったこと
- コミュニケーションの質と量が担保された
- 意思決定スピードが担保された
- 実行スピードが担保された
- 結果として、短期間で多くの学びを得ることで顧客に価値ある機能を提供できる確度が高まった
以上、ひとつの事例として皆さんの参考になれば幸いです。
