人を増やしたのに、なぜ速くならないのか ―生産性を分解して考える

「見積りでは10人日だった作業が、蓋を開けてみたら15人日かかっていた。」「遅れを取り戻そうと人を増やしたのに、なぜかスピードは変わらない。」
プロジェクトの現場では、珍しくない光景ではないでしょうか。

こうした場面で必ず出てくるのが「生産性を上げよう」という言葉です。ただ、この言葉ほど、口にした瞬間に議論がぼやけるものもありません。何を指しているのかが、人によって違うからです。

生産性そのものは、式にしてしまえば単純です。しかし単純だからこそ、扱いを誤ると人を追い詰める道具にもなります。この記事では生産性という言葉を一度分解し、PMがプロジェクト運営のどこで使えるのかを整理していきます。

生産性とは何か

一口に生産性といっても、労働生産性や資本生産性などさまざまな種類があります。ただ一般に「生産性」と言った場合は、産出された成果（アウトプット）を、その投入量（インプット）で割った、もっともシンプルな形を指します。

生産性 ＝ アウトプット ÷ インプット

この式から分かることは、実はひとつだけです。生産性を上げるには、分子であるアウトプットを増やすか、分母であるインプットを減らすか、その二択しかないということ。

ここまでは、おそらく誰も異論がないはずです。議論が食い違い始めるのは、この先──アウトプットとインプットの中身を、それぞれ何と見なすかという段階からです。

アウトプットとインプットには何が入るのか

まずアウトプットから見ていきます。アウトプットは、量で測る「生産量」のこともあれば、価値で測る「生産額」のこともあります。何で計測するかはケースバイケースですが、ひとまず「何かしら生産されたもの」と捉えておけばよいでしょう。

経済学では、生産を「生産 ＝ 資本 × 労働」という形で表すことがあります。ここでいう資本にはお金だけでなく、そこから購入できる設備なども含まれます。つまり何かを生み出すには、ヒト・モノ・カネが必要だということです。

ここに、生産性の厄介さがあります。アウトプットを増やそうとすると、人を増やすか、モノを増やすか、お金をかけることになり、それは同時にインプットの増加も意味します。分子だけを都合よく大きくする方法は、基本的に存在しません。

一方のインプットは、量でも金額でも測れますが、より敏感になるのは金額で考えたときでしょう。金額としてのインプットはそのまま費用であり、経営にとって頭の痛い数値になります。

そしてIT・Web案件の場合、このインプットは実務上、ほとんど工数（人日）という単位に集約されます。

工数（人日）は、生産性の裏返しである

「この画面の実装は3人日」と見積書に書くとき、私たちは無意識のうちに生産性を仮定しています。その作業のアウトプットを、3人日というインプットで割った値がいくつになるかを、あらかじめ宣言しているのと同じだからです。

だとすれば、見積りと実績のズレは、生産性の見誤りとして表面化することになります。

私自身、駆け出しのころは見積りと実績のズレを何度も経験しました。振り返ってみると、原因は大きく3つに分かれます。

ひとつは、仕様のヒアリング不足です。案件を進めていくなかで「実はこういう機能が必要だった」と判明する。当然、見積りには盛り込まれていません。

ふたつめは、プロジェクトのハンドリング不足です。方向性を握れないまま進めた結果、修正が何度も繰り返され、同じものを作り直すことになります。

みっつめは、依頼先の技術レベルを正確に把握できていなかったことです。身の丈に合わない依頼をしてしまい、時間だけがかかって、品質も上がらないという結果になりました。

3つとも、「作業者が遅かった」という話ではありません。アウトプットの範囲を見誤ったか、インプット側の能力を読み違えたかのどちらかです。

見積りの精度を上げたいとき、多くの人は見積りの計算方法を改善しようとします。しかし手を入れるべきは、たいてい計算方法ではなく、その前提のほうです。

人を増やしても、生産性は上がらないことがある

式の上では、インプットを増やせばアウトプットも増えそうに見えます。しかし現場ではそうなりません。

「人を増やせば作業が早くなる」と考える人は、往々にして知識をすべてのメンバーが共有しているという前提に立っています。現実には、そんなことはまずありません。

たとえばプログラミングのサポートとして開発者が追加されても、その人はプロジェクトの状況が分からず、何をしたらよいのか全体像をつかめていない、ということがよく起こります。また、既存のメンバーが開発していたプログラムを急に別の人と分担するのは難しく、プログラマー間のレクチャーを徹底しなければなりません。それを怠ると、これまでのルールを無視したコードが書かれ、かえって不具合を増やすという結果を招きます。

生産性の式に戻れば、増員は分母を増やすと同時に、レクチャーという新しいインプットまで生み出しています。分母が二重に膨らむわけですから、短期的には生産性が下がるのは、むしろ当然のことです。

増員を判断するときに見ておきたいのは、次の3点です。

• 残りの期間は、レクチャーの時間を回収できる長さか
• レクチャーに何日かかりそうか
• それを誰が担うのか（多くの場合、いま最も手が動いているメンバーです）

