AD | all

[187] 要求定義と要求開発:今更のOpenthology勉強中

クライアントと話をしていて、これはうまく行くと思う時と、これはヤバイと感じる時とがある。巧く言葉にできないのだが、「未だ見ぬものに対する覚悟」に関する対処法が同調するかしないかが、分かれ目のように想うことがある。

要求はもともとあるものではなく、
上位の目的(ビジネス要求)をもとに
合理的かつ能動的に開発するべきものである
  要求開発~価値ある要求を導き出すプロセスとモデリング
  http://amzn.to/GWnjTc

何を誰に求めるのか、そのために何をすべきと考え、その道筋の為の労苦をどのように見積もるのか。発注する側も受注する側も、この「要求」を見つめ直した方が良いのかもしれない。そう、要求を「定義」するのではなく、要求自体も「開発」すべきものとして。

Webを紙カタログ的な既にあるものの延長線上の何かと捉えるクライアントも居れば、全くの新機軸メディアだと挑むクライアントも居る。どちらが正しいかの議論に関心はない。どちらも「あり」なのだろうと素直に思う。結局そのクライアントがどのようにお客さん(エンドユーザ)と結びつきたいかという姿勢にかかっている問題だし、それにどれだけのコストをかけられるのかという体力の問題でもある。

延長線と考える方は、どちらかと言えば、プロなんだから適切にレールを惹いて、全容を見せてくれることを望む。家を建てるかの様に、壁はこれ、床はあれと、順番に選択式に決めて行けるように誘導されることを望む。新機軸と考える方は、答えが出せない事を知りつつ一緒に考えてよと願う。実際のプロジェクトがこんな二軸に奇麗に整理できないのは、予算や覚悟や現状知識という要素が複雑に絡み付くからではないかと考えている。

で、延長線と新機軸のどちらが正しいかは置いておいて、どちらが好きかという問題は、どれだけ得意か、あるいはフィットするかという面に影響を与える。プロであるならば、そのどちらにもキチンと対応すべきだという意見はゴモットモだが、限られた時間の中でヤリクリするためには、そうも言っていられない。得意不得意の中で選択肢が増えるのも良いはずだ。

これは、もしかしたら、開発側の区別にもなっているのかもしれない。デザイナ系はWebに未だ見ぬ驚き系を求めて参入して来た傾向が強い様に思う。少なくとも90年代から入って来た人達は圧倒的にこちらのグループだろう。「こんなことできるんだぜ、すげぇー」、基本的にはこれが原動力だ。今までできなかった事ができるようになる喜び。そしてその喜びの為には何者をも厭わない好奇心に満ちた時代。その為には色々なモノをそそくさと捨ててこの業界に殺到した。

しかし90年代であろうと、いわゆるSIer(システムインテグレータ)系は、結局データベースやAPIやらで従来の何かの置き換え型としてWebを見ていたのかもしれない。実際開発するモノは、さほど変わりなく、要求定義/仕様定義/実装から検証/テスト/品質管理、そして運用。プログラミング言語が変わったり、幾つかのお作法が変わったりするけれど、延長線上の何かと捉えても致し方ない。

Webシステムが、「ホームページ」から「Webサイト」と呼ばれ、同じ言葉で呼ばれながらも、中身がWebアプリケーションだったりWebシステムと変遷して来た中で、利用者数が多くなるほど、セキュリティや実装品質が重視され、通常の「開発案件」の色が強くなって行く。SIerが自分たちを余り変化させずに適応できたのはその為だろう。

しかし、検索という概念が出て来たあたりから、諸々軋(きし)みが聞こえて来た気がする。検索対象が、今まで扱って来たデータ量を遥かに越えていく、しかも信じられないスピードで。そして最新のものに優良情報があるという傾向まで見えて来た。古典にあたれば解決できる世界から明らかに変わって来た。

更に、SEOやマーケティング的な情報の扱い方、そして解析にソーシャル。決められた枠内でのアプリケーション開発者にとって、未知の敵に取り囲まれた感さえする。その辺りから、Webに特化した部隊の育成をするしないの分かれ目が生まれて来た。今でさえデザイナとエンジニアが相容れないと嘆いているチーム(チームかそれ?という問いは置いておいて)は、未知であろうが新機軸を喜び楽しんで受け入れられるかという一線が、その一因となっている可能性は高い。

そして新しいデバイスの登場が、今、更にカオスを作っている。情報の見方が根底から変わりつつある。情報にあたるなら図書館や名だたる書店と言われた時代があった。それをリアルに知っていて思い出せて語れる人は、実は凄いスピードで減っている。次に情報にあたるならパソコンという時代になる。でもそれは、タブレットやソマートホンへの過渡期かもしれないし、マルチデバイス時代の序盤戦なのかもしれない。5年後自分たちがどんなデバイスで情報にアクセスしているか、自信満々で語れる人は居ないのではないだろうか。

そして、クライアントは求めるモノを理解していないかもしれない、定まったとしても求める回答は今現時点では実現不可能かもしれない。今は無理でも、戦略的な投資を考慮すれば5年後に大きな実を成すかもしれない。今の勝利も求めているが、5年後に無駄とはならない施策も求めている。でも戦いの場すら定かではない。

UIとして、Flashに無理難題や途方もない夢ができるでしょ?と言われたレベルで、マーケティング的な事柄やビジネスモデルのレベルで囁かれ始めている。対する実装側は、マルチデバイスと新技術とソーシャルで手一杯な状態とも言える。一旦兵を引き体勢を整える時間も与えられない。でもちょっと整理が必要な時期に来ている。走りながら考えるにしても限界もある。

設計プロセスや上流行程の大切さは昔よりも強く認識されているが、仕様が大揺れするのはWebに限った事でもなく、エンジニアリングというもっと大きな枠で頻繁に問題化している。そしてその弊害ももはや稀な事ではなくなった。

そこで、気になった言葉が、「要求開発」だ。少しブームは去ったようだけれど、資料整理をしていて、今更ながらの勉強開始。気になり始めた。クライアントのビジネスゴールを睨みつつ、本当は何がやりたいのか、やれば良いのかを紐解いて行く。そこに皆をハッピーにする手がかりがある気がする。

でも問題もある。今のRFP(Request For Proposal/提案依頼書)から始まる開発案件の形が崩れる。ビジネスゴールの吟味から始めるなら、それを広く開示しない限り、複数社コンペすらできなくなる。折角RFPさえあればパートナー選びが公平に的確に行えるかのような風潮が出て来ているけれど、それが崩れる。実はRFPを書くためのパートナーが必要になり、その選定にコンペが必要になる。鶏と卵だ。

でも、実際にどんな動きをすれば事態が改善されるのか未だよく分からないが、もしも全てのWeb案件で、「要求定義」という言葉を「要求開発」と改め、そもそも何がやりたかったんだっけ?から議論できたとしたら、何かが変わる予感がする。種をまき、実を成すチャレンジではないだろうか。

参考:

以上。/mitsui