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

第3回 アジャイル開発のキモはフィードバック！

さてここらで、フィードバックという概念について確認をしておこう。

　フィードバックというのは、例えば次のような仕組みぢゃ。

フィードバックの概念図

システムからの出力を測定し（測定値）、それとあるべき姿（理想値）からの「ズレ」を次の入力に反映してやるわけぢゃ。

　ここで、適切なフィードバックにとって重要なことは、次の2つぢゃ。

　繰り返しになるが、アジャイルではフィードバックをとても重視する。「いかにフィードバックにコミットするか」がアジャイル成功の鍵といっても過言ではない。そこで、

「いかにフィードバックを受けやすくしておくか」

が重要なんぢゃ。

　ちなみにわしは、このフィードバックの受けやすさのことを、

「ツッコマレビリティ」

と呼んでおる。ツッコマレビリティを常に高くしておく。それが肝要ぢゃ。

　そのためのポイントは、まず「見える化」ぢゃ。

　例えば、要求仕様が見えるようにすること。設計が見えるようにすること。実装が見えるようにすること。そして、プロジェクトが見えるようにすること。

　仕様書でいえば、「詳細な仕様書」を棚にしまっておくのもよいんぢゃが、それよりも「しょっちゅう実際に現状のプログラムを動かして見せること」の方がよいのぢゃ。

　プロジェクトの進ちょくでいえば、例えば、壁に貼り出す。いつでも嫌でも目に付くように（＝レビューできるように）して、フィードバックを受けやすくしておく。例えば、壁を使って以下のようにレビューを行う。図のように付せんをそばに置いておくことでさらにツッコマレビリティを上げることもできよう。

壁レビューの例1 ― ソフトウェアかんばん*2

付せんをそばに置いておくことでフィードバックを受けやすくできる。

*2 トヨタ生産方式の「見える化」のためのツールである「かんばん」をソフトウェア開発に応用したもの。ホワイトボードなどに、To-Do、Doing、Doneの3つのレーンを書き、そこにタスクを書いた付せん紙を貼り付ける。作業が進むにつれ、タスクを書いた付せん紙がTo-Do　→　Doing　→　Doneと移動していくことになる。

また、次のように、それまでの活動を振り返るためのツールを使う。

壁レビューの例2 ― KPT法*3

KPT法のツールを使ってそれまでの活動を振り返る。

*3 KPT法とは、Keep（続けていきたいこと）、Problem（問題があったこと）、Try（次にやりたいこと）をみんなで付せん紙に書いて、それぞれの領域に貼ること。それまでの活動を振り返るために用いられる。

これらのツールは、プロジェクトへのツッコミを盛んにするための触媒のような役割を果たすのぢゃ。

極端なまでにレビューをすること（eXtreme Review）。それが素早くフィードバックがもらえるようにする工夫ぢゃ。

　このフィードバック・ループを図で表すと次のような感じぢゃ。

アジャイルのフィードバック・ループ

この図について解説してみよう。まず、次のようなことがいえよう。

　そして、このProblem（問題）にSolution（解）を与えるためにPractice（実践）を行う。それから、これらのすべてを可視化（＝「見える化」）してViewを提供するようにする。これが、eXtreme Reviewなのぢゃ。

　こうしてツッコマレビリティを高く保つことで、eXtremeなフィードバックが得られるようになる。それにより、次のPractice（実践）を改良でき、より的確なSolution（解）に近づいていけるというわけぢゃ。

　ウォーターフォール式でよく起こるように、

「完成間近になって『ああしてくれ』『こうしてくれ』といわれてしまう」

なんて羽目に陥らんようにしたいものぢゃな。

　間違えたら、即座に「んなアホな」「そんなわけないやろ」とツッコんでもらえるようにする。素早く多くレビューして、素早く多くフィードバックぢゃ。このループをリズムよく速く回すことなんぢゃ。

　お前たちにいっておくぞ。

「遅いことは猫でもする」

　分かるかの？

そんな諺（ことわざ）あったっけ？