RAKSUL TechBlog

RAKSULグループのエンジニアが技術トピックを発信するブログです

広告運用Agentを発想するためのLLM基礎研究への招待

この記事は  ノバセル Advent Calender 11日目です。

ノバセル テクノロジー開発部の吉田と申します。

今回の記事では生成AIの将来を直近発表された論文をとおして論じていきたいと思います。

はじめに

生成AIが普及し、総務省の調べでは日本では個人10%弱, 企業50%弱の人々が日常的に生成AIに触れるようになりました。

生成AIの利用率
生成AIのユースケースが増加している現在、その流れが今後さらに拡大していくことは容易に予想されます。 加えて大規模言語モデル(LLM)がもともと備えている検索から要約といったプロセスの自動化を基盤に、 LLMを活用してタスクを包括的に完結させる「LLMベースのエージェント」の概念が発展しています。 この進化により多種多様な情報を処理し、不確実性の高いタスクを遂行する能力が向上しており、 特定の場面では人間よりも適していると考えられる点からさらなる発展が期待されています。 そこで生成AIの裏側のアルゴリズムを理解することで、AI Agentを深く理解ヒントを得ることができると考えており、 関連基礎研究を次に概観していきたいと思います。

参考論文1: ReAct: Synergizing Reasoning and Acting in Language Models

論文リンク: ReAct: Synergizing Reasoning and Acting in Language Models

ざっくりいうと推論と行動をシームレスに連携することで相乗的に更新できるアルゴリズムを開発できましたというもの。 例えば朝出勤して今日の段取りを考えて行動しながら時間の経過や出来を確認して今後の段取りを変更するなど考えながら行動し、行動しながら行動すると言ったことは日常茶飯事であり、どちらかだけしても結果の総量は上がらないと言った経験は多いのではないか 本論文ではこれまで推論(Reasoning)だけのアルゴリズム、果ては行動(Acting)だけのアルゴリズムといった 誤りも学習してしまう脆いアルゴリズムに対して 頑健に出力できるアルゴリズム(Reasoning and ActingというわけでReActモデル)ができましたというものになります。

例を見るのが早いのでActingのみ, Reasoningのみ(CoT), Reactの順番で見てみます 用いた検証方式はFEVERを例にします。これは質問に対してWikipediaの文章が存在するかどうかに対して「支持する」「支持しない」「情報が無い」の3つに分類するベンチマークテストとなります。

acting
reasoning
react
結果として全て合っているのですが、ReActはThought, Action, Observationがバランスよく人の推論から結論に辿る過程とよく似ていることがわかると思います。バランスよく言語空間に対してActionとThoughtをしているので頑健に結論を出していることが直感的に気づくことができるかと思います。

参考論文2: Reflexion: Language Agents with Verbal Reinforcement Learning

論文リンク: Reflexion: Language Agents with Verbal Reinforcement Learning

次に見ていくのはReActにさらにReflextionという概念を付け加えたものになります。 以下の失敗を反省材料として次に活かしていくものになります

1. 繰り返し行動の検出
同じ行動が何度も繰り返され、同じ結果(無益な観察)が得られる場合、それを「非効率的な行動」としてフラグします。
例:
エージェントが「引き出しを開ける」行動を3回繰り返してもアイテムが見つからない場合、他の探索方法を考えるべきと判断。
2. 行動の無効性
特定のアクションが無効な場合、それを記録し、将来の試行ではその行動を回避します。
3. 探索の不十分性
環境内で特定のオブジェクトや情報が見つからない場合、探索が十分でないと判断し、次回の試行で探索範囲を拡大します。

Algorithmを見ていきましょう。

reflection algorithm
Reflexionとして内部で反省材料に対して負の報酬条件を定義しており、 エージェントが"「引き出しを開ける」行動を3回繰り返してもアイテムが見つからない場合、他の探索方法を考える" のように別の行動を促す仕組みになります。 これによりReActだと失敗結果が次に活かせないことになっていましたが、本提案では次の推論-行動に活かせる仕組みになることがわかります。

AI Agentへ

上のようなアルゴリズムを知ってどんな意味があるの?と思うかもしれませんが Reflectionを使ったAI Agent例はでてきており、 このようにアルゴリズムを知ることでどこまでできることなのか?学習時間(学習の反映)はどの程度かかるものか? などエージェントの特性を理解することに役立ちます。

