内製開発AI開発プロセス業界横断プロダクト

膨大なバックオフィスプロダクトに、AI時代の「完全に違う」効率で挑む。AIフル活用の内製開発を9ヶ月で確立

1backoffice株式会社

1backoffice株式会社

https://1backoffice.co.jp/
1backoffice株式会社 岩崎氏のインタビューカット

会計、人事、給与――部署ごとに分かれてきたバックオフィスのシステムを、一つのプロダクトに統合する。1backoffice株式会社が開発する「1backoffice」は、創業者の岩崎氏自身が複数の会社を経営し、事務を自ら担ってきた経験から生まれたプロダクトだ。

岩崎氏はシステム開発のキャリアが長い。ただ、今回の構想は膨大で、従来のやり方では形にできなかった。転機はAIだった。プロダクトオーナーとしてAIを使い、半年の試行錯誤でプロトタイプを形にした。

問題はその先だった。AIで作ったプロトタイプを、どうプロダクト開発と体制につなげるのか。前例はなかった。同社が選んだのは、内製を模索しながら一緒に作るCTO代行だった。

9ヶ月の伴走を経て、現在は支援を終了。組織の立ち上げと採用に成功し、社内エンジニアが自走する体制で、外販に向けた改善を進めている。その軌跡を岩崎氏に伺った。

抱えていた課題

  • AIでプロトタイプは作れるようになったが、プロダクト開発にどうつなげるかが未知数だった
  • AIを活用して膨大な機能を持つプロダクトを作りたかったが、最先端ゆえに前例がなく、進め方が手探りだった
  • 当時は社内にエンジニアがおらず、AI時代のプロダクト開発を現場で一緒に探索できるパートナーがいなかった

導入効果

  • 膨大な仕様をAIを活用したプロトタイプで決め切り、エンジニアの仕様理解が速く正確になるプロセスを確立
  • プロトタイプのコードを流用しつつAIで品質も担保し、開発の速さも品質も従来と「完全に違う」水準に
  • 開発速度と品質が大きく向上した上、エンジニアに期待値を明確に伝えられるようになり、採用も進展した

バックオフィス全体が統合された「本当に良いもの」を作りたい。AIでプロトタイプは作れたが、その先の進め方が見えなかった

インタビューに応える岩崎氏

― まず、御社の事業について教えてください

私たちが開発しているシステムは、社名と同じ「1backoffice」というバックオフィス事務の一元化、効率化を目指したシステムです。私自身が会社をいくつか経営していて、実際にバックオフィスを経験してきたのですが、複数のシステムを使い分けたり、同じようなデータを登録することが多く、もっとシンプルで使いやすいシステムが作れないかと考えたことが創業のきっかけです。

現在は社内システムとしての運用は開始しており、今後は外販に向けての改善を続けていく予定です。

― 当時、開発はどのような体制だったのでしょうか

バックオフィス全体を一つに統合するには、はじめから統合された設計で貫かれていないといけません。仕様が曖昧なまま作ると、設計はばらけて、結局は別々のシステムをつないだものになってしまう。一方で、全業務を統合する以上、機能は膨大です。決め切ることと、この規模を作り切ること。その両立が難しかった。

当初は若手のエンジニアやインターンのメンバーと、普通の開発のやり方をしていました。でも、この規模の仕様を文書で伝え切るのは難しいよねと。開発が計画通りに進まなくてチームを解散した頃に、ちょうどAIが使えるレベルになってきたんです。

AIを、プロダクトオーナーとして、プロトタイプを作るために使う。その使い方がいけるかもしれないと思い始めたのが、1年ほど前です。そこから半年くらい一人で試行錯誤をして、プロトタイプが形になってきました。

― プロトタイプが形になって、次に何が問題になったのでしょうか

プロトタイプは1人で作れるようになったが、それを開発体制にどう乗せて、どう作り切っていくか。ものすごく業界知識が自分たちにあるシステムなので、内製していこうとは決めていました。ただ、AIと内製と、新しいプロダクトオーナーの役割、事業と開発全体をどう進めるか。それが本質的な課題でした。

型にはまった開発手法では、AI時代のスピードと品質は出せない。探索しながら一緒に内製できる相手を選んだ

― そのときに欲しかったのは、どんな相手でしたか

答えが欲しいというよりは、話せて、一緒に探索できる相手ですね。それも、話すときに「ここに落とし込む」という形じゃない方がいいと思っていました。

コンサルタントや受託会社だったら、それぞれの方法論がある。私もキャリアとしていろんな役割をやってきたので、それ自体は分かるんです。

