読者です 読者をやめる 読者になる 読者になる

ガルトラで遊ぼう

ガルトラ、プログラミングについてのブログです。月に4投稿ぐらいのペースでやっていきたいと思います。

顧客とのギャップを埋めたい

f:id:scrap_girl:20170408151946j:plain

上の絵は、要求分析の難しさを表した有名な絵である。ご覧の通り、顧客が最初に説明した要件と最終的に得られたサポートが大きくずれている。それどころか顧客が本当に必要だったものは最初に顧客が説明した要件とも違うのである。これが日常茶飯事ならまったくもってやってられない。

プロジェクトが始まる時、顧客はどのようにサービスを考えるのか?

何らかの新製品、新サービスを開始する時、顧客はどのようにサービスを考えるのだろうか?想像だが、トップダウン的なアプローチをとるんじゃないだろうか?つまりマーケティングの情報や流行のキーワードからサービスを想像するんじゃないだろうか?当然聞きかじりの情報が多くなり、キーワード的な説明になりがちになると思われる。例えばクラウド対応とか、AIの技術を取り入れたいとか。

ここで厄介だと思うのは、顧客がサービスの説明をする時に手段まで考えて説明してくることじゃないだろうか?例えば、上記の絵では最初の説明でブランコを説明している。顧客は「木にくくりつけて揺らして遊ぶ」ことを実現したいと考えておりその実現のためにブランコという手段を考えて説明しているんじゃないだろうか?

技術者はどのようにサービスを考えるのか?

反面、技術者はどのようにサービスを考えるのだろうか?はっきりいってサービス自体に興味を示さない人も多いと思う。というのも、技術者は技術的興味からサービスに関わることもできるからだ。例えば、サービスを実現するために汎用的なIFを開発するとか、新しい機械学習の手法を試してみるとか、新しいフレームワークを試してみるとか。サービスを実現するための手段自体が技術者にとってサービス開発に関わる目的になり得ると思う。

そういう視点でみると上記の絵の「プログラマのコード」はプロジェクトについては致命的だが、プログラマの目的は果たしているかもしれない。ここでは、サービス云々より、木にブランコがくくりつけられているだけだが、その事自体に技術的価値があるかもしれないからだ。ただし、プロジェクトとしては限りなく失敗へ向かう気がする。

すり合わせについて

もし、顧客がサービスの説明をした時に機能や手段から入ってきたら危険だ。顧客はおそらく親切のつもりだろうが、逆に本当に必要なものが何なのかを隠してしまっている。その機能や手段がプログラマの技術的興味を揺さぶるものだとなお危険だ。特に、議論がされないままプロジェクトにGOサインがでることになる。そのようなプロジェクトは失敗の確率が上がると思う。やはり必要なのは、最初の段階で本当に必要なものがなにかを見極めることだと思う。.