こんにちは。Quipper採用担当の鈴木です。今回の記事は、@tominaritによる「Decision Making Guideline」です！是非、ご覧ください！

挨拶

新規事業開発チームにてプロダクトマネージャーを担当している冨成です。 GitHubやSNSではtominaritとして活動しています。

2018年の6月1日に入社してから公式サイトのリニューアルプロジェクトを完了させて以来、新規事業開発チームのプロダクトマネージャーとして奮闘しています。

もし当時のプロジェクトに関するブログ記事にご興味がある方はこちらからどうぞ。

前提

今のプロダクトチームはWeb Engineer 7人、 Native Engineer(iOS) 2人、Product Designer 2人、 Product Manager 1人となります。今では12人と大きくなったチームですが、去年のこの時期(MVP検証時期)ではまだ3人だったため、ここ1年で爆発的に人数が増えました。

当時は人数も少なく意思決定が早かったのですが、人が増えるにつれて様々な意見が飛び交うようになりました。多様性は非常に良いことであり、その飛び交う意見の中から最適なものを選ぶのがより良いプロダクト作りに繋がると私は考えています。Quipperはフラットな組織を目指しており、上下関係が少ないため自由に意見を発言することが出来ます。その結果多様性をよく体現出来ていると思う反面、意思決定が終わらないことがあります。

一般的な組織では意見が割れ、物事がどうしても決まらない場合、最終判断は◯◯さんに確認する等のプロセスが発生することが多いです。これは組織が大きくなりステークホルダーが増えてきた際によくある話です。しかし、決定するまでの判断に時間がかかってしまうため新規事業のようにとにかく早く意思決定し、PDCAを回して行きたい状況に置かれると不便に感じていました。

さて、ここから生まれる課題について入っていきます。

この記事でいう技術というのはTech Stack、System Architecture、Data Modellingなど、技術的に考えて決めないといけないことを包括しています。

課題

私は幸いなことに本当に優秀なエンジニアの方々とお仕事をさせて頂いています。技術力が高く、好奇心も強い、そしてビジネスにも理解を持ってくれている最高な仲間たちです。

優秀なエンジニアであればあるほど引き出しが広いと考えています。その結果、取れる選択肢が沢山出てくるため技術選定のメリット/デメリットが同じくらいな時にどの技術で行くか判断しづらくなることが増えます。結果的に技術決定者が不在な時に「技術決定者がいない時にチームの意見がまとまらない」状況が頻発していました。

一般的な解決策としてはEngineering Manager(技術面での意思決定者)を立てますが、私たちは別の方法でこの問題を解決出来ないか考えました。

技術バックグラウンドを持っているPMとしては議論に入り出しゃばらない程度に提案やファシリテーションはしますが、私はPMが技術選定の決定をしてはならないと考えています。（あくまでも現役のエンジニアが技術のエキスパートと考えているため）

この方針もあり新規事業としてスピーディーに物事を進めたい中、度々技術方針が決まらずビジネスに支障を及ぼすのでは無いかということがありました。

試行錯誤を繰り返した結果私たちは意思決定者のような組織のヒエラルキーを使わずに意思決定をし、自走出来るチームに近づける方法に辿りつきました。

解決策

私たちのチームでは「Decision Making Guideline」というものを作成し、運用しています。その結果、今まで時間の掛かっていた技術選定の効率が一気に上がり、技術決定者不在の状況でも意思決定の出来るチームになったと考えています。

解説をする前に先に作ったものをご覧ください。

新規事業でのDecision Making Guideline

新規事業は海外メンバーも多く、プロダクトチーム公用語が英語となっています。

以下が和訳したものとなります。

先にやること

大前提としてDecision Making Guidelineはルールではありません。あくまでも困った時に参考にするためのガイドラインです。ルールを設けるということはそれに忠実に従うことになるため、結果として自由を奪う可能性があります。この認識をプロダクトチームとしてこの認識を揃える必要があります。

そしてガイドラインというものは事業フェーズや外部的要因によって変動するものです。今後の展開に応じてこれは柔軟に形を変えるものであることも認識をチーム内で理解する必要があります。

Principles

ここには会社として、事業として、そしてチームとして何を重んじるかを優先順位をつけて定義しています。私たちの場合はQuipper Identitiesの一つでもある User First
を第一として Student First
を最優先として掲げました。

我々はユーザーである生徒のみなさまに対して良い学習を提供するために存在しており、それを揺るがす判断は選択肢として外れます。

このような形で Delivery Speed
Flexibility
Maintainability
をなぜそれを大切にするのかとセットで記載してあります。

これら全てに優先順位をつけ、技術方針を決める際に上から順に重んじられることの多い選択肢を選んでいくことが目的となります。

これらの優先順位を決めるのはプロダクトチーム全体でやることをお勧めします。あくまでもこのPrinciplesはチーム内で合意、または共感を得ていることが大切だと考えています。

Examples

Principleを掲げた上で具体例を上げることを大事だと思います。 いくらガイドラインを作ったところでもそれをどのように使うのか、具体例がないと実際は使いにづらく、結局使われないまま終わってしまうケースが多く発生すると考えています。

一つ例を見てみましょう。

これはとあるバグ(学習体験には影響の出ていないもの)を修正する際に、時間をかけて学習体験に影響を無い修正をするか、短期で修正する反面学習体験に影響を及ぼすかもしれない実装をするかという選択肢です。

プロジェクトに応じて何を優先するかでこの回答は変わってくるかとは思いますが、この新規事業では学習体験は絶対に譲れないものとしているため、最悪納期を後ろ倒しにしてでもクオリティを優先します。

よって前者を選択することがこのガイドラインにおいては正しい判断とします。

結果

このガイドラインを導入して以来、様々な議論にて使われてきました。

具体例を挙げると、

• iOSアプリにClean Architectureを導入する際にかかるリファクタリング工数と今実装するべき機能、どちらを優先するか
• 我々の提供しているコンテンツ（学習教材）のバリデーションテストをどこまで作り込む必要があるか

などの議論で活用されました。

まだまだチームの取り組みにおいて改善する点はありますが、技術決定者が不在の中でチームが足踏みせずに自立して物事を判断できるベースは整ったと考えています。

あとがき

正直このプロジェクトを始めてから、技術的判断を下す決定者がいないことにかなり苦戦をしてしまいました。フラットな組織を目指しているのにも関わらず、誰かの決定がないと進まないという中央集権型組織の悪いところに引っ張られてしまったと猛反省しています。

そんな中、プロダクトチームとして何をすれば自主的に物事を解決出来るようになるかを考えた結果たどり着いたのが Decision Making Guideline
となっています。

これはまだ検証段階であり、これがあれば全ての問題の解決に至るとは思っていませんが、アジャイルなチームを目指す上で是非参考にして頂けたら幸いです。