他にノバセルのように広告代理店業務に役立ちそうなエージェントのアイディアとしては 不確実な情報にならざるを得ない場面での情報量を多くなるような対話シミュレーションモデル の提案がなされています。このようなアイディアはクライアント様の情報が必ずしも完備じゃない場合にどのような対話をすることで 不確実性を下げることができるのかを何かしらのエントロピー計算をすることで下げるための探索シミュレーションが可能だと 想像を掻き立ててくれます。

さいごに

LLMの基礎研究を知ることで、今後必要とされるAI(LLM) Agentへの理解・開発のきっかけを与えてくれることを見てきました。 今回ご紹介した研究はごくごく一部になり、これらの研究は非常に盛り上がっています。 多くの先人の知恵を確認することで有益なAI Agentをクライアント様と創り上げていきたいと考えています。

sklearnとstatsmodelsのデフォルトの回帰モデルで得られる決定係数の違い

この記事は ノバセル Advent Calender 10日目です。

ノバセルでデータサイエンティストをしている宮野です。前回は CausalImpactのアンチパターン について記載しました。今回はライト目に、自身の備忘録として書き残します。

はじめに

ノバセルでは、比較的シンプルな分析ロジックを用いた分析で意思決定の支援をできるものは、streamlitを活用したWebアプリケーションを社内展開しています。その中には、単回帰分析で得られた決定係数を活用する部分が1部含まれています。

この実装を進める中で、Pythonのsklearnstatsmodelsを用いて決定係数を求めた際、デフォルト設定で計算される値に差異があることがわかりました。本記事では、この差異の理由を掘り下げていきます。

決定係数について

決定係数とは、回帰モデルにおいて、モデルのあてはまりの良さの判断基準に使われる指標で、以下のように定義されます。

  •  y_i :実測値
  •  \hat{y_i} :予測値
  •  \bar{y} :実測値の平均値

決定係数は、回帰直線のあてはまりがよければ1に近い値をとり、悪ければ0に近い値になります。

sklearnstatsmodelsで決定係数を求める

実際にサンプルデータを用いて、sklearnstatsmodelsのデフォルトで求められる決定係数が違うことを示します。

サンプルデータを用意します。

import pandas as pd
import numpy as np
import statsmodels.api as sm
from sklearn.linear_model import LinearRegression
import matplotlib.pyplot as plt


# サンプルデータの生成
np.random.seed(123)
x = np.random.rand(50) * 10
y = 3 * x + np.random.randn(50) * 2

# データフレームの作成
df = pd.DataFrame({'x': x, 'y': y})

得られたデータの散布図が図 1です。

# 散布図の描画
plt.scatter(df['x'], df['y'], alpha=0.7)

# x軸とy軸を0開始に設定
plt.xlim(0, df['x'].max() + 1)
plt.ylim(0, df['y'].max() + 1)

# ラベルを設定
plt.xlabel('x')
plt.ylabel('y')

# グラフを表示
plt.show()

図 1:サンプルデータの散布図

次に、このサンプルデータを用いてsklearnstatsmodelsで決定係数を求めます。

sklearn

model_lr = LinearRegression()
model_lr.fit(df[['x']], df['y'])
round(model_lr.score(df[['x']], df['y']), 4)
0.9044

statsmodels

model = sm.OLS(df['y'], df[['x']])
res = model.fit()
round(res.rsquared, 4)
0.9825

どちらも求められた決定係数が1に近い値になっていますが、statsmodels で求めたほうがより1に近い値になっています。

極端な例

続いて、極端な例として、回帰モデルのあてはまりが悪くなるようにサンプルデータを作成し、決定係数の違いを確認します。

# サンプルデータの生成
np.random.seed(123)
x_extreme = np.random.rand(50) * 10  # 0から10までのランダムな値
y_extreme = np.random.rand(50) * 10  # 0から10までのランダムな値(x_extremeとは独立)

# データフレームの作成
df_extreme = pd.DataFrame({'x_extreme': x_extreme, 'y_extreme': y_extreme})

# 散布図の描画
plt.scatter(df_extreme['x_extreme'], df_extreme['y_extreme'], alpha=0.7)

