JUAS『ソフトウェアメトリックス調査2014』を読み解く

まず、ちょっとこのグラフを見てほしい。
e0058447_20145718.gif

「何だこのグラフ。点がバラバラに散らばってるだけじゃないか。」
--そんな反応が多いだろうと思う。一応斜めに直線を引いているけれど、点はその線上から、ほとんど倍半分のいきおいでずれている。無理やり引いているだけで、法則性があるとはとても言えないな。誰だよこんなグラフ作ったの・・。

だが、このグラフ、わたしはとても面白いと思う。これは、「一般社団法人 日本情報システム・ユーザー協会」、通称『JUAS』が独自に行った調査の結果をグラフにしたものだ(JUAS発行「ソフトウェアメトリックス調査2014」p.66よりスキャンして引用)。グラフの横軸は情報開発プロジェクトの全体工数。単位は人月だ。そして縦軸は、プロジェクトの全体工期(=期間の長さ)で、単位は月数である。図上に散らばった多数の点一つ一つは、個々のプロジェクトを表す。

なお、よく見ると横軸は一定間隔ではない。10の隣が100、一つおいて500、1000(人月)という具合に、ちょっと奇妙な間隔に見える。実はこれは工数の立方根を横軸としたグラフになっているのだ。そして、図中に引いてある回帰直線は、
 y = 2.50 x^(1/3)
という非線形な関係を表している。すなわち、
 (全体工期)=2.50 * (全体工数の1/3乗)
になっている、事を意味する。

つまりプロジェクトの全期間の長さは、それにかける必要工数の1/3乗におよそ比例する。この式によれば、たとえば00人月の工数がかかるプロジェクトでは、
 2.50 * (100^0.33) = 11.6ヶ月
かかるだろう、という予測が成り立つ。200人月なら、14.6ヶ月だ。

JUASの2014年度調査は、会員企業からのアンケート調査で集められた累計1,076件のプロジェクト実績データを分析している。ちなみにこのグラフにプロットされたデータ数は407点。条件は、ウォーターフォール法で進められた再開発・改修プロジェクトで、FP(ファンクション・ポイント)値が3000以下またはソースコード量が330,000行以下のものだけを抽出したグラフである。なお図中に R2=0.86 と書かれているが、このR2は統計学で「決定係数」と呼ばれ、回帰式で説明できる分散(バラツキ)の割合を示す。プロジェクト全体期間の長さは、バラバラであるが、その86%が「全体工数の1/3乗」との関係で決まる、ということをおよそ意味している。

たしかにグラフの見た目は、ひどく点が散らばっている。しかし、これは社会調査的な結果であることを考慮するべきだろう。そして、この「1/3乗則」の関係は、再開発・改修のプロジェクトだけでなく、新規開発プロジェクトだけのデータでも成り立つし、全プロジェクトに対してもほぼ成り立つことが、JUASの同じレポートで示されている。式の比例定数は2.67だったり2.56だったりするが、大きくは違わない。決定係数も、0.85前後だ。つまり、「一般に情報開発プロジェクトの全体期間は、それにかかる工数の1/3乗に比例して決まる部分がかなり大きく、それは新規開発でも、既存システムの再開発・改修でも、あまり変わらない」という、非常に示唆に富んだ統計的事実が分かるのである。

これが、データの力である。正確には、データを蓄積し、それを読み解くことによって得られる力だ。最近はビッグデータというバズワードが大流行だが、データ件数が1,000程度ではスモールデータだろう。しかし、このグラフの点一つひとつが、どれほど多くの人の労力と汗と涙の結果で得られたか、その重みを考えてみてほしい。そして、こうしたデータ調査を毎年、ITユーザ企業に対して行い、結果を解析する仕事をJUASは10年近くにわたって継続している。この努力と姿勢に、わたしは率直に敬服する。

わたしがJUAS(日本情報システム・ユーザー協会)という組織のことを知ったのは、つい近年である。同じ『ソフトウェアメトリックス調査』2013年版を見てからだ。中身を見て、驚嘆した。膨大なデータを会員企業からアンケートで集め、戦略を持って分析している。その文章にも明確な主張があって、面白い。すなわち、ソフトウェア工学という重要な、しかしいまだ薄弱な工学を進歩させて実務に役立たせるためには、現実のデータに基づくベンチマークが絶対に必要だ、との主張である。いわゆる業界団体だとか役所の外郭団体が定期的に出すA4サイズ簡易製本のレポート類は、めったに面白いものがないという印象が強かったのだが、これだけは違った。

