研究開発部 兼 クックパッド料理教室の伊尾木です。 暖かくなったり、寒くなったりと気温差が激しいですが、皆さんお体は大丈夫でしょうか。
ところで、最近クックパッド料理教室で、ビジネスモデル変更に伴うリニューアルプロジェクトを実施しました。
(ビジネスモデル変更に伴う全面リニューアル)
私はPMと開発リーダーを担当したのですが、そこで実施した「やわらかいプロジェクト管理」についてご紹介したいと思います。
炎上しそうな予感がいっぱい！
ビジネスモデル変更に伴うリニューアルって聞いただけで炎上の予感で胸が膨らみますね。 ビジネスモデルの変更だけでも大きな話なのに、システムの全面刷新まで同時に実施したので、プロジェクトとして不確定要素が多く、管理が難しいものになっていました。
20名弱（エンジニアが8名、他には営業チーム、ユーザサポートチームなどがありました）で8ヶ月程度のプロジェクトでした。一般的には非常に大規模というわけではないのですが、システムの全面刷新でしたので開発量が膨大で、クックパッド内の普段の開発規模からすると非常に大きなプロジェクトです。さらにはこの規模の管理を経験したメンバーも少なく、私がJOINした段階ではどのようにプロジェクトを管理するかもあまり明確に決まっていませんでした。
つまりは、大い燃え上がることが当初から想定できていたわけです。
じゃあガチガチのプロジェクト管理をやるのも以下の理由から難しいと考えました。
- 開発量が多く、不確定要素が多い
- 期間が短い
- そんなに管理工数を割けない（PMの私もバリバリに実装していました…）
- 文化に合わない
多くの場合、不確定要素が多いとガチガチのプロジェクト管理に走ってしまうのですが、管理のための管理が発生しやすく、結果的にプロジェクトの進行が遅くなると思っています。また、社内の普段の開発方法から大きく変わると、文化的な摩擦や、コミュニケーションミスが起きてしまうリスクも高いなと考えました。
そこで変更が多発すること前提とした「やわらかいプロジェクト管理」を実施することにしました。
やわらかいプロジェクト管理
ここでいう「やわらかいプロジェクト管理」とは、
- 開発対象をやや大きな粒度でタスク化し、各タスク間にあえて「遊び」を持たせることで、調整や変更を行いやすくする
- エンジニアの生産性を低下する管理を排除する
を実施することです。
厳密な計画を立ててその通りにやることを目標にするのではなく、変更が多発することを前提として、状況に応じて臨機応変に変更できるように管理することを目標としました。 こういうと「あーアジャイル開発ね」っと思われるかもしれませんが、ここで言っているのは開発方法論のような大きな話ではなく、それよりはもう少し細かく、タスクの管理のテクニックなどの話になります。
具体的には以下のことを実施しました。
- プロジェクト全体は月単位のタイムボックス管理
- 進捗管理は週単位のタイムボックス
- 開発メンバーとの進捗確認MTGを実施しない
- 心理的安全性を保証する
プロジェクト全体は月単位のタイムボックス管理
細かいスケジュールは立てませんでしたが、全体の流れとチームやタスクの依存関係を把握するために月単位のタイムボックス管理を行いました。
プロジェクト全体を1ヶ月程度のタイムボックスに分割して、各タイムボックスに大きな粒度のタスクのみを配置します。 そして、そのタスク間の順序や依存関係を整理して、どのタイムボックス中に何ができるかを把握しました。
各タイムボックスに作業の目安となるような目的を決めていたので（e.g. 「ビジネスモデルの詳細をつめる」「管理画面の主要な機能を開発する」等）いわゆるフェーズ管理とほぼ同じものになっていたと思います。ただ、フェーズ管理のように「今が何フェーズか」というのはあまり重要ではなく、各タイムボックスに積み残しがあっても次のタイムボックスに進むようにしました。
ちなみにここでは粒度の細かいタスクを配置しないように注意しました。このレベルで細かいタスク管理などをやってしまうと、管理工数が跳ね上がってしまいますし、柔軟な変更が難しくなってしまうからです。
進捗管理は週単位のタイムボックス
タスクの具体的な進捗管理は週単位のタイムボックスで管理を行いました。 月単位のタイムボックスに配置されたタスクを少しだけ分割して、週のタイムボックスに配置し、それらの進捗管理を週次で行うようにしました。
ちなみに、日次での進捗は追わないようにしました。よくある「タスクAは、X月Y日に終了します」というのを避けて、「今週中にAとBが終わればいい」という感じです。
1週間の中でどのように時間配分するかや、どのような開発順序にするかは、各エンジニアに任せるようにしました。 どのように働くのが効率がいいのか、いつが集中できるのかなどはエンジニアによって大きく異なるので、なるべくその人が良いと思うやり方を実施しました。
また、タスク自体もあまり細かい分割は避けました。タスクを細かくして管理してしまうと、管理のための管理が発生しやすいと考えたからです。 といっても粒度が大きすぎても管理できないので、大体1週間のタイムボックスに収まるように分割しました。
開発メンバーとの進捗確認MTGを実施しない
私はPMと開発チームのリーダーを兼務していましたが、開発メンバーとは進捗MTGを実施しませんでした（リーダー間の進捗MTGは週次で実施していました）。 進捗確認MTGは、どうしても余計な作業が発生してしまうので（進捗遅れの言い訳作りや、進捗を示すためのデータ集めなど）、そんなムダなことはしたくなかったですし、 進捗を報告させるのは一定のストレスを与えてしまうので、そういう余計なストレスも与えたくなかったためです。
そもそも開発の進捗は、GithubのPullRequestやIssueを見れば大体は把握できますし、細かい部分は現場でのメンバーの様子を見ていれば把握できるので、廃止しました。
心理的安全性を保証する
チームの心理的安全性が低いとどうしてもストレスから生産性が落ちてしまいます。また、タスクの柔軟な変更や、調整を行うには心理的安全性が高くないと、防衛的になってしまって、上手く調整できなくなってしまいます。そこで、心理的安全性を保証するように色々と配慮しました。
例えば、進捗の遅れを追求しないようにしていました。 進捗が遅れている人も、サボって遅れているわけではなくその人なりに最大限努力しているので、無理に急かしたところでメリットはありません。
何か問題があって遅れているのか、見積もりが間違っていたかだけなので、問題を取り除くか、スコープを調整する必要があります。いずれにしろ問題はメンバーではないということを意識して伝えました。
また、どんなに進捗が遅れていても、メンバーのプライベートを優先することを徹底しました。
どんなに忙しくてもライブやサッカーの観戦などの邪魔は絶対にしないようにしましたし、何時に来て何時に帰ろうが自由だという空気を作るようにしました。そもそもフルフレックスなので、当然の権利なわけですが、例えばお昼から出社する場合、みんなどうしても「すいません、お昼から出社します」というように謝ってしまいます。このような発言がある場合「謝る必要ないですし、そもそも報告も不要ですよ」と伝えるようにしました。
やわらかいプロジェクト管理のデメリット
上で述べたように、やわらかいプロジェクト管理では変更を吸収しながらプロジェクトを進めることがやりやすくなります。とはいえ、プロジェクト管理に銀の弾丸はなく、当然デメリットも存在します。
まず、リーダー（あるいはPM）の負荷が非常に高いです。言ってしまえば、メンバーに対してタスク管理をあえて甘くしているため、具体的な進捗や、リスクなどの把握をリーダーが一挙に把握し切る必要があります。 つまりは、リーダーが全体を常にオーガナイズして、各メンバーの生産性を高める手法だとも言えます。
今回の場合でいうと、私が開発の全てをコントロールしていました。いわゆる、トラックナンバー1の状態で、非常に危うい状態だっと思います。
また、心理的安全性を高めるための様々な配慮も必要になります。プロジェクトが佳境に入っても、リーダーは常にポジティブな空気を作る必要があり、一般的には簡単なことではないと思います。
このため、プロジェクトの規模がある程度大きくなってしまうと、この手法は適用しづらいと思われます。
さらには、ある程度メンバーを信用して管理を行うため、自走できるメンバーがいない場合も上手く回らない可能性があります。
終わりに
クックパッド料理教室のリニューアルプロジェクトで用いた「やわらかいプロジェクト管理」についてご紹介しました。何かの参考になれば幸いです。