# x軸とy軸を0開始に設定
plt.xlim(0, df_extreme['x_extreme'].max() + 1)
plt.ylim(0, df_extreme['y_extreme'].max() + 1)

# ラベルを設定
plt.xlabel('x_extreme')
plt.ylabel('y_extreme')

# グラフを表示
plt.show()

図 2:回帰モデルのあてはまりが悪くなるようなサンプルデータの散布図

sklearn

model_lr.fit(df_extreme[['x_extreme']], df_extreme['y_extreme'])
round(model_lr.score(df_extreme[['x_extreme']], df_extreme['y_extreme']), 4)
0.0679

statsmodels

model_extreme = sm.OLS(df_extreme['y_extreme'], df_extreme[['x_extreme']])
res_extreme = model_extreme.fit()
round(res_extreme.rsquared, 4)
0.5728

散布図からもわかるように、今回作成したサンプルデータでは回帰直線の当てはまりは悪くなる ≒ 決定係数は0に近くなるはずです。

ですが、sklearnで求めた決定係数は0にかなり近いのに対し、statsmodelsで求めた決定係数は0に近いとは言えず、大きく異なる結果になりました。

差分が起こる理由

ここが本題ですが、差分の理由は「切片を含むモデルか、含まないモデルか」です。切片を含まないとは、回帰直線が原点(0, 0)を通ることを意味します。

sklearnLinearRegression()では、デフォルトでは切片を含むようになっているのに対し、statsmodels のデフォルトでは切片を含まないようになっています。この違いが決定係数の差分を引き起こしています。

極端な例で用意したサンプルデータの散布図(図 2)に、切片を含む回帰直線と、切片を含まない回帰直線を引いた図が以下の通りです。

図 3:切片を含む回帰直線
図 4:切片を含まない(原点を通る)回帰直線

切片を含まないモデルで得られる決定係数は、回帰モデルのあてはまりを表す指標ではなくなるため注意が必要です。

切片を含まない場合の決定係数は以下のように定義されます。

statsmodelsで切片を含むモデルの決定係数を得るには、以下のように定数項を追加すると、sklearnで得られる決定係数と一致します。

# 定数項を追加
x_extreme_with_const = sm.add_constant(df_extreme[['x_extreme']])

model_intercept_extreme = sm.OLS(df_extreme['y_extreme'], x_extreme_with_const)
res_intercept_extreme = model_intercept_extreme.fit()
round(res_intercept_extreme.rsquared, 4)
0.0679

おわりに

生成AIの普及により、データサイエンティストなどの専門家に聞かなくとも、コードや数式をすぐに生成し結果が得られる時代です。しかし、本記事で示したように、sklearnstatsmodelsでは、デフォルト設定のわずかな違いが、分析結果に基づく意思決定や施策の方向性に影響を及ぼす可能性があります。

ツールやライブラリを用いる際には、それらのデフォルト設定や実装の違いを正確に理解することが求められます。

参考資料

回帰直線が原点(0, 0)を通る場合の決定係数については「Rで学ぶ確率統計学 多変量統計編」の第3章にまとめられています。

新卒1年目がノバセルで学んだ「仕事を進めるコツ」

この記事は ノバセル Advent Calender 9 日目です。

こんにちは、ノバセル 24 年新卒の秦です。 テクノロジー開発部にて、データエンジニアをしています。

入社をしてから8ヶ月ほどが経ちました。

最初は仕事がなかなか上手く進められず、一つの仕事に必要以上に時間がかかっていました。 しかし、「あること」を意識するようになってから、少しずつ仕事が上手く進められるようになってきました。 今回は私が実践して効果を感じた「仕事を進めるコツ」を共有したいと思います。

コツは「分解」すること

そのコツとは「分解すること」です。

仕事は以下の二種類に大別できます。

  1. 具体的でわかりやすい仕事
    • 例: 「このデータベースから特定のデータを取得する」
  2. 抽象的で漠然とした仕事
    • 例: 「このページをお客さんが使いやすくする」

前者のような具体的な仕事は取り掛かりやすいですが、後者は何から始めればいいか分からず、進めるのが難しいです。 この「抽象的な仕事」の抽象度を下げ「取り掛かりやすい仕事」にするために必要なのが「分解」という技術です。

