この記事で分かること
- 紙の申請を、強制せずにどうやって画面へ移したのか
- 現場にアプリづくりを任せる前に、何を決めておいたのか
- 自社の紙の申請と改善の依頼で、まず何を数えればいいか
本記事は、各社が公開している導入事例・公開情報をもとに、マクセラスが独自の視点で業務改善の考え方を分析したものです。マクセラスが導入を担当した事例ではありません。
この記事の目次
01Before ─ 課題
紙の申請と現場の工夫は、どこで行き詰まっていたのか
沖縄電力は、離島を含む沖縄県全域に電力を届けるエネルギー会社です(グループ約3,800名)。社内の情報共有には Notes を長く使ってきましたが、サポートの終了を控え、2017年ごろから入れ替えを進めました。
Notes の上には、各部門が自由に作ったアプリが100個以上ありました。名前も機能も重なるアプリがいくつもありました。現場には自分たちで業務を良くしたい意欲があり、Excel のマクロや RPA で工夫していましたが、手元の道具では応えきれていませんでした。申請は紙で、上司が出張していると承認待ちの書類が机に残ったままになりました。
02How ─ 変えたこと
3項目のワークフローを「おまけ」で始めた
新しい基盤には、作り込まれた業務をアプリとして組み直せる kintone を選び、2019年に移行を終えました。そのとき、件名・本文・添付ファイルの3項目だけで、どんな手続きにも使えるワークフローを作っています。順に承認し、差し戻しや分岐もできるので、紙の段階的な承認に慣れた社員にもなじむと考えました。
広め方にも気を配りました。いきなり全面に広げると業務に差し障り、反発も出ると考え、あえて大きく打ち出さず「おまけ」として置き、使うことを一切強制していません。
最初は Notes の反省から現場でのアプリづくりを認めず、情報システム部門とグループの開発会社が作りました。依頼が相次いで追いつかなくなった2023年に解禁し、勉強会でアクセス権の扱いを徹底して教えています。受講は延べ約400名で、日常的にパソコンで働く社員の約半数です。扱う情報に応じて作れる領域を分け、アプリづくりは申請制にしました。
マクセラスの解釈
紙をなくした中心は、現場の開発より前に置いた、3項目だけの汎用ワークフローです。強制せずに置いておき、使われてから広げたことが、紙の書類を画面へ移した要だと当社は読んでいます。現場への開発の解禁は、そのあと統制を決めてから行っています。
業務の流れの前後
- 01紙で申請
- 02上司の机へ
- 03出張中は止まる
- 04順に押印
4工程。タブで変えたあとと見比べられます。
BEFORE
- 01紙で申請
- 02上司の机へ
- 03出張中は止まる
- 04順に押印
AFTER
- 013項目で申請
- 02順に画面で承認
- 03差し戻し・分岐
- 04現場がアプリ化
出典に書かれている役割の分け方
機械に任せたこと
- 申請を承認者へ順に回し、差し戻しや分岐を処理する
人に残したこと
- 情報システム部門
- 作れる領域とアクセス権を決め、助言を求められるまでは口を出しません。
- 現場の担当者
- 申請制のもとで、自分たちの業務のアプリを作ります。
03After ─ 結果
書類業務はゼロに。現場のアプリも広がった
承認にかかる日数は多くの場合で半分以下になり、上司の机で書類が止まることもなくなりました。年6万件の書類業務がゼロになり、1万5,000時間の業務時間を減らしています。汎用のワークフローが定着したあと、厳格なルールのある正式な稟議もアプリになり、グループ会社にも広がりました。
現場の開発でも成果が出ています。電話と紙のカレンダーで管理していた約30台の共有車両の予約をアプリにし、年6,000件を超える予約をさばきながら、電話と集計の時間を年に数百時間規模で減らしました。
- 電柱の建て替え工事の調整
- 年間300時間程度を削減
数字の出どころ
サイボウズが公開した沖縄電力株式会社の事例による数値です(2026年6月取材)。冒頭の書類の件数と削減時間は、全社の汎用ワークフローに限った数値です。共有車両の予約管理(年間数百時間規模)や工事の進捗調整(年間300時間程度)は別業務の数値で、上記の内数ではありません。削減時間の側には「年間」の語は付いていません。
04自社への応用
自社の紙の申請にも、同じ止まり方はないか
ここからは、出典の事実をもとにしたマクセラスの解釈と提案です。
この事例の要は、どんな手続きにも使える簡単な入口を強制せずに置き、統制を決めてから現場に作る範囲を広げたことです。
- 紙の申請が残る
- 承認のために紙が社内を回り、出張や不在で止まる
- 情シスが少人数
- 現場からの依頼がたまり、着手まで数ヶ月かかる
- 現場に詳しい人がいる
- 表計算のマクロで自作しているが、その人しか直せない
- 古い基盤を使っている
- サポート終了が近いが、載っている業務が多くて動けない
まず何を調べるか
まず1か月、紙で回っている申請の件数と種類を書き出してください。種類がばらばらでも、件名・本文・添付で足りるものが多ければ、1つの汎用の申請から始められます。あわせて情報システム部門への依頼が着手までに何日かかっているかを数えると、現場に任せる範囲を考える材料になります。
マクセラスの解釈
入口は簡単に、統制は先に決める。
現場が自分で作れるようにすると、情報システム部門の人数という上限が外れます。私たちも、作れる領域と権限の決まりを先に置き、勉強会を1回で終わらせず続けながら、任せる範囲を広げることを勧めます。
05まとめ
まとめと参考資料
- 紙の申請が上司の机で止まり、現場の工夫はばらばらのアプリやマクロに散っていた
- 3項目の汎用ワークフローを強制せずに置き、統制を決めてから現場の開発を解禁した
- 自社では、紙の申請の件数と種類を1か月書き出すところから始める
参考資料
- 沖縄電力株式会社 導入事例サイボウズ(kintone)・2026-10-11 確認原文を見る ↗
掲載している数値は、各出典が公開している報告値です。当社が測定したものではありません。 図や表は、出典が公開している事実をもとに当社が独自に作成しており、出典の図版は使用していません。
本記事は、各社が公開している導入事例・公開情報をもとに、マクセラスが独自の視点で業務改善の考え方を分析したものです。マクセラスが導入を担当した事例ではありません。

