【DB勉強会】03_プロダクトづくりとサービス設計（ビジネスモデルと価値設計も）

【製造業データビジネス勉強会】03 プロダクトづくりとサービス設計 （ビジネスモデルと価値設計も） 2026/04/21 @shimitaka1982 清水 隆史

今日の 勉強どころ

データビジネスの階層構造 プロセス 現時点の 個人的な感触 新規事業創出 プロジェクトマネジメント ビジネスモデル 要求分析・要件定義 プロダクトマネジメント リスクマネジメント プラクティ ス マインドセット 人材育成 ビジネス力 データサイエンス力 データエンジニアリング 力

データビジネスの進め方 ① 事業設計 ② サービス設計 ③ データ準備 ④ 探索的データ分析 ⑤ モデル構築 ⑥ 社会実装 ⑦ 保守・運用 現時点の 個人的な感触 • いずれも単方向ではなく、 行ったり来たりを繰り返す • 全てを行うわけではなく、 途中から始まったり途中で 終わったりすることもある • 初期の段階で後期の要素を 考えておく必要がある

用語の統一

用語の統一 この勉強会における用語の理解を合わせたい 以下のような言葉をよく聞く ✓新規事業 ✓イノベーション ✓サービス ✓プロダクト ✓ソリューション ✓システム 新規○○と言われることも

イメージ 現時点の 個人的な感触 異論は 認める 事業 商材C （ソリュー ションγ） 商材A （製品α） プロダクト 商材B （サービ スβ） 商材E （人出し） 商材D （システム δ） 事業基盤 （体制とか人財とか）

細かい違い プロダクトは汎用型、ソリューションは特化型 （※この話はまた後で） プロダクトの中にサービスと製品が含まれるイメージ （※ここでいう製品はハードウェア製品のこと） ソリューションの原義は「解決方法」。顧客課題を解 決するためにサービスや製品（つまりプロダクト）や システムなどを状況に応じて活用するイメージ イノベーションはこういった一連の活動の集合体

データの 活用どころ

データの活用どころはいくらでもある （例）製品αの量産で不具合データ分析をしたい （例）データ分析の外販サービスをサービスβとしたい （例）ソリューションγとして機器の故障を予測したい （例）システムδとして BIダッシュボード機能を 開発したい （例）これらのことが 出来る人財を育成したい

ここではサービスを対象とする データの活動どころは様々だが、ここではサービスに ついて対象とする データを取得してそのデータ分析を行い顧客課題を 解決するサービス について考えてみる （自分はたまたま こういったサービスを 立ちあげたので考え やすい）

プロダクト マネジメント

価値を明確にすることが大切 前回こんな話をした サービス≒コト売りと解釈すれば、サービス設計にお いても「なにが価値か」を考えることが超重要になる

人財・体制を整えることが大切 こんな話もした サービス≒コト売りと解釈すれば、サービス設計にお いても必要な人財・体制を整えることが超重要になる

プロダクトマネジメントの考え方 サービス設計のためには プロダクトマネジメントの 考え方を身に付けると良い というか、自分自身もこの プロダクトマネジメントの 考え方に強く影響を受けて サービス設計をして開発・ リリースした 『プロダクトマネジメントのすべて 事業戦略・IT開発・UX デザイン・マーケティングからチーム・組織運営まで』 https://amzn.asia/d/0aQXT0pe

• https://amzn.asia/d/0aQXT0pe

（参考）ITIL サービスマネジメントの知識体系としてはITIL （Information Technology Infrastructure Library： アイティル）が有名 現在は2026年2月にリリースされたITIL5が最新版 ただし日本語版のリリース時期は未定であるため、 まずはITIL4の学習を進めるのが良いとされている* またサービスづくりというよりもサービスの継続的 運用に焦点を当ててきた歴史があり *ITIL®の新バージョン「ITIL® (Version 5)」の発表について | ITプレナーズ https://www.itpreneurs.co.jp/news/20260216itilversion5/

• https://www.itpreneurs.co.jp/news/20260216itilversion5/

