ソフトウェア開発では、実際に動くようにする「実装」という作業が必要である。どのように実装するかは「要件定義」という記述を元にして検討され、その要件定義は顧客の「要求」を元に作られるというのが原則だ。本来は要求が先にあり、「〜をしたい」「〜を実現したい」という形式で記述できるものが基本である。「○秒以内で処理が完了する」と言った非機能要求も記述される。しかしながら、この要求による記述内容だけでは、その実現方法が多岐に渡る事になる。そこで、実装を円滑に進めるために「〜ができるようにする」という形式で記述できる要件を定義し、実装側は要件の実現に注力する。容易に分かるのはこうすれば実装の分業がやりやすいことだ。開発業務は元請けから下請けや複数の開発者に至る階層化された業務フローが一般的であり、要件定義は分業の基礎としてビジネス構造にもマッチする。この方法の是非はあるのだが、長年この流れをベースにやっているだけに、なかなか変えられれないというのが実情だとして、この枠内で開発における問題点を考える。
うまく分業され開発が進むかと思うと、現実には顧客が望んでいたものと違ったものが開発されてしまうという問題がある。笑い話になりそうな、全く違うものができてしまうこともある。ちょっと意図的に強調した例として次のようなものがある（もちろん、かなり単純化している）。要求として「ポイントシステムを作りたい」として、要件としていくつか作られた項目の中に「ユーザー管理機能」というものがあるとして、その要件だけを知らされて実装したとしよう。すると、単に住所録みたいなものが出来上がり、管理番号がないとか、期限の管理はどうするのよ？みたいな実装が上がってくるかもしれない。もちろん、通常は自身が実装する要件以外も目を通すので、優秀なプログラマーたちの忖度機能が発動され、次第に顧客の要求に近づくということになる。なんだ、うまく行っているということではないのか？と思われるかもしれないが、うまくいく前提の１つとして、要求も要件も記述されている、つまりは文書化されているという前提がある。もちろん、100%文書化できるものではないのは確かだが、一定以上の割合の文書化がされていないとおそらく忖度ベースの開発は成り立たない。そして、経験上、一定以上の割合が満たされることはほとんどないと感じている。
ソフトウェア開発の形態は実に様々あり、個別の事情も多いのだが、ここでは単純化して、顧客とコントラクターとデベロッパー（開発者）の３つの存在があるとして考えよう。下請け構造については「開発者」の一言で片付ける。ざっくりと言えば、SIerという人たちは「コントラクター」であるが、いわゆる「ゼネコン」の意味でのコントラクターであり、顧客から業務を請負、遂行する中心人物である。このような状況で開発をしている場合、開発者にとっては顧客の要求が極めてわかりにくいことが多々ある。好意的に見えればコントラクターが開発者にわかりやすいように解釈して作業に分割してくれている結果とも言えるのだが、コントラクターが顧客の要求を本当に理解しているのか疑問に持つような要件を投げてくることもある。たぶん、誰も悪意はない。それでも、比較的大きめの開発をしていると、要件に矛盾が目立つようになることが出てきて、疑問は急激に膨らむのである。要件は解釈がぶれる余地のない文章に一般的にはなっていることもあり、開発者は要件は書いてある通りに解釈できるものの要求が断片的にしか分からないと強く感じるようになる。コントラクターとの関係が悪くなると、責任の押し付け合いにもなる。
何とかならないのだろうか？ だからこそアジャイルなのだろうか？ 手法に至る前にまず、問題の本質をどこに求めるかを特定したい。開発者が要件が分からないと感じる時、実はコントラクターも要件はよく分かっていないことが多い。開発者がコントラクターに問い合わせた場合、開き直って「私にもわかりません」と言われても困るのだが、もっと困るのは分かっているふりをすることで、顧客の要求と異なる回答をしてしまうこともある。実は、開発者と同じ程度にコントラクターも顧客の要求が分かっていないと考えるべきだ。そうなると、コントラクターがもっとしっかりすべきなのだろうか？ それでは、よくある「営業 vs 実行部隊」の局面になってしまい責任の押し付け合いに等しく、ここから何か生み出されたことを見た事はない。開発者はコントラクターを責めてはいけない。その理由は、実際のところ、顧客自身が実はコントラクター以上に要求を理解していないからである。顧客に何か要求が明確にあるのかというとそうでもない事が普通にあるというのが現実だ。正直な顧客は「モヤモヤした話で恐縮ですが」と切り出して、構想を語る。不誠実な顧客は「お前らプロなのにそんなんことも分からないのか」と訝る。分からないから聞いているのである。私たちが超能力者でないことを説明する気力は普通は出ない。何れにしても、要求が文書化されているかと言えば、極めて限定的になってしまうのが通常である。
そこで、顧客は要求を理解していないという前提に立つ必要がある。理解していないというのは色々な側面がある。何か構想はあるけど言語化されていない場合もあれば、上司に言われてシステム化の取りまとめをしており経営的な意味は全然説明されずに担当者になっているような場合もある。この点は掘り下げたいところだが、ここでは文書化あるいは言語化されていないという状況としてまとめておこう。このような状況は、次のように考えて見よう。顧客の頭の中はファンタジーであり、顧客の発する言葉はポエムなのである。ソフトウェア開発において、コントラクターはそのファンタジーを実現すべく奔走する人であり、開発者はポエムを開発言語に翻訳する人たちである。それじゃあやってられん！と言う前にこう考えよう。ソフトウェア開発者は、要するにスターウォーズのような素晴らしいSF作品を制作しているスタッフのような存在なのだと。若干無理やりかつ恣意的なポジティブ化ではあるが、ここで前を向かないとどうしようもないのである。
ここであっさり「要求なんぞはないものだ、幻想だ」と言い切るのも無理がある。現在の多くの開発手法は要求が出発点にあるから。要求がないのではなく、開発者は要求を何らかの方法で明確化をする必要があるという前提に立ちたい。筆者は開発者として関わることがあるが、一人で全部行うコントラクター兼開発者の場合もある。後者の場合の問題点はかなり別のことが絡むので、ここでは顧客／コントラクター／開発者モデル場合だけに限定する。短絡的な考えとしては、開発者として関わっても、顧客と直接話をしたらなんとかなるのではないかとも考えた。だが、ビジネスライン的な意味で、普通はコントラクターは嫌がるのと、対顧客に対する原点的な意味での要求獲得は別の難しい問題があるので、開発者と顧客を会わせるというのはよほど限られた状況でしか成立しない。少なくとも、開発者が顧客対応可能なSE能力を持つような場合などである。ということで、顧客／コントラクター／開発者ラインを保って要求を明確化する方法はないかと試行錯誤をした結果、１つの方法がうまくやれば良い方向に行くのではないかという感触を得た。確証を得るほどの事例に当たった訳ではないが、提案はできる段階に来たと感じている。
その方法は、コミュニケーションにおいて、要求の断片を話題に含めて、その要求あるいは会社が正しいかを検証することである。例えば、要件定義として「顧客管理番号は7桁である」と書かれているとしよう。これは少なくとも、「123」でいいのか、「0000123」のようにするか悩む定義である。単に「この要件は管理番号の頭を0で埋めるという意味でしょうか？」などと問い合わせるのが普通だと思われる。このコミュニケーションの中において、要求に近い文章を紛れ込ませる。例えば、「管理番号は、ポイントカードに印刷されるので、頭を0で埋める7桁なのでしょうか？」と聞いてみる。ここで「ポイントカードは印刷してお客様に渡したい」「ポイントカードには管理番号が印刷されていて、システム問い合わせで利用したい」と言った要求を言い換えて、質問に含ませている。このような問い合わせに対して、正解と言われるかもしれないが、違っているかもしれない。「管理番号はポイントカードには印刷しません。単にバックエンドのシステムが7桁で切られているから、それを気をつけて欲しいという意味です」のように答えが返るかもしれない。どっちにしても、ほんの少しだが、要求に近い情報が得られた。もちろん、それは小さな積み重ねだが、全くないより大きな進歩があるはずだ。なんとなくそうなのかなと思っていたことが明確になることも小さな進歩だろう。前記の例だと、「実は顧客情報はバックエンドのシステムにも入れられる」という新しい発見があったのかもしれない。仮にポイントカードに印刷するための0埋めだったとしたら、それをどこでやるのかという議論に発展するかもしれない。
開発者からコントラクターに、要求が分からないから示して欲しいと言っても、コントラクターは開発者と同程度、下手をするとさらに下回るレベルでしか要求は理解していないと考えるべきだ。しかも、コントラクターはその点を意識しているかどうかも怪しい。無理やり文書化をお願いしたとしても、出てくるものには新しい情報はない。顧客に依頼するというのも同様だ。しかしながら、要件の中から要求を含めた、あるいは要求に至る内容を込めたコミュニケーションをすることで、不明瞭な要求群に対して逆算的に少しずつ隙間を埋めるような効果が期待できる。その結果、要求が次第に明確化し、気づいていない関連性が見えて来ることも期待できる。開発者にとって知る事も重要だが、コントラクターやさらには顧客に対しても気づく機会を作っていることも重要である。開発に関わる全ての人の意識を要求のさらなる明確化に向けるためのコミュニケーションが活発になることで、開発現場の様々な側面で要求が次第に固まるということを期待できるのではないかと考える。
この手法で一番難しいのは作文である。コントラクターや顧客との関係上、どこまで言っていいのかなど、ドメインや個別の事情も絡む。要件に絡めるというのが1つの成立しやすい手法だが、普段の会話で投げてみるというのもあるかもしれない。しかしながら、同じようなことを何度も聞く、突拍子もない質問になってしまうといったようなことは避けたほうがいい。バカ者かと思われてしまうのは不利な状況を作りかねない。それでもうまい問いかけを繰り返し辛抱強く進め、成果物に対する着目点を顧客／コントラクター／開発者でなるべく多く共有できれば、より良い結果になることは十分に期待できる。
実装する開発者が何人もいるような開発で、頼りになるように見える人は必ずいる。その人は、発言が多く、かつ、発言の中で、念の為にという意味合いで色々な角度で言葉を繰り出す発言が目立つ。そうしたやりとりが、開発の中で自身の実装部分に対しても非常に参考になったという経験もある。確認のために、条件を言い換えてみたり、その要件の目的をたずねてみると言った行動が、他の開発者の助けになるということもあった。そういう人はコミュニケーションスキルが高いという事で終わらせがちだが、スキルには細かなポイントがたくさんある。その1つが要求の明確化であり、それがコミュニケーションから可能ではないかということも、様々な人たちの行動や自身のプラクティスからの結論である。一方、この方法がうまく行かない事例として、コントラクターが開発者の発言を抱えてしまって顧客に流さないタイプの人である場合だ。コントラクターがしっかりしていればいいとも言えなくはないが、前記の通り、開発者が要求が分からないときは得てしてコントラクターも分かっていない。顧客に確認もしないというのは、単なる顧客に対するイエスマンかもしれないが、要求に対する問題意識がないのかもしれない。こういう現場では、とにかく時間がかかり、作業方針も立ちにくく、開発者の間で何かがぐるぐる回っているだけになる。このようにアンチパターンはある程度は見えている部分もあるが、まずはプラクティスとして問いたいと考える。