三版開発の勧めっていうか考察

いくつかの元ネタがあるのですが…とりあえずわかりやすいところで、ここ。
アジャイルだウォーターフォールだいう前にさぁ
http://msg.errobj.info/weblog/0902/000845.html

一見「これはこれで発注側の本音だよねぇ開発側も真摯に受け止めないといけないよねぇ」って思うのだけれども、冷静に読みつつそこに「経験からくる背後周囲の状況を重ねあわせる」と、概ね -検閲削除- な感情を呼び起こします。
最終的に「好意的な戦略へのプレゼン」にしたいので、王道にしたがってまずは「気になるところ、まずい点」から。

顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。
この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初から満足な量の要望なんて出し切れないんだよ?

「顧客は、内側に要望はあるんだけど、それをどうやって出力したらよいかの方法論について無知なので。そこをいい感じでヒアリングして引き出してくれるのが開発側ぢゃね？」っていうお話。
一見正論。
「いくつかの前提条件が満たされる仮定において」上述は概ねYesです。

えと…軽いところから。
「それって開発ってか正直コンサルに近いところがあるよねぇ」っていう職分の問題がありまして。「開発が出来るようになりましたなえんじにゃ〜」な程度のレベルでは、ぶっちゃけいかんともしがたいのです…が、「安く押さえようとする」と、そゆのが引っかかってきます。要注意。
なのでまぁ「提案やヒアリングも出来る」ある程度のレベルのえんじにゃ〜を、真っ当な適切な単価でひっかけてくれば、ソコについてはクリア。
えんじにゃ〜的には「ヒアリングとかインタビューとかニーズの吸い上げとか、その先にある提案とか設計とか」のスキルを学びましょう。

で、改めて議論したい「前提条件」。
上述の、Blogにある「顧客が自分でまとめた要望なんて穴だら」という単語に焦点をあててみましょう。
ポイントは、その穴が、どこにどんな理由で存在しているか、って部分。
その穴が「考察はしっかりしているんだけどうまく表現できない」んなら無問題。ただ、大抵の場合…そこぢゃない。
んじゃ、どこか？

「「いくつかの前提条件が満たされる仮定において」上述は概ねYesです。」の文章の前提条件は「顧客内では少なくとも、きちんとした要望がブレなくかたまっていて」いること。
んでもっておそらくぶっちゃけると「まず無理」。

実際問題として
・もやっとしたイメージはあるけど詳細についてはそもそも考察が出来ていないっていうか思考の軸になる骨格も曖昧だったりする。ぶっちゃけ、企画じゃなくて「アイデア草案」レベル。思いつきって言い換えてもよし
・んなもんだから、ちょっとした時間的/外的要因などで普通にイメージが、枝葉末節じゃなくて主軸レベルで平気でぶれる
・上に「社内共有が(まぁ当然ながら)できていない」って状況を前提にさらに大抵は担当者≠ステイクホルダーなので、途中でステイクホルダーからの割り込みが入って話が変化する
・かててくわえて、時流とかバズワードとかが自然に入り込んで、さらに要望が三回転半するのを「ビジネスには柔軟性が必要だから当然」とかって正当化する
ってのが一般的。
これだけの「未来変動」があると、必要なスキルは「インタビュー」ではなくて「未来予知」になるざんす B-p

その辺をあらわすのが、この辺の文章。

要望を仕様書としてまとめる代わりに、いわゆる「最低限を満たして動くもの」をもってきたとしよう。それに誘引されて顧客側の頭のなかに「どんなものを作るべきなのか」が見えてくるよね。

うんまぁそんなもんだよねぇ。「最低限を満たして動くもの」が出てきて、初めて「「どんなものを作るべきなのか」が見えてくる」と。
でもそのタイミングでようやく顧客が「こんなもん作りたいなぁ」って思うようなものを、どうやって事前に、作成前に、見積もりのタイミングで、理解しろというのだろうか？ と。
# 受発注の流れによっては、普通に下請法違反な流れですし B-p

ちなみに。
上述が「見積もりを取る段階、あるいは見積もるためのヒアリング付近」であれば、まぁぎりぎりセーフ。ただ「見積もりを取るために、最低限とはいえ動くものを作る」のは、色々と労力的にちょっと以下略。ちなみに折衷案としてはmockupで、これだとまだなんとか。
ヒアリングしてある程度認識をすり合わせてOKもらって見積もって契約を締結して、って後に上述がでてきたら、完全にアウト。
まぁ「見積もりがあまい」って話もあるのですが、そもそもとして「見積もる根拠をちゃんと提示していないっていうかその根拠が流動的に変動する」って時点で色々といかがなものかと。

でも、少なくともここのBlog主は、んで正直にいうと大半の発注者が

でもそこで「こうじゃなくてこんなのがいい」ってつたえたら「できるけど費用と納期に影響が出ます」って。それはあんまりだよ。もう予算とってプロジェクト走り始めてるんだよ?

といい

企画意図の共有ができてないなんて開発以前のヒアリング能力の問題だよね?

といってくる。…そもそも「その予算の根拠」はどこにあるんだろう？ やることやりたいことも決まってねぇのに。

えと…要約すると「なにか欲しくて、でもその何かは僕もよくわかってないんだけど、最終的に製品を見たときに"ああうんそうだよ僕がほしかったのはこれなんだ"って言うようなものを、事前に正確に予算と工期を見積もった上で作ってくれ」であってます？

