これは誰に読んでほしい記事か
- 経験の浅いメンバーで集まって、これから何かをやってみよう！でもどうしたらいいんだろう？とさっぱり方向性が定まらないスタートアップの方々
- 会社の方針通りに頑張っているのに、無理なスケジュールや理不尽な仕様の要求、または納得感の低い仕様変更に苛まれる開発チームの方々
- お客様にプロジェクトのこれからについて話し合いたいが、なかなか良いコミュニケーションが取れず、すれ違いによる焦り、圧迫感や威圧感のある打ち合わせに弱腰になってしまう担当窓口の方々
- 開発を依頼した会社から「要件定義」という言葉を聞かされ「なんだそれ？何すればいいんだ？」と露頭に迷っている依頼主の皆様
まえがき：ソフトウェア開発における要件定義や上流工程とは
手短にざっくり言うと、「要件定義」とはソフトウェア開発における上流工程の一部で、その「上流工程」とは製作を行うにあたっての分析や設計についての工程のこと。
もっと柔らかく言えば、要件定義とは「何をしてほしいかリストを作る」ことであり、上流工程とは「何をしたいのか、どうやってするのかをみんなで考えよう！」の段階のことだと思ってもらえばよい。どちらかと言えば企画や営業といった役職のスタッフの分野になり、実作業に携わるプログラマーはよほど重要な立場にいない限り、直接関わることはない。詳しく知りたいかたは専門的な記事や書籍が山ほど出ているので、そちらを参照してほしい。
開発手法には様々なものがあり、理解もバラバラである。この企画・分析を担う上流工程については「最初に一度やってしまったらもう完了というものなのでは？」と認識している方々も多いことだろう。しかし実際には「何をしてほしいか」の単位で”要件”であり、エンドユーザーの要求に応えるアップデートも要件と捉えることができれば、依頼主（クライアント）の好みや思いつきに基づく追加要望も時に要件となりうる。つまり、開発の節目節目で「何をしてほしいかリストの作成」と「どうやってするのか会議」の工程は頻繁に出てくるのが当たり前で、最初に一度決めたからもう安心という話にはそうそうならない。 （仮にあったとしたら、そのプロジェクトは相当危険だと感じたほうがよい）
本記事はその一見小難しい上流工程を、飲食店、レストランの視点で例えて身近に感じてもらおうという意図の記事である。断定口調のとっつきにくい文体で語っていくが、これは筆者なりに意図してのことなのでどうか大目に見てほしい。
上流工程、下流工程を含む開発プロセスの図解（Vモデル）
開発プロセスは一般に次のような工程で進んでいく。
- 要求分析（要求定義）
- 要件定義
- 基本設計（外部設計）
- 詳細設計（内部設計）
- 製造（開発）
- 単体テスト
- 結合テスト
- システムテスト（受け入れテスト）
- 運用、保守
この開発プロセスは工程をVの字に並べた「Vモデル」と呼ばれる図で示すことができる。
この図では同じ層にある工程は対応関係にあり、例えば「結合テストは元々の基本設計の内容を満たせているか？」などといった振り返りを行うのに役立つ。
世に知られ花形の職業として語られる「プログラマー」とは、主に5の製造に関わる役職である。実のところ開発プロセスの中ではあくまでその一端を担っている程度でしかなく、プロジェクトにおいて大きな影響力は持たない。きっちりと段取りが組まれたプロジェクトでは6〜9の下流工程にも携わることになるが、それを全身全霊でこなしきったとしても、各々の負担やプロジェクトの状況が好転することはほぼなく、結果として組織全体が疲弊することになる。
では、一体どのようにすれば貴重な戦力たるプログラマーたちを救えるのかというと、1〜4の上流工程を見直すしかない。それは言葉の定義からして堅苦しく、複数のUMLを使って分かりやすいんだか分かりにくいんだかイマイチ掴めない、微妙に雑なビジュアルでの意思疎通や合意を取らなければいけないという重労働が待っている。ゆえに依頼人も請負人も互いに理解が進まず、悪循環が発生してしまう。プロジェクトを円滑に進めるためには、これをなんとかしなくてはならない。
そこで、この開発プロセスを噛み砕いて飲食店で例えてみると、次のような図となる。
改めて箇条書きで記すとこうなる。
- 家族連れのお客様の注文
- 注文の確認
- 料理の事前説明
- 秘伝のレシピの制作、施行
- 調理
- 味見
- 盛り付けと試食
- 料理の提供
- 接客と後片付け
そしてプロジェクトのチームをレストランのスタッフに当てはめるならば、お客様との交渉を行う営業担当はウェイター、製造を担う実働部隊はシェフたち、チーフプログラマーは料理長と考えればわかりやすい。
1. 要求分析＝家族連れのお客様の注文
要求分析（要求定義）は「何を実現すべきか？」を明らかにするフェーズである。この「要求」は主語が曖昧であり、依頼主からの「これをやってほしい」という要求を指すのか、エンドユーザー（依頼主の顧客）の「あれが欲しいと言ってた」「あれを欲しがっているはずだ」という伝聞や推察に基づく要求を指すのかはケースによって分かれる。例えば「今、時代はメタバースを求めている！！」という触れ込みでアツく語る依頼主がアプリを発注するような状況は後者――エンドユーザーの要求に基づく要求――である。
これを飲食店の例で置き換えると、家族連れのお客様の注文がそれにあたる。要求が曖昧な児童に合わせて父親が「うちの息子に何か口に合うものを」と注文し、それをウェイターが受け止めたり提案したりするのが要求分析である。 お品書きのあるファミリーレストランであれば、「お子様向けにオムライスなどございますが」と示すのが受注側で、「じゃあそれを」と品定めして発注するのがお客様の役割だと考えてもらえばよい。
もし、お品書きがなく「頼まれたらなんでも作りますよ」というスタンスで営業している店舗だと、身の丈に合わない本マグロの寿司などを注文されて応えきれないかもしれないし、無理やり応えた結果経費がかさみ支払いでモメるかもしれないし、見事にこなしてリピーターを作れるかもしれない。ただ、会社やチームを守る立場にいるならば、お品書きと値段表を事前に準備してお客様に選ばせるほうがトラブルは少ないだろう。
そうは言っても、要求分析のフェーズには得てしてトラブルが多く、下記のような課題がよく挙げられる。これらの課題の性質をよく理解しておけば、事前の対策や有意義な交渉に繋がるだろう。
1-a. ユーザーの要求の曖昧さ
俗に「顧客は自分が欲しいものをちゃんと理解していない」と言われるやつである。「顧客が本当に必要だったもの」の風刺イラストでも見られるこれは、ユーザーが何を満たしたいのかをあまり考えていなかったり、なぜそれが欲しいのか理由やキッカケがわからなかったりする場合に発生する。
これは飲食店で言うと、「なんか今日サッパリしたものが食べたい気分だな〜」である。その胃もたれの原因が何にあるかは当人は理解しておらず、またそれを解決するソリューションがそうめんなのか、甘酢あんかけなのか、実はキンキンに冷えたビールなのか、下手すると正露丸なのか、正確なところは医者や栄養士に診てもらわないとわからず、飲食店は頭を抱える羽目になる。
1-b. ユーザーの要求の多様性
求めるものは人や状況によってケースバイケースだよ、という当たり前のことである。生物学や社会学の観点からすれば研究対象かもしれないが、世界の真理を解き明かす大役はその手の専門家に任せて我々は要求分析を続けたほうがよい。
飲食店で例えると「父親はサバの塩焼き定食で小学生の息子さんはオムライスで中学生の娘さんはイチゴパフェ」という状況がそれにあたる。これは当然であり、予め想定できないとこの先つらい。
1-c. ユーザーと担当者との相互理解の難しさ
「お客さんは専門分野には詳しくないから、要求を担当者とすり合わせする際にはすれ違いや勘違いが起きがちだ」という問題である。純粋に知識を知らなくてトンチンカンな話になってしまうという現象もさることながら、昨今のIT企業ではお馴染みな、「スマホアプリやWebサイトであれば日頃馴染みがあるから簡単に作れるものだよね？」という乱造に関する勘違いもこれにあたる。
飲食店で例えると「このピザのLサイズって5分でできますか？」という勘違いも甚だしい注文や「シナシナのフライドポテト嫌なんで揚げたてで持ってきてほしいんですけど」という店舗側の事情を汲み取らない無茶な要望がこれにあたる。
また、小麦アレルギーのお子さんがいる家族が欧風カレーを注文した場合に店員のほうから「小麦粉が含まれていますがよろしいでしょうか？」と確認しなければならない危険なケースもこれにあたり、仮に誠意のある先方であっても前提は揃いにくいという、”相互理解の難しさ”を示している。
1-d. ユーザーの要求の頻繁な変化
「状況や時期、はたまた担当者によって要求がコロコロ変わるよ」という、目を覆いたい事実のことである。ソフトウェア開発の現場においては極力避けたい事態ではあるが、避けられない場合も多い。
これは1-aで挙げた「ユーザーが何を欲しがっているのか自分で理解していない」際に特に多く発生し、もともとの満たしたい欲求を忘れて継ぎ接ぎ、上塗りで要求を積み重ねていくような事態によく発展する。そしてその場合、得てして良い結果は産まれない。例えば「ストーリー重視のRPGを制作しているが大して面白くないな、だったら戦闘にアクション要素を入れてムービー中に早押しクイズをさせれば楽しいヨシ解決（→ストーリーどこいった！）」と悪化していくようなものである。
あえて飲食店で例えると、お行儀の悪い団体様がやってきた居酒屋での右往左往する注文がこれにあたる。作っている最中に呼び出されて「やっぱりタレを塩に変更して」とか、注文を聞きに行ったら「さっき他の店員さんに聞いてもらったんすけど（まだ来なくて）」とニアミスがあったりとか、料理作って持ってきたら「すみません、それもういらないんで。あ、でも生３つ！」とか。
2. 要件定義＝注文の確認
ソフトウェア開発における要件定義ないし要件定義書とは「どのようにして要求を実現するか」の合意、約束事を示すものである。場合によってはトラブルを防ぐために契約書と一緒に作成する。これを行わなければ「あのときああ言いましたよね？」という稚拙な論争や「まだ期間あるので挟み込めますよね？」という周辺の事情を無視したやり取りが増えることになり、開発チームの体力が削がれていく結果となるため、開発チーム側としては必ず用意しなければならない防衛線のひとつと言える。
これは飲食店で例えると「ご注文を繰り返させていただきます」だ。店舗側からは作業的だったり、お客側からすれば上の空だったりして無駄に思える行為ではあるが、これを１回挟み込んでおくだけでお客側は安心でき、店舗側は「合意がなされた」という言質を取ることができ、互いの過失や責任分点を明らかにすることができる。
念押しすることが要件定義の最大の目的であり、それには「サイドディッシュをサラダに変更がおひとつ、アンガス牛ステーキで焼き方はミディアムがおひとつ…」といった提供方法、調理方法のオプション指定に言及することも重要だ。特に、読み上げるだけで顧客の要件やニーズの確認を満たせるような商品名、例えば「とろふわ卵のケチャップオムライス」「パリパリ麺の海鮮五目あんかけ」などは、要件定義のツボを見事に押さえていると言える。
しかし要件定義はそれだけでは収まらず、「何を実現したいか？」の打ち合わせの際には顧客からの暗黙の要求が少なからず含まれていることに留意しなければならない。それは表立っての「機能要件」とは別に「非機能要件」として定義される。
2-a. 非機能要件＝店舗側のサービス
ユースケース図などの資料を使って「どんな機能があるか」を明示する機能要件に対して、非機能要件とは暗黙の要求に対して開発側が提供する仕組み、システムアーキテクチャというものになる。機能性、信頼性、保守性…などいくつかの項目に分類されるが、要するに「バグは全部取りきってますよね？」「エラー発生時にはちゃんとタイトルに戻って再開できますよね？」「サーバートラブルの際には当然復旧できますよね？」という品質保証の部分は非機能要件として当てはまりがちである。
「そんなもの要求されていなかったぞ！」と開発側は反論したくなっても、品質保証されていなければ商品価値としては認められにくい…ぐぬぬ…となる部分は大体非機能要件であり、開発側がイヤでも満たさなければならないモノに当てはまると覚悟したほうがよい。逆にそれらを開発側から非機能要件として明示し、予算などを再見積もりしてもらうことで、互いに負担のない円滑な開発を続けられる。仮に難色を示されるとしても、破談となってしまうかもしれなくても、提供するシステムに必要な工程や甘くない現実は顧客側にどんどん訴えていくべきである。
これを飲食店に例えると、非機能要件とは「店舗側のシステムによる暗黙のサービス」にあたり、ないと困る様々なおもてなしとして認知されている。 以下は一定の水準として飲食店へ暗黙的に要求されるものの、お客側からわざわざ明示化はされず、店舗側は自腹を切ってでも満たさなければならない負担となってしまうものだ。
- 来店時にナプキンや飲料水は無料で差し出されるか？
- 食材は新鮮な国産の有機食材か？
- 食べ残しはお持ち帰り可能か？
- 料理を落としたときに新しいものに取り替えてもらえるか？
- 子供用の取皿と追加のスプーンをもらえるか？
- 食券を買ったあとに現金で追加注文を受け付けてもらえるか？
しかしこれらを店舗側から進んで説明し暗黙のニーズを満たすことで、顧客、店舗それぞれの成功体験や今後の評判に繋がっていく。非機能要件とは、軽視されながらも重要で、「あって当然ではないですよ、費用もかかりますからね」と互いに合意を取って認知させなければ成立しない、サービス業の勘所と言えるだろう。
3. 基本設計＝料理の事前説明
基本設計または外部設計とは、依頼主ないしエンドユーザーが実際に操作する箇所に対しての設計を行い、またそれの説明と合意を顧客側に行う工程である。場合によっては顧客側が要件定義と共に作成し、開発側がそれを了承するようなやり方もある。とはいえほとんどの場合は、開発側が資料をまとめた後に方針や展望を説明したうえでお客様に了承してもらう流れが多いと思われる。
これは飲食店で例えると、これから作る料理の事前説明にあたる。お品書きが揃っているレストランなどであれば自慢の調理方法や食材の紹介、美味しい食べ方のレクチャーなどが当てはまり、仮にお品書きがなく店主がいちいち説明しているような無骨な店であれば、出来上がる料理を口頭でざっと説明したうえでの注意点や確認事項がそれに当たると考えてよい。
3-a. 基本設計にもとづいた開発スケジュールの提示
開発プロセスの最中で、完成までのスケジュール感をお客様に伝えるとすれば、ある程度目算が立って開発側が工数や予算を計算できるようになる基本設計前後のタイミングが望ましい。（まかりまちがっても要件定義の段階ではやるべきでない。確実に安請け合いになる）
こちらも飲食店で例えるなら、事前の注文と準備期間が必要な誕生日ケーキの予約が概念としては近い。要望を聞きつつ出来上がりのイメージを説明したうえでオリジナル商品としての設計を行っていけば、「このサイズでこのトッピングならいつ頃にご提供できて、いくらかかります」という話がスムーズに進められるのである。
このフェーズでは仕様変更に関するリスクに対しても明示化できる。基本設計が終わっているものを挙げてスケジュール感を出し、注文を承ったあとで「すみません、オムライスのケチャップをハヤシのルウに変えられますか」という”仕様変更”がもしやってきたら、お客様には「作り直しになっちゃうのでさらに15分ほどお待ちいただいたうえで別料金いただきますけどいいですか」と交渉を行い、基本設計の恩恵を最大限利用していかなくてはならない。
3-b. モックアップ、プロトタイピングによるユーザー体験の早期提供
近年の開発では、詳細に設計する前の雑な作りで「とりあえず動くもの」を見せてお客様にプレゼンを行うことが活発になってきた。これを完成度に応じて「モックアップ」と呼んだり「プロトタイプ」と呼んだりするが、これらを使ったプレゼンはあくまで興味を引き止めるものでしかなく、広告の一種だ。製品にそのまま組み込まれるといった勘違いを避けなくてはならない手間がある。
飲食店で言えば、店頭の食品サンプルや開発中の商品の試食会がそれにあたるだろうか。試食会のような機会は一般には訪れないため、もし体験できれば特別感からウキウキした気持ちで言いふらしたくなるかもしれないが、そもそもそれが体験した通りに商品化する保証などありはしないのである。（ちなみに、開発中に体験したものを言いふらす行為は機密保持の観点でアウト）
4. 詳細設計＝秘伝のレシピの制作、施行
詳細設計または内部設計とは、内部向けにどのような作り方で作業を進めるかの取り決めを指す。お客様への説明は行わず、開発チーム側で決めたルールに沿って目指す水準のものを作り上げられるようにレールを敷いていくのが詳細設計である。ここで細かく説明を行わなくても、チームワークを行う上では大なり小なり実践していると思う。
これを飲食店で例えると、秘伝のレシピの制作と施行である。レシピのない料理に関しては丁寧に試行錯誤を重ねて時間をかけて練り上げる必要があるが、一度レシピとして完成させてしまったものはただただ機械的に施行するだけでよく、効率的な作業が行える。そして、それを複数用意することで多角的に勝負できる武器となっていくのは料理の現場も開発の現場も同じだ。
注意点としては、依頼主側に明かさない情報であるために「レシピはもうすでにあるだろうから、すぐ完成するだろう」と勘違いされがちな点である。開発チームにとって初挑戦の分野や、制作経験はあっても行きあたりばったりでこなしてきた分野で受注した場合には、背伸びせずに「設計（レシピ作り）から始めるのですぐには形になりません、そのぶん費用と時間がかかります」と明示しておくことが互いにとって有意義な時間の過ごし方となるだろう。
5. 製造＝調理
製造工程は多くのプログラマーが実務として行っている、最も楽しい工程であり、説明不要の部分である。 ただ、チームワークにおいては、高級レストランのシェフたちがどのように連携を取っているかなどのイメージを映画でもいいから眺めて参考にしたほうがよいと筆者は考える。
飲食店においては、言わずもがな厨房だ。
6. 単体テスト＝味見
製造工程において「製作した部品が正しく動いているか？」を検品するのがテスト、ないしデバッグである。昨今では有人テストよりもテストコードを書いてプログラムに問題を発見させるテスト駆動開発の知見が広まっているが、テスト駆動開発はデバッグのためのマクロ製作だとも言い換えられるため、開発状況や担当スタッフの人数、スキル次第では人の手で動作確認したほうが結果的に素早く品質を保証できるケースもある。無論、テストコードを書いてシミュレーションできるに越したことはない。 前提が崩れなければ。
飲食店で例えると、単体テストは味見にあたる。この味見はすべての食材において事細かにやったほうが間違いのないものにはなるが、鯛を捌いては味見、タレを作っては味見、三つ葉を切っては味見、昆布と椎茸でダシを取っては味見、大根をおろしては味見、と過剰な味見をやっていると本末転倒な事態になることは容易に想像できる…。
7. 結合テスト＝盛り付けと試食
製造工程において「製作した部品を組み合わせて正しく動くか？」を検品するのが結合テスト、ないしシナリオデバッグである。ログインのあとメッセージを投稿してからプロフィール編集ができるか？といった、関連する要素を一連の操作で確認する工程がそれにあたり、有人、無人ともに何度も繰り返すにはコストがでかい。これも前提が崩れなければテストコードを書いて一気に検査できるようになるのが理想だが、その理想は毎日更新し続けなければ砂上の楼閣のように崩れ去っていることだろう。
飲食店で例えると、味見よりも本格的な味見、要するに盛り付けと試食にあたる。お客様が絵皿の上で組み合わされた食材を目で楽しんで想定された通りのシナリオで舌鼓を打ち、それぞれの味が調和していくかを料理人自身が確かめることは品質の担保として欠かすことのできない工程であるが、これも毎度やる余裕が料理長にあるかっていうと。
8. システムテスト＝料理の提供
システムテスト、総合テスト、受け入れテストと様々な呼び名がある製造の最終工程は、テストと名のつく工程でありながらほぼ納品と同じニュアンスになる。依頼主のほかにも実際に利用されるエンドユーザー、例えば業務システムであれば利用を行う別の企業様をユーザーとして招待し、本番さながらに操作してもらい運用に足りうるかをテストする。ゲームの体験で言えばオープンβや早期アクセスバージョンがそれだと思ってもらって構わない。
この段階はあくまで「テスト」という名目だが、検品の結果を受けて差し戻し〜再開発となることはまずない。仮にバグだらけで運用に耐えないものであっても、先方の都合上、本番公開をしなければ関係者に迷惑がかかり、逆にひどい目にあうことがわかっているケースが多いからだ。バグが残っていてもアップデートを繰り返して地ならししていく方針が採用されがちで、評判の悪いままオープンβが開けて本番運用の際に閑古鳥が鳴くプロジェクトは今も星の瞬きのように生まれ消えて行っている。
飲食店で例えると、お客様への料理の提供や新商品発表会でのお披露目がそれに当たる。依頼人に完成と言えるものを出して評価してもらい、ちゃんと笑顔で食べてもらえるかは、これまで繰り返し尽力してきた結果がモノを言う。
9. 運用、保守＝接客と後片付け
ソフトウェア開発は製造して納品したらはいサヨナラおしまい、というわけにはいかず、さらなる集客を見込むためのアップデートやトラブル発生時のアフターケアの対応を適宜行っていくことになる。それを「運用、保守」と一緒くたに呼ぶのだが、お客様が「やめる」と言わない限り明確な終わりがないため、これを開発工程のうちの１つとして含めるには多少無理があるのは否めない。
仮に納品してすぐ終わり、公開してすぐ終わりという簡素なアプリケーションの案件だとしても、定期的に「バグを修正してください」といった依頼はやってくる。それらは別途、「運用、保守の業務」として料金を見積もり、また要件定義からはじめる旨をお客様にご理解いただく必要があるだろう。納品から運用、保守のフェーズに突入する前にはお客様へ向けて「納品後、ローンチ後の修正や追加要望の依頼は別案件という扱いになりますよ」と釘を刺しておかないと、代金を払ってもらえないまま長々と保守の業務をやらされるなどのトラブルになりやすい。（特にWebサービスやオンラインゲームに関しては）
飲食店はお客様が帰ると完全に手離れするのでソフトウェア開発のシーンと比較するのは難しいが、あえて当てはめるならば料理を出したあとの接客や後片付けは保守の分野と捉えることができる。定期的にお茶をサービスで入れたり、食べ終わった食器を片付けたり、ビュッフェの料理を入れ替えたり、次のお客様のために消毒したり、食後に店内で過ごすことをある程度許容したりと、料理を出したあとも”おもてなし”を行うことで非機能要件を満たし、顧客満足度を高める企業努力を続けたがゆえに今がある。
また、運用、保守のネガティブな部分に触れると、悪質な客であれば返品や食い逃げ、代金の踏み倒しのトラブル、営業妨害になるような嫌がらせ、今どきの言い方をすればカスタマーハラスメントに対応しなければならない。さらに言うと、もともと決めた製作期間や予算に同意したにもかかわらず追加要望を繰り返す行為は、飲食店で言えばラストオーダーの時間を過ぎて閉店後になっても居座り、追加注文やクレームを出してくるような客がいると考えてもらったほうがいい。 そのような不躾なお客様には身分相応をわきまえてお引取りいただくのが筋というものだ。仮に代金を払ってもらえず大損したとしても、スタッフの健康と店の評判には代えられない。
9-a. 継続的に運用を想定しているサービス自体の納品
本稿では「もしもプログラマーがシェフだったら〜」という建付けで語っているが、業務システム自体を納品して手離れしたり、パブリッシャーからの依頼で開発したオンラインゲームといった、所有権が自分たちにない製品については、少し事情が違い、この限りではないことがある。
それは飲食店で例えるなら、レストラン自体をプレゼン後に依頼主に引き渡してしまうような契約だ。この場合には依頼主のかたが勘違いを起こさないように、決してオープンしたら終わりなどではなく、水道やガスの点検、調理器具のメンテナンス、食材の流通フロー確立、客の呼び込みや宣伝、緊急時の連絡先の確認、支払うべき税金とその手続きなど、やることはむしろ開発より多いことを伝えなければならない。 それを理解しないままリリースまで踏み切ったというのであれば、それはもう悲劇の始まりだとご説明させていただくほかない。
プロジェクトの成功に向けて
「働き方の構造が土方と変わらない」と揶揄され、多くの中小企業が老朽化した多重下請け構造にあえぎ、多くの大企業が身じろぎできない雁字搦めの開発体制に苛まれる日本のIT産業において、依頼主の要件を明確にすることは多大なメリットがあるにもかかわらず、大変実現が難しい。いくつかの企業が「私たちはこれで成功を収めていますよ」という景気のいい話をしておきながら、水面下では大半の企業が社会構造の不条理をどのように跳ね返して泥の海から浮上できるかの大激戦を繰り広げている。
プロジェクトを機械的にこなし予定された工数と予算の通りに推進できるかどうかは、要件定義と基本設計、それに伴うスケジュールの合意とイメージのすり合わせにかかっている。この「上流工程と呼ばれるモノ」を達成するには、依頼主が協力的な姿勢を見せてくれなければ不可能だ。仮に、店に着くなり無言で席に着き、しびれを切らして店員が近づいたら「早く何か美味い物を出せ」と我が物顔で不明瞭な注文を繰り返す依頼主がいたとしたら、数十倍の労力をかけて1人分の利益しか寄こさなかったとしたら、あるいは1円も払わなかったとしたら、そのような非協力的な人物は何としてでも社会から退いてもらわなければならない。
開発チーム内で先方とやり取りを行う窓口担当、営業担当、および役員は非協力的な依頼主に対して、それ相応の覚悟と武器を持って戦うべきだろう。ただ無知なだけなら知識を与えて味方に付ければいい。開幕から威圧的、攻撃的であればそれにはNoを突き付けるべきだ。心優しいながらも忙しさを理由に心を亡くしているのであれば、その者はもう生きていない。いっそ一思いに幕を引いてやってほしい。
どれだけ上層部が騒いだって、偉い人がどんなに圧をかけたって、どの会社のどの事業も「明日は何して遊ぼうかな？」とコンテンツ過多の毎日をウキウキと暮らしているエンドユーザーの事情で動いてたりなどしない。どこかの偉い人のどうしようもない頼みごとを、優しい誰かが聞いてあげている。それで今日もこの国は感謝のお金で回っている。
誰かの願いが、誰かの幸せにつながるように、明日もお客様のご注文を聞こう。
あとがき：筆を執るに至った経緯：日本のプログラマが薄給で使い潰される最大の要因について
まず先に、本記事の冒頭に添付されているVモデルの図2種類は私が作成したものであるが、私はこの図について著作権を主張しないものとする。気に入ったかたはフリー素材よろしく好きに使ってほしい。
折りたたみ。読みたい方はどうぞ
私が所属している組織の泥臭い話であるが、ひとことで言うとITなんでも屋である。縁があってお近づきとなれた企業様に打診し「なんでもいいからITの仕事はないか」と声をかけて、業務システムの保守からハンディターミナルの組み込み、ARを利用したスマホアプリ、単純なWebサイト制作、WebGLを採用した巨大なゲームアプリの開発、よくあるソシャゲの開発支援、果てはVRChatのようなメタバースSNSの開発にまで手を出し、その度に火傷を負ってきた、しがない中小企業の１つだ。
数々の失敗や教訓から「ちゃんとテスト設計を組もう」「スケジュールを制御しよう」「勉強してトレンドの技術をモノにしよう」「ベテランを増やして実力の底上げを」「お客様に理解を求めるべきだ」など実現の叶わない理想論がいくつも飛び交い、「それができれば苦労などしない！」という当時者の叫びで元の木阿弥になる展開を繰り返している。私の組織は皆が一様にして心優しく真面目かつ誠実であるが、その姿勢や成果が適切に評価されることはほぼ無い。
そういった中で組織全体でこれは間違いがないと合意が取れ、ようやく取り組みとして前進することができたのが「要求分析」や「要件定義」といった上流工程の分野だ。「そんなこともやってなかったの？」という顔をされる方々もいるかと思われるが、この上流工程という分野は前述のとおり先方の理解度によって難易度が大きく変わる。何が上流工程を難しくし、プロジェクトを破滅に導いているのかと言えば、『客自身が客であることを理解していない』これに尽きる。
プライベートであれビジネスであれ介護であれ、人に何かを依頼するときには、依頼主が何を要求しているのかを依頼主自身が理解することが重要である。巷の文献では「お客さんは何もわからないもんだよ」と訳知り顔で諭すものばかりが溢れているが、それこそが客を甘やかして問題を肥大化させる要因だ。客は客のプロとして、どのようなものを開発しこういう約束でやってほしい、こちらでここまでは用意する、と「わかった動き」で取り組んで頂かないとこちらもプロとしては働けないということになる。客が客らしく振る舞えない状況が往々にしてあるからといって、「店員が頑張れば済むのでは？」という世論になればなるほど、この国は店員を薄給で働かせ、客に客であることを教えないLose-Loseの関係が構築され続ける。そのあおりを受けた、当事者であるはずのプログラマーやアニメーターがそれに迎合してしまい、技術力と経済力は衰退していくことになる。誇りたいはずの産業が陳腐化する。仮に国の政策としてそれが狙われていたとしても、ゲームやアニメのIT産業で食っていくと腹に決めたからには、断固としてその流れには歯向かわなくてはならない。
この手の話題の周囲には「お客様は神様か？」という議題がつきものであるが、お客様は古今東西変わらず紛うことなき神様である。舞台に立つ主役を見つめ讃え観測し干渉する神そのものである。「こんなやつが神様であってたまるか！」と言いたくなるような劣悪な客は現実には存在するが、それは高貴で有益で柔和な神を期待するとそう言いたくなるだけであって、付喪神や荒神、ましてや貧乏神や祟り神の類を省くのはいけない。仮に目の前にいらっしゃるお客様が荒神の類だとして、神が神であることを自覚していないことこそが何よりの悲劇だ。 神が自分の身の振り方を知らない、客が自分のことを知らない。それが、プログラマが薄給で使い潰される要因になる。「あなたは神様ですよ？しっかり自覚なさってください」と言ってあげるのが、客と対話する担当者としては望まれる姿勢なのである。自分を赤子だと思っている祟り神を赤子だと思ってあやしているようでは、未来は閉ざされていくだろう。
客自身が客であることを理解するまで、プロジェクトは成功に導かれない。今あなたがうまくいっているのであれば、それは大変よい神様に恵まれており、とても倖せなことだ。