関西電力株式会社様 事例紹介

業務理解から始まったシステム開発。現場を巻き込んで実現した業務改善と、JavaScriptからの脱却

関西電力株式会社は、1951年に設立された大阪府大阪市に本店を持つ電力会社です。電気事業、熱供給事業、電気通信事業、ガス供給事業を主な事業とするほか、国際事業や情報通信事業、生活・ビジネスソリューション事業、新規事業としてモビリティ事業など幅広い事業を手がけています。

電気の契約先を他社から関西電力に変更する申込受付業務について、2018年にすでに導入していたkintoneで効率化することにしました。このシステムの開発をアールスリーに依頼した経緯と効果について、ソリューション本部 企画部門 システムグループ 副長 前田悠平氏、竹内稜太氏にお話を伺いました。

ソリューション本部では、お客さまに電気やガスなどの各種ソリューションを提供しています。中でも前田氏、竹内氏の所属するシステムグループは、電気やガスの提供に必要なシステムである料金・請求関連のシステムや、案件管理・顧客管理システムを担当しています。

依頼のきっかけ：つながらない電話の苦労と、柔軟性を欠いたシステムの限界

依頼のきっかけとなったのは、大きく2つの課題でした。1つは申込に関する電話対応の負荷、もう1つは既存のJavaScriptカスタマイズが柔軟なシステムの改善を妨げていたことです。

同社では、電気の契約先を他社から変更を希望する顧客より、電話やネットで申し込みを受けられます。申し込みを受けたら元の契約会社に契約廃止の連絡をし、同一のお客様であることが確認できると切り替えが可能になります。
ここで名義の不一致や供給地点特定番号の誤りなど、同一の顧客であることが確認できなかった場合、顧客に架電して正しい情報の確認をされます。しかし、電話がつながらないことも多く時間と手間がかかりますし、コールセンターの架電担当者に心理的な負担もかかっていたといいます。
この情報の相違による架電は毎月数千件も発生していたため、効率化しようと考えられました。

もう一つの課題は、既存のアプリがJavaScriptでカスタマイズされていたことでした。
アプリが作られてから数年経ち業務にフィットしない機能があっても、JavaScriptのカスタマイズを変えることが難しく、業務の変化に合わせてアプリを変えられなかったそうです。
「これをどうにかしようとgusuku Customine（カスタマイン）を導入しました。JavaScriptのカスタマイズを置き換えて、保守性やメンテナンス性を高めようと考えたんです。少しずつ進めていたのですが、アプリ数もたくさんあるためすべてを置き換えるには至っていませんでした」（竹内氏）

選定理由：業務を理解し、意見をくれる存在

「前にも別のシステムをシステム開発会社に依頼したことがあったのですが、その時は言われた通りにシステムを作るだけといった傾向が強かったです。今回はそうではなく、私たちの業務をしっかり理解して同じ目線で開発してくれる会社がいいと思っていました。kintoneの販売元であるサイボウズさんに相談したところ、アールスリーさんを紹介してもらいました」（前田氏）

アールスリーとの初回の打ち合わせでは、思い描いていた通り意見をもらいながら、やらない方がいいことやダメなことははっきりと言ってくれると感じた前田氏。
こうしたいという要望を伝えると、「どういう意図で？何に使う？」と丁寧に問いかけが返ってくることで、立ち止まって考え直すことができたといいます。
「やりとりをする中で、『そもそもこれって必要なのだろうか？』と自分で気づく場面もありました。要望をそのまま形にするのではなく、目的から一緒に考えてくれる姿勢は、まさに理想の開発パートナーだと感じました」（前田氏）

さらに、アールスリーがカスタマインの販売元であることも後押しとなります。JavaScriptによる複雑なカスタマイズをカスタマインに置き換えるという方針にマッチし、開発を依頼することを決定されました。

業務理解：現場と一緒に、フローを可視化

2024年6月に開始した今回のプロジェクトで最初に取り組んだのは、現行の業務の全体像を正しく把握することでした。
電気の申し込みで申込内容に不備があった際の架電や情報共有など、日々の運用を誰が、いつ、どのタイミングで、どこに情報を入力して、誰に渡すのか、といった流れを時系列で整理し、業務フローを可視化しました。
さらに、新システム導入後にどこが変わるのかを比較し、関係者で共有しました。

