見出し画像

「現実を直視する」進捗管理の考え方と、遅れの取り戻し方

だらねこ

進捗管理。何かを作る仕事に身を置く人は、必ず耳にする言葉でしょう。

進捗なんて単語、もう聞きたくないよぉ！

という人もいると思います。私も、聞きたくないです。嫌いです。広辞苑からその言葉の存在自体、抹消されても良いです。

とはいえ、進捗管理をしないとプロジェクトは崩壊します。やらねばいかんのです。どんなに嫌っていても、大事なものであることには変わりがありません。広辞苑から抹消されたら困ります。

ということで、ここでは進捗管理をどうやっていけばいいのか、どう扱って行けばいいのかを、普段私なりに考えていることを共有していきます。

大きく分けて以下の3篇で解説をしていきます。

【考え方】　進捗管理に対する考え方、捉え方
【見積もり】どうやってタスクの見積もりを行うのか
【対処】　　遅れた時、どう対処していけばいいのか

ちなみに、私はフリーでソーシャルゲームのゲームデザインに関わってます。基本的に話もそっち寄りの形（例を出す時とか）で話しますが、基本的には色んな業界で同じことが言えるかなーと思います。

◆考え方：進捗管理で何を目指すのか

進捗管理をやらなきゃ！！！

とか言ってもですね。なんとな～くやったところでそんなに意味はありません。皆さん、この辺りってちゃんと考えていますか？

何のために進捗管理をするのか、ちゃんと理解した上でやらないと曖昧で意味のない進捗管理になってしまいます。そして意味のない進捗管理に時間を割くという、最高に無駄な時間を過ごすことになる。素晴らしいですね。


▼プロジェクトは遅れるし、問題も起きる

なので進捗管理をするのか、考える際に

進捗管理は、プロジェクトが遅れないように、問題が起きないようにするために行う。

と思っている方は、認識を改めた方が良いと思ってます。そんなことできないので。

「遅れ」は無いに越したことはないんですが、どうしても発生します。プロジェクトを進めていく上で、

・急な体調不良
・考慮になかった予定外の作業
・上からの急なぶっこみ（スバラシイ鶴の一声！）
・緊急のバグ対応

などなど、その人の能力に関わらず「遅れ」が発生する様々な要因は襲ってくるものです。プロジェクトの期間が長ければ長いほど、発生する確率は上がるでしょう。

そうした前提に立つと、

× 問題がおきないようにする

ではなく

〇 問題がおきたらすぐに対処して被害を最小限に抑える

と考えた方が、最終的に上手くいきやすいです。問題は起きちゃうけど、その問題を小さくすることはできる。

じゃあこれ、どうやってやりましょうか？


▼問題をより速く察知することが鍵

進捗の遅れと言うのは癌のようなもので、放っておくとどんどんプロジェクトを蝕んでいきます。例えば

①リリース半年前に、このままだと予定日に完成しないことが発覚した
②リリース1週間前に、このままだと予定日に完成しないことが発覚した

と言う状況であれば、対処できる方法が①と②で雲泥の差があります。1ヶ月あれば取り戻す方法があったとしても②の段階になってしまったら使えないのです。そうなると力技に頼るしかありません。デスマーチとかデスマーチとかデスマーチとか。

逆に言えば、早期発見できれば対処も楽です。より適切な方法で、平和に解決できます。デスマーチなんてしなくて良いのです。

なので恐れるべきヤバい状況は↓の状況。

・遅れている、問題が起きていることに気が付いていない

なので、↑を防ぐために問題が無いか監視をする必要があります。その監視の事を、進捗管理と呼ぶわけですね。


▼進捗管理は何のためにやる？

さて、以上を踏まえて、何のために進捗管理をするのか再定義しましょう。私としては

①状況把握　：遅れや問題をより速く察知する
②問題の縮小：状況に合わせて早めに対応して問題を小さくする

のためにやると思っています。


------------------------------------------------------------------


◆考え方：良くない進捗管理とは

