HANA導入をいかに成功させたのかまもなく「2027年問題」を迎えるSAPユーザーはもちろん、これから基幹システム導入や刷新を検討するIT関係者にとって、直近の大規模な基幹システム刷新事例は興味関心の高いテーマだろう。近年のシステム刷新プロジェクトには、過去に比べて多種多様なステークホルダーが関与するケースが多い。中でも特徴的なのが、かつて「ユーザーとベンダー」による2社体制でリードするプロジェクトワークが主流だったところに「コンサルタント」が入り込み3社体制になるケースだ。(以下、古河電工)、および導入を支援した富士通株式会社(以下、富士通)、ケンブリッジ・テクノロジー・パートナーズ(以下、ケンブリッジ)の3社より、古河電工SAP導入プロジェクトをリードしたプロジェクトマネージャー(PM)3名をパネリストに迎え、プロジェクト中の様々な難局とその乗り越え方を語ってもらった。前編では本プロジェクトの抱える複雑さや数々の課題が浮き彫りとなったが、後編では「それらを3社でどう乗り越えていったのか」を掘り下げていく。モデレーターは白川克(ケンブリッジ)が務めた。世間では、システム構築プロジェクトは「ユーザーが要件を言語化しそれに基づいてベンダーがシステムを構築する」のが王道とされています。した「教科書的なやり方」が通用しないシーンも多々あります。「あるべき業務の姿」や「欲しいシステムの機能」を1から100まで語れるユーザーや、要件や機能の取捨選択を迫られた時に「いる」「いらない」を明言できる人は希少だからです。SAPの世界でも同様のことが起こっています。要件をフワッとさせたまま導入を始め、「決められないから全部載せで」となるユーザーの要望をベンダーがズルズルと叶え続けた結果、アドオンだらけのSAPになってしまう。なるとメンテナンス費用はかさむし、次バージョンへの移行も困難になります。パネリストの皆さんと事前に話した時、「このプロジェクトはまさに教科書論が通じない世界だった。3社が互いに『領空侵犯』しないと決してうまくいかなかっただろう」と口々に仰っていたのが印象的でした。「領空侵犯」というのは、相手の仕事に口も出すし手も出す、ということです。具体的に言うと、ベンダーがユーザーの仕事に口を出したり、コンサルタントがベンダーの仕事を巻き取ったりということが、このプロジェクトでは日常茶飯事に発生していたということですよね。これはなかなか「教科書の世界」ではお目にかかれない、と思います。具体的にどういう領空侵犯をしたのか、どうしてこうした領空侵犯が可能だったのか、この座談会を通じて浮き彫りにしていければ、と考えます。古河電工はどのような領空侵犯をしたのか、聞かせてください。このプロジェクトではまず経理の領域から着手しました。HANAの標準機能をとにかく使い倒して業務を標準化する」を理解していたので、経理メンバーがプロジェクトに多くアサインされたのです。彼らはアサイン後ただちにSAPの学習から始め、業務に必要なSAPの知識を習得しました。本来であればSAPの専門家である富士通に知識の部分をお任せするのが「教科書の世界」なのですが、あえて古河電工の経理部門は富士通の領空を侵犯したのです。ユーザーは「ベンダーさん、お金を払うから要求通り作ってよ。システムのことは何でも知っているでしょ」となりがちですが、古河電工の経理メンバーの皆さんは「自分たちがSAPを理解しないとシステム更新はうまくいかないだろう」と考えたわけですね。今度は富士通のメンバーが古河電工の業務内容を知ろうと領空侵犯してくれました。富士通と古河電工が業務とシステムの両面で相互に理解を深めることによって「SAP標準機能で業務を運用することで生じるリスク」を早めに察知し回避することができました。これによりSAP以外の領域のリスクを回避するのに時間を使えるというメリットが生まれました。ケンブリッジがコンサルタントの立場から気を付けたことを教えてください。常に気を付けていたのは「どうすれば目の前の課題を解決してプロジェクトを成功させられるのか」という本質的なところに関係者の意識を集中させることです。会社vs会社、人vs人になるとどうしても「どちらが責任を取るのか」という話になりがちです。なってしまったとたん、プロジェクトが進まなくなってしまいます。「得意な人がやればいいじゃないか」という主旨の発言を常にしていました。富士通が得意な領域もあれば不得意な領域もあるし、古河電工に得意なメンバーがいたらお願いすればいい。ケンブリッジは上流の計画を立てるのが得意ですから、富士通の立てた計画に対し「こっちのほうがスムーズではないでしょうか」と提案をしたり、ケンブリッジで普段使っているフォーマットを提供したりしました。ユーザーである古河電工にとって無理のない計画を作るのが目的ですから、ベンダーもコンサルタントも関係ないんですよね。関係者に常に課題に集中してもらえる場作りをしたことで「ここは古河電工に出張ってもらいたい」「ここは富士通の責任範囲だけどケンブリッジがやります」などの意見が自然と出てくるようになったと思います。今の話は、好意的に捉えれば「提案時の責任範囲や成果物一覧をあまり気にせずに取り組んだ」ということですが、一方で見方によっては「非常識で危険なやり方だ」と捉える人もいるかもしれません。通常のプロジェクトだと契約の縛りもあり、多くのベンダーやコンサルティングファームは「各社の責任分界点を決め、それぞれが役割を全うすることこそが最も良いやり方だ」と考えているからです。それをあえて崩したのはなぜでしょうか。登ろうとしている山が高すぎて頂上が見えなかったからだと思います。プロジェクト開始の段階で課題を全て把握できていたわけではないし、ブラックボックス化した古いホストシステムと向き合うのだからプロジェクトを一歩前に進めるたびに様々な難題にぶつかることはなんとなく予感していました。プロジェクトを始めるときに「登るべき山がとてつもなく高い場合、誰かの責任だけで登り切るのは難しいんだ」とチーム全員に伝えました。それによって「各自が決められたことだけやって終わり」ではなく、全ての問題に対して「全員でこれを解決しないとこのプロジェクトは成功しない」という意識をプロジェクトの初期段階で醸成できました。これが素早い領空侵犯につながったのだと思います。「富士通はここまで」「ケンブリッジはここまで」ではなく「全ての問題に対し、みんなで解決すべき」という想いで取り組んでもらえました。最初はなかなか馴染めませんでした。これまで関わったシステム構築プロジェクトでは、お客様から「富士通はシステム構築のプロなので、どのように段取りすればうまくいくのかを示してほしい。それができないとベンダーの責任ですよね」と仰っていただくことがほとんどでした。システム構築プロジェクトはベンダーだけのものではなく、ユーザーも関係者です。最終的な段取りの責任はベンダーになってしまうことが多いのです。した長年のやり方が染みついているので、プロジェクトの初期段階では「古河電工が目指したい姿に対してどう段取りすればよいのだろう」とか「これは古河電工が決めてくれないと先へ進めなさそうだ」といった「ベンダーの立場」を固守してしまっていた部分は否めません。「振り返り会」の効果が大きかったかな、と思います。各フェーズの終わりに、そのフェーズを振り返ってみて「よかった点」「次のフェーズで改善すべき点」などを全員で出し合うものです。振り返り会にはもちろん富士通のメンバーにも参加してもらい、富士通から見たプロジェクトの問題点や考えられるリスク、古河電工に改善してほしいことがないか、などをを上げてもらいました。古河電工にどんな改善を要求したのでしょうか。意思決定のスピード感に関する改善です。システムを作って提供するのはベンダーの役割ですが、それを誰がどのように使うのか、どの程度の使い勝手が求められるのかを明確にするのはユーザーの役割です。今回のプロジェクトは関係者が多いので古河電工も調整に苦慮されていました。納期は厳守しなければならないので意思決定のスピードを速めるよう、強く改善を求めました。プロジェクトによっては、ベンダーから顧客へ改善を要求したりリスクを明言したりするのは難しいですよね。振り返り会は、今風に言えば「心理的安全な場」でした。「プロジェクトを成功させるためなら言いたいことを言っていいんだ」という気持ちになれたので、その後はベンダーの立場にこだわらず発生する問題に対してアプローチできたと思います。プロジェクトをうまく進めるためにユーザーやベンダーの垣根を越えてちゃんと要望を出し合おう、リスクを共有し合おう、という雰囲気をケンブリッジが作ってくれました。3社が同じ土俵で話ができたので、古河電工の体制が十分ではなかった面に気づかせてもらい、解決方法を見いだしながら進めることができました。コンサルタントがユーザーとベンダーの間に入ることで関係者が無駄に増えてうまくいかなくなるプロジェクトもあると思います。今回、ケンブリッジが介在することでプロジェクトはスムーズに進んだのでしょうか。過去のプロジェクトの経験から「ベンダーに契約通りの仕事をさせるのがコンサルタントの役割」というイメージがありました。ケンブリッジが明確に違ったのは「どうすればプロジェクトがうまくいくか」に100%向き合っていたことです。振り返り会などを通じて「プロジェクトにとって何が課題か」「誰がそれを解決するのがベストか」をプロジェクトのメンバーに問いかけ、議論をドライブしていました。したケンブリッジの「場作り」とファシリテーションが3社相互の領空侵犯を後押ししていたし、私にとって新鮮でした。会社の立場にこだわらず言いたいことを言った結果、プロジェクト全体に対して貢献できた、ということですね。多くのプロジェクトでは、契約の縛りもあり、責任の取れないことに対して会社として発言してはならない、という暗黙のルールがしばしば存在するように感じます。「ここに大きな課題があるのに」と思っても発言しないメンバーがいるかもしれない状況は、プロジェクトとして不健康に思えます。今回のプロジェクトのように「プロジェクト全体として何が課題なのか」を全員できちんと議論できる場が用意されていれば、プロジェクトに関わるメンバー全員が「同じ土俵」に上がることができるし、今まで気づかなかった課題を見つけられる可能性も高まるし、「誰がその課題に対応するのがベストか」を判断できます。様々なチームで「みんなで解決しよう」という雰囲気を古河電工のメンバーが作ってくれてそこに富士通のメンバーも参加してくれるなど、信頼関係を日々醸成できたと思います。大所帯だったので、なかなかこちらの思うようなコミュニケーションを取るのが難しい人も中にはいました。そこはプロジェクトの意思としてきちんと指摘して、それでも改善が見られないようなら他の人に変わってもらったこともありました。プロジェクトが長丁場になるほど「上手くいかなかったから諦めて放置する」のではなく「いかに現場をもっとよくするか」という粘りが必要ですね。最後に、現在進行形で難しいプロジェクトに取り組んでいる人、いつか取り組む人に、皆さんからひと言ずつお願いします。今回、プロジェクトをうまく立ち上げ成功させることができた最大の要因は、富士通、ケンブリッジと、契約の関係だけでなく「1つの船に乗って同じ方向を目指す」ということを常に意識して行動したことにあると考えます。これを実現できればプロジェクトはかなり成功に近づくと思います。「会社としてここまでしかやれない」という「立場の壁」を越えて関係者がワンチームにならないと、大きなプロジェクトは成功しないと思っています。立場を越えてワンチームになるためには、「まず自分が『のりしろ』になろう」と心がけることが必要です。仕事人生の中で大きなプロジェクトを体験できることはめったにないので、チャンスだと思って飛び込んでほしいです。同じ方向を向きつつ、立場が違えば当然見え方は変わります。「自分からはこう見える」と腹を割ってぶつけ合うことが大事だと思います。「人や会社ではなく課題と向き合う」という話をしましたが、こうした様々な見え方を持つ関係者が集まれば、課題解決のスピードは断然上がっていくと思います。この座談会のまとめとして、こういう事例セミナーは、お客様とベンダー、あるいは、お客様とコンサルティング会社の2社が登壇することがほとんどですが、今回はあえて3社に一堂に集まってもらいました。座談会の中でも「領空侵犯」「のりしろ」という印象的な言葉が出てきましたが、改めて、こうした大きなプロジェクトでは、ユーザー、ベンダー、コンサルタントが、各々の会社や立場の垣根を越えて、お互いの信頼や努力を噛み合わせながら仕事を前に進めることが必要なんだ、と感じることができました。この実感を観客の皆さんに少しでも伝えるためには、3社が集まる必要がありました。この座談会が少しでも皆さまの役に立てば幸いです。HANA導入をいかに成功させたのか」は分量が多く、本事例ページでは前後編に分けてお届けしています。それでも文字量の都合で掲載できなかったパート(経営層やユーザーの巻き込み方)があります。そこで、これらも含めた「全文掲載版」をご用意しました。ご興味のある方はこちらをご覧下さい(要事前登録)。FORM」よりご連絡ください。SITE」をご覧ください。