申し訳ありません、「プロジェクト編その３」を抜かしてしまいました。順序が逆になりましたが、掲載します。

ユーザが仕様を早く決めてくれないから開発期間が長くなる

これが間違いっておかしいでしょとみなさん言うと思います。たしかに、開発プロジェクトでは、ユーザがなかなか仕様を決めてくれないために仕方なしに見切りで進めていって、あとでひっくり返されるという痛い目にあっているからそう思われるのでしょう。

私の経験上でもよくあったことですが、まず最初にユーザの担当者を決めてもらうのですが、だいたいにおいてキーパーソンは出てきません。キーパーソンと言うのは文字通り軸になっている人ですから、本来の業務が忙しくて、そんなプロジェクトに関わっていられないというわけである。

これもよく考えるとおかしな話なのですが、日本の企業の開発プロジェクトでよくある話である。従って、担当者は新人であったり、ひまな人がアサインされたりします。そんな状態ですから、仕様なんて決まったようで決まっていません。最後の方の、さあもうすぐ本番だから運用のテストをしようなんて頃になって、キーパーソン登場です。

こんなんじゃダメだとなり、仕様変更です。そしてあわてて変更開発をして、それが原因で不具合発生です。ですから、タイトルの意味は正しいのです。しかし、よく考えてください。ユーザが早めに仕様を決めてくれば解決するのでしょうか。というか、ユーザはどんなシステムができ、どう動くかもわからない段階で仕様をびしっと決められるものなのでしょうか。

私はユーザの立場に長いこといましたから言えるのは、仕様はきちっと最初に確定はできません。何となくこうしたいでは決まらないし、これでやると決めても技術的に無理だなんてこともあるわけです。ということは、無理なことを言っているのです。つまり、ユーザは仕様をなかなか決めてくれないという前提でプロジェクトを進めるべきだと思うのです。

そのために必要なことは何でしょうか。早い段階で動くシステムを見せてやることではないでしょうか。この早いというのは２つ意味があって、ひとつは開発の初期段階でプロトタイプがあるということと、もうひとつはユーザから要求が出たらすぐに実現してあげることです。

現在の開発ではアジャイルが増えてきましたが、まだまだ、仕様を固めて、それから時間をかけてコードを書いて、できたころには最初の仕様は何だったっけみたいな話になる。これじゃあ、ユーザだって最初から真剣になりません。尻に火がついてからでいいやとなってしまうのです。ぜひ、ユーザのせいにしないでユーザが本気になるやり方を考えてもらいたいのです。