【開発生産性カンファレンス 2025】B2C＆B2B＆社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理

Belongの中古デバイス事業と全体像

福井：株式会社Belong CTOの福井です。本日は「B2C・B2B・社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理」というテーマでお話しさせていただきます。

まず会社の紹介にお付き合いいただいた後、一般的なイニシアチブ管理に触れ、弊社Belongが抱えていた課題と、それに対するアプローチについてご説明します。

弊社Belongは伊藤忠グループの100%子会社として、そのグローバルネットワークと連携し、PCやスマートフォンなど中古デバイスの調達から販売・レンタル（利用）までを一貫して手掛けています。

調達では個人向けに「にこスマ買取」、法人向けに「Belong One」といったサービスを展開しており、販売・レンタルも同様のサービス名で提供しています。



事業の大きな特徴は、検品やデータ消去といったプロセスをすべて自社で行っている点です。お客様が抱く中古端末への不安に応えるため、データ消去および検品を徹底した良品のみを届けています。

中古携帯のビジネスは「横流しするだけ」と思われがちですが、実際は非常に複雑です。だからこそ私のようなCTOがおり、システムを内製開発しています。



難しさの例として、規模、個別管理、高い価格の流動性、差配先の多様性、の4点を紹介します。

まず年間百万台以上、多いときは数百万台という膨大な「物量」の管理が必要であり、これはExcelで簡単に管理というわけにはいきません。

さらに「個別管理」の難しさもあります。新品と違い、中古品は同一モデルであってもバッテリーの最大容量や外観グレードが一つひとつ異なるため、すべて個別に管理する必要があります。この数百万台規模の「個別管理」は既存のERPでは対応が難しく、いずれにしてもフルカスタムレベルの規模になるため、自社でフルスクラッチ開発しています。

「価格の流動性」も課題です。価格の安定した新品と違って中古価格は市況に応じて常に変動するため、利益を確保しつつ適正な価格で取引するには、データ分析による価格の可視化や利活用が欠かせません。

最後に、利益を最大化するための「販路の最適化」も重要です。国内の個人・法人から、アメリカや香港といった海外まで販路は多岐にわたります。どの端末をどの販路に提供すれば価値が最大化されるか、そのためのルールやアルゴリズムを構築しています。

福井：これらの事業を支える弊社のエンジニア体制は、B2C、B2B、そして両者を支える共通基盤という構成になっています。



B2CではECや買取サービスがありますが、特徴的な点として、Googleの公式認定再生品「Google Pixelの認定再生品を国内で唯一取り扱っているのは「にこスマ」である点や、Amazonなどでスマートフォンページを見ていくと、弊社のサービスにいきつきます。B2Bサービスに加え、これら全ての事業を支えるオペレーションやデータ分析の基盤も内製しています。

また、早い段階から生成AIも積極的に活用しています。こちらは以前別のカンファレンスでもお話ししましたので、ご興味があればご覧ください。

一般的なイニシアチブ管理とは

福井：ここからは、一般的なイニシアチブ管理の話をします。

その進め方は、事業やサービスのフェーズで異なります。PMFを目指す立ち上げ期は、とにかく多くの機能を作る「全部やる」状態になりがちです。一方、成熟したサービスでは、どの顧客に、どの機能を、どういう順序で提供するか、といった詳細なロードマップに基づいて進めるのが一般的かと思います。



イニシアチブ管理は、まず「アイデアの収集・発掘」から始まります。その源泉は様々です。

次に、集まったアイデアを「評価・選定」します。戦略適合性、収益性、実現可能性などを総合的に評価して実施するものを決定し、投資会議で承認を得た後、開発・リリースへと進んでいきます。

Belongでは、開発における優先順位を明確に定めています。全体の詳細はスライドをご確認いただきたいのですが、最上位はセキュリティ、次にデータ損失防止と、サービスの信用に関わる項目が続きます。



基本的には、既存機能の安定利用を優先し、既存機能が安定していないのに新機能を追加しても使ってもらえないという考え方で進めています。この優先順位の中でも、今回のメインテーマは表の一番下にある「新機能開発」「技術的負債の解消」「UX向上」などをどう進めるか、という点です。これらの中で、次に何に、どういう順番で取り組むべきかという課題に焦点を当てます。

