プロジェクトで問題が発生したとき、どうするか
以前にTwitterで書いた内容をまとめ直したエントリーです。
プロジェクトで問題*1が発生した場合にどう管理するか、をまとめました。プログラマーよりもプロジェクト管理者に視点がありますが、プログラマーにも読んでもらいたいと思います。
問題を共有する
問題が発生した時にまずやるべきは、問題の共有です。どう言った問題があり、どのようなリスクを生むものなのか、と言った事実を共有する必要があります。共有する範囲は、最低限でプロジェクトチーム全員です。
問題を発見すると、プログラマーやエンジニアとしてはさっさと修正してしまいたくなるものです。が、それはNG。なぜ、いきなり修正してはいけないか。これには理由が4つあります。
全体においてリスクと考えられない問題かも知れないため
解決を阻害する要因があり放置されていた問題かも知れないため
同様の問題が自分の担当範囲外でも発生しうるため
チームメンバーが把握している仕様と異なる成果が作成されてしまうため
上記の理由により、問題が些細でも共有する必要が有ります。
混入場所を特定し、水平展開する
問題の存在が共有されたら、次は問題の混入工程を特定します。デザインの問題ならば画面設計工程になるでしょう。仕様ミスならば基本設計以前になります。
混入工程が把握できると、同様の問題が他に混入されていないか、作業者毎や機能毎に水平展開して調査します。例えば、プログラミングミスならばミスをしたプログラマーが担当した別箇所を調べる必要があります。似た機能がある場合はコピーペーストしている可能性があります。その場合はペースト先で同様の問題が発生する可能性があるため、その部分も調べる必要性があります。
調査した結果、どの程度の範囲に問題があるかが見えるようになります。範囲が見えることで、解ることが2つあります。
問題の影響度
解決のための工数
優先順位をつける
問題の影響度と解決のための工数が解ることで、問題に「優先度」をつけることが出来るようになります。これを付けて初めて、問題解決に着手することが出来るようになります。
何故、優先度をつけずに問題解決に着手してはいけないか。
具体的な例を挙げます。殆ど工数を掛けずに解決できるが影響度の低い問題がたくさんと、工数は掛かるが重篤な問題がひとつ発生しているとします。こういうとき、人間心理として前者を優先して処理したがる傾向があります。そうするとどうなるか。一瞬で終わるバグフィックスでも、山のように積もれば工数を次第に圧迫しますし、リグレッションテストの工数が肥大する可能性はあります。結果、時間がなくなってしまって重篤な問題が解決できなくなってしまうかも知れない。優先度による順次対処をしないと言うことは、そう言う危険性があることなのです。
問題を管理する
問題発見から解決までを記録していないと、どういった問題があってどこまで解決しているのかがわからなくなります。問題が発生したら「内容」「発生日」「優先度」「ステータス」「解決方法」を管理する必要があります。
割と一般的だと思われる方法は、3つです。
報告票
一枚の紙(Excelシートなど)に、不具合の内容などを事細かに書く方法です。
物理的な紙に出すので、管理が面倒です。敢えてデジタルな開発現場で使う必要があるのか疑問です。
案件によっては、成果物のひとつとしてフォーマットが決まっていることがあります。そういった場合には後付で作成して提出しておけば良いでしょう。
まとめ
問題が発生したときは共有→把握→解決のフローで実行します。そして、それを管理するシステムが必要です。もしプロジェクト管理者になった時は、状況を管理するためのシステムの構築と、問題解決のためのフローの徹底をまずおこなうべきではないでしょうか。
*1:ここで言う「問題」とは、バグのみならず、パフォーマンス・セキュリティなどの成果物に関するもの全てを指します