多くのプロジェクトで進捗管理は行われていますが、多くのプロジェクトで進捗管理が成功しているか、と言われると……はい。

ということで、反面教師としてちょっと良くない例も出していこうかと思います。良い進捗管理をするには、悪い進捗管理を知っていた方が捗ります。

まず何のために進捗管理をやっているのかおさらいです。

①状況把握　：遅れや問題をより速く察知する
②問題の縮小：状況に合わせて早めに対応して問題を小さくする

悪い進捗管理ってのは、この目的が達成できない進捗管理です。①ができなれければ問題を察知するのが遅れて対応が後手に回ってしまう。②をしなければ問題を察知する意味が無い。

ちょっと具体例を出しましょう。


▼①理想の上で成り立つ進捗管理

進捗報告を聞いててよくあるのが

・できると思います（根拠はないけど）
・トラブルなく進めばいけます

というやつで、希望に満ち溢れた報告だなぁと聞くたびに思います。そんで、だいたいは「想定外の作業がでちゃった★」とかで遅れます。HAHAHA。

1つ意識して欲しいのは、

・根拠のない報告やポジティブな思考は、問題発見を邪魔する煙幕になる

ということ。誰しも問題を見逃したいとは思っておらず、「こうなってほしい」という願望に引き摺られて見えなくなっていることが多いのです。

なので、これらを防ぐためには、

・「問題ない」の根拠を数字等で示す（現実を見ましょう）
・「問題ない」 = トラブルが多少起きても大丈夫な状態 として扱う

といった形で進捗管理を進めると良いです。この辺りについては後で詳しく書きます。


▼②遅れているのは分かっていても対処しない

何言ってるんだ？と思われそうですが、これも多いです。

とりあえずスケジュール立てました、作業を進めます。
あ、遅れました。遅れてます。遅れ遅れ遅れ…あーーーーーー！

みたいな感じなの。

進捗管理に対する理解不足からくるものだと思うのですが、本来は

〇 問題を対処するために進捗管理を行う

のはずが、

× 進捗管理した方が良さそうだから進捗管理を行う

みたいな形になっている時に発生しがちです。方法が目的になっているようなパターン。スケジュールは立てるだけでは意味が無いのです。

基本的に、「遅れている」という報告と「どうやって取り戻すか」という報告はセットです。こんな感じ。

とりあえずスケジュール立てました、作業を進めます。
あ、遅れました。3時間の遅れです。
　↓
3時間分、○○で補えば今週中には遅れを取り戻せます。

遅れているのを知りながら放置している…というのはどうしようもない状態になるだけです。何も進展しないうえに精神的にはキツいという、楽しい展開になるので「どうやって取り戻すか」は大事。

スケジュールは立てるだけでなく、スケジュールを使いましょう。


------------------------------------------------------------------


◆見積もり：基本は「無い袖は振れない」

無い袖は振れない、というのは

持ち合わせの無いものはどうすることもできない

ということ。まぁつまるところ、「頑張ったってできないものはできない」ってことです。10日かかる作業を2日でやれと言われましても、無理。

口にするとそりゃそーだろって話なんですが、無い袖を振ろうとしてブンブン頑張ろうとしている人は非常に多いです。例えば

・上司の顔色を窺って「できらぁ！」しちゃう
・頑張ればできると信じて「できらぁ！」しちゃう

みたいな。特に責任感とやる気があるような人とかは注意。上記のようなものに支配されて見積もりを行っちゃうと、

最初から「超ギリギリスケジュール」を組む
　↓
何かしらのトラブルや予定外の作業が発生
　↓
進捗、遅れています……

みたいな状況になりがちです。なぁなぁにされがちな状況なんですが、私は相当危険なものとしてみた方が良いと思っています。人を壊す状況なので。


▼「遅れている状態」は心身を壊す

遅れている状態ってかなりストレスになるんですよ。人のやる気を削ぎ、うつ病にするといっても過言ではないくらい。特に真面目で責任感のある人（そう、私のような人！！！WATASHI!!!）には強烈な毒となります。

