こんなスケジュール、ありえない！
橋本：皆さんこんにちは。パラダイスウェアの橋本です。
中島：中島です。
古長谷：古長谷です。
橋本：誰プロラジオ、第4回ですね。始めたいと思います。
橋本：今回のテーマは？
古長谷：『こんなスケジュールありえない』です。
橋本：（笑）スケジュールですね。前回要件定義の話をして、そこでスケジュールの話があって、スケジュールどうですか。どうですかっていうのもあれだけど。
中島：何か、一番生活に密着してつらい原因の上から3つぐらいには入る。
橋本：（笑）かなり上位に。
中島：そうですね。
橋本：スケジュールって聞くとみんなネガティブなイメージしかないと思うんですけど、プロジェクトって3つの要素をクリアしないといけなくて、QCDっていう要素があって、クオリティ（品質）と、コスト（予算）と、あと、デリバリー（納期）っていうのがあって、このバランスをクリアしないといけないんですね。一番多分クリアするのが難しいのが納期。そして、一般的にはスケジュールって言われているところかなと思います。
スケジュールの悪い組み方
橋本：スケジュールって、バッドパターン、アンチパターンっていうのがあって、やってはいけないやり方っていうのがあるんですよ。何ですか。
古長谷：えっ。理想どおりに進むと思ってる設定。
橋本：なるほど。
橋本：中島さんは？
中島：後ろから決める？
橋本：正解です。大体、何でもそうなんですけど、プロジェクト始めるときに偉い人とかクライアントからいつごろにこれをリリースしてほしいとか、そういうオーダーってあると思います。「新しいサイトを来年の3月にリリースしてほしいんだけど」っていうお願いが来て、「じゃあ分かりました」と言って進めて、「まあ何かいけそう」みたいな。これ逆線表っていうやり方なんですけど、後ろから決めていくといろんな要素が抜け落ちちゃうんですね。
それなので、逆線表っていうやり方をやってしまうと、プロジェクトはすごく破綻をしやすいです。それはなぜかっていうと、一番最初のお客さんが「何月ぐらいにこのサイト、プロジェクトリリースしたいんだけど」っていう話をするときって、やりたいことがすごくモワモワっとしてる。そして、プロジェクト、ゴーってなると、要件定義を始めましょうと言って、やりたいことを固めていくわけなんですよね。
この中でちゃんとこのやりたいことを実現するためにどれぐらいの人が必要で、それに対してどれぐらいの予算が必要で、何人いるから何カ月働くとこれぐらいのボリュームなので、今回本当にやりたいのはここなんだけど、現実的に、じゃあ3月までできる機能とかシステムはこの辺ですねっていう合意を固めないといけないんですよね。
だけど逆線表をやるときって、『これを実現します』っていう約束の中で、ここしかできないものを作ろうとするので、途中で計画が破綻してることに気がついて、炎上して、残業ばっかりとか、徹夜続きです、みたいな世界になってしまう。
というのがあるので、順番を、本当はちゃんと要件定義して、今回のプロジェクトのスコープはここですというのを決めた上で、現実的にスケジュールを引っ張らないと絵に描いた餅になっちゃうという感じなりやすい。
中島：そうですね。そこで生まれた地獄のようなスケジュールにどんどんみんな疲弊していって、普通のスケジュールでやってればもうちょっとクオリティいいものができたかもしれないけど、みたいな感じで結局いいことがないんですよね。汲々としていっちゃって、人も疲弊して、クオリティも悪くなってって、もうどんどん負のスパイラルになっていっちゃうんですよね。
橋本：以前の回でもお話したんですけど、ITって今ものすごく複雑化しているんですよね。昔だったら例えば公式サイトを50ページ作るはずで、今実は納期が来月なんだけど、10ページしかできてません、みたいなのって、わりと人と時間を増やすとカバーできないこともなかったりしたんです。でも、システムで、「いや、実はこの機能いるんだったんだよね」みたいな話があると、その機能がいろんなところに影響しているとこれはスケジュール、徹夜して何とかなる世界ではなくて、設計のやり直しとか、場合によってはメンバーの入れ替えとかも発生しうるので、ゴリ押しがもう通用しなくなってるんですよね、時代的に。
中島：そうですね。ウェブサイトだと単純に、コーダーを増員するとかっていうだけで済むところが、全然そういうわけではないですよね。
スコープを決めてきっちり仕上げる！
橋本：システムとかアプリとかで恐ろしいのは、例えばやりたかったことが100％だったとして、60％のものが60％使い物になるかっていうと、そうじゃない。60％までしか作れてないものはゼロと等しいので、スコープを決めてきっちりつくり上げるっていうことはものすごく大事。
中島：大事ですよね。さっきのウェブサイトだったら、じゃあできてるとこから順次公開していきましょう、みたいなことにはできますけどね。
橋本：できるけど、システムはログイン抜けてるけど公開しましょうとかはない。
中島：退会できないけど公開しましょうとかできないですからね。
どうして後ろから組んでしまうのか？
中島：何でこんなに後ろから決める人が多いんですかね。
橋本：そこはね、ビジネスのやり方である意味しょうがないところがあって、何か新しいプロジェクトやりましょうと言ったときに、会社の予算を取らないといけないですよね。普通、単発のプロジェクトって会計的に言うと、固定費は会社員の人件費とかなんだけど、変動費から出すっていうのが普通なんですよね。
例えば、そこそこの会社で今年は3億円変動費がありますと。新しいプロジェクトやるので1億円必要ですっていうすごくざっくりの予算感があったとして、そのプロジェクトは、じゃあいつからいつまでやるものなのか、みたいなのって、その予算取りのときにすごく大事なんですよね。だから、最初に何も決まってない状態で「いつごろリリースしてほしい」っていう話がやっぱり出てきちゃう。
マスト感を確認しよう
橋本：あと、そのプロジェクトをいつぐらいにやりたいんだけどっていう話をクライアントとか上司から言われたら確認したほうがいいのは、そのマスト感。このぐらいでお願いしたい、が、ちょっとプロジェクトを進め始めると、なんかマストの感じになっちゃってるけど、これって本当にマストなんだっけ、みたいな話。
例えば今年、予算は1億円なんだけど、来年は増やせます、みたいな話だとすると、予算はオーバーラップしてるので、別にその会計年度に合わせる必要必ずしもなかったりするんですよ。だから、そのつもりで進めてもいいですよねっていうと、実は案外するっとオッケーだったりするので、無理してプロジェクトの意思決定者が言ってきた納期に合わせる必要はなくて、ただ、合わせるんであれば「こういうスケジュールになります。そして、その際はこれぐらいの予算感で、これぐらいのものを作れます」みたいな話ができると炎上しなくて済むと。
炎上は良い結果を生まない
橋本：炎上すると本当にね、いいことが何もないので。
中島：1個もないですよね。
橋本：1個もないです。古い体質って言うとあれだけど、「頑張ってくれている」みたいなのを求める企業とか担当者ってやっぱりいて、それは感覚的な話としては分かるんだけど、プロジェクトチームが無理をしてるとアウトプットは絶対に良くならないんで、「一所懸命やる」のと「無理する」のは全然違うから。
中島：全然違いますよ。
橋本&古長谷：（笑）
中島：何かそういうヤバイことになってきちゃうとみんなバタバタしだして、冷静な判断がどんどんできなくなってきちゃうじゃないですか。そして、結局さっきおっしゃってた、スケジュールが本当にこれでゴーしなきゃいけないのかってことすらも正常に判断できないっていう状態になってしまっているプロジェクトっていっぱい見てきたんで、実際そうなってしまいかけたときにやらなきゃいけないこととか、見直したほうがいいこと、気を付けたほうがいいことって何かありますか。
計画見直しのタイミング
橋本：残業が1カ月以上、恒常的に発生してたら一旦止めたほうが良いです。スケジュール、別の回でまた見積りの話をしようと思うんですけど、1日8時間の稼働で20日が1カ月のパッケージなんだけど、これで出せるアウトプットが見積りで「できます」ってコミットする作業量なんですけど、これがずれてると残業が発生するんですよ。
そして、1カ月とか、数週間程度だと、想定と違う事態って絶対発生するので、残業発生するということはあり得るんですけど、それが恒常的になってくると根本的なところは多分間違ってるので、一旦見直した方がいいです。多分2カ月とか残業が発生、あと休日出勤とか発生してると、これはもう炎上なので、これを人によるんですけど、続けると3カ月目ぐらいからリタイアする人が出てくる。
炎上チェックをしよう
橋本：人のストレス耐性って人によって違うので、大体PMってストレス耐性がおかしい人が多いんだけど（笑）、その人の基準で、僕は「気合いスケジュール」って言ってるんだけど、「気合いスケジュール」を引っ張ると誰もついてこなくなる。気合スケジュールで脱落者が出ると、今度はリカバリーしないといけなくて、今って別にすぐ代替要員が来る時代じゃないので、それにまた1-2カ月待ったりとかしないといけなかったり、来た人がいかに優秀だったとしても、立ち上がりまでにやっぱ1カ月から3カ月ぐらいかかるので、そのことを考えるとものすごい遅延につながる可能性があります。
だから、ヘルスチェック的な感覚としては1カ月残業が続くと危ない。2カ月ぐらいになると、もう一旦止めたほうがいいです。これを続けて、多分納期に間に合わせるっていう努力をしても、多分リスケの嵐になるので。
中島：やりきれないですよね。
橋本：炎上が発生しているっていうこと自体がもうすでに見積りとスケジュール管理能力がないという証明になっているので、別の人を立てるとか、PMに対するサポートを入れるとか、そういうことをやったほうがいいですね。
苦い思い出
橋本：何かあります？苦い思い出。
中島：苦い思い出。
橋本：昔はでも、プロマネできる人なんていなかったから、残業とか当たり前でしたよね。
中島：当たり前ですね。
橋本：若いころは本当、夜中とかね。今も夜中仕事してるんだけど、会社代表だから別にいいんだけど（笑）。うちの会社でブラックなの僕だけなんで（笑）
マネジメントはとても大切
橋本：今もうブラック企業が何とかとか、コンプラが何とかでね。
古長谷：本当数年で変わりました。橋本さんと私の出会いが、「年末仕事終わらないです」という相談から始まったりとか（笑）
橋本：（笑）
橋本：だから会社側もそういうことをきっちり考えないと、現場に無理させること自体がものすごくリスクであるっていうことを本当に考えないといけない時代になってる。今は正社員が今まで頑張ってやってきた部分を外に投げるみたいなことをやろうとしている企業も多いんですけど、そんな仕事を受ける企業ってないから、マネジメントを強化しないと難しい時代になってくる。
プロジェクトは精神的に大変
中島：人間らしい生活をしながらいい仕事を。
橋本：プロジェクトって本当に大変なんだけど、特に精神的に大変じゃないですか。今まだ世の中にないものをこれから作りますとかっていう世界になったりとか、あるいは業務改善のプロジェクトだったら、今までとは違うやり方をこれからやらないといけないですっていうのを実現させるものなので、精神的にはすごくしんどいんです。それに生活のしんどさが乗っかってきたら、もうそれは耐えられる人はいない。
古長谷：そうですね。20代のころは自分も健康で、誰も倒れず、みんなが集中するっていう体で行程を組んで、スケジュールで見積りでってなったんですけど、それだと誰か倒れるかもしれないし、トラブル起こるかもしれない、が抜けちゃうんですよね。
必ずバッファをとろう
橋本：そう、あとスケジュール考えるときに大事なのは、バッファ（余分な工数やスケジュール）っていう考え方ですね。バッファは絶対持っておかないといけなくて、プロジェクトで読みどおりに発生したことって、僕は300件ぐらいプロジェクトやってるんですけど、数件ぐらいしかなくて、絶対想定外のトラブルとか、技術的なトラブルみたいなのって発生するんですね。それを解決するための余裕を残しておかないといけなくて、それがバッファになります。
すごく余裕がないプロジェクトでも、さっき残業やっちゃいけない理由っていうのが、残業がバッファにできるからですね。「ごめん、ちょっと今回短納期で想定外のトラブルが発生したから、ちょっと残業してほしいんだよね、2-3時間ぐらい」みたいな話だと、そりゃみんな頑張ってくれるんだけど、「読みが全体的にずれてました。ズルズルいってます。いつ残業終わるか分かりません」っていうのがみんな脱落していくので、そこらへんの違いを明確にするためにも、バッファを設ける必要がありますと。
システム開発の場合は、バッファは工数の1.2倍から1.5倍なんですけど、1.2倍は相当少ないですね。だって例えば、5カ月のプロジェクトの2割って数週間とかになっちゃうので、かなりタイトです。場合によっては1.5倍ぐらいは見ておいたほうがいいですね。
終わりに
中島：というわけで。
橋本：今回はスケジュールの話ですね。
古長谷：尽きないですね。
中島：尽きないですね。また時期を見てほかの切り口からスケジュールの話もできれば。
橋本：そうですね、見積りの話をしましょう。
中島：そうですね。
橋本：ということで終わりたいと思います。ありがとうございました。
中島&古長谷：ありがとうございました。