分解の実例: 「オムライスを作る」

例えば「オムライスを作る」という仕事を例に考えてみます。 この状態だと抽象度が高く取り掛かりにくいです。 そこで、以下のように分解していきます。

料理は「食材の準備」と「調理」に分けられます。

  • オムライスを作る
    • 食材の準備
    • 調理

まだ実行可能な抽象度ではないので、さらに分解していきます。

  • オムライスを作る
    • 食材の準備
      • 冷蔵庫にある食材を確認する
        • (必要な食材は何?)
      • 足りない食材を買い出しに行く
    • 調理
      • (そもそも作り方知らないぞ?)

分解をしてみると食材の準備として何を準備する必要があるのか、そもそもどういう調理をすればオムライスを作れるのかわからないということに気づきました。 つまり、見落としている仕事があったという事です。 見落としている仕事を追加してさらに分解します。

  • オムライスを作る
    • オムライスの作り方を調べる
      • レシピサイトで検索する
      • どのレシピを使うか決める
    • 食材の準備
      • レシピにある食材を確認する
      • 冷蔵庫にある食材を確認する
      • 足りない食材を買い出しに行く
    • 調理
      • レシピを参考にする

このように分解することで

  • 抽象的な仕事を実行可能な具体的な仕事にできる。
  • 分解前は見落としていた仕事を発見できる。

というメリットが得られました。

分解をしていなければ

  • とりあえず買い出しに行って、結局何を買えば良いかわからない。
  • 作り方を調べる時間を考慮しておらず、完成を約束した時間に間に合わない。

ということが起こり得ます。

分解を身につけるには

分解をすれば良いとわかっても、いざ分解してみようとすると思いのほか難しいです。 自分なりにどうしたら分解しやすくなるかを書きます。

まず分解の出発点は「仕事の目的を明確にすること」です。 目的があいまいなまま分解に取り掛かると必要な要素を見落としたり、無駄な作業が増えたりすることになります。

再度「オムライスを作る」を例にします。 「お客様に振る舞う」のが目的なら見た目や盛り付けが重要ですが、「自分で食べる」なら味に集中すれば十分です。 目的を明確にすることで、何を分解すべきかも明確になります。

あとは、分解のためのフレームワークを活用する事です。 調べたら色々出てくると思いますが、例えば前中後というフレームワークがあります。 このフレームワークでは、仕事を三つに分けて考えます。

  • 前: 取り掛かる前に行う準備
  • 中: 実際に行う作業
  • 後: 終了後に必要な確認や後始末

オムライスの例で言うと以下のようになります。

  • 前:オムライスの作り方を調べる、食材の準備をする
  • 中:調理をする
  • 後:盛り付けをする、食卓に出す、洗い物をする

このようにフレームワークを活用することで分解がしやすくなり、さらに見落としていた仕事を見つけることができます。 今回でいえば、後の仕事が漏れていたことに気づくことができました。 他にも色々フレームワークがあるので調べて活用してみてください。

あとは分解する時間を意識的に取ることが大事です。 仕事が忙しかったりすると、分解を省略してしまいがちですが、分解をしないと結局仕事を上手く進められず必要以上に時間がかかることにつながります。 仕事に取り掛かる前に仕事の目的を確認し、分解をする癖づけをしましょう。

分解は難しいものですが、経験を積めばどんどん上達していくはずです。 日々分解を意識し、分解する経験を積むことで今までより仕事が上手くできるようになるはずです。

まとめ

抽象的な仕事は進めにくいですが、「分解」を意識することで具体的な仕事に分解できます。 具体的な仕事になれば仕事に取り掛かりやすくなり、今自分が何をしてるかを人に共有しやすくもなります。 そして、具体と抽象という本にもあるように、具体と抽象の両方をセットで扱える力が必要です。 今回は分解をすることで抽象から具体化することができ、仕事がしやすくなるという話をしました。 逆に具体から抽象化する力も身につけることで、より仕事がしやすくなると考えています。 具体化力と抽象化力を鍛えてもっと仕事ができるようになりましょう!

最後まで読んでいただきありがとうございました!

おそらくあなたがまだ知らない AI 情報系 YouTube チャンネル 5 選

序文