具体的に言えば

・ちゃんとできていないことによる、自己肯定感の低下
・周りに迷惑をかけているという重圧とストレスで、精神的に負荷がかかる
・常にタスクの事がちらつき、休もうとしても心身が休まらない

といった症状が出てきます。やる気は立ち消え、心は削られる。仕事は楽しくなくなり、仕事の時間が迫ると非常に強いストレスがかかり、やがて……

みたいな。身に覚えのある人、いるんじゃないですかね。

「遅れている状態」が常態化しちゃっているチームもみかけますが、本当にこれは避けた方が良いです。人が壊れかねないし、この状態で仕事をしても良いパフォーマンスは得られません。あと疲労と焦りによって、仕事の勉強をしようっていう気にもなれないので、やる気のある人の成長を阻害する事にも繋がります。

チームのためにも自分のためにも、「遅れている状態」を如何に避けて立ち回るか…を考えることはかなり重要です。


▼結局かかる時間は一緒なら、遅れていない方が遥かに良い

10時間かかるタスクがあったとしましょうか。コレに対して

①6時間でできると見積もりをした。10時間かかり、4時間遅れた
②12時間でできると見積もりをした。10時間かかり、2時間早まった

といった場合。どちらがいいかと言えば、当たり前の話で②の方が遥かに良いです。遅れどころか早まってるので、今後の作業が2時間遅れても問題ない。精神的にも楽だし、他に困っている人がいたらヘルプに入る余裕もでてくる。

口にすると本当に当たり前の話なんですが、①をしようとしてもがいて苦しんでいる人は大勢います。なんででしょうね？


▼ギリギリの見積もりをしてしまう「幻想」

人間、非合理なものですが、①に陥りがちなのは

・タスクの見積もりよりも先にスケジュールが決まっている
・「できない」と言ってしまうと評価を下げられそう

みたいな時です。ちゃんとした見積もりでやろうとするとスケジュールが最初から破綻しちゃうから、なんとか詰めて詰めて……とか。できないって言うと自分がダメなヤツみたいな気がして、やる気を見せて「できる」って言ってしまうとか。

そういった思考を止めるために、私が大事にしているのが冒頭で言った「無い袖は振れない」です。できないものはできない。冷静に、現実を見ましょう。まず

・タスクの見積もりよりも先にスケジュールが決まっている
→ 見積もりをした際に、スケジュールが破綻している

であれば、やるべきことは

・そのスケジュールで破綻しないように、人員の追加や優先度の低い機能を削って調整する

のが第一となります。そこを「担当者が頑張る」で通そうとすると地獄を見るのは当たり前です。

また、

・「できない」と言ってしまうと評価を下げられそう

についても安心してください。進捗遅れてますって報告していく方が評価を下げられますし、信頼も落としやすいです。もちろん「できない理由」を明確に説得力のある形で示す必要はありますけども。

あ、あと当然として「ちゃんと見積りができていない」というのもあります。そこについてはこれから説明します。


------------------------------------------------------------------


◆見積もり：どうやって見積もりをするのか

スケジュールは、各タスクの見積もりを基に決定されます。つまり、

見積もりがクソだったらスケジュールもクソ

になります。これは必然であり、世界の運命です。なので見積もりはより正確に、実際にやった時にかかる時間と近い数字をはじき出す必要があります。

そのための方法はいくつかあるんですが、ここでは具体的かつ細かい方法論までは踏み込みません。「WBS」だの「ガントチャート」だの「PERT法」だの話始めると色々出てきますが、ここでは触れないです。

PERT法（見積もりの計算式）が気になる方は、この辺りを参考にするとよいかもです。

ここで語るのは、もっと根本的な、超基本的な部分になります。


▼見積もりの流れ

タスクの見積もりは、基本的に

タスクの把握
　　↓
タスクの見積もり

です。細分化しようと思えばもっと細かく言えますが、基本的にはこの流れ。超シンプル。簡単。

