ソフトウェア業界で最も古くからあり、最もプロジェクトに採用実績のある素晴らしいソフトウェア開発プロセスのファンクション製造駆動開発をご紹介します。この項目は、独自研究を元に書かれています。
ファンクション製造駆動開発（FMDD）とは何か？
ファンクション製造駆動開発とは、Function Making Driven Development の略で、（経験豊富なプログラマは説明せずともご理解いただいていると思いますが）その名の通りまず何よりも先にプログラミングを行い機能を製造する事によって製品を開発する手法を指します。
この「何よりも先に」というのは、要求仕様を策定する行為をプログラミングで代わりに行い、要求仕様が確定した段階でおおよその実装も完了するという素晴らしい納期短縮テクニックを指します。
よくアジャイルプロセスの一種と勘違いされる方がいらっしゃいますが、FMDDでは顧客との対話は行わず、架空の顧客（もしくはベテラン過ぎるSEまたは会社上層部）から発せられる突発的な思いつき素晴らしいキャッチフレーズを元に推測交じりに開発することを指します。
ファンクション製造駆動開発宣言
アジャイル宣言(をパクって)にあやかってFMDDでも以下の宣言を採択しています。
プロセスやツールよりも常駐して実装を、
包括的なドキュメントよりもソフトウェアの実装を、
契約交渉よりも期間見積もりを、
計画に従うことよりも顧客の機嫌を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
FMDDの開発プロセス
ここで本当によくある一般的なウォーターフォール開発と当、FMDDとの違いを説明します。
FMDDの開発プロセスの例
(1)誰かの何かの思いつき → (2)プログラミング → (3)思いつきによる仕様変更 → (4)実装 → (1)に戻る
(5)予算がなくなり次第テスト → (6)運が良ければリリース/運用
FMDDの非常に優れている点は「本当は何がしたいのか」というプロジェクトの起点となる原初の要望をエンジニアに伝えない点です。本来ならばその「何がしたいのか」を元にシステムのシナリオを作成すると思いますがそのような事は行いません。発案者の希望に沿うように情況が許す限り機能のプログラミングをし続け突発的な仕様変更を繰り返します。
このことにより副作用として「何が正解かわからない」「仕様変更がたび重なり構造が崩壊寸前」「ここに至り技術文章が皆無のため仕様が北斗神拳状態（一子相伝的何か）」の様な事態が発生するかと思いますが、若い(未経験～2年目)プログラマを客先に大量投入して顧客に現場を監視させることにより事態が(一見すると)解決[する|したかのように見える]ためご安心ください。
そうこうしているうちに発案者の予算が尽きなし崩し的にテストフェーズに突入します。そうして「何が仕様かわからない」状態からテストが品質保証ではなくただのデバッグとなり、テスト者の感性によった不具合の報告（「ここは見た目が悪い」や、「ここの操作性はこれではダメだ」）をすべて「仕様です」と言い乗り越えデバッグが終了します。
そうして出来上がったプロダクトは糞以下のゴミ非常に素晴らしい性質（非一貫性、保守困難性、素晴らしい操作性、性能）を持っているためその膨大な赤字額を回収するべく、テコ入れのため担当が変わり、またもやFMDDが発動するもしくは外部の専門家が介入し、赤字額を更にふくらませ製品は世に出ることは無いでしょう。（運が良ければ出るかもしれませんがその頃にはプロジェクトに参加している可能性が非常に低いため知ったことでは無いです。）
つまりどういうことだってばよ
ここまで書いておいて何ですがFMDDには関わらない方がいいです。逃げられるなら逃げましょう。こんな現場に長いこと居て「仕様の伝承者」みたいな存在になるとなかなか逃げにくいです。プログラミングの勉強にはなるかもしれませんが…
もしSEとしてこんなプロジェクトに直面してしまったら、お客さんの言う事を鵜呑みにして機能を開発する事だけはやめましょう。大抵本当にやりたい事は別にあります。FMDDを要望してきた場合、まず、落ち着いて、具体化する前に、背景や趣旨といったものをちゃんと聞いたほうが良いでしょう。(中には怒り出す人も居るそうですが…)「どうしてその機能が必要なんですか？」「誰が何に使うのですか？」と軽く聞くだけで大分違うはずです。そしてその時聞いた事をペラ紙1枚でもいいので何かに書いて会社のストレージに保管しておきましょう。必ず後で必要になります。要件超大切。
[要求|要件]定義についてはFMDDの範囲から外れるので会社の先輩か書籍かネットで調べ頂ければと思います。
