Case
現場で起きたこと
変わったのは、仕組みだけでは
ありませんでした。
私たちの支援は、特定の課題を解決して終わるものではありません。長期にわたり、場面場面で様々な施策に関わるため、一つの事例として切り取ること自体が難しい側面があります。
ここでは、支援の中で実際にあった場面の一部をご紹介します。劇的な数字の変化ではなく、組織と人が少しずつ変わっていったプロセスをお伝えできればと思います。
なお、守秘義務の関係から、業種・規模・固有名詞などは匿名・一般化して掲載しています。
システム・ツール導入の落とし穴
事例A
要件定義は進んでいたが、誰も使った後の姿が見えていなかった
システムは動くのに、誰も使い方が分からなかった
背景
インフラ系企業の設備管理部門で、複数種類のデータを統合管理するシステムの構築プロジェクト。設備や保全、設計、調達など複数の業務部署が関わる大規模システム導入案件で、ベンダー主導で要件定義が進められていた。
何が起きていたか
システムベンダーのPMに事前に確認したところ、業務フローは作成したと言っていたが、見せてもらうとそれは業務フローではなく、システムフローに関わるユーザーが記されているもので、システム視点であって業務視点ではなかった。参加しているユーザーは、業務視点での繋がりが分からないまま要件定義に臨んでいた。各部署がシステム導入後にどう連携して動くのか、業務運用ルールも決まっていなかった。プロジェクトメンバー自身も「このシステムを入れると、現場はどう変わるのか」が見えていない状態で、システムを導入する作業だけが進んでいた。
弊社の関わり方
要件定義の終盤で参画。まずシステムの機能を業務の流れにつなぎ直すことから始めた。各部署がこのシステムを使って何をするのか、どう連携するのかを「業務全体図」として整理し、それをベースに各部署の運用ルールを定めた。業務全体図を示したとき、ユーザー部門の担当者から「ようやく自分たちの仕事が見えた」という声が上がった。それまでは、靄がかかったような状態で分かった気になっていたのだという。
本質的な
問題
ベンダーが担うのはシステムの仕様設計まで。それを現場の業務につなぐのは、別の仕事として誰かが担う必要がある。
要件定義の場に「業務視点を持つ人」がいなければ、業務設計は生まれない。
事例B
データはあった。何をすればよいかが見えていなかった
戦略が定まらないまま、システム化が始まっていた
背景
複数事業（運輸・旅行・観光・娯楽など）を持つ企業で、AIを活用した顧客管理システムの構築プロジェクト。各事業で顧客データを保有しており、「横断的に有効活用したい」という要望があった。複数のベンダーが参画していた。
何が起きていたか
「顧客データを活用したい」という要望は抽象的なまま、複数のベンダーに具体的な提案を求めていたが、なかなか出てこなかった。背景には「よい顧客とは」という定義が整理されていないことがあった。会社全体として優良な顧客と、各事業にとって優良な顧客は必ずしも一致しない。その定義があいまいなまま、システム導入の視点で要件定義を進めようとしていたため、何を決めるべきかが定まらずプロジェクトが止まっていた。
弊社の関わり方
「この会社にとってよい顧客とは何か」という問いを事業ごとに整理し直すことから始めた。各事業でどんなターゲットに対してどんな施策を取ることで目指す収益構造を作るか、事業別にモデルを作成した。その上で、横断的なデータ活用の方針を定め、要件定義を前に進めた。
本質的な
問題
ベンダーが提案できなかったのは、システムの能力の問題ではなかった。「どんな顧客に何をしたいか」というビジネス戦略が未定義のまま、システムの要件を決めようとしていたことが根本原因だった。そもそもシステムベンダーの仕事は、事業戦略を定義することではない。「よい顧客とは誰か」という問いは事業側が答えるべきものだが、その認識が共有されていなかった。複数のベンダーが参画していても、誰もその問いを立てようとしなかった——それ自体が、この種のプロジェクトの典型的な構造問題である。
事例C
高度なBIツールが、使われていなかった
誰のためのツールか、誰も定義していなかった
背景
別の支援案件に取り組む中で、担当者から「大手コンサルティング会社が構築したBIツールの利用率が低い」という悩みを聞いた。スライサーやドリルダウンの機能が盛り込まれ、収益構造の可視化まで実現した技術的な完成度の高いツールだったが、使われていなかった。外部コンサルタントとしてロールモデルを提案したところ手応えがあり、本格的な支援に発展した。
何が起きていたか
レポートが高度すぎて、誰向けのものかが曖昧だった。「どんな立場の人が、何のために使うのか」が設計されておらず、ユーザー数が伸び悩んでいた。
弊社の関わり方
役割に応じた説明責任を定義した。役員から現場まで、同じデータを使って何が起きているかを説明するロールモデルを設計し、各会議体で誰がどんな説明をするかというルールを整備した。経営トップから現場まで統一したデータベースのデータを用いることで、問題の事象と原因の解明、対応策の立案がやりやすくなった。
結果として、経営会議の資料作成にそれまで3日かかっていたものが半日で済むようになった。BIツールの利用率も20％から70％まで上昇した。
本質的な
問題
「高度なツールを作れば使われる」という思い込みがあった。誰が何のために使うかという業務設計と役割定義が抜けていると、どれだけ優れたツールも現場に根付かない。
仕組み化の欠如
事例D
展開のやり方が人によってバラバラだった
担当者が変わると止まる、という状態だった
背景
子会社へのERP統一化を推進している企業から、標準化プロジェクトとして依頼を受けた。ERPのリプレースを繰り返す中で、手順が属人化しており、一部はブラックボックス状態になっていた。展開を担当する複数のメンバーが同じ手順を別々の方法で進めていたものもあった。
何が起きていたか
担当者ごとに展開の進め方が異なり、品質にムラがあった。「できる人がやる」という状態が続いており、特定の担当者が抜けると展開が止まるリスクがあった。
弊社の関わり方
各担当者にヒアリングし、属人的な業務を可能な限り手順としてモデル化した。標準化・文書化によって、役割を持った10名規模のチームが共通の全体像を持って動けるようになった。新たにメンバーが加わる際も、自分の前後の工程が見えることで「自分が何に注力すればよいか」がわかりやすくなったという声が多く聞かれた。
本質的な
問題
個人のスキルと経験に依存した運用は、組織として脆弱。「仕組みとして定義されていないもの」は、担当者が変わると失われる。属人性をなくすことは、リスク管理であると同時に組織の成熟でもある。
組織・プロジェクトの機能不全
事例E
プロジェクトがバラバラに動いていた
プロジェクト全体が、一人の頭の中にしかなかった
背景
複数ベンダーが参画する大規模プロジェクトで、システム導入後の混乱が起きていた。優秀だがワンマンなPMが一人で切り盛りしていた。全体の課題を把握しているのがPMのみで、それぞれの担当者はPMの指示がないと動けない状態だった。限られた時間の中でプロジェクトメンバーが自律的に動ける体制作りが急務とされていた。
何が起きていたか
WBSも課題一覧も整備されておらず、チームメンバーがバラバラに動いていた。PMのコミュニケーションスタイルがチーム全体に影響し、メンバー間の連携が取れていなかった。お客様の信頼も揺らいでいた。
弊社の関わり方
ヘルプとして参画し、WBSの統一・課題の整理統合と優先順位付け・コミュニケーションルールの整備を行い、プロジェクトマネジメント体制を立て直した。お客様の信頼がすぐに回復したわけではなかった。ただ、課題が整理され対応の優先順位と方向性が見えたことで、「何が問題でどう対処するか」をお客様と同じ目線で議論できるようになったことが、最初の変化だった。
本質的な
問題
個人の能力でプロジェクトが回っていた。どれだけ優秀なPMでも、仕組みがなければチームは動かない。マネジメントは個人の才能ではなく、仕組みとして設計するものである。
人・チームの変革
事例F
DX推進部門が、ユーザーから信頼されていなかった
部門が存在しているのに、誰にも頼られていなかった
背景
BIツールベンダーの支援として参画していた案件。ITに不慣れなマーケティング部門のメンバーがDX推進部門として再編されたばかりで、BIツールの有効活用を支援する役割を担う予定だった。
何が起きていたか
社内BIツールのユーザーからは「あそこに聞いても何も解決しない」と思われており、問い合わせすら来ない状態だった。根本にはBIツールのデータ品質の問題があり、DX推進部門としての機能を果たせていなかった。
弊社の関わり方
まずデータ整備から着手した。その上で、積極的にユーザー部門へ御用聞きを行い、問い合わせ対応→課題解決→提案ができるまでを伴走した。「頼まれるのを待つ」から「自分たちから動く」への転換を支援した。伴走を続ける中で、ユーザーから自発的に相談が来るようになり、部門としての信頼が少しずつ積み上がっていった。
本質的な
問題
ツールの問題以前に、データ品質と「誰のために何をする部門か」という役割が不明確だった。人の育成と役割の定義が先であり、それなしにDX推進部門は機能しない。「存在しているのに使われない部門」は、仕組みと役割が定義されれば変わることができる。
私たちの支援の進め方について、
詳しくはこちらをご覧ください。