連載
開発をもっと楽にするNAgileの基本思想

第4回 「プチ・パラダイムシフトせよ！」

メソッドを作るとき、どんなふうに考えて作ったかの？ 例えば、この「足すキーを押す」というメソッドはどうぢゃ？

はい。まず、「足し算ができる」というテスト・クラスの中に「足し算キーとイコールキーで足し算ができる」というテストを作って、どんなふうに電卓のキーを押して足し算をやるのかを考えました。次のようなテストです。

ここで決めたのは、次のような仕様です。

　この電卓では、最初の状態から数のキーを［1］［2］［3］と押していくと、表示は「123」になるべきです。その後、足すキーを押しても表示は変わりません。次に、数のキーを［4］［5］と押すと、「45」になります。ここでイコールキーを押すと表示は足し算の結果である「168」になっているべきです。そして、再度イコールキーを押しても表示は変わりません。

うむ。

このように、テストを書いていく中で電卓オブジェクトがどんなメソッドを持つべきかが決まります。それで、まずは電卓クラスにメソッドのスタブを追加していきます。それから、テストが通るように、少しずつメソッドの実装を書いていきます。

うむ。そうぢゃ。ここでのポイントは……メソッドが最初に書かれるとき、

「どうやってメソッドを作ろうか？」

とは考えないということぢゃ。そういう視点でプログラミングは行わない。

「どうやって作ろうかと思い煩ってはならぬ」

　図にしてみようか。

顧客視点の開発

顧客視点の検証

まず、「顧客側の抱えている問題は何か？」と考える。この場合、電卓オブジェクトを使う側が顧客で、電卓がサービスを提供する側ぢゃ。

　TDDでは、テストが顧客になっている。そして、顧客側の視点で、以下の順序で進んでいく。

「テスト」ではさらに、サービスが自分の問題の解になっているのかを顧客としてテストする。実装側でリファクタリングが行われたときも、それが解であり続けているのかをテストする。もちろん顧客側の視点でぢゃ。これは、ミクロな単位での受け入れテストといえるぢゃろう。

……なるほど。

さて。まったく同じ問いを3度お前に問うことになるが、

ソフトウェア開発は何のためにやるのだったかの？

はい。顧客の問題を解決するためです。

そうぢゃ。そしてそれは、ソフトウェアの規模が大きくても小さくても同じぢゃ。クラスを作るときも、小さなメソッドを1つ作るときだって同じなのぢゃ。クライアント・オブジェクトの問題をサーバ・オブジェクトに解決させる。また、顧客であるテストによって記述された問題を、サービスの提供側であるクラスやメソッドに解決させる。

　まず「問題は何か?」と考える癖を付けよ。プロジェクト全体を考えるときも、仕様を考えるときも、設計のときも実装のときもぢゃ。

　ソフトウェアを開発するときは、

「このソフトウェアは、どういう問題を担当するのか？」

と考えるのぢゃ。つまり、

「このドキュメントは、顧客のどういう問題を担当するのか？」
「このオブジェクトは、顧客オブジェクトのどういう問題を担当するのか？」
「このメソッドは、顧客メソッドのどういう問題を担当するのか？」

と考える。別のいい方をしてみようかの。

「このドキュメントは、顧客をどう幸せにするのか？」
「このオブジェクトは、顧客オブジェクトをどう幸せにするのか？」
「このメソッドは、顧客メソッドをどう幸せにするのか？」

開発者というのは、解の側からの視点で方法を考えがちなのぢゃ。「どうやって解こうか」と考えてしまう。大切なのは、顧客視点での価値を増やすことぢゃというのに。

　例えば、「電卓に足し算機能を付けるには、どんな実装を書こうか？」と考えてしまう。「足し算機能を付ける」という作業で、メソッド名も決まる前にいきなり最初に足し算する部分の実装を書こうとする者もおる。いきなりライブラリのヘルプを見て、どれが使えるかを探す者もおる。

　だが、滝よ。「どうやって作ろうか？」にとらわれるな。重要なことは、

「顧客の問題を解くことにコミットすること」

なんぢゃ。そういう態度を持つことぢゃ。決して自分の問題を解こうとすることではない。

　顧客視点で考えよ。ソフトウェア開発では顧客視点が大切なんぢゃ。そして、それは、クラスを1つ作るとき、メソッドの名前を1つ付けるとき、パラメータ名を1つ付けるときでも同様ぢゃ。粒度が小さくなっても同じなんぢゃ。

「顧客の問題が開発を駆動する」

　オブジェクトの粒度でいうと、こうなる。

「クライアント・オブジェクトの問題がサーバ・オブジェクトの開発を駆動する」

　そして、TDDでは、テストがクライアントの問題を表現するので、こうなる。

「テストが開発を駆動する」

　これがTDD、テスト駆動開発ぢゃ。TDDではない従来のやり方「設計 → 実装 → テスト」とは、視点が違っていることが分かるぢゃろう。顧客視点（＝ソフトウェア開発の本来あるべき視点）なんぢゃ。

　ちなみに、プログラミングの中でクラスやメソッド、オブジェクトなどの「名前付けが重要」なのも、顧客の問題を記述するのに必要な概念が「名前を付けることで決定する」からぢゃ。開発者視点で考える者の中には、実装のための名前付けになっているものも多いようぢゃ。しかし、「変数名やメソッド名なんてコンパイルが通ればよい」とばかりに、いいかげんな名前を付けるのは、とんでもないことなんぢゃ。

それから、もう1ついっておこう。顧客の「要求」というのも、やはり問題から出てくるものぢゃ。顧客の要求を形にするには、問題に目を向けることが不可欠ぢゃ。そして、

「要求は最も抽象度の高いソリューション」

という言葉もある。ソフトウェア開発とは、「その抽象度の高いソリューションを徐々に、より具体的なソリューションに変えていく作業」ぢゃ。その源になるのは、顧客の問題ぢゃ。つまり、「顧客の問題が開発を駆動する」ことになる。

　滝よ。TDDを実践することで、やがてお前にその視点が芽生えてくるだろう。TDDが、お前にプチ・パラダイムシフトをもたらすことぢゃろう。