この記事は ノバセル Advent Calender 8 日目です。 ノバセルで CTO をしている戸辺です。

ノバセルはいま AI を "使う" ということに力を入れており、AI を使って徹底的に社内外の生産性を改善したいと考えています。もともと私たちの親会社であるラクスルの Vision は "仕組みを変えれば、世界はもっとよくなる" ということで、レガシーな産業に IT 等の仕組みを取り入れることで、世界を良くするということにアプローチしてきました。ノバセルもそこは同じで、特にそれをマーケティング領域で実現していこうという事業体なだけです。

この観点にたつと、before AI の世界における IT は after AI の世界からみるとレガシーであり、AI を取り入れて仕組みを変えて、世界をもっとよくするということは、私たちの Vision そのものに通ずることであり、かついまやるべきことなのです。

単に、私がこの手の領域がとても好きというのがありますが。

自身でも囲碁を、だいたいアマ 2 段くらいの腕でやり、ゲーム AI 開発を嗜んでいた身からすると、AlphaGo の登場は衝撃でした。当時世界で一番強かった人類最強の棋士を相手に、3 戦全勝。このときに、AI は人間の代替や、部分的な生産性改善ではなく、いわゆる "超知性" 足りうることを証明したと感じました。AlphaGo はあくまでも囲碁という閉じた領域ではありましたが、これをアナロジーとし、あらゆる人間の知識労働は、"超知性" として置き換えられるだろうと確信しています。

どちらかというと興味の領域は、それがなるかどうかではなく、いつなるか、です。

そのために欠かさず情報キャッチアップをしている次第です。単に好きなだけですが。大事なことなので 2 回いいました。

※ わかりやすさのために、 before AI とか after AI という言葉を使いましたが、これは ChatGPT がリリースされた 2022 年 11 月 30 日 以前以後のことです。AI とは受け手にとって曖昧な用語だと思いますが文脈からご判断いただけますと幸いです。ちなみに、AlphaGo の文脈で述べた AI は LLM でもないので、技術的には全く別のものということは理解したうえでなお、そのアナロジーは通じると考え、例示してあります。

選考基準

せっかくこの記事を読んでくださった方に新規の情報を届けたいと思いまして、思い切って "あなたがまだ知らない" と題してしまいましたので、まず、チャンネル登録者数を 20 万人未満のものに厳選しました。ちなみに、OpenAI は執筆時点で 132 万人の登録者がいました。とはいえ、見る価値があるクオリティも必要だと思いますので、その観点で登録者数は 1 万人以上という条件もつけました。登録者数が多ければ質が担保されるというわけではないかもしれませんが、一定の相関はあると思いますし、質については一応私が見ての判断も加味されていますので。

続いて、次の基準として、これ自体が Tech Blog ということ、つまり読者はおそらくエンジニアであろうということから、エンジニアに向けて特に有用なものを選びました。

最後に、これは少し特殊かもしれませんが、英語に限定しています。これは私自身が英語学習を兼ねながら見ているということもあるのと、日本語の情報は割と受動的にも入ってきやすいのに対して、英語での情報は能動的に取りに行くほうが早く情報が得られるという側面もあり、英語でピックアップしています。

選考基準まとめ

  • チャンネル登録者数 1 ~ 20 万人
  • エンジニアにとって有用
  • 英語

最後に英語で YouTube を見るときに有用なブラウザ拡張も紹介しておこうと思います。

おそらくあなたがまだ知らない AI 情報系 YouTube チャンネル 5 選

(特におすすめ順というわけではありません)

1. AICodeKing

@AICodeKing: 4.75 万人

概要

まずは AICodeKing から。このチャンネルは主に IDE や Editor などの開発環境に関する話題が多めです。特に人気なのは "Stop Using xxx" シリーズ。みんな "Cursor" 使ってるけど、"VSCode + AIder + Supermaven" 使うほうがいいよーとか、そういうやつ。また、最新の IDE などにもよく触れてくれており、最近だと Google の IDX の紹介もしてくれていました。なんだか眠くなるトーンの声の方なのですが、IDX の紹介の時は結構テンションが高かったように思います。他には、Aider については本人も好きなのか、何回かに分けて説明してくれており、ユースケースの理解に役立つと思われます。WindSurf とか、日本では紹介記事が少なめの Editor もよく取り上げてくれています。

