左から、CTO 田中さま、弊社担当 里見
iChain株式会社さまは、保険会社・共済向けSaaS型基幹業務プラットフォーム「iChain Base」をはじめ、保険をスマートフォンで一元管理できる「iChain 保険ウォレット／うちの保険」など、保険領域に特化したプロダクトを展開するインシュアテック企業です。
サービスのローンチを経て事業が成長フェーズへ移行する中で、同社が直面したのは「運用・保守が回らない」という深刻な課題でした。開発に集中してきた体制のまま問い合わせや不具合対応が増え、業務は属人化。結果として、新機能開発が停滞し始めていました。
その状況を打開する現実的な選択肢として、iChain株式会社が取り入れたのがフリーランス活用です。
本記事では、CTOの田中様に、当時の課題認識やフリーランス活用の意思決定、そして参画後にどのように開発体制が変化していったのかについてお話を伺いました。
田中さま：iChainは、主に保険会社に対して、保険会社の業務を支える基幹システムをSaaSとして提供しています。
保険契約の管理や、契約者の状況確認、申し込みが入った際の査定・審査、問い合わせ対応といった業務を、システムで支援するイメージです。
従来の金融系システムは、重厚長大で、ベンダーが一から作り上げる高額なものが一般的でした。ただ、私たちが狙っているのは、そうした大規模保険会社だけではありません。
メインターゲットは少額短期保険会社で、たとえば本業が別にある事業会社が「自社サービスに保険を付帯したい」というときに、保険のためだけに大きなシステムを導入するのは難しい。そこで、スタートアップでも導入しやすい軽量なSaaSとして提供することで、コストを抑えながら保険業務を実現できるようにしています。
組織としては、社員は10名強で、業務委託メンバーやオフショア開発も活用しています。「iChain Base」の開発は、基本的に新機能開発を行う開発チームと、制度改正対応やバグ修正、運用継続のための保守チームに分かれています。ただ、当初からこの形だったわけではなく、そこに至るまでに試行錯誤がありました。
田中さま：課題が表面化したのは、業務システムのサービスがローンチして少し経った頃でした。
スタートアップとして「まずは作ってローンチする」ことに集中するのは自然だと思うのですが、当時はまさに開発偏重で、運用・保守体制が社内として整っていなかったんです。
具体的には、保守チームも開発チームも分かれていなくて、お客様から問い合わせが来たら「できる人がやる」という状態でした。役割分担が曖昧なので、対応が属人的になります。
たとえばバグが出ても、今のように管理できていない。障害が起きたときも、原因を分析して次に活かすための手順がなく、都度その場で火消しをする。結果として、同じような問題が再発しやすい状態でした。
そして一番大きかったのが、「できる人」に仕事が集中することです。能力がある人ほど問い合わせやトラブル対応まで抱え込んでしまい、本来進めるべき新機能開発が止まる。サービスを拡張したくても、手が回らない。
このままでは成長のスピードが落ちてしまうので、問い合わせ対応や保守メンテナンスを担う人と、新規開発を担う人を分けて、責任を分担する体制にしないといけない。ちょうどその検討をしているタイミングでした。
田中さま：まず考えていたのは、保守・問い合わせ対応と新規開発を明確に分けることです。責任範囲を切り分けて、「組織として回る状態」を作らないといけない、という認識はありました。
ただ、採用面においても壁がありました。Wantedlyなどで募集はしていたのですが、応募は来るものの、フィットする人材に出会うのが難しい。
保険会社・銀行など金融系システムの経験者や、いわゆる「お堅めの開発プロセス」を理解している人を探そうとすると、従来の採用チャネルでは限界があると感じていました。
田中さま：一番大きかったのは、「早くこの状態から抜け出さないといけない」という危機感です。保守・運用の負荷が増えるほど、新機能開発が停滞し、サービスの成長が止まってしまう。
正社員採用はどうしても時間がかかりますし、当時求めていたのは、保険・金融系の業務システム経験や、ウォーターフォール的な工程理解といった、ある程度の現場経験が前提となる人材でした。そこを一から育てる余裕は、正直ありません。
だからこそ、フリーランスとして即戦力の方を迎え、まず体制を立て直すという判断が現実的だったと思います。
一方で、不安がなかったわけではありません。もちろんパフォーマンスも気になりますが、それ以上に難しいと感じていたのは、「自社の要件をきちんと伝え切れるか」という点です。
欲しいスキルや経験だけでなく、プロダクトの状況やフェーズ感、どこに課題があるのかまで言語化しないと、そもそも探しようがない。その難易度は高いと感じていました。
田中さま：まず重視していたのは、保険会社のシステム経験、もしくは金融系業務システムの実務経験があることです。
保険の業務ロジックは、設計書やソースコードにそのまま表れます。そこを読み解く「勘所」がないと、立ち上がりに時間がかかってしまいます。エキスパートである必要はありませんが、業務システムの空気感を理解している方でないと、キャッチアップのスピードに差が出てしまうと感じていました。
もう一つは、ウォーターフォール型の工程理解です。世の中ではアジャイルが主流になりつつありますが、業務システムには工程ごとに押さえるべきポイントがあります。単語の意味だけを知っているのと、実際の現場で運用してきた経験があるのとでは、大きな違いがあると考えていました。
当時は工程を一から教える余裕がなかったため、SIer出身などで、要件定義から設計、製造、単体テスト、結合テストまでの流れを理解している方を求めていました。
その前提を踏まえたうえで、保守体制を立ち上げるリーダー、保守の中核、顧客対応のボトルネック解消、インフラ領域の弱点補完など、フェーズごとに必要な役割を整理しながらオファーしていきました。
N.Tさん30代2010年よりエンジニアとしてのキャリアをスタートし、業務系システムの運用保守から開発領域まで幅広く経験。Python（Django）によるバックエンド開発とTypescript（Angular）によるフロントエンド開発の双方に対応できる点が強み。近年はシステムエンジニア兼プロジェクトリーダーとして、メンバーのディレクションやクライアント折衝、採用対応、コードレビューや品質管理などにも携わりながら、自らも開発を担ってきた。
C.Aさん40代COBOLによる基幹システム開発からキャリアをスタートし、大手企業の業務基幹や金融機関向けシステム開発に長年従事。詳細設計からテスト工程まで幅広い経験を持ち、安定性や品質が求められる環境で実績を積んできた。近年はC#を用いた開発を中心に、オンプレミスからAzureへのクラウド移行案件にも参画。PLとしてPMと連携しながら要件定義から実装・テスト・リリースまでを推進できる点が強み。
N.Kさん40代Java（Spring等）環境で10年以上の開発経験を持ち、SESとして多様な常駐案件に参画。特に基本設計から実装工程を得意とし、インターネットバンキングシステム開発では実質的に設計〜実装を一手に担うなど、高い自走力を発揮してきた。法人向け受注管理システムの改修や商品DB整備など、業務変化に応じた改善対応にも豊富な経験を持つ。直近では税務申告システム開発に長期参画し、Javaによる詳細設計〜開発を担当。
Y.Iさん40代エンジニア歴14年。バックエンド開発を起点に、クラウドインフラ設計・構築へと専門領域を拡張してきたフリーランスエンジニア。AWS環境でのインフラ基盤構築やマイクロサービス基盤設計、CI/CDパイプライン整備、TerraformによるIaC化などを得意とする。製造業向けプロジェクトではオンプレからクラウドへのリフトシフトや性能試験を含む基盤全体を担当。直近では人材系システムのインフラ構築にも参画し、DevOps導入を推進。
田中さま：最初は、開発と保守を分けたいという話があり、保守側を立ち上げる必要がありました。そこでN.Tさんには、保守側リーダーとして「組織を一緒に作ってほしい」というミッションをお願いしました。
当時の開発状況を見てもらい、課題を一から洗い出してもらって、計画を立てながら段階的に改善していく。まさにゼロから体制を構築していく役割でした。
C.Aさんには、保守チームの中核として参画いただきました。保守と開発がほぼ兼任のような領域もあったため、経験値のある方に入っていただけたことは非常に大きかったです。
その後、開発が進むにつれて保守の負荷が増え、お客様対応がボトルネックになってきました。そこで「窓口専任部隊」を立ち上げることになり、N.Kさんに顧客対応専任として入っていただきました。
Y.Iさんには、インフラ領域の弱点補完として参画いただきました。インフラ人材は正社員採用が難しく、定着もしづらい領域です。だからこそ、経験者をできるだけ長期間確保したいという狙いで、インフラの土台づくりをお願いしました。
田中さま：N.TさんやC.Aさんは、サービスのためになることを自分から発信してくれる方々です。「ここはまずいから直した方がいい」といった指摘や提案が自然に出てくる点は、本当に優秀で、とても助かっています。
N.Kさんは、顧客対応の領域からサービスの弱点を捉え、ツールを作るなど改善を進めてくれており、自主的に動ける人材だと感じています。Y.Iさんはインフラという継続性が重要な領域において、安定運用に向けた基盤づくりを進めてくれています。
田中さま：最初に取り組んだのは、現状を可視化し、課題を整理することでした。
N.Tさんが中心となって、「どこに課題があるのか」を一から洗い出してくれました。これは当時の資料としても残っており、後から振り返れる形になっています。
そこからは、いきなり理想論を押し付けるのではなく、計画を立てて一つずつ解決していきました。段階的に是正していくことで、保守が組織として回る状態を作っていった形です。
また、ボトルネックが移動するのに合わせて体制を組み替えたのも重要でした。開発が進むと保守負荷が増え、次に顧客対応が詰まってくる。そこで窓口専任部隊を立ち上げる、といったように、「いま何がボトルネックか」を見ながら必要な役割を追加していきました。
田中さま：一番大きな成果は、やはり「組織化されたこと」です。
バグ発生時の手順や障害分析、開発フロー、各工程の作業手順やルール、責任範囲、役割分担など、以前は明確でなかった部分が整理されていきました。
その結果、新しく参画するメンバーも、既存のルールに沿って動くことでオンボードできるようになりました。何もない状態から入るのと、型がある状態で入るのとでは、立ち上がりのスピードがまったく違うと感じています。
また、組織化が進んだことで、働き方の柔軟性も両立できるようになりました。タスクと期限が可視化されているため、家庭の事情などで途中離席があっても、どこでカバーするかが分かる。結果として、「自分の裁量で進めてよい」という運用が成立してきたと思います。
コミュニケーション面でも、始業前にチャットで軽く集まり、「このあと少し話したい」といった声掛けからMeetやZoomで短時間のすり合わせを行うなど、必要なときに対話する文化が定着しました。テキストだけに偏らないコミュニケーションへ変化したのも大きなポイントです。
田中さま：フリーランス活用という手段そのものよりも、プロパートナーズさんが「きちんと向き合ってくれた」ことが大きかったです。
他社さんともお話ししたことはありますが、「要望を聞いて、条件に合う人を提案する」という動きが中心という印象でした。もちろん、それはそれで整備された仕組みだと思います。
ただ、私たちにとって難しかったのは、「要件を伝え切れないこと」でした。テキストだけで伝えた内容が、本当に意図どおりに届くとは限らない。私たち自身も未熟で、言語化が甘い部分があったと思います。
その点、プロパートナーズさんは、こちらが伝えきれていない部分を拾い上げ、疑問を持って掘り下げてくれました。求人票のテキスト化だけでは伝わりにくいニュアンスを、対話を通じて明確にしてくれたのがありがたかったです。
当社の前任者も「Hajimariが一番熱心にやってくれるから、付き合いを続けた方がいい」と話していたのですが、実際に私たちも同じ感覚を持っています。
また、直接応募型の媒体だと、要件が整理しきれていない段階ではミスマッチが起きやすいと感じています。間にエージェントが入り、要件の整理と事前フィルタがあることで、面談の質が担保される。そこは大きな価値だと思います。
田中さま：採用に悩んでいる企業は多いと思いますし、フリーランスというと「ドライな関係になるのでは」と感じる方もいるかもしれません。
でも実際には、N.TさんやC.Aさんのように、サービスのためになることを自主的に発信してくれる方もいます。フリーランスであっても、熱量を持って一緒に仕事ができる人はいると感じました。
だからこそ、まずは一人でも二人でも、試してみることが大切なのではないかと思います。
正社員の理想像を待ち続けてスピードが落ちるくらいなら、スモールスタートで試し、状況を見ながら判断していく。フリーランス活用の良さは、そこにあると思います。
また、長期稼働のメンバーがいるほど、「いつまでも同じ体制が続くわけではない」という前提で、バックアップ候補を確保しておく必要も感じています。家庭の事情やキャリアの変化は自然なことですから。
保険・金融領域の経験者とこちらから繋がれる確率は決して高くありません。その点で、必要に応じて候補者をピックアップしていただけるのは、とてもありがたいですね。
iChain株式会社さまがフリーランス活用に踏み切った背景には、ローンチ後に明らかになった運用・保守体制の未整備や属人化、そしてそれに伴う新機能開発の停滞がありました。
そこで同社は、保険・金融領域の経験や工程理解を持つ即戦力を迎え入れ、保守体制の立ち上げや顧客対応のボトルネック解消、インフラ面の弱点補完へと、フェーズに応じて役割を広げていきます。
最大の成果は、バグ対応や開発フロー、役割分担を標準化し、誰が参画しても回る「組織としての型」を築けたことです。さらに、要件の言語化から伴走するパートナーの存在がミスマッチを減らし、体制づくりを着実に前進させる原動力となりました。
フリーランス活用は単なるリソース補填にとどまらず、成長フェーズにおける課題を整理し、開発体制を整えていくための有効なアプローチともいえます。
