90%シンドローム

という言葉を聞いたことがありますでしょうか。

百分率の進捗報告ほど当てにならないものはありません。

毎週の進捗報告で、ある機能の実装／単体テストが、30%→60%→80%と順調に推移してきたのに、翌週から85％→90%→92%などと足踏み状態になることは日常茶飯事です。

ときには、90％だった進捗が80％に戻ったりすることもあるのでもはや謎以外のなにものでもありません。

決して嘘をつきたいわけではないのでしょうけど、結果的にそんな報告になっていく人が非常にたくさんいます。少なくともＩＴ業界ではそう言われてきましたし、実際タイトルと同じキーワードでググって見たらたくさんのWebサイトが見つかることでしょう。

　
報告時の進捗率（ここでは「今まで作業に費やした時間 ÷ 完了までに要する時間」を進捗率と定義。尺度は時間であり、成果物の分量ではない）をどのようなアルゴリズムで計算しているのかをリバース･エンジニアリングで調査してみると、実際の進捗(x)と報告上の進捗(y)との間には、以下の関係が成り立つことがわかっているそうです。それが

　 y = 21.7logeX

という計算式。
この関係をグラフに整理すると、下図のようになります。

つまり、エンジニアが「だいたい…70％くらいです」と報告したとしたら、上図により実際には25％程度しか終わっていないことになります。

これは、報告者本人に悪意や過失があるわけではありません。進捗を聞きたい側（リーダーまたはマネージャー）にとって評価する基準がない場合に起こる事象です。

基準をあらかじめ教えられていないと、報告者は大抵の場合、

　・今後も割込み作業等、外的要因によって変化することがない
　・指摘やバグ等は発生しない
　・ゴールは「作業の完了」でなく「とりあえず一旦作りきる」ところまで

等と言った都合のいい暗黙の前提のもとに、ざっくりと現在の達成状況を割合にして報告しがちです。

仮にそうでなかったとしても、報告者の多くは報告する時に限って目の前の作業だけしか見えていないことが多いものです。だから後半になってレビュー指摘が加わったり、不良が見つかったりしだすと、その影響範囲や要するであろう作業工数などに振り回されて数値が安定しなくなるのです。

こう言った些細なことさえ、トラブルの原因となったりすることがよくあります。だからこそ、計画時にきちんとルールや基準を決めておくことが重要になってきます。

進捗を知る（割合で把握する）

もし、みなさんがリーダーやマネージャーの立場であった場合、やはり部下やメンバーの状況は把握したいことでしょう。先の説明のとおり「進捗（進み具合）」を割合として知りたいというのであれば、まず

　"基準"

を設けましょう。たとえば

未着手：0%
作成中：10%
作成済：50%
審査（レビュー）中：60%
対策（修正）中：70%
対策（修正）済：80%
レビュー済：90%
完了：100%　　（ざっと適当に作った一例です）

といった感じでもいいかもしれません。そうするだけで報告者の個人的に感覚に頼ることは無くなります。ただし、こうした状態遷移を基準にした場合、数値から残りの日程が予測できない、というデメリットもありますのでそれが嫌な方はこの方法を推奨しません。

ちなみに一般的に推奨されている方法の１つではあるのですが、個人的にはこの方法は好きじゃないので使いません（その理由はのちほど説明しますが）。

進捗を知る（物理的数値で把握する）

これもあまり現実的ではないのですが、成果物量などの予実を管理する方法です。たとえば「実績値/計画値」といった形で報告します。

　「現在、25/90です」

みたいな。ソフトウェア開発の世界ならテスト消化を報告する際のバーンダウンチャートなんかと同じと思ってもらえればいいでしょう。

この方法は「計画値」がよほど正確に出ている時に限り、有効に機能します。実績はやったぶんだけ数えればいいわけですからさほど難しくないのですが、いかんせん未来予測の賜物である計画値を正確に先に導き出せ、というのが難しいのです。

