バグの修正1つするのだって、プロジェクトが大規模であればあるほど作業工数がかかる。
「バグ出たから、さくっとソース直しといてー」というわけにはいかない。そうしたいところだが。
たとえば「文字が途中で切れている」といった単純なバグ1つとっても、いざ修正するとなると結構めんどくさい。
私はこれまでに開発もテスターもやっていたので、全体のフローがわかる。
そんなわけで、自分の会社（正確には顧客である会社）ではこうやってるという話です。
正直、他のベテラン開発者から見るとツッコミどころも多いと思います。プロジェクトの方針なので、そこはゆるく見といてください。
前提となる設定は以下。
■作業内容：バグ1件の修正
■テストチーム
・リーダー
・テスター
■開発チーム
・リーダー
・テスター
■ブリッジ担当
・エラい人
（制約事項として、これから修正するバグ1件以外に誰一人として作業を抱えていないものとし、各工程で示している最大工数の方を総工数算出時に使用します）
★結論
いきなり結論を言います。「約14時間」です。
★作業の流れ
バグを修正するまでの工程を順に追うと、こんな感じ。
１、テスターから開発者に対し、見つけたバグの詳細情報を展開する
２、その情報をテスト側のリーダーがチェックする
３、テストチームと開発チームのブリッジ役であるエラい人がチェックする
４、エラい人がバグだと認識したら、開発チームのリーダーに展開する
５、その情報を開発側のリーダーがチェックする
６、開発側のリーダーがバグだと認識したら、開発チームのメンバに作業指示を出す
７、開発メンバがソースコードを修正し、動作確認する
８、修正したソースコードをGitに入れる
９、ソフトリリース
１０、再テスト
１１、テストでOKになったことを報告し、完了報告
以下、順に見ていきます。
１、テスターから開発者に対し、見つけたバグの詳細情報を展開する（30分〜1時間）
どんな操作を行ったり、どういった条件下で発生するのかについての情報を書いて展開する。
その際、実際の動作を写した動画と当時のログもあわせて展開する必要がある。
情報の粒度は「その通りに実施したら再現できる」程度であれば良い。なお、書き方などの細かいルールはここでは割愛する。
ログと動画の取得＋詳細情報の記載が実作業。長くても1時間あればできる。
２、その情報をテスト側のリーダーがチェックする（15分）
テスターから報告があったバグについて、それが本当にバグであるかどうかをチェックする。
仕様とは異なる動作であるかを確認した後、以前にも報告が上がっていないかをチェックし、上がっていなければ新規バグとして、ブリッジ役の人に報告する。
リーダーとあって手慣れているものとして、15分もあればチェック完了。
３、テストチームと開発チームのブリッジ役であるエラい人がチェックする（5分）
基本的には２と同じだが、チェックする人がワンランク上の人間になっただけ。
といっても私の現場の場合、この人はマネジメントが仕事なので、自分に回ってきたバグをそのまま開発チームに渡すことしかしていない。わかるものだけチェックするというスタンス。
ひとまず5分。
４、エラい人がバグだと認識したら、開発チームのリーダーに展開する（1分）
３でチェックした後、開発チームのリーダーに展開する。渡すだけなので、実質1分の作業。
５、その情報を開発側のリーダーがチェックする（5分）
エラい人から展開されたバグについて、開発側のリーダーが内容をチェックする。こちらもリーダーだけあって、5分もあれば判断が下せるものとする。
６、開発側のリーダーがバグだと認識したら、開発チームのメンバに作業指示を出す（1分）
そのバグに詳しそうなメンバに対して、バグ対応の指示を出す。
機能Aに関するバグなら、機能Aに関するソースコードを実装・修正しているメンバに対して振る。
特段の事情がなければ作業を振るだけなので、1分。
７、開発メンバがソースコードを修正し、動作確認する（30分〜4時間）
おそらく多くの人が最もイメージしやすい部分。
バグを解析し、ソースコードを修正してバグを取り除く。
その後、修正した通りに動作するか、また他の操作や機能に影響はないかを確認する。
しかし、バグの程度によって、修正が簡単なものもあれば難しいのもある。修正する範囲が広かったり、他の機能にも影響するようなレベルであれば日数がかかってしまう場合があるが、今回は中難易度のバグと仮定して、長くても4時間（半日）あれば完了するものとする。
８、修正したソースコードをGitに入れる（20分）
動作確認まで完了したソースコードを、Gitと呼ばれるモノに入れる。
Gitとはなんぞや、という説明はここでは省略するが、簡単にいうとソースコードの「入れ物」。
開発者はその入れ物に入っているソースコードを自分のパソコンに保存し、修正を行う。ただし、Gitに入っているソースコードは、Git内のデータが消されない限りは何度ダウンロードしても消えることはない。
イメージ的には、無限に湧き出るカルピスの原液みたいな。
Gitのソースコードは、いわばマスターファイルであるので、不具合が出るようなソースコードを投入してはいけない。だから、この作業は慎重に実施する必要があり、20分とした。
９、ソフトリリース（8時間）
Gitに入っているソースコードを使って、ソフトウェアをリリースする。一体どういうことか。
やり方は、ソースコードを「コンパイル」することで、ソフトウェアにします。コンパイルとは、ソースコードに書かれた内容をもとに、コンピュータが実行できるような形に変換する操作のこと。これによって、ソフトウェアが作成されます。
ただ、大規模開発だとソースコードが数十万〜数千万行あったりするので、1回コンパイルするだけでも数時間は平気でかかります。
私のプロジェクトの場合、何もなければ8時間程度で完了するので、工数はこれにします。
１０、再テスト（15分）
リリースされたソフトウェアを使って、テスターが再度テストを行う。
せっかくここまで複数の工程を踏んできたが、再テストの結果がNGであれば1に戻ることになる。といってもきっちりやり直すのではなく、実際には1から始めて必要な工程だけを辿り直しています。
再テストは1よりも工数は少なくて済むので、15分ほど。
１１、テストでOKになったことを報告し、完了報告（2分）
再テストの結果がOKであれば、その旨を報告してバグの修正が完了。
★総工数
そして、これらの工程ひとつひとつにかかる工数を考えてみる。
１、テスターから開発者に対し、見つけたバグの詳細情報を展開する（30分〜1時間）
２、その情報をテスト側のリーダーがチェックする（15分）
３、テストチームと開発チームのブリッジ役であるエラい人がチェックする（5分）
４、エラい人がバグだと認識したら、開発チームのリーダーに展開する（1分）
５、その情報を開発側のリーダーがチェックする（5分）
６、開発側のリーダーがバグだと認識したら、開発チームのメンバに作業指示を出す（1分）
７、開発メンバがソースコードを修正し、動作確認する（30分〜4時間）
８、修正したソースコードをGitに入れる（20分）
９、ソフトリリース（8時間）
１０、再テスト（15分）
１１、テストでOKになったことを報告し、完了報告（2分）
1〜11までを合計すると、バグ1件の修正に必要な総工数は「844分」です。
時間に直すと、約14時間となるわけです。
★まとめ
バグ対応1つ取っても、実はこれだけの工数がかかるんです。
ひとえに開発といっても、細かく分解すればソースコードをいじる以外にもいろいろな作業が存在するので、今回のような分析結果も工数見積もりの１つの判断材料として利用したいのが本音。
だけど見積もりそのものができる時間も限られるので、厳密には分析することができないんですよねー。残念。
にしても人月単位で考えるなら、せめてスキルの幅であったり閾値的な基準を考慮したいところだが、そもそも人がいないので困ったものだ。