共有基盤課題 ― B2C・B2B・社内向けの属性差が生む優先度のジレンマ

福井：では、このテーマを深掘りするにあたり、まず弊社が抱える課題についてお話しします。今回の話の特に難しいところは、共有基盤にあると思っています。例えば、B2C、B2B、社内向けという3つの異なるユーザー属性向けにサービスを提供しています。各サービスの優先順位はチーム内で決定していきますが、それら全てが依存する在庫管理などの共有基盤に改修要望が上がった際、どれを優先するかの判断が特に難しいのです。

まず、対象ユーザーが異なるサービスの特性の違いをみてみましょう。



B2Cは不特定多数の個人が相手で、高頻度なリリースをするパターンもあります。なので、トランクベースでのアプローチなど素早いリリースサイクルも選択肢にはいります。一方、B2Bは特定企業の担当者が相手であり、挙動の安定性が重視されるため、月次や四半期ごとの計画的なリリースが求められます。社内向けは自社従業員が相手で、一定の自由が利くことと、開発サイクルは業務影響度に応じて変動可能です。

加えて、UI/UXにおいては、B2Cではより魅力が、B2Bでは信頼性や業務適合性が重視され、社内向けは業務効率が焦点です。フィードバックの取得方法も、B2CはA/Bテストなどで定量的に分析し、B2Bは営業経由で直接ヒアリングし、社内向けは利用者と密に連携するなど、それぞれ異なります。



こうした特性の違いによって、優先順位付けが難しくなってきます。B2C案件はユーザー数が多く影響は広範囲に及びますが、顧客単価は比較的小さくなるかもしれません。B2B案件は顧客単価は大きくなるかもしれないですが、影響範囲はその一社に限定されるかもしれません。そして社内案件は 直接的な売上には繋がらないかもしれませんが、業務やガバナンス上、不可欠で、直観的に使えるUIが求められます。

共有基盤はこのような特性・モチベーションの異なるサービスの各方面から要望が寄せられるため、限られた開発リソースをどのように優先順位をつけて配分するかという課題が発生します。

EID（Engineering Initiatives DB）と定量スコアリング

福井：この課題へのアプローチが、EID（Engineering Initiatives DB）と定量スコアリングです。まず、EIDについてですが、これは、エンジニアリングチームが取り組むイニシアチブを一元管理するデータベースです。

例えばJiraを使っていると、バックログのような概念で、「やることリスト」を作ったりすると思いますが、EIDでは特に「何を、なぜ行うのか」と「期待するアウトカム」を強調します。昨日のケント・ベック氏のキーノートをご覧になった方もいるかもしれませんが、「最後の終端を計測しよう」という話と同じで、アウトカムを意識することを重視しています。エンジニアもプロダクトマネージャーも、アウトカムを意識したいという思いからこの仕組みを運用しています。

これがあると、投資会議でのリクープ計画――いくら投資していくら回収し、何年でペイするか――を見やすくできます。また、アウトカムで計測すべき指標をあらかじめ可視化できます。「これは売上向上」「これはコスト削減」「これはガバナンス対策で利益には絡まない」といった区分を明確にして取り組んでいます。こうしてエンジニアの仕事の価値、アウトカムを明確化させることはできると思います。

創業期からEID誕生まで ― 背景と課題の顕在化

ここからは、Belongの第一創業期までの歩みを簡単に振り返ります。創業1年目は「にこスマ」とそれを支える在庫管理システムだけで、Excelと手作業でオペレーションを回すという、とにかく頑張るという感じでした。

その後、1年目以降〜4年目あたりでサービスが増え、B2B（Belong One）や買取サービス（にこスマ買取）が本格稼働しました。ノーコードツールも現在は活用していますが、「スケールはしなくても UI を素早く用意したい」など限られた領域で使える場面が見えてきました。この時期から、複数のプロダクトや複数のステークホルダーにサービスを提供する点で、どのステークホルダーを優先すべきかという課題が顕在化してきたのです。

この課題解決のために導入したのが、エンジニアリングチームが「何を行い、何を達成したいのか」をアウトカムとして提示する「EID」という仕組みです。これにより、経営陣も現在優先度の高いイニシアチブと、その想定する成果を理解しやすくなり、SSoT（Single Source of Truth）の実現にも繋がりました。

