ツイッターで、システム開発をラーメン屋に例えたつぶやきが反響を呼んでいました。
ラーメン屋で「醤油ラーメン」と注文した後に「半ライスつけて。餃子つけて。やっぱ塩で。ネギ多め。やっぱ炒飯で。メンマつけて。やっぱ味噌で。もやしつけて。海苔要らない」位の追加注文した客が、最初の醤油ラーメン代だけ払って帰るのを呆然と見るのがシステム開発です。
— ケルビン＠斜壊人 (@legendkelbin) March 17, 2016
これについて共感の意見が多数ありますが、僕（SIerを生業としている）の意見はちょいと違います。
これ、全部”請負”だからうまくいかないんですよね。
大規模プロジェクトは違います。
まずは、要件定義フェーズ。
これは”準委任”契約で行います。期間は基本的に決まっていますが製造責任（つまりラーメンは出さない。）はありません。要件は聞いて、こちら側で整理していきます。
（もしくは頑固なラーメン屋なら、「ウチは味噌ラーメンが売りだよ！」とか言ってきます。特にコンサルが。）
「醤油ラーメン」→はい。
「半ライスつけて。」→了解です。
「餃子つけて。」→了解です。
「やっぱ塩で。」→変更しましょう。
「ネギ多め。」→よろこんで。
「やっぱ炒飯で。」→半ライスはどうしますか？
「メンマつけて。」→了解ですが、トッピング多すぎないですか？
「味噌で。」→お客さん、味コロコロ変えますね。
「もやしつけて。」→味噌ならそうなりますねぇ。提案しようと思っていた所です。
「海苔いらない。」→味噌にはいらないですよね。
ここで、整理します。要件定義フェーズ終了。
成果物としては、
次の工程（ラーメン開発）で
・味噌ラーメン
・もやし
・メンマ
・ネギ多め
・炒飯
・餃子
を作ります。ここで「2000円と30分かかりますけれど良いですか？」（ここで、構築フェーズの見積もり提出）
となる訳です。「そんなに払えるか！」だとトッピングを消す事になりますね。もしくは、「んじゃ、他のラーメン屋に行ってくれ！」となります。
まぁ、普通は基本設計から入るので、「まず、醤油か塩か味噌か決めましょう。」で、仕様凍結（もう決めたよね！変えないよね！）します。
ここからは、2000円をもらって”請負”作業になります。実際にモノを出すまで、ラーメン屋に責任があります。
しかし、ラーメンを出してしまったらあとは客が残そうが関係ありません。（ここらへんがシステム屋は冷たいと言われる所以ですが。）
「味噌だからコーントッピングして」と言われれば「100円でトッピングできますが、どうしますか？」となります。所謂「仕様変更（もしくは、仕様追加）」です。
もし、「味噌止めて塩にして。」と言われたら、今、どこまで調理しているのかを店長が整理して、「まだ麺をゆでている途中でスープを変えれるので500円ですね。」かもしれないし、「もうスープに麺いれちゃって最後のトッピング工程なので、1800円でまた30分かかります。」となるかもしれません。
ポイントは、委任契約と請負契約と言う事なんですよ。
後は「成果物」。これをきちんと”契約”で結んでおかないといけません。
逆に、「やべ、メンマ仕入れるの忘れてた！とか、麺をゆですぎた！」となれば、システム事故になり、30分で済まなかった分の損害賠償がラーメン屋からお客様に発生していきます。
大抵の仕事を規模から「請負」で行うのでこのような事象が発生するのですね。
くそ真面目にSIerの観点から考えてみました。
これは日本式と言うか、ウォーターフォール式開発と言えます。
今、流行りの（流行ってるの？）アジャイル開発ではそうは行かないですよね。DASHの究極のラーメン作るようなもんです。まずは、小麦から。この例は”請負”契約でアジャイル開発をしたバッドパターンなのです。
まぁ、一言いうなら、「食券制」の自販機置けってことですね。