意外と「タスクの把握」の工程をすっ飛ばして見積もりを行い始める人もいますが、簡単に地獄を見るのでおススメしないです。

というわけで、「タスクの把握」の重要性を語っていきましょう。


▼タスクを知らないと、見積もりもクソもない

超当たり前の話ですが、そのタスクがどんなタスクなのかを知らなければ、当然作業の見積もりを正確に行うことはできません。なので、見積もりの正確性は「いかにタスクを知るのか」に大きく左右されます。

では、タスクを知るにはどうすればいいのか。方法としてはざっくり言うと

①タスクを細分化する
②経験者に聞く
③まずはやってみる

があります。他にもあるでしょうけど、とりあえずはこの３つ。


▼タスクを細分化して考える

ちょっと例を出して考えていきましょう。例えば

ソーシャルゲームのキャラクターを今月は3体出す。その3体のキャラクターをリリースできる状態にしてほしい。期間は30営業日。

とします。これを作り切るのに、どのくらいかかりそうでしょうか？そんなもん知らねーよと思われそうですが、これを「知る」状態に持っていくのが見積もりをする上では大事です。

まず、フワフワした部分を取り除いていきましょう。例えば

キャラクター3体とは言うけど、まず1体作るのにどのくらい時間かかるのか
　↓
キャラクター1体を作るのにどんな工程（タスク）があるのか

をハッキリさせます。タスクの細分化ですね。例えば今回で言うなら

①まずどんなキャラクターにするのか、設計をする
②設計した内容に合わせて依頼を出す（イラストレーターさんにこんな感じのキャラを描いてくれ！とお願いしたりとか）
③設計した内容に合わせて、データを作る
④作ったデータを動かしながら、ゲームバランスを調整する
⑤バグがないかチェックする

とか。結局のところ、１つのタスクにかかる時間というのは、その中にある細かい作業にかかった時間の合計でしかありません。なので、

①キャラ設計　：3日
②依頼　　　　：1日
③データ作成　：1日
④バランス調整：2日
⑤デバッグ　　：2日

であれば、キャラ1体に対して9日かかることになります。これが3体なので、合計で27営業日で作れる、という算段になるわけです。設定していた期間が30営業日だったので、期限内に作れそうです。

こうすることで、人に説明する時に「各工程これくらいかかるから見積もりとしてはこうなりますよ」とある程度説得力を伴って説明ができますし、なんとな～く「キャラ3体ってこれくらいかかるかな？」と考えるよりも現実的な数字がはじき出せます。

ちなみに「そんなこと言ってもキャラ設計とかってどのくらいかかるかわかんねーんだけど？」という場合はさらに細分化して考えます。キャラ設計で言えば

①どんなキャラクターにするのか、コンセプトを考える
②名前とか種族とかの基本情報を考える
③どんなステータスにするか考える
④どんなスキルを持たせるか考える
⑤これらを上長に見せてレビューしてもらう
⑥レビュー内容に合わせて修正する

とか。これらにかかる時間の合計がキャラ設計にかかる時間です。


▼よくわからないのは経験者から聞いておく

とはいえ、

・そもそもどう細分化すればいいのかわからない
・細分化したけど、どのくらいかかるのかイメージつかない

という場合もあるでしょう。そんな時は経験者に聞いちゃうのが手っ取り早いです。いないと聞けないですけど。

1つ注意するところとしては、「経験者」と「初めての人」では感覚が大きく変わってくるので、「この人が2日でできるから私も2日でできる！」とは思わない方が良いです。この辺りについては後述します。


▼まずは「やってみて」「修正する」ことでズレを潰す

さっき、1キャラ9日って出しましたけど、本当にやってみたら9日でできるでしょうか？経験のある作業ならともかく、初めての作業なんかだとズレが出ます。経験のある作業でもズレるときはままあります。

しかし、それについて悲観する必要はありません。そういうものです。そしてこれまで説明してきた通り、進捗管理においては

・問題は発生するもの
・問題をいち早く見つけて、大きくなるまえに潰す