上述を満たせる能力は、ヒアリング能力ではなくて、予知能力といいます。
以前は「読心能力が高ければ」とも思っていたのですが、読心では「外部要因」「未来の変動」に耐えられないので、やはりここで必要なのは「予知能力(プレゴクニション)」１択になります。
それ以外の選択肢としては…人心操作系呪文？ でもそれ使えるならそもそも「開発とかなにもせずにお金を頂戴できる」ので、開発前提で考えるとやっぱりちがうなぁ。
なのでやっぱり要求能力としては「100%を誇る予知能力」。…どうやってその能力を身に着けましょうかねぇ？ どこぞの都市学園の、今は壊れてしまった「おそらに浮かぶコンピュータ」でも再現してみますかねぇ？

閑話休題

いやまぁ気持ちがまったくわからないとは言わないのですが。とはいえ、現実を冷静に見据えるに、どう考えてもご無体極まりない話だと思いませんか？
同じ話を「建築で」繰り広げたらどうなるんでしょ。
家を建ててから「やっぱり間取りが気に食わないから、部屋数ふくめ、間取り全部作り直していただけるかしら？」とか。
…それ、本当に言ってみたら、どうなるんだろ？(苦笑

んで。

ゆえに本来的には「まず最低限、顧客のほうで何がほしいかっていう要望くらいはきちんとブラッシュアップして、発注の前後でぶれない、過不足のないようにしておいてくれ」という話になるのですが。
えと…そっち側の人にわかりやすく言うと「必要な機能、できていなければ困ること、をMECEでまとめてください」とか。

ただ、とりあえずどこに問題があるかってのはさておいて、少なからぬクライアントが「モノが出来上がってからようやくイメージが湧いて、ようやく要望が見えてきて、そこから変更と追加が雨あられと出てくる」様子をみていると、おそらく「事前に要望を練り上げる」っていうのは難しいのであろうと推測するので。
だとすると「何がしか対策を練る必要があるのではなかろうか？」と思われます。

そこで「三版開発」です！！
(やっと本題だよ orz)

基本的には
・α版
・β版
・リリース版
の３版で構成します。
以下、開発の流れ。

まずは「α版」の設計をします。ここでは「しっかりとヒアリング」して「必要なものを原則として漏れなく」聞き出します。
設計にそって一端makeします(ここではデザインをあてないことを強くお勧め)。
納品して、α版の契約を終了します。

α版を見るときっと色々と「顧客側の頭のなかに「どんなものを作るべきなのか」が見えてくる」はずなので。
この時点での「どんなものを作るべきなのか」をまとめるのが「β版」の設計。その後、makeをします。
納品してβ版完了。
場合によってはこのあたりでデザインをあてつつ「一般公開」とかをするのもあり、かと。

で。おそらく「β版をみて初めて気づくこの辺」ってのがあるので、その辺をヒアリングして設計してmake。
この一連が「リリース版」の契約。
ここでまだ「リリース版をみて初めて気づく今日この頃」があるなら、２版、３版と版を重ねていきましょう。

こういう風にすると、お互いにあまり波風を立てずにいけるのではないでしょうか？
ちなみにβ版の金額は、α版の、大体0.6倍〜2倍くらいの間におちる、ことが、比較的多いんじゃなかろうか、と、予想、してみます。比較的高めの確率で。あくまでも確率にすぎませんが。
なので「気持ちとしては"αで開発が終了する"くらいの気持ちできちんと練り倒している」前提で頑張れば、α版の見積もりの1.6〜3倍くらいのご予算でいける「可能性」が、もしかしたら、状況によっては、ある程度くらいの確率で、あるんじゃなかろうか、と。
なので、その程度の予算を見越しておくと、あるいはもしかしたら大丈夫「かも」しれません。

時々、βのほうが、αの数十倍くらいに膨れ上がりそうになることもあるのですがまぁおいといて。
ついでにいうと「根本的に技術的に不可能な話がβになって飛び出してきた」ら、それは「不可能だよねぇ」で終わるのですが。

そのあたりについては。
もちろんクライアントが悪いわけではありません。要望が「技術的に可能か不可能か」なんてわかるわけないんですから。
でも同じくらいにエンジニアも悪くありません。そもそもとして「聞いてもなければ議論の俎上にも上っていない機能の技術的工数的可能性なんて、どうやったって把握しようがない」んですから。
なので、膨れ上がったり不可能だったりすることがβ版とかで判明したら「しかたがないねぇ」とつぶやいてあきらめましょう。
で、もしあきらめるのがどうしても嫌ならば「当初の練られていない場当たり的思い付きに無駄に固執せず、予算的技術的に可能な折衷案をきちんと受け入れ」ましょう。
あぁ莫大な予算があれば「お金に物を言わせる」方法も、なくはないです。たぶん、桁が３つ４つ、ないしそれ以上、程度変わりますが。

…こうやって見ていると。
やっぱり現況は「企画を立てた人間が、その企画を練りきれてない」のが根本原因だなぁ、とは思うのですが orz
あるいは「基本的なスキルと知識が欠け過ぎている」とか。ITのサービスを考えるのに「基本的な技術知識すらない」ってあたりで「根本的に崩壊してるよねぇ」とか思うのですが…まぁ。

とはいえ「けっして稀ではなく」おきうる事象なので、まぁ簡単に見解とかメモとかを。