【代理店ソリューションメルマガ】2025年10月号をお送りします。
―――――――――――――――――――――――――――――――
１．【保険代理店のToDo管理を自動化】
ＩＮＧ株式会社（旧西日本総合保険） 益田 隆
２．【スクラム開発手法】
成長クラブ 開発担当 栗栖 史匡
３．【保毎掲載】
成長クラブ 尾籠 裕之
―――――――――――――――――――――――――――――――
１．【保険代理店のToDo管理を自動化】
ＩＮＧ株式会社（旧西日本総合保険） 益田 隆
― 大事なToDoが何処かに消えた！をゼロにする ―
いつもお世話になっております。
今回は、保険代理店の皆さまにとって頭の痛い「ToDo管理」の効率化について、弊社がRPAを活用して実践している最新の取り組みをご紹介いたします。
■ 支店が増えると、ToDoも迷子になる？
近年、代理店も複数支店を展開するケースが増えています。
そこに追い打ちをかけるように、保険会社から随時配信されるToDoが全支店合算で届くため、一覧は“てんこ盛り”。
「福岡支店のToDoを久留米支店の人が見ても仕方がない」
「小倉支店分が邪魔をして、大切な自分のToDoを見落とす」
こうして多くの代理店が「ToDo迷子」に陥っています。
しかもこの悩み、どの保険会社の取扱代理店でも同じ。
さらに複数社を扱う乗合代理店では、各社ごとに届くToDoを整理・管理しなければならず、毎日が迷路探検。見落としリスクは倍増します。
■ RPAでToDo管理をフルオートメーション化
弊社では、RPA（WinActor）で次の仕組みを構築しました。
- 毎朝8時、“バッチ”で自動スタート
※バッチとは？…PCの目覚まし時計のようなもの。決まった時刻に、あらかじめ並べておいた作業をまとめて自動実行する“指示書”です。 - 当日の最新ToDoを“プログラム”で自動取得
“プログラム”（＝やることを順番に書いた手順書）が定時に走り、代理店システムから必要なToDoだけを抜き出します。 - SharePoint上にExcelを自動配信
※SharePointとは？…社内向けの安全なファイル置き場＆掲示板です。ブラウザで開けて、支店や担当ごとに閲覧権限を分けられるので、「見せたい人にだけ見せる」が簡単。 - Excelはテーブル化＋スライサー対応
最大1000行までのデータをテーブル化し、支店・担当・保険会社などで瞬時に絞り込み。さらに処理期限の近いToDoは自動で色分けされ、
– 1週間以内 → 赤色
– 10日以内 → 黄色
と一目でわかる仕組みになっています。 - 管理者は全支店を一望
同じExcelで全体把握も可能。支店別と全体像、両方に対応。
■ 実運用の効果
- 「支店ごとに見たい情報だけ出るので、見落としゼロ」
- 「始業時点で最新になっているから、朝の段取りが速い」
- 「管理者は全体把握、現場は局所最適。同じExcelで両立」
- 「期限の色分けで、優先順位が直感的にわかる」
- 「複数保険会社のToDoが混ざっても整列されるので、迷路が一本道に」
つまり、「ToDo迷子」のリスクを根こそぎ解消し、事務効率と安心感を両立できました。
■ おわりに
支店数の増加や乗合化で複雑さが増すなか、限られた人員でToDoを漏れなく回すには、**RPAによる“全自動”**が最適解です。
もし最近「ToDoがどこかに消えた！」と叫んだ覚えがあるなら、それは自動化の合図。
実際のプログラム構成や運用事例はいつでもご覧いただけます。お気軽にご相談ください。
ING株式会社 システム事業部
２．【スクラム開発手法】
成長クラブ 開発担当 栗栖 史匡
大学院の授業でシステム開発手法の一つであるスクラム開発を演習で行ったので、その説明と感想について述べたいと思います。
システム開発手法にはいくつかあり、古典的な開発手法はウォーターフォール型です。
要件定義⇒開発⇒テスト⇒運用
という流れに沿って各段階を厳密に進め、後戻りしない点が特徴です。
途中で仕様を変更することができないため、最初の要件定義が一番重要だと思います。
これまでのシステム利用環境では一旦システムをリリースするとそのあとでシステムを変更して再リリースするのはかなり大変でありリスクを伴うため、このような手法が一般的でした。
しかし、現在はスマホアプリの例にあるように、頻繁にアップデートすることが可能な環境になったため、環境の変化にともなってシステム開発手法も変化してきたわけです。
そこで最近注目されているのがスクラム開発です。
スクラム開発は、
設計（仕様の打ち合わせ）⇒開発⇒テスト
を繰り返し行う開発手法です。システム全体の機能（フェーズ）をいくつかに分けて、その機能（フェーズ）ごとに設計・開発・テストを繰り返して開発を進める手法です。
システムを開発していく中で
l 「ここはこうできた方が使いやすいでのは？」
l 「こんな機能があったらいいのは？」
という改善点が見つかれば、それを次の開発に反映させるという点が特徴です。
この繰り返す単位をスプリントと言います。一つのスプリントの中で設計・開発・テストを行い、その結果を踏まえて次のスプリントの設計を行い、開発・テストを繰り返します。
またスクラム開発ではチームで開発を行います。チームの役割はオーナー・スクラムマスター・開発者（数名）です。
オーナーは
l どのようなシステムを作るのか？
l どのような機能を持たせるか？
l 使い勝手はどうか？
などユーザーの視点に立ってシステムを評価する役です。
スクラムマスターは「司会進行役」です。オーナーが求めている機能を実現するために開発を細分化しタスク化して、開発者にタスクを割り振って開発進捗管理を行います。
大学院の演習は４名のチームでGo（あえて誰も使ったことのない言語を指定）という言語を使ってオセロゲームを開発するという内容でした。
最初のスプリントでは、コマを初期配置する、コマを置く（入力する機能）、裏返す、コマを数えるなどの基本的な機能が意見として挙がり、
それで開発を進めるうちにコマを置くためには、空いたマスかどうかの判定、裏返しできるマスにしか置けない
というゲームルールに対応した判定用関数が必要だという意見が出て、それを実現させるためのタスク化を行いました。
後半のスプリントではゲームをセーブする、コマを画像で表示するなどの追加機能が開発仕様に加わりました。
皆が知らない開発言語だったため、各自で調べながらお互いに教え合いながら開発を進められるかどうかがポイントでした。
確かにチーム内のコミュニケーションはスクラム開発のキーワードです。
教授がシステム開発会社向けにセミナーを開催したところ、超大手M社はこの手法を取り入れているようでしたが、小規模の会社はそうではないようでした。
すべてのシステムでこのスクラム開発が有効であるわけではありませんが、「チーム開発」の重要性を認識できました。
３．【保毎掲載】
成長クラブ 尾籠 裕之
10月から保毎の掲載を始めます。タイトルは「生産性1500万円よもやま話」です。
毎月第3水曜日の10面に載るそうです。10月は15日になります。
今年9月に出版した「生産性1500万円モデルの進展」に関連した話ですが、どちらかというとこぼれ話的なものが多くなりそうです。気楽にお読みください。
僕が進めている生産性1500万円モデル（15モデル）は、業務プロセスのカイゼンで生産性が上がる、という見方をしており、多くの方が関心を持っている商品や、マーケティングや保険会社の戦略といった領域から独立しています。
どちらかというと地道なカイゼンを主体としているため、専門的な話になりがちで敬遠する人の方が多い領域です。
製造業の製造工程に関する領域も、だれもが興味を持ちそうな話題は年に数回くらいしかなく、通常はある程度の知識がないととっつきにくい領域です。どちらにしてもマスメディアやSNSの話題にはなりません。
今回の連載では、15モデルそのものよりも、15モデルの背景にある経験をお伝えしようと思っています。
データベースとか、1回の入力で完結とか、ビジネスプロセス領域がこの50年ほどの間に経験してきた、分かり切ったような話を載せるつもりです。
軽く読んでいただいて、頭の片隅にでも残っていれば日常の業務プロセスを見直すきっかけになると思います。
最後までお読みくださりありがとうございます。
成長クラブHPでソリューションを紹介しています。