が大事です。そういうものなら「ズレることがわかったら早めに修正」すればいいだけなのです。

例えば今回の例でいうなら、

①作業を進めていって、「あ、これ9日じゃ終わらんぞ」と気がついた時点で報告をあげる（管理する人がこの時点で問題を把握できる）

②実際やってみたら1キャラ12日かかった。キャラ設計が+2日、データ作成が+1日で1キャラあたり3日のズレ。

③3キャラやれば36営業日で、期限から6日分オーバーしている。

④デバッグは2日、イラスト依頼は1日。これを他の余裕のある人にお願いすれば、2キャラで6日なので30日に収まる。お願いして対応する。

とか。1キャラ作った時点でズレたのが分かったなら、その時点で予定を変更して対応すれば問題を潰せるのです。

ちなみに進捗管理をまともにやっていないと、期限の直前あたりに「すいません全然できていないです……」みたいな相談が飛んできます。ヤメテ。

これ、逆に言えば「大きくズレが出そうな作業を後回しにする」のはかなりヤバいです。やってみたら問題が発覚したけど、対策するにも時間なさ過ぎて詰んだとか。

初めての作業なんかは優先度を高めに設定して早めに1つ行い、「見積もりからのズレを早めに知る」ことが大事です。


------------------------------------------------------------------


◆見積もり：余裕を持った見積もりを行う

よくある悪い見積もりは、「自分がギリギリできる範囲」を見積もりで出します。いわゆる

×トラブルが無かったらいけます

の状態ですね。まぁ何度も言っている通り、無理です。なので正常な見積もりは

〇多少のトラブルがあってもいけます

の状態を保つのが定石です。いわゆる「バッファをとる」というやつで、トラブルを想定して多めに見積もりをとるとうまくいきやすい。

例えばさっきの例でいえば

・見積もり：9日
・実際　　：12日
→3日分のズレ

でしたが、バッファをとってると

・見積もり：9日 * 1.2倍（バッファ） = 11日
・実際　　：12日
→1日分のズレ

となり、ズレが少なく済みます。そしてもし見積もり通りにいっても、予定よりも2日分進むので他の作業の対応が楽になります。

予想よりも多めに見積もりをすることに抵抗がある方もいらっしゃるかもしれませんが、見積もりは基本的に

・いかにブレを小さくするか
・「遅れ」の方向にブレを出さないか

が重要です。それに比べれば、多めに見積もる時の罪悪感、抵抗感みたいのは無意味です。無視しましょう。


▼どのくらいバッファをとるか

とはいえ、無限にバッファをとるわけにもいきません。さすがに限度はあります。どのくらいとればえーっちゅうねん…という話にもなりますが……

1つの基準としては「どのくらい不安要素があるか」ですかね。例えば

・特に不安要素はないけど、何かあるかも？
　→小（1.1倍）
・依頼はされたけど仕様が定まってなくてトラブルありそう
　→中（1.3倍）
・初めてやるタスクでけっこうズレそう
　→大（1.5倍）
※中の数字は適当です。

とか。まぁ詳しい方法とか知りたい人はですね。自分で実験するなり自分で調べるなりしてください。


------------------------------------------------------------------


◆見積もり：「時間」単位でタスクの見積もりを行う

さて、ここまで見積もりの例で「〇日」という日（day）単位を使ってきました。ただぶっちゃけると、この単位は

・長期的なタスクに対して「だいたい」を知るのには有効
・ただし正確な見積もりをするのにはあまり向いない

という特徴があったりします。わりとフワっとしていて、現実から目を逸らすのに、なんとな～くで見積もりをするのに向いてるのです。ちょっと説明しましょうか。


▼1日の作業時間は一定じゃない

1日の作業時間って、安定しないんですよ。例えば1日8時間労働とすると、1日の作業時間は

①1日その作業にのみ集中できる → 1日8時間
②会議に出たり他の雑務が入る   → 1日4時間

といった形でブレたりします。

これが6時間かかる作業なら、

