「仕事進んでますか？」と聞かれた時に、「もう終わってますよ」と答えるのが大好きな、ユゲタです。
仕事はとにかく早く仕上げるがモットーなんですが、それゆえに、荒削りなんですね。
ミスも多いし、直しもたくさんあることがほとんどです。
でも、終わらないよりはずっとマシと思って、これまでやってきましたが、先日、とある会社でエンジニアをしている友人が
「うちの開発、タスク進捗が80%超えたらなかなか上がりにくくなるんだよね」という話を聞きました。
なんでかな？と一緒に考えてみたら、実はタスク進捗率って、かなり適当にやっているのではないかという話で盛り上がって、
まあまあな業界あるあるではないかと考えて、ブログにまとめてみました。
開発進捗率の曖昧さ
このブログを読んでいるあなたの開発チームは、開発進捗管理をどのように行なっていますか？
・ガントチャート方式
エクセル好きな年配管理者も多い事から、いまだに手作りガントチャートで運用している人も多いのでは無いでしょうか？
日別に何の作業をやるか明確にわかりやすいですが、これってチーム開発の基本の様な感じがしますが、そもそもこの綺麗なガントチャートを作って運用管理する工数が、このチャートに反映されていないところから、
かなり曖昧な値である事がわかります。
これ結構時間かかるんですよね。簡易に考えている管理者のプロジェクトは、必ず炎上しますからね（個人的な経験に基づく発言です）
・jira方式
今時の開発っぽい、webサービスを使った進捗管理方法です。
https://www.atlassian.com/ja/software/jira
見た目でグラフが上がっているか下がっているかで、進捗の進み具合を確認する事ができて便利そうですが、やっている事はガントチャートと全く同じです。
入力する欄が用意されていて、運用は若干らくなのと、プロジェクトが変更したときにリカバリ方法などが仕組み化されていて、便利と感じる人も多い様です。
ほかにも、
Backlogや
wrike、
asana、
trello、
stock...
腐るほどあります。レッドオーシャンやったんかい！
そのツールを使っても、実際に開発する人の作業は何にも変わりません。
そして、「このタスクいつ終わるの？」と聞かれて、先週は10%進んでいて、来週までに終わらせるから、とりあえず「50%ぐらい進んでます」と言っておけばいいと思ってそのまま進捗管理ツールに登録しているエンジニア、多く無いですか？
要するに、進捗率って、ナンの根拠もない数値である事が大半なんですよね。
%に意味はなく、0か100かそれ以外で考えよ
そもそも進捗率って、ちゃんと工数を消化できているか、納期までに完了できるかという目安にするためのものですよね。
ウォーターフォール式で、全ての作業を洗い出して、全部で100個の作業があった時に、10個の作業が終わっていれば、10%とするとわかりやすいと思いますが、実際は、１機能で１タスクで数える事が多く、
１タスクの進捗度合いが、半分ぐらい終わっているから50%としてしまいがちです。
この50%は、開発のコーディング作業が終わるまでの時間で、その後の検証やら、問題発生時の工数は含まれないので、結果的にそうした作業があとから追加されて、想定工数をオーバーしてしまうケースがよくあります。
もちろん、作業を細かなタスクとして登録できればいいのですが、そうしたことを踏まえての設計をきちんとできている現場もなかなか少ないのも現実なので、多くの現場では、
想定外が発生した時のリカバリー期間を、「バッファ」という名目で設けています。これもまた曖昧な単位で笑ってしまうんですが、想定の20%から30%ぐらいのバッファが普通という風に感じている人もいれば、
200%ぐらいの感覚もいるし、実際にお金を支払うクライアントからすると、1%でもバッファなんか設けてくれるなと考えている人たちもいます。
個人的にはバッファと聞くともはやカオス開発現場という風に聞こえてしまうのは正常なのでしょうか？
やはり、デジタル作業ということも考えて、0か1でタスクの完了を判断するのが好ましいですね。
進捗に悩んでいる人の話
とにかく、ディレクションをする人で、開発現場の進捗管理をする中間管理職の人は、おそらく多くの場合、「面白くない仕事」と感じているでしょう。
ユゲタも正直、その仕事に面白みを感じるポイントは少ないですね〜。
1人でやった方がよっぽど効率的だし、独創的な開発がなかなができないというデメリットを強く感じてしまうので、
なるべく納期のある仕事は短期のみに留めたいと考えてしまいます。
長期で縛られる案件って、まあまあな手足縛られ感があるので、個人的にはその開発期間中はなんか閉塞感があるんですよね〜。
開発の人で、こんな感情に共感できる人いませんか？
