kintoneの構築から伴走支援でご支援を行う

  Topへ↑

ファクティブ様は、既に自社でLOCAL FARMの運営をされています。会員管理や請求・入金管理についてのビジネスフローについては、確固とした経験と知見をお持ちでした。
ただ、もともとのシステムで管理されていた会員データ、請求データ、農園データなどは、kintoneで一から作る必要がありました。

この部分のご支援については、伴走支援を主とした準委任契約を締結しました(2025/1/25)。

会員データ、請求データ、農園データをきちんとkintoneで管理できるようにするため、データ構造やフィールドなど、kintoneデータを管理するため、細かい仕様まで含めて何度も打ち合わせを行いました。

kintone構築にあたっての契約は、準委任契約です。そのため、弊社としては特に手は動かしていません。共に遊びながら構築する共遊開発の形を取らせていただきました。
ただし、項目の設計や発番体系などは、データの性質や流入経路、管理粒度などを想定し、かなり細かい調整を行いました。
時にはあるアプリのあるユニークなフィールド値の桁数を何桁にするかを決めるために数時間以上を費やしました。

弊社はkintoneの構築部分については、その後の運用時に起こりうる様々なパターンについての知見があります。そのリスクも助言しながら、共に作り上げていきました。
また、アプリや項目の設計が曖昧だと、弊社が続いて請負開発として進めるSBPaymentと請求決済データをやり取りする実装に支障が生じます。
ここでkintoneのデータについて、様々なパターンをつぶしていたからこそ、運用開始時にトラブルが最小限に抑えられたと思います。

同時に、申し込みフォームに関してもファクティブ様と共に検討を加えていきました。
今回、弊社が担当したのは新規入会フォームです。今回の運用の全体では、初期のお問い合わせフォームを始め、多数のフォームがあります。
ただ、新規入会フォームについては、FormBridgeの標準機能だけではうまく実装できないことが想定されていました。そのため、カスタマイズを弊社が行う想定で進めました。

一方で、SBPaymentとの連携に関しては、PHPを用いた開発を提案しました。弊社メンバーが設計と実装を担う体制で進めました。

会費請求の送信、決済結果の受信だけでなく、カード切り替え、カードエラーのデータもうまく矛盾なく取り込まなければ、サービスの運用は回りません。
また、不備の際の再請求のフローも考慮する必要があります。そのため、入会フォームの検討を進める際には、SBPaymentへの導線も考慮しました。そして、kintoneと周辺の整備を進めていきました。

フォームの実装で問題が発生する

  Topへ↑

kintoneのアプリ構造やフィールドの構成は固まり、SBPaymentからの連携に関しても実装が可能との目処がつき始めました。そこで、開発フェーズに移行し始めました。
開発フェーズは請負開発として締結を行いました(2025/9/2)。

ところがこの時期、ある問題が生じました。
それはFormBridgeにおいてです。

ファクティブ様の農園はあちこちに存在します。また、各農園の中には多数の区画があります。

新規会員の方に円滑にフォーム上で入力を行っていただくため、フォーム上では農園→区画の順に選んでいただくインターフェースを想定していました。（議論の結果、新規会員様にはパラメーター付きのURLを案内する運用に落ち着きました。その際、農園の初期値は選択されています）

ところが区画マスターのレコードは、区画の数だけ用意する必要があります。つまり、レコード数が多数にのぼります。多数の区画を新規入会フォームに選択肢として全て表示することは、ユーザビリティの観点から避けなければなりません。新規入会者にとってストレスになるばかりか、離脱が発生してしまうためです。
それを避けるため、区画の選択肢は選んだ農園に応じて動的に変える必要がありました。フォームで選んだ農園に一致する区画だけ、動的に絞り込んで選択肢として表示することが必須要件でした。

FormBridgeの旧フォームには、動的に絞り込むための術が用意されていました。FormBridgeに備わっているkViewerルックアップの候補が表示されたタイミングで発動するイベントがあり、開発者はそのイベントの発動後、画面を制御して任意の候補だけに絞ることができました。
ところが、新フォームではkViewerルックアップの選択肢が表示された際に起動するイベントが廃止されました。そのため、動的に選択肢を絞る術がなくなってしまいました。

これはフォームを運用する上で死活問題でした。どうにかして実装できないか、色々と手を尽くし、知恵を絞りました。
旧フォームでは出来たのに、新フォームでできないはずがない、と。

FormBridgeが生成する画面をいじって無理矢理実装することも考えました。ただ、それは難しそうです。また、ノーコードツールの使い方としては、今後のリスクになります。そのため、断念しました。
もちろん、トヨクモ社のサポートにも問い合わせました。ですが、その時点では新フォームで廃止されたイベントの対応予定はないとのお返事でした。

