「ITを統べるためのヒント」の続きを書くことになった。今回は、数回分共通のテーマを掲げ、少し纏まった議論を展開したいと考えている。宜しくお付き合い願いたい。そこで今回から１０回分のテーマであるが、CIO諸氏が多分ご興味をお持ちであろう日本のシステム開発と生産性を取り上げることにする。筆者は、初期の混沌期から日本の標準的なシステム開発の流儀が確立し成熟する過程を実体験として過ごしてきた。そこで、筆者の手に余る問題かも知れないが、日本のシステム開発の実相をモデル化し解剖を試みてみたい。これまで、日本のシステム開発に関して、現実に即した分析にお目にかかったことがないような気がする。これが単なる筆者の不勉強なのであれば良いのだが、残念ながら、そうではないように思える。そこで、僭越ながら日本のシステム開発のやり方や生産性などに関して私見を述べてみようと考えている。まず議論の手始めとして、システム開発の現状を示す数値データの話から入ることにする。

求められる短納期・低コスト・高品質のシステム開発
　日本のシステム開発に関して、これまでも色々な意見が述べられてきた。曰く、「人月方式が諸悪の根源」とか、「ウォーターフォール型開発工程を止めないと改善はない」とか、あるいは、「諸外国はERPパッケージソフトを採用しているのに、日本では自前開発に固執しているのが問題」だとかである。このように、それぞれの立場から色んな意見が述べられてきた。しかし、筆者のように長年、システム開発に関係してきた人間から見ると、それぞれの意見は一面の真理は付いていても、それ以上の説得力を持ちえていないという気がする。それは、現状の日本のシステム開発の基本モデルをきちんと定義し、それをベースに議論するのではなく、評者の主観的な感性に頼った見解に過ぎないという印象を持つからである。また、議論の目的が不明確ということもある。つまり、何のために行う議論なのかがはっきりしないということだ。

　そこで、本稿での議論の目的をまず述べておくことにする。まず、CIO諸氏をはじめ世の中のシステム開発への根源的な要求は、現在よりも短納期・低コスト・高品質を実現できることと筆者は考える。そして、そのためにどうすればよいかを考えることが本稿の目的なのだ。つまり、Q(Quality：品質)、C（Cost：コスト）、D（Delivery：納期）の三つとも同時に改善するような画期的なシステム開発の実現をCIO諸氏をはじめ世の中は望んでおられるということだ。そして、その実現のために、現在の日本のシステム開発の特徴や問題点・改善点を議論するということである。

日本のシステム開発の完全成功率30％
　このような議論を始める出発点をどこにするかは大きな問題である。筆者は、できれば客観的なシステム開発に関する数値データを分析の出発点にしたいと考えた。しかし、皆様ご案内のように、社会が共有するシステム開発における客観データは余りにも少ない。多分、SI’er各社では詳細な自社の関係したシステム開発に関するデータをお持ちなのだろうが、それらのデータが外部に開示されることは稀である。そんな中で筆者が見つけた数少ないデータが表7-1である。このデータの出典は日本情報システムユーザー協会（JUAS）の「企業IT動向調査2006」である。このデータだけからいきなりものを言うのは、「データ不足」の謗りを免れないかもしれない。しかし、調査の標本数がそれなりの数のデータを前にして何も議論を始めないのは、これもまた非生産的なことと筆者は考える。そこで、この表から読み取れることを以下述べてみたい。なお、この表の上段は工期に関する回答であり、下段は予算に関する回答である。

＜JUAS2006調査から読み取れること＞
① 開発の規模が大きくになるに連れて、「予定通り完了」という完全成功の比率が低下している。
② 100人月未満の小さな開発でも、納期も予算も計画通りという完全成功率は3割程度に過ぎず、それよりも規模が大きくなると、徐々に逓減していく。
③ 「予定より超過」という自分でも「失敗」を認めざるを得ないケースが、小規模のケースでも2割前後あり、規模の拡大とともに増加し、500人月以上では4割を超える程度にまで拡大している。

　ここで、筆者は「完全成功」という言葉を使っているが、これはQCDの三つとも計画通りに成功することを意味している。また、この表からは、QCDの中のQ、つまり品質に関する情報は読み取れないが、ユーザーが検収したことをもって品質も検収基準を達成していると考えられる。そうなると、この調査での「予定通り完了」はQCD三つの要素とも計画通りに達成していると考えられる。つまり、このJUASデータが示すところは、システム開発では精々見積もっても「完全成功率30％程度」ということになる。一方、ものづくり一般の品質管理基準では、６シグマ、即ち、99.9999という9が６つも並ぶ品質レベルが達成目標となっている。今のシステム開発の現状は、残念ながらものづくり一般とは比べるべくもない低水準の計画達成にとどまっていることが分かる。

