フィーチャー・クリープ
feature creep

プロダクト開発において、必要以上に機能を追加したり性能を向上させてしまうこと。

プロダクトを開発する際に、顧客からの度重なる仕様変更要求に対応したり、機能追加や性能向上等のエンハンス対応が積み重なることをフィーチャー・クリープという。

フィーチャー・クリープの直訳は「機能お化け」、つまり「機能だらけ」という意味である。フィーチャー・クリープが生じた結果、必要以上の機能数がプロダクトに組み込まれて、複雑な仕様になってしまう。

フィーチャー・クリープは、プロダクトを開発する際に大きな障害となり、生じるリスクは下記2点があげられる。

  1. 改修コストの肥大化
  2. ユーザビリティの低下

1.改修コストの肥大化

フィーチャー・クリープは、改修コストの肥大化を引き起こす。要件や影響範囲を綿密に把握しないまま、急な仕様変更や追加開発を対応していくと、プログラムがツギハギの状態になり保守性が低下する。保守性が低下したプログラムに対して機能追加や性能の改善を行う場合、必要以上に大規模な工数とコストが必要になる。

2.ユーザビリティの低下

フィーチャー・クリープは、プロダクトのユーザビリティを低下させる。1つのプロダクトに多くの機能を用意して、どのようなニーズにも対応しようとフレキシビリティ(柔軟性)を高めると、ユーザビリティが低下してしまう。(フレキシビリティとユーザビリティの二律背反性

機能がたくさんあったとしても、それぞれの機能の使い方が理解できなければ、ユーザーは不便に感じてしまう。

マイクロソフトWordで全ての機能を表示させた状態。機能が多くなり過ぎている。(引用元:Feature Creep Rant: Making the Right Thing

「機能が多いほど売上が伸びる」という誤解

ステークホルダーやプロジェクトメンバーが、1つのプロダクトで多くの機能を提供することによって、顧客の満足度を高め、売上の向上につながると「誤解」しているため、フィーチャー・クリープが発生してしまう。

明確なゴール設定がフィーチャー・クリープを抑制する

フィーチャー・クリープを抑制するには、プロダクトのゴールを明確に設定することが大切だ。

会計サービスを提供するIntuitインテュイット社の共同創業者scott cookスコット・クック氏は、プロダクトのゴールを “ユーザーが抱える面倒な会計作業を減らすこと” に限定した。

プロダクトのゴールを明確にした結果、インテュイット社が開発した会計システムの機能数は、競合システムに比べて半分の数になった。一方、システムの値段は競合システムの2倍に設定したにも関わらず、アメリカの会計システム市場でトップシェアを獲得した。

関連用語

参考文献

この記事を書いた人:藤原 脩平

現在、システムエンジニアとして自社サービスの企画/開発を行なっています。
ユーザーファーストなサービス開発を心がけたいという思いから、UX DAYS TOKYOのスタッフとして活動を始めました。

最近はリサーチスキルを伸ばすために統計学を勉強している。