子供の頃、私はニンジンが嫌いでした。においや食感がイヤだったのです。しかし実家を出て、自炊をするようになってからニンジンが好きになってきました。ニンジンそのものが変わったわけでもないですし、私の味覚が変わったわけでもありません。違いは調理法です。私の母や彼女と同年代の多くの英国人は、料理が得意ではなく、特に野菜の料理はイマイチでした。母はニンジンを20分以上茹でていたのです。適切な方法でニンジンを調理すれば、全く違った味になるということを私は学びました。

ここは調理のことを話すサイトではなく、ソフトウェア開発のことを話すサイトです。しかし、技術やツールはおいしくないニンジンと同じだなと思うことがよくあります。それは、「その技術が適切に用いられなかったことが本当の問題であるにも関わらず、技術自体が良くないものとして非難される」という点においてです。

いつか例を挙げてみましょう。私の複数の友人が、「ストアドプロシージャは最悪だった。なぜならバージョン管理できないからだ」（バージョン管理の代わりに、GetCust01やGetCust02、GetCust02Bといったような名前を付けていたそうです）と言っていたことがあります。これはストアプロシージャの問題ではなく、それを使う人たちが正しく使えてないのが問題なのです。同様に、TDDは設計を不安定にさせる、と批判していた人たちに更に話を聞いてみると、そのチームではリファクタリングを全く行っていなかったということが判明しました。リファクタリングは、TDDの重要なステップです。

どちらも茹でたニンジンと同じで、有効なツールを正しく使えていないのです。ストアドプロシージャ、TDDのどちらにおいても価値を見出してきたチームを私は知っています。使用方法を考慮せずにこれらの使用を取りやめてしまえば、私たちは役に立つツールをツールボックスから失ってしまうことになるのです。

しかし、全ての技術の失敗が茹でたニンジンというわけではありません。私は確かな情報として、リスを調理する方法はないので、リスをどうしても食べたいと思ってない人にとっては、食欲をそそられるものなのだと聞いたことがあります（この春、リスたちが私の庭で何をしていたのかと考えると恥ずかしくなります）。もし、共有フォルダ内でバージョン管理無しでコードの作業を行うチームであれば、技術を活用することはできないでしょう。それは同様に驚くようなことではありません。

ですから、技術の失敗を耳にしたら、私たちはより多くのことを質問するべきなのです。

• 問題は技術そのものなのか？　それとも、何か他のことを見逃してしまったのか？　技術が影響を及ぼしているのか？　（バージョン管理とストアドプロシージャは別物ですが、ツールの特性が関係しているので、バージョン管理とストアドプロシージャを一緒に使うのは難しくなります。）
• 適したコンテキストで技術は使われていたのか？　（テストをしていないのに、大規模なリファクタリングをマニュアルで行ってはいけません。）ソフトウェア開発というものは、人間が行うものだということを覚えておいてください。文化や個々の好みによって、技術がコンテキストに適さなくなることはよくあるのです。
• 技術の重要な部分を見逃していなかったか？
• 現実に即していない兆候に気を取られていなかったか？　このようなことをSteve McConnellは カーゴ・カルト・プログラミング と呼んでいます。
• ある一定の範囲では機能する技術を、適用可能範囲を超えて使用していないか？　「薬と毒の違いは投薬量である」というパラケルスの原則を覚えておくといいでしょう。UIを使ってシステムのテストを行うことは、幾つかのケースにおいて有効ではありますが、メインのテストアプローチとして使用すると、遅くて壊れやすいテストになってしまうでしょう。そうなれば、あなたは足手まといになるか、無視される羽目になるでしょう。

この興味深い側面は、ある技術が脆弱かどうかという点です。例えば、その技術は正しく適用するのが難しく、欠点の多いアプリケーションになりやすいのでしょうか？　その技術を適切に使うのが難しいなら、それは技術上の妥当な制限であり、技術を使うことができるコンテキストが削減されます。繊細な食材は、熟練のシェフに任せなければいけません。そうすれば、間違った技術を実施することはなくなりますが、対応できるのは熟練チームだけに限定されてしまいます。これがコンポーネントの統合を遅い段階で行うことに関する基本的な問題であると、私は主張します。一部のチームがギリギリの段階で統合できるように入念な仕様でコンポーネントを開発することができる一方で、実際には、それをやってのけることができるチームはほとんどありません。そして、直前の統合は結局Fuguのようになります。

茹でたニンジンに注意を払う必要がある一方で、「方法論は一度も失敗したことはない」とされる状況も把握する必要があるということを覚えておいてください。どんな失敗でも（ここでは「 WhatIsFailure 」で書いた内容をご存知と仮定します）、方法論から幾つかのバリエーションを見つけることができます。このことが擁護者たちに「方法論に従わなかったので失敗せずに済んだ」と言わしめることになるのです。真の不安はこの点、つまり、技術に裏打ちされた深層原理を深く理解することなくして解決できない失敗にあります。重要な点は、「スパゲッティ・カルボナーラには、迷うことなくお手本にできるたった一つのレシピは存在しない」のと同じように、そのような技術を厳密に言葉では表現できないということです。結局、本当に重要なものは出来上がった料理、つまり調理の技術であり、優れたシェフを奮い立たせ、指針とすることができます。しかし技術があっても、ある程度のスキルを持たない人が成功することを保証できません。

どんな職業でもそうですが、お互いの経験から学べば、より早く習得することができます。技術やツールを使っている人たちによるレポートは重要で、それを基に自分たちの仕事で何を試すべきかを判断することができます。しかし、単純な偏見にとらわれることは一般的に、判断を下すのに十分ではありません。技術の適正な使い方のコンプライアンスを測定することができないのと同様、成功の度合いを測定することはできません。重要なことは、うまくいかない技術の存在が判明した時はいつでも、ニンジンを茹で過ぎていないかを見極めるために、深掘りをすることです。そうでなければ、価値あることを実施する機会を逃してしまう危険があるのです。

当初、私はこの話題を「不完全な技術を二分する」の中で書きましたが、今は、茹でたニンジンの比喩の方がより覚えやすいと思っています。

参考文献

私は、Ron Jeffriesの同様のたとえ話、「 野球をしてみたが、できなかった 」が気に入っています。

謝辞

記事の草案を、内部メーリングリストで一緒に検討してくれたHenrique Souza、Jeantine Mankelow、Karl Brown、Kief Morris、Kyle Hodgson、Matteo Vaccari、Patrick Kua、Rebecca Parsons、Ricardo Cavalcant、 Roni Greenwood、Sriram Narayan、Steven Loweに感謝します。