もちろん計画がコロコロ変われば、都度報告する際に替えて報告すればいいかもしれません。ですが、それではリーダーやマネージャーはプロジェクトの予測が立てられなくなってしまいますし、計画がコロコロ変わるのが当たり前と言い切ってしまうと、みんなテキトーに設定しようとするでしょう。

たとえば、100ページの文書を作るとして1日あたり10ページの生産性と仮定します。するとスケジュールは10人日設定することになります。ですが、翌日には「あ、やっぱ90ページ」さらに翌日には「ちょっと〇〇忘れていたので25ページ増えました」と言われてしまうと、どんなに実績値が正確でもスケジュールコントロールなんてまともにできません。

ですので、この方法もよほど計画値が確定しない限り、私は絶対に使わない方法です（確定していれば、逆に精度が高いので使いますけど）。

進捗を知ろうとしない（残予定数で管理する）

そんな中、私が最もよく使うのは、

　進捗（進んだ実績）は管理しない

という方法です。これが案外、巷では受け入れられない…。

本来、リーダーやマネージャーにとって最も重要視すべきは「過去どうした」ではなく「これからどうする」の方のはずです。メンバーの状況を聞く際に「今日までどうしてきたか」という報告ではなく、

　「あとどれだけ残ってて、その完了までにどれだけかかるか」

のはずです。順調であれ、不調であれ、過去はもう巻き戻せないのですからどーでもいい話です。だから、計画を立てたあと、私は「計画通りに進んだか」より、このあと「計画通りに進みそうか」という観点で部下やメンバーに確認します。

だから第一声は

　「あとどれくらいで終わりそう？」

です。「どこまで進んだ？」とは聞きません。あらかじめ立てておいた計画通りに終わりそうならそれでよし。そうでないなら『課題』または『問題』が生じたということですから、課題管理や問題解決管理に話をスライドさせていくだけです。

その場でも「何がボトルネックになっているか？」を確認し、メンバーの中で達成すべき役割ないの作業とそうでない作業に切り分け、極力メンバーにとって「すぐに解決できる状態」を作り出してあげるように尽力します。

　メンバーのパフォーマンスの『最大値化』

ができる環境づくりはリーダーやマネージャーの役割であり責任だと思っているので、目の前の役割に集中してパフォーマンスを最大値で出す努力はメンバーに任せるものの、役割にないことや集中を阻害する要因は『最大値化』させる環境づくりを役割とするリーダーやマネージャー…すなわち私の責任で解決してあげることだと思っています。

一般的に部下をこき使うだけの上司、リーダー、マネージャーの場合、予想通りに進んでいないと

　「おい、どーするつもりだ」
　「どうするんだ！」

というだけで自分では何もしようとしないかもしれませんが、そんな環境では部下やメンバーが100%の実力を発揮することはありません。結果、もっと当初計画よりも効率が落ちるだけです。

「アイツだったらこれくらいできるだろう」という予測の生産性を前提として計画を立てている以上、その生産性が常に発揮できる環境を用意し、維持してあげるのは計画を立てた者の責任ではないでしょうか。

…ちょっと話はズレてしまいましたが、そういう思想のもと、課題や問題を細分化して、彼らが自らの役割が持つ課題や問題に集中し、最も高いパフォーマンスができるようにしてあげることで、「あと〇日あれば完了します」というメンバーたちの報告のなかにも、精神的な余裕が生まれ、実現性が高くなり、そうすることでリーダーやマネージャーも安心してその報告を受け取れる…という良いサイクルが生まれるようになります。

最後に

要するに90%シンドロームというのは、リーダーやマネージャーが本当の意味でマネジメント（の中の監視・コントロールプロセス）を使いこなせておらず、「一般的にそうだから」というだけで何となく行っている進捗管理を形だけ真似たせいで、メンバーが混乱をきたした結果…生じるものなのかもしれません。

リーダーやマネージャーたちが本当は

　「どう管理したいのか」
　「何をゴールとしたいのか」
　「そのためにはどうすることが一番なのか」

を一人ひとり真剣に考えていれば、こうした症状はここまで浸透することは無かったのかもしれません。