具体的なEIDの内容として、まず「やりたいこと」とその理由を明確にします。弊社は物理的な端末を扱うため、SaaSにはない「データと現物の同期をする」といった制限事項や、「これはスコープ外」というゴールではない点も明記します。また、期待するアウトカムと、その効果をどう可視化するか（例：「ダッシュボードで確認」「スプレッドシートで計測」）もあらかじめ定義し、誰でも後から効果を測定できる状態にします。



さらに、詳細設計前のラフな段階で解決策の仮説も立てます。プロダクトマネージャーやステークホルダーと議論しつつ、エンジニアが変更点を箇条書きで洗い出すことで開発工数を見積もり、どのイニシアチブをいつ実施するかの判断材料にするのです。

EIDの導入により良かった点は、ビジネスサイドの思惑が文書として可視化されるため、「こういう狙いがあってこの機能を使いたい」「このパートナーをオンボードしてこういうことを狙っている」といったイニシアチブの背景が分かるようになったことです。エンジニアからのフィードバックも行いやすくなり、「それをやるならここも変えないと後でブロッカーになります」「データが足りません」といった話が進みやすくなりました。

同時にエンジニアが生み出す価値も理解してもらいやすくなります。エンジニアは「プログラムを書くことが好き」という技術志向の人も多いですが、「あなたの仕事の価値はこういうところで会社に貢献している」と可視化できるのは良かった点です。

また、社内受託のようにしたくないという思いもあるため、エンジニアが「自分たちが作っているものをどうあってほしいか」を考えられるようにしたいとも考えており、EIDはこうしたプロダクトの在り方をお互いに議論するきっかけにもなっています。

新たな課題への対応 - 定量スコアリングの導入

一方で、新たな課題も生まれました。意思決定は結局属人化したままで、かつ戦略的重要度が高い課題が優先されます。「このイニシアチブにはこういう価値があります」とずらっと並ぶと、利益貢献が大きなものなどが優先して選ばれがちです。一方で、効果は小さいが短期間で終わるものも実はやりたいのに説明が難しく、事業的重要度が高いものが選ばれがちという課題が見つかりました。

成熟期に入ると、やりたいことが四半期ごとにたくさん出てきますが、プロダクトマネージャーとエンジニア、経営陣が集まる時間が限られ、「この時間取れないから来週に」となることもあります。属人性は依然として解消されていないので、それを改善するために定量的なスコアリングを取り入れることにしました。定量スコアリングは数値化により客観性が高まり、自動的にスコアの高い順に並べられます。客観的に比較し、数値が大きい順に実行していくことができます。



世の中にはイニシアチブを決める手法がいろいろありますが、まず採用を考えたのが ICE スコアリングです。ICEの「I」は Impact（売上などの影響度）、「C」は Confidence（そのイニシアチブに対する自信度）です。例えば「売上を500万円伸ばします」と言ったときに、それは本当ですか、どれくらい自信がありますか、を示します。「E」 は Ease ｘ（容易さ）で、どれくらいの期間で実現できるかの逆数、期間が短いほど数値が大きくなります。

ICE に近い概念として RICE スコアリングがあり、違いは Reach（特定期間内にどれだけのユーザーに影響を与えるか）を考慮するものです。Reach は B2C などでは有効ですが、弊社の場合は社内共有サービスで使いたいという動機があり、ユーザー数をそこまで考慮する必要がないものも多いと判断したため、ICE を採用しました。



具体的な運用ルールは以下の通りです。



ICEスコアでは一般的に 1〜10 のスケールを推奨する例がウェブなどに出ていますが、 1〜10 だと逆に設定する側が分かりづらく、「どの程度の差がどの数字に当たるのか」を定義するのが大変です。そこでまずは 1〜5 のスケールで始めました。

インパクトの指標には売上の伸びだけでなくコストダウンも含め、利益への影響度と比例するよう設定しています。同時に、利益では測りづらいガバナンス対応やインシデント再発防止策も考慮して数値が設定できるようルールを決めて運用しています。Confidenceの指標では、たとえばPoCで一度効果検証したものは数値を高く設定します。市場調査で一般的に言われている程度の裏付けがある場合は中程度、何となく「行けそうな気がする」程度なら低く設定するというルールです。Ease の指標では、開発期間が 1〜2 週間で完了するものを最も高く、1 か月ならその次、という基準で設定しています。