『プロダクトマネジメントのすべて』の 紹介を見てみよう プロダクトマネジメントに欠かせない知識、スキル、 方法論、マインドセットを網羅しているため ●新事業・新サービス開発 ●既存事業テコ入れ ●DX ●起業 ●スタートアップ にかかわるすべてのマネージャー、エンジニア、デザ イナーにとっては必読の完全保存版 https://www.shoeisha.co.jp/book/detail/9784798166520

• https://www.shoeisha.co.jp/book/detail/9784798166520

『プロダクトマネジメントのすべて』の 目次を見てみよう 【目次概要】 PartⅠ プロダクトの成功 PartⅡ プロダクトを育てる PartⅢ ステークホルダーをまとめ、プロダクトチー ムを率いる PartⅣ プロダクトの置かれた状況を理解する PartⅤ プロダクトマネージャーと組織の成長 PartⅥ プロダクトマネージャーに必要な基礎知識 https://www.shoeisha.co.jp/book/detail/9784798166520

• https://www.shoeisha.co.jp/book/detail/9784798166520

プロジェクト マネジメント

プロジェクトとプロダクトの違い この辺に書いた *プロジェクトとプロダクトの違いについて学ぼう！ https://www.docswell.com/s/shimitaka/ZR243R-po-pjm-pdm

• https://www.docswell.com/s/shimitaka/ZR243R-po-pjm-pdm

どちらも大事！ サービス設計においてはプロダクトマネジメントと プロジェクトマネジメントの両方の考え方が大事 プロダクトマネジメント観点 ✓（例）このサービスの価値は何か？ ✓（例）このサービス開発・運営にはどのような人財・体制が必要か？ プロジェクトマネジメント観点 ✓（例）このサービスのリスクは何でどのような対応が必要か？ ✓（例）このサービスのステークホルダは誰でどのような対応が必要か？

誤解を恐れずに超分かりやすく言うと プロダクト マネジメント プロジェクト マネジメント 攻め 守り

サービス成功の 3要素

プロダクトを成功させる3要素 ビジョン ✓「プロダクトを通してつくり出したい未来の世界観」 ユーザー価値 ✓「ユーザーに価値があると感じてもらい、使い続けてもらう」 事業収益 ✓「市場を観察し、競合とは異なる戦略を打ち出してビジネスモデルを 構築する」 この3要素はサービス成功の為にも必要 （出典）『プロダクトマネジメントのすべて 事業戦略・IT開発・ UXデザイン・マーケティングからチーム・組織運営まで』 https://amzn.asia/d/0aQXT0pe

• https://amzn.asia/d/0aQXT0pe

ビジョン 経験的には以下を明確化することが多い ✓Mission/Vision/Valueの制定 ✓「我々はなぜここにいるのか」*の検討 Mission/Vision/Valueは会社や事業部やチームとして 規定している場合もある より上位のものからオーバーライドしてもよい 全部考えなくてもよい *「我々はなぜここにいるのか」は書籍『アジャイルサムライ』の インセプションデッキの中に出てくるアクティビティのひとつ

ユーザー価値 ビジネスモデルと合わせて考えると良さそう 後の章で考えてみる 「ビジネスモデルと価値」の章へ

事業収益 どこで収益をあげるか？を設計する 特にデータビジネスは収益性の確保が非常に難しい。 なぜなら、何かモノを販売するわけではないため、 売る方も買う方も具体的な成果物が分かりづらいため これは、サービス全般について言えること 「ビジネスモデルと価値」の章へ

ビジネスモデル と価値

ビジネスモデルを考えてみる* No. ビジネスモデル 社内 価値（売りもの） 事例 1 SaaS × ソフトウェアサービス （Webアプリ、スマホアプリ） Speeda 2 コンサルビジネス △ コンサル（アドバイザリー） アクセンチュア 3 受託分析・開発 △ 分析行為や開発アウトプット ブレインパッド 4 人財育成・教育 ○ 研修・研修資料 Udemy 5 データ販売・流通 × データそのもの （またはその流通プラットフォーム） ※あまり事例を見ない （POSデータなど？） 6 インサイト・レ ポート販売 △ レポートそのもの （またはその流通プラットフォーム） 大手総研等のレポート 7 アルゴリズム提供 △ アルゴリズム ※ほぼ事例を見ない （アルゴリズム単体というより人財も 含めた企業買収ならある） *あくまで清水の所感なのでこれがすべてというわけではありません

