改修にどれくらいかかる？ー故障改修見積もりー

きっかけ

お客様からいただいたごく小規模な案件の試験工程で既存故障が検出されたため、改修にどれくらいの時間が必要なのか、見積もり依頼がありました。

作業内容

このプロジェクトではLOCをベースに開発効率や規模を算出しているため、具体的にステップ数を算出する必要がありました(正確に言うと、私の中ではそういう認識でした)。
ステップ数の算出を行うために、変更後の関数を使用してざっくりとコードを書き、そこからステップ数の算出を行いました。

実際に書いたコードから算出してみて、結果としてはその作業は必要ではなかったかなと思いました。
例えば別のアプローチとして、この案件では使用している関数の変更を行うため、変更後の関数を使用しているモジュールを参照して、そのモジュールで関数に使用しているステップ数を計算すればよかったかもしれません。
立て続けに見積もりを行っていて疲れたので、コーディングが楽しくなってしまったのかもしれないです 笑

レビュー

試験観点が不明確であると指摘されました。
また、試験内容の記載は、見積書を見て試験項目書が書けるくらいのレベルで記載すべきだと言われました。
これについては「試験項目書が書けるレベル」というのが私の中では曖昧な状態です。
どんなインプットがあれば試験項目書が起こせるのか、そのあたりの理解が足りないのかもしれません。
ここで言う「試験項目書」とは、受け入れ試験で起こすような業務シナリオのイメージだったのかなと、あとで振り返ってみると思います。

こうして内部レビューを受け、指摘事項を反映させた見積書は「見積書の作成に時間をかけすぎ」とプロジェクトマネージャから評価されました。
そう言われてみると、要点を得ない不要な記述が多いように思えました。
無駄なくスマートにまとめるにはシステムのことはもちろん、業務の理解が必須であることを感じ、今の自分にはそれが不足していることを痛感しました。
業務シナリオが想像できなければ要点を絞った試験内容の記述は難しいと思うのです。
また、試験については試験しすぎ、との指摘がありました。
確かに「故障改修箇所を確認する」という目的からすると不要な試験が多いように見えました。
それまで仕様変更案件ばかりを担当してきた私には「故障」への対応と「仕様変更」への対応とが異なるという認識が全くありませんでした。