ITエンジニアが書く書類でいちばん多いのが、ある工程が終わったときに書く完了報告書です。
呼び方は、会社によって、プロジェクトによって、工程によって、違うかもしれません。
何を書けば相手に満足してもらえるか、どんなことを書けば余計な作業が増えないか、
を考えながら書きましょう。
- インプットと網羅性
- 定量的な見解
- 定性的な見解
完了報告書の書き方
イト屋です。
工程が終わると、完了報告書を書きます。
書く相手は、上司であったり、QAであったり、顧客であったりです。
報告書の名前もいろいろです。「完了報告書」「品質見解書」「フェーズゲート資料」など区切りを示すような書類です。
特に、請負作業の途中経過報告のようなときも似た書類を作るかと思います。
読書感想文のような資料を書いていませんか？
あるいは文章なしの数字を羅列している表だけを提出していませんか？
書くことを押さえておけば、すぐに書けるようになりますよ。
- インプットと網羅性
- 定量的な見解
- 定性的な見解
インプットと網羅性
インプットを意識しましょう。
設計工程であれば前の工程の仕様書ですし、テストであれば対応する設計工程の仕様書です。
| 現工程 | インプット文書 |
| 外部設計 | 要件定義書 |
| 内部設計 | 外部仕様書 |
| コーディング | 内部仕様書 |
| 単体テスト | 内部仕様書 |
| システムテスト | 外部仕様書 |
| 受け入れテスト | 要件定義書 |
なんらかの網羅性を言えるのがベストです。つまりインプット文書に書いてあることは全部やったよ、ということです。
便利なのはPMPで出てくる「要件トレーサビリティマトリクス」です。
要件トレーサビリティマトリクスの一部分を埋めてやるべきことを全部やった、と主張しましょう。
PMが要件トレーサビリティマトリクスを作っていない場合は、簡易的でもインプット文書の章と現工程でやったことの対応表を作るとよいと思います。
内部設計の完了報告書では以下のような文章が書かれます。
「インプット文書である外部仕様書に従ってYYY工程を実施した。添付の要件トレーサビリティマトリクスの通り、検討すべきことすべて検討し、仕様として決定した」
定量的な見解
定量的な見解は、作ったものがどれだけか、と、指摘（不良）がどのくらいあったか、です。
「内部仕様書xxページを策定した。レビューを行い指摘yy件であった」
「単体テストではテストケースxx件を実施。不良をyy件摘出した」
ここで、多かったとか少なかったとかの理由とか書く人もいます。
プロジェクトによっては、過去のプロジェクトの実績をとっている場合があります。
過去のとの比較を行って、「XXXの機能が難しかったから」「XXXの機能は未経験だったから」などと書くこともあります。
定性的な見解
まず、指摘（不良）を分類してください。どう分類するかは下記のような軸で分類します。普通はプロジェクトごとに決まっていますがご参考まで。
- モジュールごとに
- 工程ごとに
- 何をまちがったか （検討もれ、詳細化不足、仕様間違い、、など）
顕著な傾向にあるところの関連見直しをします。
以下のような文章を書ければよいかと思います。
「XXXモジュールのAAA工程で検討もれがpp件で全体のii％を占める。この工程でYYYYを観点に見直しを行い、xxx件を見直し、KKKとLLLをAAA仕様書に追記した」
関連見直しは、やれと言われてやると嫌ですが、率先してやっておくとよいです。
門外漢に賢しらに指摘されてやるものは消化試合になってしまいますが、何が弱いかはエンジニア自信がよく分かっていると思いますので、本質的に価値あることを自分の手でやっておきましょう。
まとめ
完了報告書の書き方をまとめてみました。
書くことは概ね決まっていますので、相手に納得してもらえる書類をさくっと書いていきましょう。
コメント