DXコラム
2024.12.02
システム開発内製化への挑戦【Vol.2】～弊社における内製化の取組とその変遷（後編）～
こんにちは。編集長のP太郎です。
本日は、「システム開発の内製化への挑戦【Vol.1】～弊社における内製化の取組とその変遷（前編）～」に続き、その後編をお届けします。
前編では、様々な苦労を経て、エクセルマクロ開発のSESによる”準内製化”とRPA開発の内製化を果たし、特定の業務工程の効率化に留まらない業務フロー全体での効率化を図った取組についてご紹介しました。本後編では、一定の成果が出たからこそ生まれた新たな課題にどう立ちまわったのか、また、新たな分野（プラットフォーム）での挑戦についてご紹介します。
■ 開発業務内製化Phase３のはじまり
産みの苦しみを経て一定の成果を出せたことでPoCフェーズは完了し、内製化にむけた本格的な体制づくりに着手しました。まず、部長の私がRPAの開発を行っていたこともあり、エクセルマクロ開発をお願いしていたシステムエンジニアにRPAを習得してもらい、担い手を増やしました。次に取り組んだのが、社員としてのシステムエンジニアの採用です。
当時、業務効率化案件が累積している状況であったのと、PoCを経て採算がとれる目途が立っていたこともあり、社内決裁はスムーズに取得できました。が、”伊藤忠”の看板があっても、”保険代理店のIT部門”に好んで応募してくるシステムエンジニアは予想通り、なかなか現われませんでした。そこで、知り合いのシステム会社を頼ってフリーランスの方を紹介してもらったり、過去の仕事仲間にあたって転職を検討中の方を紹介してもらったりし、ようやく１名の若手（本サイトの編集者でもある”唐揚げニスト”です）の採用に漕ぎつけました。（余談ですが、採用活動は一定のスキル評価・人物評価はしたものの、こちらが品定めをする”面接”というよりは、私から、会社のDX戦略やビジョンを語り共感を得るための”プレゼン”に近いものでした。）
この採用をもって、一定の引継ぎ期間を経てSES契約は解約し、エクセルマクロとRPAの開発については完全に内製対応できる体制を整備することができました。１名という限られたリソースでしたが、弊社にとって大きな一歩となりました。
■ 開発業務内製化のマネジメント
話は少し脱線しますが、ここで内製開発の採算性についてお話しします。IT投資の採算性については、 「IT投資の費用対効果はどう測る？」の記事でも紹介していますが、弊社では、システム導入およびその維持にかかるコストに対して業務削減効果が上回っているかを投資判断指標・最終評価指標としています。内製開発についても同様で、システムエンジニアの人件費に対して、業務削減効果が定量的に上回るように案件を執行していかねばなりません。その観点では、最小の労力（開発工数）で最大の効果（業務削減時間）を得る必要があり、案件選定が極めて重要となります。
内製開発における案件選定では、外部委託より開発コストを抑えやすく、採算性がとれる案件が多くなるという側面がある一方で、開発リソースが限られているという側面を考慮する必要があります。どの案件を優先的に取り組むかは、業務削減効果と開発工数の見合いで自然と決まってくるものなのですが、システム開発においては、実現の難易度と業務要件の詳細さによっては、当初の開発工数の見積からずれることがよくあります。
当初の見積どおりに案件推進するためには、①業務パターン（分岐）が多く複雑すぎないか（※）、②業務の主管部署が業務要件を正しく定義できるか（業務フローや手順が可視化されているか）が重要なポイントです。
※業務フローが複雑で属人化しているような業務であれば業務整理（業務手順の見直し・簡素化）を経てシステム化を検討するようにしています。
今ではこのような整理ができているのですが、2019年当時は内製化に着手したばかりでシステムエンジニアを稼働させることに主眼をおいていたため、業務部署から”手間がかかっている”という相談があった案件を次々とこなしていく対応でした。社員として初のシステムエンジニア（当サイト編集者の”唐揚げニスト”）の頑張りもあり、かなりのスピードで案件をこなした結果、通年では高い採算性（単年度ROIで3倍強）が確保できました。
“内製開発の道は”唐揚げニスト”が忍耐と熱量をもって切り拓いた”
■ 嬉しい悲鳴となった新たな課題
内製開発事業として幸先のよいスタートを切ることができましたが、2年目に入り大きな課題が顕在化しました。リソースの問題です。
効率化が図れた業務が増えた結果、初年度後半から相談案件急増し、”待ち状態”となる案件が二桁にも上っていました。さらには、2年目になったことで保守依頼も増え、第二四半期に入った頃には新規案件の着手が初年度の半分程度まで下がっていました。「保険の特約が増えたから処理を追加してほしい」「お客さまからの要望でパターンを増やしてほしい」という類の保守依頼はある程度優先的に対応せざるを得ないため、既存案件の改修にかなりのリソースが費やされる状況が続いていました。そのうえ新規案件が急増したため、対応しきれず社内からクレームが発生する事態になっていました。
そこで考えたのが、既存のエクセルマクロやRPAの保守（軽微な改修）を業務部署に対応してもらうことです。しかしながら、私でもハードルが高いエクセルマクロの改修を業務部署にお願いするわけにもいかないので選択肢から除外。でも、RPAであれば対応できるのではないかと業務部署の担当者を対象とした研修を開催しましたが、その後、開発の担い手として手を挙げてくれる担当者が現れることはありませんでした。業務部署の開発業務への参画はあっけなく不発に終わりました。
（こういう苦い経験を経たため、今年になってからRPAの開発を行った業務部署が登場したことには本当に嬉しかったです）
→ 業務部署による開発【Vol.1】入金消込業務の自動化ツール
→ 業務部署による開発【Vol.2】PDFデータ取得ツール
開発リソース不足が続いていた経緯があり、また、基幹システムの刷新プロジェクトやインフラ領域の運用保守の内製化を計画していたこともあり、段階的に２名のシステムエンジニア（編集者の”傾奇者”と本サイト副編集長の”会津藩士”）を幸いにも採用でき、リソース問題は徐々に緩和され、更なる効率化を目指す体制を整備することができました（この採用の苦労話はまた別の機会に紹介したいと思います）。
■ 開発内製化Phase4としてのノーコード開発の取組
突然ですが、保険代理店に限らず、企業にとって、業務効率化の取組は本当に終わりがないと最近つくづく感じます。現在は、システムエンジニア３名＋非技術者２名の内製開発体制を整備して対応を進めているのですが、未だ案件相談が留まることがありません。
内製開発２年目の年末も同様のことを感じていました。次年度の計画を策定している中で、ふと「このまま永遠にシステムエンジニアを採用し続けないといけないのだろうか」という疑問が浮かんできました。すでにIT部門の人件費が人員増とともに増えている状態だったので、このまま採用を続けていけば”コスト割れ”するリスクが高まることは間違いありません。増え続ける相談、恒常的に発生する保守、これらを人件費の増加なくマネジメントしていくためには、やはり、業務部署の手を借りるしかない、と考え、3年目に入り、システム開発業務の一部を業務部署に担ってもらうことに再度チャレンジする決意を固めました。
そこで目をつけたのは当時導入したばかりのkintoneでした。
kintoneは、技術者でなくてもシステムを”ノーコード”で開発できるクラウドサービスで、開発業務も”開発”というよりは”設定”に近く、文字通りプログラムを書く必要がない”ノーコード開発プラットフォーム”です。
弊社におけるkintone活用の第１号案件は、とある事業部の案件管理業務でした。案件管理業務には、顧客情報・顧客担当者情報・契約情報・案件情報・活動履歴などの情報を管理する必要があり、まずは、それぞれの情報を管理する「アプリ」（エクセルでいうところのシート）を作成しました。次に、アプリ間を紐づけるための設定、期限管理のためのアラートの設定、ダッシュボートの作成・・・などを、マニュアルやサポートサイトを見ながらポチポチと設定を進めました。一部、取引先のシステム会社の手を借りたものの、業務の合間で作業を進め、約2ヵ月間であっという間に完成させることができました。私がRPAを習得したときとは比べ物にならないほど簡単でした。kintoneはそんなプラットフォームです。
またもや自分でトライすることで「このツールであれば業務部署でも対応できる！」と確信を持つことができました。業務部署がメンテナンスできないエクセルマクロをkintoneアプリに移行し、IT部門における保守工数を抑制する、あるいは減らしていく、そして、ゆくゆくは業務部署でも新規のkintoneアプリを開発できるようにする・・・そんな構想が浮かんだのは本取組がスタートしてから3年目の時でした。
■ 業務部署開発の下地作り
とはいえ、すぐに業務部署の開発を推し進めたわけではありません。IT部門としても、どのような業務が移行できるのかの見極めがついていなかったこともあり、ノウハウ蓄積とメンバーのスキルアップを主眼に、まずはIT部門の総力をあげて案件に取り組みました。案件を進めることで業務部署がkintoneに触れる機会が増え、実体験を通じて業務効率化の効果を感じることができるため、業務効率化の推進とともにkintoneの社内プロモーションを展開しました。
具体的には、第１号案件を活用事例として各部署に紹介してまわり、kintoneを活用して業務効率化が図れそうな案件を発掘しました。案件を選定してもらう段階では業務部署の担当者はkintoneの活用余地に懐疑的なスタンスでしたが、IT部門で開発したデモ版を操作してもらったあとには総じて高評価でした。特に、表記ゆれを防ぐ入力チェック機能や期限管理を行うアラート機能、業務担当者同士のコミュニケーションがkintone上で行えるコメント機能が好評で、いずれもエクセルにはない機能でした。
一方、なかなか活用イメージが沸かずに案件選定が難しい業務部署もありました。そういった部署には、kintone活用案件が増えるたびに紹介し、近しい業務をピックアップしてもらいました。また、手間がかかっている業務を洗い出してもらい、IT部門のほうでkintoneを活用できるか精査することも行いました。このような活動を通して多くの業務でkintoneが活用されるようになりましたが、エクセルマクロやRPAの取組と同様に、保守依頼も増えるようになりました。これは想定済みであったため、設定レベルで済むような改修は業務部署で対応してもらうよう調整を進めました。
「システムを作るのはIT部門の仕事」という考え方は一般的ですが、「リソースは、より高い業務効率化効果が見込める新規案件開発に配分すべき」という考え方のもと、業務部署にも協力してもらい、項目の追加といった設定レベルのものから順次対応してもらうようにしました。実際には、業務部署で設定変更を行う際、会議室や担当者席で椅子を並べて同じ画面を見ながら設定を一緒に行う”伴走開発” の形式（業務部署が操作し、IT部門がそれをサポートする体制）で進めました。業務担当者が実際に操作することで設定方法を覚えてもらえるだけでなく、IT担当者が横でサポートすることで効率よく、また安心して設定変更に臨める、という意味でとても効果的な進め方です。
こうして、IT部門においてはリソース配分の最適化が図れ、また、業務部署においてはタイムリーに修正が行えるだけでなく、ITスキルの向上も図れる、という両得が徐々に実現していきました。
■ 業務部署開発の取組は続く
これまでお話ししたように、少しずつ開発業務の内製化を進めてきていますが、まずはIT部門でシステムエンジニアを抱えることの採算性を確保できるかどうか、次に業務部署の協力が得られるかどうか、が大きなポイントとなっています。
“内製開発の採算性向上にはIT部門の保守工数をどれだけ抑えられるかが肝”
また、業務部署の開発業務への参画においては、過去にRPAで失敗しkintoneで少しずつ進展してきていることをふまえると、採用するプラットフォーム（ツール、技術）が重要であることがわかります。
※最近では、ノーコード開発・ローコード開発ができるプラットフォームが多く登場していますが、実際にはノーコード開発・ローコード開発とは言えない代物もありますので、導入には充分なトライアルを行うことを強くお勧めします。
後編は以上です。
次の最終編では、内製化の取組においてなぜ業務部署開発が重要であるかを、リソースの観点以外で考察し、実際に業務部署開発をkintoneで進めている中での開発手法についてご紹介したいと思います。
＞＞最終編に続く（12月中旬公開予定）
＜連載記事＞
Vol.1 弊社における内製化の取組とその変遷（前編）
Vol.2 弊社における内製化の取組とその変遷（後編）※本稿
Vol.3 業務部署による開発の重要性とその進め方
（編集長・Ｐ太郎）
お問合せ先
事例やコラムに関するご照会、案件に関するご相談やお見積は以下のフォームからお問合せください。