開発者たちがアジャイル開発に抵抗感を示すワケ

一見、アジャイルは開発者にとってはとても良い話のように思えますが、いまでも意外と拒絶反応を示されることも多いですよね。

おそらく今までの手法に対する信仰、つまりソフトウェアは工学と管理で制御できるという考え方が強いのだと思います。私に言わせるとそれは妄想でしかないのですが、とにかく「良いシステムを作るためには、しっかり設計しなければならない」というドグマがある。それだけを聞くと誰も否定できないですよね。そりゃそうだよなと思ってしまう。

逆らいがたい「しっかり」の威光

でも、アジャイルはそうは言っていないんですよね。まず、ビジネス価値の一番高い機能を素早く作る。で、それをお客さんに見せた上で、反応を見ながらサービスを広げるべきだと言っている。しっかり設計していたのでは遅いんですよ。そもそも、それが必要かどうかもわからない。

必要ないものをしっかり設計してはだめ。「時間をかけて設計する」ことそのものにもリスクがある、ということなんです。このリスクは、「雑な設計をしてしまう」ことのリスクとの天秤になります。両者を足して、一番リスクが低くなるようなポイントがプロジェクトごとに存在します。このポイントが、「設計を十分かつシンプルにする」という按配で、アジャイル開発はこの按配が肝になります。

妙な完璧主義を捨てて、現実的、合理的に行動せよということですか？

そういうことです。ただ、その完璧主義がなかなか捨てられないんですよね。伝統的な開発をやってきた人にとっては、アジャイルがいい加減な設計をしているように見えちゃう。もちろん、しっかりした設計といい加減な設計だったら、しっかりしている方が良いに決まっていますよ。

でも、現実にはそれは難しい。実物を前にした会話をすることもなく最初から大きな設計をしても、うまくいかないことの方が多いですよね。せっかく作った機能が全く使われなかったり、本当に必要な機能が漏れてしまったりといった事態が起こるわけです。そのことをアジャイルではBDUF（Big Design Up Front）という言葉で戒めています。

先ほどの「よい按配」にあるのが、ENUF（ENough design Up Front）という考え方です。まずはシンプルに設計して、一回お客さんに見てもらいましょう。その方が、絶対に顧客満足度が上がるし、良いものができますよという信念です。過剰品質、過剰デザイン、過剰設計に陥らないようにする。前工程に時間を掛け過ぎないことが重要なんです。

BDUFとENUF

でも、「しっかり」という言葉があまりに強くて誰も否定できないから、ついついそこで思考停止してしまいがちです。何か問題があったときに「しっかり設計していないからじゃん」と言われると、そうなのかなと思っちゃうことってありますよね。

プロジェクト運営などにも同じことが言えそうですね。例えば、ウォーターフォールという仕組み自体に欠陥があるかもと考えるのではなく、そこで定められている標準にきちんと準拠することができなかったからだと考えてしまう。

そうそう、本質的な問題解決とは逆の方向にどんどんアクションしてしまうんですよね。たとえば、コミュニケーションに問題があると、「課題管理表を作って管理する」というような逆方向に進み勝ちです。そうじゃなくて本音で話せる会議をつくるほうがうまくいくんです。（次ページに続く）