B2C＆B2B＆社内向けサービスを抱える 開発組織におけるサービス価値を 最大化するイニシアチブ管理 株式会社 Belong 執行役員 CTO 福井達也 (@ttyfky) 2025.07.04 開発生産性 Conference 2025 

会社・事業紹介 01 02 03 一般的なイニシアチブ管理 Belong特有の課題 CONTENTS 2 04 EID と 定量スコアリング 

自己紹介 3 -PROFILE- Tatsuya Fukui (@ttyfky) CTO @ Belong Inc. (2020/06~) TSE @ Google (2018/07~) SWE @ Goldman Sachs (2013/04~) Belong 釣り部部長 (Chief Tsuri Officer) ©Belong Inc. 

01 About the Company 

5 携帯関連の新規事業を目的に 伊藤忠商事の 100％子会社(間接保有 含む)として設立 セキュリティーなど独自の基準をクリアし た中古品をアジアや北米など世界中か ら低価格で仕入れが可能 会社名 株式会社Belong 会社設立 2019年2月 所在地 東京都港区赤坂6-4-10 赤坂ZENビル 4F オペレーション センター 神奈川県座間市広野台2丁目10番10号 GLP座間 3階 社員数 社員数：259名（派遣社員含む）（ 2025年3月末時点） 資本金 1億円 日本最大級規模のオペレーションセ ンターで、選抜されたスタッフが丁寧 に管理、検品を実施しています。 伊藤忠グループの安心ネットワーク 自社運営のオペレーションセンターで品質担保 会社概要 

多様なルートから調達した端末を、自社オペレーションセンターにて検品し、改めて適切な販路にて販売しています。 端末の検品からデータ消去、配送まで対応 オペレーションセンター 入荷 検査 消去 差配 中古スマホ価格分析プラットフォーム 検品 利用 海外 国内B2B リサイクル 国内B2C 端末調達 海外拠点から 法人から 個人から 個人から 法人から 6 ©Belong Inc. Belongの事業｜Product Map 販売サービス 買取サービス 

7 Service slogan 中古だからこそ、全ての人に、正直に。 徹底した透明性で、安心を届けます。 わたしたちは常に「正直であること」を信条に、 すべての人に中古関連のサービスを提供してまいります。 お客様が安心して中古スマホライフを送れるよう、 Belongは日々進化していきます。 

リユースデバイスの商売に なぜエンジニアリングが必要なのか？ 8 ©Belong Inc. 01. 年間 100 万台以上の取り扱い 02. 個別管理の難しさ 03. 価格の流動性 04. 利益最大化のための動的差配 model storage battery_health grade iPhone 13 128GB 97 A iPhone 13 128GB 83 B iPhone 13 128GB 90 C 国内 vs. 海外 個人 vs. 法人 

Belong エンジニアリングのチーム体制 9 ©Belong Inc. 

生成 AI の活発な利活用 10 ©Belong Inc. Belong は比較的早い段階から、 生成AI の利用やプロダクトとの連携を試みている 詳しくは以下 : Workflow から Agent へ ~生成AIアプリの成長過程とアプローチ ~ 2025.06.18 AI Engineering Summit 

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

イニシアチブの決定方法 12 エンジニアが取り組むイニシアチブはどう決めていますか？ ©Belong Inc. 新サービス - ローンチドリブン 運用中サービス - ロードマップ 

1. アイデアの収集・発掘 • 企業戦略上やりたいこと • プロダクトマネージャーなどが追加したい機能を提案 • 顧客からのフィードバック • エンジニア視点で改善点や非機能要件を提案 2. アイディアの評価・選定 • 戦略適合性 / 収益性 / 実現可能性 などを評価 3. 投資会議 4. 開発~リリース 一般的なイニシアチブの決定方法 13 ©Belong Inc. 

