「1/15の工数でブラックボックスを解消」
SUBARUが進める最先端の“AI駆動BPR”とは？

——AI駆動BPRに取り組むことになった経緯を教えてください。

大山：私は2024年から26年3月までの約2年間、IT戦略本部内にあるIT運用部（現：ITサービスマネジメント部）に在籍していました。IT運用部の役割は、社内システムの運用や、社員からのパソコンに関する申請・問い合わせに対応することです。

私は異動する前から、IT運用部に「保守的な部署」という印象を持っていました。実際に異動してからも、IT運用部の先輩から代々伝えられている「決められたことを決められたようにやるのが運用だ」という言葉に違和感を覚えました。もし、新入社員がこれを言葉の意味通り受け取ったら「何も変えなくていい、変えてはいけないのだ」と考えてしまう恐れがある、と感じたのです。

そこでIT運用部の文化（マインド）を大きく変えようと、様々な取り組みをしました。例えば、IT運用業務の自動化です。いろいろなIT運用の自動化に取り組んだのですが、私が運用業務のことをよく分かっていなかったために、ほぼ全てのプロジェクトが失敗しました。私は「自動化で運用業務が0になればそれが一番良い」と思っていたのですが、実際には自動化のために必要なデータがそろっておらず、取り組みが進められないケースが多くありました。加えて、BPO（ビジネス・プロセス・アウトソーシング）先のITベンダーさんとの長年の関係があり、いきなり発注量を0にするのは現実的ではないというような実情も十分に理解しておらず、現場との温度差がありました。現場の「できない理由（課題）」を理解できたのは、取り組みを始めてからしばらくたってからのことでした。

このように多数の失敗があったものの、1年くらいすると「文化（マインド）を変えよう」とする私の姿勢に共感してくれる部員が増えてきました。そういった流れの中で取り組んだのが、アクティブディレクトリ（AD）やMicrosoft 365に関するIDの申請・変更ツールの改修と、それに伴うAI駆動BPRでした。

ID関連の申請・変更の業務はとても複雑で分かりにくいため、異動してすぐに「何らかの見直しが必要だ」と感じました。しかし、申請・変更のためのツールが10年以上前に作られたもので、過去にツール改修を繰り返した結果、ソースコードは10万行に達しており、中身がブラックボックス化していました。

社員の誰も手を入れられない状態で保守・改修が自社内では不可能であることに加え、ツールから出力されるCSVファイルにバグがあり、それを担当者が手入力で修正して何とか業務を回している、という状態でした。

——最初からツールの改修にAI駆動BPRで取り組もう、という方向性だったのですか。

大山：最初はこのツールの構築を依頼したベンダーさんに、ソースコードの解析や業務全体がどうなっているか解き明かしてもらうおうと、見積もりを依頼しました。すると「一部だけでも約１年以上はかかる」という回答でした。

　「そこまで時間がかかるなら厳しい」と残念に思ったのですが、ちょうどお付き合いが始まっていたＦＰＴ様にもご相談しようと思い立ちました。すると、「まずはAI駆動のリバースエンジニアリングで解き明かしをしましょう」と提案がありました。試行した結果、15分の1程度の工数で可視化できて驚きました。

まずAIで大量のソースコードを分析し、次に業務手順書などのドキュメントや、作業担当者にヒアリングした作業内容などもAIに読み込ませていきました。丁寧に1個1個解き明かしていくと、最終的には意外と簡単なフローであることが分かったのです。

ブラックボックス化した業務やツールをリバースエンジニアリングで解き明かしてしまえば、あとはBPRがメインとなります。その後は、現状のオペレーションで困っていることを書き出し、一つひとつをピンポイントで直していきました。1週間かけてプログラム開発とテストをし、ユーザーの受け入れテストを1週間やって本番投入、という2週間のサイクルを何度も回していったのです。ウォーターフォールだとそれぞれ何カ月もかかる作業ですから、スピード感に驚きました。結果として、ほとんどの課題を約3カ月で解消できました。

——ＦＰＴは過去に多くのBPRプロジェクトに関わった経験があると思いますが、今回のプロジェクトの難易度をどう捉えていましたか。

田中：SUBARU様のBPRの対象選定がまず素晴らしかったと思っています。生産ラインに直接影響するようなクリティカルな業務ではなく、リスクをコントロールしながら新しい手法に挑戦できる領域を対象としていました。「仮にシステムが止まっても手作業で対応する」と言っていただけたので、思い切って進められました。

約10万行とかなりのプログラムの量だったものの、それでも基幹システムほど多いわけではありません。これもAI BPRのトライアルとして、実効性を早期に検証することができ、その後の展開につながったと感じています。

鈴木：SUBARU様とＦＰＴとの契約形態そのものも大きなポイントだったと考えています。ブラックボックス化の解消という最も重要なゴールだけを決め、具体的な成果についての取り決めはしませんでした。

アサインメンバーの作業時間などはあらかじめ決めていましたが、取り組みの進め方はフレキシブルに変える、という形でした。実際にプロジェクトの進め方や優先順位は、日々の話し合いの中で決めていきました。具体的な作業内容や進め方にも縛りを設けていなかったため、取り組みの中で自由に手法を変えていきました。

