無料マンガ・ラノベなど、豊富なラインナップで201万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで201万冊以上配信中！
◎400を超えるAIプロジェクトの伴走実績から生まれた、AI経営の実践書
◎AIで「売上を伸ばす」ことを正面から論じた一冊
AIで1円を削ることには成功しても、100万円を創るところまでは届いていない。
いま多くの日本企業が直面しているのは、この壁です。
◆こんな課題を抱えていませんか？
・自社のAI活用が効率化の域を出ていない
・全社員に生成AIのアカウントを配っただけ
・AIプロジェクトの進め方に、手応えが感じられない
・そもそも、どの領域に本格的な投資をすべきか分からない
◆「効率化」と「新規事業創出」のあいだに、最大の機会がある
多くの企業は、AI活用を「今やっていることの効率化」か「まったく新しい挑戦」の2択で捉えています。前者では経営インパクトが小さく、後者は飛躍が大きすぎる。だから動けない。
本書が提案するのは、この2択そのものを見直すことです。
すでに手元にある顧客基盤、業務データ、技術的知見、現場のノウハウ。それらを起点に、AIで売上の構造を変えていく。著者はこれを「事業深化」と呼びます。日本企業にとって最も現実的で、最もインパクトの大きい領域です。
◆本書が提示するもの
・売上を伸ばすAI活用の全体像「AI活用の3段階モデル」
・AIが売上のどこに効くのかを見極める「2つの式」
・製造、通信、建設、小売、教育、自治体、化学など10業種の導入事例
・汎用AIツールで済ませてはいけない領域の見極め方
・なぜ従来のプロジェクト管理がAIでは足枷になるのか
・作るべきはAIモデルではなく業務プロセスだとする「MVPP」
・「精度95%」に固執せず着地点を設計する考え方
・不確実性を制御する「振動型マネジメント」
・撤退基準の置き方と、投資が丸損にならない構造
・技術とビジネスを翻訳する新職種「ソリューションデザイナ」
・AI推進体制の2類型と、意思決定の3機能
・AIを「第4の経営資源」として管理する2層のガバナンス
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
著者の主張・6つのスキル体系・育成方法・事業開発への示唆がつながる形で詳細に整理します。
『日本企業はAIでどう稼ぐか』添付箇所まとめ
――「ビジネスが分かる人」がAIを使い、事業成果に変えるための能力と育成法
1. このパート全体の主張
この箇所の中心メッセージは、かなり明確です。
AI時代に価値を持つのは、AIそのものに詳しい人ではなく、ビジネス課題とAI技術を往復しながら「事業成果が出る解決策」を設計できる人である。
著者はこの役割を「ソリューションデザイナ」と呼んでいます。
重要なのは、AIプロジェクトに必要な人材を「AIエンジニア」や「データサイエンティスト」だけで捉えていないことです。
むしろ企業にとって希少なのは、
ビジネス課題を見つける
→ 技術を理解する
→ 実現可能性を見立てる
→ 解決策を設計する
→ 業務に実装する
→ さらに新しい価値を構想する
という一連のプロセスを横断できる人材です。
したがって、著者のいう「AIを学ぶ」とは、プログラミング言語やモデルの使い方を学ぶことではありません。
「AIを使ってビジネス上の問題を解き、事業成果に変換する能力」を身につけることだと整理できます。
⸻
2. 「思考エンジン」を磨くための事業開発
添付箇所の前半では、新規事業開発そのものが、人材の「思考エンジン」を磨く場になるという話が展開されています。
ここでは経営学者チャールズ・オライリーの「両利きの経営」が登場します。
企業がイノベーションを起こすためには、
既存事業を深掘りする「深化」
と、
新しい領域を開拓する「探索」
の両方をバランスよく行わなければならない、という考え方です。
ただし、本書では「探索」を単なる新規事業創出手段として扱っていません。
むしろ、
新規事業で得た知見が、既存事業を磨くためのヒントになる
という点に注目しています。
つまり、
探索 → 学習 → 既存事業への還流 → 深化
という循環です。
これは、新規事業を「成功するか失敗するか」だけで評価しない考え方でもあります。
新規事業の探索によって、既存事業では得られなかった視点、顧客理解、技術理解、意思決定パターンが蓄積されれば、それ自体が企業能力の向上につながります。
⸻
3. 無印良品に見る「製品ではなく思考エンジンを磨く」
その具体例として、無印良品のアートディレクターである原研哉氏の考え方が紹介されています。
無印良品では、単に「売れる商品群を増やす」というより、
あるプロダクトを生み出すための「思考のエンジン」を磨き、そのエンジンから製品群を生み出す
という思想があるとされています。
つまり、
商品を作ることが目的ではなく、商品を生み出し続けられる思考体系を作る
ということです。
これはAI事業開発にもかなり重要な示唆があります。
個別のAI PoCを成功させるだけではなく、
「どういう問題をAIで解くべきか」
「何をデータとして見るべきか」
「どこに人間判断を残すべきか」
「どう業務に落とすべきか」
という思考様式そのものを組織に蓄積する方が、中長期的な競争力になります。
言い換えると、
AIモデルを資産化するだけでなく、AIを使って事業を設計する「思考OS」を資産化する
という考え方です。
⸻
4. AIを学ぶ＝プログラミングを学ぶ、ではない
ここから「ビジネスが分かる人がAIをどう学ぶか」という本題に入ります。
著者は、ソリューションデザイナに必要な技術理解について、
単にプログラミング言語を習得することではない
と明確にしています。
必要な能力は、大きく
スキル
と
スタンス
に分けられます。
特にスキルについて、著者は6つに整理しています。
#スキル本質
1課題発見スキル本当に解くべきビジネス課題を見極める
2技術解釈スキルAIの仕組みと出力を理解・解釈する
3技術的問題設定・検証スキル技術的な実現可能性を仮説化し検証する
4解決策設計スキルビジネス課題と技術を結びつける
5業務プロセス設計スキル人とAIが協働する業務を設計する
6イノベーション構想スキルAIを使った価値創造を再現可能にする
そして重要なのが、
この6つは独立した能力ではなく、6つを総合的に持つことで初めて機能する
という点です。
⸻
5. ① 課題発見スキル
「AIで何ができるか」より先に「何を解くべきか」を決める
最初に求められるのは課題発見スキルです。
たとえビジネス部門出身で業務知識が豊富でも、
「現場からこういう要望が出ている」
ことと、
「本当に解くべき経営・事業課題」
は同じとは限りません。
したがって必要なのは、
目の前の要望 → 構造的課題 → 真のボトルネック
へと掘り下げる力です。
著者は、
「ビジネス上の本当のボトルネックは何か」
「その問題は実際に解決可能なのか」
という問いを持つことを重視します。
さらに、その問題を技術者や経営者など多様な関係者に対して、
5W1Hなどを使って分かりやすく言語化する
能力も含まれます。
ここでは、コンサルタントや事業企画担当者が持つ課題設定能力が大きな基礎になります。
⸻
6. ② 技術解釈スキル
コードを書くのではなく、「なぜこの結果になったのか」を理解する
2つ目が技術解釈スキルです。
ここでいう技術理解は、
「Pythonを書ける」
「モデルを実装できる」
というレベルではありません。
むしろ、
AIが内部で何をしているのかを概念的に理解する
ことです。
たとえばディープラーニングであれば、
モデルとは何か
損失関数とは何か
重みがどう更新されるのか
データ分布によって結果がどう変化するのか
といった構造を理解します。
なぜなら、この理解がないと、AIの出力結果を正しく解釈できないからです。
AIの精度が悪かったときにも、
アルゴリズムの問題なのか
データの問題なのか
前提条件の問題なのか
を切り分ける必要があります。
この「原因を構造的に分解する能力」が技術解釈スキルです。
⸻
7. ③ 技術的問題設定・検証スキル
「この条件なら、このくらいできる」という実装感覚
3つ目は技術的問題設定・検証スキルです。
著者はこれを「実装感覚」とも表現しています。
たとえば、
「このデータとこのモデルなら、おそらくこの程度の結果になる」
という見立てを仮説として持てることです。
100件しかデータがない場合と1,000件ある場合では、できることは変わります。
また高度なAIプロジェクトになれば、
モデルやアルゴリズムだけでなく、
システム構成
インフラ
データ基盤
データ量・品質
なども考慮する必要があります。
つまりAIは、「モデル単体」の話ではありません。
技術システム全体として実現可能性を見立てる力
が必要になります。
そして著者は、この能力について、
座学では身につきにくく、複数のプロジェクト経験の中で蓄積される
と指摘しています。
⸻
8. ④ 解決策設計スキル
ビジネス課題とAI技術を結びつける「翻訳力」
4つ目が、非常に重要な解決策設計スキルです。
著者によれば、多くのビジネスパーソンがソリューションデザイナになる際、ここが大きな壁になります。
なぜなら、
ビジネス課題を理解すること
と、
AI技術を理解すること
だけでは足りないからです。
両者を、
「このビジネス課題なら、この技術的手段で解く」
と結びつけなければなりません。
つまり、
Business Value ↔ Technology
の対応関係を設計する能力です。
ここには、
論理的思考
批判的思考
構造化能力
などが求められます。
本書の表現を使えば、
ビジネス上の問題を、AIで解ける課題に翻訳する能力
です。
これはAIプロジェクトにおける、非常に重要な「橋渡し機能」と言えます。
⸻
9. ⑤ 業務プロセス設計スキル
AIモデルを作るだけでは価値にならない
5つ目が業務プロセス設計スキルです。
AIモデルを作ったとしても、それだけでは企業価値は生まれません。
最終的には、
AIを既存の業務プロセスに組み込む
必要があります。
ここで重要なのが、AIの限界を理解することです。
AIには、
間違いやすい領域
不得意なケース
精度が安定しない条件
があります。
したがって、
AIが判断する部分
人間が判断する部分
AI結果を人間が確認する部分
を組み合わせなければなりません。
つまり、
Human in the Loop
の設計です。
ソリューションデザイナには、
「AIをどこに入れるか」
ではなく、
人とAIがどう協業すれば業務全体として成果が最大化するか
を設計することが求められます。
⸻
10. ⑥ イノベーション構想スキル
最終的な価値は「AIを使って新しい事業成果を再現可能にする力」
6つ目は、著者が最も重要と位置づける、
イノベーション構想スキル
です。
ここまでの5スキルは、いわば土台です。
ソリューションデザイナの真の価値は、
AIという技術を使いながら、新しい価値や事業成果を構想し、それを再現可能な形で実現すること
にあります。
著者は、ソリューションデザイナの価値を、
「ビジネス理解が深いこと」
でも、
「AIに詳しいこと」
でもないとしています。
両方を使って、
イノベーションを実現できること
が重要なのです。
さらに、ビジネス価値と技術的手段は常に変化します。
その中で、
どこを最終到達点にするのか
何を事業成果と定義するのか
どの条件を組み合わせるのか
を探索し続けなければなりません。
⸻
11. ソリューションデザイナとは何をする人なのか
添付の図と文章を統合すると、ソリューションデザイナは、
ビジネス価値と技術的手段が変動する中で、関係者をマネジメントしながら、その事業にとって成果となる最高到達点を探索・発見し、そこへ至る条件の組み合わせを設計する人
と定義できます。
これは一般的な、
事業企画
PdM
PM
コンサルタント
データサイエンティスト
のどれか一つとは少し違います。
むしろ、
Business × Technology × Implementation × Innovation
を横断する役割です。
⸻
12. スキルだけでなく「スタンス」が重要
著者は、6つのスキルだけでは不十分だとしています。
それを実務で発揮するためには、一定のスタンスが必要です。
大きく整理すると、
スタンス内容
現状把握現在の状態を解像度高く理解する
構造化問題を構造的に整理する
本質追求表面的な事象ではなく課題の本質を見る
最善追求既存案に妥協せず、より良い解決策を探す
技術探索AIや周辺技術で何ができるかを探索し続ける
創造技術とビジネスを組み合わせ、新しい解決策を構想する
特に、
「課題の本質を見極め、最善の解決策を諦めずに追求し続ける姿勢」
が判断力の根幹になります。
⸻
13. ソリューションデザイナは「座学」では育たない
ここから育成論に移ります。
著者の結論は、
OJTが中心になる
というものです。
理由は明確で、6スキルのうち後半にいくほど、
知識ではなく経験知
になるからです。
特に、
③技術的問題設定・検証
④解決策設計
⑤業務プロセス設計
⑥イノベーション構想
は、教科書を読んだだけでは身につきません。
実案件を繰り返し経験し、
仮説 → 実装 → 結果 → 解釈 → 修正
を回すことで身につきます。
⸻
14. 育成の出発点は「ビジネスで優秀な人を技術との境界に置く」
著者が提案する第一歩は、
社内でビジネス的に優秀で期待されている人を、AIプロジェクトに入れる
ことです。
そしてその人を、
技術チーム
と
ビジネス現場
の中間に置きます。
つまり、橋渡しの役割を経験させます。
ここで重要なのは、最初からAI専門家を育成しようとするのではなく、
既にビジネス能力が高い人に技術側の経験を積ませる
という発想です。
これは「AI人材育成＝エンジニア教育」という一般的な発想とは逆です。
⸻
15. 完成したソリューションデザイナが社内にいなくてもよい
著者は現実的な問題も指摘しています。
そもそも、
完成されたソリューションデザイナが既に社内にいる企業は少ない
からです。
したがって、最初は、
外部パートナー
AIベンダー
技術チーム
との共同プロジェクトを通して学ぶ方法が現実的です。
「できる人が社内で教える」という徒弟型育成ができないので、
実案件そのものを教師にする
わけです。
⸻
16. 最も危険なのは「分析結果を受け取るだけ」
新人ソリューションデザイナが陥りやすいのが、
技術チームから分析結果を受け取り、その数字を見るだけで終わる
状態です。
たとえば、
「精度80％でした」
「データの30％が欠損しています」
という報告を受けたとします。
そこで、
「なるほど、80％なのか」
と受け取るだけでは、ソリューションデザイナにはなれません。
重要なのは、
なぜ80％なのか？
どの要因が精度を下げているのか？
業務上80％で十分なのか？
今回のMVP設計にどう影響するのか？
と問いを深めることです。
⸻
17. AIの精度を「モデルの良し悪し」で終わらせない
たとえばAIの精度が十分出なかった場合、考えるべき仮説は複数あります。
データの偏りなのか
対象業務の切り方なのか
モデル選択なのか
入力条件なのか
データ量なのか
と切り分けます。
さらに重要なのが、
AI精度そのものを上げる以外の解決策
を考えることです。
たとえば、
精度が高い条件だけAIに任せる
あるいは、
人間の確認ポイントを変える
ことで、現状の精度でも業務価値が出るかもしれません。
これは非常に重要な論点です。
企業の目的は、
モデル精度100％
ではありません。
目的は、
業務成果・売上・利益・生産性・顧客価値を改善すること
だからです。
⸻
18. 技術結果を「業務設計の論点」に引き上げる
新人段階では、自分だけで答えを出す必要はありません。
むしろ、
「この結果は業務上どう解釈すべきですか？」
「次は何を検証すべきですか？」
と技術チームに問い返すだけでも意味があります。
重要なのは、
技術的な分析結果を、数字の報告で終わらせず、業務設計・事業設計の論点へ持ち上げること
です。
これを繰り返すことで、
「このデータ状態ならこの程度」
「この精度ならこの業務設計」
「ここはモデルを変えるより業務側を変える」
という実践的な見立てが形成されていきます。
⸻
19. 本文から読み取れる「AI人材育成」の本質
添付箇所を一段抽象化すると、著者が提案しているAI人材育成は、
AIの知識を教える育成
ではなく、
AIを材料として「意思決定能力」を鍛える育成
です。
成長プロセスは、
分析結果を受け取る
→ 結果の原因を問う
→ 技術的仮説を持つ
→ 業務への影響を考える
→ 業務設計を変える
→ 事業価値との関係を考える
→ 新しい価値創造を構想する
という流れになります。
ここまで行って初めて、
「AIが使える人」から「AIで事業を作れる人」
になります。
⸻
20. この章の考え方を一枚で整理すると
本書のロジックは、次のようにまとめられます。
事業課題を理解する
↓
① 課題発見
↓
② AI技術を解釈
↓
③ 技術的実現可能性を検証
↓
④ ビジネス課題 × 技術を結合
↓
⑤ 人 × AIの業務を設計
↓
⑥ 新しい事業価値を構想
↓
AIを事業成果へ転換
そして、この一連の能力を育てる方法が、
実案件によるOJT
です。
⸻
21. 特に重要な示唆
この箇所で特に重要なのは、AIプロジェクトの成功条件を「モデル性能」から「事業設計能力」へ移していることです。
AIプロジェクトでは、
Model → Business
ではなく、
Business Problem
→ Technical Problem
→ AI Solution
→ Business Process
→ Business Outcome
までつなげなければならない。
その全体を設計する役割がソリューションデザイナです。
そして、その人材は研修だけでは育たず、
実案件で問い、判断し、失敗し、修正した履歴
によって育つ。
したがって本書の人材育成論は、
AI人材育成とは「AI研修」ではなく、「AIを使った実案件型の事業開発訓練」である
と整理すると理解しやすいです。
⸻
今回の添付範囲の核心
最終的には、次の一文に集約できます。
企業がAIで稼ぐために必要なのは、AIそのものの専門家を増やすことだけではない。ビジネス課題を発見し、AIの可能性と限界を理解し、人とAIの業務を設計し、事業成果まで運べる「ソリューションデザイナ」を実案件の中で育てることである。
特に、「探索案件を人材育成装置にする」「AI出力を判断材料に変える」「実案件の反復によって見立てを蓄積する」という3点が、この箇所を貫く重要な思想です。
※アプリの閲覧環境は最新バージョンのものです。
