■ 積荷や装備を増やすと自重で船が沈むのは当然のこと
製造業の場合は自社製品の企画・設計の段階で、サービス業の場合は自社サービスメニュー開発において、経営コンサルタントの場合は基本構想や要件定義の場において、度重なる顧客や上司、さらには同僚・他部署からの要望までも、目の前の設計・開発すべき対象物に新機能、追加機能として盛り込まざるを得ないケースが多々あると思います。
そういう時に思い出してほしいのが、1628年に処女航海に出たスウェーデン海軍所属のヴァ―サ号の逸話。出航後、１マイルに満たない航行で海の藻屑として沈没してしまいました。
●引用元：ヴァーサ (戦列艦)（WiKi）
もともと砲甲板は一層の予定であったが、建造途中で二層に増やされるなど無理な構造で、さらに重武装だったため極端にトップヘビーな艦になってしまいました。基本設計が終わった後から、大砲や船体を飾る彫刻などが後から追加され、安定性を著しく欠くと共に、重量オーバー状態だったのです。
「1628年の処女航海でストックホルム港に沈没した王室の軍艦、ヴァーサ号が展示されています。ヴァーサ号は、沈没から333年後に、奇跡的に極めてよい状態で引き上げられました。北欧で最多の来場者を誇る人気の博物館です。
博物館を貸しきったパーティーなどもとても好評です。
ストックホルムに来たなら必ず訪れたいスポットです！」
●出典：ヴァーサ号博物館 － スウェーデン大使館公認 観光情報サイト
その姿をその目で収めたい人は、ストックホルムで直接目にすることができます。
■ 当たり前のことが軽視される現場の怪
フィーチャー・クリープ（機能の増殖）は、製品やサービスメニュー開発、各種プロジェクトの企画段階で、コスト超過やスケジュール遅延をもたらす、プロジェクトマネージャーの頭を悩ます大きな課題のひとつです。
フィーチャー・クリープが容易に発生しやすくなるのに、2つの主要な理由が考えられます。
（１）基本構造が逆にしっかりしているがために、簡単に有れば便利と新機能を追加しやすい
（２）プロジェクト関連のステークホルダーを満足させるために、それ以外の解決策がない
私は、数多くのプロジェクト経験の中から、出来が良すぎる基本デザインのものと、ステークホルダーをきちんと管理できていないプロジェクトの両方がこうした問題を引き起こす遠因になっていることを身近に感じており、その兆候が表れ始めたらすぐさまそういう意見の火消しに努めるようにしています。
つまり、出来の良すぎるアイデアや基本構想も、アンコトローラブルな意見の双方が成功するプロジェクトの敵になり得るのです。そして、得てして、前者はうまくいっているプロジェクト、後者はあまりうまくいっていないプロジェクトで起こりがちであることも知っています。
プロジェクトの繁忙さにかまけて、当事者たちは、この忍び寄る「フィーチャー・クリープ（Feature Creep）」の発生をつい許してしまいがちになります。
■ フィーチャー・クリープが発生するのは人の性によるところ大
では、どうしてこうした「フィーチャー・クリープ」が発生し、場合によっては、処女航海に出たばかりの戦艦が沈んでしまう悲劇を引き起こしてしまうのでしょうか？
こうした人々の要望を増長させる一番の要因は、「モア・イズ・ベター（あればあるほど良い）」という考え方が当たり前となっているからです。あなたも、とあるIT機器やWebサイト、ガジェットなどで、「このボタンのそばに次のアクションのトリガーとなるボタンがあれば便利なのに」「右クリックで説明書きがポップアップで表示されればいいのに」「もっと多くの通信プロトコルでアクセスできたらいいのに」という素朴な要望をひとつやふたつ、頭に思い描きながら、ユーザとしていろんな製品やサービスを日々使用しているものと推察します。
しかし、そうした機能をどんどん、基本設計を無視したり、基本設計を無理に変更して追加していったらどうなるでしょうか？ シンプルな構造だからこそわかりやすかった操作ストリームも分断され、多くの分岐で捜査に迷うことになったり、多重の操作が必要以上に増えたり、ということが頻発する恐れがあるのです。
設計開発の段階で我々が気を付けなければいけないのが、その仕様は、
（１）一体、誰のためのものか？
（２）本当に追加・更新されなければ目的が達成できないのか？
（３）その目的に合理性は本当になるのか？
という、最低でもこの3つの問いにパーフェクトに応えられていないと、検討の俎上に載せるのも危なかっしいものであるとここに断言します。安易な機能追加は、もはや伝説の域に達しているガラパゴス携帯（いわゆるガラケー）だけでもう沢山です。(^^;)
では、そうならないために、我々が留意すべきポイントとはなんでしょうか。
（１）どんな機能も、必ずターゲットとする顧客（使用者・ユーザ）のニーズにだけフォーカスする
（２）開発者や提供者の簡便さをそのままダイレクトに仕様に盛り込まない
（３）ステークホルダーの声は参考程度に押しとどめ、仕様決定の意思決定プロセスを明確化しておく
これら、ちょっとした配慮により、あなたの各種プロジェクトは、「フィーチャー・クリープ」の魔の手から逃れることができるでしょう。
もし、あなたのプロジェクトで、誰かが「新機能追加が必要だ」と言い出したら、迷わず、「フィーチャー・クリーパー、ここに発見、要注意！」と大声で叫ぶことにしましょう。(^^;)
コメント