その要件定義、今の会社を「標本」にしていませんか？
システム刷新が始まると、現場へのヒアリングが行われます。
- 誰が入力するのか
- どこで承認するのか
- どんな帳票が必要なのか
- 例外処理は何か
現在の業務を丁寧に聞き取り、一つずつ要件として整理していく。
そして、新しいシステムで現在の業務をきれいに再現できれば、「よくできたシステム」が完成します。
しかし、少し見方を変えると、別の評価もできます。
現在の会社を、きわめて精密にシステムの中へ保存した。
ということです。
会社は壁紙を替えるつもりだった
システムは5年、10年と使われます。その間に会社は変わります。
- 事業部を統合する
- 商品体系を変える
- 代理店販売から直販へ進出する
- 承認ルートを簡素化する
- 新しい事業を始める
会社としては、少し模様替えをするくらいのつもりかもしれません。
ところがシステム側から、
「そこを変えると影響範囲が大きいです」
「データ構造から見直す必要があります」
と言われる。
壁紙を替えるつもりだったのに、柱まで工事することになる。
なぜ、こんなことが起きるのでしょうか。
25年以上前にも、同じ話があった
2000年頃、フューチャーシステムコンサルティングの金丸恭文氏は、中小企業経営者向けの講演で、システムを「家」に例えています。
重要なのは、画面や帳票といった目に見える部分だけではなく、その下にある基礎や骨組み、つまり設計構造である。設計構造が悪ければ、画面上の小さな変更であっても、それが「柱」と一体になっているため、柱そのものを直すことになる。
さらに金丸氏は、「顧客の定義も商品の定義も変わるのだから、内装や外装をいつでも変えられる構造を持つべきだ」と論じています。
ここが興味深いところです。
将来の商品や顧客を正確に予測して、それに備えたシステムを作れ、と言っているわけではありません。
顧客も変わる。商品も変わる。組織も変わる。
ならば、現在の顧客、商品、組織を精密に固定するのではなく、それらが変わっても受け止められる「構造」を先に持つ。
家でいえば、将来どんな壁紙を選ぶかまで決める必要はない。しかし、壁紙を替えるたびに柱を削らなくて済む構造にはしておく。
四半世紀以上前の話ですが、現在でも十分に通用する考え方です。
その後、技術は大きく変わりました。クラウドになり、SaaSが普及し、APIでつながり、いまではAIまで使えるようになった。
それでも、壁紙を替えようとすると柱の工事が始まる。
なぜ、同じ問題が残っているのでしょうか。
誰も「今の会社を固定しよう」とは思っていない
理由の一つは、プロジェクトそのものが、現在の業務をシステムへ埋め込む方向に流れやすいからです。
現場は当然、「今できていることができなくなると困る」と考えます。ベンダーも、将来起こるかもしれない変化を際限なく開発範囲へ盛り込むわけにはいきません。プロジェクトには予算と期限もあります。
そして要件定義では、「将来こうなるかもしれない」という話よりも、「現在こうしている」という事実の方が、はるかに仕様へ落とし込みやすい。
誰かが間違っているわけではありません。
それでも結果として、「今どうしているか」は要件になりやすく、「なぜそうしているか」「将来も必要なのか」は要件になりにくい。
こうして現在の会社が、少しずつシステムの中に固定されていきます。
現行業務は、まだ「要件」ではない
ここに、要件定義で考えておきたいことがあります。
たとえば現場へのヒアリングで、
「100万円以上の発注は部長が承認しています」
と聞いたとします。
これをそのまま要件にすれば、
100万円以上 → 部長承認
となります。
しかし、この時点で分かっているのは、あくまで「現在そうしている」ということです。
- なぜ100万円なのか
- なぜ部長なのか
- 何を統制するための承認なのか
- 組織改編で部長という役職がなくなったらどうするのか
そこまで考えてみると、本当に必要なのは、
「一定の条件を超える取引について、所定の決裁権限を持つ者が承認する」
ということかもしれません。
そうであれば、「部長」という現在の組織図をシステムに固定する必要はありません。
つまり、
現状を知ることと、要件を決めることの間には、本来もう一つ仕事がある。
現状を聞き、その背景や目的を考え、何を残すべきかを判断する。
ところが、この工程を飛ばして、
現状 → システム要件
とショートカットすると、現在の会社がそのままシステムの中へ入っていきます。
それは「柱」なのか、「壁紙」なのか
同じことは、さまざまな場面で起こります。
- 商品コードの一部が現在の事業部を表している
- A社向けだけ昔から特殊な処理がある
- この部署だけ別のステータスを使っている
どれも現在の業務としては事実でしょう。
しかし、現在そうなっていることと、次のシステムでもそうすべきことは別です。
そこで考えたいのが、先ほどの「柱と壁紙」です。
その要件は、システムの柱として組み込むべきものなのか。それとも、組織や商品、取引形態が変われば一緒に変えられる壁紙として扱うべきものなのか。
これは「何が将来変わるかを当てる」という話ではありません。
むしろ逆です。
何が変わるか分からないからこそ、変わる可能性のあるものと、それを受け止める構造を分けて考える。
顧客が変わっても、商品が変わっても、組織が変わっても、全部を作り直さなくて済む。
変わるものを精密に作り込む前に、変化を受け止められる構造を考える。
ここに、システム設計の重要な役割があります。
何でも変えられるようにすればいい、わけでもない
では、あらゆる要件を変更可能にしておけばよいのでしょうか。
それも違います。
将来変わるかもしれないからと、何でも設定できるようにすれば、システムは複雑になります。開発費も増え、運用も難しくなる。設定項目だらけになれば、かえって事故の原因にもなります。
未来をすべて予測して、あらゆる可能性に備えることなどできません。
だから必要なのは、未来を当てることではなく、何を固定し、何を固定しないかを判断することです。
「残す」「捨てる」「変えられるようにする」
現行業務から一つの要件候補が出てきたとき、少なくとも三つの選択肢があります。
残すのか、捨てるのか、変えられるようにして残すのか。
- 残す：自社の競争力や業務上の必然性につながるものなら、独自の仕組みとして残す意味があるでしょう。
- 捨てる：過去の経緯で続いているだけの業務なら、新しいシステムへ持ち込まず、パッケージやSaaSの標準に業務側を合わせる選択もあります。
- 変えられるようにする：必要な業務ではあるものの、組織や制度、商品、取引形態によって変わる可能性が高いのであれば、将来変更できる形で持つことを考える。
重要なのは、現行業務を見つけた瞬間に、それを「要件」として確定しないことです。
「今そうしている」から「次もそうする」までの間に、判断を入れる。
そして、変えられるようにしておくと判断したものについては、個別の将来像を予測するのではなく、変化を受け止められる構造を考える。
それだけでも、要件定義はかなり変わります。
そのIT投資は、未来に使われているか
金丸氏の講演には、もう一つ興味深い指摘があります。
設計構造の悪いシステムでは、追加投資をしても、その大部分が既存システムの調査や過去との整合を取るための修正に使われ、実際の変化に使えるお金が少なくなってしまう、という話です。
これは現在でも珍しい話ではありません。
新しいことを始めるために予算を取ったのに、既存プログラムを調べる。影響範囲を確認する。古い仕様との整合を取る。別の機能が壊れないように修正する。
投資しているはずなのに、かなりのお金が「過去との辻褄合わせ」に消えていく。
壁紙を一枚替えるたびに柱の補修が必要な家なら、模様替えそのものをためらうようになります。
システムも同じです。
改修に時間とお金がかかる状態が続けば、やがて「システムの都合」が、事業を変えるかどうかの判断にまで影響し始めます。
要件定義とは、「現在」を書き写す仕事ではない
新しいシステムを考えるとき、「今、どうやっていますか？」は重要な質問です。
ただし、それは出発点です。
- なぜそうしているのか
- それは今後も必要なのか
- 組織や商品が変わっても残るのか
- そして、これはシステムに固定してよいものなのか
そこまで問い直して、初めて次のシステムの形が見えてきます。
要件定義とは、現在の会社を精巧に書き写す仕事ではありません。
現在の業務を見ながら、「残すのか、捨てるのか、変えられるようにしておくのか」を判断する仕事でもあります。
その判断をせず、現行業務を忠実に実装すれば、完成した瞬間は100点かもしれません。
ただしそれは、今日の会社をきれいに保存した「標本」なのかもしれません。
会社は、システムが完成した翌日からも変わり続けます。
顧客も変わる。商品も変わる。組織も変わる。
だから、将来の姿をすべて予測して作る必要はありません。
変わることを受け止められる「構造」を先に考える。
「今どうしているか」の次に、「何を固定してはいけないか」を問う。そして、その変化を受け止めるために、何を構造として持つべきかを考える。
そこから、要件定義は少し変わるのではないでしょうか。
現行業務を、そのまま「要件」にしていませんか？
システム刷新では、現状を正確に把握するだけでなく、
「何を残すのか」「何を捨てるのか」「何を変えられるようにするのか」を判断することが重要です。
オーシャン・アンド・パートナーズでは、発注側の立場から、業務整理・要件整理、RFP作成、ベンダー選定、プロジェクト推進まで支援しています。
次のシステムに何を持ち込み、何を持ち込まないか。
要件を固める前の段階からご相談ください。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
