トドケールのプロジェクトカルチャー
トドケールのカルチャーを紹介するシリーズの第一弾。今回紹介するのはトドケールのプロジェクトカルチャーです。「全員で開発する」、「挙手すれば誰でもPMになれる」など一般的な会社におけるプロジェクトマネジメントとは少し異なる独自のプロジェクト運営の方法をご紹介したいと思います。
プロジェクトとは？
コンサル企業や大規模な事業会社においては割と一般的に使われるプロジェクトという仕事の単位ですが、もしかしたらあまり馴染みがない人もいると思います。そもそも一般的なようで明確な定義もないような気がしますので、ここで紹介するプロジェクトという言葉はあくまでトドケールで使う「プロジェクト」の定義だと思って読んでいただけると幸いです。
さて、ではトドケールにおける「プロジェクト」は以下の条件の場合に組成されます。
複数人による共同作業や会議体が必要な業務
決めるべき内容が多く、マイルストーンの設定やスケジュール管理が必要となる業務
改善するべき「体験」もしくは達成するべき「成果」が明確にできる業務
正確にこれらの条件がそろっていないとプロジェクトにしてはいけないというわけではありませんが、これらの条件が揃ったときにプロジェクトとして管理する対象となることが多いです。
自分でプロジェクトを組成してPMに
プロジェクトの組成はいつ、だれが決めても問題がありません。「これが問題だから改善したい！」「これをやりたいけど、一人では無理！」という業務については、勝手に自分がプロジェクトマネージャー（以下、PM）に名乗りを上げて、プロジェクトを組成することができます。
業務をプロジェクトとするために、PMは下記の内容を決める必要があり、それが決まった段階でプロジェクトは組成されます。そして、プロジェクトの運営はすべて名乗りを上げたPMが行うことになります。
テーマ
プロジェクトメンバー（誘うのもPMの役目）
スケジュール（最初は大まかな目安）
成果物（最初には決まらないことが多い）
テーマ
プロジェクトのテーマは「体験」もしくは「成果」となっています。
「体験」はユーザーからの「使いにくい」、「こういう機能が合ったらいいのにな」といったフィードバックをベースに「体験」という単位を特定し、その改善に努めます。単純な機能の追加という単位で考えるのではなく、フィードバックをもとに「どんな体験を求めているのか」、「どんな体験を提供するのか」をプロジェクトメンバー全員で話し合います。
「成果」は数字や客観的な事実の達成を意味しています。数字をベースに何を達成するのかを決めて、その達成を目指す時に利用します。例えば、レスポンスタイムの向上であったり、認証の取得や脆弱性診断の実施、KPIで測る品質の向上といった客観的な事実を対象とする場合には「成果」を対象としてプロジェクトを組成します。
プロジェクトメンバー
プロジェクトのテーマが決まったら、次に必要な人材をメンバーとしてアサインします。基本的にプロジェクトへの参加は本人の意思と現在の業務とのバランスで決まります。他の業務が忙しいということであれば、参加を見送ることもできます。
プロジェクトは新しい体験に満ちた成長の機会ですので、これまでプロジェクトへの参加を断った人はいません。しかし、プロジェクトが多すぎると、通常業務が圧迫される可能性もあるので、参加は３つが上限だと決まっています。（でないと、スケジュールが会議だらけになってしまいます。。。）
スケジュール
プロジェクトについてはフェーズとステップが決められており、PMはこれらをどのタイミングで完了させて、いつまでにプロジェクトを完結させるのかをコントロールする必要があります。以下、各フェーズとステップについて解説します。
トドケールのプロジェクトは大きく「Discovery（ディスカバリー）」と「Delivery（デリバリー）」の2つのフェーズに分かれています。ルールとしてこの2つのフェーズを合わせたプロジェクトのスケジュールが3か月に収まる必要があります。3か月を超えるプロジェクトは基本的に認められません。
Discovery Phase (ディスカバリーフェーズ)
Discoveryは提供するべき体験を定義し、それを達成するために実行するべき内容を特定して、実行可能なパーツに落とし込むことを目的としたフェーズであり、ビジネスとプロダクトの２つのチームが参加する、基本的に全員参加のフェーズです。
Discoveryフェーズは理解/定義、スケッチ、決定、プロトタイプ、テストの5つのフェーズで構成されます。フェーズの内容はデザイン思考のステップを参考にして、定義されています。それぞれのステップにおいて作成するべき成果物が決められており、これを作成することで、次のステップに進むことができます。決まった内容はGate Review（後述）を通過するまで決定事項ではなく、プロトタイピングとテストを繰り返す中で何度でも前のステップに戻ることができます。
また、このフェーズにおける最終的な意思決定においては必ず顧客ユーザーにプロトタイプを見せることでフィードバックをもらう必要があります。顧客とプロダクトチームが対話をする橋渡しとして必ずカスタマーサクセスが間に入り、垣根を超えて一体となってプロジェクトを推進します。
Delivery Phase (デリバリーフェーズ)
Deliveryは開発プロジェクトであれば、開発するフェーズであり、ビジネスプロジェクトであれば、計画を実行するフェーズです。Deliveryは開発/実行、QA、リリースという3つのステップからなり、Discoveryで決まった内容を実行するフェーズですので、微細な調整はできても、原則として内容を大きく変更することはできません。
このフェーズにおいては詳細な検討は終わっているので、基本的に実行するチームのみがプロジェクトに残ります。ビジネスが実行するのであればビジネスのみ、プロダクトが実行するのであればプロダクトチームのみが残ります。
Gate Review（ゲート レビュー）
そして、2つのフェーズの間にはGate Reviewと呼ばれるマネージャー以上の職位によるレビューが存在します。Gate ReviewではDiscoveryの中で出来上がった計画や仕様が詳細にレビューされます。このGate Reviewを通過しないとDeliveryのフェーズが開始されることはありません。
Deliveryフェーズにおいては基本的に前のステップに戻れないという前提から、Gate Reviewによって様々なフィードバックが出され、プロジェクトのメンバーは納得できるまで何度でもGate Reviewの前で考えを尽くします。
例えば、Disocveryフェーズでプロジェクトメンバーから出てきた計画が良いものであったとしても、3か月の期間に収まらないと判断する場合は、Gate Reviewにおいてフィードバックが出され、プロジェクトの分割やミニマムな機能のリリースを目指すという形になったこともあります。ただ、その結果、シンプルで使いやすい機能ができたということが何度もあったため、このGate Reviewと呼ぶレビュープロセスは有効に機能していると判断しています。
成果物
プロジェクトの目的は体験の向上であったり、成果の創出であると考えています。その中で最終的に体験や成果を測定することが難しいこともありますが、プロジェクトの進め方を標準化するために、弊社では基本的な成果物はあらかじめテンプレートとして用意してあり、改善する体験や成果の複雑性に応じて、何を用意するかも定められています。
プロジェクトの推進に当たり、何が必要かを個別具体的に特定する必要がある場合もありますが、体験や成果の改善という観点のプロジェクトにおいて共通することが多く、以下はその成果物の例です。
- プロジェクト企画書
- プロブレムステートメント、もしくはユーザーストーリー
- ユーザージャーニーマップ
- 機能一覧（開発系プロジェクトの場合）
- プロトタイプ（開発系プロジェクトの場合）
- デザインカンプ（開発系プロジェクトの場合）
- QAシナリオリスト（開発系プロジェクトの場合）
- 実行計画（ビジネス系プロジェクトの場合）
体験や成果を生み出すために何を成果物とするかはプロジェクトの内容に応じてPMが個別に決めることですが、上記の例があることである程度の指針になります。PMはこれらの資料を用意することでGate Reviewに臨み、Gate Reviewを通過することができた時点でデリバリーが完了することになります。
PMの役割
前述の通り、トドケールでは誰でもPMになることができます。改善したい体験や創出したい成果があれば、誰でもプロジェクトを立ち上げて、PMになることができます。しかし、プロジェクトが乱立することを防ぐため、PMは原則として一つのプロジェクトしか担当できません。つまり、最大でも社員の人数と同じだけのプロジェクトしか同時に存在できないことになっています。
では、具体的にPMはどんなことをするのでしょうか。以下が大まかにPMの役割となります。つまり、PMはプロジェクトの推進に責任を負い、プロジェクトを進めるために努力する必要があります。
- メンバーの招集・会議体の設定および運営
- 全体のスケジュールおよび進捗管理
- 各種成果物の作成およびGate Reviewへの提出
メンバーの招集・会議体の設定および運営
PMはプロジェクトを組成した後にメンバーをアサインし、プロジェクトを進行するためにアジェンダを決めて会議体を設定します。会議は原則といて週1回1時間で設定され、PMは会議体の進行役を務め、同時に議事録の作成を担当します。
全体のスケジュールおよび進捗管理
PMは各会議体で参加メンバーに作業を割り当て、その進捗を管理します。タスクをこなしていないメンバーがいれば会議前日までにリマインダーを送り、前に進むことができるようにサポートします。スケジュールについては関係各所と相談・調整しながら、全体感をもって決めます。
各種成果物の作成およびGate Reviewへの提出
最終的に話がまとまった時に資料と成果物をすべて揃えてGate Reviewに対して提出することはPMの役割です。すべての資料や成果物を自分一人で作るというわけではありませんが、プロジェクトの企画書はPMが責任をもって作る必要があります。Gate Reviewを通過した後はDeliveryにおいても進捗を管理する必要があります。
なぜこの方式になったの？
ここまでトドケールにおけるプロジェクトの推進方式を説明してきましたが、スタートアップにしては整っているという印象を受けたと思います。なぜここまで労力をかけてプロジェクトの詳細を整備したのかというと、過去の失敗体験に基づいて反省をしたことが理由として挙げられます。
機能しなかったアジャイル開発
トドケールはフルタイムの全従業員がわずか5名の会社です。パートタイムや業務委託を含めても15名程度であり、お世辞にも人員の余裕があるとは言えません。その中で顧客のフィードバックをもとに開発を進めるにあたって、最初はとにかく作って、リリースして、フィードバックをもらって改善してというプロセスを実行していました。
しかし、このアジャイル形式の開発を続けるには整った開発体制があることが必須でした。限られたメンバーでアジャイル形式の開発を続けた結果、プロダクトチームへのプレッシャーが強くなり、チームが疲弊するのが目に見えてわかりました。
また、法人向けサービスでは利用顧客がいる状態で一度リリースした機能に突然の変更を加えると顧客からのクレームにつながることが多く、機能に変更を加えることに躊躇いが生じ始め、アジャイル形式の開発体制が機能しなくなり始めました。
これらの理由からトドケールにおいては顧客に利用されない可能性がある機能を作ったり、一度リリースした機能を事前のアナウンスなく変更したりというシステムアップデートは可能な限り避けるべきであるという認識で一致しました。
そして、開発に入る前に可能な限りプロトタイプで顧客にフィードバックをもらい、そのニーズやユーザビリティを検証し、ミニマムなリリースで順次アップデートするという方針で開発を進めることになりました。ここまでに紹介した開発のプロセスは私だけでなく、CTOやほかのエンジニアやビジネスサイドも一緒になって試行錯誤しながら作り上げたプロセスです。
話し合いに多くの時間を割くため、開発のスピード感という意味では少しスローに感じる場面もありますが、少ないエンジニアのリソースを有効な開発に費やし、無駄な開発を避けるという選択は要件定義から実装までを含む全体として開発のスピードを上げる、かつ、顧客に価値がある体験を作り出すためにはとても有効な開発のフローになったと感じています。
事実、このプロジェクト方式による開発を進めた後には手戻りが少なく、かつ、顧客に使ってもらえる機能を提供することができるようになり、ユーザーの体験は大きく向上しています。
あえてPdMをおかない全員参加型開発
トドケールはPMFを目指すフェーズで開発をするにあたり、顧客の潜在ニーズを把握した上で、意味ある機能を提供するためにはどうしても開発にかかわるメンバー全員が顧客を理解する必要があると感じました。
また、何名かのPdMの方を面接した印象として、PdMと名の付く業務をしていた人であっても必ずしもPdMとして必要な資質や経験がある人であることを意味するのではなく、同時にそれらの資質と経験を備える人材は希少でトドケールが持つ予算で見つけだすことは難しいと感じるようになりました。そのため、トドケールではあえてPdMを置かず、プロジェクトの中で全員が機能開発にかかわることを選択しました。
この決断は開発およびビジネスの両者を長時間の会議やディスカッションに巻き込むという意味で、全員に高い負荷を強いることになった一方で、全員が顧客を理解しないでは、いい議論ができないという事実も我々に教えてくれることになりました。
結論としてビジネスを理解し、顧客を理解した上で何かを作るというコミットを持たずして、良いものはできないというのがこれまで我々がプロジェクトを運営してきた実感です。
このままずっとPdMを置かずに開発を続けていくのかどうかはわかりませんが、この方式が現時点で最善である以上、これを超える方法がない限りトドケールではプロジェクト型の業務運営を続けていくべきであると考えています。
また、プロジェクトマネジメントを多くの従業員が経験することで、本来であれば管理職相当の人材のみが経験するプロジェクト型の組織運営を早い段階から経験することで人材育成にも資すると考えています。
というわけで、トドケールにおいてはこのプロジェクト型の運営カルチャーを今後も大事にしていくと方向性が一致しています。願わくば、この組織の中からPdMに育ってくれる人材が現れてくれたら嬉しいと考えています。
最後に
今回はトドケールのプロジェクトのあり方について説明しました。デザイン思考、デザインスプリントなどの要素を取り入れつつ、現在のリソースに合わせた最適な形を模索した結果がこの形となり、現在の組織においてはとてもうまく機能しています。
同時に、人材育成の観点でも大きな役割を果たしてくれるシステムだと思っていますので、今後もこのプロジェクト型の業務運営がトドケールのカルチャー、文化になってくれると嬉しいと考えています。
この記事が気に入ったらサポートをしてみませんか？