鶴の多い企業は要注意

「すいません、鶴の一声で決まっちゃいまして……」は、現場でよく聞くフレーズのひとつ。

要件定義フィックスまでの道のり

一般的なシステム開発では、要件定義フェーズが確定（フィックス）して初めて、正式な見積もりが出て開発フェーズがスタートします。

ここから先の仕様変更や機能追加は、原則として追加費用が発生します。タイミングによっては対応が次期開発に持ち越されることもあります。これは業界的に広く通用するルールです。

現場ユーザーからの「やっぱりこういう機能も欲しいです」は、「承りました。次期開発で対応しましょう」で着地できることが多いです。みんなそのルールを知っているので、折り合いがつきます。

しかし、鶴は違います。

役員や統括部長といった職位の高い人が「この機能を搭載しろ」と言い出すと、開発フェーズも稟議の有無も、もはや関係ありません。「上が言ってるんだから」という力学が、あらゆるプロセスを飛び越えてきます。

こうなると、担当者がベンダーに連絡します。

「すいません……鶴の一声で決まっちゃいまして」

電話口のベンダー担当者は、たぶんため息をついています。でも、断れないのはお互いわかっています。

対応にかかる費用をどうするか、という問題も出てきます。

仕様変更の追加費用を稟議にかけると、「なんでこんな費用が発生するの？」と言い出す人が出てくることもあります。その費用が発生した原因は自社の偉い人の一声なのですが、そのあたりが混乱しています。

稟議が通ればまだよいほうです。揉めている間にも、スケジュールはじわじわと圧迫されていきます。

要件定義のフィックスには、意味があります。 開発フェーズ中の仕様変更がどれだけコストと混乱を生むか、事前に関係者全員が認識を合わせておくことが、鶴の一声リスクを減らす第一歩になります。それが難しい組織構造であれば、最初から余裕のあるスケジュールと予算を見込んでおくことをおすすめします。