"作って終わり”にしない内製開発：FP法と生成AIで知を育てる

行政サービスのDX化が進む中で、自治体においても「内製開発」の重要性が高まっています。

外部ベンダーに依頼するのではなく、自らの手でサービスを設計・構築することで、現場の知見を反映しやすく、改善のサイクルも早く回せるようになります。

私はGovTech東京の職員として、こうした内製開発を支えるインフラ基盤やプロセスの整備に取り組んでいます。

私が前職のSIerで開発を行っていた時は、開発だけを行って検収をもらった後はお客様へ納品する、もしくは自社の運用・保守部門に引き継ぐということがほとんどでした。

いわゆる「作って終わり」です。
しかし、行政サービスの提供者になれば、内製開発は単に “外注せずに自分たちで作ること” ではありません。自分たちで作ったものも外注で作ったものも作ったあとの面倒をみていく必要があります。

本質的には、

“自分たちで開発した経験から得られた知見を活かし、プロダクトの品質・開発のプロセスを継続的に改善していく活動”

だと考えています。

この活動を持続可能なものにするためには、過去の開発データの蓄積と活用が不可欠です。

蓄積されたデータを活かすことで、将来の開発における工数見積もりやリスクを事前に予測し、より良い意思決定につなげることができます。

本記事では、内製開発でどのようにすれば「知（データ）を育てる活動」を行うことができるかを考えていきます。

開発データ──比較に適した指標とは？

過去の開発データというと、工数（人月）を思い浮かべる人が多いのではないでしょうか。私も前職のSIerでは、工数（人月）をデータとして良く目にしていました。

工数（人月）という値は、プロジェクトに関わったメンバーのスキルやお客様の関与度、システムの構造的な違い、ドメインの違いなど様々な外的要因の影響を受けます。

例えば、

• スキルのあるエンジニアを多数アサインできたから、プロジェクトが滞りなく進み少ない工数で開発できた。
• お客様の関与度が低く、プロジェクト終盤になって大きな修正が入ってしまい工数が増大した。

などの経験はありませんか。

工数（人月）というのは、比較を行う上でのデータとして最適といえるものではありません。

そこで注目したのが、システムの構造的な違いやドメインの違いに依存せずに機能の複雑さを定量化できる「ファンクションポイント法（FP法）」です。

FP法とは？──技術に依存しない“機能の複雑さ”を測る指標

FP法（Function Point Method）は、ソフトウェアの機能規模を定量的に測定する手法です。

FP法では、ソフトウェアの基本的構造である
”入力→処理（変換）→出力”
に観点を置いて計測するため、先述したプロジェクトの外的要因やプログラミング言語やアーキテクチャなど内的要因の影響を受けずに規模を測定することができます。

ソフトウェアの基本的な構造

具体的には、システムの機能を以下の5つに分類し、それぞれの複雑さに応じてポイントを割り当てます：

• 外部入力（EI）：入力フォームなど、ユーザーが入力する情報
• 外部出力（EO）：帳票や入力確認画面など、システムが返す情報
• 外部照会（EQ）：検索画面など、情報の参照機能
• 内部論理ファイル（ILF）：ユーザー情報など、システム内で管理されるデータ
• 外部インターフェースファイル（EIF）：他システムと共有するデータ

FP法は、機能が扱っている情報に着目することで、技術的な詳細にとらわれず、共通の指標で構造を比較・分析できるようになります。

※詳しく知りたい方はITシステム可視化協議会（旧日本ファンクションポイントユーザ会）にある概要ぺージの説明などをご覧ください。

組織におけるFP法の有効性

GovTech東京では、東京都や都内区市町村からの派遣職員、民間出身のエンジニア、デザイナーなど多様な専門性を持つメンバーが集まり、公共サービスの内製開発を推進しています。

開発に関する知識、認識がメンバーごとに異なるため、共通の“ものさし”として機能する指標が不可欠です。

FP法は、技術に依存しないため、多様なバックグラウンドを持ったメンバー間の共通言語として機能し、システムの構造を読み解くツールとしても有効です。

例えば、

機能名	説明	工数（人日）
〇〇情報登録機能	〇〇情報を入力し、保存ボタンを押下すると入力した値がデータベースに保存される	1.5
△△情報登録機能	△△情報を入力し、保存ボタンを押下すると入力した値がデータベースに保存される	0.5

よりも

