はじめに
ソフトウェア開発プロジェクトにおいて、適切な工数見積もりは成功への重要な一歩です。しかし、見積もりは見積もりした人によって異なることがあり、問題となっています。筆者自身も何度か見積もりをしたことがありますが、見積もりをした時期によってバラバラな見積もりを出すといったことになってしまっている状況です💦。また、見積もり業務自体が特定の有識者に常に集中してしまうといった問題もあります。それを避けるための方法として、ファンクションポイントを使って定量的に見積もりする方法があります。
今回は、ファンクションポイントを使ってどのような観点で項目を見積もりするべきか、私なりのアイデアをまとめてみました。これが全てではないと思いますが、各プリセールス、プロジェクトマネージャー、エンジニアの皆さんの一助になれば幸いです。
ファンクションポイントとは何か
以下はWikipediaから抜粋したものです🙏。
具体的な内容については、読者の皆様で調べていただけると幸いです。
ファンクションポイント法（ファンクションポイントほう、英: function point method）とは、1979年にIBMのアレン・J・アルブレヒト（A.J.Albrecht）が考案したソフトウェアの規模を測定する手法の1つ。ソフトウェアがもつ機能数や複雑さによって重みづけした点数（ファンクションポイント:FP）を付け、そのソフトウェアにおける合計点数から開発工数を見積もる。米国International Function Point Users Group(IFPUG)によってマニュアルが策定された。
プログラミング言語に依存しない、開発する機能数を測るためユーザー側から見てもわかりやすい等の利点がある。
ファンクションポイントを使うタイミングについては、ウォーターフォール開発における見積もりの進め方でも解説しているため、合わせてご覧ください。
基本方針
ではどのようにしてファンクションポイントを活用するか、以下の方針で設定する方法とします。
- 1ページ、1API、1ジョブ、1バッチ単位で見積もりをする
- 各ページや機能に搭載される内容に応じて更に重み付けをする
- インフラについては搭載されるサーバーに応じてポイントを追加していく
- 非機能要件については実施する施策に応じてポイントを加算していく
この方針に従って、フロントエンド、バックエンド、インフラストラクチャに関する各項目のファンクションポイントを設定します。
ファンクションポイント表
フロントエンド (FE)
| 機能 | ポイント |
|---|---|
| HTML、CSSのみ | +1 |
| 複雑なビジネスロジック | +2 |
| リアルタイム通信によるインタラクティブなUI | +3 |
| データの読み出し (項目数が5項目につき加算ポイントは更に増やす) | +1 |
| 検索機能 (検索クエリが5つにつき加算ポイントは更に増やす) | +1 |
| ページング機能 | +1 |
| フォーム（登録・更新項目が5項目につき加算ポイントは更に増やす） | +2 |
| グラフやチャートの表示（コンテンツ数が2つにつき加算ポイントは更に増やす） | +2 |
| 多言語対応 | +2 |
| レスポンシブデザイン | +1 |
バックエンド (BE)
| 機能 | ポイント |
|---|---|
| 基本的なCRUD API | +1 |
| 基本的なバッチ処理・スケジューリング | +2 |
| 複雑なビジネスロジック | +2 |
| 外部システム連携 | +2 |
| ファイル処理（アップロード、ダウンロード、圧縮、解凍など） | +1 |
| 検索（部分一致、複数条件、検索条件が5つにつき加算ポイントを更に増やす） | +2 |
| ユーザー認証・認可 | +2 |
| ロギング・モニタリング | +1 |
| Webhookのハンドリング | +2 |
インフラストラクチャ
| 項目 | ポイント |
|---|---|
| アプリケーションサーバー | +3 |
| データベースサーバー | +2 |
| キャッシュサーバー | +1 |
| 検索サーバー | +1 |
| ロードバランサー | +2 |
| CDN | +1 |
| ファイルストレージ | +1 |
| メッセージキュー | +1 |
| CI/CDパイプライン | +2 |
| モニタリング・アラート | +1 |
非機能要件
| 要件 | ポイント |
|---|---|
| セキュリティ対策（SSL/TLS、WAF、認証・認可など） | +2 |
| パフォーマンスチューニング | +2 |
| 負荷分散・オートスケーリング | +2 |
| ディザスタリカバリ対策 | +3 |
設定例
ログイン画面のファンクションポイント
| 機能 | ポイント |
|---|---|
| HTML、CSSのみ | +1 |
| フォーム（ログインID、パスワード） | +2 |
| レスポンシブデザイン | +1 |
ログイン画面のファンクションポイント合計：4ポイント
ログインAPIのファンクションポイント
| 機能 | ポイント |
|---|---|
| 基本的なCRUD API（ログイン認証） | +1 |
| ユーザー認証・認可 | +2 |
| 複雑なビジネスロジック（ログイン試行回数の制限、ロックアウト機能など） | +2 |
| ロギング・モニタリング（ログイン履歴の記録） | +1 |
ログインAPIのファンクションポイント合計：6ポイント
工数への落とし込みについて
例えば1ポイントを4dayと仮定します。更に要件定義、設計、構築、テストの割合は、以下のように割り振りをしたと仮定します。
- 要件定義（20%）
- 設計（30%）
- 構築（40%）
- テスト（10%）
先の例に合わせると以下のようになります。
ログイン画面の工数見積もり
| 工程 | 工数 |
|---|---|
| 要件定義 | 4ポイント × 5日 × 0.2 = 3.2日 |
| 設計 | 4ポイント × 5日 × 0.3 = 4.8日 |
| 構築と単体テスト | 4ポイント × 5日 × 0.4 = 6.4日 |
| テスト | 4ポイント × 5日 × 0.1 = 1.6日 |
ログイン画面の総工数:16人日
ログインAPIの工数見積もり
| 工程 | 工数 |
|---|---|
| 要件定義 | 6ポイント × 4日 × 0.2 = 4.8日 |
| 設計 | 6ポイント × 4日 × 0.3 = 7.2日 |
| 構築と単体テスト | 6ポイント × 4日 × 0.4 = 9.6日 |
| テスト | 6ポイント × 4日 × 0.1 = 2.4日 |
ログインAPIの総工数：24日
まとめ
本記事で提案したファンクションポイントの設定方針を活用することで、プロジェクトの規模や複雑さを機械的に評価することができます。これにより、適切な工数見積もりや進捗管理が可能になり、プロジェクトの成功確率が向上することが期待されます。ただし今回あげたファンクションポイント表はサンプルにつき、実際のファンクションポイントは皆さんの会社などで適宜定義してもらえると幸いです。
最後までお読みいただきありがとうございました