①：8時間以内に収まるので、1日で出来る
②：4時間以内に収まらない。1.5日かかる。

といったことが起きたりします。こういう時、日単位で見積もりが行われると大抵「1日でできらぁ！」判定をしがちなので、これが積み重なっていくと「遅れ」として出てくるのです。

1日の「定義」によって1日分の作業量は変わります。ここを意識しないと、簡単に見積もりが崩壊したりします。


▼時間単位で見積もりを行うことのメリット

なので、私は「時間(hour)」単位での見積もりを推奨しています。これは6時間かかる、これは4時間かかる、とかなら1日の定義に左右されにくい。

また、日単位のように曖昧な単位じゃなくなるので、「頑張れば取り返せる、いけるいける」みたいな遅れた時の都合の良い解釈もしにくくなります。詳細な数字になることで現実を見やすくなる。

そして、もう1点。日単位よりも遅れの対策がとりやすいのが大きなメリットです。例えば

・遅れが5時間
・周りに余裕のある人はいない、自分でなんとかする必要がある
・スケジュールの変更も難しい
　↓
・5時間の遅れなら、5日間1時間ずつ残業すれば取り戻せる

みたいな形ですね。これが「1日の遅れ」として見てしまうと、上記のような案は出にくくなります。


------------------------------------------------------------------


◆対処：どうやって遅れを取り戻すのか

これまでもちょっと触れてきましたが、「遅れ」を確認したら「対策を考える」のもセットです。遅れをそのまま放っておけば予定日には間に合わないので、何かしらの対処をする必要があります。

はい。どうやって？

遅れを取り戻すぞー！と意気込んでも、その方法が明確になっていなければ取り返せません。意義込んで取り返せるなら、遅れは発生しないのです。進捗管理をする人間としては、状況に合わせて適切な方法をとれることが腕の見せ所です。とりあえず残業、人力で頑張る…しかない人は論外です。


▼遅れを取り返す方法

では、遅れを取り返すにはどういった方法があるのでしょうか？ちなみに私がざっと考えた場合、対応方法は以下の5つに分類できます。

①作業時間を増やす（残業等）
②多めに見積もっていたタスクで帳消しにする
③他の人に作業を巻き取ってもらう
④クオリティを下げる
⑤必要な作業を削る
⑥スケジュールを伸ばしてもらう
⑦デスマーチ (⋈◍＞◡＜◍)。✧♡

それぞれ見ていきましょう。特徴や使いどころを考えてみます。


①作業時間を増やす（残業等）
・遅れの状況　　　　　：小
・プロジェクトへの影響：無
・人的負担　　　　　　：中（使い方間違えると大）
【どんな時に使うか】
ちょっと遅れているけど、他人に迷惑をかけるほどじゃないよねって時に向いてる。ご利用は計画的に。

最もポピュラーで、最も常態化しちゃいけないやつです。時間が足りないなら増やせばいいじゃない！！

数時間くらいの遅れなら、これで取り返せばいいかなって思います。ただし、毎日これをやるようならスケジュールは破綻していると思ってください。危険で、人にも負担がかかります。そういう場合は他の手を使った方が良いです。

遅れが溜まる前に、ちょびっとやって正常な状態を保つ…のも1つの使い方ですね。遅れが溜まるよりも、精神的には楽になります。

決して、遅れの状況がデカい状況で頼らないように。


②多めに見積もっていたタスクで帳消しにする
・遅れの状況　　　　　：小
・プロジェクトへの影響：無
・人的負担　　　　　　：無
【どんな時に使うか】
意図的にバッファを多く取っていた時に、辻褄合わせに使う。ただし未来に期待しすぎると「こんなはずではなかった」になるので注意。基本的には使わない方が良い。

「どうやって遅れを取り戻そうか？」
って話をする時に、
「あのタスク多めに見積もってたんで、前倒しで進めれば〇時間で終わって取り戻せると思います」
的な形で使う。ただそのタスクがトラブったらヤバいので基本的に非推奨。