そこで急遽、実装方法を変更しました。
新規入会フォームのみ、FormBridgeの使用を諦めました。そして、Studioとは別にWordPressのサーバーを用意していただきました。
弊社が提案したのは、WordPressのフォーム拡張機能として著名なContact Form 7を用いてフォームを実装することです。そのフォームには、選択肢の絞り込み機能は当然実装します。そして、5つのステップのフォームを通じて、ストレスを感じさせないようにお客様を導きます。その途中では、キャンペーン割引を適用した金額を表示する機能や、最後にkintoneの複数アプリへのデータ登録/更新機能や、SBPaymentへのデータ連携まで実現します。それら全てが弊社のミッションでした。

ところが、このフォームの実装にはとても苦労しました。

まず、Contact Form 7はそもそも基本機能としてマルチステップフォームの機能が用意されていません。それを実装するためには、別の拡張機能をさらにインストールして実装する必要がありました。
マルチステップフォームの実現にあたっては、各フォームを行き来しても、入力したデータがフォームを跨いで保持されなければなりません。
また、ダブルブッキングを避けるため、区画を仮確保することも必要でした。ということは、フォームを開いたまま長時間放置された場合、区画がロックされたままにならないための考慮が必要です。
お客様の利便性は最優先。そして、ファクティブ様の運営も円滑に実装する必要があります。

さらに、入力したデータを同時に複数アプリに登録または更新するための処理も必須です。
結果として、参照するアプリが3つ、登録するアプリが3つ。更新するアプリが1つに決まりました。
対象となるアプリが一つだけであれば、Contact Form 7からkintoneに連携するForm Data to kintoneという拡張機能があり、それだけで処理は実現できます。
ところが、複数アプリの参照と登録と更新を行うためには、PHPによるカスタマイズが発生しました。

また、上記の新規入会フォームの実装にあたり、セキュリティリスクは完全に排除する必要があります。

当初、フォームの実装はこの記事を書いている私が行っていました。ところが当時はCybozu Daysの直前準備に加えて、私から新代表への代表交代の諸作業も控えており、別案件の提案や実装も進めなくてはなりません。その結果、私自身に実装に割ける余裕がありません。その時間を捻出するため、週末や夜にまとめて作業していました。要するに、進捗が芳しくありませんでした。

この時に感じたのは、FormBridgeのノーコードツールとしてのメリットです。FormBridgeなら、かなりのことがノーコードで実現できます。このことについては、年末のAdvent Calendarに個人的な記事として書きました。（なお、その他の様々な入力フォームはファクティブ様によってFormBridgeで実装していただいています）

少しずつ進めた実装によって、この時点で新規入会フォームやkintoneの構成はほぼ固まりつつありました。一方、PHPを用いたSBPaymentとの連携に関しても実装の目処がつき、テストも始まりました。

テストを重ねてリリースに至る

  Topへ↑

テストすべき内容は、多岐にわたりました。
まず月額請求処理です。kintoneの契約アプリのレコードをもとに請求データを生成し、それをSBPaymentにバッチ処理で送ります。SBPaymentから帰ってきたデータのうち、決済不能やカードエラー等の問題が起きた時は二度目三度目と再請求をかけます。
さらにカードの変更処理などの実装も必要です。SBPaymentにはそうした処理に対するエンドポイントが多数用意されており、それに合わせて処理を実装しました。
まず、そうした処理のテストにあたり、様々な請求パターンをファクティブ様に考えていただきました。それをもとに当方でもテストデータを整備しました。

2026年の年明けには、新規入会フォームの実装に目処がつきました。ただ、新規入会フォームのテストと改修作業については、私の作業リソースが心もとなく、テストを進めるために弊社のメンバーに引き継ぎを行いました。
引き継ぎにあたっては、Contact Form 7の設定やPHPのプログラムの実装、さらに画面を制御するJavaScriptの実装も伝えました。本格的に引き継ぎ始めたのは3月の上旬からです。
この引き継ぎによって、私のリソース不足がリスクではなくなりました。メンバーが実装内容を完全に把握し、テストから改修までの作業を進められるようになりました。
それもあって4月の頭から始まったテストは、テスト時に発生した障害の解消も含め、順調に進みました。
4月のバッチ処理、入会フォームの修正と新規入会処理のSBPaymentへの連携。
5月にも様々なテストを行いました。

テストを行うタイミングは、月次請求を意識する必要がありました。が、その懸念も設定を工夫し、月の途中であってもテストができるようにしました。それは、テストを進める上でとても効果を発揮しました。

そして6月。いよいよリリースです。
その前にSBPayment社に依頼し、SBPayment内で一連のデータを旧管理システムから新たな環境で使えるよう、データの移行作業を行っていただきました。
また、移行前まで運用に使っていた管理システムからのkintoneへのデータ移行もファクティブ様によって無事に完了しました。

問題が皆無だったわけではありません。一部の処理ではエラーが起こり、修正作業が発生しました。
例えば、入会フォームについては、入力フォームからSBPaymentに制御を渡す直前に数件のiPhoneの処理で決済画面に遷移できない問題が生じました。
こうしたエラーはすぐに対応し、それ以降、エラーは起こっていません。

