デジタル・DXの戦略・実装情報サイト
1．失敗しないシステム導入に「超上流工程」が重要な理由
昨今、急激な環境変化に対応するためにDXが急務であるとされる中、「DXを冠とした社長直結のプロジェクトを発足したが、うまく推進しない。」「業務改善プロジェクトチームがシステムを導入したが、望んだ結果にならない。」「社内基幹システムの老朽化により業務効率が上がらない。しかしどう入替をしたらよいのかわからない。」「そもそも何から始めたらよいのかわからない」など、経営者やプロジェクトリーダーからお悩みを伺います。
特に、DXを実現するために足かせとなっているのが老朽化した既存ITシステム（レガシーシステム）であり、それらが新システムへの刷新の課題となっています。
それではなぜ、システム導入がうまくいかない、プロジェクトが推進しない、望んだ結果にならないということが起きるのでしょうか。この問題の多くは、「デジタル技術を活用することで企業のあるべき姿」や、「システム導入により業務のあるべき姿」「システム化のための明確な工数や期間、費用」といった内容が社内全体で十分に議論されていないことにあります。プロジェクトメンバーや現場スタッフに実務を任すことに問題はありませんが、自社が目指す方向性は経営層も自分事と捉えて議論の場に参加していく必要があります。
DX白書2023ではITに見識がある役員の割合について、3割以上いると回答した企業は日本が27.8％なのに対し、米国は60.9％と2倍以上の差があり、 日本の経営層のITに対する理解が不十分であるということがわかります。（※図1参照）
デジタル技術やシステムはあくまで手段であり、現状認識を十分に行った上でシステム導入の目的を明確にしないと望む結果となりません。そこで本コラムでは失敗しないシステム導入への重要工程である「超上流工程」について話していきたいと思います。
2．超上流工程とは
「超上流工程」とは、IPA（情報処理推進機構）のSEC（ソフトウェア・エンジニアリング・センター）が定義した、システム設計などの上流工程よりもさらに上流の工程を指します。
具体的にはシステムやソフトウェアの開発プロセスでよく表記されるV字モデルの「システム化の方向性」から「システム化計画」「要件定義」「設計」「テスト」「運用」「運用改善・保守」（※図2参照）のプロセス全体の最上流にある「システム化の方向性」「システム化計画」「要件定義」のことです。
「超上流工程」はそもそもの目的や計画を明確にするステップであり、プロジェクト成功の可否を左右すると言える重要な業務です。自社がシステム導入により目指す姿の議論、またシステム化計画の決定については経営層も関わることが必要です。
※タナベコンサルティングでは「システム化の方向性」「システム化計画」を総称して「企画」 と表現しています。
3．超上流工程の3つのプロセス
では、超上流工程の3つのプロセスである「システム化の方向性」「システム化計画」「要件定義」では具体的にどのようなことを行うのかを説明します。
（1）システム化の方向性
まずは、経営方針や経営層の思いを可視化していきます。たとえば、会計システム刷新の際にはリアルタイムで経営数字を見える化し、迅速な経営判断が行える体制を整備したいという方針をよく聞きます。また、業務効率化により営業担当が顧客と向き合う時間を創出して売上を上げたい、という経営層の想いも伺います。漠然としたものであっても、まずは声に出し共有することが重要です。そこからシステム導入によって経営層が目指す自社のあるべき姿を可視化します。顧客に寄り添うことを理念に掲げているのであれば、寄り添い方や時間の創出をシステム導入により実現させていきたいというように、経営理念やビジョンなどに紐づけて方向性を可視化します。
次に、IT部門の責任者や現行システムを運用している担当者へ、現在の業務フローや抱えている課題をヒアリングします。できるだけ多くの課題や改善のアイデアなどを聞き出すことが重要です。このとき改善のアイデアをお持ちの人材がいたら、後のプロジェクトメンバーの候補としておくとよいでしょう。ヒアリングが完了したら、現在のシステムの全体構成や業務フローを完成させ、経営層の目指すべき姿とすり合わせを行い、システム導入の大まかな方向性を決定します。
ここで弊社がご支援した製造業のIT化構想の事例をご紹介します。経営層との最初のセッションでは、システム連携が不十分であり、一気通貫で管理できるシステムを望まれていました。具体的には、販売管理と生産・出荷管理のデータが未連携で、手作業で処理されているため、過去の実績が不明であり営業に活かすことができない、というものでした。しかし、セッションを重ねていくことで、実は「顧客が自社の商品履歴や工事内容をいつでも確認し、必要なときに注文ができるようコミュニケーションがとれること」がIT化構想の目的であることがわかりました。単純なシステム連携による情報共有だけでなく、システム導入で連携したデータを顧客に見せ、提案型の営業スタイルから受注型の営業スタイルへと変革することが真の経営層の望む自社のあるべき姿でした。
このように、システム化の方向性を丁寧に議論することで、経営層と現場とのギャップを埋めることができますし、業務効率化という漠然とした目的ではなく、より具体的な方向性が見えてきます。
（2）システム化計画
システム化の方向性の検討時に整理した課題と業務フローをもとに、業務のあるべき姿を決定していきます。課題については、粒度の違いやアナログで解決できる内容もありますのでスコープには注意が必要です。さらに粒度についてはシステムの使いづらさなど目先の改善だけにスコープしてしまい、根本的な改善につながらないことがあります。
申請承認作業を効率化したいという課題をもつ企業がありました。紙を電子化する、承認フローを明確にするといった解決方法をもとにあるべき姿を決定しました。その後、システムを導入しましたが、想定した削減効果は得られませんでした。
再調査した結果、そもそもの課題が申請自体の多さであり承認者の確認作業が多いことでした。紙での申請であることが問題ととらえ、その上位である申請の多さを見落としていたことが原因であり、システム導入だけでは解決できなかったという事例です。
もうひとつ、システム化について注意が必要なのが、現業務をそのままあるべき姿と捉えてシステムに反映することです。古いシステムからの入替であれば、一定の効果はあるかもしれませんが、根本的な業務効率化に繋がらない場合があります。そこでシステム導入のアプローチである「Fit to Standard」と「Fit＆Gap」をご紹介します。（表1参照）
簡単に説明すると、「Fit to Standard」は業界のベストプラクティスで設計されたパッケージシステムを導入し、自社の業務を合わせていくというものです。一方「Fit＆Gap」は自社固有の業務に合わせてシステムに機能追加していく方法です。
自社の業務が同業態の他社と大きく違い、固有である場合はシステム開発が必要となり、「Fit＆Gap」で進めるほうが良いです。ただし、開発期間が長くかかること、ほしいシステム機能をベンダーに正確に伝えなくてはならないこと、保守や改善のために専任スタッフや開発ベンダーの保守料がかかるといったデメリットがあります。メリットとしては、今までの運用と変わらないため業務プロセス変革にかかる時間がないこと、特別な対応もシステムで可能であり、現場スタッフの抵抗感が少ないことです。
しかし、現在では「Fit to Standard」が主流となっています。その理由としては、短期間かつ低コストであること、バージョンアップに合わせて常に最新の機能を使うことができる点が挙げられます。環境変化が激しい時代において、システム開発から本格稼働までに何年も費やすことで社会情勢や経済状況が変わってしまい、システムが陳腐化してしまう可能性があるため、主流となっています。デメリットとしては、現場スタッフを説得して業務を合わせるということが求められ、業務の改革に時間を要することです。
システムのあるべき全体構想とそれに伴う業務のあるべき姿が決まったら、次は優先順位を決定していきます。最優先とすべきものはまず期限が決まっているもの。例えば、法令にかかるものは期限厳守となります。特に、期限ギリギリでのベンダー依頼はリスクが高いので、できるだけ時間に余裕を持ちすぐに着手しましょう。次に、重要かつ時間がかかるものです。期待される効果が少ない場合は後回しにすることも検討しますが、時間がかかるものほど早くに着手をしないと、のちに別システムへの影響が発生することもあります。また、短期で成果を生み出しプロジェクトメンバーの小さな成功体験を積み重ね、推進力を高める方法もありますが、バランスを見て決定していきます。
優先順位を決めたら、ロードマップに落とし込みます。その際に、プロジェクトメンバーや業務分担を明確にしていきます。メンバーとしてIT知識が深いことも必要ですが、知識がなくても問題意識を持ち、常に解決策を考えているような人材や、周囲を巻き込むスキルをもつ人材などバランスよく配置し、部門ごとに選抜するほうが効率は上がります。図3は実際に、弊社でも使用しているロードマップとなります。メンバーの推進体制もロードマップに組み込み、目的やゴールの共有など必要なことも落とし込むことでプロジェクトの士気を高めます。
（3）要件定義
「システム化計画」にてロードマップを作成し、計画を立てた次は「要件定義」です。
要件定義とは、システム化計画やベンダーに提出する提案依頼書（RFP）に記載した要求事項からさらに詳細な機能やデータの流れなどを明確にする業務です。要件定義には「業務要件」「機能要件」「非機能要件」があります。各要件の具体的な内容は下記表を参考にしてください。
要件定義はベンダーへ情報を伝える大事な仕事です。「5W1H」を意識して作ることが重要です。この工程については、発注側であるわが社の一方的な要件だけで作成せずに、ベンダーと丁寧にすり合わせをして創り上げます。IPA－SEC出典の「超上流から攻めるIT化の原理原則17ヶ条」の原理原則1条「ユーザとベンダの想いは相反する」とあるように、相互の責任、義務、想いを知り、役割分担の明確化とプロジェクトの積極的に関わることが必要です。（図4参照）
ユーザ企業・ベンダ企業の相反する想いより引用 P8
4．超上流工程で取り組む3つのポイント
超上流工程とは何か、具体的な3つのプロセスをお伝えしましたが、最後に取り組む際のポイントについて整理します。
ポイント1
経営層が丸投げせず自分事として捉えること、経営理念やビジョンと紐づけて戦略を練ることです。全体像を見ないままシステムの入替や導入を行うことで、かえって非効率になる場合があります。また、経営層と現場とのギャップが埋まらないまま進むことで、開発のやり直しなど時間や費用をムダにする可能性もあります。
「システム導入による自社のあるべき姿」をえがき、会社全体が同じベクトルを向くように言語化していくことが大切です。
ポイント2
現状認識を泥臭く行い、真の課題を見つけ出すこと。システムの複雑化や属人化でブラックボックス化した情報を紐解き、情報を共有することで運用面における課題を可視化していくことが重要です。この工程を疎かにすると、システムの要件定義の際に求めている機能が不十分に伝わったり、業務担当者の納得感を得られないままシステム改修となり運用面に悪影響を与えるケースがあります。多くの時間を割くことになりますので、ITコンサルティングなどをうまく利用することをお薦めします。
ポイント3
プロジェクト型で進める。システムの単純な入替ではなく業務フローの見直しといった大きな変革が必要となることが多いです。そうすると、実際に運用する業務担当者への負荷が大きくなります。自社のあるべき姿、業務のあるべき姿に向けたステップであることを自部門へ説明し、前向きに働きかけをして全社一丸となって進めていきましょう。そのためにも部門を超えたメンバーとも目線を合わせ、課題意識・目的意識を共有し推進していくことはもちろん、経営層からの発信も重要です。
下記の図5はDXに向けた具体的なステップの図です。IT化構想で重要とされる超上流工程はDXにおいても必要なステップとなります。上記のポイントを押さえ、次のステップであるデジタル化・IT化による業務効率化・省人化を実現、必要な情報を効率化に可視化することによるマネジメントへの活用へとつなげ、DXへの基盤としてください。