どちらかと言うと、そういうタスクであらかじめスケジュールを前倒しにしておく意識の方が良いです。

一見タスクを問題なくこなしている人でも、全てのタスクを順調にこなしているわけではなかったりします。早く終わったタスクで遅れが出たタスクをカバーしている事も多い。

バッファって大事。


③他の人に作業を巻き取ってもらう
・遅れの状況　　　　　：小～中
・プロジェクトへの影響：無
・人的負担　　　　　　：小～中
【どんな時に使うか】
ちょっと自分の力だけじゃ取り戻せそうにないけど、プロジェクトに影響を与えたくない時。

ちょっと作業に余裕がある人とか、担当者よりも能力があって作業が早い人がいる時とか。多用はしたくないけど、1人に残業させまくって潰しちゃうよりは遥かに良いです。

他人に迷惑かけちゃうこと気にする人もいますが、まぁ、うん、次はそうならないようにしっかり考えて頑張りましょう。

ただしずっとこの状況になると自己肯定感の低下が半端なく、ストレスも強くなるので、多くなるようなら別の方法をとった方が良いです。


④クオリティを下げる
・遅れの状況　　　　　：中
・プロジェクトへの影響：小～中
・人的負担　　　　　　：小
【どんな時に使うか】
クオリティを求めるよりも、完成させるときを重視する時。リリースできなきゃ意味が無い。10の工数で10の物を作らず、5の工数で7くらいの物を作る。割り切ったやり方。

時間が無い時は、ある程度割り切ることも大事です。

ゲームバランスの調整にいつもは10時間かけるけど、時間が無い時は5時間くらいで出来る範囲になんとか納める…みたいな。

そのタスクに対して、どの部分を割り切って進めれば出来るだけクオリティを落とさずに早めに終わるか…みたいなのを見極める必要もあるので、地味に能力は必要かも。

完成しないよりはマシなのです。ただ、クオリティを下げれば下げるほど、そのプロジェクトの成功率は下がるので乱用はしない方が良いと思います。

ちなみに、私は少し無茶なスケジュールを振られたときによく交渉に使います。

「どうしてもって言うならできる。ただしクオリティをある程度落とさないとできない。私としては、もうちょっと期間を設けてちゃんとやった方が良いと思うけど…本当にやる？」

みたいな。


⑤必要な作業を削る
・遅れの状況　　　　　：中～大
・プロジェクトへの影響：中～大
・人的負担　　　　　　：小
【どんな時に使うか】
それなりに遅れが出ていて、ちょっとヤバめな時。優先度は低いけどそれなりに工数は持っていかれるような、燃費の悪いタスクがある時。

いわゆる「機能をオミットする」ってやつ。

作る予定だったけど、このままじゃ間に合わないからこの機能は作らないで完成させちゃおう、みたいな形ですね。仕様の中には、そんなに重要じゃない、あった方がいいけど無くてもそれなりに成り立つ……みたいのがあったりするわけです。それを切っちゃう。

クオリティだけを求めていくなら最良ではないけど、やっぱり完成しないと意味が無い。


⑥スケジュールを伸ばしてもらう
・遅れの状況　　　　　：中～大
・プロジェクトへの影響：中～大
・人的負担　　　　　　：小
【どんな時に使うか】
もうどうやっても期間が足らない。最初に決めた期間で終わらせるのが望ましいが、必ずしもその期間に終わらせなくてもまだ大丈夫…な時。

他に打つ手がないよね、とか。まぁ最初に期間は決めたけど、クオリティを落とすよりは延ばした方がいいよね、って判断できる時とか。

ただし期間が延びれば延びるほど人件費も嵩むし、利益は出なくなる。気軽にできる物ではない。


⑦デスマーチ (⋈◍＞◡＜◍)。✧♡
・遅れの状況　　　　　：ああああああああ
・プロジェクトへの影響：無
・人的負担　　　　　　：大
【どんな時に使うか】
人力で頑張るしかやれることがない

