（2006/1/4 掲載)
今回の生産性の向上はリストラ効果日本経済新聞（1月3日）によると、日本の製造業の2003年の労働生産性は1990年比で1.5倍に向上しているという。しかしながらこの数字は手放しでは喜べません。同紙も指摘していますが、この数字は９０年代の激烈なリストラの効果であり、工場部門を中心に労働者の代わりに自動化を推進した結果です。同時に「製造業」の分類に関する統計上のトリックも一部含まれていると考えられます。
バブル崩壊を乗り切るための激しいリストラによって、たしかに生産性は向上しました。その効果として、企業の抱える「不良債権、過剰債務、過剰雇用」は解消（日本経済新聞）し、大企業の収益はバブル期を凌ぐまでになっています。最近の株価はその収益に反応しているのです。だがそうした過激なリストラを実施した結果、ベテランが持っていた「ノウハウ」を喪失し、それに伴って、今までなら起きなかったようなトラブルが頻発するという副作用を伴っていることも事実なのです。
結論から言えば、ここまでの生産性の向上は、労働者の作業技術そのものの改善に根ざしていないため、近い将来に頭打ちの状態になるだろうし、日本社会の高齢化の現実を考慮すれば生産性が低下する危険すらあると考えています。利益が出ている今のうちに、作業そのものの生産性を向上させる技術を確立する必要があるのです。
少子高齢化の中での日本の産業
日本では「少子高齢化」が叫ばれるなかで、2005年は出生者数が死亡者数を下回ったといわれています。いわば2005年は人口減少元年（元年は2004年という説もある）でもあるのです。人口の減少は戦争などではしばしば起きるのですが、今の日本の現象は平時の中で人口減少が起きているのです。人口の減少によっていろいろなところに影響が出ることが考えられますが、その一つがGDPが減少する可能性があることです。生産性が変わらなければ人口減少は間違いなくGDPの減少に繋がります。
GDPは資本主義社会では、豊かさを測る「一つの尺度」です。もちろん、豊かさはお金だけで得られるものではありませんが、大きな要素であることは確かです。「金は天下の回りもの」といいますが、GDPが減少するということは、回るお金が量的に減ることを意味します。もちろん、政策的にインフレを誘導すれば、見掛け上は回るお金は増える（減らない）のですが、“価値”を含めると減少するのです。
このような人口減少の中で日本の産業が求められているのは生産性を向上させることです。労働時間を増やさずに生産量を増やす技術を確立することです。その手段として、「自動化」という方法によって、少ない労働者で生産を維持することも選択肢の一つです。でも、全ての作業が自動化できるわけではありません。
たとえば、ソフトウェアの開発プロセスでいえば、関数仕様からソースコードを生成するプロセスは自動化しやすい部分なので、今後も自動化は進んでいくでしょう。それに対して、顧客や市場の要求を把握して表現する仕様化プロセスや、それを適切に実現するための設計のプロセスは、まだまだ自動化は難しい領域です。
特に、ソフトウェア開発における生産性が低い状態にあり、日本の製造業にとってっもこの生産性の低さがネックになる危険があります。ネックになるということは、ソフトウェア開発そのものが国外に流出する危険があるっことを意味します。したがって、ソフトウェア開発の生産性を大幅に改善することは、小子高齢化時代、人口減少時代において、もっとも重要なテーマであると言えるのです。
ソフトの比重が高まっている
汎用コンピュータやサーバー上で稼動するIT関係のソフトウェアやビジネスアプリケーションの世界では、ほとんどすべてがソフトウェアで実現しています。また、組み込みシステムの世界でも、その製品を実現するのに、ソフトウェアの支援を得なければならない部分が広がっています。携帯電話やカーナビ、DVD、デジタルTVなどは言うまでもありません。それらの製品に組み込まれているソフトウェアの規模は数100万行〜1000万行にも達するようになっているのです。自動車を制御するために組み込まれているソフトぅエアも、最近は500万行を超えるといわれています。
このような状態になると、製品のコストに含まれるソフトウェアの開発コストの割り合いはどんどん大きくなっていくし、ソフトウェアの善し悪しが製品の品質を決定する重要な領域になっていきます。つまり、ソフトウェア開発のコストが製品のコストに大きな影響を与え、ソフトウェアの“でき”が、製品の“でき”を左右し、メーカーのブランド戦略の主要な要素になるということです。
このような立場から現実のソフトウェア開発の現場を見ると、あまりにもお粗末な状態です。テストが不十分な状態で強引に出荷したものの、１週間も立たないうちに市場でバグが顕在化し、回収に走ったり、ダウンロードの案内を出すようなケースは数えきれないほど発生しています。多くの現場では、仕様化の遅れや稚拙な仕様、その影響を受けて頻繁に発生する設計プロセスでの手戻り作業によってテスト工数が食われているためにバグを見つけきれれないのです。こうしたトラブルの様子は、各メーカーのホームページで見える。
お粗末なのは、こうした家電製品などの組み込みシステムだけではありません。自動車のエンジンやミッションの制御プログラムにもミスやバグが現れはじめています。
東証では、誤操作を取り消す仕様が組み込まれていないなど、金融や証券関係のソフトも信用できない状態になっています。先の東証のトラブルでは直接的な損害は４００億円ですが、世界における日本の証券市場の信用喪失は金額に表わしきれないほど大きいのです。そしてこのトラブルは、単に東証の信用を低下させただけでなく、日本の「システム」に対する信用と、ソフトウェアに対する信用の両方の信用を毀損してしまったのです。
こうしたトラブルは製品やシステムに対するソフトウェアの比重が増加しているのに対して、精度の高い設計技術・開発技術の確立を怠ってきたことのツケが回っているのです。多くのソフトウェア開発の現場では旧態依然とした「力任せ」の開発方法がまかり通っています。適切な要求の仕様化技術を持たないため、その後の設計プロセスや実装プロセスを混乱させているのです。そして、こうした状況は、生産性を低下させ、収益を圧迫しています。このような状況が改善されなければ、今後の事業の継続すら危うくなることに気付くべきです。
ソフトの生産性を下げている主な原因
ソフトウェア開発の生産性を下げている要因としては幾つも考えられます。
その中でも最大の要因は２つです。
１）要求を適切に仕様化する技術を持ち合わせていないこと
２）要求を実現するための合理的なプロセスと成果物の連鎖を設計する技術を持たないこと仕様モレしにくい要求仕様書が書けないということは、レビューでも発見されにくいということです。当然、設計プロセス以降に入ってから仕様変更が頻発するのを押さえきれないし、設計や実装中でも気付かなかった仕様がQAテストの中で数多く発見されることになります。もちろん、仕様モレが多い場合は期間が圧迫された中でのテストでは発見しきれないバグが残り、不完全な状態で出荷したり顧客に提供することになります。
要求の仕様化が不十分な状態では、要求の実現性に対するリスク管理での対応が漏れてしまい、終盤になって、設計のやり直しなどの大きな手戻りが必要になるし、担当者のアサインでも失敗する可能性が高いのです。
一方、合理的なプロセスを設計する技術がなければ、効果的な成果物をイメージできないことになり、サイズに基づいた見積もりやスケジューリング、さらには“フィード・フォワード”を活用した進捗管理ができなくなります。何よりも、ゴールへの合理的な経路が見えないことから「間に合わないモンスター」に襲われ、必要なプロセスを省いて不用意にソースコードの実装に取りかかろうとするでしょう。そのような状態で、実装工程の中で、仕様確認や設計方法の模索などもミックスされるため、必要な成果物はほとんど残らないのです。
特に、派生開発では、変更点や変更箇所に関する情報は何も残さずにいきなりソースコードを変更してしまうために、事前に変更点についてのレビューもできません。その結果。最終的に必要なソースコードの変更行数の２倍近い行数をいじってしまうことになるのです。つまり半分はその後に変更し直しているということです。その結果、実装工程における生産性を著しく低下させてしまう。
「仕様化：設計：実装：テスト」で工数配分を見てみると、適切なプロセスを設計できない組織では、「１：３：３：３」か「１：２：４：３」の配分に近くなります。さらに実装工程における生産性も「１０〜２０行／時」という数字になって表れるのです。もちろん、最初の約束の納期はとっくに過ぎています。
でも私自身の経験と私のコンサルティングの中では「３：３：１：３」か「４：２：１：３」の配分になります（あくまでも参考のレベルです）。つまり、実装工程は、全体の１／８〜１／１２の工数で終わるのです。しかもコーディングの手戻りはありません（若干のバグで発生する程度です）。さらに、実装工程の生産性データは「８０行〜１３０行／時間」の生産性になります。さらに私のプロセスに慣れてくると「２００行／時間」にも達するのです。
そして、何よりも当初の納期を余して終了します。特に派生開発では、私が考案した独特のプロセスによって、納期を１０〜３０％余して終了します。はじめて取り組むチームでも１０％程度の納期の前倒しを達成することができるのです。私自身も「組み込みの時代」は、この派生開発プロセスによって、周囲の人と比べても５０％の工数で終わってきたし、平均して３５時間／週以上は投入していません。
また多くの現場では、後のプロセスの役に立たない成果物が数多く作られています。これも合理的なプロセスが設計できないために起きているのです。文書そのものは必要なものでも、中身が後のプロセスで活かされなかったり、必要な内容が書かれていないのです。各自のディレクトリーの中に不足を補うために「メモ」のような資料がたくさん残っているのはその証拠です。そのメモがあとのプロセスに活用されないということは、その成果物（メモを含む）を生み出した工数は回収できないことを意味します。こうして、活かされない工数が浪費されてしまうのです。
このほか、最初の段階での仕様化が甘いために、設計や実装のプロセスの中で仕様が明らかになる度に、すでに終わったはずの作業をやり直すことになります。調整の範囲が広い場合は、手戻り工数も１、２週間にもなってしまいます。この時点になれば、その手戻りは“不可欠”な作業ですが、最初に計画されていれば、やり方によっては１／１０以下の工数ですむことが多いのです。
そして、最終的には大量のバグで多くの時間を失ってしまいます。特に、デバッグと改修の工数は、事前には見積もられていないことが多いため、バグに関連する工数は全て期間オーバーの要因になってしまいます。例えば、20／KLOCのバグを出すとすれば、今回のプロジェクトで100K行を生成した場合は2000件のバグを出す計算になり、これにかかる工数も合計で8000〜10000時間に達することもあるのです。これが１／１０になれば、1000時間となり、２０人で取りかかっていれば１人で50時間ですむ計算になります。
このように、現状の開発プロセスにおいて至る所で大事な工数が無駄に使われているのです。そうして失われている時間（無駄な時間）は、全体の３０％を超えていると思われます。場合によっては５０％にも達していることもあるでしょう。
生産性を３０％UPできる
このような低い生産性しか出せない組織では、そこにいるエンジニアは疲弊することは言うまでもありません。そこでは納期のつじつまを合わせるために、１日の労働時間を増やすしかありません。でもそれはエンジニアとしてはまさに“自殺行為”です。
「技術を時代に合わせて更新できないエンジニアには明日はない」
これはソフトウェアのエンジニアに限ったものではありません。エンジニアとは、常に技術力の更新、革新を継続させなければならないし、そうでないと、エンジニアの役は勤まらないのです。
製造業は日本の経済にとっては生命線です。そこで作られる製品の中でソフトウェアの比重が急増していて、ソフトウェアの生産性の低さが目に余るということは、日本の製造業にとっては危険な状態にあると言いうことになります。目先の景気は回復しているように見えていますが、先述したように、これは燃え残った“炭”がリストラによって空気が流れたことで燃えているだけで、今後も燃え続けるための薪の中身はシロアリに食われてほとんど燃える力が残されていない、というのが私の見方です。
このような状況の中で、今の私の願いは
「日本中のソフトウェア開発現場で、生産性を３０％以上向上させたい」
ということです。そうでなければ、世界中に競争相手が出現する２１世紀には日本の製造業は崩壊してしまいます。1991年にCMMと出会ったことで、「私の方法」が理に適っていることがわかりました。そこで、それらの方法を整理して、1995年にプロセス改善のコンサルティングに転向したのですが、そこには、「私の方法」が、他の組織、他の人たちでも活用できることを確かめたかったということも含まれていました。もちろん、そこにビジネス・チャンスがあることは分かっていたのですが、それ以上に、私だけにしか出来ない方法なのか、そうでないのかを確かめる必要があったのです。
しかしながら、当時の私は「１外注エンジニア」に過ぎませんでした。「納期を外さないエンジニア」と評価されていても、それは私を知ってくれている顧客の中だけのことであって、それ以上の何の「力」も持っていませんでした。でも、1995年に「ホームページ」という手段が手に入り、それから１０年経って、雑誌や本にする機会を得ました。そしてこの１０年間のコンサルティングの中で「私の方法」が生産性を大幅に改善できるという成果も手に入りました。
これらの状況は、私に「次の一歩」を踏み出すことを求めていると判断し、「私の方法」をホームページや雑誌や本に公開することに踏み出したわけです。
その第１弾として、2004年4月に「Software People」vol.4に「要求の仕様化入門」を掲載し、昨年10月にまとめとして「要求を仕様化する技術・表現する技術」を単行本の形で公開しました。これは、生産性を低下させているおおもとの「要求の仕様化」に対する「私の方法」です。
そして第２弾として、2006年4月の「Software People」vol.8に「派生開発プロセス」を先行して公表します。これは、最近の派生開発におけるトラブルが相次ぐ中で、急いでこの場面に対応できる「私の方法」を公開することにしたものです。したがって、内容的にはまだ不足していますが、「派生開発プロセス」とはどういうものかは見えると思います。
そのあと、「PFD（プロセスフロー・ダイアグラム）を使ったプロセスの設計」から「進化するスケジューリング」に繋ぐ方法も公表する予定です。2004年10月の「Software People」vol.5に公表した「サイズ見積もりと進捗管理」は、この中の一部を先に公表したものです。（「PFDの表記法」は、すでに私のホームページに公開していますので、現時点ではそちらを御覧ください）
これらは、「私の方法」の中で、設計技法の影響をあまり受けないで、今後も活用できるものとして選んだもので、これまでのコンサルティングの中でも生産性を大幅に引き上げることができる方法として確認できているものです。
「派生開発プロセス」には、要求の仕様化からソースコードの変更までのプロセスが含まれていますので、派生開発のプロジェクトに対してほとんどそのまま適応できます。新規開発の場合は、「要求の仕様化」＋「プロセスの設計」によってそこで用いられる設計方法に繋ぎますが、いずれの場合も大幅に生産性が改善され、最初に求められた納期内に作業が終わっています（一部の例外はありますが）。
はじめて取り組むチームでも１０％程度の工数を余しているのです。これは、途中で新しい取り組みに対する戸惑によって１０％程度の工数の浪費を含んでの数字です。しかも単にカレンダー上で余っているのではありません。工数そのものが使われていないのです。このとき、従来のやり方ではカレンダー上でも明らかにオーバーしていたはずですし、工数的にも大幅に超過していたと思われます。
こうした状況から、ほとんどの組織において、「現状」に対して３０％の生産性を引き上げることは十分可能と判断しています。それぞれの組織におけるデータを見れば、３０〜５０％は無駄に浪費されているこが見えるはずです。まずは、工数を「３０％」改善することで、多くのプロジェクトは当初の工数（納期）で終わることができます。
そして、仕様変更率を５％以下に、バグの発生率を３件／KLOC以下に（設計者テストのバグと合計した場合は１０件／KLOC以下にすることを目指してください。これらの数字は要求の仕様化と合理的なプロセスの設計によって手に入るか、すぐそこまで手が届く状態になるはずです。
その上で、上記の数字をさらに改善できますし、新しい設計技術の修得にも取り組むことができます。組織をあげてのCMMへの取り組みも、このようなQCDを改善する技術を背景にすることで、組織全体にこの方法を展開することができます。
２１世紀の日本のソフトウェア産業、さらには製造業は、このホームページを御覧になったエンジニアの皆さんの手にかかっているのです。皆さんの作業の生産性が上がることにかかっているのです。私にできることは、皆さんにその「方法」を提供することです。
２００６年１月
「硬派のホームページ」主催者より