問題の一つは、申請内容の不備だった。記入漏れのほか、半角カナの混入や略称ルールへの違反など、入力形式に関する不備も発生していた。そのたびに目視での確認や申請者への問い合わせ、差し戻しが必要となり、申請者と出納担当者の双方に負担がかかっていた。

　また、申請の受付経路が分散していることで、最新の対応状況や過去の変更履歴を把握しにくいことも課題だった。申請情報や処理状況を確認するためにメールやファイルを探す手間が生じるほか、担当者ごとに対応方法や作業手順が異なり、業務の属人化も懸念されていた。

　こうした状況を改善するため、同社はマスター申請の受付からSAP S/4HANAへの登録に必要なファイルの生成まで、業務プロセスと処理状況を一元管理する仕組みの構築を目指した。

APIによる直接連携ではなく、ファイル連携で既存のSAP運用を生かす

　今回の仕組みの構築に当たり、京急電鉄が採用したのは、kintoneとSAP S/4HANAをAPIで直接連携させる方式ではなく、SAP所定の形式に合わせたファイルを介してデータを受け渡す方式だ。

　kintoneに、マスター申請や承認、データ整形などを担うフロント側のアプリを構築した。申請受付から承認、SAPへのアップロード用ファイルの生成、進捗管理までをkintoneで管理し、生成したファイルをSAPに取り込む構成とした。

　kintoneを採用した理由には、画面や入力項目、業務プロセスを柔軟に設定できることに加え、プラグインを活用して複雑な処理にも対応できる点があったという。

　この構成によって、既存のSAP運用を生かしながら、申請受付や確認、データ整形といった周辺業務を改善が見込める。SAP本体に大規模な改修を加えることなく、業務アプリ側で申請情報の管理や登録用データの生成を標準化する設計とした。

　開発では、IT部門の支援を受けながらプロトタイプを作成し、アジャイル型で改善を繰り返した。その後は経営戦略室の2人が中心となって開発を進め、3～4カ月で本番稼働に至った。

入力不備や確認作業を削減、年間約600時間の業務時間削減を見込む

　同社は取引先マスター申請・登録アプリを、2026年2月に本格稼働させた。これにより、申請内容や対応状況、過去の変更履歴などをkintoneで一元管理できるようになった。

　従来のようにメールや申請ファイルを個別に探す必要がなくなり、申請情報や処理状況を確認しやすくなった。また、入力ルールに沿った申請やデータを整形する仕組みを整えたことで、記入漏れや入力形式の不備が抑制され、担当者による確認や差し戻しの削減につながった。

　さらに、SAP S/4HANAへのアップロード用ファイルの生成も標準化されたことで、担当者ごとの作業のばらつきや、特定の担当者の経験に依存する業務運用の抑制も期待できる。

　同社は、目視確認や差し戻しが大幅に減ったことなどから、年間約600時間、約75％の業務時間削減を見込む。加えて、申請者への確認作業やデータ検索、申請者自身の入力時間が減ることによる追加効果も期待している。

　今回の取り組みでは、単に申請手続きをデジタル化しただけでなく、申請情報の集約や入力ルールの徹底、登録用ファイルの生成の標準化を一体的に進めた。申請者と処理担当者の双方に発生していた作業負担を軽減するとともに、業務プロセスを共通の仕組みで管理できるようにした点が特徴だ。

次の課題は業務のブラックボックス化、市民開発の拡大を目指す

　京急電鉄は今回の取り組みを踏まえ、非エンジニアの業務担当者が自らkintoneを活用して業務改善を進める市民開発を、次のステップに位置付けている。

　現在、検討を進めているテーマの一つが、SAP S/4HANAの保守に関する問い合わせ対応を一元管理するアプリの構築だ。問い合わせ情報や対応状況を集約することで、保守業務の管理効率化を目指す。

　もう一つは、本社における取引先情報の管理や関連事務処理のアプリ化だ。この業務では、これまで複数のツールを組み合わせ、特定の担当者が処理を担っていたため、業務のブラックボックス化が課題となっていた。

　同社は、アプリ化に当たって既存の業務プロセスを棚卸しし、整理することも重視している。業務の流れや役割分担を可視化し、標準化を進めることで、単なるツールの置き換えにとどまらない業務プロセスの変革につなげる考えだ。

　さらに、将来的には「kintone AI」の活用も視野に入れている。kintoneに不慣れな担当者でもAIを活用することでアプリ開発に取り組みやすくなり、市民開発の裾野を広げられると期待している。

　AIの活用を通じてDXをより迅速かつ低コストで進められる可能性があるとして、各事業部門やグループ会社の担当者が業務改善に取り組みやすい環境づくりを引き続き推進する方針だ。

基幹システムの整備に加え、周辺業務の標準化が重要に

　今回の京急電鉄の事例からは、基幹システムの共通化だけでは、申請受付やデータ確認、登録用ファイルの生成といった周辺業務の課題が解消されない場合があることが分かる。

　特に、複数の部門やグループ会社が同じ基幹システムを利用する環境では、申請ルールの統一や入力不備への対応、進捗管理など、システムの外側にある業務プロセスも重要になる。こうした業務がメールや個別ファイル、担当者の経験に依存していると、確認作業の増加や属人化につながりやすい。

　その対策として、基幹システム自体を大規模に改修するだけでなく、周辺業務を担うアプリを構築し、既存の運用を生かしながら改善する方法もある。京急電鉄は、kintoneによる申請業務の一元化を通じて、処理時間を削減し、業務を標準化させた。

　今後は、こうした個別業務の改善を、業務プロセス全体の可視化や市民開発の拡大へとつなげられるかが焦点となる。ツールの導入そのものを目的とするのではなく、業務の棚卸しや標準化を並行して進め、現場が継続的に改善できる仕組みを整えることが、企業のDXを進めるうえで重要になりそうだ。