「好成績なのに評価が低い」日本のシステム開発の謎
　一方、日本のシステム開発は、世界と比較してどのような位置にいるのだろうか。つまり、世界のよその国に比べて、優れているのか、それとも劣っているのかである。少し古いが恰好なデータを発見した。表7-2を見て頂きたい。これは世界的なコンピュータ・ソフトウェア産業研究の第一人者である米国マサチューセッツ工科大学（MIT）のマイケル．クスマノ教授の手持ちデータである。なお、この表の中で下段の日本を1とした指数は筆者が追加したものである。まず、以下のように概観して分かることを上げてみる。

① 表上段の1人月プログラムコード行数であるが、日本は米国やインドに対して、2倍程度の生産を行っている。欧州に対しても優勢である。
② 表下段の1000行当たりのバグ数であるが、日本のバグの数は圧倒的に少なく、米国、インド、欧州に比べてほぼ一桁少ないことが分かる。

　このデータを最初に見た時の筆者の感想は、「日本のSEは圧倒的に世界一」というものであった。プログラムコードの生産性が高く、しかも、その品質が一桁高いということから、「日本のSEは世界一優秀」という結論に自然に結びつく筈である。とにかく、日本のSEが圧倒的に優秀で、大いに頑張っていることだけは確かなのである。しかし、このデータを引用した週刊東洋経済誌の記事では、「日本のIT産業に競争力があるとか日本のシステム開発が優れているという評価に繋がらない」と指摘している。そして、この記事では、「この論文は、日米の研究者の間で議論の的になっている」と結んでいる。つまり、客観的にデータを見る限り日本のSEが世界一優秀に見えるのだが、そのような評価にならないのは何故かという大きな謎が存在することになるというのだ。筆者は、このことを「クスマノ先生の投げかけた日本SEの謎」と呼んでいる。

ものづくり視点からのアプローチ
　さて、次には、特徴がはっきりしたこの二つのデータを出発点として日本のシステム開発を分析するための切り口を抽出してみよう。まず、システム開発も無形の人工物であるコンピュータ・ソフトウェアを製造するというものづくりの端くれである。そこで、先進ものづくりの視点からの解剖が可能ではないかと筆者は考えた。つまり、現状は精々完全成功率30％程度に過ぎないシステム開発のレベルアップを図るために、先進ものづくりノウハウからヒントが得られないかという視点である。そこから「システム開発をものづくりノウハウの目線で解剖する」というアプローチが浮上してくる。従来は、「システム開発は他の製造業とは異なる」と固く信じられてきたので、このような視点での分析が行われてこなかった。しかし、トヨタ生産方式（TPS：Toyota Production System）をシステム開発に導入しようという試みやその経験を記したいくつかの著作（注１）が散見されるようになってきた。従って、このようなものづくりノウハウからシステム開発を解剖する試みも無駄ではないと筆者は確信している。そこで、ものづくり一般を分析する手法の一つである設計を切り口にした分析を「日本のシステム開発を解剖する」と題して、今回を含め第12回までお届けする積もりである。

生産性論議からのアプローチ
　もう一つの「クスマノ先生の投げかけた日本SEの謎」を解くためのヒントを考えてみたい。まず「バグの発生率が低いこと」は、常にどんな形態のシステム開発であれ価値のあることで、この点での日本のSEの優秀さは疑うべくもないと考えられる。そうなると、「プログラムコードの生産性の高さ」が、本当に真のシステム開発の生産性の高さに直結するのかどうか。別の表現をすれば「システム開発の生産性とはそもそも何だ」という疑問が浮上してくる。そこで、本稿を書き進める二つ目の分析の切り口として、生産性を取り上げ「システム開発の生産性を考える」と題して、第13回以降の4回分で議論を展開する積りである。

　今回は、問題提起に終始したが、次回より具体的な分析に入ることにする。そして、次回のテーマは、そもそも設計とは何か、設計にはどんなタイプがあるのかを、ものづくり一般の観点から考察することにする。

（注1）：具体的には、以下の著作が出版されている。
『実践！！IT屋のトヨタ生産方式』富士通プライムソフトテクノロジ著　風媒社　2005刊
『図解　よくわかるソフトウェア・ジャストインタイム』前田卓雄・橋本隆成著　甲斐敏治監修　日刊工業新聞社　2005年刊