こんにちは。ウォンテッドリーのグロースチームでプロジェクトマネジャーをしている原(@chloe463)です。技術的な専門領域はWebフロントエンドです。
このブログではプロジェクトマネジメント、タスクマネジメントの方法について紹介します。プロジェクトマネジメントの方法はプロジェクトマネジャーだけが知っていればよいというものではなく、関係するメンバーそれぞれも知っておいて損はない話です。むしろ全員が知っておくことでコミュニケーションがスムーズになったり、プロジェクト進行がスムーズになる可能性を秘めているものです。「自分には合わない章かも…」と次の章までページを進めようとしたあなたも、ぜひ一度目を通してみてほしいです。
この章で紹介する話はウォンテッドリーの技術発信をしているPodcastでも一度話している内容になります。そちらも視聴してみてください。
この章で紹介する内容はもともと社内のAll hands meetingで社員向けに共有したものがベースです。発表当時はプロジェクトマネジャーという役職が明示的なものになってから期間が浅い時期でした。実際どういうことをやっている役職なのか分かりづらいという課題があったと認識していたため、社内に向けて役割の紹介をしました。
また、新卒入社から数年目のメンバーにむけて何かヒントを残せればよいなとも考えていました。ウォンテッドリーでは新卒のメンバーであってもある程度大きめの抽象度高いタスク(やることが明確ではなく不確実性の大きいタスク)を渡されることがあります。そういったタスクを渡されたときに、この紹介内容をもとにスムーズに進行できるようになってくれたら嬉しいなと考えました。
プロジェクトマネジメントのノウハウはマネジャーだけが知っていればよいというものではなく、プロジェクトに関わるメンバー全員が知っておくほうがよいものです。マネジャーからメンバーに対してこう動いてほしい、こうコミュニケーションをとって欲しいと一方的に訴えかけるだけでは非対称性があり続けるだけです。メンバーもプロジェクトマネジメントについての知識をもっておくことで、適切なコミュニケーションが取れるようになるはずです。「この情報を今伝えておかないと進行がまずいことになる」「この進行のままでは期間内に完了することは難しいか、見積もりの変更を伝えよう」といった感じです。プロジェクトマネジャーだけが進行について責任を持つ、管理するだけではなくプロジェクトに関わるメンバー全員がオーナーシップを持って取り組めるようにこのノウハウを知っておいてほしいなと考えています。
ウォンテッドリーにはもともとプロジェクトマネジャーという役職は存在していませんでした。もちろん明示的なタイトルを冠していないが実態としてプロジェクトマネジャーをしている人は存在していました。もともとはSquad Leader (チームリーダー) が複数の役割を持っていました。複数の役割とはプロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントなどです。その結果Squad Leaderの持つ責務が肥大化しすぎてしまったため、それを分散させようという改善の一貫として、プロジェクトマネジャー、プロダクトマネジャーという役割がSquad Leaderとは別の人へ割り当てられるようになりました。(完全に切り離されたわけではなく、Squad Leader兼プロダクトマネジャーという人も存在します。) 役割を明確にSquad Leaderから分散させたことによって、それぞれの責任範囲が明確になりプロダクト開発やそれに関わるコミュニケーションがスムーズになったように感じています。
誤解を恐れずにプロジェクトマネジメントの極意は下記の3つになると考えています。
これらを繰り返し、プロジェクトメンバーやステークホルダーとコミュニケーションしながら、プロジェクトの完了を目指します。もちろん、これ以外にもやることはあります。それらについて説明します。
まずはそのプロジェクトの目的、何のためにやる必要があるのか、を把握します。チームメンバー全員の目的意識が揃わないと良いものは作れません。
また、作ろうとしているものがその目的を達成するための手段として最適か、という視点で考えるためにも目的をしっかりと確認しておきましょう。
エンジニアをやっていると、作ること自体が目的になってしまうことがままあると思います。しかしながら、本当に提供するべき価値は何か、解決するべきユーザーの課題は何か、という目線を忘れないようにしましょう。
これから解決したいユーザーの課題は何で、今から作ろうとしているものでそれは解決できるのか、というのをプロジェクトのスタート時にチームメンバーで認識をあわせましょう。
目的をしっかりと把握したら、作るものの仕様の整理、スコープの整理をしましょう。いきなり作り出すのではなく、しっかりとどのようなものを作る必要があるかを整理し、どこからどこまでを範囲とするのかを決めましょう。
たとえば、ウォンテッドリーにはメッセージという機能があります。企業と候補者間でメッセージのやりとりをするための機能です。この機能に改修を入れるという際、言葉以上に広い範囲が含まれます。
メッセージ機能を改善したい、と一言に言っても実はこれだけの範囲が含まれます。そのうち全部を改修するのか、それともWebしか対応しないのか、といった範囲が考えられます。
こういった範囲を最初に定義しておかないと、プロジェクト進行の途中で「あれ、もしかして別のところにも手を入れる必要があるのか？ その場合時間や人が足りないぞ…」ということが起こり得ます。適切なリソース確保やスケジュール管理のために「何をどこからどこまで」というのをしっかり把握するようにしましょう。
またステークホルダーの把握と交渉も忘れないようにしておきましょう。ここでいうステークホルダーとは開発しようとしている機能に関わるプロジェクト内外の関係者のことです。先程のメッセージ画面の例でいえば、開発チームのエンジニアやデザイナーの他にも、ビジネスチームのメンバーが上げられます。採用管理画面の改修は、契約企業の業務に直接の影響が及ぶかもしれないため、企業と直接やりとりをしているビジネスチームのメンバーにも知っておいて貰う必要があるためです。他にもたとえば、契約プラン周りに手を入れる必要がある場合はコーポレートチームや法務といった部署の人たちがステークホルダーとなり得ます。
なぜこういったステークホルダーの把握や折衝が重要なのでしょうか？ それは開発者の目線だけては分からない、各部署・各メンバー目線での利害やリスクを把握するためです。開発者が良かれと思った機能改修であってもビジネスメンバーから見ると許容できない変更 (運用に重大な影響が発生してしまうなど) であるかもしれません。法律と照らし合わせてNGになる可能性 (特にウォンテッドリーの場合は個人情報の扱いなどでリスクがあります) があったりします。こういったリスクが開発後期になり出来上がってきた段階で発覚していまうと大きな手戻りが起きてしまったり、最悪の場合プロジェクトそのものが中止になってしまったりしまいます。こういったリスクを避けるためにも初期段階でステークホルダーを把握し、それぞれと折衝をしておくことが重要です。
ここまででだいぶやるべきことが明確になってきたはずです。ここからは実際に手を動かせるように分解をしていきます。「早く手を動かしたい！」という気持ちは分かりますが、まだその気持ちは抑えてください。この状況で手を動かし始めるのは、ホールケーキを目の前にしていきなり顔を突っ込むようなものです。
ホールケーキを目の前にしたときまずやるべきことは、包丁を取り出して何等分かに切り分けてショートケーキの形にすることです。そして一人前のショートケーキにした後、フォークなどを使って一口分にしてから口に入れて味わいます。プロジェクト遂行に関してもこれと同じようなことをします。
フェーズ分解とタスク分解
まずはざっくり大きなフェーズに分解します。ホールケーキでいうと最初に半分・そのまた半分で四等分くらいにするイメージです。
それぞれのフェーズについてさらに分解をします。タスク分解は好きなタスク管理ツールを使用してください。GitHub ProjectsやJIRA、Googleスプレッドシートでもよいと思います。著者はスプレッドシートで管理するのに慣れているため、Googleスプレッドシートをよく使用しています。
タスク分解はなるべく細かめに、誰が読んでも分かるようにしておきましょう。自分だけが分かればよい命名のタスクはよくないです。ローコンテキストに、チーム外の人が読んでも分かるレベルのものを目指すとよいと思います。こうすることで仮にプロジェクト外のメンバーがヘルプに入らないといけなくなった場合でもスムーズに合流できる可能性が高まります。あとはシンプルにタスクについての理解の解像度が上がり、別のタスクを作ったほうがよいということに気づけたりもします。
見積もり
タスクの分解がある程度できたら、今度はそれらについての見積もりをします。大体これくらいの時間を使ったら終わるだろうという予測を立てます。このときに楽観的な予測と悲観的な予測を立てておくとよいなと考えています。楽観的には1時間だが、悲観的には（当初予期しなかったエラーが発生した、別の考慮が必要だったなどで）3時間かかるかも、といった具合です。それぞれにある程度のバッファも設けておくとよいでしょう。前段でタスクの分解を細かめにやっておくと、ここでの予測の精度が上がります。ざっくり抽象的なタスクでは予測が難しいですが、具体度が上がって何をやればよいかが明確になればなるほど、予測の精度が上がるはずです（もちろん予測する人の練度にも依存するとは思いますが…）すべてのタスクについての予測ができたら楽観的・悲観的な予測の合計値を計算します。合計値が分かると、幅を持った完了日が予測できるようになります。「大体◯月◯日からX月X日までの間に完了しそうだ」という見積もりが得られます。
不安ごとの洗い出し
タスク分解のときにはそれぞれについての不安ごとも書き出しておきましょう。これが不確実性を排除していく活動につながります。あるタスクについて、「これを完了するためには◯◯という事前情報が必要」「これは◯◯さんとネゴっておく必要がある」「◯◯というライブラリを使ったらできそうだが使用実績がなさそうだ」といった具合です。もちろん誰かとネゴっておく必要がありそうだ、と気づいたらそのまま別のタスクとして積んでおくのがよいでしょう）。ここの不安ごとの解消がプロジェクト進行をスムーズにしたり、見積もりを正確にしたりということにつながります。
タスク分解はどこまでやったらいいのか？ という質問があると思います。どこまでやっても網羅的に洗い出せているか不安と感じることもあるかでしょう。その不安はもっともです。ただし、どこまで網羅性を高めようとしても結局プロジェクト進行の中で、新しく生まれるタスクというのは発生します。初期段階では気づかなかった要素や、ステークホルダーとのやりとりの中で新たに発生することなどで、あとからタスクが追加されていくことはよくあることです。タスク分解は初期段階では完全に網羅できない、という前提のもと都度振り返りを行い、プロジェクトの状況とタスク表を見比べながら都度アップデートしていきましょう。
とはいえ初期段階で、網羅性が高いことに越したことはありません。ペアでタスク分解の作業をしてみたり、自分よりも経験のある方と一緒に作業してみることで、気づかなかった目線というのに気づける可能性もあります。そういった取り組みによって網羅性を高めることはできるかなと思います。
「不確実性」とは誤解を恐れずにざっくり言い換えると、そのプロジェクトを進める上で「分からないこと、決まっていないこと」です。
「分からないこと、知らないこと、決まっていないこと」があるとそれに関連するタスクの見積もりが大きくぶれます。実例を出して説明します。ある機能のリニューアルの際、クレジットカード番号のトークン化をするためにStripeというサービスを使用する必要がありました。しかしながら、著者自身にはそのサービスとライブラリの使用経験がなく、また社内でもStripeのReactライブラリ(react-stripe-js)の使用実績がありませんでした。そのため、「カード番号入力フォームを作る」というタスクについてどのくらいで完了するのかという見積もりが非常に難しい状況でした。この課題を解決するべく、まずはreact-stripe-jsについて調べ、ミニマムな実装を作ってみることにしました。CodeSandbox上に極小の環境を作り、次のこと確かめることを最優先しました。
これは、実装の最初期段階で行いました。もしreact-stripe-jsが提供する機能では、要件を満たせないということがわかった場合、UIデザインのやり直しや設計のやり直しなど、いろいろな手戻りが発生してしまう可能性が考えられたためです。見積もりを正確にする以外にも、他メンバーや他工程への影響を最小限に抑えるという面で、不確実性を減らすための活動というのは意味があります。
不確実性を減らす活動は前述のとおり、ミニマムに動く概念実証を作るという手段以外にも下記が考えられます。
タスク分解をし、見積もりをして、実際にプロジェクトが手を動かすフェーズに入ってからもプロジェクトマネジメントは重要です。毎日のスタンドアップミーティングや、週次のミーティングで進捗をトラッキングしましょう。計画と実際の進捗を見比べ、大きなずれがないか、新たに発覚した不確実性がないかなどを把握していきます。
綿密にWBSをして、いくら良い計画を立てていたとしても実際に動いてみるとまったく計画どおりにいかないということが分かると思います（以前そういう経験をしたという方も多くいらっしゃると思います）。重要なのは、そういったズレをそのまま放置しないことです。放置しないというのは、スケジュールどおりにいくようにプロジェクトメンバーに無理を強いて期間内に消化できる以上のタスクを与えることではありません。タスクの進捗を妨げている要因を探り、その障害を取り除く活動をします。それはたとえば、下記のような活動です。
ズレは時間が経つにつれて大きくなっていき、より修復が難しくなっていきます。小さなズレの段階であれば、修正は容易です。日々ズレを把握し、小さなズレの段階で改善アクションを取れるようにしましょう。
見積もり・予測はあくまで予想でしかありませんし、所詮は人間がやることですので、100％スケジュール通りにいくということが珍しいと考えておいたほうがよいです。ただし、人は間違えるという前提にたって考えるからといってスケジュール遅延などをそのままにしておいて良いわけではありません。できるだけズレを小さくするような活動を日々取るようにしましょう。
プロジェクト進行がうまくいっていない場合、どのようなアクションが取れるでしょうか。先述のアクションをもう少し具体的に考えてみようと思います。
ここでは大きく、その成果物のリリース日が動かせる場合と動かせない場合に分けて考えてみます。
まずリリース日を動かせる場合についてです。事業会社での機能改善等であればこのケースに当てはまると思います。結論から言うとリリース日を動かしましょう。ただし、単純にリリース日を後ろに倒すだけではなく、進め方の改善も同時に必要です。当初のスケジュール通りにいかない、トラッキングし続けたがズレが修正できていない状況というのは、進め方のどこかに改善の余地があるということです。ここでいう進め方とはタスク分解や見積もりの仕方であったり、アサインであったりします。既存の進め方でうまくいっていないのであれば、その進め方で続けてもズルズル延びてしまう可能性があります。そのため一旦立ち止まって何がうまくいっていないのか、進め方で改善できることはないのか、ということを考える必要があります。下記のようなコミュニケーションやアクションが取れるとよいと思います。
次に、リリース日を動かせない場合について考えます。プレスリリースを事前に出していて、明確な日付がコミットメントとして出ている場合です。この場合はリリース日をずらすことは簡単にはできないため上のような改善手段は取れません。考えられる1つの手段はプロジェクトに関わるメンバーの数を増やすことです。残りの日数とタスク量を鑑みると明らかにオーバーする、終わらないと確信したら、ヘルプメンバーを投入しましょう。もちろん残り1日になってメンバー投入というのは不可能だと思いますので、これもズレが小さいうちに打診できるとよいです。またはタスク分解と見積もりの段階で分かると尚良しです。プロジェクトの後期になってしまうと、新規メンバーのキャッチアップにかかる時間というのが発生してしまうため、なるべく初期段階から共通認識を獲得できるように動けるとよいと思います。
新規の人員を投入できない場合には、プロジェクトスコープの見直しをしましょう。すべてを作ることが期間内に難しいのなら、リリースの時点では必要ない機能の優先度を下げ、必ず必要になる機能を優先して作っていけるようにしましょう。機能ごとに以下の3つにレベルを分けて、対応するのがいいかと思います。
ステークホルダーとはプロジェクトの成果に関心のあるプロジェクトチーム内外の関係者のことです。こういった人たちは実際手を動かさないとしてもプロジェクトの進行に影響を与えます。それぞれの利害があるため、うまく調整する必要があります。
たとえばウォンテッドリーの場合、契約企業が使用している機能の大きな改修の場合、お知らせの公開やヘルプページの修正が必要になります。そういった作業はエンジニアではなくカスタマーサポートチームのタスクとなります。伝えるのが直前になってしまってお知らせやヘルプページの準備が、実際のプロダクトリリースから遅れてしまっては良くありません。あるいは契約企業のワークフローを考えるとその機能の変更は許容できないといったこともあり得るかもしれません。チーム間の共有が遅れ、リリース直前に「その機能はそのままでリリースしないでください」ということになってしまったら、大きな手戻りもしくはプロジェクト自体がポシャってしまいます。
また要注意なのは上記のように普段一緒に仕事をしないようなチーム外のメンバーが関係する場合です。同じチームで仕事をしていると、ほとんど同じようなタイムラインで動いておりミーティング等の時間を合わせるのも容易です。しかし別の部署で働いているメンバーの場合そういってタイムラインが共有されていないことがあります。タイムライン以外にも前提となるドメイン知識の差や違いもあったりするため、認識を揃えるために必要なコストが同じチームで働いているメンバーにかかるものより大きくなってしまいます（エンジニア組織とビジネス組織の間、エンジニアとコーポレート組織の間、などです）。そのため大きな手戻りの発生をなくすためにはなるべくプロジェクトの初期段階でステークホルダーの洗い出しをして、早めの折衝をしておきましょう。
プロジェクトメンバー間のコミュニケーションについて、自分の経験からこうしたほうがよいだろう、こうしたらうまくいったというものを紹介します。まず大原則として "The bad news first/fast"、悪いニュースを先に・速く伝えるということを意識しましょう。日々のトラッキングのセクションで紹介したように、小さいズレのうちから改善の手立てを打っていけばリリースが大幅にずれるということはなくなります。小さいズレのうちから改善をしていくためには、悪い情報を早い時期に把握している必要があります。もちろんプロジェクトマネージャーとしてそういった情報にリーチできるように努めますが、実際に手を動かしているメンバーでないと気づけない細かい課題というのがあると思います。そういったことはできるだけ早めにプロジェクトメンバーで共有できるようにしましょう。
プロジェクトマネージャー視点でいうと、進捗はもちろん気になりますが、進めづらいことや困っていることも気になります。メンバーだけでは解決できない課題を取り除くのもプロジェクトマネージャーの仕事です。なにか気になることがあっても「順調です」というふうに伝えたほうがよいのかな、とメンバーは思ってしまうかもしれないですが、気になること・不安ごとは積極的に共有しましょう。特に新卒で入ったジュニアメンバーがつまづくことはある程度当然なので遠慮しないでほしいなと自分は思っています。中途であっても、入社してすぐの場合はドメイン知識がなかったり、前職とは違う進め方で戸惑うことが多いはずです。それも遠慮しないでほしいと思っています。
なにかうまくいっていないときには、個人のスキルのせいにするのではなく、進行の仕方やワークフローのほうに目を向けましょう。人間なので、なにか悪いことがあると特定の個人のせいにしがちですが、そこは一旦落ち着いて俯瞰で物事を考えてみましょう。また個人のスキルのせいにしてしまうと思考がストップしてしまいます。「○○さんの実力が足りないから進捗が出ないのだ」ではなく、それをカバーする進行の仕方を考えたり、○○さんがやりやすいやり方やタスク分解を考えたりということをしましょう。もしかしたら、前提としている認識が違っているだけの可能性もあります。またはコミュニケーションミスが起きていてお互いが考えていることが違っていたということもありえます。開発に便利なツールの存在を使うべきではない言葉なので修正してくださいだけだった、開発イテレーションを回すのが非常に難しい箇所だった、ということかもしれません。バイアスを取り除いて、個人ではなく進め方やツール、自分の行いまで目を向けて改善できないか、ということを考えましょう。
ここまでプロジェクトマネジメントについて自分の経験からこうしたらうまくいくよというtipsを述べてきました。プロジェクトマネージャーがただのスケジュール管理おじさんではないということが伝わっていたら幸いです。だいぶ端折っている箇所や、もっと細かく言及できる箇所もあるとは思いますが、エッセンスは伝えられたのかなと思います。冒頭にもお伝えした通り、マネージャーだけがこれを知っていればよいかというとそうでもありません。特にコミュニケーション周りなどはメンバーの人に知っておいてもらいたいことです。
ウォンテッドリーでの開発に興味が湧いたという方はぜひカジュアル面談に来てください！
みなさんが今関わっているプロジェクトや、次のプロジェクトの進行がスムーズにいくことを願っています。
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
