Measure What Matters ― OKRの本質をYouTubeソースで読み解く

OKRが徐々に浸透していますが、その本質は従来型の目標設定と大きく違うため、なかなか理解や着実な実行が難しいのかなと想像しています。トップダウンの組織目標と、実際に作業を進めるチームの目標をどのようにすり合わせるか(アラインメント)や、透明性を用いて協力を生み出す、給与評価と切り離す、といった重要な側面は、従来の目標管理システムの運用とは真逆になるため、十分に検討しないと混乱を呼ぶのかもしれません。OKRの形式(目標と結果指標)はシンプルなのですが、ではいくつくらいの目標をどれくらいの期間で、チーム目標なのか個人目標なのか、などを十分に説明した資料が広く読まれていない可能性も感じます。

そこで今回は、OKRの原典ともいえるドーア著『Measure What Matters』と、YouTubeで無料視聴できる2つの一次ソースを手がかりに、OKRの本質を掘り下げてみたいと思います。


「実行こそが最も重要だ」― OKRの誕生

1975年、若きエンジニアのドーアはIntelでグローブにこう言われました。「何を知っているかはほとんど問題ではない。最も重要なのは実行だ」。グローブが編み出したOKR(Objectives and Key Results)は、目標(Objective)と主要な結果(Key Result)を対にしたシンプルな目標設定システムです。目標は方向性を示し、KRは測定可能でなければなりません。やったのか、やらなかったのか。イエスかノーか。シンプルです。

アンドルー・グローヴ - Wikipedia

1999年、ドーアはこのシステムをGoogleに持ち込みました。当時のGoogleは社員40人のスタートアップです。それ以来、四半期ごとに全社員がOKRを書き出し、評価し、公開しています。Google社内ディレクトリ「MoMA」では、各社員の電話番号やメールアドレスの横にOKRへのリンクが表示され、今四半期だけでなく過去の四半期のOKRと評点も誰でも閲覧できるそうです。

OKRの三層構造:Why → What → How

ドーアはOKRを「透明な器(transparent vessels)」に例えています。WhatとHowで器の形を作り、そこにWhyを注ぐ。「本当に大切なのは、その器に注ぐ'なぜ'だ」と。

TED TalkではNunaのCEOジニ・キム(Jini Kim)の物語が紹介されています。9歳で弟をメディケイドに登録した原体験がミッションとなり、それが会社となり、連邦政府のメディケイドDBプロジェクトを勝ち取る原動力となりました。個人的なWhyが組織の目標の発射台になるのです。リーダーは「何を」だけでなく「なぜ」も伝えなければなりません。社員はやりがいを求め、自分の目標が会社のミッションとどう結びつくのかを理解したいと思っています。

▶ Objectiveは「曖昧な思考に対するワクチン」

良いObjectiveの条件は「重要・具体的・行動志向・鼓舞する」の4つです。ボノのONE組織は「世界最貧国の債務免除」「HIV治療薬への普遍的アクセス」を掲げました。ボノは「OKRは狂気を育て、リスクと信頼の環境を与えてくれる。そういう構造があれば、魔法はすぐそこにある」と語っています。書籍ではスティーブ・ジョブズ(Steve Jobs)の言葉が引用されています。

スティーブ・ジョブズは「イノベーションとは1000個の提案に対してノーと言いつづけることだ」と語っていた。通常、四半期OKRは3~5項目であるのが理想的だ。もっと多くの目標を盛り込みたくなるかもしれないが、それはたいていうまくいかない。目標が多すぎると、本当に重要な項目へのフォーカスが弱まったり、他のおもしろそうな課題に注意が向いてしまうリスクがある。 (『Measure What Matters』 第4章 )

▶ Key Result ― 数値目標と品質目標を「対」にする

KRは「具体的・期限付き・測定可能・検証可能」であるべきです。メリッサ・マイヤー(Marissa Mayer)の言葉を借りれば「数字がなければKRではない」。Chromeを率いたサンダー・ピチャイ(Sundar Pichai)は「ユーザー数」という1つのKRに3年間こだわり、2000万→5000万→1億と引き上げ続けて1.11億を達成しました。

しかし書籍は「フォード・ピント」の悲劇も警告しています。一面的な数値目標(重量2000ポンド以下・価格2000ドル以下)を追求した結果、安全性が犠牲となり大規模リコールに至りました。ウェルズ・ファーゴの不正口座スキャンダルも同様です。グローブは「数値目標と対になるKRは、仕事の品質を示すものでなければならない」と説いています。例えば「新機能3つ」には「各機能あたりバグ5件以下」を対にする、といった形です。


OKR実例① Intel「クラッシュ作戦」(1980年Q2)

ドーアがIntelで経験した全社OKRの実例です。モトローラとのマイクロプロセッサ競争において、8086の性能優位を証明するためのOKRでした。採点結果は平均0.625――まずまずの評価です。Intelでは100%達成がありえない水準で目標設定するのがルールでした。

OBJECTIVE|全社目標 「8086」を業界最高性能の16ビット・マイクロプロセッサ・ファミリーにする

KEY RESULTS

  1. 「8086」の性能優位性を示すベンチマークを5つ開発し、公表する(0.6)

  2. 「8086」ファミリーの全製品をリリースし直す(1.0)

  3. 8MHz版の製造を開始する(0)

  4. 演算コプロセッサのサンプルを6月15日までに製作(0.9)

平均スコア: 0.625(まずまずの評価)― 書籍『Measure What Matters』第4章より

OKR実例② クラウ / Blogger PM(Google)

クラウはGoogle Venturesのワークショップで、自身のBlogger PM時代のOKRを公開しています。Bloggerは世界第8位のWebプロパティでありながら、社内では忘れられた存在でした。クラウは「収益成長を加速させる」を毎四半期の第一目標に置いていました。

OBJECTIVE 1 Bloggerの収益成長を加速させる

KEY RESULTS

  1. 収益化タブをローンチし、AdSense導入をワンクリックにする(1.0)

  2. AdSenseホストチャネルターゲティングを実装し、RPMをX%向上(0.3)

  3. 収益に関する実験を3つ実施し、成長ドライバーを特定(0.7)

クラウのコメント: KR2は実装したがRPMへの影響が小さく失敗。KR3は3実験中2つしか有用な学びを得られなかったとのことです。

OBJECTIVE 2 Bloggerのレピュテーションを改善する

KEY RESULTS 1. 業界イベントで3回講演する 2. Blogger初期からのトップユーザーに個人的に連絡し、関係を構築 3. Blogger 10周年記念のPR施策を統括・実行する 4. DMCA対応プロセスを改善し、誤ったブログ全体削除を解消

YouTube動画 [2] (47:32付近) で詳細と採点が解説されています

OKR実例③ ドーアの会議OKR(1999年)

ドーアがGoogle初のプレゼンを行ったとき、彼自身がその会議に対してOKRを設定して臨みました。これ自体がOKRの好例です。

OBJECTIVE|ドーアの Google 初プレゼン(1999年) 計画のための実用的なモデルを構築する

KEY RESULTS

  1. プレゼンテーションを時間通りに完了する

  2. 3カ月分のサンプルOKRセットを完成させる

  3. 経営陣に3カ月の試験運用への同意を得る

クラウの講演でドーアのオリジナルスライドとして紹介されています。YouTube動画 [2] (7:43付近)


グローブが示したOKRの要諦 ― 7つの原則

書籍の中でドーアは、Intel時代にグローブから学んだOKRの要諦を7つにまとめています。健全なOKR文化の本質――徹底的な知的誠実さ、利己心の排除、チームへの完全な忠誠――はグローブの人格そのものだとドーアは書いています。以下、その7つの原則をご紹介します。

▶ ① 絞り込む(Focus)

「ひとにぎりの目標を厳選することで、何にイエスと言うべきか、何にノーと言うべきかが明確に伝わる」とグローブは書いています。1サイクルあたりの目標は3〜5個、各目標のKRは5個以下です。クラウは「ある四半期に7つの目標を持ったことがあるが、あれほど消耗したことはない。明らかに広げすぎだった」と振り返っています。OKRがしっかり機能している組織では、上司は指示の代わりに問いかけます。「一番重要なことはなんだ?」と。

▶ ② 目標はボトムアップで

組織と個人の意欲を引き出すには、上司と相談しながらOKRのほぼ半分を自分で決めさせるとよいとされています。すべての目標をトップダウンで設定すると、意欲は削がれてしまいます。ドーアのオリジナルデッキでは60%がボトムアップとされ、クラウも「半分以上が個人から上がってくる必要がある」と強調しています。グローブは「最前線の人々は最も価値のあるイノベーションにいち早く接する」と語りました。

▶ ③ 押しつけない(No dictating)