この業務フローの整理には現場のメンバーも加わり、実務の感覚に沿って進めました。図や表による共有は認識のずれを防ぎ、プロジェクトの初期段階で全員の理解をそろえることができました。

依頼のきっかけとなった2つの課題に対してアールスリーがどのように解決したのかご紹介します。

課題1：不備対応の負担を軽減した、新たな仕組み

依頼のきっかけで紹介した通り、不備の電話対応における架電担当者の負荷は相当なものでした。そこで同社は、架電担当者が不備を解消するのではなく、顧客自身で解消してもらう方法がないか検討されていました。アールスリーに依頼をいただいた時点で、すでにQRコード付きの書類を送付する仕組みを考えられていたのですが、具体的な実現性が検討できていませんでした。この課題に対してアールスリーは、前述の業務理解を行ったうえで、具体的な実現性の検討・検証を行いました。

これまでの知見と詳細な検証により最適な連携サービスを選定

同社では以前から、電話での申込受付時にFormBridgeを使っていました。受付担当者がkintoneアカウントを持っていないためです。FormBridgeを使えば、kintoneアカウントを持たなくても外部フォームからkintoneへの新規登録が可能です。
一方で、FormBridgeのみでは、登録済みのレコードの編集は行う事ができません。お客様もkintoneアカウントを持たないため、外部から既存のレコードを修正できる仕組みが必要でした。
アールスリーは既存のレコードを外部から編集する方法を検討し、kViewerをFormBridgeと連携させることで、既存レコードをFormBridge上で編集できるようにする方法を採用しました。
また、QRコードを印字した書類の送付を実現する具体的な方法も検討。カスタマインで生成した帳票を、郵送代行サービスであるRepotovas Proで送付する仕組みを採用しました。
本番運用を想定してさらに検証を重ね、実際にこの基本構想で実現できそうなことがわかり、同社の当初の狙い通り、不備対応時の架電が不要な仕組みを実現できました。

コスト面と心理面の両側の改善に

不備対応の架電が不要になったことで、さまざまな効果がありました。 コールセンター業務は外部の協力会社に委託していたため、架電を減らしたことによって委託費用を削減することができました。さらに、何度架電しても出ないという心理的な負担も軽減され、対応にあたる現場のストレスも軽くなったといいます。新たに郵送手配業務が加わりますが、基本的にボタン操作のみで一括手配できるため、負担はほとんどありません。 

また、これまで期日もなかったため、電話がつながらず電気の契約先の切り替え手続きが完結できないままになっているケースが多々ありました。今回、回答期日を設けたWebフォームにしたことで、完結しやすくなりました。Webフォームに顧客自身で入力してもらうことで、口頭でのやりとりに比べて漢字の間違いやアルファベットの表記ミスといったヒューマンエラーも減少しています。こうしたことから、今後は完結率の向上が期待されています。

申込方法の違いにも連携サービスの活用により柔軟に対応

実は、お客様からの切り替えの申込方法は電話受付、Web受付の2種類あり、それぞれ運用が異なるので、実現方法も異なります。電話受付とWeb受付では、両方ともお客様ご自身に書類のQRコードを読み取っていただき、Web上のフォームから修正いただける仕組みになっているのですが、QRコードに含まれるURLの発行方法と、Webフォームへのアクセス方法が異なります。

電話受付については先ほどご紹介した通り、従来から担当者がFormBridgeを使い、kintoneへレコードを登録していました。新方式では、kViewerのマイページと連携させることで、kintoneレコードへの登録と同時にURLが自動発行されます。このURLは申込ごとにユニークなURLとなっていて、kintoneレコードに紐づけられた外部フォーム（マイページ）にアクセスするためのものです。切り替えの申請後に不備があった場合は、担当者が郵送用PDF作成のボタンを押します。

ボタンを押すとQR(URL)を印字した郵送用のPDFが自動作成され、郵送待ちのステータスに変わります。担当者が一括郵送用のボタンを押すと、一括で郵送が自動的に手配される仕組みになっています。

書類がお客様に届いたら、QRコードを読み取っていただきます。URLはユニークで、かつ、暗号化されていて他の人には推測できないものとなっているので、認証等は不要です。QRコードをお客様に読み取ってもらうだけで対象のレコードが表示され、kintoneレコードが編集できる仕組みになっています。