これらの数値を掛け合わせたものが最終スコアになりますが、定性的な価値も考慮が必要です。会社の戦略上、Confidenceやインパクトが読みづらくても「どうしてもやりたい」という案件は、インパクトを 100などに補正して調整できる余地を残しました。

ICE スコアリングを導入した結果、大半のイニシアチブは自動的に順位が決まるようになりました。同時に、実施するイニシアチブの幅が広がりました。従来は期間が短くとも利益貢献度の低いものは評価されづらかったですが、期間の短さでスコアが上がる仕組みにしたことで、インパクトがやや小さくても期間が短い案件に着手しやすくなり、狙い通りに機能しています。



一方、属人性の課題は一部残っており、話し合い自体は必要です。ビジネス戦略上、不確実でも「ビッグパートナーとの連携はやりたい」「将来展開の布石として先にやっておきたい」といった定性的価値の高い案件は、インパクトを 100 などに設定して引き続き対応しています。一方で、そういったケースが増えるとスコアリングの意味がないので、基本的には自動的にメンバー側で決められるようにしたいと思っています。

スコアリングをすることでの難しさもあります。例えば、ステークホルダー間で目線を合わせるのは意外に難しく、スコア自体は定量でも「どの数値を付けるか」は属人的になりがちです。売上の数値については基準を決めて対応できるのですが、ガバナンスの部分は結局どうしようかとなり、いろいろとバランスを取りつつルールを作る必要があります。業績至上主義にならないようにはしたいですが、包括的なルールを決めるのは難しく感じてもいます。

たとえば AI 開発のための環境整備では、AI を使うだけなら予算を確保するだけですが、みんなが同じドキュメントを読んで学習するのは効率が悪いので、プラットフォームエンジニアリングチームで「この設定をすればすぐ使える」という環境を用意しています。ただ、それが売上をどれだけ伸ばすか、開発スピードがどれほど高まるかは読みきれないため、とにかく現状のエンジニアの開発生産性が向上して欲しい思いで推し進めるような形にもなります。こういった数値化が難しいものは、ルールを設けてスコア設定方法に反映する必要があります。

成果・課題・今後 ― 自動順位決定と拠点拡大、残る属人性への挑戦

福井：今、Belongは「改革期」に入ろうとしています。ニューヨークは Belong にとってこれから改革期に入る拠点で、正直どうなるか読めない状態にはあります。伊藤忠のグローバルネットワークに関連してニューヨークに新しい拠点、オペレーションセンターが増えました。メインの開発拠点は日本ですが、向こうのイニシアチブを考えたり、日本からエンジニアをアメリカに送り対応したりする必要があります。（Belong Tech Blog: 日本発事業会社としてグローバルビジネス展開する価値）

日本では日本でやりたいことがあり、別の拠点でもやりたいことがあると、どちらの優先順位が高いのか、どれから着手するかがより難しくなっていきます。会社規模が大きくなると部署や拠点が増え、同様の課題が生じると思います。一方で、今回の EID とスコアリングはこうした状況でも適用可能だと感じています。



まとめになります。まず今回のお話ですが、イニシアチブの優先順位付けには難しさがあるという話をしました。B2C・B2B・社内向けではユーザー属性によってフィードバックの取り方や、あるべき開発サイクルが異なります。各サービスの影響を受ける共有基盤では、どれを優先するかが特に難しくなります。

そこで「何をやりたいのか」「なぜやりたいのか」「期待するアウトカムは何か」を可視化し、そのうえでどれから実行するかを議論すると優先順位が分かりやすくなります。話し合いだけだと属人性が高まるため、スコアリングと合わせ技で、定性的な価値も可視化しつつ、スコアで大まかに決め、最後に調整する流れにすると、効率化しつつアカウンタビリティも担保しやすいです。

最後に、弊社はエンジニアを大募集中です。ニューヨークで働きたい方や、マネージャーとして今回のような取り組みに関わってみたい方、データモデリングやサービス立ち上げに関心のある方も大歓迎です。カジュアル面談だけでも構いませんので、お声がけいただけると嬉しいです。

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

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です