ビジネスモデル所感* SaaS＋コンサル＋人財育成が無難 ただ、SaaSは製造業には難しい（理由は後述） コンサルも製造業には難しい（理由は後述） 受託分析・開発も製造業には難しい（理由は後述） 人財育成・教育は儲からない（詳細は後述） インサイト・レポート販売は1ショットになりがちで 継続性が難しい（詳細は後述） *繰り返しになりますが、あくまで清水の所感です

SaaSは製造業には難しい ソフトウェア開発人材が少ない ソフトウェア運用人材が少ない ソフトウェアを開発して運用してそれで価値を提供する という文化が乏しい （いまだにハードウェアのおまけ、という意識が強い） サービスというビジネスモデルをやったことが少ない マーケティングの考え方も乏しい つまり、体制・文化・スキルが未成熟

とはいえ、ポテンシャルはある ソフトウェア人材もかなり増えてきた（気がする） 20代～30代はソフトウェアネイティブ世代 SaaSも一般的に広く普及しており、仕事でもプライ ベートでも使っているからイメージができる 製造業にはデータがたくさんたまっている （使いものになるかどうかは別の話） みんな真面目で勉強熱心

コンサルも製造業には難しい 「知見とデータを生かしてコンサルビジネスやろう」と いう話もよく出てくる ただ製造業にはコンサル人材が少ない ✓ここで言っているコンサル人材とは、顧客の課題に着目して、その課題 を整理し、その解決方法を複数立案し、解決方法を主体的に実行した上 で、顧客の課題解決と目的達成にコミットメントできる人 （目的は顧客による） ✓コンサル人材が社内にいないのに、コンサル事業をやろう という謎の判断になることが多い ✓もしかしたら、コンサルを甘く見てるのかもしれない

とはいえ、ポテンシャルはある 課題解決や課題整理というのは非常に頭を使う 製造業にいる人はみんな真面目で勉強熱心で頭がいい 実際、製造業からコンサルに転職する人は大勢いる スキルやマインドに適性があるからだと思われる 言い方を変えると、人財のポテンシャルは非常に高い。 あとはその人財が仕組みや体制にうまくハマれば、コン サルビジネスは製造業でも成り立つと思われる （というか、私はやっていた）

受託分析・開発も製造業には難しい これはスキルや体制の問題というよりも、単純に単価 が見合わないから 受託分析や受託開発は人月商売になることが多い ✓（例）1人月150万円の人を3人3か月間送り込みます→1350万円 ただ、製造業の単価は基本的に高いため、金額感が合 わない場合が多い ✓（例）例えば顧客のクラスタリングを1,350万円で委託するという会社 はほぼないと思われる 生成AIの台頭で委託が少なくなっている（らしい）

人財育成・教育は儲からない ニーズはあるが人財育成にかける費用（確保している 予算）はどの会社もそんなに多くはない 人財育成・教育のみでビジネスを行うのは厳しいが、 それを起点にして他のビジネスに拡大するということ は大いにありうる また、他のビジネスを行うための 土壌として人財育成・教育から入る というケースもある （例：BIを販売する前に統計学を学ぶ）

インサイト・レポート販売は1ショット データから何かしらのインサイトを割り出してレポート として作成しそれを販売する、というビジネスモデルも ある（私は過去そういったビジネスもしていた） これはニーズにもよるが、1ショットになりがちで、い わゆる売り切りビジネスのような形になる。 そのため、営業・マーケティングコストがかさむうえ、 収益性が安定しないため、売上が読みづらい（持続性と いう観点で会社としては投資しにくい）

結論 サービス単発での収益化は難しい 複数の商材でお互いの良さを補完し合うことで全体と してビジネスが成り立つという構造を設計したい つまりサービス設計が 事業設計に繋がる 事業と商材はいったり きたりして検討する

