YAGNIを実践する(翻訳)

概要

原著者の許諾を得て翻訳・公開いたします。

画像は英語記事からの引用です。

YAGNIを実践する(翻訳)

しばらく前に私はLaraconYAGNIの実践についてスピーチしました。このような大きなカンファレンスで大勢の観衆を前にプレゼンしたのは名誉なことでした。以来、私のスピーチに多くの反応や関心が寄せられています。

私のスライドを共有したいという申し出を多くの方からいただきましたが、ほとんどの議論がスライドに対して行われたので、ブログ記事にまとめる方がよいと思えました。スライドをご覧になりたい方は、StreamAConで私のスピーチを視聴できます。


私は自分自身を「探求者」だと思っています。プログラミングの秘訣における聖杯、それさえ手に入れれば即座にスキルアップできるたったひとつの聖杯の探求です。そのような唯一無二の聖杯などありえないことは自分でも認識していますが、いくつかの秘訣なら存在すると信じています。そのひとつがYAGNIです。

YAGNIはエクストリームプログラミング(XP)の法則の1つです(私は日頃からXPを実践しています)。YAGNIは「You Aren’t Gonna Need It(今必要でないことはやるべきでない)」の略語であり、プログラマーは本当に必要になるまでは機能を追加すべきではないと戒めています。理屈では簡単ですが、実践できているプログラマーはほとんどいません。

YAGNIの実践が困難な理由

YAGNIの話を続ける前に、YAGNIがどんな問題を解決するのかについて理解しておく必要があります。その問題とは「オーバーエンジニアリング(over engineering)」です。エンジニアはある時期、複雑であることにプライドを感じるようになるものです。寸分違わずピタリと合うデザインパターンを徹底的に追求したり、もっともっと複雑なアーキテクチャをあれこれ構想したりすることに取り憑かれてしまいます。

XKCDの漫画「一般的な問題」は、このオーバーエンジニアリングの問題を表しています。

The General Problem

「塩ください」
「あのー?」「聞こえてますよ!どんな調味料でも渡せるシステムを開発中ですから」
「ってもう20分も待ってるんだけど」「長期的には時間を節約できるんです!」

この漫画が面白いのは、やってることは間違いではないからです。「とりあえず塩を渡してやればいいのに」と思わずにはいられませんが。

KISSの原則(Keep it simple, stupid)ではどんなことが起きたでしょうか?MVP(Minimum viable product)はどこがまずかったのでしょうか?その答えは「間違ってはいない」、ただそれだけです。私たちにはシンプルさに立ち戻るための方法が必要であり、それを助けてくれるのがYAGNIです。

YAGNIを実践する方法

YAGNIの実践方法をうまく説明しているのは、エクストリームプログラミングの共同提唱者であるRon Jeffriesの次の言葉だと思います。

実装は、それが本当に必要になるまでは行わないこと。「今後必要になる」という予見を理由に実装してはならない。

にもかかわらず、議論が最も白熱するのは「それはいつなのか?」という点です。実際に必要になるよりも前の段階でコードを書き続けるのはオーバーエンジニアリングであり、「予見」と「必要」を混同しています。

この2つを明確に区別するために、将来期間(time horizon)を設けるという方法があります。Kent Beckは、Full Stack Radioでのインタビューでうまい説明を与えています。

ちょっとした実験を行ってみたんです。設計上の将来期間を「6か月」に限定して、そこから先のことを予見しないようにしたらどうなるかと思って。これは自分にとってうまくいったと思います。オーバーエンジニアリングも減りましたし、進捗もはかどりました。心配の種も減りましたし、いろんなことがクリーンになって理解しやすくなりました。将来期間を「3か月」や「1か月」に変えたらどうなったと思います?実験中に期間の上限に達したことはついに一度もありませんでしたね。

このようにして、YAGNIの実践は「将来期間を実験で確かめる」という具体的な作業になります。将来期間を繰り返し短縮することで、私たちがコードを書きすぎないよう制限しやすくなります。理想的には、コードが実際に必要になるまではコードを書かないようになるまで、期間の短縮を繰り返します。これは、私たちがYAGNIの実践について考えているとか、YAGNIを実践したいとか、現在作業中のコードに関連しているからというだけが理由ではありません。私たちは、現在のコードが機能するうえで新しいコードの実装が真に必要になるまで待つのです。

これは私も認めざるを得ませんが、最初のうちはきっと面倒くさい気持ちになるでしょう。コードを書くことを意図的に避けろと命令されたような気持ちになるでしょう。ある意味それは本当です。ここで重要なのは、コードを書きたいと思ったタイミングは、コードを書いてもよいタイミングではないという点です。仮説を立てることで発生する可能性のあるあらゆる問題を、待つことによって防ぐのです。

YAGNIを実践すべきでないとき

YAGNIのメリットに気がついた人は、きっとあらゆる局面でYAGNIを実践しようとするでしょう(他のプログラマーに呪われるかもしれません)。「大いなる力には大いなる責任が伴う」ことを忘れてはいけません。YAGNIは「ノーと言う」ための方法ではなく、不要な複雑さを時が満ちるまで先延ばしにするためのものです。

そして、YAGNIを実践すべきでないときもあります。残念ながら、これを見極めるには経験が必要です。そこで、YAGNIの実践を開始するうえで役に立つシナリオをいくつかご紹介します。

  • 新しいことを学ぶとき: 新しい技術を評価するときは時間を惜しんではいけません。その時間はきっと後で報われます。そして、誤った技術を選択して時間を無駄にするリスクを緩和できます。
  • 将来の必要性に基いて現在の設計を決定するとき: YAGNIを仕事の妨げや怠けの言い訳に使うべきではありません。こういうときは、将来問題を起こさない設計を選び、ただし実装は現在の必要を満たすだけにとどめましょう。こうすることで、YAGNIを損なうことなく手戻りを減らせます。
  • 外部依存性を抽象化するとき: 外部への依存が追加されると、プロジェクトがその分複雑になります。これまでの例と同様、十分時間をかけてこうした依存性を抽象化することで手戻りを回避し、複雑さを低下させることができます。
  • テスト、セキュリティ、スケールアップ、ビジネス上の要求: 残念ながらYAGNIは、テストの作成やセキュアなコードの作成、スケールやビジネス上の要求を却下するフリーパスではありません。

私にとってYAGNIとは何か

私はYAGNIを実践することで自信を得られます。設計上の決定を行うのにふさわしいタイミングは(現在ではなく)未来なので、安心して設計上の決定を先延ばしにできます。コードがシンプルに保たれているので自信を持って方針を転換できますし、コードのリファクタリングや進化も容易になります。私はコード量を少なくすることを心がけています。率直に言えば「コードがない」のがベストのコードなのです。


詳しく知りたい方へ: Twitterで@gonedarkのフォローをお願いします。コーディングの便利なヒントや、さまざまなリソースを参照するリツィートなど、盛りだくさんの情報をお届けいたします。

関連記事

Rubyのクラスメソッドがリファクタリングに抵抗する理由(翻訳)

肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

関連する記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