「新規事業の検証フェーズ、大規模システム導入前の効果測定フェーズにて、大きな力になってくれる企業がファンリピートさんだと感じます。」
Belong株式会社 取締役副社長 COO 清水 剛志様
東京都出身。京都大学大学院卒業後、2012年に伊藤忠商事株式会社入社。2016年よりITOCHU International Incのシリコンバレー事務所駐在。2018年に帰国後、2019年2月に伊藤忠商事の社内ベンチャーとして、Belongを設立。
Belong様との取り組み/プロジェクトの概要
![](https://funrepeat.com/wp-content/uploads/2023/11/image-7.jpeg)
プロジェクトの背景
・大規模なプロダクト開発の着手に伴い、要件定義を効果的に進められる手法を検討されていた
・アジャイルな開発手法*1 を採用すると仮定しても、その前段階でPoC*2 の実施は必要になると考えられていた
当社からの提案内容
・実際の画面イメージをベースにした迅速な要件定義/企画提案
・ノーコードツール*3 を活用した短期間でのシステム開発/PoCの実施
プロジェクトの成果
・当初の想定よりも短期間での開発に成功し、要件定義フェーズを大きく進捗させられた
・チーム内でシステムのイメージ共有が円滑になり、手戻りなくプロジェクトを進められるようになった
・開発時に課題となる落とし穴のような箇所が可視化されて事前に発見しやすくなった
*1 アジャイル開発: アジャイルとは「すばやい」「俊敏な」という意味で、短い開発期間単位を採用することで、リスクを最小化しようとする開発手法の一つ
*2 PoC(Proof of Concept、読み:ポック / ピーオーシー): 直訳すると概念実証となる、新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な実現化を行うための検証手法
*3 ノーコードツール: コードを書かずに短期間でソフトウェアを構築できるツールの総称
まずはBelong様の事業について教えてください
![](https://funrepeat.com/wp-content/uploads/2023/11/image-8-1024x684.jpeg)
弊社は、伊藤忠商事100%出資の社内ベンチャーとして、私と代表の井上2名で立ち上げた会社です。現状、約200名程度の規模となっています。
事業内容としましては、「中古スマートフォンの流通事業」を行っています。端末の購入や買取、回収から販売まで総合的なソリューションを提供しております。
ヘルスケア業界からレストラン業界まで、様々な業界で「スマートフォンやタブレットを必要とするお客様」にお引き合いを頂いています。
今回取り組まれたプロジェクトはどのような内容でしたか?
弊社では、「Belong One」*1 という法人向けのスマホ・タブレット端末のレンタル・回収サービスを展開しています。今回のプロジェクトでは、Belong Oneで使われている端末を「どこにどういった形で貸し出しているのか」を軸に、見える化を進めていきたいと考えておりました。
弊社側のみならず、お客様側からも端末を管理しやすくしたいと思っており、そのためのプラットフォームを構築するにあたり、今回、POC(概念実証) の位置付けとして、実際に動いて要件定義を進められるシステムを作りました。
*1 Belong Oneの公式サイト: https://belong.co.jp/business/lease_lp1/
どのようなシステムを開発したいと考えられていたのでしょうか
一言で申しますと、スマホ・タブレット端末の管理サービスとなります。お客様ごとに貸し出し中の端末や回収対象の端末などを一元管理できるようなイメージです。
我々が端末のレンタルなどを中心にサービスをご提供させていただいてるので、お客様の手元にどんな端末があるのかが管理できる機能はもちろん、端末が壊れたらシステム上から交換依頼を出せたりといった、レンタル後にも付随して発生するような業務を、システム内で実現できるプラットフォームにしたいと思っていました。
今回、このプロジェクトに対してPoCの実施を考えられたのは、どういった背景があったのでしょうか
![](https://funrepeat.com/wp-content/uploads/2023/11/image-9-1024x684.jpeg)
もともと、今回開発しているシステムは非常に規模の大きいものになるという印象を持っていて、最初から1億円や2億円かけて開発するにはリスクのあるプロジェクトだと思っておりました。
特にシステム要件の部分に関しては、我々が営業活動をしていく中で、「こういう要件もあるな」「こうしたほうが良いな」というのは必ず出てきますので、プロジェクトを進めていく中で、どうしても変わってしまうという現実があります。
仮にアジャイルな開発手法で進めていくとしても、最初の発射台みたいなものを用意して、プロジェクトチーム内の共通認識を明確にしておきたいなっていう考えがあったんです。
その発射台を作るために、ノーコードツールを用いてスピーディーに開発を行い、チーム内で「これが発射台です」という共通認識を作りたかったというのが、今回、PoCの実施を行った背景ですね。
これまでのご経験から、システム開発のプロジェクトでは「規模が大きくなると要件定義が難しくなる」という印象を持たれていたのでしょうか
おっしゃる通りです。そのため、ある程度動くものを作り、実際に使ってるチームにヒアリングを行ったりして、「こういう機能があった方がいいよね」「こういったUIの方がいいよね」という意見を出し合いたいなと考えておりました。
そういったものを積み重ねて、本番のシステム開発に向けて「大きくズレが出ないようにしたい」というのがありまして、まずチーム内の認識の統一を図りたかったんです。
実際にそうやってプロジェクトを進めていくと、本番の開発を行う際にズレがなくなります。ノーコードツールで表現されているものを、あとはどうスケーラブルにしていくかという事を考えていけばいいだけなので、結果的にプロジェクトが手戻りなく円滑に進んでいます。
こういったシステム開発プロジェクトで結構ありがちなのは、作った後に「UIでここはちょっと駄目だな」「この機能のイメージが違っているな」といった要件のズレが原因で手戻りが発生することだと思うんですよね。
UI/UXデザイナーとかがチーム内にいれば、そこら辺の問題も解決するのですが、なかなかやはり我々の規模だと、そこまでチームに力を入れられないっていうのもありましたので、「こういったシステムをイメージしていますよ」といったチーム内でのコミュニケーションを円滑にするための、POCの実施としては非常に良かったのかなと思っています。
弊社を選んでいただいたきっかけ、経緯についてお伺いできますか?
![](https://funrepeat.com/wp-content/uploads/2023/11/image-11-1024x684.jpeg)
そうですね、そもそもノーコードツールの活用・開発の支援を、ある程度専門的にやられている会社はそれほど多くはないかなと思っていました。
私の中で、ノーコードツールの中でもbubble*1が、特にいろいろな機能を実現できるんだろうなと思っていたので、bubbleの開発ができる会社という切り口でも探させていただき、御社を見つけたという感じです。
*1 bubbleの公式サイト: https://bubble.io
最終的な発注先として弊社をお選びいただいた理由は何かありましたか?
最初にご相談させていただいた段階で、私からスプレッドシート等を用いて「データはこういう構造で、こういうふうに作りたいです」という話をさせていただいたのですが、その際の理解度が非常に早く、こちらのやりたい要望を、よくご理解いただいてるなという印象を持ちました。プロジェクトの目線合わせとしても非常に合ってるかなと思い、発注させていただきました。
発注後の弊社の仕事の対応や印象について何かありますか?
![](https://funrepeat.com/wp-content/uploads/2023/11/image-10-1024x684.jpeg)
想定していたよりも短い期間でプロジェクトを進めていただいたと思っております。実際に納品していただいたシステムを見ても、弊社側の認識とほとんどズレがなかったなという印象がありました。
そのため、それほど修正依頼もかけてないと思うんですよね。そういった観点では、スピーディーに自分たちが求めているものを作っていただけたと感じています。
今回のプロジェクトの肝となる要件定義・企画提案といった上流工程のご支援という観点も踏まえて、良かった点、改善点をお伺いできますでしょうか?
そうですね。良かった点は、まずプロジェクトに関わるドキュメント等を細かく丁寧にまとめてもらっていたところですね。他にも質問や課題などは課題管理表で逐一連携していただいていたりだとか、「こういうイメージですか?」という細かい提案も的確で、弊社への質問も回答しやすいようにまとめていただいていましたね。
私も他の業務の関係上、まとまった時間が取れなかったりするので、そういった中でもコミュニケーションの取りやすい環境をつくっていただき、御社からいただく質問もズレてなく、要件のキャッチアップが非常に早いと感じました。
改善点は、プロジェクト期間としてもそれほど長くなかったので、特段ありません。強いて言えば、おそらく限られたリソースの中でプロジェクトを進められているという背景もあったかと思いますので、開発の部分でエンジニアを増やすことができたら、そのぶん早く終わるのかなと思ったりもしました。
それでしたら同じ金額でもいいので、人数を投入してもっと早めに結果をもらった方が、我々としてはフェーズ的に合ったのかなっていう感じですね。
他に弊社へのご要望、ここを改善してほしかったなどございましたか?
![](https://funrepeat.com/wp-content/uploads/2023/11/image-12-1024x684.jpeg)
ほとんどないですね。ノーコードツール(bubble)で実現できない機能なども事前にご提案いただいておりました。「こういう機能がbubbleだと表現できないんです」「こういう所はこうした方がいいです」など、タイムリーにご提案いただいていたので、振り返って「こうしてほしかった」「ああしてほしかった」というのはあまりないですね。
他にも開発会社さんと色々とご関係があるとは思うんですけれども、他と比べて、弊社のここが良かったという点ってあったりされますか?
ノーコード開発の特徴だと思うんですけど、アプリケーションありきで考えられてるので、比較的ビジネスサイドや現場の議論と合いやすいというのはあるかと思います。
他の開発会社、普通のいわゆるSIerとかSESを提供されているような会社では、「この機能をどうやって作っていきますか」「この機能をいかにして実装していきましょうか」といったような技術的な観点が中心になりがちだと感じています。
当然、システム規模が大きくなると、担当者1人1人の役割っていうのが相対的に狭くなってくるので、ビジネスサイドや現場の意見も含めた全体像がちゃんと見えないままで進んでしまっているケースが意外と多くて。
他のシステム開発会社にお願いすると「いやいや、これってこういうプロダクトにしたいのに、これじゃ絶対駄目ですよね」みたいなのは過去に何度かありました。そのため、本当に細く1人1人の業務を見て、「この業務をこっちに優先させて、タスクはこうなって、機能追加としてはこういもので」といった形でマネジメントしていかないと、大きなミスが発生してしまったりすることもあるかと思います。
その点、ノーコードツールなどを活用すると、基本は1人や2人とかでも、ある程度は設計から開発まで進められるので、開発するシステムのイメージにズレがあまりなくなってくるという印象を持ってます。
当然ながら、弊社がやりたい事を、1人のエンジニアが聞いて、そのエンジニアが実装まで完結できちゃうっていうのが、プロジェクトの要件や認識のズレを起こさないための効果的な方法だと思うので、そういった点でノーコードツールを活用された開発の支援を行われている御社では、要件の認識ズレなどもなくスピーディーにプロジェクトを進められた点が非常に良かったかなと思っています。
今回、エンジニアへの指示出しが明確になったなど、PoCを実施された効果についてはいかがでしょうか
そうですね、エンジニアがシステム要件を細かく把握しやすくなった点や、今後スケールさせていくためにはどういう構造にしなきゃいけないのか等、開発のイメージがしやすくなりました。
しっかりと作り込むと「ノーコードツールだと簡単に作れるけども、本格的なシステムにするとここって意外と重いよね」といった、落とし穴みたいな箇所も見えやすくなってるかなとは思ってますね。
最後に、弊社を他社に紹介すると想定した場合のコメントをいただけますか?
![](https://funrepeat.com/wp-content/uploads/2023/11/image-13-1024x684.jpeg)
私の個人的な意見でいうと、POCフェーズでの開発や、新しく新規事業を立ち上げる際は、御社が非常に相性がいいんじゃないかなと思ってます。
ユーザーが1万人以下とか、まず小規模のサービスとしてトライする場合や、そもそもデータ量がそれほど多くないような管理系のツールだったりだとか、そういうシステムを開発するのであれば、御社みたいな会社の力を借りながら進めてみるのがいいと思うんですよね。
新しくサービスとして検討されている方や、中規模以上のシステムの開発を検討されている方とかには、まずはこういうところ(ファンリピートさんの所)でスモールスタートしてやってみたらっていうのはお伝えしたいですね。
使えるリソースが限られた検証フェーズなどには、スピーディーに開発が進められる弊社がマッチしやすいということでしょうか
そうですね。例えば新規事業であれば、PMF(プロダクトマーケットフィット)*1の段階で、スピーディーにPDCAサイクルが回せると思うので、ノーコードツールをどんどん活用していった方が、結果的には事業としても手戻りなく進められるのではないかと思います。1〜2千万掛けて、1つのシステムを作ってみたはいいけど、実際に使われなかったら意味ないですしね。
外部とのデータ連携が複雑になっているようなシステムになってくると、なかなか大変かとは思うんですけど、ひとつのアプリケーションで完結するようなものであれば、ノーコードツールなどでクイックに作ってしまった方が、結果的にはトライ&エラーの機会が増えるかと思うので、いいのではないかなと個人的には考えていますね。
※1 PMF(Product Market Fit): 提供しているサービスや商品が、顧客の課題を解決できる適切な市場で受け入れられている状態を指す
今回のプロジェクトを終えてファンリピート竹村が感じたこと
プロジェクトの当初から、清水様はエンジニアとしてのバックグラウンドをお持ちなのではないかと感じるほど、システム開発の勘所にお詳しい方だという印象を持っておりました。
そのため、お客様にとって判断が難しいようなシステム要件を定義する場面でも、会議中に迅速に意思決定を進められていました。結果的にそれが今回のプロジェクトを、想定よりも短期間で進められた大きな要因かと感じております。
今後、弊社の支援により「新規プロジェクトを成功させられた」という会社様をもっと増やせるよう尽力していきたいなと思います。
改めまして、この度は弊社までご発注いただき誠にありがとうございました。今回、Belong様の事業推進のお力になれたことを大変光栄に感じております。今後ともどうぞよろしくお願い致します。
お客様情報
![](https://funrepeat.com/wp-content/uploads/2023/11/image-14-1024x684.jpeg)
会社名:株式会社Belong
URL:https://belong.co.jp/business/
設立:2019年2月
事業内容:中古スマホの小売・卸売業
※掲載している内容は取材を実施した2021年11月当時のものです。