予定日にリリースできない原因は「スケジュール管理の甘さ」　新規事業開発のPMに伝えたい、予定管理に必要な3つのこと

成宮氏の自己紹介

成宮吉将氏：事前（告知）とタイトルが変わっています。書いていくうちにスケジュール管理の話で筆が走ってしまったのでスケジュール管理の話をします。それでは始めたいと思います。

よろしくお願いします。期待値とずれていたらごめんなさい。コメントとかで後で補足します。Relicの紹介は先ほど北川さん（北川祐希氏）がしてくれたので、飛ばしますね。

私の自己紹介をします。もともとNECで技術営業やシステムエンジニアをしていました。みなさんが使っている携帯電話の電話網に使う、馬鹿でかいスイッチやルーターを売る仕事をしていました。

そこからたまたま社内新規事業のPM（プロダクトマネージャー）に移って、「あぁ、おもしろいな。社内新規事業、おもしろいな」と思いました。（そのまま）PMをやりたいなと思いつつ、ちょっとエンジニアリングを勉強したいなと思って、フロントエンドエンジニアとしてRelicに入りました。数年経験して、今またPMに戻っているかたちになっています。

今はプロダクトディスカバリー事業部に所属していて、プロダクト開発を通して「どうしたら新規事業の成功確率が上がるか」を特に考えながらプロダクトを作るのを主な仕事にしています。

基本的な業務の内容としてはPMに近いんですが、単純に開発するだけじゃなくて、新規事業がより成功するためにはどうするか考えながら、クライアントの方々と一緒に開発することが多いかなという職業です。

新規事業開発のPMに求められること

（スライドを示して）「新規事業開発のPMに求められること」と最初に大きい題目で書かせてもらいました。僕は最終ゴールはやはりプロダクトを伸ばすことなのかなと思っています。

プロダクトを作る以上はプロダクトを伸ばしたいし、クライアントワークだとしても、一緒にプロダクトを伸ばすところまでコミットする勢いでやることが、私やRelicのミッションです。

ただ、POの要望をプロダクトの形にするということが大前提にあるのかなと思っています。大前提として物をちゃんと作れないと伸ばす以前の話になってしまって、それどころじゃないプロダクトやプロジェクトを私自身も何回も見てきました。

なので、やはりPOの要望をプロダクトの形にする。もっと言うと、ある意味リリース予定日にリリースすることが目標なのかなと思っています。今回、ここを特にスコープとしてまず発表したいと思います。

なぜリリース予定日にリリースできないのか？

（スライドを示して）では、なぜリリース予定日にリリースできないのか。みなさん、思い当たることがこれまでの経験でもいろいろあるかなと思っています。私も、ここを語るといっぱい話せることはあるんですが、やはり最初によく挙がるのは（スライドの）上の2点で、スケジュール管理ができていないことが多いのかなと思っています。

3番目もよくありますね。後半になって「ここ直してください」と言われるということ（に対して）は、どういう手が打てるのかと（いうことを）話し始めるといろいろあります。

今回は（それについては話さず、）特にある意味PMの初歩の部分でもあるような、よく言われる「スケジュール管理ができます」と（言えるということは）はどういうことなのかを、もう少し分解して話せればと思っています。

特に開発スピードが思ったより遅かったり、見積もりが甘い、要件定義が遅れるというところで、（その時に）どういうことを考えているのかを発表します。

細かくスケジュールを作る

簡単に話をまとめました。スケジュール管理に必要なことを3つ書いています。スケジュール周りの大事なことを上から順に、まずなによりスケジュールを作る。次に、そのスケジュールを常にチェックする。3番目に、スケジュールの共有と書いています。

これだけ見ると「それは当たり前だろう」という話もあるかもしれないので、もう少し、「なぜこれが大事なのか」が腹落ちできるように。よく言われるんだけど、あらためてなぜこれが大事なのかがわかるように今日は話せればと思います。

（スライドを示して）まず「スケジュールを作る」ですね。どういうことかというと、新規事業開発では、暫定の情報や仮説でも良いので、プロジェクトが始まったらすぐスケジュールを作ったほうが良いと自分は思います。

ウォーターフォールで、言われたとおりに仕様を作るものだったら（作らなくても）いいかなと。それならそれでよいかなとは思いつつも、新規事業はアジャイルの要素が入ってくると思います。決まっていないことが多いと思います。

そういう時に、まずとりあえずは仮説でスケジュールを作ります。自分がそのプロダクトをリリースするとして、必要なタスクを漏れなく洗い出す勢いで作ります。実装タスクも3日以内のタスク、ページやAPI単位でタスクにして詳細化します。

（スライドを示して）最初のスケジュールは本当にこれぐらいです。要件定義、実装テストぐらいしか決まっていないと思いますが、それをこういった単位で、商品一覧実装やコメント表示、コメント登録機能などで（スケジュールに）落としていきます。

（スライドを示して）「これをやると良い」とよく言われます。なにが良いのかというと、すごくよくある（ことな）んですけど、いろいろ要件定義を話していて（スケジュールが）遅れてしまったとします。

その時にスケジュールを細かく作っていないとなにが起きるのかっていうと、「ここが遅れました。じゃあ間に合いますか？」となった時に、間に合うか間に合わないか、あまりわからない。どれぐらいリスクがあるのかわからないことがあるかなと思います。

