「前にもやったがダメだった」社内からあふれたネガティブな声

粘り強いコミュニケーションで部下を率いるマネジメントスタイルは、子育て期を終えてからさらに洗練されていった。

女性初の理事になった頃、長期にわたるプロジェクトで責任者を務めた。会計と購買の新システム移行を中心とした業務改革のプロジェクトだ。新システムの導入を機に会計と購買の部署で業務プロセスやルールを見直し、さらにシステム開発だけでも2年はかかる規模だった。

過去の基幹系システムは、システム部門に依頼してゼロから構築するスクラッチ開発で進めていた。業務に合わせて独自のシステムを開発する形だ。

しかし今回は、世界的に実績があるERPパッケージ(経営資源や実績情報を共通化する仕組み)を導入することにした。ベストプラクティスに合わせた業務変革が第一の目的。

通信業界は競争が激化し、KDDIは新サービスを数多く導入していた。国内外でM&Aを進める場合も多く、いつまでも手作業に頼っているわけにはいかない。財務会計・管理会計では国際財務報告基準(IFRS)の適用など環境が一変していた。環境変化に対応するために業務プロセスの刷新を迫られていた。

ERPパッケージへの業務Fit率目標は90%超と定めた。つまり、自社に合わせてカスタマイズするのは10%未満だ。会計、購買の現場からは「業務プロセスの見直しなんてやってもムダ」「前にもやって失敗した」「どうせ途中で諦めることになる」とネガティブな意見ばかりが聞こえてきた。

当時はちょうどDXが注目されだした頃。DXの必要性は理解できても、ハードウェア重視のハコ発想や組織の壁、人的資本への投資不足、古い意識や価値観などが組織変革のボトルネックとして大きかった。

【図表1】当時の職場が抱えていた問題点

「失敗したら私が責任を取ります」

パッケージ導入とはいえ、基幹システムの開発は情報システム部門の協力が必要になる。プロジェクトへの参加を求めると「どの部門がシステム開発の責任を持つのか?」と聞かれた。

スクラッチ開発では情報システム部門が責任部門になる。しかし今回はパッケージ導入だから、トラブルになったら責任が取れないというのだ。最勝寺さんが「失敗したら責任は私が取ります」と言うと、「本当に取るんだね」と念を押された。「はい、取ります」と答えた瞬間、あ、言わされたと気がついた。システム開発を含め、プロジェクト全体の責任を取る立場になっていた。