【DX推進】基幹システムの自社開発！『MERP』の成功事例と改革の裏側
内製化
濱松 みのり
2025年03月03日
デジタルトランスフォーメーション（DX）を成功させるためには、基幹システムの内製化が鍵となり、近年、多くの企業が「基幹システムの刷新」「DX推進のためのERP導入」「クラウド活用」に取り組んでいます。
メンバーズはその課題に対し、外部委託に頼らず自社のエンジニアでの開発を選択。その結果生まれたのが、画期的な基幹システム「MERP（Members Enterprise Resource Platform）」です。
本記事では、MERP開発責任者の山本真義と執行役員の大友卓を中心に、開発秘話、技術的工夫、運用の実態を深掘りし、メンバーズ最大の社内プロダクトであるMERPの価値についてお届けします。
また、開発やデザインに携わっているメンバーの声を通じて、MERP（メルプ）がもたらした組織的な変革についてBEMA Lab編集部の濱松が詳しく探ります！
山本 真義（写真：右）
MERP開発責任者。メンバーズ入社後はエンジニアチームの立ち上げやプロジェクト推進を担当。
大友 卓（写真：左）
執行役員・VPoE（Vice President of Engineering）。エンジニア組織を牽引し、エンジニア文化の醸成に貢献。
基幹システム『MERP』とは？
『MERP（Members Enterprise Resource Platform）』は、メンバーズが2020年に内製で開発を開始した基幹システムです。このシステムの目的は大きく3つあります。
- 情報の統合による経営判断の迅速化
- 業務の効率化を通じた生産性向上
- テクノロジー活用によるDX推進
当初は業績管理・集計ツールである「FORECAST」から開発をスタートしましたが、その後4年間で徐々に領域を広げ、現在、MERPは15のプロダクトを展開し、提案から納品までの案件管理はもとより、社内で行われる業務の大半をカバーしており、社内では「MERPなしでは仕事が成り立たない」と評価されています。
MERPのロゴに込められた意味
ロゴには、メンバーズのコーポレートカラーである赤と青を使用しており、赤い部分が”社員(人)”、青い部分はMERPを表しています。
この形によって、人が頑張っても”足りない・失敗しやすい・非効率”といった部分をシステムが補完していくことで、メンバーズグループが目指す組織形態である”まるい組織”を実現していくという意味が込められています。
外部委託ではなく自社開発を選んだ背景と課題
大友：MERPを開発するきっかけとなった社内の課題やニーズは何ですか？
山本：当時はASPやSaaSを組み合わせていたのですが、提案・案件管理・稼働管理が分断され、多くの手作業が発生し、業務全体の効率化が進まない状況でした。また、データも分散していて、有効に活用できない状態になっていました。今後の成長のためには、これらを解消する必要がありました。
その経験から、当社の複合的なビジネスモデルにフィットし、変化にも対応していくために、MERPは自社開発でスタートしました。
大友：内製での開発を選んだ理由について教えてください。
山本：既存システムの課題感にも通じる部分ですが、このシステムはいかにメンバーズの業務にフィットさせるかが肝でした。契約形態が異なる受発注業務の横断的な管理など、メンバーズの目指すミッション・ビジョンをしっかり理解したうえで、変化に柔軟に対応できなければ、新しく作る意味がありません。
また、この構築を通し、社員の育成基盤とするとともに、DXに関するナレッジをしっかりため、社内に還元していくという目的もありました。
これらを実現するために、長期的な視点で柔軟性と効率性を兼ね備えた自社開発を選択しました。
大友：社内の勉強会で1時間にわたり、濃いナレッジを共有していましたね。
MERP開発の苦労と工夫：トライアンドエラーで成功を掴む方法
大友：MERPの開発初期において、特に苦労した点や課題は何でしたか？また、システムの正確性を高めるために行った工夫などあれば教えてください。
山本：開発初期は、気合いと根性の連続で、トライアンドエラーの積み重ねでした。私自身、現場でマネージャーもしていましたし、知識はあるほうだと思っていましたが、全然浅かったですね。
各種指標の計算に関しても、法律や社内運用上のルールが絡んできます。例えば、稼働率の計算でも、有休や特別休暇といった多様な勤怠、稼働登録されるタイミング、公式のルールと実際の運用の差を考慮しながら、予定と実績でどのデータを用い、加工し、計算するかを考慮する必要があり、正確なデータを反映するために計算ロジックを何度も見直しました。また、法律や経営方針との整合性を担保することも重要で、エンジニアだけでなく、関係者全員で膝を突き合わせて議論を重ねました。
大友：特に難しかったポイントを教えてください。
山本：MERPは業務に密接に関わるシステムなので、主に昼間に使用され、夜間はほとんど利用されません。また、月末月初の月次決算期には、特にアクセスが集中します。その中で、各種データの集計・連携を高速に実現していくために、マイクロサービスやPubSubによるデータ連携の仕組みを作りましたが、これが不整合や過負荷の原因になったりすることがあり、この勘所をつかむのが特に難しかったですね。
今だから言えるしくじりとは？
大友：今だから言えるしくじりがあれば教えてください。
山本：データの整合性について、開発初期には多くのミスがありました。例えば、データ集計時にプラスとマイナスが逆になっていたりしたことです。とても初歩的ですが、根本的には勘定科目の分類や複式簿記における勘定科目の借方・貸方の取り扱いを間違えていたことが原因であり、正確に作るには簿記の知識が関係してきます。最初はこうしたミスを見逃すこともありましたが、発覚するたびにチーム全員で原因を突き詰め、徹底的に改善を繰り返していきました。
大友：それは大変だったでしょうね。具体的にどのようにその問題をチームで解決したのですか？
山本：関係者と密にコミュニケーションを取り、しっかり根底にあるルール(ドメイン知識)を理解した上で実装・修正をするように意識していきました。また、トライアンドエラーを根気よく続けた結果、チームに知見がたまり、システムの安定性を確保することができました。
このようなシステムの開発では、実際業務を行っている人(業務担当者)にとっては当然の知識・ルールでも、私たちエンジニアには存在すらわからないことが多々あります。一方で、エンジニアにとっての当然であるシステム的な考え方は、業務担当者にはわかりません。そういった中で、お互いに根気強く、齟齬を埋めていくのがとても大切な過程でした。
そして、この取り組みが現在ではチームの文化となり、システムの精度を高める基盤となっています。
ここからは、2017年入社のデザイナー・西見美里と、2022年入社のエンジニア・千綿政幸に、MERPチームで直面した課題や、それを乗り越えた工夫について伺います。
エンジニアとデザイナーが語る、MERP開発の現場エピソード
大友：デザイン面で苦労した点や、それを克服するための工夫について教えてください。
西見：社内には3,000人以上の利用者がいて、それぞれ多様なユースケースを持っています。この幅広いニーズに対応することがデザイン面での大きな課題でした。そのため、業務効率化を最優先し、操作が複雑になりすぎないよう、直感的なデザインを心がけました。今後もメンバーズに寄り添った基幹システムで在れるように、デザインの力で多くの課題を解決しながら、引き続きブラッシュアップを重ねていきたいです。
大友：開発中に発生する課題やトラブルにどのように対応していますか？
千綿：課題を迅速に解決するため、テレビ会議システムを常時接続して、業務中にディレクターやエンジニアと即時にコミュニケーションを取りました。また、仕様書も様々な職種が意見を出し合いながら協力して作成し、ディレクターが全体を管理することで、チーム全員で随時更新を行う仕組みを採用しています。
マイクロサービスとクラウド活用：MERPの技術的成功要因
大友：MERP開発で採用した技術や設計のポイントについて教えてください。
山本：MERPは、マイクロサービスアーキテクチャとクラウド基盤を活用することで、高い柔軟性と拡張性を実現しました。例えば、月末月初には約2,800人が一気に稼働登録がしていますが、クラウド環境（特にCloud Run）の自動スケーリングのおかげでスムーズに対応できています。
また、UI設計にも力を入れ、新卒採用が多く、セルフ化を推進している当社の特性に鑑みて、新卒社員でもマニュアルを見ずに8割は使えるよう、直感的な操作性を重視しました。基本的なことは見ればわかる。使い込むためにマニュアルを見るという線引きを大切にしてます。
大友：技術選定で他に重要だったポイントは何ですか？
山本：スケーラビリティと保守性が重要でした。業務要件が変化した場合でも、柔軟に対応できる設計を心がけ、将来を見据えた技術基盤を構築しました。特にマイクロサービスアーキテクチャは、分割粒度としては、”業務ごと”と多少大きめではありますが、その結果、業務要件の変更や追加に対して柔軟に対応していくことができています。またすでにリプレイスされたプロダクトもいくつかありますが、そのたびに、新しい言語や技術を採用することができています。
保守性の面では、”クラウドサービスをレンタルサーバーの延長にしない”というコンセプトで、マネージドサービスを積極的に活用しています。その結果、設定のチューニングや調整が自動化されたり、障害リスクが低減し、15ものプロダクトを少人数で運営できる基盤になっています。今ではエンジニアの人数よりプロダクトのほうが多くなっています。
エンジニアが成長する組織づくり：チームの人材戦略
大友：MERPの開発において、チームづくりや人材育成の面でどのような工夫をされましたか？
山本：このチームは公募を中心に集まったメンバーです。そのため、コーダー等からのキャリアアップとして参画してもらうことも多く、当初はエンジニアとしての経験が浅いメンバーが中心でした。そのため、それぞれの経験を踏まえつつ、まずは簡単なタスクから始めてもらい、徐々に担当領域を広げて、スキルを伸ばせるようにするなど工夫をこらしました。
ある程度経験を積むと、新規プロダクトの立ち上げを担当してもらいますが、この際にもマイクロサービスを導入しているからこそ、一から作る経験を積めますし、その時に新しい技術や言語を採用するなど、チャレンジもできる良い機会となり、スキルアップに大きく寄与しています。
その結果、当初は経験の浅かったメンバーも、現在は自立してプロジェクトを推進したり、後輩を育成できる人材になっています。
これらの成果は、仕組だけでなく、メンバーが自発的に考え、いろいろな知識・スキルを身に着けるための努力を続けた結果、実現できたものです。いろいろ困難な局面があった中でも、継続して行動してくれたメンバー・関係者には感謝しています。
今後は、各メンバーが自分の専門分野を伸ばしてらい、協力してチームを支え、”まるい組織”によって、システムの安定運用と進化を支えていきたいと思っています。
ここからは、MERP開発チームの成長を象徴するエピソードに焦点を当てます。実際に開発に携わった、デザイナー・西見美里と、エンジニア・千綿政幸が自身のキャリアや技術の面でどのように成長したのか語ります。
エンジニアとデザイナーが語る、MERP開発の成長エピソード
大友：MERP開発チームで技術的・キャリア的に成長したポイントを教えてください。
西見：経営方針から現場の細かいオペレーションなど、会社の成長に沿った解決力を俯瞰的な視点で培うことができました。組織の理解の部分について、日々勉強になっています。
千綿：設計からリリースまでの一連の流れを経験できたことが大きな成長ポイントです。同年代のエンジニアと比べると、ディレクターや営業など幅広いメンバーとのコミュニケーションを経験できた点がとても良かったです。
15のプロダクトで業務を支える、MERPが実現した運用効率化事例
MERPは現在、現場部門からバックオフィスまで多くの部門で活用されております。
大友：MERPが社内にもたらした具体的な成果や変化について教えてください。
山本：MERPは多くの部門に浸透しています。商談・提案段階から販売管理、稼働管理、業績の可視化までを統合的にサポートすることで、業務効率と精度が大幅に向上しました。具体的には、1日1回だった業績集計が即時になったり、1日3回だった打刻の同期が即時になった結果、稼働の締めが早期化するなど、小さいけど大きな変化がたくさん起きています。
システムとして実現していることは当たり前の小さい事でも、積み重なって経営判断の迅速化や業務生産性の向上に寄与できています。
また、各方面からの要望に対し、定期的なリリースサイクルを実現し、フィードバックをもとにした継続的な改善サイクルを回しています。
MERPの未来：人事労務やデータ活用で進化するDX推進のビジョン
大友：MERPの今後のアップデートや発展に向けた構想があれば教えてください。
山本：今後はデータウェアハウスを中心としたデータ活用基盤構築や、取引先管理の高度化・人事労務領域への展開、そして既存システムの改修・アップデートを進める予定です。また、個人的にはシステムに『エモさ』を加え、業務を進めるだけでなく、利用者が親しみやすい環境を提供したいと考えています。
また、システムを進化させる際には、新機能の追加だけでなく、組織全体の課題解決やユーザーの期待に応えることをも重視し、これまでの経験を活かしながら、常にチャレンジを続け、DXの先進事例となるようなシステムを目指していきたいですね。
アドバイス：社内アプリ開発で失敗しないための重要な心得
大友：社内アプリ開発やDX推進を目指す企業に向けて、アドバイスをいただけますか？
山本：まず、会社を動かす仕組みというのは、関係者それぞれの立場によってとても多くの思惑や制約が絡んでいます。そして、すべての領域にはそれぞれ専門知識やノウハウがあります。お互いに見ているものや範囲が違う中で、完全に理解し合うことはほぼ不可能です。
大友：確かに、すべての領域を完全に理解するのは難しそうですね。その中で、どのように進めていけばよいのでしょうか？
山本：相互理解は大事ですが、落としどころばかりを探していると、使いづらいシステムになってしまいます。それを防ぐためには、それぞれの立場・役割を超えて、各領域のプロフェッショナルとして、未知の部分にもしっかり向き合うことが大切です。
具体的には、会社全体として目指しているミッションやビジョンを深く理解し、各領域が果たすべき役割を明確に定義し、互いを尊重する姿勢が必要です。その土台があって初めて、全体の目標に向けた実現可能なシステムを構築することができると考えています。
この土台を作る過程はとても難しく、険しく、根気が必要ですが、そこをしっかり作れるかどうかが、DX推進の勘所ではないかと思います。
まとめ
MERPの開発と運用の成功は、メンバーズが誇るエンジニアリング力とチームの結束力の賜物です。15ものプロダクトを安定して提供し、社内の基盤として欠かせない存在に成長したMERP。その背景には、チームの卓越したスピード感と専門性がありました。
また、メンバーズが持つ独自の企業文化――若手が積極的に挑戦できる環境――にも改めて感銘を受けました。例えば、MERP開発においても、経験の浅いメンバーがチーム内でスキルを磨き、新たなプロダクト立ち上げを担当するまでに成長する機会が用意されています。ひとつ上の環境で挑戦する姿勢は、個々の成長を促し、組織全体を前進させる原動力となっています。この文化がMERPの成功を支え、未来へつなげる原動力になっているのですね。
MERPは社内開発ですが、プロダクトオーナーを社内の主管部門と見立てることで、メンバーが社外のお客様と同等の緊張感を持ちながら取り組むことができています。また、自社内で使用することを想定することで、メンバーが主体的に取り組むことができている印象でした。社内プロダクトとなると、曖昧になりがちですが、メンバーズでは大枠の方針や優先順位を明確に設定し、社外プロダクト開発と同等の取り組みを行っています。その結果、社内外を問わずプロジェクトを推進できる人材が育っています。
メンバーズは全社の使命としてーーDX現場支援を通じて顧客と共に社会変革をリードするーーを掲げ、さらにエンジニア事業では「開発現場から世界を変える」というスローガンを実現すべく活動しています。エンジニアリング事業では、フロントエンド、バックエンド、クラウドインフラまで、幅広い技術領域に対応。さらに、アジャイル開発やスクラム手法を活用し、専任チームを編成することで、顧客企業とともに成長する柔軟かつ持続可能な開発体制を構築しています。こうしたスローガンや理念が、MERPの成功という具体的な成果につながった一例です。
今回の取材を通じて、MERPという社内プロダクトの全貌を掘り下げることができたことは、本当に貴重な体験でした。「開発現場から世界を変える」というスローガンに共感し、メンバーズのエンジニアリング文化をより多くの方に知っていただければ幸いです。本記事が、自社開発やプロダクト成長を目指す企業さまに、新たな視点や気づきを与えるきっかけとなれば嬉しく思います！
この記事を書いた人
Advent Calendar!
Advent Calendar 2024開催中！
