SAPの導入・運用に関わっていると、必ず耳にするようになったワードがある。「Joule」だ。
SAP社が提供するAIアシスタントで、自然言語でSAPを操作できる、問い合わせに即座に答えられる——そんな触れ込みで注目を集めている。
「これで保守費が下がる」という声も聞く。
本当にそうだろうか。35年以上、SAPの現場を歩いてきた立場から——ABAP開発を軸に、FI領域も経験してきた現場人間として——正直に考えてみた。
SAPの保守費、正体は「時間」だ
まず前提として、SAPの保守費の本質は何かを整理したい。
契約形態はさまざまだが、結局のところ費用の正体は工数＝時間だ。
お客様から問い合わせが入る。運用保守ベンダーが受け取る。答えを出すまでに時間がかかる。この「かかる時間」がそのままコストになる。
問い合わせの難易度によって、対応の深さも変わってくる。
お客様から問い合わせ
↓
運用保守ベンダーが一次対応
↓（難しければ）
ベテランSAPコンサルに確認（＝高単価）
↓（それでも解決しなければ）
外部ABAP開発ベンダーに依頼（工数清算）
↓（それでも）
SAP社へ有償サポート依頼このエスカレーション構造の中で、どの段階で止まれるかが保守コストを大きく左右する。
ベテランコンサルを常駐させれば早く止まれるが、単価が高い。かといって経験の浅い担当者だけでは、エスカレーションが多発してかえって高くつく。
「誰を現場の最前線に置くか」——これがSAP保守コストの核心にある問いだ。
現場で一番多い問い合わせは何か
現場に長くいると、問い合わせのパターンがわかってくる。
障害・不具合系は件数は少ないが緊急度が高い。「今すぐ動かない」という状況なので、即時対応が求められる。
だが件数として圧倒的に多いのは、別の種類の問い合わせだ。
「なんでこうなってるの？」——設定・仕様の背景を問うものだ。
ここに、SAPという巨大パッケージシステム特有の皮肉がある。
そのシステムの仕様は、もともとお客様自身が「こうしてほしい」と要望して作ったもののはずだ。導入プロジェクト時に、時間をかけて決めた設計のはずだ。
それがなぜか、数年後には「なぜこうなっているのか」という問い合わせとして運用保守ベンダーに届く。
理由は単純で、担当者が変わるからだ。導入時のことを知っている人はいなくなり、現在の担当者は引き継いだシステムを「あるもの」として受け取っているだけだ。
さらに厄介なのは、この問い合わせの本当の背景にある。
「なんでこうなってるの？」と聞いてくる担当者は、たいていの場合、自分が知りたいわけではない。上層部から「この仕様の根拠は何か」と問われており、その答えを探しているのだ。
だから、運用保守側が「私たちも知りません」と返すのは技術的には正直な答えだが、実務的には不誠実な対応になってしまう。現場ではその背景を想像し、汲み取りながら、できる限り誠実に答えることが求められる。
これが現場の現実だ。
Jouleは何を解決しようとしているか
では、Jouleは何者なのか。
Jouleは20万ページ以上のSAPドキュメントと、2TBのコミュニティ知識を学習したAIアシスタントだ。2.5億行のABAPコードを学習した専用LLMも使われている。
SAP社が社内の4,000人を対象に行った検証では、1日あたり約1.5時間の調査時間短縮という結果が出ている。コード解釈にかかる時間も40%削減されたという。
自然言語で問いかければ、SAPの標準機能について即座に答えが返ってくる——という触れ込みだ。
Jouleが「保守費を下げられる」とすれば、どのシーンか
正直に言う。
Jouleが「SAPとはどういう仕様になっているか」を答えることはできる。標準機能の背景、設定の意味、操作の手順——ドキュメントに存在する知識については、驚くほど的確に答えるだろう。
だがJouleには、絶対に答えられないことがある。
「あなたの会社が、なぜその仕様を選んだのか」だ。
お客様固有の設計判断、過去のプロジェクトで積み上げた意思決定の経緯——それはどこにも文書化されておらず、Jouleが学習できる類のものではない。「なんでこうなってるの？」問い合わせの核心部分に、Jouleは届かない。
では、Jouleに意味はないのか。
そうは思わない。コストを下げられる可能性があるとすれば、「現場最前線の人材選定」においてだ。
従来、SAPの保守現場には単価の高いベテランコンサルを置く必要があった。それは、知識と経験の厚みがないと即座に判断できない場面が多すぎるからだ。
Jouleが変えるかもしれないのは、中堅・初級のSAPコンサルがベテランに近いスピードで動ける環境だ。
「この設定はどういう意味か」「この操作の手順は」「このエラーメッセージは何を示しているか」——こうした問いに、Jouleが即座に答えてくれるなら、経験の浅い担当者でも対応の速度は格段に上がる。
それでも、最後の「水際判断」は人間にしかできない
ただし、ここで冷静になる必要がある。
Jouleが出してくる答えは、「正解一択」ではない。
あくまでも可能性の高い回答であり、その内容をそのまま実行するかどうかは、人間が判断しなければならない。SAPのシステムは、一つの設定変更が思わぬ場所に影響を及ぼすことがある。「Jouleがこう言ったから」では済まない。
Jouleが示した答えを見て「これは正しいか」「本当に実行していいか」を判断できる目——それはやはり経験から来るものだ。
ではベテランでないと無理か、というと、私はそう思わない。
確かに最初は心もとないかもしれない。だが、中堅・初級のコンサルにその判断を任せることは、その人の成長を促し、組織を強くすることでもある。Jouleという強力なサポートがある環境で経験を積むことは、何もない環境で経験を積む以上に、早く確実な成長につながる可能性がある。
コストとスピードの観点からも、長期的な組織育成の観点からも、「中堅・初級にJouleを持たせて最前線に立たせる」という判断は、十分に合理的だ。
まとめ：Jouleは「保守費を下げる魔法」ではなく「人材の方程式を変えるツール」
Jouleで保守費が下がるか——答えはシンプルではない。
Jouleが得意なのは、標準仕様の説明、操作のナビゲーション、ドキュメントに存在する知識の即時提供だ。それはエスカレーションを一段階減らし、対応速度を上げる力を持っている。
だが、「あなたの会社の仕様の背景」は答えられない。最後の判断も、人間にしか下せない。
Jouleが変えるのは、保守コストの構造そのものではなく、現場に置く人材の組み合わせの選択肢だ。
ベテランでないと回せなかった現場が、Jouleを持った中堅・初級で回せるようになるかもしれない——そこにこそ、コスト削減の本質的な可能性がある。
そしてその恩恵は、コスト削減だけでなく、次の世代のSAPコンサルを育てる土台にもなる。
現場目線から見れば、それは悪くない話だと思う。
（このブログではSAP×AIに関するリアルな情報を、現場の視点からお届けしています。）
コメント