こんにちは。
今回、初めて「プロマネ日誌」に記事を書きます。
t.h.です。
私はPM歴としては4年程度で、現在はとある銀行の開発チームで現場マネージャを担当しています。
また、PM職に就く前は現場リーダやサブリーダを長いことやってきましたので、「プロマネ日誌」ではその中でやらかしてきた失敗談を綴っていこうと思います。
よろしくお願いします。
過去の失敗を文書にする事は、以下のような理由で意味のあることだと考えています。
- 失敗を客観的に分析できる。
- 過去の失敗を思いだす。（喉元過ぎれば…にならないように）
- 失敗をノウハウとして共有できる。
さらに、過去の失敗に対して経験を積んだ今の立場から改めて当時を振り返ってみると、当時は思いつかなかったような問題点や改善点が見えてきます。
今後、これらの問題点を検証し、それに対する改善点をノウハウとして取りまとめていこうと思います。
このブログが、PL/SLについたばかりの方や、これからPL/SLを目指す方にとって有効な教材となれば幸いです。
それでは、最初のプロジェクトについて、その概要と発生した問題、また原因の分析と今考えられる対策を考えていきます。
１．プロジェクトの概要
| プラットフォーム | Solaris（HP-UXからSolarisへの移植） |
| 開発言語 | C/Pro*C |
| DBMS | Oracle8i |
| 他 | 一部オンライン機能のAPサーバとしてWeblogicを使用 |
| 種類 | 企業向けパッケージシステム |
| 開発目的 | HP-UX上で稼働していたシステムをSolarisへ移植、および新機能追加 |
| 開発期間 | 3ヶ月 |
| プロジェクト規模 | 最大要員10名 |
最大で10名のプロジェクトでしたが、そのうち5名が新人…新卒入社5ヶ月目くらい。
残り5名のうち、2名は2年目、あと3名は私を含めて5年目から7年目くらいの中堅でした。
また、10名のうち前回開発からの継続メンバーは、中堅メンバー1名と2年目のメンバー2名で、残りは私も含め今回の開発から参加したメンバーという体制でした。
２．発生した問題
開発内容はそれほど難しいものではありませんでしたが、システムテストで品質問題が発生しました。
バグが多発したのです。
なぜ上記のような問題が発生したのか、12年ぶりに振り返ってみたいと思います。
- PCLに問題があった。
基本的な問題ですが、確認項目が具体的に記載されていませんでした。
（結果は「正しいこと」としか記載されていなかった。）
このため、バグの見落としが発生しました。 - テスト結果の確認方法に問題があった。
結果確認をExcelで行ったため、作成されたファイルにNullの制御コードが設定されていることを確認できませんでした。
例）出力したCSVファイルの各項目が、’12345__’（’_’はNull値）のようにNull埋めの固定長で出力されていた（下記画像）。
主な直接的原因は以上の2点だったと記憶しています。
新人が多かったため、設計から実装までの苦労もかなりのものでしたが、それは問題の直接原因ではありません。
３．真の原因の分析
PCLについては、私がレビューした際「おや？」と思ったのですが、確認項目として「正しく出力されていること」とのみ記載されていました。
これについては、作成者が継続メンバーで経験年数も私とおなじ中堅SEだったため、「細かい指摘は不要だろう」と考え、特に指摘しませんでしたが、これがもっとも大きな失敗の原因でした。
リーダーとしては、やはり自分の経験や知識を信じ、おかしいと思ったことはきちんと指摘しないとダメなのだという、とても基本的なことができていなかった事を今でも悔やんでいる事例です。
テスト結果の確認方法については、新人に対する指導が不十分だった事と、エビデンスチェックができていなかった事が原因です。
４．対策
当時から10年以上経験を積んできたわけですが、この様な失敗プロジェクトを防止するためにはどのような方法が有効か、これまでの経験を踏まえて考えてみたいと思います。
このプロジェクトでは、そもそも会社に入って初めてプログラムを始めた者や、仕事でシステム開発を実施する事が初めての者5名に対して、基本的には2名で指導を実施していました。
この様な場合、新人の指導にかかる稼働が非常に大きくなるため、どのようなプロジェクトでも実施するような共通的な作業については、フローや手順を作成し、PCLなどについては社内でフォーマットや品質チェックのチェックリストなどを「社内ノウハウとして」あらかじめ用意しておくことが有効だと思います。
例えば、作業フローについては、テスト実施後にはエビデンスチェックを実施することを明記しておけばチェック漏れが防げますし、PCLについては、確認項目に「必ず具体的な出力値を記載すること」と記述しておくことで、上記のような問題は回避できます。
これによって、そもそもチェック内容が曖昧なPCLが作りにくくなりますし、「まあ大丈夫だろう」というレビューの甘さも排除しやすくなります。
何よりもPL初心者にとってはそれが良い「道しるべ」になります。
５．まとめ
- 標準的なプロジェクト実施フローを作成しておくことが、PL/SL初心者の育成には有効だと考える
- 設計書やPCLのようなドキュメントは、あらかじめ社内フォーマットを用意しておくことで、レビューの指針となり漏れやあいまいさを防ぐ。
- PL初心者に対しては、プロジェクトの進め方に対してPMが定期的にチェックする場を設けることにより、PLのミスによる問題を防ぐ。
終わりに
現在取り組んでいる「プロマネ会議」では、上記のような「社内ノウハウ」を形にすることを目指しています。
以上、いかがでしたでしょうか。
今考えると本当に情けなくなってきますが、過去の失敗をきちんと精算して今後も精進していきたいと思います。
