前編（第13回）に引き続き、炎上プロジェクトを見分けるポイントについて説明していきます。前編では炎上プロジェクトを見分ける6つのポイントを紹介し、［ポイント1］～［ポイント3］について取り上げました。
- ［ポイント1］受注のためにコンペに参加して値引きしている
- ［ポイント2］営業が顧客側に立って要件をそのまま伝えてくる
- ［ポイント3］見積もりの工数に時間が書いてある
- ［ポイント4］RFQ（見積依頼書）が存在しない
- ［ポイント5］テストツールを使っていない
- ［ポイント6］マネージャーが夜中まで残業している
後編は［ポイント4］～［ポイント6］について順に説明したいと思います。
［ポイント4］RFQ（見積依頼書）が存在しない
プロジェクト内に、RFQの資料が見当たらない場合は要注意です。RFQは見積もり時に顧客から提示される資料で、主に顧客が実現したい要望などについて記載されています。従って、本来はその資料に基づいて見積もり書を作成していなければなりません。
ところが、RFQの資料が存在しないことがあります。この場合、一体マネージャーは何に基づいて見積もりを作成したのでしょうか。よくあるのは、1枚ほどの紙に記載された要件一覧というものです。
これは、要件を定義した資料としては不適切です。要件はそれほど簡単なものではありません。より具体的に行き違いのないように記載すべきですし、要件としては機能要件だけではなく性能要件なども必要です。
そう考えると、適切なRFQというのはある程度のボリュームになっているはずです。顧客がRFQを作成できない場合、開発側は顧客と一緒にまず要件定義をし、それを要件定義書などの資料として作成する必要があります。
RFQであれ、要件定義書であれ、最も重要なのは「その資料を誰が承認したか」ということです。要件を提示する責任者が明確ではない場合、顧客側でも誰かの意見によって要件がぶれる可能性が高いと思った方がよいでしょう。
要件の変更は、炎上案件を生む非常に大きな原因の1つと言ってよいと思います。プロジェクトを炎上させないために、顧客と開発側の双方で認識の違いや言葉の食い違いなどが発生しないように、RFQや要件定義書といった資料でゴールを明確にし、認識を共有する。これが炎上案件を防ぐ第一歩となります。
［ポイント5］テストツールを使っていない
私の経験上、炎上しているプロジェクトは品質管理の意識が低く、テストツールを使っている確率は低いと思います。テストツールとは、あらかじめ決められた仕様に従って、さまざまな入力値や操作に対してその仕様通りの出力ができるかどうかを自動でチェックするツールです。
なぜ、テストツールを使う必要があるかといえば、人間がテストをした場合、チェック漏れが発生しやすいし、疲れなどのせいでテストの失敗を成功だと嘘をつく可能性も払拭できないからです。さらに、バグが発見されたなどの理由でコードに修正が入った場合、変更箇所が影響する部分については、全て再テストしなければなりません。これを人の力でやろうとするから、予測のできない作業が多く発生し、残業が増えて炎上に至るのです。
テストを人力で行うのは極力避けた方がよいでしょう。これはプログラム開発以外でも言えることです。特に少子化に向かっている先進国では、さまざまな分野において人間の手や目によってテストを行う方法は時代遅れです。今後は基本的にツールを使って効率的に勧めることが重要になることでしょう。根性論や精神論では乗り切れない時代になりつつあるからです。
「DevOps＊」でも自動テストツールを使うことが前提とされています。単体テストのみならず、結合テストやユーザビリティーのテストに関しても自動化されていく傾向にあり、そのためのツールがたくさんインターネット上で公開されています。
テストの自動化ツールを使ったことがないのであれば、「xUnit」や「Selenium」といったキーワードを調べてみるとよいでしょう。