たとえば、システム開発に使用する言語については、こんな結果になっている(p.45):
- COBOL 17.2%
- C 13.8%
- VB 13.1%
- PL/SQL 16.8%
- Java 46.9%
- HTML 8.0%
現在、半分近くのシステム開発はJavaで行われており、その比率はまだ伸びている。だがCOBOLもいまだ17%、PL/SQLも17%と、微減ながら現役である。CやVBよりもまだ多い。これは調査対象企業が製造業・流通業など一般企業で、その大半が業務系システムであることも大きく影響しているだろう。

なお、パッケージソフトを利用した開発は全体の10.4%にすぎない(p.43)。9割近くのシステム開発が、スクラッチから書いているのだ! 2013年調査では17.5%、2012年度は18.3%だった。つまりパッケージソフトの利用は、むしろ減少しているのである。かつて2000年頃のITバブル期、ERPブームの時代には、パッケージを使わない奴は馬鹿みたいなことを、世間では喧伝していた。いま、その風潮はひっそりと、だが明確に反省期に入っている。

システム開発のプラットフォームでは、こうなる(p.44):
メインフレーム=22.6%、オフコン=1.2%、Unix=33.2%、Linux=21.4%、Windows=52.8%。
これはマルチアンサーだから合計は100%以上になるが、オフコンを含む汎用機がまだ十分現役であることにも、少し驚いていい。システムのアーキテクチャでは、
汎用機:21.2%、C/S:26.6%、Web:68.2%。
この比率は2013年度からほとんど変わっていない(p.44)。クラサバもまだ根強いなあ、との印象である。上の結果とあわせると、現在でも業務系システムはその多くが、JavaでWebベースで、かつスクラッチから書かれている。某社の某基幹システムを思い出して、ううむ確かに、などと思ってしまう。

しかし、ここら辺はまだ序の口だ。JUASはできあがったシステムの品質についてもたずねる。彼らの品質(欠陥率)の定義は、
 欠陥率=(顧客側総合テスト~フォローのフェーズで発見された不具合数)/(プロジェクト全体工数)
である(p.76)。UAT以降のバグ数を、人月あたりで割り算したものだ。この指標の立て方には異論もあると思う。だが、ユーザ企業から見ると、とても実質的で分かりやすい。このモノサシをたてて、彼らは経年変化を調べている。その変化は、緩やかだ。つまり一定の統計的傾向があるのだ。その中央値は0.20、平均値は0.58である。そして過去8年間に、平均値は1.00から0.20へ、また中央値は0.35から0.18へと、おおむね減少してきた。

ソフトウェア開発の品質は、次第に、だがかなり決定的に、向上しているのだ(バグをABCランクで重要度の重み付けをした数値については、報告書を参照してほしい)。それだけではない、「品質については、要件定義・設計・実装の各フェーズがすべて請負・請負・請負の契約のものの品質が明らかに悪い」(p.191)と大胆にも分析している。『業者にお任せ』型の開発は、よい品質を生まないのだ。

ソフトウェア開発の生産性はどうか。パッケージ開発以外で、かつIFPUG法で計測した127プロジェクト(うち新規開発と改修・再開発はほぼ半々)について、人月あたり全体の平均は約11 FPだった。ファンクション・ポイントではなく、単純に画面数と帳票数から全体工数を推算する式も出している(p.148)が、補正決定係数は0.34なので、あまり精度はよくない)。

JUASの調査は開発だけでなく、運用保守まで対象に入れている。自社開発システムの稼働後の開発費用・保守費用の比率では、稼働までの開発費用を100とした場合、初年度には平均して追加開発費が19.4%、保守費が8.5%かかっているという(p.196)。年間IT総予算の中の運用費用の割合も、大企業の場合は55%に上る(p.245)。なお、情報子会社の保有状況を見ると、子会社ありが19.7%、なしが80.3%である(大企業に限ると、保有比率はもっと高くなる)。

また今年度から、「マスターデータ管理」ならびに「アジャイル法と超高速開発法」についての質問も追加されたらしい。マスターデータ管理では、「導入済み」企業が8.7%であるのに対し、「未検討」はまだ70.6%だ。開発方法論では、2014単年度の回答集計ではウォーターフォール法が101件であるのに対し、アジャイル法7件、超高速開発法が47件だ(p.47)。500万円以上のプロジェクトを対象としているわりに、思ったより新しい手法が多いと、わたしは感じた。ただ、調査開始以来の累計データでは、まだ9割以上がウォーターフォールである。データ件数がまだ少ない上に、今回は品質データがとれていないため、一番興味ある「新しい開発手法の品質満足度はどうか」が分析されていないが、これは次年度以降の課題だろう。