※kViewerのマイページビュー：kintoneのレコード詳細画面を外部公開したページ。1レコードに1つ専用ページ（Myページ）が生成される

一方、Web受付では、まず基幹システムにデータが入り、そこから出力したcsvファイルをkintoneに取り込む仕組みになっており、FormBridgeを経由しません。調査した結果、その場合は申込レコードごとにユニークなURLを発行する機能が使えない事がわかりました。
そこで、同じくkintoneアカウントなしで、外部からkintoneレコードにアクセスできるkViewerのリストビューを使う事にしました。

ただし、リストビューで発行されるURLは、お客様ごとに発行ができない固定のURLになっているため、そのままでは他のお客様の申込内容も閲覧できてしまいます。そこで、同じくkViewerのEメール認証の仕組みを使い、Web受付時に入力してもらったメールアドレスが一致するレコードのみを表示するようにしました。

カスタマインの活用によりスタッフの負荷を軽減

また、今回の仕組みを実現するうえで、新たに発生する業務の業務負荷の削減、手作業によるミスの予防等のためにはカスタマインの活用は必須でした。例えば以下のような仕組みの実現にカスタマインが関与しています。

• お客様が回答した時に、ステータスの更新などの後処理を自動で行う
• PDFに印字する郵送先住所の動的な切り替え（条件により配送先が変化）
• Web受付の場合の修正フォームにアクセスするタイミングのみログインを許可し、修正完了が確認できれば自動的にログインできない状態にする

このように、本来手動で行う必要のあった業務を自動で行えるように工夫しています。
担当者の負荷の削減にカスタマインも貢献しています。

課題2：保守性の低さを解消し、市民開発が進む環境へ

従来、同社ではkintone導入初期に構築されたアプリの多くがJavaScriptでカスタマイズされており、業務に合わなくなった機能があっても簡単に修正できないという課題を抱えていました。保守の難しさから改善に踏み切れず、使いづらさを抱えたまま運用を続けていたアプリも少なくありません。

機能は損なわずに可能な限りカスタマインへ置き換え

そうした中で、今回のプロジェクトではカスタマインを活用し、ノーコードで柔軟にシステムを改善できる仕組みへと移行しました。JavaScriptで構築されていたカスタマイズを、メンテナンスや再利用しやすい形で再構築しています。

機能追加・変更が容易になり業務の変化にも柔軟に対応可能に

これまでのJavaScriptカスタマイズをカスタマインに置き換えたことで、業務の変化に応じて柔軟にアプリの設定や機能を変更できるようになりました。また、JavaScriptでカスタマイズされたアプリはまだ多数存在するのですが、今回置き換えたJavaScriptは各アプリにも共通する機能を多数含んでいます。この置き換えを実現したことにより、これを参考にアールスリーの手を借りずに自分たちでJavaScriptをカスタマインに置き換えていきやすくなったといいます。

「JavaScriptからカスタマインに置き換えたベースのアプリができたのは大きな成果です。市民開発（各部署の担当者がアプリ作成をする）の広がりに合わせて、カスタマイズも自分たちで行いたいという声が挙がっています。カスタマインで置き換えたベースのアプリがあれば、それをもとに各部署で業務に合わせてアプリを変えられます。2024年からはJavaScriptでカスタマイズは一切しないようになっていますが、まだそれ以前に作ったJavaScriptが残っているアプリも多々あるので、これを置き換えていくことで、属人化の解消が期待されます！」（竹内氏）

kintone担当チームは人数も限定的で、定期的な異動で人の入れ替わりもあります。その中で、高度なJavaScript開発スキルを継承しながら、JavaScriptを含むアプリの改修や業務改善を進めていくのは難しい状況だったそうです。
そうした中で、各部署が自分たちで業務に合わせてアプリを改修できる体制が整ったことは、とても大きな変化です。属人化を防ぎながら、現場主導で改善を進められる体制に、着実に近づいています。

開発の鍵：声を聞き、業務に寄り添い、スピードを生む

今回のプロジェクトでは、現場・システムグループ・アールスリーの三者が連携し、現場を巻き込む形で開発を進めていきました。
実際に業務でシステムを使う現場のメンバーにも初期の打ち合わせ段階から参加していただき、利用者視点での意見を反映しながらプロジェクトを進行。現場を知るメンバーが参加したことで、ちょっとした思い違いや手順の抜け漏れにも気づきやすく、スムーズな開発につながりました。