基本的には「既存の機能の安定利用を優先する」という考え方 開発優先順位ガイドライン 14 ©Belong Inc. Priority Issue Type Description 1 Security Issue Security is the most important matter. Security issue can may cause data violation and reputation problem. 2 Data-loss prevention Data loss is one of the worst issue that may cause business continuous concern, and reputation issue. 3 Availability, Incident Corrective Actions Service unavailability should require high attention. 4 Regression Issue, Functional Bug Things that worked before, or working unintended way. 5 Performance Improvement Performance of existing functionality directly impacts to UX. 6 Issue prioritized by special request Something requested by key customer or management. 7 System Monitoring/Alerting Monitoring or instrumentation related such as Logging, Tracing, Monitoring 8 New Features, Tech Debt, Usability Improvement UI/UX issue for existing functionality. Belong で実際に利用する開発優先順位ガイドライン 今回の話は #8 の新機能などの優先順位付けが主になる 

03 Belong特有の課題 

我々の開発組織が向き合う多様なサービス群 16 Belong は 3 タイプの異なるユーザー属性向けのサービス開発が必要 ©Belong Inc. B2C B2B 社内向け 

共有プラットフォームにおける優先付けが特に難しい 17 ©Belong Inc. 

サービス特性の根本的な違い 18 ©Belong Inc. 特性 B2C (例: EC サイト ) B2B (例: 企業向け SaaS) 社内向け (例:在庫管理システム ) ユーザー属性 不特定多数の個人、多様な嗜好・リテ ラシー 特定企業の担当者、業務遂行目的 自社従業員、業務効率化目的 開発サイクル 高頻度なリリースが可能 計画的かつ、月〜四半期ごとなどで一定粒度の変 更が期待される 可変（緊急度、業務影響による） 要求される品質 UI/UXの魅力、動作の軽快さ 高い信頼性、セキュリティ、業務適合性 操作の簡便性、安定性、業務効率 ビジネスモデル 購買、広告、有料会員 ライセンス料、サブスクリプション 事業サポート（直接収益なし） 成功指標(KPI) MAU、DAU、エンゲージメント率、 CVR MRR、顧客継続率、解約率、導入企業数 業務処理時間短縮、業務標準化、 オンボーディング時間短縮 

フィードバック取得方法の違い 19 ©Belong Inc. B2C B2B 社内向け 傾向 間接的なものが主 直接的かつ少数 直接的かつ具体的 特徴 - 大量かつ広範囲 - 匿名性が高く率直 - 定量データ（評価、 PV数など）と定性 データが混在 - 具体的で業務に即した意見が多い - 契約関係に基づき、建設的な意見交換 - 少数だが深いフィードバック - 組織としての意見として集約されることも - 直接的で具体的な意見が集まりやすい - 利用が半強制的となり、サイレントマジョリ ティの声が拾いにくいことも チャネル - アクセス解析、利用状況データ - ユーザーインタビュー・テスト - カスタマーサポート (電話, メール, チャット) - アンケートフォーム - 口コミ - SNS - 営業担当、アカウントマネージャー経由 - カスタマーサクセス担当経由 - サポート窓口 (電話, メール, ポータル) - 定期的なミーティング - 利用部門からの直接ヒアリング - 利用データ分析 - 社内アンケート、サーベイ 

無視できない「共通の課題」 20 ©Belong Inc. ● 優先順位付けの複雑性及び期待のコンフリクト ○ B2Cはユーザー数が多く影響範囲が広い ○ B2Bは一社あたりの売上が大きい ○ 社内システムは直接的な売上には繋がらないが業務上重要 ● リソースの分散と最適配分の困難さ ○ 特に共通基盤は B2C or B2B or 社内 のどれに影響があるイニシアチブを進め るかを決める必要がある ○ 「B2C向けの機能改善、B2B案件向けの大型機能開発、そして社内システムの 高速化対応…どれに優先的にエンジニアをアサインすべきか？」 限られた開発リソース（人員・予算）を、緊急度も重要度も異なる複数のサービ スにどう配分するかの判断が常に難しい 

04 EID (Engineering Initiatives DB) と 定量スコアリング 

22 EID (Engineering Initiatives DB) 

