サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

旧館より 開発プロセス

プロジェクト完了報告書の問題

投稿日:2013年1月24日 更新日:


プロジェクト完了報告書

昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。

「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作られ、プロジェクトの情報、経緯、様々な指標をまとめられているものです。
当時は規模や金額など一定条件のプロジェクトに対し、作成することが義務付けられていました。

ただそれが当時は有効に活用されていないと感じていました。

書くタイミング

1つは書くタイミングが遅いため、有用な情報が記載されにくい問題がありました。

当時、プロジェクト完了報告書は、カットオーバーやお客様が検収を終えた時など「プロジェクトの終了時」に書くことが大半でした。

そのため、「プロジェクト完了報告書」を書けるほど最初から最後まで携わり、内容を理解しているリーダーは、すでに別プロジェクトに参画していることが多くありました(そしてそういうリーダーは新しいプロジェクトでも忙しくなっています)。
それが原因で「プロジェクト完了報告書」を書く時間もなかなか取れず、さらに時間も経っているので記憶も薄れがちでした。その結果、既存資料からの抜粋などが多くなり、教訓や改善ポイントなどが抜け落ちてしまいます。

#リーダー以外のメンバーも、プロジェクトやお客様の目的、経緯、改善ポイントなどを把握できていることが望ましい形だと思います。しかしながらインセプションデッキとか書くと驚く程、違うってのも普通にあるので、これはこれでなかなか難しい問題です。

「終わってから作る」ことが原因の1つなので、ウォーターフォールであれば工程毎に数字や背景、ノウハウなどをサマリーして「少しずつ」完了報告書を作っていけば良かったと今になっては思います。

活用の仕方

守秘義務などもあるのでしょうが、ポイントとなる情報などは公開されていないことが多く、あまり有効に活用できませんでした。
「何かあって情報漏洩と言われたら困る」というディフェンシブな発想からか、隠さなくても良いノウハウなども書かれていないことも多くありました。

結局、当時の感じたところは以下のようなものでした。
作る側:(管理する側から)やいやい言われてうるさいから仕方なく作っている。
管理する側:これまでプロジェクト完了報告書を未提出のプロジェクトがありますた!が、注意したところこれだけ提出されるようになりました!!(えっへん)

その完了報告書がどれだけ他のプロジェクトに活用されたかを評価の指標に組み込んだり、作り手にフィードバックすれば良かったとこれも今になっては思います。

そのアクションや成果物の目的が何のためで、それが「期待通りに活かされているか?」「より良い活かし方がないか?」などを計測したり考えていかないと、せっかくの良い施策もムダになってしまいます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

※アイキャッチ画像:http://www.flickr.com/photos/printhousecorp/6543078999/

-旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

あるプロジェクトで工夫したこと

(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。 そのプロジェクトの特徴は以下の通りです。 【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。 【要素 …

「会社を移る」ことと「部署・プロジェクトを移る」こと

主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。 弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか… …

burn-down-chart

バーンダウンチャートの疑問を聞いてみた

先日社内勉強会で「バーンダウンチャート」について説明する機会がありました。 その際の資料として@ryuzeeさんの「[Agile]バーンダウンチャート虎の巻(資料公開)」を使わせてもらいました。 #@ …

問題対私達の構図

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。 #ここで …

自分が議事録を書く際に気をつけていること

「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。 良い議事録を書く留意点、テクニックは色々あり、例えば… 1営業日以内に書く 記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるの …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。