OKRは優先事項を設定し、その進捗をどのように測るかを決めるための協力的な社会契約です。会社全体の目標についての議論がまとまっても、それに付随するKRについてはまだ議論する必要があります。ドーアのデッキでも「全員が合意しなければならない。命令ではない」と明記されています。目標達成を最大限促進するには、協力的な合意形成が不可欠です。

▶ ④ 常に柔軟な姿勢で

事業環境が変化し、現在の目標が現実的ではない、あるいは妥当性を失ったと思われるときには、サイクルの途中でもKRを修正したり、場合によっては捨てたりしてもよいとされています。クラウも「年間OKRは石に刻まれたものではない。方向を示す援助であり、目隠しではない」と述べています。ただし、性急に放棄したOKRからは何も学べません。打ち切る場合は必ず振り返りを行うことが大切です。

▶ ⑤ 失敗を恐れない(Dare to fail)

「全員がすべては手の届かないような目標に向かって努力するとき、アウトプットは伸びる傾向がある」とグローブは書いています。野心的なストレッチ目標は、困難ではあるが達成可能なものにすべきです。Googleでの採点のスイートスポットは0.6〜0.7。クラウは「常に1.0を取っているなら、それは破壊的にやっているのではなくサンドバッギングしているのだ」と明確に述べています。ボノの言葉を借りれば「OKRは狂気を育て、リスクと信頼の環境を与えてくれる」のです。

▶ ⑥ 手段であって、武器ではない

OKRは個人の仕事のペースを管理するためのものであり、勤務評定の根拠となる正式文書ではないとグローブは書いています。GoogleでもOKRはボーナスや昇進の評価基準ではありません。クラウは「Googleでの5年間の年次評価で、OKRが評価の標準要素になったことは一度もない」と証言しています。報酬と結びつけるとサンドバッギングが起き、ストレッチゴールの文化が損なわれます。また「フォード・ピント」の悲劇が示すように、数値KRには必ず品質KRを対にすることが重要です。

▶ ⑦ 辛抱づよく、決然と

どんなプロセスにも試行錯誤はつきものです。グローブが講義で語ったように、「Intelは何度も躓いた。その基本的目的が何なのか、十分理解していなかったからだ。時間の経過とともに、少しずつうまくできるようになってきた」。システムが軌道に乗るまでに4〜5四半期のサイクルを繰り返す必要があるかもしれません。目標設定の筋肉を十分身につけるには、さらに多くの時間がかかるでしょう。クラウも「たとえ5人の会社でも、できるだけ早く始めるべきだ。その規律がもたらす価値は計り知れない」と語っています。


ボトムアップ ― 最前線からの目標設定

かつて産業界では、目標はシナイ山の石碑に刻まれた十戒のように、組織図の上から下へと伝えられていました。しかし純粋なトップダウンには4つの弊害があります。機敏性の欠如――中規模企業でも6〜7階層あり、全員が上からの指示を待っていたら目標設定サイクルに何週間もかかります。柔軟性の欠如――カスケードの手間がかかりすぎて、サイクル途中での見直しを躊躇してしまいます。コントリビューターの軽視――最前線の声が届きません。組織連携の一面化――垂直方向のみで水平連携が生まれません。

Googleのラズロ・ボック(Laszlo Bock)は「目標はパフォーマンスを高める。しかし上から下への目標伝達に膨大な時間をかけるのは逆効果だ」と著書『ワーク・ルールズ!』に書いています。

健全な組織は目標の一部をボトムアップで設定します。トップダウンとボトムアップの比率はたいてい半々だとドーアは言っています。クラウも「半分以上が個人から上がってくる必要がある。トップダウンの指示が多すぎると、人々のインスピレーションが損なわれる」と語っています。

▶ ポール・ブックハイト(Paul Buchheit)とGmail ― ボトムアップの好例

GoogleのエンジニアブックハイトはLinuxのメールクライアントに不満を持ち、「メールを検索可能にできないか」という個人的な問題意識から開発を始めました。やがてそれはGmailとなり、Googleの核心的な戦略目標の一つになりました。個人のボトムアップから会社レベルのOKRへと成長した好例です。

上意下達の逆は、グーグルの実践する「20%ルール」かもしれない。これは技術者に週1日、本業以外のプロジェクトに自由に取り組むことを認める制度だ。とびきり優秀な社員たちをくびきから解放することで、グーグルは世界を一変させた。2001年にはポール・ブックハイトが20%ルールに基づき「カリブー」というコードネームのプロジェクトをスタートさせた。それは今、世界最大のウェブベースのメールサービス「Gメール」となっている。 ( 『Measure What Matters』第7章「意識を合わせる――北極星に向けてのアライメント」)

アライメント ― 目標の透明性が協力を生む

会社全体の目標が定まったら、そこからが本番です。OKRは計画段階から実行段階へ移行し、管理職もコントリビューターも日々の活動を組織のビジョンと結びつけます。これが「アライメント」です。HBRによると、戦略にアラインした企業は同業他社の目標に入る確率が2倍だそうです。しかし「会社の戦略と自分に期待されていることを理解している」と答えた従業員はわずか7%にとどまっています。

透明性は協力の出発点になります。社員Aが目標達成に苦労していれば、公開された進捗を見た周囲がサポートを申し出ます。複数の人が同じ仕事に取り組む重複も解消されます。

クラウは自身の体験をこう語っています。「YouTubeホームページのPMだったとき、他チームから『ホームページでプロモしたい』と依頼が来る。相手が私のOKRを見れば、会話前に私の答えが予測できる。依頼が私の目標と合致していれば、協力は容易。そうでなければ、その四半期では難しいとわかる」。OKRの公開性が自然な調整メカニズムとなるわけです。

▶ 部門横断と「暗黙の依存関係」

書籍ではアンダーアーマー傘下のMyFitnessPalの事例が紹介されています。買収後の幹部OKRミーティングで、eコマース、メディア営業、その他のチームがそれぞれ特定の成果を期待していましたが、他チームが何を求めているかはまるでわかっていませんでした。どこを見ても「暗黙の依存関係」があったのです。アライメント実現まで18カ月かかりましたが、OKRがなければもっとかかっただろうとされています。

▶ クラウ と YouTubeログイン目標

クラウはYouTube PMとして、サイトにログインするユーザーの割合が低いという問題に取り組みました。CEOラリー・ペイジに相談したところ、期限9カ月ではなく3カ月とされました。全社の最上位OKRになったことで「会社のあらゆる目が僕らのチームに注がれるようになった」そうです。別の四半期では「会社の5〜6つのOKRのうち2つを自分が担当した。それは素晴らしいが、3万人の会社では少し怖い」とも振り返っています。ボトムアップの問題提起がトップのコミットメントと結びつき、全社アライメントが実現した好例です。

youtu.be

期中のトラッキングと振り返り

OKRは設定したら終わりではありません。目標からずれるのを防ぐには定期的なチェックが不可欠です。ピーター・ドラッカー(Peter Drucker)は「行動計画がなければ、経営者はただ事象の囚われ人にされてしまう」と書いています。トラッキング時の対応には4つの選択肢があります。「継続」(計画どおり)、「更新」(環境変化に応じて修正)、「開始」(新OKR追加)、「停止」(有用性を失った目標の廃止)です。OKRはガードレールであり、束縛の鎖ではありません。目標が非現実的になったら打ち切りますが、必ず振り返りを行います。

▶ 採点と自己評価 ― 数字だけでは不十分

Googleは0から1.0の尺度で採点します。0.7〜1.0が青(完了)、0.4〜0.6が黄(進捗あり)、0〜0.3が赤(実のある進捗なし)です。ただし客観的スコアだけでは不十分です。書籍では「新規顧客を10件獲得」という同じKRに対し、進捗が70%でも「市場が低迷した中での努力の結果」なら0.9、一方「100%達成だが8週間で目標が低すぎた」なら0.7といった例が示されています。OKRをそのまま評価ランクに使うのではなく、状況に応じたフィードバックとチームでの議論のほうが重要です。

▶ ふりかえりの重要性

「われわれは経験からは学習しない。経験を振り返ることで学習するのだ」とジョン・デューイ(John Dewey)は言いました。サイクルの締めくくりでは、「どのような障害があったか」「成功要因は何か」「次にどう生かすか」を振り返ります。クラウは「四半期末にOKRを振り返ると、その年に何をしたかを数分で把握でき、会社へのインパクトを要約するのが非常に簡単になる」とも述べています。そして足を止め、チームの進歩をかみしめ、成果を祝いましょう。みんな頑張ったのですから。


補足 ― OKR導入時に陥りやすい落とし穴

▶ 補足1:カスケード(上意下達型目標展開)の危険性