EID (Engineering Initiatives DB) とはなにか？ 23 EID: エンジニアリングチームが取り組むイニシアチブを記録するためのDB EIDR: EID の各レコード（イニシアチブごと）のことを指す ● バックログの概念に近いが、「何を、なぜおこなうのか 」「期待するアウトカムはなに か」を強調するもの ● 投資会議におけるリクープ(投資回収)計画や、イニシアチブ実施結果の効果レビュー に直接的につながる形で記載する エンジニアの仕事の価値（アウトカム）を明確化させる役割 ©Belong Inc. 

組織フェーズによる対応の変遷 24 ©Belong Inc. 今このあたり 

創業期(~1年) 25 小さい組織・小さいサービスであるため細かいことを考え る必要(余裕)もなかった ● 在庫管理システム (社内向け) ● EC 販売 (B2C) そもそも「これがないと仕事が回らない」が多い ©Belong Inc. 

成長期(~4年) 26 ● B2B や買取などが本格的に動き出した ● No Code などで簡易的に使えるような仕組みも導入 ● 複数のプロダクト、複数のステークホルダー 「どのステークホルダーのイニシアチブを優先するべきなのか？」 ©Belong Inc. 販売サービス 買取サービス 

EID によるイニシアチブ要望管理の実施 27 ● エンジニアリングチームが取り組むイニシアチブを記録（What） ● 何を行いたいのか、それはなぜなのかを明確化（Why） ● イニシアチブの結果から得られると期待されるもの、 想定アウトカムの提示 （Goal） 経営陣を含めシニアマネジメントメンバーが中心に会話を行い方向を決 めるための情報の SSoT (Single Source of Truth) とする ©Belong Inc. 

EID の内容 28 ● やりたいこと - 解決したい課題 ● 背景 - モチベーションや課題・困っていることについて ● 制限事項 - 取り組むにあたり避けたり考慮するべきことがあれば記載 ● 期待する成果・アウトカム - イニシアチブを実施することで得たい結果や効果 ○ 対象を測定・確認する方法 - 現状を知る方法。 ○ １ヶ月後の状態 - 結果 ○ 四半期後の状態 - 結果 ● 解決策の仮説 - プロダクトマネージャーとエンジニアの認識を合わせるためのヒント ● スコープに含めないもの - スコープに含めない、含めるべきでないもの ©Belong Inc. 

EID を作って良かった点 29 ● ビジネスサイドの思惑、向かう方向性が明確化されると同時に、エンジニア からのフィードバックも行いやすくなる ● エンジニアが生み出すビジネス価値が可視化される エンジニアも「プロダクトのあるべき姿」を考え、提案するBelongのカル チャーにフィットする ©Belong Inc. 

EID を運用して見られた課題 30 ● 意思決定の属人化 ● 戦略的重要度の高い課題が優先される 一方で、ちょっとした改善が後回 しにされがち ○ 「効果はともかく、すぐ終わるからやっておこう」が進めづらい 安宅和人 (著) 『イシューからはじめよ ――知的生産の「シンプルな本質」 ©Belong Inc. 

成熟期 31 規模が大きくなり、より属人性を排除した仕組みが欲しくなる ● 毎回 PdM + エンジニア + 経営陣が集まる必要があるとスケールしない 定量で自動的に優先順位が程度決まる形が嬉しいのではないか？ ⇒スコアリング ©Belong Inc. 販売サービス 買取サービス 

32 定量スコアリング 

定量スコアリングとはなにか ? 33 施策やアイデアの優先順位を客観的な基準 に基づいて 数値化（スコアリング） し、比較検討する手法 ● 自動的にスコアの高い順で並べるなど、客観的な比較が容易になる ©Belong Inc. 

