はじめに
いきなりですが、進捗報告を％で報告するのはおススメしません。
経験がある人も多いと思いますが、進捗80%を超えてから100%になるまでの道のりが長く、進捗80%までのスピードが嘘のように失速します。
報告を聞いた相手もですが、何より自分自身にひどくガッカリするものです。
僕の体感では、
進捗80%になるまでのスピード ： 進捗80%⇒100%になるまでのスピード ＝ 1 ： 4
くらいな気がしています。
どんなに開発に慣れてきても、体感はこんな感じです。これからも変わる気はしません（苦笑）
僕はこれを進捗80％問題と呼んでいるのですが、おそらく多くのITエンジニアの方に共感してもらえると思っています。
今回はその進捗80％問題がなぜ起こるのか？
それが起こることで生じる弊害、解決策を僕自身の経験を踏まえて書き残しておきたく記事にしました。
RPAの開発を前提として書いていますが、RPA以外の仕事に従事されている方でも理解できるように書きました。
ご参考になれば幸いです。
進捗80％問題
弊害
記事の冒頭で、進捗を％で報告するのはおススメしないと言いましたが、なぜおススメしないのかについて触れておきます。
- % では何も伝わらない
- 伝わるのは期待感だけ
- 「見積もった工数の1/3でもう80%進んだぜ☆」などとアピールしてしまうと後で自分の首を絞めることになる
- いわゆる「駆け出しエンジニア」にありがち
- 80%までいってるなら「後1日で終わるよね？」などと甘く見られてしまう
- 開発経験のあるPMであれば、そこから先が長いことを理解してもらえるはず。。。
何も伝わらないしデメリットしかない。
僕は自分に甘いので(笑)進捗率高めに報告して、後々苦労した経験がたくさんあります。
なぜ起こるか？
答えはシンプルで、こだわりのせいだと思っています。
進捗80%を超えた後に、ユーザーがさほど気にしないと思われる箇所に注力してしまったり、過剰なクオリティに仕上げるために時間を投下してしまう。
これを本記事ではこだわりとします。
進捗80%までで実装するのは、いわゆる正常系です。エラーハンドリングから実装することはまずないでしょう。
仕様がある程度きっちり固まっていれば、正常系と分かりやすいエラーのハンドリングは頭の中ですぐにイメージできるでしょうから、手が止まることはあまりないかと思います。
そこまで実装できていて、（通常業務で起こりうる範囲での）インプットデータが問題なくさばけるだろうと自分の中で確信が持てたら進捗80%到達です。
進捗80%から100%に到達するまでは、自分の中のこだわりとの戦いです。
進捗80%から先は、主にエラーハンドリング周りやイレギュラーケースの実装がメインになると思います。
特にエラーハンドリングは、開発者の性格によってこだわりの強弱が分かれます。
僕が見てきた限りだと、マジメな人ほど進捗80%から100%は遠い道のりになりやすいです。
そして僕もどちらかというとマジメなので、エラーハンドリングは割とがっつり作り込むタイプです。
設計書にしっかりエラーの時の実装について書いておけば、こだわりが入り込む余地なんてないやん☆
と思う人、いると思います。
理想はそうなのですが、どうしても実装中に気づいたり、より良い方法が閃いたりするものです。
設計書は机上の空論になりやすいのであまり作り込みすぎるのもどうかと個人的には考えています。
設計書に時間を割くのであれば、実装に時間を割いて、試行錯誤する時間に充てた方が結果的にクオリティの高いものが出来上がる気がします。
設計書を作るときに頭の中でぐるぐる考え込むよりも、実装で手を動かしてる方が脳が刺激されてアイデアが閃きやすいですね。
なので、上流工程をどう工夫しても実装者のこだわりは出てきてしまうものなのだと思います。
解決するには？
開発全体の工数を見積もる
今回の例では**3週間（15日）**としましょう。
工程別の工数は
設計：3日
実装：5日
テスト：3日
本番検証（UAT）：4日
としておきます。
本番検証は厚めに工数を割いておくのがコツです。
余談ですが、ユーザーとの業務自動化案件の打ち合わせの際に、要望や仕様の話を一通りヒアリングさせてもらった後で
「どれくらいかかりそうですかね？」
と聞かれることがよーくあります。。。
経験値からざっくり答えて流しているのですが←
1日単位だとちょっと具体的すぎるので、1週間単位くらいで出しておくと気持ちがラクになりますw
実装の進め方
僕は今フルリモートで仕事をしているので、ここから先の話はフルリモート前提で進めます←
そして、決してキレイな働き方ではありませんので、悪しからず。
今回の場合、実装工数は5日と見積もっていますね。
前述したように、体感では
進捗80%になるまでのスピード ： 進捗80%⇒100%になるまでのスピード ＝ 1 ： 4
なので、進捗80%を1日で実現しなければならない計算になります。
ムチャクチャや！と思うかもしれません。
ですが、これを1日でやります。
実装2日目の時点でユーザーにプロトタイプとしてお披露目できるレベルのものを作るイメージで作ります。
いやムリムリ！と思いきや、意外といけますw
なぜなら、頭の中でイメージができていると、やる気が出て自然と手が動くからです。
やる気はだんだん下がっていくものです。ぜひこの初動のやる気を大切にしましょう。
徹夜してでも…とまではいきませんが、僕は平気で夜中に実装してたりします。
リモートだからいつでも開発できるのです。
（人に言われてやらされるならブラックですが、自発的にやってるからブラックではありません）
重要なのは、見積実装工数の20％で80%の完成度を実現すること。パレートの法則です。
進捗80%到達後
進捗80%に達したことで、気持ち的にかなりゆとりが生まれます。
これが大切です。
進捗80%を1日で達成させる理由は、精神的なゆとりを保つためです。
個人的には、納期が迫っていたり、見積工数をオーバーするかどうか瀬戸際のところで開発をするよりも、
まだ余裕がある☆という気持ちで開発した方が、不思議と生産性やクオリティが上がります。
ただし油断は禁物で、僕の経験上、見積工数のギリギリまでこだわりの呪縛から離れられませんw
パーキンソンの法則ですね。
こだわりの呪縛から脱却するには、「これでOKやろ！」と自分が納得するクオリティまで早く持っていくしかありません。
そのためには、どんなインプットデータが来ても大丈夫☆と言えればいいわけです。
ということは、（通常業務で起こりうる範囲での）インプットデータのパターンを、自分が納得する数だけ用意して片っ端から流せばよいのです。
実際、細かいエラーハンドリングなんてユーザーは大して気にしていないものです。
ユーザーにとってはちゃんと業務を遂行してくれれば良く、エラーパターンが来た時の対処は「いい感じ」にやって業務に支障が出なければ何でもOK！というスタンスであることがほとんどです。
なので、ふとしたときに「あ、こだわりすぎてるな…」と感じたら、実装は一旦休憩して、
あらかじめ用意したテストデータをざっと流してみて、明らかにおかしい結果じゃないか？を確認してみるのは有効だと思います。
「さっきまで実装してたエラーハンドリング、大して重要じゃないな。。。」「実装しようと思ってたあの処理はやっぱいらないな」と考え直し冷静になったことで、進捗100%として納得できるかもしれません。
自分のこだわりはユーザーにとってはそれほど重要ではなかったりすることも多いのです。
まとめ
- 進捗報告を％で行うのはデメリットだらけ
- 進捗80%問題の原因は実装者の「こだわり」
- 自分の中で「進捗80%になるまで」と「進捗80%から100%になるまで」の工数比率を認識しておく
- 筆者の場合は1：4
- 進捗80%到達後は気持ちにゆとりができ、生産性やクオリティが上がりやすい
- こだわりの呪縛から脱却するには、通常業務で起こりうる範囲でのテストデータを流して結果を見てみる
- こだわってた部分を一度客観的に見直してみる
- 自分のこだわりは他人にとってはそれほど重要ではないことも多い
※全て筆者の個人的見解です