SLOCとFPのあいだ

政府情報システム調達ガイドラインが2015年4月に改訂された。この改訂において、これまで最も大きく変わったところは、規模見積り手法にFP（ファンクションポイント）法を原則的に用いることが定められたところである。

「イ要求内容に設計又は開発に関する工程が含まれる場合には、原則として、ファンクションポイントの見積り及びその根拠 ※ガイドラインより引用　第3章「予算要求」の「2.経費の見積り」」

これが、見積り時に事業者より取得すべき事項として挙げられている。

本ガイドラインをきっかけとし、今後日本のシステム開発の規模見積りにFP法の適用が増えていきそうだ。しかし一方で、その本格適用には数々の課題が存在している。

FP法は規模見積りの手法の一つであるが、同じ規模見積り手法であるSLOC（Source Lines of Code、ソースコードの行数）方式で見積もった規模と例として以下の様な違いがある。

＜FP方で計測した規模＞

＜SLOC方式で計測した規模＞

どちらの手法も一長一短ではあるが、歴史的な経緯としてはこれまでSLOC方式での見積りを基本としてきた開発ベンダが多い。一方で、FP法はユーザ側の納得感向上の観点から導入を検討する組織も多かったが、少なくとも国内では浸透しきっていないのが現状である。

単に規模の計測方式を変えるという側面だけみると、見積り手法自体を変更することは容易だと思われるが実態はそうではない。SLOC方式からFP法への移行の難しさの原因には、日本のシステム開発における特徴が関係している。

要件がなかなか決まらない
まず挙げられるのが、FP法では機能要件が定まっていないと、精度が十分に出ないという点である。先のガイドラインにおいてもFP法が適用される時期は「予算要求」時点である。この時点で、ユーザ側が要件を詳細に詰められるかというとかなり難しい。
改修の影響範囲に対応するコストが多い
また、FP規模と工数の相関が特に捉えづらい改修開発が国内のシステム開発の多くを占めている。機能改良時用のFP法も考案されているが、開発工数と関係性については保証されているとは言えず、また、大型の基幹系改修案件ともなれば、改修先の母体の影響範囲の量、テスト範囲の量が工数見積りに非常に重要な要素となるが、この部分の計測は、これまで開発ベンダがSLOCを用いて推定していたものと比べると、精度が充分でないといえる。
規模に表さなければコストの合意形成がしにくい
FPで計上しない規模に関連する作業量を評価しにくいことも、FP法が敬遠される理由である。長年、規模と工数が一定の比例関係にあるという考えのもとコスト評価がなされてきた開発文化があるなかで、計上されていない規模に対する作業コストの合意形成は行いにくいのが実情である。

SLOC方式からFP方式に変えることは、ユーザ側の見積りへの納得性を高めるという利点はあるが、これまで以上にユーザ側にはシステム開発の知識が、ベンダ側には説明力の向上が求められる部分が存在する。

とは言え、IT業界においては、見積り根拠への妥当性についてはかねてより関心が高い（JUAS調査）。また、見積りの妥当性評価を積み重ねていくことは、ひいては適切なITガバナンス・投資戦略につながっていく。

ではそのような見積り妥当性評価はどうやって行っていくべきか。私は以下の取り組みが重要だと思う。

背景にある有識者の規模感・コスト感の可視化
例えば、「～～の画面の～～の項目を直したらXXXステップだ（ZZZ人日だ）」という感覚が、組織にいる有識者は持っているはずだ。SLOC、FPの値として表現される前のこの量感覚を共有化できれば、合意形成の非常に大きな武器となる。そのためにはCoBRA法や類似開発案件の見積り情報分析により、これらの感覚をデータ化し蓄積していくことが必要だ。
見積り値・実績値のライフサイクル管理
見積りは予算確保して終わりではなく、要件や前提条件の変化があれば見直され、完了時の実績との差異は次の見積りに活かされるべきだ。このようなデータドリブンなプロジェクト管理により、仕様の不安定さに起因するリスク度合いをユーザとベンダで共有していくことが、結果的に、ベンダ依存を解消し納得性の高い受発注に繋がる。

FP方式への移行は単なる規模表現の変更にとどまらない課題をはらんでいる。これをきっかけに業界として本腰をいれて取り組んでいくべきだ。