田中：AI駆動BPRといっても、全てがAIだけで完結するわけではありません。まずAIの特性を理解し、それに対応してAIに任せた方が効率的な点などを見極めて、AIを道具として使いこなす姿勢が重要だと考えています。

大山：効果の高さとやりやすい所を選んで取り組んだことも大きかったと感じています。今回は、ツール改修の範囲で対応できるものに対象を限定しました。今回を取り組みのバージョン1（スピード重視のBPR＆BPO）と位置付け、やり残したことについてはバージョン2（横展開＆自動化）や3（本業への適用）で取り組みたいと考えています。

——今回のAI駆動BPRによって改修したツールの運用についても、BPOという形でＦＰＴに依頼しています。BPOを決めた経緯についても教えてください。

大山：当初はAI駆動BPRのみのプロジェクトであり、BPOは可能性を議論するだけにとどまっていました。従来もツールの運用は別のベンダーさんにアウトソーシングしていたのですが、それによって業務もプログラムもブラックボックス化してしまったので、まずはその状態を解消して自社で主導権を取り戻すことからスタートしたのです。

ツールと業務のリバースエンジニアリングを終え、業務の主権を取り戻した後に、BPOを意識したAI駆動BPR に取り組みました。この取り組みを進めるうち、既存業務をBPOしているメンバーも、本プロジェクトに協力してもらえるようになり、BPRが加速していきました。

——コスト面などではどのような成果が出ていますか。

大山：お話しした通りゴールを定量的な所に置いていなかったので、コスト評価を開始したのは、ごく最近です。これまで投資したコストの回収期間を12カ月と定め、この期間で回収できるかどうかを判断しています。従来も運用をアウトソーシングしていたので、それをＦＰＴ様に切り替えたことによって12カ月間以内で回収できるコストかどうかをチェックする、ということです。それは確実に達成できると思っています。

——今回のプロジェクトはAIを使った最新の取り組みといえます。その取り組みが成功した理由は何だとお考えですか。

大山：AI活用は、DXの取り組みの1つです。そういった意味では今回改めて、「デジタルトランスフォーメーションは、まずトランスフォーメーションが重要だ」と感じました。デジタルやAIは脇役であり、トランスフォーメーションがないと業務をデジタルに置き換えられません。

冒頭で「IT運用部を大きく変えたかった」とお話ししましたが、私が今回感じたIT運用部の変化の1つが、部員の愚痴の内容が変わったことです。最初はＦＰＴの担当者様がうちの社員に「ソースコードをください」と依頼しても、「忙しい」「難しい」とすぐに行動する社員が少なかったそうです。こういった気分や不満を漏らす、「感情型」といえるタイプの愚痴が多くありました。

時間がたつにつれ、愚痴の内容が「この仕事は誰の判断に使われているのか」「なぜここで二重入力が必要なのか」「この仕事は廃止できないか」といった仕事の構造に関するものに変わっていきました。私はこういった「構造型」ともいえる愚痴を部員のマインドの変化だと感じ、希望の兆しだと前向きに捉えました。

最近では「このKPIは目的とずれていないか」「この会議は本当に何かを決めているのか」と、判断そのものを問い直す発言をする部員が増えてきました。いってみれば「意思決定型」の愚痴です。部員の愚痴が、感情から仕事の設計や意思決定に向かい始めたとき、変革が始まるのだということは、今回の大きな学びでした。

——今後の展開について教えてください。

大山：今回改修に取り組んだID申請・変更のためのツールは、サービスデスク領域に当たります。今後は、ITインフラの運用や、その他業務システムの運用保守にも対象を拡大したいと考えています。

今回のプロジェクトをさらに深める取り組みもしたいと考えています。お話しした通り、これまでをバージョン1とし、バージョン2ではBPOした業務の自動化に取り組みます。自動化の取り組みが難しいのは、多くの業務を自動化しようとするとそのためのツールの開発費・維持費によってかえってコストが高くなってしまうという点です。そのため、「どこまで自動化するとコストメリットが出るのか」というバランスを見極めていきたいと思っています。これと関連して、開発段階からシステムのランニングコストを意識した、「運用オリエンテッド」な新しい開発手法も検討したいと考えています。

バージョン3は、基幹業務の見直しを含めたBPRに取り組むことですね。自動車づくりの本業は規模が大きいので、仮に1％業務効率を改善するだけでも数十億～数百億円のコストメリットが出る可能性があります。我々の取り組みを深めることで、事業全体の利益に貢献できるのではないかと思いますので、失敗を恐れずチャレンジしたいと考えています。

最後に、SUBARUのIT戦略本部では、すべてのプロジェクトを「運用オリエンテッド」の視点で進めています。システムは、開発にかかる費用よりも、運用が始まってからの費用のほうがはるかに大きくなるからです。今回のAI駆動BPRも、まさにこの運用の視点から業務そのものを見直す取り組みでした。

「AI駆動BPR」という言葉が世の中にまだなかった1年以上前から、FPTの皆さんと手探りでチャレンジを重ねてきました。その積み重ねによって業務の主導権を取り戻し、運用の現場から設計のあり方までを見直すことができたと感じています。ご一緒いただいたFPTの皆さんに、心より感謝申し上げます。