連載
NAgileで始める実践アジャイル開発

第2回 ソフトウェア開発をシンプルにする考え方のコツ

さて、「プチ・パラダイム・シフト」だが、今日は5つの価値の中の1つ、「シンプルさ」にコミットすることの意味とその理由を話そう。

　いまさらいうまでもないことだが、ソフトウェア開発というのは、複雑さとの戦いだ。大規模になるにつれ、開発が進むにつれ、そして利害関係者（ステークホルダー）が増えるにつれ、問題は複雑になっていく。その複雑な問題にどう立ち向かうか？

　工学的に考えてみると次のような感じだろう。

　これらはアジャイルだとこんな感じになる。

　もちろん工学的アプローチは重要だし有効だろう。だがアジャイルのアプローチもまた、別の角度から問題解決にとても役立つ。

　アジャイルの方では、シンプルに考えることが大切だ。例えばアジャイルでは、以下のようなことをいつまでもくよくよと思い悩んだりしない。

　これらのことは重要かもしれない。だが、状況や要望というものはどんどん変化していくものだ。これらのことを、悩んだり検討したりしている時間は、結局「変化」によってムダになってしまうことが多い。アジャイルではそのようなムダ、つまり結局はプロジェクトの価値に結び付かないものを嫌う。

　NAgileでは、シンプルに考えることでムダを排除する。取りあえずNAgileでいう「シンプルさ」のことを、（N*ツールになぞらえて）ここでは“NSimplicity”とでも呼んでおこう。

　それではこれから、その「シンプルさ」にコミットする具体的な例を挙げていこう。まずはその考え方に慣れてもらう。

まずこの問題に答えてもらおうか。

え？ なんか唐突ですね。

　うーん……えーと、キリンを小さくする？ 特大の冷蔵庫を日立に頼んで特別に作ってもらう？ 当然キリンは切っちゃ駄目なんですよね。キリンはアミメキリン？ それともマサイキリン？

もっと、シンプルに考えるのだ。この問題の答えはこうだ。

同様にこちらの問題はどうだ。

こちらの答えはこうだ。

　シンプルに考えろ。正解が重要なのではない。考え方を学べ。

では次の例だ。

　次に挙げるのは、アジャイルを現場に導入しようとしている2人の開発者の会話だ。

　前もってリスクを適切に評価するのは重要なことだ。だが、この開発者Bは問題に対して起こってもいない問題をどんどん付け加えていって、問題を複雑にしている。解決方法を提案しても、また新たな問題を持ち出してくる。

　問題を、解けない方向に解けない方向にと、持っていっている。しかもそれに気付いていない。結局、開発者Bは、本心ではアジャイル開発をやりたくないのかもしれない。

　だが、ここでお前にいっておく。

「問題は単純なまま解け。複雑にするな」

　これが「冷蔵庫にキリンの原則」（Giraffe-Refrigerator Principle）だ。

さて、別の例だ。サイバラ（西原理恵子さん）という漫画家がいるのを知っているか？

またまた唐突ですね。

サイバラのある漫画に、数値などの具体的なところは忘れたが、こういうような式が載っていた。

　さすがサイバラだ。

え。そうなんですか。単に小学校レベルの計算が苦手なだけでは……。

まあ待て。私は以前、こういう質問をされたことがある。

　これは難問だ。テスト工程のコスト・ダウンは重要で、かつ、やっかいな問題だ。ウォーターフォール型で開発している場合にはこういう状況に陥りやすい。

ウォーターフォール型開発に対して偏見ありません？

ここでサイバラのやり方だ。

え！？ そうなるんですか？

答えは、

「そんな複雑な状況に自分を持っていかない」

　NAgileでは、日ごろからなるべくシンプルなソース・コードを心掛ける。また、「テスト・ファースト」と「リファクタリング」を行う「テスト駆動開発」（TDD：Test-Driven Development）に取り組む。これらにより、ソース・コードをなるべく複雑にしない。

　そして、顧客へのレビューを常に行うことで、仕様バグを含む不具合をできるだけ早い段階でつぶしておく。プログラムの確からしさを常に確認し、また、ソースも「ペア・プログラミング」や「コードの共同所有」によって、ほかのプログラマーが常に確認するようにする(*2)。

*2 このあたりの手法は、「.NET開発者のための開発プロセス入門」に詳しい。

　つまり、「『バグがあり過ぎてどうにも手が付けられなくなるような状態』に自分を持っていかない」ということだ。

　覚えておけ。これが「サイバラの原則」（Saibara's Principle）だ。

【「サイバラの原則」のポイント】 複雑な問題を扱わなければならないような状況に自分を持っていかないようにする。