一方で、今回は前例のない内製プロセスの構築が鍵でした。バックオフィス全体を包括したプロダクトを、スピードも品質も落とさずに作り切る。そのプロセスを、AI時代に合わせてゼロから作る必要があった。だからこそ、結論ありきで話さない関係性がいいなと。

それと、開発にすごく特化してしまうと、どうしても開発の最適化になってしまう。もうちょっと事業全体を見られる、というのは重視した方がいいかなと思っていました。

― レミナス以外に検討した選択肢はありましたか

まだ検討し始めの段階だったんですが、最初に探したのは「内製支援」でした。でも、内製支援って、なかなかないんですよ。内製がうまくいくと契約が終わってしまう可能性があるので、開発会社としては積極的にはなれないのだと思います。

決め手は、レミナスがその内製支援だったことです。自分たちで作り続けることを前提に、一緒に進めてくれる。それに加えて月額でリスクが小さく進んでいく形だったので、話を聞いてみて、やってみようかなと。

― 当初、スケジュールを細かく決めずに進めたいとのお考えが印象的でした

「いつまでに何を」とゴールを決めると、そこから逆算して引いていくやり方になる。それは自分もやってきたから分かるのですが、今回はそれとは違うかなと思っていました。

構想が良くて、メンバーが良くて、計画が良ければ、あとは普通にやれば大体いける、というのはさすがに経験してきている。けれど今は、AIによってその「普通」が揺らいでいる。そうなると、一つ一つ納得しながら進めていかないと、最適な形にはならないと思ったんです。

AIで動くプロトタイプを仕様書に。エンジニアに伝わり、コードにも活きる仕組みを作り上げた

支援の手応えを語る岩崎氏

― 支援が始まって、印象に残っていることはありますか

まず良かったのは、柔軟さがすごくあったことですね。情報を持ってきてくれるけど何もしません、ではなくて、開発を前に進めるために、日々すごく具体的な提案をもらえたり、コードに向き合ってもらえた。

プロダクトオーナーが自分でコードを書いてプロトタイプを作る、というやり方は、従来の常識に反することも多いと思います。でもレミナスさんは、自分のアイデアに対して、デメリットは適切に伝えつつ、いつも背中を押してくれるので、前に進みやすかった。

やった結果、課題が出たときも、「ほら言ったでしょ」といった姿勢ではなく、最適なプロセスを作るための学習過程と前向きに捉えて、当事者として一緒に向き合ってもらえた。その感覚を持ってくれていたことが大きいですね。

― 一緒に探索した結果、どんな開発プロセスに落ち着いたのでしょうか

プロダクトオーナーがAIでプロトタイプを高速に作れることに、希望を感じていました。文書だと、書くのも理解するのも時間がかかる。動くものなら、何を作りたいかが一目で伝わる。しかも自分でAIで作ったものなら、試行錯誤するのも捨てるのも簡単です。全面的に作り直したこともありますし、作ってみて価値が感じられずに捨てた機能もあります。このプロトタイプを最大限に活かすプロセスにしたかった。

迷ったのは、渡し方です。プロトタイプを参考にエンジニアが一から書き直すのか、プロトタイプのコードをそのまま育てるのか。私一人では決められないところで、レミナスさんにエンジニアの視点で一緒に考えてもらいました。

結果、プロトタイプをそのままエンジニアに渡して活かせる、理想の形にたどり着きました。エンジニアはビジュアルで仕様を理解しながら、コードを流用し、品質を磨き上げて本番に仕上げる。文書を読んで一から作るのとは、速さがまったく違う。また、エンジニアに渡しやすく不具合が起きにくいプロトタイプが生成される仕組みも整えてもらいました。そのおかげで今は、プロトタイプからエンジニアへの受け渡しが、迷いなく回っています。

速さも品質も「完全に違う」。膨大な構想を少人数で作り切れる状態になり、採用まで進展

開発体制の変化を話す岩崎氏

― 普通に開発していた場合と比べて、何が変わりましたか

速さも品質も、全然違います。それも開発者の生産性というより、事業側の仕事の速さと品質、そして蓄積です。クオリティの高いプロトタイプがあれば、人が入れ替わっても何を作りたいかが全部そこに詰まっている。エンジニアにパワーポイントで伝えていた頃とは、完全に違います。

もう一つ大きいのは、業務を一番分かっている人間が、仕様を最後まで決めきれたことです。普通の開発だと、考え切る前にリリースや本番運用が来てしまって、「とりあえずこれで」と妥協したまま進むことが多い。今回はプロトタイプで納得いくまで試せたので、膨大な仕様は決め切ることができました。あとはエンジニアと実装を詰めるだけで、ある意味、普通の開発に戻れたんです。今は、バックオフィス全体の一元化という製品構想を、やりきれる手応えがあります。