おすすめの一本

www.youtube.com 基本的にチュートリアルが多めなので、気になる Editor や IDE がありましたら、このチャンネルの中で検索してみるというのがよい使い方だと思います。そのためおすすめの一本にはみんなが好きそうな Zed + Aider を使ったものを選びました。こういう自動生成のコードは質が悪いという方もいると思いますし、現時点では私もそう思うことがありますが、基本的にそれはモデルの進化と同時に改善されていくので、開発スタイルとしては AI がサポートする形、もしくは AI がベースを書いて人間がサポートをするという形に近づくはずです。そのため、開発プロセスとしては、AI を利用したプロセスに切り替えていく必要はあると思っており、こういうところでの情報収集は重要だと考えています。

2. IndyDevDan

@indydevdan: 2.96 万人

概要

エンジニア向けだとどうしてもコードアシスタントが多くなってしまいます。この方も AIDER を使ったコードアシスタントの動画をたくさんあげてくださっているので、AIDER 解像度を上げてコードアシストしてもらおうという方には便利です。加えて、このチャンネルではプロンプトエンジニアリングの解像度をあげてくれるコンテンツもあり、プロンプトエンジニアリングの考え方のフレームワークを提示してくれたり、今後それがどれだけ大事になるかなどを具体例を示しながら教えてくれたりします。

おすすめの一本

www.youtube.com おすすめの一本にはそのプロンプトエンジニアリングについての解説動画をあげました。全体的に長めの動画なので時間のある時にご覧ください。エンジニア向けにプロンプトエンジニアリングを解説してくれています。マルチエージェントで単一プロンプトに依存せずに精度を上げる方法などは参考になることと思います。

3. WorldofAI

@intheworldofai: 8.18 万人

概要

最初に紹介した AICodeKing と少しテイストが似ているところはあるのですが、それよりはコードを書くことだけに限定されず、もう少し広く日常の仕事を便利にするための AI 利用について紹介してくれています。

おすすめの一本

www.youtube.com これは最近の動画なのですが、AI をいろいろ試すための環境構築についてまとまっていて非常に良かったです。AI についての調査研究、それから実際に役立つツールなどを開発するとき、いずれにせよ開発環境の構築は必要です。基本的には Docker が用意されているものはそれを使えという話なのですが、具体的に見ながら真似して用意できるという作りになっているのは便利なのではないでしょうか。

4. techfren

@techfren: 0.9 万人

概要

(少し基準に届いてないけど許してください) この方はライブが多めで、ライブ動画を編集してあげてくれています。そのため、実用的なものが多くまた、躓きながら乗り越えていくという生の部分が見られるのがとても有用です。

おすすめの一本