その後も、あるフィールドのデータ体系を修正する必要が生じました。そのため、PHPで修正作業が発生しました。それらも7月の請求においては問題なく動いています。
なお、バックアップは、開発の途中の段階でcli-kintoneを用いてご支援しました。具体的には、弊社にて一アプリを対象にcli-kintoneの実装を行い、その使い方をファクティブ様にお伝えしました。こちらも問題なく運用されています。

まとめ

  Topへ↑

今回の反省は、フォームの要件とシステム側の仕様調査が不十分であったことです。
ここは、我々がきちんと押さえておくべきでした。
そのためにFormBridgeからContact Form 7への実装対象の変更が発生しました。さらに、当初のスケジュールに若干の変更が生じてしまいました。

ただ、それ以外は、弊社とファクティブ様の間では、きちんとしたコミュニケーションができていたと思います。
お互いの業務範囲や役割分担の認識のずれも最小限で済み、ファクティブ様の主導による要件定義書が更新され、詳細な仕様書も矛盾なく作り上げられました。

この辺りのコミュニケーションが丁寧に進められたからこそ、運用開始後の障害は最小限で済んだと思います。

また、弊社としてもStripe、Zeusに続いて、SBPaymentを用いた決済サービスとkintone連携の知見を貯めることができました。

今後も、こうしたサービスの需要はあるはずです。弊社でもkintoneと決済サービスの連携に携わる機会もあるはずです。
ファクティブ様、本当にありがとうございました。

株式会社ファクティブ様より

  Topへ↑

導入からの日々をファクティブ社のご担当者様は、こう語ってくださいました。

「今回、kintone を中心に、SB ペイメントサービスとの決済連携、FormBridge、kMailer、WordPress の入会フォーム、Contact Form 7 との連携及び、PHP によるサブスクリプションの決済サービスなど、お客様管理から決済管理までを含めたシステム開発をアクアビットさんにお願いしました。
振り返ると、NDA 締結から 2 年弱。要件定義から設計、実装、テスト、運用研修まで、本当に長い期間ご一緒いただきました。その間、 Cybozu Days でも何度かお会いしながら、少しずつ理想の形を作り上げていったことを思い出します。

アクアビットさんをおすすめしたい理由は、大きく 3 つあります。
まず 1 つ目は、「確かな経験と実績に基づく提案力」です。
システム開発会社を選ぶ際、大手企業では実際に誰が担当するのか見えづらかったり、担当者によって品質にばらつきが出たりすることがあります。また、kintone 界隈でも若い開発者の方が増えていますが、経験不足による不安を感じる場面もあります。
その点、アクアビットさんは、 Cybozu Evangelist でもある長井さんをはじめ、経験豊富なエンジニアの方々が在籍されており、数多くの実績に裏打ちされた提案をしていただけます。
常に「今できるベストな方法は何か」を考えて提案してくださるため、非常に大きな安心感がありました。
2 つ目は、「開発そのものだけではなく、その周辺知識やノウハウも共有していただけること」です。
アクアビットさんが掲げている「ともに遊ぶ開発(共遊開発)」という考え方は、単なる受託開発ではなく、発注者側も理解しながら一緒に作り上げていくスタイルです。
実際に、開発をお願いしていない部分についても、「こういう方法がありますよ」「こういうプラグインがありますよ」といったヒントや知見を数多くいただきました。私たち自身がGPT を活用しながら試行錯誤したり、簡単な部分を自社で実装したりする際にも、多くの示唆をいただけたことは非常にありがたかったです。
3 つ目は、「最後まで粘り強く、良いものを作ろうとするモノづくりの姿勢」です。
長期間の開発では、要件が固まりきらない時期もありますし、途中で方向性を見直さなければならない場面もあります。今回のプロジェクトも決して平坦な道のりではありませんでした。
それでもアクアビットさんは、要件定義の段階から実装前の仕上げ、そして運用開始後の研修まで、一貫して「より良いものを作る」という姿勢で伴走してくださいました。発注者である私たちも悩み、アクアビットさんにもご苦労をおかけした場面があったと思いますが、最後まで粘り強く向き合っていただいたことに感謝しています。
一方で、正直にお伝えすると、すべてをベンダーに丸投げしたい方には、アクアビットさんは向いていないかもしれません。

要件整理から運用まで完全に任せたい、システムの中身は理解したくない、というスタイルであれば、他社のほうが合う場合もあると思います。
しかし、「自社でも運用できるようになりたい」「kintone を活用する力を社内に蓄積したい」「ベンダーと一緒に良いものを作りたい」という会社にとっては、これ以上ないパートナーだと思います。
kintone が目指している『現場が自ら業務改善できる世界』を実現するために、発注者側も成長しながらシステムを作っていく。その考え方に共感できる方には、心からおすすめしたい会社です。長井さんをはじめ、アクアビットの皆さま、本当にありがとうございました。
今後ともよろしくお願いいたします。」

株式会社ファクティブ様のご紹介