25年前にRichard P. Gabriel氏の提唱した“Worse is Better(悪い方がよい)”のコンセプトに従うならば，機能が少ない方がよい製品を生み出せる，ということになる。我々は“Worse is Better”のコンセプトから，アジャイル/リーンによる開発とアーキテクチャを学ぶことができる，とKevlin Henney，Frank Buschmann両氏は言う。
両氏はOOP 2015 conferenceで，“Worse Is Better, for Better or for Worse (よくも悪くも，悪い方がよい)”と題した講演を行う予定だ。講演で両氏は，反復型開発を考える上で，製品あるいはアーキテクチャを中心とした手法を探り，ソフトウェア開発の成功における品質管理，スコープ管理の有用性について議論する。InfoQではOOP 2015の様子について，ライトアップやQ&A，アーティクルなどでお伝えする予定だ。
InfoQは“Worse is Better”のコンセプトについて両氏にインタビューし，ソフトウェア設計にどのように活用するのか，“Good Enough Software(必要十分なソフトウェア)”アプローチとの違いは何か，アジャイルあるいはリーンソフトウェア開発ではどのように適用されるのか，などの疑問を尋ねることにした。
InfoQ: “Worse is Better”というコンセプトの意図について説明して頂けますか？
Kevlin: “Worse is Better”ということばは元々，Richard Gabrielが25年前に定義した造語です。少し誤解されているかも知れませんが，一般的なソフトウェアのよいか悪いか – 不良率，パフォーマンス，クラフトマンシップなど – という考え方で，悪い方がよい，と言っているのではありません。ここで悪い(worse)というのは，ソフトウェア製品が備えるべき機能として，あまり欲張ったビジョンを持たずに，スコープを狭くする，という意味なのです。最小限の機能セットから始めて，適切な実装とパフォーマンスを確保しながら，段階的に機能を開発していくのが“Worse is Better”な製品です。
Frank: Wikipediaの説明が分かりやすいと思います。“Worse is Betterとは，機能の向上が必ずしも品質を向上するのではない，という考え方である。ここで重要なのは，実用性や使いやすさといった面から言うならば，機能の少ない方("worse")が望ましい("better")，という事実だ。機能的な制限があっても使い方のシンプルなソフトウェアは，そうでないものに比べて，ユーザやマーケットによりアピールする場合もあるのだ。”
InfoQ: “Worse is Better”なソフトウェア設計の特徴はどのようなものか，説明して頂けますか？
Frank: 最も重要な機能の最小セットから始めて，実装面でのソフトウェア設計のシンプルさを維持することです。バグがない，動作が速いなど，すべての重要な面において，ソフトウェア設計が常に適切であるように努めます。実装時には，既存の(既製の)ソフトウェアや，ユーザの使い慣れたツールを使用します。
Kevlin: 小さく始める，シンプルさを保つ，バグを許容しない，迅速に開発する，抽象論に迷い込まない，既存ソフトウェアとインフラストラクチャを活用する，といったところでしょうね。
InfoQ: “Good Enough Software”アプローチについては，どのようにお考えですか？ “Worse is Better”とはどう違うのでしょう？
Kevlin: 選択したことばのためでしょうか，“Good Enough Software”アプローチは “Worse is Better”アプローチとよく混同されます。ですがその特徴は，まったく逆といっていいでしょう。“Good Enough Software”の“Good Enough”というのは，製品本来の品質のことを示しています。障害管理やコード品質，パフォーマンスといったものが，重要な品質として優先的に考慮されたり，管理されたりすることはありません。最終的に重要視されるのは，市場投入時期を念頭に置いて決められた開発期限なのです。このようなアプローチは，短期的にはメリットがあるように見えるかも知れませんが，長期的に見れば，経済的な理に適うものではありません。実現された機能よりも，品質上の問題による思いがけないコストの増加や遅延の拡大が，開発の成果を決定することになるからです。
Frank: “Good Enough Software”の目標は市場投入時期です。必要十分な機能と安定性を備え，幅広いユーザを対象とする，そのマーケットセグメントにおける最初の製品が，最大のマーケットシェアを獲得します。設計や実装が品質的に不足していたり，欠陥があったり，あるいはもっとよい競合製品が後になって入手可能になったとしても，その状況が変わることはありません。要するに“Good Enough Software”とは，提供時点の製品品質の高さよりも，市場投入時期や障害管理に価値をおくアプローチなのです。
InfoQ: “Worse is Better”のコンセプトがRichard P. Gabriel氏によって提案されたのは今から25年も前ですが，現在でもそこから学ぶものがあります。それはなぜでしょう？ 実例を示すことは可能でしょうか？
Frank: ソフトウェア開発コミュニティとしての私たちには，今でもシステムをオーバーエンジニアリングする傾向があります。誰も必要としない，あるいはごく少数だけの人が必要とする機能を追求したり，起こりそうもない変化に備えて，行き過ぎた汎用性，柔軟性，多様性を備えようとしたりするのです。このような考え方の結果として生じる，偶有的複雑性(accidental complexity)と技術的負債(technical debt)によって，実装や安定化，マーケットが期待する妥当な価格とリリースのタイムフレームで展開する上で，大きな損失を被るような設計となるのです。“Worse is Better”は私たちに，本質に集中するためのバリューシステム – 実装も使うのもシンプルな，最小限の機能を備えた製品の開発 – を与えてくれます。開発が成功すれば，そこを起点として，ユーザの真のニーズと“現場経験”に基づいて，段階的に進化させることができます。このアプローチは，スマートフォンやタブレットでどこからでも操作可能な，コンシューマ指向のホームオートメーションシステムから，小規模あるいは信頼性の低いITインフラストラクチャを使用する分野の小売業向けオーダシステムまで，数多くのシステムで成功を収めてきました。 私としては，アプリであっても，ある程度は“Worse is Better”のコンセプトが当てはまると思っています。よいアプリは小さくてもパワフルな機能セットを持っています。そのようなアプリは，馴染み深いインフラストラクチャ上で，手軽かつ直感的に使うことができる上に，その動作も高速です。
Kevlin: 現在でも非常に多くのプロジェクトが偶有的複雑性に陥り，不必要あるいは考慮の不十分な機能を背負い，技術的負債や障害に苛まれています。思い込みの汎用性よりもシンプルで高速な実装に注目し，バグを蓄積せずに不寛容であるようにすれば，製品の寿命にも，開発者の生活にも，大きな違いが生じるはずです。
InfoQ: “Worse is Better”のコンセプトが，アジャイル/リーンソフトウェア開発に適用可能だという実例はありますか？
Kevlin: 対象とする問題が閉じたスコープ内で完全に定義されたものでない限り，開発プロセスは計画よりも実証的であることが必要です。この意味からいえば，製品とそのアーキテクチャは，仮説の組み合わせとして扱うことができます。いずれも理解され，検討されることが必要です。仮説を証明できればビルドブロックとなりますし，そうでなければ廃棄されることになります。この考え方は，アジャイル/リーンアプローチの反復型モデルによくマッチしますが，パフォーマンスと実装特性により重点が置かれています。
Frank: 私の考える“Worse is Better”とは，本質的には製品開発を成功させるための価値システムであり，あるいは製品の機能，全体的なデザイン，実装品質といった面から行うべきことを定義した，行動の指針となる原理です。製品がアジャイルあるいはリーン手法で開発されるのか，または他の開発手法なのか，そういったことは問題ではありません。反復型開発や継続的デリバリのようなアジャイルプラクティス，ムダとり(elimination of waste)などのリーンプラクティスは，いずれも“Worse is Better”の概念を支持するものです。ただし，このような考え方は，他の設計価値システム，例えば“Good Enough Software”などにも適用できます。ですから個人的には，このような議論は，実践的というよりも理論的なものだと思います。“Worse is Better”を標榜する開発組織はきっと，“Worse is Better”な製品を実現する方法を見つけるでしょう。