DXコラム
2024.12.16
システム開発内製化への挑戦【Vol.3】～業務部署による開発の重要性とその進め方～
こんにちは。編集長のP太郎です。
システム開発の内製化シリーズもいよいよ最終章となりました。【Vol.1】では弊社の内製化の始まりと苦労の変遷を、【Vol.2】ではkintoneを活用した業務部署主導の開発事例をご紹介しました。そして今回は、「業務部署による開発」の重要性と、具体的な進め方について深掘りしていきます。
DXを加速させたいと考える保険代理店の皆様に、実践的なヒントとなれば幸いです。
■ 業務の分類と採算性の課題
会社には、業務負荷の高い業務から低い業務まで様々な業務が存在しています。業務負荷は「処理時間×発生頻度」で定量化できます。この観点で見ると、次のような傾向が見られます。
・処理時間が長い、または発生頻度が高い業務
→ IT投資効果が得られやすい。
・処理時間が短い、かつ発生頻度が低い業務
→ システム化しても採算が合わない傾向がある。
保険代理店事務の基幹業務は、見積～申込手続き～請求書発行～入金管理～収明記帳～成績管理などによって構成されています。これらの業務は常態的に発生する手順が多いため、システム化をつうじて業務量を大幅に削減できます。また、一連の業務フローにおいて、前工程で作成したデータが後工程に流れるフローとなっている場合には、データの一元管理を確立することで更に高いIT投資効果が見込めます。
一方、例として「月末に１回だけ発生する２時間の集計作業」について考えてみましょう。一見、システム化で効率化できそうですが、仮に２時間の作業が30分に減ったとしても、システム化の対応に20時間かかるようなケースでは採算が合いません。担当者は面倒な作業を何とかしたいと感じるものの、こうした業務はIT投資の優先順位が低くなりがちです。結果として、多くの業務が非効率なまま放置されることになります。
前編・後編をつうじてご紹介したとおり、弊社では、外部委託によるシステム開発では採算が合わない業務を内製開発で対応することによってシステム化を図り、業務効率化と採算性の両立を図っています。しかし、それでも内製開発で対応できない業務が多く残っているのが現状です（弊社の経験則では、会社に存在する７割の業務はこれに該当すると思われます）。これらの業務は、担当者が手作業で対応せざるを得ず、結果として、非効率な業務として”塩漬け”されているのが実情です。
■ 業務部署による解決策
業務が複雑で多岐に亘る保険代理店の課題として、システム化の対象から”見捨てられた”非効率な業務を中長期的に解消していく必要性は極めて高いといえます。外部委託もできず、IT部門にも頼めない業務だからといってそのまま放置してしまっていては効率化は図れません。よって、業務部署が自ら開発を担うことが一つの有効な解決策となります。
業務部署による開発の最大の強みは、要件定義の負担軽減です。通常、IT部門や外部委託先との打ち合わせを重ねて要件を固める必要がありますが、担当者自身が開発することでこのプロセスを大幅に簡略化できます。
例えば、「要件定義に時間をかけるより、実際に作りながら調整したほうが早い！」というケースも少なくありません。
また、業務部署が自ら開発に取り組むと、業務整理が進むという副次的な効果も得られます。外部にシステム開発を依頼する場合、現行業務をそのままシステム化する依頼をしてしまいがちです。しかし、担当者が自分でシステム化を検討する際には、「無駄な手順はないか」「もっと簡素化できる手順はないか」といった視点で業務を見直す機会が生まれます。これにより、自然と効率的な業務フローの実現につながるのです。
業務部署による開発を実現するためには、業務担当者でもスキルが習得しやすいローコード開発プラットフォームの採用と、業務担当者がスキルアップするためのサポートが不可欠です。弊社ではローコード開発プラットフォームとして様々な業務システムに対応できるkintoneを採用していますので、kintoneで業務部署が業務システムを開発する際のサポート形態について次章でご紹介します。
■ 業務部署開発の推進方法
業務の複雑性や業務担当者のスキルなどによって採用する推進方法を変えていますが、大きく２つの方法で業務部署開発を進めています。１つは「伴走支援方式」、もう一つは「開発分担方式」です。比較的簡易な業務フローについては前者を、複雑な処理が入ったりプラグインを多用するような業務フローについては後者を採用しています。
１）伴走支援方式
伴走支援方式では、ミーティング形式でIT担当者が業務担当者をリアルタイムでサポートします。同じ画面を見ながら操作のアドバイスを行い、業務担当者が不明点や”つまづき”をすぐに解消できる仕組みです。
主な特長：
・業務担当者が効率よくシステム設定を進めることができる
・会話を通じて業務課題が整理され、より効果的なフローが生まれる
正直なところ、IT担当者が「自分で設定したほうが早い」と思う場面がほとんどなのですが、業務担当者のスキルアップを目的とした”未来への投資”と考え、伴走支援を重視しています。
伴走支援方式で進めている案件は徐々に増えており、その一部を以下の記事でご紹介していますのでご参照ください。
⇒業務部署によるノーコード開発をkintoneでトライ！（2024.4.30）
⇒業務部署による開発【Vol.3】在庫管理・発注システム（2024.9.30）
２）開発分担方式
もう一つの方式が、業務部署とIT部門のそれぞれの担当者が分担して開発を進める方式です。例えば、以下のような分担が一般的です。
・IT部門：開発の上流工程（アプリ設計やプラグイン導入）
・業務部署：開発の下流工程（簡易な設定やテスト作業）
スキルの高い業務担当者の場合は、上流工程から開発し、プラグインなどの難易度の高い設定がある場合はIT部門が伴走支援する、という開発分担方式と伴走支援方式を組み合わせたサポートも柔軟に行っています。以下がおおまかなステップです。
①業務部署による現行業務の可視化
まず、現行の業務フローをエクセルにフローチャートの形でまとめてもらいます。既存のマニュアルにフローが記載されていればそれで代用します。ここで、業務を減らすために無くせる・変えられる手順がないかを検討してもらい、どの工程でどのような手順に変えたいか文章で記載してもらいます。
②IT部門によるデモ版の構築
業務部署が作成した業務フローと改善箇所をもとに、IT部門がおおまかなシステムフローを作成します。システムフローにはアプリ構成と選定したプラグイン、処理の概要を記載します。当該システムフローにもとづいて、デモ版のシステムを早々に構築してしまいます。要件定義を簡素化しているので細かい作り込みはあえてせず、業務フローの大枠を捉えたシステムを構築し、早い段階で業務部署に見てもらいます。エクセルの管理表から移行するケースがほとんどのため、初期データはエクセルから移行しておきます。
③デモ版のレクチャーと改善点の洗い出し
次の段階で業務部署にデモ版を見てもらい、想定する業務フローの説明を行います。デモ版を使いながら業務手順を進めるなかで、「ここはこういう風にしたい」「ここはこういう処理を追加する必要がある」というような改善点が出てくるので、それをまとめていきます。ミーティングの最後に、洗い出した改善点を業務部署・IT部門のどちらが担うかを決めます。項目の追加やレイアウトの変更などの難易度の低い設定は業務部署が担い、アプリ構成やプラグインの変更・追加など設計部分にかかわるところはIT部門が担います。
③改善点の反映
①②の工程でよほどの認識相違がない限りIT部門における追加作業はあまり発生しないため、本工程では業務部署がメインの作業を担います。業務担当者は、業務フローに照らして実際にシステムを操作しながら業務手順を進め、同時に設定作業を進めます。kintoneの設定スキルが高い業務担当者は自ら作業を進められますが、そうでない業務担当者に対しては伴走支援を行います。IT担当者が担うタスクがあれば、並行して設定作業を進めます。
④システムテスト・業務運用テスト
業務担当者・IT担当者がそれぞれ進めた設定作業のチェックを行います。業務担当者が設定した部分はIT担当者が、IT担当者が設定した部分は業務担当者が確認を行い、そのうえで業務担当者が業務運用テストを行います。業務運用テストは業務担当者が行いますが、IT担当者が同席のうえでメインストリームの業務フローをまわし、細かいところは持ち帰って実施してもらいます。
以上の流れを通じて、業務部署開発を進めています。特に、業務の特性や複雑性に応じて柔軟に手法を選択し、各工程で必要に応じた調整を重ねることがポイントです。保険代理店業務のように多様で複雑な業務フローにおいては、要件定義を完全に固めてから開発に進む従来型の手法では対応が難しいケースも多いため、アジャイル開発方式を採用することで、設定とその確認（③～⑤の工程）を繰り返しながらシステムの完成度を高めていくのが得策です。
以上、３回にわたりシステム開発内製化の弊社の取り組みについてご紹介いたしました。皆さまの会社でのＤＸ推進の一助になれば幸いです。
＜連載記事＞
Vol.1 弊社における内製化の取組とその変遷（前編）
Vol.2 弊社における内製化の取組とその変遷（後編）
Vol.3 業務部署による開発の重要性とその進め方 ※本稿
（編集長・Ｐ太郎）
お問合せ先
事例やコラムに関するご照会、案件に関するご相談やお見積は以下のフォームからお問合せください。