ここを見ないまま人を足すと、チームで最も貴重な人の時間から奪っていくことになります。

同じ作業でも、人によって差がつく理由

同じ実装でも、新人のAさんはゼロから開発し、ベテランのBさんは過去の案件から類似のコードを持ってきて改良し、短期間で仕上げてしまう。IT業界ではよく見かける光景です。

差を生んでいるのは、ツールの習熟度と、これまで見てきた事例の数──つまり引き出しの量です。

ここで押さえておきたいのは、これがインプット側の差だということです。同じアウトプットに対して、必要なインプットが少なくて済んでいるから、生産性が高い。裏を返せば、生産性はインプットを育てることで上がるということになります。

ただし、スキルと経験が育つには時間がかかります。明日の締切には、どうやっても間に合いません。生産性の議論が締切の場で噛み合わないのは、このためです。生産性の話は、締切の場ではなく、育成と体制の場でするものだと考えておくのが健全です。

注意点：やってはいけない「生産性向上」

人日で動くIT業界では、生産性を上げようとして、かえって組織を痛める打ち手が繰り返されています。私が実際に目にしてきたものを挙げておきます。

担当案件数を増やす

一人の担当者が受け持つ案件を増やせば、見た目の生産性は一時的に上がります。しかしその結果、過労によって退職してしまうという事例を、私は何度も目にしてきました。

抜けた人の持っていた知識は引き継がれず、残ったメンバーがその負担を引き受けることになります。数字が上がっていた期間の何倍もの時間を、そのあとで失うことになります。

「安い」という理由だけで依頼先を選ぶ

単価の安いプログラマーに依頼したものの修正が多く、チェックの工数が膨らんで、結果的に全体の生産性を下げてしまう。これもよくある話です。

インプットの一部（外注費）だけを見て、別のインプット（自社の確認工数）が増えることを勘定に入れていない典型的なパターンです。

案件の金額で測る

デザイナーやプログラマーの生産性を、担当した案件の金額で測っている場面に出会ったこともあります。

しかしこれでは、自社を高く評価して十分な予算をくれた案件Aについたスタッフと、長年の付き合いで低予算のまま無理やりねじ込まれた案件Bについたスタッフとで、生産性が変わってしまいます。案件の金額が表しているのは、スタッフの働きぶりではなく、営業関係と交渉の結果です。

3つに共通しているのは、測りやすいものを測ってしまっているという点です。そして測られた側は、測られた指標のほうに最適化していきます。指標の選び方は、そのままチームの行動の選び方になります。

実践：アウトプットとインプットを分けて追う

では、PMは生産性をどう扱えばよいのでしょうか。私が有効だと感じているのは、生産性というひとつの数字を追うのをやめ、アウトプットとインプットを分けて見ることです。

インプットは、スキルと経験の変遷として追う

IT・Web案件のインプットは、突き詰めればメンバーのスキルと経験です。スキルシートのような形で、何ができるようになったかを定期的に記録し、その変遷を眺めていきます。人日という数字だけを見るより、はるかに多くのことが分かります。

インプットが上がっているのにアウトプットが上がらないなら、別の原因を疑う

これが、分けて見ることの最大の効用です。

スタッフがあまり作業に集中できていないという個人的な問題のこともあります。しかし、ディレクターの指示が曖昧で修正が重なってしまっているという、本人以外の側に原因があることも同じくらいあります。生産性というひとつの数字で見ていると、この区別がつかず、責任がすべて作業者に寄ってしまいます。

アウトプットは、多面的に評価する

初稿として提出された成果物だけを見るのは危険です。プログラマーであれば、修正の少なさや、後から手を入れやすいかというメンテナンス性も、立派なアウトプットの一部として数えるべきでしょう。

初稿の速さだけで評価すれば、直しにくい成果物が増えるだけです。

そして最後に、これがいちばん大事なところだと思っています。生産性は評価のための道具ではなく、状況を網羅的に把握するための指標にとどめておくのがよい、というのが私の考えです。生産性だけを追いかけると、どうしても一時的・部分的な対応に走ってしまうからです。

数字が下がったときに問うべきは「誰が悪いのか」ではなく、「アウトプットとインプットのどちらに、何が起きたのか」です。

生産性は、上げる前に分ける

ここまでの内容を整理します。

• 生産性 ＝ アウトプット ÷ インプット。上げる方法は、分子を上げるか分母を下げるかの二択しかない
• アウトプットを増やそうとすれば、たいていインプットも増える。都合よく分子だけを伸ばす方法はない
• IT・Web案件のインプットは工数（人日）であり、その中身はメンバーのスキルと経験
• 見積りと実績のズレは、生産性の見誤りとして表面化する
• 増員はインプットを二重に増やすため、短期的にはむしろ生産性を下げる
• 測るなら、合成された生産性ではなく、アウトプットとインプットを分けて測る

「生産性を上げよう」と言いたくなったときは、その前に一度、分解してみてください。アウトプットとインプットのどちらに手を入れる話なのかが決まるだけで、打ち手はずいぶん具体的になります。そして多くの場合、答えは「もっと頑張る」ではないところに見つかります。