一般的にソフトウェアの開発会社の仕事というのは、パソコンに向かって一日中キーボードを叩いて、プログラムを書くように思われることが多いですが、実際は大分違います。
ソフトウェア会社の下請けで、かなり完成度の高い仕様書をもらって作業をする場合以外は、プロジェクト全体の作業の中で、所謂プログラミングという仕事の占める割合は低いです。
うちの場合も、プロジェクトによっては半分以上が細かい具体的な仕様を決めるまでの資料づくりや検討・打合せであることがあります。
つまり、下請けでないシステム開発会社はプログラミング技術だけでなく、お客さんとのコミュニケーション能力が必要です。
特に「要件定義」と呼ばれるお客さんの要望を具体的な仕様にするための作業は、最も重要で難しい作業です。
先日、ソフトウェア開発支援ツールを作っているメーカーのセミナーの資料（セミナーに申し込んだのですが、直前に用事できて受講できず資料だけもらいました）にもその事が書いてありました。
- ソフトウェア開発の作業のかなりの部分は要件定義に費やされる
- 要件が後から変わることによって必要になる再作業は再作業全体の８０％以上
- プロジェクトの失敗の原因の上位5つは要件に起因する
- 要件不具合による再作業のコストは後工程にいけばいくほど高コスト（運用開始後の要件変更のコストは110倍）
書いてあることについては、以前から感じていたことではありますが、大手メーカーのちゃんとした調査で、数値が示されていると、自分の考えていたことが正しかったと確認できて安心します。
また、うちだけが特別悩んでいることではなくて、大手も含めほとんどのソフトウェア開発会社が同じ問題で悩んでいるということが分かって安心できます。統計から考えると、うちの成績はよい方であることもわかりましたし・・・。
また、要件定義に失敗（プロジェクトの失敗）の原因についても、その資料によると（私の意見ではなくて資料に書いてあることです）
- エンドユーザーとのコミュニケーションギャップ
- 現状の分析不足
- 曖昧な要件
- 要件漏れやシナリオ抜け
- エンドユーザーの確認不足
などが上げられています。かなり賛同できます・・・
ただ、だからといって「お客さんの出す要件が曖昧で、ちゃんと確認してもらえなかったからシステムはできませんでした」とは言えないのが辛いところです。
お客さんに合わせて、打合せや確認資料の作成、現場での調査や確認作業の手伝いなど、どこまでやれば正しい要件を引き出すことができるのかを考え、プロジェクトを成功に導くのがプロとしての努めだと思います。
ただし、それには余分なコストがかかることをお客さんには認識していただきたいと切に願います。
「御社の作った○○サイトよりも規模が小さいから、そのときの費用よりは安くしてよね」
というのは成り立たないのです。コストに係わるのはプログラミングだけでなく、むしろ要件定義やその確認などのコスト、および、その漏れリスクの方なのです。
お客さんの意識が「プログラミング会社に作らせる」という意識であるとプロジェクトは失敗する可能性が高いです。あくまでも「プログラミング会社と一緒に作る」という意識で頂く必要があると思います。
・・・って、かなり偉そうなことを書いてしまいました。 お客さんごめんなさい。
■関連リンク