パフォーマンス基準時間の概念 (2009/07/17)

オフショア開発が米国のIT業界で広まりはじめたのは、いまから10年ほど前のことだったと思う。当時私は、米国の制御システム・インテグレータをつかって、メジャーオイル向けに工場のDCSとMESを納入する仕事をしていた。私のグループはMESを担当し、隣の部の同僚たちはDCSを担当して、それぞれ仕様をとりまとめ、同じ米国のインテグレータに詳細設計と実装をさせるやり方をした。彼らはMESの方は米国内のサブベンダーをつかってとりまとめ、一方DCSの制御ソフトはインドの子会社をつかって開発していた。とはいえ、彼らにとってもインドのリソースを使うのは初めての挑戦だったらしく、おかげで納期の面でも品質の面でもかなり苦労をさせられた。

その2,3年後、私はフランスの会社と共同で電子調達サイトの仕事をしていた。こちらの方は、米国の最大手ERPベンダーが基本テクノロジーの提供者だった。シリコンバレーの本社で相手のディレクターと何度か話し合ったが、彼が「インドをつかえ。」としきりに強調していたのが印象に残っている。このころはちょうど米国のITバブルが崩壊した直後で、米国に出稼ぎに来ていたインド人技術者がかなり本国に帰っていた時期だったと思う。このころ、我々の会社も、社内システムを作るために、インドのIT企業をつかってオフショア開発をはじめていた。ちなみに、’90年代後半にはすでに、エンジニアリング業界ではプラントの詳細設計業務をアジアの子会社にやらせるようになっていた。

それからさらに3年後、私は中国に子会社をもつ日本のIT企業と一緒に、システム開発のプロジェクトを進めることになった。日本企業の間で中国でのオフショア開発がブームになり始めたのは、ちょうどその頃ではなかったか。中国人はチーフ・クラスでもなかなか英語が通じず通訳・翻訳経由となるので閉口したが、近くて時差がほぼないため会議がやりやすい(あるいは現地に乗り込みやすい)というのはメリットだった。

オフショア開発やオフショア設計にはいろいろなパターンがある。が、発注形態の面で見ると、大きく2種類に分けられる。一括発注(ランプサム契約)と、工数精算(マンパワー・サプライ契約)だ。海外のSIerに仕様を与えて、できた製品を受け取るのは、前者のやり方だ。海外子会社に設計や実装段階の仕事を分業させる場合は、後者の形態が多い。両者の最大の違いは、マネジメントの責任、とくに工数管理の責任が、発注側にあるのか受注側にあるのか、にある。

一括発注の場合は、いうまでもなく、工数管理の責任は受注者側にある。最初に、仕様と金額と納期を決めたら、あとは品質をみたす製品を納期通りにおさめる責任は相手側にある。見積を間違えて大勢を追加投入するハメになっても、受注側は自己負担するしかない(発注側に仕様変更等の不手際がない限り)。この点、発注先にしっかりとしたマネジメント能力がありさえすれば、一括発注はある意味で気楽だと言えるだろう。そして大事なのは相手側のマネジメント能力を評価する手法ということになる。

一方、工数精算の場合は、マンパワーの追加投入の事態が生じたとき、責任は主に発注者側にあると考えられる--受注者側によほどの非効率がない限り。そう。そしていつもトラブルの種になりがちなのは、この効率の問題なのである。

マンパワーの効率とは何だろうか。それはすなわち、人時あたりの生産性である。同じ仕事を、Aさんがやったら1時間かかり、B君がやったら3時間かかる、としよう。このとき、AさんはBさんの3倍の生産性があることになる。

生産性とは、(前にも書いたが)次の式で定義される(等幅フォントで見てください)。
      産出量
 生産性=-----
      投入量

同じ産出量(成果物)に対して、投入する人時が3倍になったら、生産性は1/3になる。きわめてシンプルな式である。

では、海外子会社に分業で仕事をさせるとき、必要な人時はどう見積もるのか? 当然、生産性の概念が必要になる。このとき、日本の親会社でやれば 500人時ですむはずの仕事を、その子会社でやるときは、生産性が(たとえば)0.5倍なので1,000人時の工数がかかるだろう、という計算になる。この上さらに、子会社の進捗コントロールやコミュニケーションのために、親会社側で必要になる「マネジメント工数」が加算される。それでも、『給料の高い日本人』を使うよりはずっと安い、浮いた時間はもっと高度に知的な作業につかえる、という計算が成り立つから、海外との分業を選んでいるはず、なのだと思う。

これが成り立つためには、二つの条件が必要だ。まず、子会社の生産性の測定方法。そして、「最善の生産性でやったらxx人日かかる」という、工数見積の基準である。これをパフォーマンス基準時間の概念と私は呼んでいる。

SEやプログラマの生産性は人によって3倍以上も違う、という話をIT業界ではよく聞く。この業界の人が好きな話題らしい。そうかもしれないな、と私も思う。ところで、その個人別生産性の具体的な数表を、私は一度も目にしたことがない。ウチの会社では、生産性の個人差は最大4.7倍もありました、というような定量的な話をついぞ聞かないのである。まあ、これは私の見聞の範囲が限られているからかもしれない。たいていのまともな会社は生産性についてきちんと測定していて、ただ社外秘だから出せないだけなのだろう。

ところで、基準となる工数見積の方は、どうだろうか。上の式を見てほしい。これを計算するためには、産出量(作業量)を測る尺度=BOQが必要である。産出量がこれこれで、基準生産性がこの値だから、基準工数は何人時になる、という計算になる。これは、実装だとかテストといった「力仕事」の場合、計算しやすい。だが詳細設計やデザインの場合、それなりの工夫が必要である。

そして、よく見かける間違いは、ここにマンニング計算を用いてしまうことだろう。マンニングというのは、縦に職種、横に週や月の並んだ表を作って、“だいたいこの時期は何人が必要になるはずだから~”と数字を入れ込んで人時を集計する方法である。これでは、作業量の基準として工数をとっていることになってしまう。だから、マンニング計算は体制表のチェックには有用だが、工数見積の根拠にはならない。工数を作業量と生産性に分解する。工数自体は仕様で決まるため、簡単には変えられない。だが、生産性は向上させることができ、それが競争力の源泉となる。

こんな当たり前のことをわざわざ書いているのは、生産性という概念が、製造現場を離れると、忘れられやすいからである。デザインは非定型的な仕事なので見積もれません、みたいな主張が、すぐ現れてくる。だが、見積もれない仕事に、企業は給料を払える訳はない。もし競争力を向上したいのなら、多少強引にでも時間と生産性を測るべきなのだ。測れないものは、カイゼンできないからである。