― 開発プロセスが固まったことで、採用にも変化があったと伺いました

それはありますね。開発の仕組みが整理できたことで、候補者の方とも自信を持って開発への取り組み方が議論でき、反応が変わった記憶があります。加えて、AIや技術に深く向き合っているレミナスさんと毎週話すことで、エンジニアの視点や用語に慣れるので、候補者の方とも話が噛み合うようになりました。

それと、プロダクトオーナーはここまでやる、エンジニアはここから、という線が明確になった。私がコードでプロトタイプを作るので、要望を綺麗なドキュメントにまとめる仕事は要らない。万人に合うわけではないので、お互いに合いそうかがはっきり分かるようになりました。

― 途中でサーバー基盤の整備もレミナスにご依頼いただきました

インフラは、立ち上げの時期に作業が集中して、その後は手がかからなくなる。サービスの本格展開までは、専任を採用するほどの仕事量ではないものの、専門領域で短期間に仕上げる必要があった。それなら、すでに社内を知っているレミナスさんにお願いする方が安心だと判断しました。

採用がうまくいったこともあり、インフラはしっかり構築して社内に引き継いでもらえたので、今は社内のエンジニアだけで自走できる状態になりました。

同じ立場の経営者へ。正解がないAI時代に、助言で終わらず一緒につくれる「他にない選択肢」

― レミナスは、どのような会社・経営者におすすめできますか

シンプルに言うと、内製をしたいけれど、自社に合う開発の型がわからない、という会社ですね。開発をやったことがある会社も、正解はまだ見つかっていないなら手伝ってもらうのはすごくいい。

内製前提で、正解が決まっていなくて、具体的に手を動かしてほしい。情報収集だけなら今はAIでいくらでもできますから、中身を理解した上で、例えばちょっと作ってきてくれるとか、採用についてもただ「業者を使えばいいですよ」ではなく「この会社がいいですよ」と言い切ってくれるとか。

こうしたニーズを満たせるサービスは他にないかなと思います。

― AI時代に合った開発プロセスを作りたい、と考えている経営者に一言いただけますか

これからは、一般的な質問にはAIが答えてくれるし、ちょっとしたものなら自分だけでも作れるようになる。でも、ということは、みんなそうするわけですよね。だから、それに収まらないこと、それではできないことをやっていかなきゃいけない。

そうすると、事業領域や体制によって、プロセスはすごく多様になると思うんです。これまでのように標準的な開発プロセスの型があって、その通りにやればどの事業領域でも大体いける、ということではなくなる。

だから、なぜそのプロセスがその事業領域にとって良いのか、を議論できる人とやっていかないと作れない。最適なプロセスを一つ一つちゃんと考えていくことが、競争上すごく大事になってくる。そう思っている経営者には、レミナスのサービスはとてもいいんじゃないかと思います。

― 最後に、今後の展望を教えてください

これまでのバックオフィスのシステムは、事務担当者の所属部署に合わせてデザインされてきたと思うんです。経理部に合わせて会計システムがあり、人事部に合わせて給与計算システムがある。でもよく考えると、従業員や給与といったデータは両方のシステムで必要になる。システムを一つにできれば、重複する作業やデータの同期がなくなって効率化します。

バックオフィスの事務領域を、一つの無駄のないシステムでカバーすることは、とても難しいことで、時間もかかります。税理士や社労士などの専門家とは長く議論を続けてきましたし、行政のシステムの理解にも時間をかけてきました。

しかし、バックオフィス事務はどんな会社でも避けて通れない業務であって、それを担うシステムは会社の重要なインフラの一つだと言えます。見た目は少し地味ですが、専門家と共に会社を支える重要な土台を作っているという実感がありますし、自分たちで事務処理の新しい形を創り出せるという楽しさがあります。今後も、そのような事業に共感してくれる方と協力しながら、開発を続けていきたいと考えています。

― ありがとうございました。

技術判断でお困りの方へ

  • 技術が正しいか判断できない
  • CTOやリードエンジニアがいない

こうしたお悩みは、お気軽にReminus(レミナス)へご相談ください!

資料ダウンロード無料相談

資料ダウンロード

Reminus(レミナス)のサービス資料をダウンロードいただけます。

資料ダウンロード

無料相談

初回のご相談は無料です。まずはお話を伺わせてください。お役に立つ情報をご提供します。

無料で相談する