このほかにも、まだまだ紹介しきれないほどたくさんのデータと知見が詰まった本である。この調査は経産省からJUASが受託して行われたものだが、世界的に見てもこのレベルの調査をオープンにしているところはあまりなく、欧州からうらやましがられているとも書かれている。これはひとつには、日本の経済規模が大きいため、それなりに多数のユーザー企業が存在することによるものだろう。ソフトウェアのメトリクス(計量指標)に興味ある人々にとって、必携の参考資料だと言えると思う。とくに、繰り返しになるが、JUASのこの調査報告書には明確な『主張・思想』のある点が、読んでいて小気味よい。こうした報告書では希有の体験である。

ところで、最初にあげたグラフから、工数の立方根と全体プロジェクト期間の関係を導くような分析アプローチに対しては、当然、疑問や批判もあるだろうと思う。上記の式はマクロな関係を示しているだけだから、もし誰かが、“全体工数は100人月だから期間は11.6ヶ月でスケジュールを作成しました”、などといって計画書を持ってきたら、わたしは「まずきちんとWBSから具体的スケジュールを組んで持ってこい。」とつっかえすだろう。その上で、推算式はバックチェックにつかうはずだ。森を見るマクロな視点は、木の枝を見るミクロな作業の積み上げにおいて、何かクレイジーな勘違いをしていないかをチェックするためのものだ。あるいはせいぜい、ごく初期の段階での超概算見積などに使う程度だ。使い方を間違えてはいけない。

しかし、もっと根本から疑問を呈する人もいるかもしれない。「法則性と言うにはあまりにもバラツキが多く、精度が悪い。それに、プロジェクトというのは元々、ユニークで個別な存在だ。だから、過去データから見てこうなるはず的な議論はナンセンスだ。」 

この反論は、よく見ると二つの別々の意見から成り立っている。まず、「法則と言うにはバラツキが大きすぎる」という意見。これはいいかえると、精度が高ければ法則として使う、という立場を表している。ところが後半は違う。「プロジェクトはすべて個別でユニークな存在だから、過去を参考にするよりも、自分の意思が大事だ」と言っている。この立場から見れば、そもそも法則性などというものは認めないことになる。だからこの二つは、実は並び立たない両極端の意見を表している。

前者の立場を、ここでは「科学法則主義」と呼ぶことにしよう。これは、電気におけるオームの法則のように、厳密な関係性を求めている。たしかに冒頭のグラフは点のバラツキが大きい(だからワザとこれを引用したのだ)。おそらくプロジェクトの全体工期を決める要因としては、工数以外にまだ大事な変数があって、その要因が層別し切れていないために、このようなバラツキを生んでいるのではないか、とも考えられる。他方、後者の立場を「個別主義」とここでは呼んでおく。プロジェクトはすべてユニークだと考える立場だ。この立場ではリーダーの気合いやパッションを重んじる人が多い。

いずれの立場も、主義主張であるから、それ自体が正しいとか正しくないとかは簡単に議論しがたい。しかし、この両者は両極端であるにもかかわらず、不思議な共通点がある。それは、JUASが苦心惨憺して集めた過去のデータは価値がない、と見る点だ。JUASのこの報告書の著者は、科学法則主義でも個別主義でもなく、その中間の立場にいる。そして、過去のデータはそれなりに参考になるし、価値があると考える。過去のデータの価値をどれだけ認めるかを模式的なグラフにしてみると、両端がゼロ(無価値)で、真ん中が盛り上がる形になっているにちがいない。

e0058447_1921038.gif


そして、わたしもJUASの著者と同じ立場である。過去を知り、過去のデータに学ぶことには、とても大きな価値があるのだ。科学法則主義と個別主義は、たとえているならば二人の登山家であろう。山の中で道に迷って、日もとっぷり暮れてしまった。正しい道を探しているのだが、科学法則主義者は「磁石が不正確で正しい方位を指さない」といって途方に暮れ、個別主義者は「そもそも方位なんてものは当てにならないのだ」と文句を言っている。それだったら、他人の足跡を探せばいいじゃないか、とわたしは思う。足跡の集積が、道になるのだ。他人の経験に学ぶことこそ、わたし達が賢くなる一番の早道ではないだろうか?
by Tomoichi_Sato | 2015-03-28 19:08 | プロジェクト・マネジメント | Comments(0)
<< ロボットとして生きないために 書評:「『戦略』決定の方法 〜... >>