OKRを導入するとき、多くの組織が最初に試みるのが「カスケード(cascading)」です。CEOのOKRを部門長のOKRに分解し、それをさらにチーム・個人へと滝のように降ろしていきます。一見合理的に見えますが、ドーアは書籍の中で「すべての目標がカスケードされると、プロセスは機械的な塗り絵のような作業になる」と明確に警告しています。

純粋なカスケードには4つの弊害があります。第一に機敏性の欠如――中規模企業でも6〜7階層あり、全員が上からの指示を待っていたら目標設定サイクルに何週間もかかります。第二に柔軟性の欠如――カスケードの手間がかかりすぎて、サイクル途中での見直しを躊躇してしまいます。少しの修正でも下流の人々に負担を強います。第三にコントリビューターの軽視――厳格なトップダウンでは最前線の声が届きません。第四に一面的な連携――垂直方向のアライメントは得られますが、部門横断の水平連携が生まれません。

Googleのラズロ・ボックは著書『ワーク・ルールズ!』で「目標はパフォーマンスを高める。しかし企業の上から下へ目標を伝達するのに膨大な時間をかけるのは、むしろ逆効果だ」と書いています。クラウも後年の振り返りで2017年に「個人OKRはスキップすべきだ。特に若く小さな会社では冗長だ。会社レベルとチームレベルのOKRに集中すべき」と訂正しました。また、フェリペ・カストロ(Felipe Castro)は2012年のクラウの動画が「純粋なトップダウンのカスケードを示してしまった」ことを指摘し、動画の引退を提案したほどです。

ではどうすればよいのでしょうか。ドーア自身が書籍で推奨するのは、カスケードとラダリング(ボトムアップ)の両方を組み合わせることです。「健全なOKR環境では、アライメントと自律、共通の目標と独創の自由のバランスが取れている」と書籍にあります。組織のOKRの約半分をトップダウンで、残り半分をボトムアップで設定し、それを透明性のある公開を通じて水平方向にも接続します。これが書籍の描く「ネットワーク型」のアライメントです。

▶ 補足2:OKRは長期計画ではない ― 四半期サイクルが基本

OKRとドラッカーのMBOの根本的な違いの一つがサイクルの長さです。MBOは年次ですが、OKRは四半期または月次でまわします。グローブはこう指摘しています。「フィードバックに実効性を持たせるには、評価対象となる活動が終わった直後に行う必要がある。したがってOKRシステムは、事業計画が年単位であれば、それに対応するOKRは少なくとも四半期単位でまわすべきだ」。

ドーアは「3カ月先に締め切りが見えていれば、仕事を先延ばしにする気持ちにはなれまい」とも書いています。また「ルールは絶対的なものではなく、あらゆる組織が採用すべき単一のパターンはない」とも述べており、技術チームなら6週間サイクル、アーリーステージの会社なら月次サイクルも有効としています。要は「あなたの会社の事業環境と文化に適したサイクル」を見つけることです。

ただし例外もあります。TED Talkで紹介されたピチャイのChromeの例では、「最高のブラウザを作る」というObjectiveは3年間維持されました。しかしKR(ユーザー数)は毎年更新され、2000万→5000万→1億と引き上げられています。つまり「長期的な方向性を示すObjectiveの下に、四半期ごとにKRを刷新する」という二層構造は許容されます。クラウも「年間OKRは石に刻まれたものではない。方向を示す援助であり、目隠しではない」と述べています。 [f:id:wayaguchi:20260403094644p:plain]

重要なのは、OKRを「Q1はこれ、Q2はこれ、Q3はこれ」という年間ロードマップのように使わないことです。OKRはその四半期に最も重要なことに集中するためのツールであり、プロジェクト管理や中期計画の代替ではありません。


YouTube 参照ソースガイド

今回の記事は、以下の3つのソースを中心に構成しています。いずれも無料で視聴・閲覧でき、OKRの一次情報に触れることができます。

[1] ドーアTED Talk "Why the secret to success is setting the right goals" (約11分) https://www.youtube.com/watch?v=L4N1q4RNi9I OKRのWhy/What/HowをNuna・ボノ・Chromeの実例で凝縮した動画です。OKR入門に最適です。

[2] クラウ / Google Ventures "How Google sets goals: OKRs" (約82分) https://www.youtube.com/watch?v=mJB83EZtAjc ドーアのオリジナルデッキ(1999年)を基にGoogleでのOKR運用を詳解しています。クラウのBlogger OKR実例と採点、四半期サイクルの実務が具体的に語られています。※2017年にクラウ自身が個人OKR非推奨等を訂正しています。

[3] WhatMatters.com ― Google OKR Playbook (ドーア公式サイト) https://www.whatmatters.com/ 書籍の補足資料、OKRテンプレート、企業事例集、OKR Explainedオンラインコースを無料公開しています。


新しい決算期が始まり、新たな目標設定を行なっている会社さんも多いかと思います。制度をまるっと変えるのは現実的ではないでしょうが、OKRの運用は制度の整備以上に、目的と文化を理解することが大事なのではないかと感じています。トップダウンで人を動かすには、世の中が複雑すぎるのです。

Do you have the right metrics?

時間を取って、あなたの価値観、目標、そして主要な結果を書き出してください。今日やりましょう。 ― ドーア

スポンサーさん宛の請求書をPretixで各地スクラムフェスの実行委員が自分で発行できるように

前回の記事: Pretixで領収書(インボイス対応請求書: PAID)を再発行する方法:購入者・管理者それぞれの手順


背景・課題

スクラムフェスは、東京(RSGT)を起点に盛岡、名古屋、金沢、神奈川など各地で開催されています。スポンサー企業から協賛金をいただく際の請求書は、当初はMisocaで発行していましたが、その後マネーフォワード(MF)請求書に移行し、東京の実行委員が一括で発行していました。

これは意図的な判断でした。スポンサー請求書は差分が金額くらいで、フローを一貫させた方が間違いが少ない。それに、銀行口座の入金確認は結局東京でしかできないので、請求書の作成だけを各地にオフロードしても、あまり手間が減らなさそうだと考えていました。

ただ、この運用にはいくつかの課題もありました。

  • 一般社団法人に作業が集中する: 各地のスポンサーとやり取りしているのは現地の実行委員なのに、請求書の発行だけ一般社団法人に依頼していただく必要がある
  • 入金突合が大変: 銀行口座のCSVを目視で確認し、会社名のカタカナ表記と請求先を手作業で照合していた。まとめ振込(複数イベント分を一括入金)のパターンもあり、突合作業が複雑化していた
  • ツールが分散する: 参加者チケットはPretix、スポンサー請求書はMF請求書、入金管理はスプレッドシートと、情報が3箇所に分かれていた

「その人しかできない」はImpediment (障害物)

この課題を振り返ると、スクラムの基本原則に行き着きます。

スクラムの基本は、実務者が集まってチームになり、管理を自分たちでやるということです。チームが全情報を持つ。旧来の管理の仕組みでは、全情報にアクセスできるのはマネージャーだけ——だからマネージャーが管理「せざるを得ない」。その人しか握っていない情報があるのだから、その判断が効率的かどうかさえ検証できません。

請求書の発行が一般社団法人に集中している状態は、まさにこの構造でした。一般社団法人の担当者しか請求書を発行できない、銀行口座も一般社団法人でしか確認できない。各地の実行委員は自分のイベントのスポンサー状況を完全には把握できない。「その人しかわからない」状態は、スクラムでいう障害物(Impediment)です。

この課題はここ数年、ずっと気になっていて、色々な対策案を考えたのですが、いまひとつ決定打が見いだせないできました。

透明性がなければ、検査も適応もできない。だからキャッシュフロー情報はチームから見える場所に集めたい。これは信頼するとかしないとかの問題というより、もっと機械的なことです。でも同時に、やはりY理論で人を信頼している、ともいえます。

Beyond Budgetingとキャッシュフロー表

RSGT 2026では、Beyond Budgeting(脱予算経営)の提唱者であるBjarte Bogsnеsさんをキーノートに招き、年次予算とコントロールのサイクルを超える経営のあり方を考えました。

kawaguti.hateblo.jp

全国のスクラムフェスが赤字になれば一般社団法人の資金が尽きます。しかし黒字を積み上げることが目的ではなく、参加者の皆さんに還元することが目標です。実行委員・スタッフはボランティアですから、意思決定のたびに「節約しなければ」と委縮してほしくない。旅費などの持ち出しは避けたい。でも無駄遣いも嬉しくない——この「ちょうどいい」を全国で共有するための表がキャッシュフロー表です。

各地の実行委員がキャッシュフロー表に自分のイベントの収支を記録し、全体の資金状況が見える状態を作る。Pretixへの移行は、この設計思想を請求書発行と入金管理にも広げる取り組みです。できる限り各地の実行委員さんで自律的に!

