レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

5章プラクティス1やり方より先に目的、理由、誰のためかを伝える

従来のソフトウェアプロジェクトでは開発の半分もの時間が要求収集に費やされていた。初めから勝ち目はないのだ。チームが要求収集に重点的に取り組むときは、コーディングに関して技術指導もされていないビジネスアナリストのような経験の浅い人たちを連れてきて、顧客のところに送り込み会話をさせる。最終的には、顧客の話すことを中身もわからずそのまま伝えるようになるのが常だ。

人は、相手に求められていそうなことを言う傾向がある。顧客と接する専門家であっても、このワナに陥りがちだ。「いや、欲しいのはそれではなく、これですよね？」とか、「うまくいくか気を揉むのはやめましょう。開発者を信頼していればきっと前に進みますよ」とは顧客には言いにくいものなのだ。

顧客の求める機能をリストにして、私たちが考える顧客の言ってほしそうなことを言えれば簡単だ。「わかりました。できると思います」と。だが、本当にできるのだろうか？

さらに重要なのは、やるべきかということだ。

話し言葉では、自然と実装の観点になってしまう。それが人間の話し方なのだ。そして、自分がそうしてしまっていることに気づくのは難しい。私は自分なりの理解を経て一般化する。あなたは私が一般化したものを聞いて、あなたなりに理解をする。そうして最終的に、それぞれが共通の理解だと考えるような2つの異なる経験則を持つことになる。だが、それらは十中八九まったくの別物だ。

要求の妥当性を検証するのに決まった形はない。顧客がアナリストに伝え、アナリストがドキュメントにし、開発者がそれを読みながらコードに落とし込む……。まるで伝言ゲームだ。ものの再解釈の仕方というのは千差万別だ。それゆえ最終的に顧客にリリースバージョンを渡しても「そんなことは言ってない。欲しかったものはそれではない」と言われてしまうのだ。 ...