コラムColumn

　見積りの要素技術の１つであるファンクションポイント (FP: Function Point) を適切に計測できることを認定する国際資格が CFPS (Certified Function Point Specialist) です。この資格は FP の普及推進団体である IFPUG (International Function Point Users Group) が運営し、その日本支部である「ITシステム可視化協議会 (MCIS: Measurement Council for IT Systems, Japan)」も協力しています。

　CFPS を20年間保持すると、CFPS Fellowという上級資格が IFPUG により認定されます。筆者は日本人で唯一の CFPS Fellow に認定されており、日本一 FP に精通していると自負しております。本コラムでは、CFPS Fellow に認定されるまでの筆者の活動を振り返りつつ、見積りや FP の技術的側面に触れていこうと思います。

　筆者が FP の存在を知ったのは、1994年の晩秋の頃でした。当時のITシステム/ソフトウェアをめぐる状況は、パソコン(PC)が企業に入り始め、実務者の手元にあるクライアント PC と業務を司るサーバー PC をネットワークで接続する、いわゆるクライアント/サーバーシステム（C/Sシステム）が登場しました。開発技術の面では、Visual Basic (VB) 等のC/Sシステム向け開発支援ツールにより、開発の進め方が従来と大きく変わっていった時期でした。こういった変化は当時「ダウンサイジング」と呼ばれていました。

　この変化は、見積りに大きな混乱をもたらしました。それまで、ソフトウェア規模のメトリクスは、ソースコード行数である SLOC (Source Lines Of Code) が主流でしたが、C/Sシステム向け開発支援ツールは、画面を GUI で作成でき、ソースコードの作成量が従来よりもはるかに少なかったので、従来の感覚では SLOC が見積れなくなりました。SLOC は見積りのベースとなるメトリクスなので、工数や他のメトリクスの見積りも難しくなってしまいました。

　それに加えて、ソフトウェア開発の生産性を測定する観点でも問題がありました。C/Sシステム開発は、従来の開発に比べて明らかに生産性が高かったのですが、当時主流だった生産性メトリクスである SLOC/人月 で測定すると、従来の開発より生産性の数値が低くなる場合があるという、感覚に反する結果になったのです。これも、C/Sシステム向け開発支援ツールのソースコード量の少なさに起因していました。

　そんな、見積りや生産性測定の問題に苦慮していた頃、後に日本ファンクションポイントユーザ会（JFPUG、現 MCIS の旧称）の初代会長を務めた、当時 NTT の西山茂氏に FP をご教授いただきました。筆者は FP のコンセプトに強く共感し、すぐさま筆者が当時所属していた日立製作所で FP の適用検証に取りかかるとともに、JFPUG に法人会員として入会しました。

　FP が素晴らしいと感じた点は、ソフトウェアの機能を論理的に捉えて点数化するしくみにより、プログラム言語や開発支援ツールに関係なくソフトウェアの大きさを比較でき、生産性を的確に表現できることです。生産性のメトリクスに FP/人月 を用いて調べると、従来の COBOL による開発と比べて、VB による開発は（当時調査した範囲で）5～10倍という高い生産性を示しました。この生産性の高さを数値で確認できたことは、ダウンサイジング開発技術の推進を加速させる一因になったと思います。

　ここまでは今から30年前の状況を振り返りましたが、現代はどうでしょうか。近年、ローコード/ノーコード開発が増えていますが、この開発におけるソースコード量の少なさは VB の比ではありませんので、SLOC 適用は不可能でしょう。こういった開発技術の進展により、実装形態が多様になってきた現代において、FP の果たす役割はますます大きくなると筆者は感じています。

※このコラムは全４回を予定しています。