見積の前提
見積は私たちが保守開発を行った場合を想定しています。
他社が実際の開発を行った場合は
私たちの見積と大きく乖離した結果となる可能性があります。
これは、見積の時間や予算は
見積者の技術的背景を前提としているためです。
見積者が技術的に洗練している領域であれば
見積は時間的にも予算的にも低い見積が期待できます。
逆に、得意分野ではない領域に関しては高い見積となりやすいです。
私たちの得意分野
バックエンド、業務システム、DevOps
私たちの不得意分野
フロントエンド、ゲーム、負荷テスト
見積の手順
- 要件・目的・必要な見積粒度の確認
- 要件の分解と最小化
- 既存システムの設計とコードの監査
- 日次で現在の暫定見積とその理由の報告
- 必要な見積粒度となった内容はその時点で完了
- 見積粒度の進捗が芳しくない内容については
更に課題の分割やシステム保守の方針自体の見直しを検討
特にコードに関しては、手順 2. でコードの監査を行うことで、
「循環的複雑度」という指標を計算し、見積の見積の参考にします。
「循環的複雑度」が高いコードが存在する場合
見積の正確性が担保できませんので、
次のような別の方策を検討する必要があります:
- 不要な機能の削減
- 「循環的複雑度」を 20 以下を目標とした
テストコードの追加とリファクタリング - 「ユビキタス言語」の定義とコードの更新
一度のやりとりで見積を終えない理由
日次での暫定的な見積とその原因の報告を行う理由は次の通りです:
- 既存システムの設計によって
目標となる粒度の見積にかかる時間が大きく異なるため - 見積が難しい部分に関しては
更に課題の分割や保守開発の方針自体の変更を検討が必要であるため - 見積の先送りが可能と判断できれば、
先送りした方が将来見積が容易になるため