なので、なんとなく打ち手も「あぁ、実装をちょっと早めてがんばります」みたいな、曖昧な施策になりがちかなと思います。みなさんにも思い当たることがあるかなと思います（笑）。

スケジュール後半で、実装をしていくうちに「あっ、間に合わない」ということに気がついても、プロジェクト全体で見ると対応可能な時間が短くて、なかなか施策を打つ時間がなくて結局間に合わないみたいな経験がある方もいるかなと思います。

（スライドを示して）スケジュールを細かく作っているとなにが起きるか。例えば、細かくスケジュールをあらかじめ仮置きでも置いておくと、予定より要件定義が遅れてしまった場合、ちょっと延びても、延びた分を「あっ、ちょっと初期リリース、コメント編集機能をいったん作成しなければ間に合いそうだな」ということがパッと見でわかるかなと思います。

こうすると「コメント編集機能をなくせば間に合いそうなので大丈夫です」という具体的な施策の検討が早い段階でできます。また、編集機能をなくせない場合でも、他の施策を打てますね。

例えば人を増やすとか、リリーススケジュールを遅らせるとか。この図だと、いろいろな施策を検討する時間が先ほどの倍以上あるかな。実際はもっと長いと思います。

そういうことが打てるので、仮置きでもいいので、まず細かくスケジュールを置いておくと、いろいろな検討ができるかなと思います。

スケジュールを常にチェックする

（スライドを示して）2点目はスケジュールを常にチェックすることです。ちょっとごめんなさい。いつの間にかビジーなスライドになってしまいました。

スケジュールは常に変わります。僕はスケジュールは生き物かなと思っています。常に変わるので、少なくとも週1回は見直したほうがいいと思っています。

特に（見直しの時に）重視することは、仮で置いたスケジュールと比べて、開発スピードが問題ないかということです。そしてプロダクトオーナーの方。誰かしら「こういう機能を作りたい」という方がいて。自社サービスなら社内だし、クライアントワークだったらクライアント先だと思いますが、その要求度合いが当初の見積もりの予定と差がないかを常に見たほうがいいと思います。

例えば、仮でやっておいて最後にバッファがちょっとあるかなと（スケジュール）置い（てい）た時に、「当初の想定より機能や仕様が多そう」「意外に要望があるな」「思ったよりリッチなことを求められているな」となってスケジュールを置き直してバッファがなくなっちゃったら、この段階で早めに関係者に共有するほうが良いと思います。

開発向けだったらちょっと仕様を調整して、「そんなにリッチに作らなくていいので、もう少し簡易に作りましょう」とか。仕様としては変わらないけれど、裏側のロジックでより細かく作る部分があると思いますが、そこをちょっと落としたりとか。

PO向けも、仕様調整という言葉は一緒なんですが、例えば先ほどみたいに機能を落とすとか。そういったところで早めに（対策を）打てるかなと思います。

さらに、「初めてのメンバーでやって（いるから）、開発スピードが読めなかったけど、やっていくうちに、開発スピードが想定より遅いなということがわかってきた」（という）時に、リリースを大幅に遅延してしまうことがわかった時点で……。先ほどまでは注意報でしたが、（この場合は）警報かなと思います。

大きい施策だとすると、体制を強化するとかリリース日を調整するとか、早ければ早いほど検討できると思うんですよね。1週間前に「ちょっとリリース日をずらしてください」というのは難しいと思いますが、「何ヶ月前とかだったら検討できますよ」というのもよくある話だと思うので、スケジュールを常にチェックして、こういうことが起きないようにするのが大事かなと思います。

スケジュールの共有

（スライドを示して）3つ目はスケジュールの共有ですね。個人的にはこれはすごく大事な話かなと思います。まず大前提として、プロジェクトのメンバー、PMだとPMの方が一番プロジェクトに責務を持ってスケジュールを守っているんですが、みんなプロジェクトを成功させたいと思っているし、スケジュールを間に合わせたいと思っているんじゃないかなと思います。

一方で、やはりスケジュールがわからないと、どれぐらいのペースで進めたらよいかわからないのが現実かなと思います。マラソンと一緒で、ある意味スケジュールはペースメーカーで、ペースメーカーがいないとペース配分ができません。

開発でいうと、機能を作り込みすぎちゃう。開発は、やろうと思えば気になることは無限にあると思うので、作り込みすぎちゃったり、「こういう機能を入れたら便利だな」ってやりすぎちゃったり。あとペース配分がわからないので、「実はこれが遅れていたんだ」ということが誰もわかっていないということがあるかなと思います。

あと、関係者に共有するというのもありますね。開発メンバーもやはりスケジュールが遅れているとわかると、いろいろアドバイスをくれます。

POの方（として）も「間に合うならこういう機能を入れてほしい」というのは、プロダクトに対する想いがあるので当然出ると思います。しかし、やはり最優先は（予定日）リリース（することに）したいので。そこのスケジュールが見えていると、スケジュールに無理な影響が出る要求は出づらくなるかなと思います。

なので、なるべくここの共有は忘れずにしたほうが良く、PM1人で抱えるんじゃなくて、みなさんと常に「今こういう状態ですよ」「これぐらいの健全度ですよ」というのを共有したほうがよいかなと思います。