機能名	説明	工数（人日）	外部入力	内部論理ファイル	FP値
〇〇情報登録機能	〇〇情報を入力し、保存ボタンを押下すると入力した値がデータベースに保存される	1.5	10	3	15
△△情報登録機能	△△情報を入力し、保存ボタンを押下すると入力した値がデータベースに保存される	0.5	5	1	5

と表現した方が、全員が同じ登録機能でも構造の違い（複雑さ）があることを理解しやすくなります。
FPという共通の“ものさし”によって、開発データを正しく理解・利用することできます。

FP法の課題と生成AIによる解決案

FP法はシステムの構造の違いを定量化できる有効な手法ですが、実際の運用には課題もあります。

• FP値の算出には専門知識と時間が必要な点
• 設計がある程度進まないと、必要な情報が揃わない点
• 担当者によって判断がばらつき、属人化しやすい点

こうした課題へどう取り組んでいくか、私は1つの方法として生成AIを利用したアプローチを思いつきました。

GovTech東京では、生成AIを活用したアプリケーションを簡単に作成できる共通基盤（生成AIプラットフォーム）を整備しています。
私自身もプラットフォーム上で、生成AIを日常的に活用して業務を行っています。

自分で作成したチャットBOT（広島弁で回答してくれたり、雑談にものってくれるようにプロンプトを作成しました。）

FP法のような構造的な知識を生成AIに学習させることで、FP法の課題をクリアし、さらに進んだ意味ベースでの設計支援や資産管理を実現することが可能になるのではないかと考えたのです。

例えば、自然言語で書かれた要件定義書や設計書から、機能の“意味”を読み取り、FP分類（EI, EO, EQなど）を推定することができます。さらに、過去の類似業務との比較により、FP値の仮見積もりや設計資産の提案も可能なはずです。

自然言語から“意味”を読み取り、FP分類を推定する

生成AIは、自然言語で書かれた要件定義書や設計書から、機能の“意味”を読み取り、FP分類（EI, EO, EQなど）を推定することができます。

その際、特に注目するのが動詞です。

「登録する」「表示する」「参照する」「送信する」などの動詞は、機能の性質を表す重要な手がかりになります。

例えば、以下のような要件定義の一文があったとします

ユーザーは申請フォームに氏名・住所・口座情報を入力し、申請ボタンを押すことで申請が完了する。申請後は確認画面に申請内容が表示され、通知メールが送信される。

この文章から、生成AIは以下のように動詞と対象データを抽出し、FP分類を推定します。

動詞	対象	FP分類	意味
入力する	氏名・住所・口座情報	EI	ユーザーが情報を入力する機能
表示する	申請内容	EO	入力内容を画面に出力する機能
送信する	通知メール	EO	メール通知を行う機能

動詞の意味と対象データの関係から、生成AIによってFP分類を自動的に推定することができます。さらに、入力項目数や処理の複雑さなどを加味することで、FP値の仮見積もりも可能になります。

これにより、設計が固まっていないプロジェクトの初期段階でも、システムの構造理解と見積もり支援が実現でき、また分類の判断を生成AIが行うので属人性の排除にもつながります。

さらにFP値を単なる見積もりのための数値としてではなく、意味づけされた構造データとして蓄積していくことで、開発資産としての価値が生まれるのです。

今後の展望──FP法と生成AIがつなぐ“知”の循環

FP法と生成AIの連携は、内製開発における品質の確保と価値の創出、そしてリスクの予測・回避までを一貫して支援する可能性を秘めています。

私は、GovTech東京でこうした技術的な可能性を理論にとどめることなく、実践を通じて価値に変えていくことを目指しています。

FP法を組織の共通言語として活用し、生成AIによってその意味づけを深めることで、エンジニアと業務担当者が同じ視点で議論できる環境を整え、内製開発の継続性と再利用性を高めていきたいと考えています。

今後は、こうした取り組みをさらに発展させ、

• 設計テンプレートの標準化：FP分類ごとに設計資産を整理し、誰でも使える形で蓄積
• ナレッジ共有：類似業務の構造を比較し、再利用可能な資産として共有
• 住民ニーズに即したサービス設計の高速化：意味ベースの設計支援により、現場の声を迅速に反映

といった取り組みを実現できたらと考えています。

現在は、その第１歩として

• 既に内製で開発が行われたサービスの仕様書から実際にFP値を計測し、実際の工数との紐づけを行ってみる
• 仕様書をセマンティックチャンキングし、そこからFP値の自動算出が可能か

などの活動を始めています。

“作って終わり”ではなく、“作った知を育てる”内製開発を実現し、開発力とサービス品質の底上げに貢献できればと思います。