Feature Parity とは？
ソフトウェアシステムのマイグレーションにおいて、新たに開発するシステムに、オリジナルのシステムが持つ機能セットを移植する。こういう方針や行為を、"Feature Parity" と言う。「機能等価性」とでも訳せば良いだろうか。
Feature parity の動機となるユースケースはマイグレーションだけじゃない。デスクトップアプリのモバイル版を開発するような、プラットフォーム間移植でも起こり得る。スタートアップ企業が、先行企業の製品を真似るようなケースでも同様。
しかし、こういった動機による Feature parity への強い要求が、ビジネスやソフトウェアシステム開発プロジェクトをしばしば失敗に陥れる。その大きな要因のひとつが、「機能負債（Feature debt）」だ。
機能負債（Feature Debt）とは何か？
ソフトウェアエンジニアがよく知っている言葉に、「技術的負債（Technical debt）」がある。端的に言うと、「機能開発と引き換えに意識的、あるいは無意識に貶めた、システムの内部品質」のこと。
書籍「『エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング』広木大地著、技術評論社（2018）」でも紹介された、フィリップ・クルーシュテンの四象限で、技術的負債は「非エンジニアには見えないが、システムにとってはネガティブな価値」として定義されている。
ここにもある通り、ローンチしたばかりの新機能は、ソフトウェアシステムを提供する側にとって「ポジティブな価値」として認識されている。しかし、ユーザーやビジネスにとって、実際にローンチされた機能がポジティブな価値として位置付けられているとは限らない。
ユーザーからすると、使わない機能に価値はないし、使いづらい機能は苛立たせる。ビジネスから見ても、収益に貢献しないような機能に投資したくはない。
つまり、ポジティブな価値であったはずの「新機能」が、実際にローンチしてみると、ネガティブな価値である「欠陥」に位置付けられている。これが、機能負債の正体。
Feature parity の問題は、新たに構築するソフトウェアシステムに、もとのソフトウェアシステムが抱えるこのような機能負債を再現してしまう点にある。
特に、レガシーシステムのマイグレーションでは、技術的負債の返却にフォーカスがあてられ、機能面では Feature parity であることを求められる傾向が強いのではないだろうか。本ブログエントリーのタイトルを「機能負債がレガシーシステムのマイグレーションを失敗させる」としたのはこのためである。
"Legacy migration feature parity" と名付けられたこのケースは、ThoughtWorks の Thechnology Radar でもアンテパターンとして、Techniques カテゴリーの Hold にプロットされている。
機能負債の影響はそれほど大きいのか？
Standish Group のレポート（2014）を見ると、ソフトウェアシステムが持つ機能の 80% がほとんど使われない。本当に価値があるのは 20% の機能のみという、パレートの法則のような結果となった。
使われない 80% の機能開発への投資が全て無駄だとは思わないが、この数字は十分にインパクトがある。
※2023/3/28追記：マイクロソフトの調査では、対照実験を実施したアイデアのうち、3分の2は価値がない、あるいは逆に価値を損なわせるという結果になった。また、ソフトウェア産業におけるアイデアの成功率は、対照実験によって科学的に評価した場合、50％以下であるという報告で溢れていると言う。いずれも厳しい数字だ。詳細は、記事『リリースした新機能や改善の多くに価値がないという調査結果が意味すること』にまとめた。
機能負債を引き継がない
機能負債を引き継がないためには、新しいソフトウェアシステムに搭載する機能を、本当に価値のある 20% に絞り込むことになる（もちろん "20%" という数字にこだわる必要はない）。
幸い、機能負債は技術的負債と違い、エンジニアでなくとも見ることができる。ユーザー視点、ビジネス視点も交えて機能を評価し、次のような図にプロットしてみると良い。
ユーザー価値、ビジネス価値が共に低い（D）、あるいはいずれか一方が低い機能（B, C）は、機能負債である可能性が高い。これらは捨てる、あるいは見直す対象として整理できる。
新たな機能負債を積み上げない
搭載すべき機能リストの整理はできた。でもこのリストはあくまでも仮説に過ぎない。実際にローンチしたら、使われないかもしれないし、ビジネスに貢献しないかもしれない。どうなるか、結果は不確実で保証はされない。
だから、検証が必要になる。それぞれの機能を仮説だと考え、実験し、そこで得た学びを機能にフィードバックする。
搭載予定の機能すべてを一括でローンチするのではなく、機能に優先順位を付け、こういった仮説検証を繰り返しながら、機能を少しずつ順に積み上げていく（参考記事『「いかに作らないか」が考え抜かれた機能開発を。』）。
この、アジャイルや MVP（Minimum viable product）的なアプローチが、不確実性をコントロールしやすくし、新たな機能負債の発生を抑えることに繋がる。
最後に
本文で引用した、機能利用状況に関する 2014 年版の Standish Group の調査結果は、2002 年版と大きな違いがない。この点が、実は少し気になっている（2002 年版では Always + Often が 20% で、Sometimes + Rarely + Naver が 80%）。
2002 年当時と比べ、アジャイルも随分浸透した。それが機能負債の減少にも繋がっていると思う。
それにも関わらず、未だに "Hardly Ever" が 50% にものぼる理由は何だろうか。2014 年のレポートに書かれている数字が、2002 年の調査結果なのかもしれないが。
※2023/3/28追記：この疑問について調べたところ、2014年版の数字は、2002年版と異なる調査によるものだった。詳細は記事『リリースした新機能や改善の多くに価値がないという調査結果が意味すること』を参照。
