他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。
(2019/4/19 リンク切れを修正)
「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む
「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。
- 本来あるはずのレアケース、例外に関する要求が出てこない
- 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない
- 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手段がない
- ステークホルダーによって要求が異なったり、ステークホルダー間で要求が矛盾したりする
- 複数の要求提供部門が存在し、一方の要求を満足しようとすれば他方が成り立たない
- 業務用語知識の欠如
- IT動向や他社事例を参考に、自社システムの実態とは乖離した要求をされる
- システム化の目的よりも手段が重視され、顧客の真の要求が引き出せない
- 画面の細部に顧客の注意がいってしまい、本質的な要求でないことに発散
- 顧客予算に限りがあり、設計書を作成し仕様を確定してから実装をしては間に合わない
- 計画段階での要求発散や確定漏れ
- 経験者によるレビューを受けずに要件定義書を作成し、統合テストの段階で仕様にはない日機能要件を要求されて大きな手戻り
- 要求を獲得した段階で開発規模を示す必要があるが困難である。顧客側にとってもその良否を判断するための手段がない
- ユーザのビジネス要求の優先順位と要求に対するシステム化の優先順位が異なる
- 利害関係者からシステム化に伴う費用対効果を求められる
- 課題に対する原因を検討する方法がわからない
- 要求の分析が不十分であるにも関わらず、予算や納期が先行している
- 顧客のシステム導入経験があまりない
さて、上記の状況でどうするかを考える事はできるだろうか。以前に失敗から学ぶというエントリも書いたのだけど、こういったトラブル事例などを見て「考える」というのが重要だ思っている。これらの事例を一般化して方法論が作られたりするのだけれども、一般化した時点で学びにくさや使いにくさというのが生まれてしまう。
上記例については「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF)に対策例が出ているので答え合わせをしてみても良いと思う。
リスクを予測して最小限度の手を打つ
あるべき姿は自分のプロジェクト固有のリスクを特定して、コンパクトに対策を講じること。不勉強だったりトラブルを恐れて「ベストプラクティス全部入り」を目指すと、やらなければならないことが多くなりすぎて個々の検討や分析が浅くなりすぎ、結局トラブルとなる。体系化・一般化された方法論は「ベストプラクティス全部入り」になっていることが多いので本当に注意が必要だ。
残念ながら、それほど自信も専門知識もない開発者や顧客やマネージャは、計画や仕様や標準を一式すべて作成しておいた方が安全だと考えがちである。ここに至ってある種のグレシャムの法則（「悪貨は良貨を駆逐する」）が働き、最も専門知識に乏しい参加者が先頭に立って、必要な部分だけに絞り込むこともなく、文書一式すべてを作成する方向にプロジェクトを押しやることになる。
アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～