「現場のメンバーが前向きに参加してくれたことが成功の要因の一つです。システムを実際に使う人が“こうしたい”という要望を積極的に出してくれて、ありがたかったです」（竹内氏）
利用者の視点が初めからプロジェクトに組み込まれたことで、業務にしっかりフィットする仕組みを作ることができました。

同社とアールスリーのコミュニケーションも非常にスムーズでした。進捗状況や仕様のすり合わせなどは、図解や表、アプリ内でタイムリーに共有され、やりとりに滞りはありませんでした。当初半年程度かかると思われていた今回の開発も、実際には約3か月で完了。お互いのレスポンスが早く、スピード感あるやりとりがプロジェクトのスムーズな進行を後押ししました。

業務知識がない状態からスタートしたアールスリーでしたが、業務の流れを一つずつ丁寧にひもとき、業務全体を捉えた開発を進めていきました。
「システム外を含めて誰が・いつ・何を行っているのか、そしてシステムはどのタイミングでどのような目的で操作するのかを意識することが、すごく大切だと思っています」（アールスリー 田邊）
複雑な業務構造に対しても、単に仕様を受け取って作るのではなく、その背景や目的まで掘り下げて理解する姿勢がありました。
「なんでこんなことをする必要があるんだろう？と、まずは社内で話し合います。わからないところはそのままにせず、ちゃんと聞いて解決し、業務を理解してから開発を進めていくのがアールスリーの特徴です」（アールスリー 大澤）
「業務を理解して、使ってもらえるシステムにしたいです。これでいいのかな…と迷いながら渡すのではなく、自信を持って提供できるように、地道に整理しています」（アールスリー 鈴木）

こうした丁寧な対話と理解の積み重ねが、業務に本当にフィットするシステムを生み出す基盤となっています。

「私も自分が知らない業務をアプリにすることがありますが、言われた通りに作ってしまうこともありました。でも本来は、ちゃんと業務を理解したうえで作るべきです。そういう意味でも、今回アールスリーにお願いして本当によかったと思っています。愚直に、地道に整理していくことが必要なんだと実感しました」（前田氏）

展望：市民開発でつなぐ、業務改善のこれから

今回のプロジェクトを通じて同社では、技術的にも業務的にも大きな一歩を踏み出すことができました。とくに、大きな業務システムを任せられる信頼できるパートナーが見つかったことは、長年悩んでいた課題の解消につながる大きなきっかけとなったといいます。

「JavaScriptからカスタマインに置き換えたベースのアプリができたことで、市民開発に対応しやすくなりました。すでに2024年度からはJavaScriptを使わない方針にしていますが、今後もさらにシンプルなアプリ開発をしていきたいですね」（竹内氏）

一方、基幹システムの刷新も並行して進められている中で、基幹システムに乗せきれない機能や個別業務については、kintoneでの対応が求められる場面も増えてきているそうです。
「できないこともあるとは思いますが、できることはどんどんkintoneでやっていきたいと思っています。その際にはまたアールスリーさんの力を借りられると嬉しいです」（前田氏）

まだJavaScriptでカスタマイズされたアプリも多く残っており、ガスの開栓業務のシステムなど対応が必要なものがあります。こうしたアプリの見直しも含めて、今後も現場と連携しながら業務に合ったアプリを自分たちで作れる環境を整えていきたいといいます。

「今回のプロジェクトで、すでに期待以上のものを得られたと感じています。この関係性のまま、これからも一緒に進めていけたらと思っています。業務フローの整理の仕方や、開発のノウハウも引き続き教えてもらえたらと思っています！」（前田氏）

信頼できるパートナーとともに取り組んだ今回のプロジェクトは、単なる業務改善にとどまらず、これからの業務を支える体制づくりの土台となりました。同社では今後も現場とともに、着実に業務改善の幅を広げていきます。

取材2025年3月

アールスリーでは、本案件のようなkintoneアプリの開発や内製化に繋がる構築支援サービスをメニュー化し、2024年4月に「キミノマホロ for kintone」としてリリースいたしました。作業内容やメニューごとの価格体系を載せていますのでぜひホームページでご覧ください。