なぜPretixか

転機になったのは、各地の実行委員がチケット販売でPretixを日常的に使うようになったことです。 pretix.eu

Pretixの操作に慣れているなら、同じ要領でスポンサー請求書も発行できるはず。MF請求書は使ったことがなくても、Pretixなら「いつもやっていること」の延長になります。これなら間違いも起こりにくいだろうと考えました。

元々使っていたEventbriteでは固定料率のため、チケットに比べて高額なスポンサー料を決済すると、利用料も高額になりそうでした。Pretixは料金に上限値があるので現実的になりました。

Pretixはもともとヨーロッパのカンファレンス向けに作られたプラットフォームで、請求書の自動生成、銀行振込への対応、多言語対応など、私たちに必要な機能がすでに揃っていました。

仕組み

スポンサー商品の公開方法は2パターン

各実行委員会の運用に合わせて選べます。現行、Google Forms を使ってスポンサー募集しているので、それを活かすならパターンA。それも飛ばして直接Pretixに応募してもらうのがパターンBです。

パターンA: バウチャー限定 — これまで通りGoogle Formsでスポンサーを募集し、実行委員がPretixに転記する方式です。請求書発行ツールだけをPretixに移す運用ができます。バウチャーコードを知っている人だけがアクセスできるチケットを作り、実行委員がアクセスして、Google Formsへの応募データから、請求書に関わる情報を転記していきます。

パターンB: ショップ公開 — そもそもスポンサー募集自体をPretixに統合する方式です。スポンサー商品をショップ画面に直接表示し、スポンサーが自分で申し込めます。趣意書に公開するURLを、PretixのショップURLにします。Pretixは購入時にアンケートフォームを表示できるので、Google Forms で集めていた情報を盛り込むこともできます。

申込から請求書発行まで

いずれのパターンでも、スポンサー企業の担当者(または代理で実行委員)がチェックアウト画面で「企業・団体顧客」を選択し、会社名・担当者名・住所を入力します。銀行振込を選択して注文を確定すると、請求書PDFが自動生成されます。

請求書にはリファレンスコード(例: 2026-UCVCJ)が付与されますが、実際にはスポンサーが振込時にこのコードを摘要に入力してくれることはほとんどありません。そのため入金突合は、会社名と振込名義の辞書的な照合で行っています。なお、支払い方法の選択画面では「銀行振込」を明示的に選ぶ必要があります(PayPalも選択可能です)。

やってみてわかったこと

実際に設定して運用してみると、いくつかPretix特有の注意点がありました。

価格は税込で入力する

Pretixの表示価格は内税です。趣意書でGold 20万円(税別)としている場合、Pretixには22万円(税込)で入力する必要があります。最初にこれを間違えると請求金額がずれるので、設定時に注意してください。

口座情報は「請求書のテキスト」に書く

Pretixの銀行振込設定には「銀行口座の詳細」と「請求書のテキスト」の2つの入力欄があります。「銀行口座の詳細」は支払い方法の選択画面に表示されるだけで、請求書PDFには印字されません。請求書に振込先を載せるには「請求書のテキスト」欄に口座情報を記入する必要があります。

イベント名が請求書に反映されないことがある

「請求書のカスタマイズ」の紹介文にイベント名を入力しても、PDFに反映されない場合がありました。設定後は必ずPDFのプレビューで確認することをお勧めします。

請求書の日付は遡及できない

Pretixの請求書の日付は注文日で自動発行されます。「12月付で発行してほしい」といった依頼には対応できないので、スポンサー企業にはあらかじめお伝えしておく必要があります。

電子帳簿保存法への対応

Pretix上にPDF請求書と注文データが保持されていますが、税理士さんに確認したところ、Pretixだけでは電子帳簿保存法の保存要件を満たさない可能性が高いとのことでした。発行した請求書PDFはMFクラウドBOXにも保存する運用にしています。

コストは増える

Pretixの手数料は1通あたり約2,000円かかります。MF請求書と比べるとコスト増になります。ただ、前述のとおりPretixは手数料の上限が2,000円なので、金額が大きくなっても手数料が膨らまないという利点があります。

各地の実行委員が自分で発行できるようになる運用負荷の軽減と、入金管理の効率化を考えると、十分見合うトレードオフだと判断しました。

インボイス制度への対応

適格請求書(インボイス)の要件として必要な記載事項は、発行事業者の名称・登録番号(T+13桁)、取引年月日、取引内容、税率ごとの合計額と消費税額、宛先です。角印や社印は法的要件ではないため、Pretixが自動生成するPDFでもインボイス要件を満たすことができます。

入金管理が楽になった — Claude Codeの活用

以前の入金突合は、銀行CSVのカタカナ名義と請求先の会社名を手作業で照合する作業でした。

名寄せ問題

