組織の成長に伴うプロダクト開発のリードタイムが増える問題を考える

タクシーアプリ「GO」でアプリ開発のマネージャーをしている takahia です！
本記事は開発生産性アドベントカレンダー20日目の記事となります。

はじめに

プロダクトの成長に伴って、人を増やし組織の成長させていくことは自然な流れです。
しかしながら、初期の小規模の組織だった時の成功体験から、組織を変えずに人を増やした結果、思うようにスケールせず、リードタイムが長くなってしまった経験を持っている方は結構いるんじゃないかと思います。

では、どうして人が増えればリードタイムが増えるのか、考えていきたいと思います。
簡単にですが、リードタイムが増える要因は、以下の３点が考えられます。

1. 人が増えると、情報格差が顕著になってくるため、ドキュメントの用意が必要になる。

2. 人が増えると、管理コストの増加する。

3. 構造化が進むため、意思決定までに時間がかかる。

1, 2に関しては、様々な管理方法が存在し、良し悪しはチームによって異なってしまうため、本記事では、3について、成長する組織の構造化に伴い、プロダクト開発のリードタイムが増えてしまう現象について考えていきたいと思います。

組織の構造化とそれに伴う一般的な考え方

例えば、メインプロダクトをアプリとしている会社の組織として、フェーズとして黎明期や成長期に区切って、PdM、Designer、iOS ENG、Android ENG、Backend ENGのそれぞれの職能の関係性を見ていきましょう。

組織の黎明期

それぞれの職能に対して、かなり少人数で組織を構成している時期かと思います。
少人数の時は、意思決定者もチームに所属しているため、プロダクト開発のリードタイムも最小限で済みます。

プロダクト開発を行うチーム

組織の成長期 Ph1

続いて、成長期を見ていきましょう。
プロダクトも成長し、少しずつ人も増えてきました。
大抵の場合は、リソース効率の観点から、案件アサイン型の運用となります。

各案件に各職能からメンバーをアサインし、案件チームを形成する

この時、案件ごとに一緒に仕事をする人が異なるため、お互いの職能に対して求める期待値が異なってくることが問題となってきます。

ここで、極端な例を見ていきましょう。
ENG目線で、ENGからPdMに求めるアウトプットが、あるENGはPdMに対して要件を要求し、WhatやHowを自分たちで考えることを望んでいるが、別のENGは仕様までをPdMに求め、コーディングすることを望むようにな環境を考えてみます。
この時、PdMは案件ごとに、一緒に仕事をするENGに対してやり方を変えることに頭を悩ませ、ENGも担当PdMが異なることによって期待しているPdMのアウトプットの違いにストレスを感じてしまいます。

今回は極端な例を出しましたが、少なからず、この体験をした方はいらっしゃるのではないでしょうか？

ここで、組織は、I/Fを用意する決断をします。
つまり、職能間のやり取りにおいて、I/Oを統一するために、ドキュメント形式を決めたり、開発フローを決めたり、依頼方法を固定化したりしていきます。

お互いにI/Fを用意する

組織の成長期 Ph2

さて、だいぶ人が多くなってきました。
人が増えることによって、各職能ごとに構造化が起きます。
この時、マネージャーが各職能にできるようになり、案件の進捗状況を細かく認識する必要性が出てきます。
その結果、マネージャーが、自分自身が全体を把握できる状況を作り出し、他職能へのアプトプットの責任も負うことになります。
基本的にソフトウェアのプロダクト開発は、製造業とは異なり、常に新しい挑戦をし続けているため、組織の成長期 Ph1で作成したI/Fから外れる事象も発生してきます。
人数が少ない時は良かったのですが、構造化されているわけですから、I/Fの更新に対しても、複数の職能のマネージャーの合意と、メンバーへの周知が必要になり、そこに時間がかかったりもします。

職能ごとに構造化が進み、I/Fを通してコミュニケーションを行う

こうなると、案件の意思判断のスピードはどんどん遅くなり、プロダクト開発のリードタイムが延びてきてしまいます。
一般的に、１人のマネージャーが見ることのできるメンバーの人数の適正値は7人程度のようなので、人が増えれば増えるほど、この構造化が進み、それに従ってどんどんリードタイムが延びてきてしまいます。

ではどうすれば良いのでしょうか？

リードタイムを減らすための取り組み

結局のところ、マネージャーが案件の進捗状況を細かく認識する必要性を考える必要があります。
これに関して、理由は以下の２点が挙げられます。

1. 他の職能に対するアウトプットに責任を負っていること

2.  メンバーの評価

共通のI/Fでコミュニケーションをすることをやめる

１つの手段として、各々の案件に対して、共通のI/Fでコミュニケーションをすることをやめるという方法が考えられます。

共通のI/Fでコミュニケーションをするからこそ、他の職能に対するアウトプットに責任を負う必要が出てくるため、その必要性を排除するために、共通のI/Fでコミュニケーションをすることをやめることを検討します。

そうすると、組織の成長期 Ph1で発生していた課題が、再発してしまうという懸念があると思います。
しかしながら、I/Oを統一しないといけない状況に陥ってしまったそもそもの背景は何でしょうか？
それは、案件ごとに一緒に仕事をする人が異なるということが、この状況を生み出してしまっていると言えないでしょうか？
つまりは、逆に言うと、一緒に仕事をする人を固定化することによって、この問題を解決できる可能性があります。

案件にチームをアサインする方式

タクシーアプリ「GO」のアプリ開発では、職能横断でチームを固定化し、案件をチームにアサインする手法をとっています。
そのため、各職能間のコミュニケーションに共通の制約はなく、チームごとで独自の文化形成がされています。
タクシーアプリ『GO』- プロダクト開発のプロセス改善というブログに、どのような体制で開発を行なっているか経緯も含めて書いていますので、是非興味がある方はご覧ください。

メンバーの評価

マネージャーがメンバーの評価のために案件の進捗状況を細かく認識することを止めるためには、どうしたら良いでしょうか？
１つの手段として、自分以外から、メンバーの情報が集まる仕組みを作る方法が考えられます。
メンバーと一緒に仕事をしている関係者から、ピアフィードバックを得る手法も良いでしょう。
しかし、一番重要なことはマネージャーの評価内容とメンバーの認識が合い、メンバー本人が内省をして成長することだと思います。
そう考えた場合、メンバーの情報をメンバー自身がしっかり把握し、適切にマネージャーに共有できる状況が一番健全だと考えます。
私のグループでは、メンバーとの1on1の内、月に１回は期の目標に対するメンバーの振り返りを行なっていますが、その際に、合わせてこの1ヶ月間に何ができたのかの認識合わせを行なっています。
これは担当案件の進捗確認という話ではなく、メンバー個人が何を達成したのか、例えば、テックブログを書いたという些細なものまで、しっかりアウトプットをお互いに把握するということに時間を使っています。

まとめ

組織の考え方は、チームや会社の文化にマッチしているかどうかにも左右されます。
ですので、本記事の考え方ややり方は１つの例だと思って理解していただければと思います。