おまけ こうやっていったりきたりしながら全体の妥当性検討 をしていくのがプロダクトマネジメントの神髄 極めて範囲が広いことをやる 一方で製造業では部署ごとで役割分担しがち ✓戦略を立てる人、事業計画を立てる人、商材を考える人、開発する人 …など だから人任せになったりお見合いになったりして うまくいかないことが多い

サービス設計

出口から逆算して価値を設計する おすすめなのが出口から逆算して価値を設計すること 出口とは ✓最終的なアウトプットの脳内イメージ • 例：この前使った●●みたいなアプリをつくりたい ✓サービス提供後のチームやステークホルダの感情 • 例：こんな分析をしたらお客さんがめちゃくちゃ喜んでくれそう • 例：こんなサービスが提供できたら誇りになりそう ✓想像を膨らませることが大事 ユースケースを考えて言葉や図にしてみる

（参考）ユーザーストーリー アジャイル（スクラム・XP）でよく使われる形式 以下のテンプレートを使うことが多い ✓誰にとって必要なプロダクトなのか ✓ユーザー（または特定のペルソナ）が何を求めているのか ✓その開発するプロダクトにより、どんな目的を果たせるのか （例） ✓工場の工作機械の運用担当者にとって ✓特定の工作機械の故障予測時期が分かるようにしたい ✓なぜなら無駄のない点検スケジュールを立てることができるからだ

【コツ1】継続性を担保した運用設計 機械学習モデルの陳腐化（ドリフト）対策 ✓市場環境やユーザー行動の変化でモデルの精度は落ちる ✓精度の監視および新しいモデルの即時アップデートのMLOps環境整備 アプリ運用の継続監視 ✓不具合が発生していないか継続的に監視を続ける ✓不具合発生時のリリースや再発防止策などの対応を決めておく カスタマーサクセス ✓顧客の満足度やニーズを定期的に確認し（アンケートなど）、その フィードバックをサービスに活かす体制づくりが必要

【コツ2】現場への「手触り感」の提供 説明性の確保（XAI） ✓なぜその結果になったのか根拠（特徴量）を提示する ✓分かりやすく説明する（専門用語を使わなくても分かるようにする） 現場の感覚との整合 ✓現場で「予測が外れていた」場合のフィードバックの仕組み整備 業務フローへの統合 ✓現在使っているツールや業務フローと自然に接続され、使用すること に違和感がないようにする

【コツ3】リスクとコストを考える コストの把握 ✓リアルタイム処理が必要か、バッチ処理で十分か。それによってコス トが変わってくる。 法規制とプライバシー対応 ✓個人情報保護法や各種ガイドラインへの準拠が必要 ✓特に「目的外利用」にならないかの確認が必要 責任分界点 ✓機械学習モデルの判断は「正解」ではない ✓機械学習モデルの提案に従って損失が出た場合に誰が責任を持つのか、 ガードレールを設計する必要がある

全部PMBOKに書いてあった PMBOKの最新版（第8版）には以下のパフォーマンス 領域の記述がある。ひとまずこれらの項目をサービス設 計として考えるところから始めてみよう。 ✓ガバナンス：（例）法的リスクや社内稟議の段取りはどうなっているか ✓スコープ：（例）そもそもプロジェクトとしてどこまでやるのか ✓スケジュール：（例）いつまでに何をやるのか ✓ファイナンス：（例）予算はいくらで何にどれだけつかうのか ✓ステークホルダ：（例）ステークホルダは誰で何に関心があるのか ✓リソース：（例）誰が作業にあたれるのか ✓リスク：（例）どのようなリスクがありどう対応するのか

今日のまとめ サービス設計は「出口」からの逆算で価値を決める 「運用」を初期段階から組み込む（MLOpsと継続性） 現場への「手触り感」と業務フローへの統合 ビジネスモデルは「組み合わせ」で収益性を担保する プロダクトマネジメント（攻め）とプロジェクトマネ ジメント（守り）の両立

Thank You !!