イニシアチブ選定手法の有力な候補 34 ICE スコアリング ● 要素 ○ Impact (インパクト): イニシアチブの影響度 ○ Confidence (信頼度): 推定に対する自信度 ○ Ease (容易さ): 実装の容易さ ● 計算式: Impact * Confidence * Ease RICE スコアリング ● 要素 ○ Reach (リーチ): 特定期間内にどれだけのユーザーに影響を与えるか ○ Impact (インパクト): イニシアチブの影響度 ○ Confidence (信頼度): 推定に対する自信度 ○ Effort (労力): 必要なリソース（時間、人数など） ● 計算式: (Reach * Impact * Confidence) / Effort ⇒ ICE スコアリングに決定 ©Belong Inc. 

ICE スコアリングの運用ルール 35 ● Impact - 基準に従い 1~5 のスコアを付ける ○ 売上/利益 n万円など ○ ガバナンスの対応やインシデントフォローアップなど、業績に直接紐づかないもの も考慮する ● Confidence - 基準に従い 1~5 のスコアを付ける ○ PoC による効果検証、市場調査結果、思いつきレベルなどの確度 ● Ease - 基準に従い 1~5 のスコアを付ける ○ 想定開発期間が短いものから点数が高くなる 最終的に各スコアの乗算で優先度が算出されるが、定性的価値 や 会社の戦略 を鑑みて Impact を 100 にするなどの調整余地を残す ©Belong Inc. 

ICE スコアリングを導入した結果 36 ● 投資会議の前におおよそのイニシアチブは決まる ● 実施するイニシアチブの幅は広がった ● 一方で、結局話し合いは必要 ○ ビジネス戦略上イニシアチブの定性価値は無視できない ■ ビッグパートナーとの連携 ■ 今後のビジネス展開の布石 ■ 実験的施策の実施 ©Belong Inc. Quick Wins Fill Ins Major Project 

Impact スコアの目線合わせが難しい ● ステークホルダーの認識合わせ ○ スコア自体は定量だが、スコアの付け方は主観の余地を残す ● 業績至上主義にならないような意識(条件付け)が必要 ○ Impact で売上・利益だけではなく、ガバナンスであったり、定性的に価値があるも のにも高いスコアを与えられる設計が必要 ■ AI 開発のための環境整備 ■ 非機能要件や予防的施策などを織り込む ● 確率は低いが影響が大きなインシデント防止など ICE スコアリングの難しさ 37 ©Belong Inc. 

改革期 38 Belong にとってはこれから ● ニューヨークの拠点ができた大きな変化 ← New! ○ メインの開発拠点は日本予定 ■ 米国の開発メンバーも必要 ● 日本と米国、それぞれ別に必要な機能の優先順位付け ○ 日本でも要望は山積みだが、米国立ち上げのイニシアチブも重要 ● 今回の話はおそらく適用可能 ©Belong Inc. 

05 まとめ 

まとめ 40 ● Belong のイニシアチブ優先順位付けの難しさの紹介 ○ B2C・B2B・社内向け、という異なるユーザー属性向けサービス提供を行っ ており、開発の優先順位付けが難しい ● EID のルールを規定し、エンジニアリングチームが取り組むイニシアチブの目 的・背景や期待するアウトカムを可視化 ○ エンジニアの仕事の価値がわかりやすくなる ● ICE スコアリングの導入 ○ より機械的に優先順位付けが出来るよう定量指標を利用 ©Belong Inc. 

告知 41 Belong Study - 生成 AI パネルディスカッション 開催します 7/18 (Fri.) 12:00~13:00 ©Belong Inc. 第一部: エンジニアメンバーによる生成 AI の開発における活用 ● 開発における生成 AI の使い方、利用中のツールなどの深堀り 第二部: B2C&B2B&社内システムのプロダクトマネージャーが生成 AI についての思いを語る ● プロダクトマネージャーとしての生成 AI との向き合い方 ● エンジニアに期待したいこと 

各職種採用中！ 42 ● イニシアチブをリードしたい Tech Lead ● イニシアチブの優先順位を裁量を持って考え実行したい EM ● データを分析し価格トレンド予測や在庫差配モデルを行うデータサイエン ティスト ● ニューヨークで働きたいエンジニア ● etc. ©Belong Inc. 各種エンジニア採用中です！ - 求人情報