難しかったのは「名寄せ」です。Pretixの請求書には「YesNoBut株式会社」と書いてあっても、銀行の振込名義は「ヤスノブ(カ」です。さらに、複数イベントのスポンサー料を合算して一括で振り込んでくださる企業もあります(手厚いご支援、大変にありがとうございます!)。単純な文字列マッチングでは解決できない、でも毎回人間が目視確認するのは非効率——そこをClaude Codeと一緒に考えながら解いていきました。

「APIの世界」と「まだCSVの世界」

Pretix移行後は、Pretix REST APIから注文データ(会社名・金額・ステータス)を取得し、銀行口座のCSVと突き合わせる処理をClaude Codeで一括処理できるようになりました。リファレンスコードが摘要に入力されていなくても、会社名と振込名義の辞書を使って照合できます。

一例として、4つのカンファレンス・18社のスポンサー入金確認という作業があります。手作業なら2〜3時間かかるところが、Claude Codeでの処理で30分に短縮されました。

ただし、銀行口座の入金データは引き続きCSVダウンロードです。「APIの世界」と「まだCSVの世界」が混在している——これが現実です。口座のトランザクション数はまだそれほど大きくないのでCSVでも十分ではありますが、手作業は減らしたいところです。

東京と各地の役割分担

入金確認の作業は以下のように分担しています。

東京の実行委員: 銀行口座(PayPay銀行)の入金明細を確認し、Pretix上で「支払い済みとしてマーク」を付ける

各地の実行委員: Pretix上で自分のイベントの入金状況を確認し、キャッシュフロー表に反映する。未入金のスポンサーにはリマインドの連絡を行う

銀行口座自体は東京で管理していますが、入金状況の確認と後続のコミュニケーションは各地の実行委員が主体的に行える体制になりました。以前の「一般社団法人→各実行委員→スポンサー」と何往復もする構造から、各地の実行委員が直接動ける構造に変わりました。

税理士さんに確認したこと

Pretix移行にあたり、顧問税理士さんに以下の点を確認しました。

売掛金の会計処理: MF会計上に売掛金を計上せず、カンファレンス開催時点で売上計上する運用で問題なし。

Pretix手数料の税務処理: Pretix運営元はドイツのpretix GmbHですが、当法人は課税売上割合が95%を超えるため、リバースチャージ方式の会計処理は不要。通常の取引登録で問題なし。

期を跨ぐ取引への注意: 請求書発行と入金が決算期をまたぐ場合は留意が必要(これまでと同様、来期分のスポンサー収入については前受金として、来期初に売上高に組み替える)。

これらの確認は各法人の状況によって異なりますので、移行を検討される場合は顧問の税理士さんにご確認ください。

スポンサー企業の皆様への感謝

今回の移行にあたり、請求書のフォーマットがMF請求書からPretix発行のPDFに変わりました。見た目や体裁が変わる中、スポンサー企業の経理担当の皆様には柔軟にご対応いただいています。スクラムフェスの運営は皆様のご支援で成り立っており、こうした裏方の変更にもご協力いただけていることに心から感謝しています。

まとめ — 完成していない実践

スポンサー請求書をPretixに一本化したことで、以下の改善が得られました。

  • 各地の実行委員が自分で請求書を発行できるようになり、一般社団法人への集中が解消された
  • Pretix APIと銀行CSVのClaude Codeによる突合で、手作業のカタカナ名義照合が大幅に効率化された
  • チケット・請求書・入金状況がPretixで一元管理でき、情報の分散が解消された
  • キャッシュフロー情報の透明性が高まり、各地の実行委員が自律的に動ける体制になった

一方で、1通あたりのコスト増、電子帳簿保存法への追加対応(MFクラウドBOXへの保存)、請求書の日付が遡及できないといった制約もあります。銀行APIはまだCSVの世界のままです。

これは完成した事例報告ではなく、「いまこうなっています」という進行形の話です。私たちのケースでは、運用負荷の軽減がこれらのコストを上回ると判断しました。同じような課題を抱えているコミュニティイベントの運営者の方に、少しでも参考になれば幸いです。

この取り組みの詳細は、Scrum Fest Kanazawa 2026向けに「アジャイルな経理と Claude Code と経営の未来」としてプロポーザルを提出しました。よかったらLikeをしていただければ嬉しいです。参加者の皆さんと一緒に考えたいと思っています。

操作ガイドは各地のスクラムフェス実行委員に共有しています。ご質問があればお気軽にどうぞ。

Pretixで領収書(インボイス対応請求書: PAID)を再発行する方法:購入者・管理者それぞれの手順

以前の記事(一部のスクラムフェス/RSGTでは、インボイス制度対応の領収書発行方法が変わります)では、購入者側の手順を中心に書きましたが、今回は管理者側の操作も含めて整理します。


そもそも領収書とは

税法上、「受取書」「領収証」「レシート」「預り書」はもちろん、請求書や納品書に「代済」「相済」などと記入したものも含め、金銭の受取事実を証明するものはすべて領収書に該当します(国税庁タックスアンサーNo.7105)。

www.nta.go.jp

多くの企業が経費精算に領収書を求めるのは、損金算入と消費税の仕入税額控除の証明のためです。Pretixが発行するインボイス対応の請求書(PAIDラベル付き)はこの要件を満たします。

 


購入者側の流れ

1. 購入時点でPAID請求書がメールで届いている

チケット購入が完了すると、Pretixから確認メールが届きます。このメールにはQRコードと、チケット情報画面へのリンク、そしてPAIDラベル付きの請求書PDFが添付されています。当日QRコードをこのメールから出している方がほとんどだと思いますので、一度は目にしているはずです。

2. 社名入り請求書が必要な場合

購入時に社名を入力しなかった場合は、確認メールのリンクからチケット情報画面を開き、「あなたの情報」欄に会社名・住所を入力してください。ただし、PDFの再発行には管理者側での操作が必要です。情報を更新した上で、実行委員会までメールまたはDiscordでご依頼ください。

 


管理者側の流れ

3. Pretixの注文画面から対象注文を検索する

Pretix管理画面の「注文」から検索します。購入者からメールアドレスを聞いている場合はそれで検索できます。確実なのは注文番号(購入確認メールに記載されています)での検索です。

 

4. 注文を確認し、再発行する

対象注文が特定できたら、以下の操作が可能です。

  • 購入者が入力した請求先情報(社名・住所)の確認・編集
  • PAIDラベル付き請求書PDFの再発行・送信
  • 請求書PDFの直接ダウンロード(メール添付で送ることも可能)

なお、再発行には回数制限があるようです。試していたところ、途中から再発行できなくなったことがありました。ただし、再発行が何度も必要になるケースは稀なので、通常は支障がないと思います。

 

 

追記: 管理者側のオペレーションなしで、請求書を自動再発行する機能はありますが、オンしないほうがいいと思います

一見管理者は楽そうですが、以下のケースでまずそうなので、この機能はONにしない(デフォルトOFF)のがいいかなと思います。

まずそうなケース

 1. 第三者にURLが知られた場合に、勝手にキャンセルされて別社名で発行される
 2. 本人が複数枚の領収書を欲しい場合、複数社名の有効な領収書を容易に得られる

いずれにせよ発行者の責任も問われるケースになると思うので、ここは自動化せず、念のためご連絡をいただく現行のフローがいいんじゃないかなと思います。

 


まとめ

Pretixへの移行後、インボイス対応の領収書はシステムから直接発行できるようになりました。購入者・管理者それぞれがやることは上記の通りシンプルですが、「社名を後から入れたいが再発行のボタンが見当たらない」というお問い合わせもありました。お困りの際はお気軽にご連絡ください。

「SaaS is Dead」は粗製濫造の話ではない

先日、レッツゴーデベロッパー仙台2026で「Claude Code for NOT Programming」というLTをしました。Claude Codeをコーディング以外の作業に使ってみたら便利だった、という話です。そのLTの準備を通じて「SaaS is Dead」について考えたことを書いてみたいと思います。

LTスライド → https://speakerdeck.com/kawaguti/claude-code-for-not-programming
イベント → https://lets-go-developer.connpass.com/event/380700/

「SaaS is Dead」の誤読

「SaaS is Dead」という言葉が飛び交っています。AIエージェントでアプリを粗製濫造できるようになるから、という読み方をしている人も多いようです。私も最初はそういう想像をしなくもなかったのですが、たぶんそうじゃないんじゃないかと思っています。

ソフトウェア自体が「痒いところに手が届く」ようになる

これから起きるのは、AIのチャットインタフェースを通じて、ソフトウェア自体がもっと柔軟に人に寄り添うようになる、ということだと思います。

多少入力を間違えても対応してくれる。そもそもこれからやろうとしていることを、先にプランしてくれる。たとえば経費精算したいとき、会社の経費精算アプリのマニュアルを読むのではなく、レシートを見せてAIに聞く。やり方から仕組みまで教えてくれます。聞かなくてもオートで進む。しかも間違えない。

「間違えない」がなぜ可能になったのか

この「間違えない」が大事です。AIといえばハルシネーション、とバカの一つ覚えのように言う人が多い気がしますが、LLM(AIエージェント)を複数使って相互にチェックすることで、ミス率が大きく減ってきました。人間が複数人でチェックするのと同じ仕組みです。これによって、人間に情報が届く頃には、操作している人間以下のミス率で仕事が遂行されるようになってきています。

SaaSが担ってきた「定型業務」の価値が揺らぐ

もちろん万能ではありません。でも、そもそもSaaSって、経費精算とか人事とか営業支援とか、それほど考える必要がない定型業務をミスなく進めてもらう仕組みでした。Coworkのようなツールを使えばミスがなくなる(かもしれない)。少なくとも、これまでのようなコストメリットは得られなくなります。しかも用途ごとにさまざまなSaaSを別々に契約する必要もない。昔ながらの古いUIのままでも構わないかもしれません。

つまり、多くの人が想像してきたDXのビジネスチャンスが萎む可能性があります。

SaaSは「土管」になるのかもしれない

これまでは「検索エンジンが代替される!」とGoogleが騒いだのが最初でした。Googleは見事に対応して強者であり続けています。次に起きるのは、「使いやすいUIとサブスクリプションを売りにしてきたSaaS業務アプリが、単なる土管(API)でよくなる」という話ではないでしょうか。UIを頑張らなくても、REST APIをかっちり提供してくれれば、UIはCoworkがやってくれます。

そうなると、社員全員に配られる、思ったより高額な一席いくらの定額サブスク費は、もう取りにくくなるんじゃないかと。そういう想像が働いての「SaaS is Dead」なのかなと思っています。

「RPAの悪夢再来」か、それとも

日経クロステックの木村岳史さんが「『SaaS is Dead』かどうか知らんが、AIエージェントはRPAの悪夢再来だぞ」というコラムを書いていました。業務プロセスがブラックボックスのままAIエージェントを走らせたら、RPAのときの悪夢が再来する、という警鐘です。
https://xtech.nikkei.com/atcl/nxt/column/18/00148/020900421/

これはもっともだと思います。ただ、私はもう少し楽観的に見ています。RPAは「画面のここをクリックして、ここに入力して」という手順の記録再生でした。だから業務が変わると壊れるし、ブラックボックスになりやすかった。一方、AIエージェントは「何を達成したいか」を理解して、手順を自分で組み立てます。手順ではなく目的に基づいて動く。これはRPAとは本質的に異なります。悪夢の再来というよりは、RPAが目指していたものの正しい実装に近いんじゃないかと思っています。

想像と期待の世界

まあ、そんなにみんなが使うだけのAI用のCPU資源があるのかはわかりません。でも日々高性能なGPUがデスクトップに配られているわけで、市場はそこは楽観的なのかもしれません。

株価の話なので、想像と期待の世界です。そうなるかどうかはわからないけど、株価は反応しました。という理解です。

 

 

 

学生向けPBL 最終回に伝えたいこと

この講義のスタッフは、現役の企業人で構成されています。実際の社会人生活で起きてきたことを、できる限り再現することを目標に作りました。

まず、受講者をお客様として扱わないこと。

企業では、皆さんはお客様ではありません。何か社業に関わることに貢献する人材として期待されています。ですので、準備が整った講義を予定通り受講できるような世界は、一切ありません。

私たちは一時的な大学教員ではありますが、皆さんに対して教育サービスを提供するつもりで準備はしていません。その点で他の講義と大きく違う点があり、戸惑った方もいらっしゃると思います。

でも、社会に出ると万事この通りです。そこは、できる限りリアルに作ったつもりです。

準備も、かなりできている方だと思います。皆さんも修士一年でお忙しいと思いますが、私たちもフルタイムの仕事がある中で、夜に時間を作り、環境を整えてきました。お互い様です。

人によっては、準備ができていないことに不満を持つ人もいるでしょう。人のせいにする人のことを「他責指向」と呼びます。社会に出て何か活動をするときに、他責指向の人は、なかなかうまくいきません。人を助ける人が、長期的には頼りにされ、一人でできる以上の実績を出していくのを、私たちはたくさん見てきました。他のチームを助けることを、この講義の評価としてとても重視しました。それは、皆さんにできる限りこの成功の秘訣を体験してほしいからです。

教育課程では、皆さんを競争させ、トップを取った人に良い成績を与えるという、外発的動機付けで評価をするケースも多くあると思います。一見それはフェアに評価できるように見えるかもしれませんが、社会で必要なのは、チーム全体やもっと大きな組織全体での成功に貢献することです。一人一人を競争させることで評価をつけるのは、それが単に楽だからです。

例えば、ある企業が何か製品を売っているとして、それを最もたくさん売った人が評価を受けることは、それなりの妥当性があると思いますが、一方で、その製品を作るために努力した人、とてもスムーズに運搬できるようにした人、売った後にサポートをして企業のイメージをよくした人...多くの貢献があってその製品が売られており、それがブランドの全体を構成します。優れた企業は、さまざまな立場の関係者の皆さんの内発的動機付けに支えられて成り立っているのです。

この講義は、情報科学の講義の一環なのですが、この仕事のなかには人間関係に関することが多くかかわります。そもそも人々の要求をかなえるという時点で、人とのコミュニケーションは欠かせないのです。

ソフトウェアが抱える問題の多くは、社会的なものです。 ―― Tom DeMarco & Timothy Lister『ピープルウエア』

それでも、チームとして結果を出していく必要があるのが社会です。もしかすると、他責指向の人がチーム内にいたかもしれません。すごくできる人かもしれません。でも、そういう人と仕事をするのは、とても疲れます。一緒に仕事をすると、気持ちが落ち込むような人たち。そういう人を、ブリリアントジャークとか、クソッタレ(Asshole)といったりします。これは経営学者が作った用語なので、一般的なものです。今後もそういう人はいらっしゃるでしょう。

参考:『あなたの職場のイヤな奴』ロバート・I・サットン(講談社)

準備が十分にできていない中でもベストを尽くす姿をお見せしたつもりです。社会人生活で必要なことの一つが、この姿だと考えているため、できてないふりをすることなく、皆さんにできる限り透明性をもってお伝えしたつもりです。


この講義の中ではあまりアジャイルを強調してきませんでしたが、私たちは、アジャイルのコミュニティに属しています。短い期間でスプリントを行い、毎回動くソフトウェアを使ってもらってレビューをもらったり、そのことを通じて多様な専門家が集まったチームで、より上手に作れるようになっていくことを目指しています。

技術を高めることは大変で、短い期間ではなかなかうまくならない部分もあります。必要とされる範囲も広く、さらに日進月歩で高度に発展してしまいますので、常に情報を集め、学び続けることが必要な業界です。ソフトウェアはコピーできるものですので、これから作る必要があるということは、まだ世の中に存在しません。ですから、予測も難しいことが常です。

ただ作ればいいということではなく、ユーザーのアウトカム、ビジネス上のインパクトを出してこそ、作り手である私たちの給与の原資が生まれるのです。

参考:あなたのプロダクトの価値はなんですか?いまさら聞けないアウトカムとインパクトの話 ジェフ・パットン氏基調講演 RSGT2025


www.youtube.com

アジャイルは、予定通りに行かないビジネスの世界で、現実に即して、できる限りのことをするプラクティスの集合体です。そこには、お客様はおらず、全員が貢献者としてふるまいます。あなた方のために親切丁寧に準備を整えてくれる先生はいません。

私たちはこれまで、そういう世界で、準備が整っていない環境の中で、できる限りの準備を進めることをしてきました。

予定通りに事が進むなら、誰でもできることです。それでは商売になりません。


ぜひ、皆さんの今後の成功を祈っています。

興味を持っていただいた方は、アジャイルコミュニティでお会いしましょう。

プロダクトオーナーの本質 ― アニメ・ゲーム・自動車業界の名プロデューサーたちに学ぶ

昨日(2026年1月30日)、『機動戦士ガンダム 閃光のハサウェイ』第二部『キルケーの魔女』が公開されました。第一作から約5年。待った甲斐があったと思える作品でした。

今日の舞台挨拶で、村瀬修功監督がこう語っていました。5年かけて作った。それでも2ヶ月前は出せるかどうかわからない制作状況だったと。

すごい話です。5年かけて作っているからアジャイルじゃない、と思う人がいるかもしれませんが、これは、ウォーターフォールアジャイルかという話じゃない。


プロダクトオーナーとプロダクトマネージャーの違いを超えて

ここで一旦、用語を整理しておきます。プロダクトオーナーとプロダクトマネージャーは何が違うのですか?というご質問をよく受けます。

プロダクトオーナー(PO)はスクラムで定義された役割で、トヨタの主査制度を原型としています。バックログを整理する人、優先順位をつける人、ステークホルダーと開発チームの橋渡しをする人。あるいは「最終決定権を持つ人」ということで、自社や顧客企業の予算権限を持つ偉い人をPOに据えるケースもあります。どれも間違いではないのですが、どこか本質を捉えきれていない気がしています。プロダクトオーナーはすべてを見ないといけません。その源流はトヨタの主査制度にあるそうです。

ジェフ・サザーランドは著書『スクラム』でこう書いています。

プロダクトオーナーという役割は、トヨタのチーフエンジニアから発想を得たものだ。(中略)トヨタの名高いチーフエンジニア制度(以前は主査と呼んでいた)といえば、「トヨタ生産方式」を率いるリーダーのようにイメージするかもしれないが、実際、チーフエンジニアに権限はない。直属の部下は持っていない。

プロダクトマネージャー(PM)は米国で生まれた職制です。1931年にP&Gで生まれた「ブランドマン」の概念が、ヒューレット・パッカード(HP)を経てシリコンバレーに広まったそうです。米国企業のPMさんの話を聞くことも何度かありましたが、スクラムにおけるPOとはかなり違う役目なのではないかと推察しています。

プロデューサーは、ゲーム業界や、映画、アニメ、TVなどの作品に関するプロジェクトでよく目にする役割です。現場を取り仕切るのがディレクターで、プロデューサーはプロジェクトそのものを起案したり、予算を確保したり、全体の進捗を管理する役割として語られていると思います。

最近、アニメやゲーム業界の優れたプロデューサーたちのインタビューを読み返して、POの本質について考え直すきっかけを得ました。彼らは「雇われて要件整理する米国型プロダクトマネージャー」でもなければ、「予算を取るだけの社内政治家」でもありません。プロダクトに心血を注ぎ込むクリエイターたちと徹底的に具体的な話をしつつ、任せて待つ度量も持っています。


小形尚弘プロデューサー ― 入社時からの夢を形にする

閃光のハサウェイ』のプロデューサー・小形尚弘氏は、第一作公開時(2021年)の電ファミニコゲーマーのインタビューでこう語っています。

僕は中学生のころに劇場版『逆襲のシャア』を見て、その流れで小説の『閃光のハサウェイ』を手に取って、その内容にショックを受けた世代だったんですけど、就職でサンライズに入社することになり、そのときからいつか『閃光のハサウェイ』をアニメ化したいと思っていたんです。

中学時代から温め続けた夢を、プロデューサーとして実現する。それだけでも十分すごいのですが、注目すべきはその実現の仕方です。

小形氏が最初に声をかけたのは村瀬修功監督でした。『ガンダムUC』で絵コンテや作画を依頼し、「次は一緒にがっつりと作品を作りたい」と思っていた人物です。村瀬監督には『F91』でやりきれなかった思いがあると感じ取り、富野由悠季が執筆した『閃光のハサウェイ』なら受けてもらえるかもしれないと考えてオファーしました。

結果、第一作は興行収入22億円を超える大ヒットとなりました。そして第二作『キルケーの魔女』まで約5年。公開2ヶ月前まで出せるかどうかわからない状況だったといいます。それでも待てる。なぜなら、このプロダクトが世に出る意味を、誰よりも深く理解しているからです。


www.youtube.com


福士裕一郎アニメーションプロデューサー ― 作品の仕上がりを左右する存在

『葬送のフリーレン』のプロデューサー・田口翔一朗氏(TOHO animation)は、アニメイトタイムズのインタビューで印象的なことを語っています。

アニメ化を企画するにあたり、私としては「どのアニメーションプロデューサーと組むのか」という部分を非常に重視しました。私はもともとアニメ制作スタジオで制作進行をしていました。だからこそ、"アニメーションプロデューサーによって作品の仕上がりが変わる"という認識がありました。

田口氏が選んだのは、マッドハウスの福士裕一郎氏でした。「モノ作りにかける情熱は業界内でも有名で、確かなもの」だといいます。

福士氏は斎藤圭一郎監督をはじめとする素晴らしいスタッフを集めました。斎藤監督には「人望の厚さや手腕」があり、「斎藤圭一郎さんがやるなら是非自分も参加させてもらいたい」という人が集まってきたそうです。

ここで重要なのは、田口氏が「企画と製作」に専念し、現場の構築はアニメーションプロデューサーに任せていることです。大まかな地図を描き、適切な人を選び、あとは任せる。劇伴作家や主題歌アーティストの提案など、自分の責任範囲では徹底的にこだわりつつ、現場には口を出しすぎない。そういう姿勢が見えます。

www.animatetimes.com


シブサワ・コウ ― 制作を積み上げないとプロデューサーはできない

コーエーテクモホールディングス代表取締役社長の襟川陽一氏(シブサワ・コウ)は、CEDEC 2023の基調講演で、プロデューサーについてこう語りました。

プロデューサーには先を見る力が必要だ。そのプロジェクトにはどれくらいの人員や予算、時間が必要なのかといったことが把握できないと務まらない役職で、そのためにはさまざまな現場経験が必要になる。

コーエーテクモでは基本的に社員を新卒で採用し、育成を続けてパートリーダー、ディレクター、プロデューサー、やがては役員へと成長させます。現在の役員は全員新卒入社で、かつ全員が開発の仕事も抱えたプレイングマネージャーだそうです。

4Gamerの過去記事でも、襟川氏は「プロデューサーは制作をやって積み上げないとできない」と述べています。同社が中途採用をせず、新卒から叩き上げで制作を育ててきた理由がここにあります。

これは「品質・納期・予算」の管理にも関わります。襟川氏は管理を「一定の範囲内に結果を収めること」と定義し、「いくらいいタイトルを作れても、管理ができなければ大赤字になり、会社も大きな影響を受ける」と説いています。プロデューサーは経営者と同じ。ゲーム会社の盛衰は優れたプロデューサーがどれだけいるかで決まります。


内山田竹志 ― 中学時代の夢を世界初の量産ハイブリッド車で実現した主査

ゲーム業界だけでなく、自動車業界にも同じ構造があります。

トヨタ自動車の内山田竹志氏は、2023年の株主総会でこう語っています。

私は少年のころから大変クルマが好きで、中学2年生のときに「将来大人になったら、自動車会社に入って、自分が企画したクルマを世の中に出したい」と思って、ずっと学生時代を暮らしておりました。そして、念願かなって、トヨタ自動車に入社することができ、さまざまな開発に携わることができましたし、初代プリウスを世の中に送り出し、子どものころの夢を実現することができました。

1997年に「21世紀に間に合いました」のキャッチコピーとともに発売された初代プリウス。世界初の量産ハイブリッド車であり、同等のガソリン車の約2倍という燃費を実現しました。その開発責任者(主査)が内山田氏でした。

興味深いのは、内山田氏がそれまでチーフエンジニアの経験がなかったことです。「ゼロから新しいモデルを作り上げるには予断のないことがむしろ好都合」と考えられ、リーダーに抜擢されました。

開発目標は「燃費2倍」。従来技術では到底達成できない目標でした。豊田章男氏(現会長)は内山田氏についてこう語っています。「燃費を倍にというのは、とんでもない目標だったと思います。それを経営陣ではなく、チーフエンジニアという立場でリードした」。

プリウス開発の特徴は、タスクフォースチームによる部門横断の協働でした。内山田氏は後にこう振り返っています。「欧米のエンジニアと話していてよく聞かれたのは、2モーターを器用に使って複雑に絡み合うシステムをどうやって作ったのかということでした。タスクフォースチームを作って技術者同士が話し合って問題を解決したと話すんですが、なかなか理解してもらえない。欧米の縦割り社会だと、われわれのようなやり方は難しいところがあるようです」。

正式な開発着手から約2年で、未踏の技術を量産化するという異例のプロジェクト。経営陣が「できなければプロジェクトは解散」とまで言ったハイブリッド化の決断。それを受けて立ったチーフエンジニア。内山田氏は「技術者冥利、チーフエンジニア冥利に尽きるプロジェクトだった」と語っています。

トヨタの「主査」(チーフエンジニア)制度は、ジェフ・サザーランドが著書『スクラム』でプロダクトオーナーの原型にしたと書いています。

サザーランドはこう説明しています。チーフエンジニアには権限がない。直属の部下を持たず、誰かの業績評価や昇進・昇給を決める権限もない。代わりに「どんな車にするかというビジョンと、その車をどう造るかを決める役割を担う。この決定を、強制や圧力ではなく、説得を通じて行なう」。

そして「スクラムで実現したいのはまさにこの考え方だった」と。

ただし、この役割を果たすには「普通ならその道で三〇年くらいの経験がなければ務まらない」。そこでサザーランドは、この役割を二つに分けました。仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオーナーが担う、と。

スクラムと初代プリウスプロジェクトの比較については、トヨタの竹内さんと南野さんが分析しています。

youtu.be


宮本茂 ― なにもできないからプロデューサーになった

任天堂宮本茂氏は、2024年1月のほぼ日インタビューで、示唆に富むタイトルの記事を残しています。

「なにもできないからプロデューサーになった」

『マリオ』『ゼルダ』『ピクミン』を生み出した、世界で最も尊敬されるゲームクリエイターの一人が、自らをそう表現しています。

宮本氏がプロデューサーとして何をしているかは、任天堂の「社長が訊く」シリーズなどで垣間見ることができます。彼は現場に深く入り込み、操作したときの手応えにこだわり、ダメ出しをします。しかし、それは「自分がすべてを作る」こととは違います。最少人数のチームで始め、できる人に任せ、最終的な判断だけを下す。

ただし、「任せる」というのは、単に金と時間を渡すことではありません。

2017年のCEDECで、『ゼルダの伝説 ブレス オブ ザ ワイルド』の開発チームが行った講演が話題になりました。そこで明かされたのは、「引力」「三角形の法則」「3つのものさし」といった設計思想の徹底的な言語化でした。

ゲーム世界の距離感を決めるために、開発チームは京都市内を地図片手に実際に歩き回りました。ダンジョンの所要時間を決めるために、京都の観光名所をゲーム内に再現してリンクに探索させました。「郵便ポストと出会う頻度」を基準に、モンスターの配置密度を議論しました。

大人数でゲーム世界を同時開発するために、「フィールドタスクビュー」という仕組みも作りました。制作中のマップに「工事中」の看板を立て、誰がどこを作っているか、どんな議論があったかをチーム全員が共有できます。重複や手戻りを防ぐだけでなく、スタッフ同士がアイデアを出し合って改良できる土台になりました。

講演を聞いた記者は、こう書いています。「任天堂のゲーム作品と聞くと、『独特なセンス』でゲーム仕様を決めて、調整に時間を掛けてバランスさせて開発しているイメージを勝手に抱いていた。まさかここまで事前に理詰めの調査や実験を行って仕様を策定していたとは」。

こういうものづくりは、ただ金と時間を渡すだけでは起きません。プロダクトの本質を一緒に考え抜き、チームが自律的に良いものを作れる仕組みを整える。それがあって初めて「任せる」が機能します。

以前、宮本氏が「うちはタレント事務所ですから」と話したと聞いたことがあります。冗談めいても聞こえますが、「それくらいIPを大事にしている」と受け取ることもできます。そして同時に、タレント(才能ある人材)を活かすことがプロデューサーの仕事だという意味にも聞こえます。


手作りのカンファレンス、手作りのチーム

レベル感は全然違うのですが、自分がやってきたソフトウェア開発やカンファレンス運営にも、同じ構造があります。

ソフトウェア開発では、自分が発注者であり、自分が作って成功させ、ユーザーを楽にするというところにこだわってきました。もちろん継続的にみんなでやります。そのためのチームでありスクラムです。

カンファレンスも同じです。手作りで行って、主役であるスピーカーさんや参加者の方々が楽しく学べるような場所を作る。みんなでバランスを取ります。予算と時間の制約の中で、クオリティを追求します。

kawaguti.hateblo.jp

www.wiajapan.org

この全部やる感覚がプロダクトオーナーの感覚に近いんじゃないかと思います。もちろん全部はできないんだけど。

すなわち各人が、各研究者も教授も、アーティストでありデザイナーでありサイエンティストでありエンジニアであり、なおかつ教授の場合ビジネスマンでもなきゃいけない。一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終わっている。 もちろんすべての学問でNo.1にはなれませんけども、それぞれの言語をfluentに話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これからやっていけない、というふうに思います。 ― 石井裕先生 2005年講演(メモ

漫画原作ドラマ/アニメにおける漫画家の立場と、ビジネスの関係については山田玲司さんの話が参考になります。厳しい納期に合わせてビジネスを成立させる感覚と、アイデアをクオリティに転換するための十分な時間を確保して打ち込むという感覚がうまくバランスできないと、こうしたものは作れないんだろうなと。


www.youtube.com

Netflix『THE DAYS』の増本淳氏は、もともとテレビ局の社員で、ドラマのプロデューサーなのですが、実はこっそり脚本も書いていたそうです。プロデューサーでありながら、制作の核心に関わる。


www.youtube.com


プロダクトオーナーの本質とは何か

これらの事例から見えてくるプロダクトオーナーの本質は、次のようなものです。

1. プロダクトへの深い愛着と理解 小形氏の「中学時代からの夢」、内山田氏の「中学2年生のときからの夢」。プロダクトを誰よりも愛し、その価値を信じています。

2. 適切な人を選び、任せる力 田口氏が「どのアニメーションプロデューサーと組むか」を最重視したように、誰と組むかがすべてを決めます。そして、選んだら任せる。

3. 制作経験に基づく判断力 シブサワ・コウの「制作を積み上げないとプロデューサーはできない」。現場を知らなければ、適切な判断はできません。

4. 待つ度量 第一作から第二作まで約5年、公開2ヶ月前まで出せるかわからない状況でも待てる。それは信頼であり、覚悟でもあります。

5. 品質・納期・予算のバランスイデアとクオリティを追求しつつ、ビジネスとしても成立させる。この両立こそがプロデューサーの腕の見せどころです。

6. チームが力を発揮できる仕組みを作る ただ金と時間を渡すのではなく、設計思想を言語化し、部門を超えて協働できる土台を整える。任天堂のフィールドタスクビューも、トヨタのタスクフォースチームも、その例です。


おわりに

スクラムの文脈で語られるプロダクトオーナーは、ともすれば「バックログを並べ替える人」に矮小化されがちです。しかし、本当に優れたプロダクトを生み出すPOは、もっと深いところでプロダクトと関わっています。

クリエイターと、カネと政治の問題。プロデューサーが作品をリスペクトしているかどうか、すごく重要なのだと思います。そして、予算も納期も人も確保しなければならない。ビジョンと現状を真摯に説明し続ける必要もあるでしょう。ただし、社内の主要なポジションにいても、十分にプロダクトに関われないのであれば職責を果たすことはできません。

これは、ウォーターフォールアジャイルかという話じゃない。

プロダクトを心から愛し、人を選び、任せて待ち、最後は自分が責任を取る。それがプロダクトオーナーの本質なのだと思います。

「レシピを捨てよ、シェフになれ」― RSGT2026で語られたアジャイルの未来

2026年1月、羽田空港直結のベルサール羽田空港で開催されたRegional Scrum Gathering Tokyo 2026。今年の3つの基調講演を聴いて、私の中で一つのキーワードが浮かび上がりました。

「自律」

予算管理の自律、アジャイル実践の自律、そしてAI時代における人間の自律。三者三様のテーマでありながら、根底には同じ問いかけがありました。

2026.scrumgatheringtokyo.org



100年前の発明に縛られていないか?

初日に登壇したBjarte Bogsnes氏。Beyond Budgeting Roundtableの会長であり、北欧最大のエネルギー企業Equinorで従来型予算を廃止した張本人です。

彼が最初に投げかけた問いが印象的でした。

「あなたの会社で使っている予算管理の仕組み、いつ発明されたものか知っていますか?」

答えは、約100年前。マッキンゼー創設者ジェームズ・O・マッキンゼーが体系化した手法が、いまだに多くの企業で使われているのです。

Bogsnes氏は「信号機とラウンドアバウト」という比喩を使いました。従来の予算管理は信号機のようなもの。過去のデータをもとに、現場にいない誰かがルールを決め、現場はそれに従うだけ。一方、Beyond Budgetingはラウンドアバウト。現場のドライバー自身がリアルタイムの情報をもとに判断する。

研究によれば、ラウンドアバウトの方が事故も少なく、交通の流れも効率的だそうです。組織運営にも同じことが言えるのではないか、というのが彼の主張でした。

興味深いのは、彼が「予算を廃止しろ」と言っているわけではない点です。予算が持つ3つの機能―目標設定、予測、リソース配分―を分離し、それぞれ適切なタイミングで見直すことを提案しています。

年に一度の儀式的な予算編成から、継続的な対話と調整へ。これはまさにスクラムの「検査と適応」そのものです。



家畜化されたアジャイルを野に放て

2日目のDave Snowden氏の講演タイトルは「Rewilding Agile(アジャイルを野生に戻す)」。Cynefinフレームワーク創始者であり、DSDMコンソーシアムの創設メンバーとしてアジャイルの黎明期から関わってきた人物です。


彼は現在のアジャイルを「家畜化された犬」に例えました。

野生のオオカミは5種類しかいませんが、高いレジリエンスを持っています。一方、人間によって家畜化された犬は数百種に分化し、見た目は多様になりましたが、多くは野生では生きていけません。

アジャイルも同じだと彼は言います。アジャイルマニフェストが掲げた価値と原則は、認定制度や方法論、フレームワークによって「家畜化」されてしまった。レシピ通りに作ることしかできない人が増え、状況に応じて判断できる「シェフ」がいなくなった。

Too many recipe book users, very few chefs
レシピ本ユーザーは多いが、シェフがほとんどいない

この言葉が会場に響きました。

Snowden氏はまた、複雑性科学の観点から興味深い指摘をしています。

複雑系は分解と再結合でスケールする。集約や模倣ではない」と。大規模フレームワークを導入すれば解決する、成功事例をコピーすれば再現できる、という発想への警鐘です。



「逃げちゃダメだ」― スクラム第二章の幕開け

3日目のクロージングキーノートは、ウルシステムズ創業者の漆原茂氏。AIエージェント「Devin」を使った開発の実践者として、現場のリアルを語りました。

札幌市役所の150万ステップ置き換えプロジェクトでは、最大200のDevinを並列稼働させ大幅なコスト削減を実現。「グレない、拗ねない、1 on 1 要らない。言ったこと忘れない」とAIの特性を表現し、会場の笑いを誘いました。

しかし、彼の講演の核心はAIの凄さを語ることではありませんでした。

むしろ、AIが当たり前になる時代に「人間に何が残るのか」を問いかけていました。


  • 何を作るかを決める意思決定
  • 「なぜそれを今やるか」の判断
  • 技術的不確実性への対応
  • 説明責任、価値や倫理の判断
  • ナレッジを抽出し、共有すること
  • モデリング、メタ設計

これらは当面、人間にしかできないことです。

漆原氏はスクラムの5つの価値を、AI時代に合わせて再解釈することを提案しました。


価値 AI時代の解釈
勇気(Courage AIに任せすぎない勇気
集中(Focus) 「問い・学び」に集中
確約(Commitment) 「価値」へのコミット
尊敬(Respect) ヒトとAIの役割を尊重
公開(Openness) AIの判断・限界を開示

講演の最後、漆原氏は静かに、しかし力強く言いました。

スクラムの第二章が幕を開けた。逃げちゃダメだ



三つの講演が指し示すもの

Bogsnes氏は「信号機からラウンドアバウトへ」と語り、Snowden氏は「レシピ本ユーザーからシェフへ」と語り、漆原氏は「タスク消化から問いと学びへ」と語りました。

言葉は違えど、すべて同じことを言っています。

「与えられたルールに従うのではなく、自分で判断せよ」

予算も、フレームワークも、AIも、すべて道具に過ぎない。道具を使いこなすのは人間です。そして使いこなすためには、原則を理解し、状況を見極め、自分で判断する力が必要です。

Snowden氏の「シェフになれ」という言葉が、三つの講演を貫くメッセージを象徴しているように思います。レシピに書いてあるから砂糖を入れるのではなく、今ここで何が必要かを判断して蜂蜜を使う。そういうマインドセットが、これからのアジャイル実践者に求められています。



さいごに

RSGT2026の3日間を終えて、アジャイルコーチとして心に強く思ったことがあります。

フレームワークを押し付けるのではなく、皆さん一人ひとりが「シェフ」になるためのトレーニングやコンサルティングを続けていきたい。

AI時代になると、定型的な作業は機械がやってくれるようになります。残るのは、判断と意思決定と、人間同士のつながりです。

スクラムの第二章が始まりました。

みんなで始めていきましょう。