www.youtube.com これは n8n をローカルにセルフセットアップする例です。ひとつうえのおすすめの一本でも n8n をローカルホストする例は見られるのですが、こちらの動画では実際にそれを使った事例までやってくれます。Gmail を受信すると、それをトリガーとして ChatGPT が返信の文面を自動生成して、それを下書きに保存しておいてくれるというものです。n8n はローカルにホストすればタダで使える Zapier という印象が強かったのですが、いまは AI も強力に協調動作します。(ちなみに Zapier もワークフローの途中に AI を入れられるそうです、いまは。ラズパイに常駐させて、いろんなことを AI にやってもらいたくなりますね。

5. Anthropic 公式

Anthropic の公式: 5.72 万人

概要

"あなたがまだ知らない" ってことはさすがにないとは思いますが、選考基準にギリギリ入っているので(ギリギリというのはエンジニア向けという意味で)最後に紹介させていただきます。OpenAI のチャンネル登録者数が 132 万人であることを考えるとずいぶん少ないと思います。出しているモデル、機能は素晴らしいのですが。Computer useMCP などここ数ヶ月は話題に事欠かない Anthropic でしたが、それらをもう少し理解しやすい具体的なユースケースを結構紹介してくれているのがこちらです。

おすすめの一本

www.youtube.com Computer use を使って VSCode を操作してコーディングする動画です。これを見た時に、思ったより近い将来にコードを書く仕事は相当量減るんだろうなと思いました。まだご覧いただいていない方は、どうやってコードを書く量が減っていくのかを、この動画を見て、想像してみてください。

(おまけ) 英語で YouTube を見やすくするブラウザ拡張

NoteGPT これの Chrome 拡張が無料で使えます。これをいれると、YouTube の画面の右側に動画の Transcript が出せます。Summary などを見る場合はログインが必要になりまが、Transcript だけであればログインもアカウントも不要です。また、Transcript さえあれば、コピペで Claude なり ChatGPT なりに渡して、サマリーを得たり、考察の壁打ちなどをするのも自由にできるかと思います。ぜひお試しください。

※ 社内の英語レッスンで先生に教えていただきました

ノバセルPdMが「プロダクトマネジメントのおすすめ本」を語る

この記事は ノバセル Advent Calender 7日目です。

こんにちは。ノバセルにてプロダクトマネージャーをやっている林です。 本記事では、私が今年読んだ本の中からプロダクトマネジメント関連のおすすめ本を2冊ご紹介したいと思います。

おすすめ本①:プロダクトマネージャーのしごと 第2版

1冊目は『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』です。

この本を一言で言うと「PdMが実際の仕事で成果を出すための心構え/TIPSが学べる本」です。 プロダクトマネジメントの単なるベストプラクティス解説ではなく(むしろべスプラを盲信する危険性が語られる)、様々に変化する組織/事業状況に上手く対応するための方法が書かれています。 かといって、「特定の場面にしか使えないTIPSの羅列」という訳でもなく、PdMとして仕事を進める上での指針となる思考法が豊富な具体例と共に載っています。

おすすめポイント

ポイント①:きれいごとだけではない「PdMとして上手くやるためのノウハウ」が詰まっている

これが本書最大の魅力だと思います。 本書の中では

  • プロダクトの方向性について、ステークホルダーからの「表向きの承認(積極的な承認ではない「よさそう」/沈黙等の曖昧な回答)」を信じてプロダクト開発を進めたら、リリース直前で「これは何だ?聞いてないぞ」とちゃぶ台を返される

  • プロダクトバックログの優先順位付けをするため、優先順位付けが「正しく」行われることを保証してくれるフレームワーク探しに固執する

など、PdMとして働く中で「その問題にぶつかるよね!わかる!」という事例が沢山出てきます。 「リアルなプロダクトマネジメントの現場で成果を出すための秘訣」が包み隠さず書かれており、非常に参考になります。 と同時に、「世界中どこのPdMも似たような問題に悪戦苦闘しているのだな。自分だけではない。」と背中を押してくれます。

ポイント②:気を付けるべき観点/アクションが端的にまとめられている

「取るべきアクションが明確」というのも、本書のもう1つの魅力です。 全部で16章あるのですが、各章の最後に「チェックリスト」が設けられており、その章で語られたことを実行に落とす際の強い味方になってくれます。

例えば、「2章:プロダクトマネジメントの CORE スキル」の末尾には

  • コミュニケーション上手とは「イケてる言葉で人の印象に残る話し方をする」ことではないことを忘れないでください
  • 自分自身とチームの透明性を高めるためには、たくさんの心地悪い会話をこなさなければいけないことを認識しておいてください

など、取るべきアクションが覚えやすくキャッチーな言葉で書かれています。

どんな人におすすめ?

個人的には「PdMを数年やっているが、一皮むけて成長したい!」という人におすすめです(まさに私です笑)。 これからPdMを始める方にも参考になるとは思うのですが、本の中に出てくる事例がリアリティを持って迫ってくる(そして、思い出したくない過去の失敗が走馬灯のように...)のはミドル~シニアを目指す方かなと思います。

おすすめ本②:Continuous Discovery Habits

2冊目は『Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value』です。

この本を一言で言うと「顧客価値とビジネス価値を両立させるプロダクトを発見するための体系的な方法を学べる本」です。 残念ながら日本語訳が出ていないのですが、海外の方が書いたPdM向け読書リストには必ずと言っていいほど入っている一冊です。

おすすめポイント

ポイント①:「継続的ディスカバリー」の明確な定義が分かる

PdMであれば「定期的に顧客と話しましょう」「ユーザーインタビューをしましょう」というのは嫌ほど聞いていると思います。 ただし「定期的ってどれくらい?」「どんなメンバー/目的でするべき?」等がふわっとしていることも多いのではないでしょうか? 本書では「継続的ディスカバリー」の明確な定義が書かれています。

  • 少なくとも週1回以上顧客と接点を持つこと
  • プロダクトを作るチーム自身によって行われること
  • 小さなリサーチ活動の形式で行われること
  • (顧客/自社にとって)望ましいアウトカムは何か?を追求していること

特に「少なくとも週1回以上顧客と接点を持つ」はPdMにとって明確な指針になると思います。 私も本書を読んで以降、週1回以上は顧客と接点を持つように心がけています。

ポイント②:「継続的ディスカバリー」の一連の流れを理解できる

他のユーザーインタビュー系の本同様、本書でも

  • 顧客理解の最初の一歩はどう始めればよいのか?
  • ユーザーインタビューでする質問のアンチパターン
  • インタビュー結果をどう構造化するか?

等が記載されています。

一般的な本との違いとしては「顧客課題の発見/検証を一連のフレームワークで理解できる」点です。

本書では、大まかな流れとして

  • 目指すアウトカムの設定
  • アウトカムに紐づく「機会(Opportunity)」の構造化と検証
  • 機会に基づく「解決策(Solution)」の構造化と検証
  • 上記を継続的に回す習慣作り

という4つのステップで継続的ディスカバリーを体系しています。

また、体系を支えるフレームワークとしてOpportunity Solution Tree(通称「OST」)が提示され、本書で何度も言及されます。

※OSTの参考記事 www.productplan.com

詳細については本書を読んで欲しいのですが、使い方としては

  • この本で顧客課題発見の全体像を理解する
  • 個々のステップにおける詳細は専門の本を当たる

がよいと思います。

どんな人におすすめ?

「顧客課題発見系の本を色々読んで来たが、1本筋を通す体系を学びたい」という方におすすめです。 あと、「PdMが普段する会話を英語で書くとどうなるか?」も学べるので、ビジネス英語を勉強したい方にもおすすめ!

ノバセルの実務で活かしてみて

最後に、私のノバセルでのPdMの実務において、2冊の本で学んだことを活かしたケースについて話そうと思います。

活かした内容

  • 1冊目:過剰コミュニケーション(第4章:過剰コミュニケーションの技術)
  • 2冊目:真の課題に辿り着くには「一般的な状況でどうすると思うか?」ではなく「具体的な状況でどうしたか?」を聞く(Chapter Five: Continuous Interviewing)

※「過剰コミュニケーション」とは?:「最適なコミュニケーション量が分からず失敗するくらいなら、コミュニケーション過剰に倒した方がよい」という原則のこと

具体的なケース

あるクライアントの商談に同席していた時、「Aという作業が直近大変なんだよね」という話がポロっと出ました。 ただ、クライアントの社内用語を使って説明されたので、私としては「なんか大変そうだけど、具体的に何が大変か分からないなあ」という状態でした。 そのような状況で、今までの私の場合「頓珍漢な質問をしたら『なんかよく分からないことを聞かれた』と思わるんじゃないか?」「MTG後に同席メンバーと『あれってどういう意味だった?』を確認しよう」と質問を躊躇することが多かったです。

でも、ここは「過剰コミュニケーション」の原則に則って「馬鹿だと思われてもいいから徹底的に顧客に聞こう」と意思を固めました。 かつ、顧客への質問の仕方として「なんでAという作業が大変なんですか?」という一般的な状況ではなく、「Aという作業を実際に見せてください」という具体的な状況を聞くことにしました。 すると、よくよく顧客の話を聞くと「大変な作業Aが発生しているのは、定常的にやるべき作業Bが出来ていないから」「本当は作業Bを定常的に実施できるようにしたい」という話が出てきました。 「臆せず顧客に質問した結果、真のニーズに辿り着けた」瞬間でした。

これはほんの一例ですが、今後も学んだことを実務に活かしてPdMとして一歩も二歩も成長していきたいです。

まとめ

今回はプロダクトマネジメント関連のおすすめ本を2冊紹介しました。 気になった方は是非読んでみてください。

明日は弊社CTOが登場! 「今年購読を開始した AI 情報系 YouTube チャンネル」について書くということで、乞うご期待!