①の超強化版。取れる手は打った、もうスケジュールは延ばせない。でも時間は足らない。さぁそんな時こそデスマーチ！みんなで死ぬ気で頑張ろう！

…まぁ、こうならないように事前に手を打ちましょう。それが進捗管理です。はい。


▼遅れを取り返す方法

上記をまとめると、基本的に

【遅れ：小】
①：軽い遅れであれば、まず個人で頑張って取り戻す

【遅れ：中】
ずっと①が続いたり、個人の頑張りだけだと負荷が強すぎる場合は
②：余裕のある人の手を借りることも検討
③：タスクの完了が大事なら、割り切ってクオリティを落とすのも検討

【遅れ：大】
小手先の対応じゃどうにもならないレベルまで遅れてしまったら
④：重要度が低く、コスパの悪い作業は切り落とす
⑤：スケジュールを伸ばせるなら伸ばしてもらう
⑥：もう④も⑤も使えないなら (⋈◍＞◡＜◍)。✧♡

って感じですかね。


◆まとめ

今回語るのは以上です。まとめると、

◆進捗管理で何を目指すのか
　・状況把握　：遅れや問題をより速く察知する
　・問題の縮小：状況に合わせて早めに対応して問題を小さくする
◆良くない進捗管理とは
　・理想にまみれて、現実が見えていない
　・「遅れている」って言ってるだけで何も対処しない
◆どうやって見積もりをするのか
　・見積もりの流れは「タスクの把握」→「タスクの見積もり」
　・タスクの内容をきちんと把握するのが超重要
　・タスクを細分化して、把握をする
　・経験者から聞いて、把握をする
　・経験に勝る情報は無い。まずやってみること
　・最初の見積もりを守り抜くより、早い段階で修正する
◆バッファを持たせて、余裕のある見積もりをする
　・トラブルがなかったらいける、は大抵いけない
　・多少のトラブルがってもいける、を目指す
　・大抵は遅れるので、多めに見積もった方がズレない
　・どれくらいバッファを持たせるか、不安要素に応じて決めるのもアリ
◆日単位ではなく、時間単位で見積もりを行う
　・日単位の見積もりは意外とブレやすい
　・「1日」の定義で実際の作業時間が変わってしまう
　・時間単位で見積もれば、その辺りを潰せる
　・時間単位で見積もれば、遅れへの対処に幅が出る
◆遅れへの対処方法
　・大事なのは、どうやって遅れを取り戻すのか。
　・「遅れている」と「どうやって取り戻すのか」はセット
　・遅れの対処方法は↓がある
　　①作業時間を増やす（残業等）
　　②多めに見積もっていたタスクで帳消しにする
　　③他の人に作業を巻き取ってもらう
　　④クオリティを下げる
　　⑤必要な作業を削る
　　⑥スケジュールを伸ばしてもらう
　　⑦デスマーチ (⋈◍＞◡＜◍)。✧♡

ですかね。長い。

遅れへの対処方法とかはここで挙げたもの以外にもあると思います。ぶっちゃけ私がここで語った内容がベストとは思ってません。

どうやって見積もるのか、どうやって管理するのか、どうやって遅れに対処するのか……というのは、色んな人の知見を集めながら、自分達にあったやり方をとればいいんじゃないかなーと思います。

なんかいい感じに逃げ道を残しておわり。


◆宣伝

ゲームデザイン大好きっ子なので、自分で考えたゲームデザイン論的なのを書いてたりします。『心理学界の異端児「行動分析学」から考えるゲームデザイン』とか。

いや、この記事もそれの番外編みたいなもんですけど。よろしければ気になる記事がないか見てみてください。


仕事でソーシャルゲームを作ってますが、個人でインディーゲームも作ってます。Twitterで情報垂れ流し中。

進捗はダメです。



サポート（投げ銭、金銭支援）歓迎です。 頂いたお金はゲームの開発費に使用させていただきます。 　↓ 支援が多いと私のゲームのイラスト枚数が増えたりオリジナルの曲が組み込まれたりします。美味しいお肉を食べに行ったりはしません。