『Explore It!』——プロダクトのふるまいを探索し、驚きを発見する探検家のために

8月28日に『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』(エリザベス・ヘンドリクソン著、スクラムフェス新潟訳、ZEN大学出版会)が発売されます。訳者のひとりとして、この本の中身を紹介します。

テストの本ですが、プロダクトマネージャーやプロダクトオーナー、つまり要件を定義する人にこそ読んでほしい一冊です。AIがコードを書く時代に求められているのは、コーディング技術ではなく、プロダクトのふるまいを探索し、驚きを発見する探検家。本書は、ソフトウェアを未知の大地に見立てて踏み込む、その技術を教えてくれます。プログラミングの知識がなくても読めるように書かれています。

テスト=チェック+探索

本書の序盤に、著者ヘンドリクソンの同僚のこんなため息が出てきます。机の上に積まれた厚さ1インチのテストケースの山を指して——「どれだけたくさんのテストを書いても、どれだけたくさんのテストケースを消化しても、一番深刻なバグが見つかるのは決まって手順書から外れた操作をしたときなのよ」。

心当たりのある人は多いのではないでしょうか。データ、構成、相互作用、タイミングのバリエーションは無限にあり、すべてを事前のテストケースでカバーすることは論理的に不可能です。だから本書は、テスト戦略が答えるべき質問を2つに分けます。「ソフトウェアは、想定される条件のもとで意図した通りに動作しますか?」——これは事前に設計したテストでチェックできます。「その他のリスクはありますか?」——こちらに答えるのが探索です。両方やって、はじめて「テスト完了」。

つまり、ソフトウェアは「お願いしたとおりにできている」ことのチェックだけでは足りず、「おかしなことが起きていない」ことの探索が必要なのです。解説を寄せてくださった和田卓人さんは、この「テスト=チェック+探索」という整理を「既知を既知にピン留めするのがチェックであり、未知を既知に持ってくるのが探索である」と読み解いています。探索が未知を切り開き、自動テストがそれをピン留めして、既知の陣地が広がっていく。探索的テストは自動テストと対立するものではなく、両輪なのです。

第I部 基礎の確立(第1〜5章)——探索を「設計された実験」にする

第1章の冒頭に登場するのは、初期のコンピューターENIACの逸話です。ネズミがケーブルをかじるリスクに対して、開発チームは推測で議論する代わりに、飢えたネズミに候補のケーブルを与えてみました。結果、ネズミの好むケーブルは採用を見送られます。テストの本質は「リスクに関する質問に答えるための経験的証拠を集める実験を設計すること」——本書を貫く定義です。

探索を方向づける道具が「チャーター」です。モデルは、ジェファーソン大統領が探検家ルイスとクラークに与えた大陸横断の指令。「どこを探索するか(ターゲット)」「何を使うか(リソース)」「どんな情報を発見したいか」の3要素で、探索のミッションを短い一文にします。チャーターの種は、要件、ステークホルダーからの質問、既存の成果物から拾えます。プロダクトの最悪の事態がニュースの見出しになる想像からリスクを洗い出す「悪夢の見出しゲーム」というチームワークショップも紹介されます。

続く章では、探検家の基礎体力を鍛えます。観察の章のタイトルは「ところで、ムーンウォークする熊を見ましたか?」。人間は注意を向けたものしか見えない——だからこそ意識的に視点を変え続け、コンソールやログも使って「見えないものを見えるようにする」技術が要ります。バリエーションの章では、揺さぶるべき「変数」の見つけ方を学びます。サイズ、深さ、タイミング、相対的位置……。Therac-25の放射線事故やアリアン5の爆発を招いたのは、まさにこうした「とらえにくい変数」でした。そして評価の章では、仕様書に書いていなくても「これはおかしい」と判断するための基準——「決して〜ない/常に〜する」というNever/Alwaysルール、内部一貫性、標準規格との比較——が示されます。

第II部 次元を追加する(第6〜9章)——「次に何を試すか」を系統的に生み出す

探索が行き詰まるのは、たいてい「次に何を試せばいいか」が尽きたときです。第II部は、プロダクトを分析する軸を4つ追加して、試すべきバリエーションを系統的に生み出せるようにします。

ひとつめは手順と相互作用。画面の名詞と動詞を組み合わせ、ランダムな操作を混ぜ、ペルソナになりきって「その人ならやりそうなこと」を徹底的にやってみる。ふたつめはエンティティと関係性。プロダクトが扱うモノを洗い出し、それぞれをCRUD(作成・読み取り・更新・削除)で攻め、データの流れを追いかける。みっつめは状態遷移。状態とイベントのモデルを描くと、「この状態でこのイベントが起きたら何が起こる?」の答えを誰も知らないセルが「???」として浮かび上がります。ここが驚きを発見する絶好の機会です。よっつめはエコシステム。システムを取り巻く依存関係を図にして信頼境界を見つけたら、探検家の仕事はその信頼をあえて裏切ってみることです。

第III部 文脈に沿って考える(第10〜13章)——現場に持ち帰る

第III部は、身につけたスキルを現場の文脈に合わせて使う方法です。UIのないAPIやWebサービス、プログラミング言語そのものも探索できます。ドキュメントも仕様書もない既存システムは、まず偵察セッションで全体を把握し、発見を記録・共有しながら正体を突き止めていきます。「恐怖の再現不可能なバグ」を、エビデンス収集と変数のブレインストーミングと状態モデルで追い詰める方法も、この部にあります。

私が特に推したいのは第12章「要件の探索」です。探索の対象はソフトウェアだけではありません。要件定義の会議で「What If?(もしも?)」を投げかけ、関係者どうしの思い込みのギャップを実装前に発見する。仕様書を鵜呑みにせず、疑問を投げかけ、モデルを描きながら読む「アクティブリーディング」。要件を定義する人にこそ読んでほしいと言った理由が、この章にあります。

最終章は、探索をチームの日常に統合する方法です。早く、頻繁に探索する。探索の工数を確保し、見積もり、いつ終えるかを判断し、ステークホルダーに報告する。専任の探検家を置くチームも、全員で探索するチームも、探索を「後付け」ではなく第一級の活動として扱う——それが本書の結論です。

付録と解説

付録は2本。探索的テストのスキルを見極める採用面接の方法と、現場でそのまま使える「テストヒューリスティック・チートシート」です。各章末には演習も付いています。

そして日本語版には、和田卓人さんによる解説「『Explore It!』: 才能から技術へ」を収録しました。「バグの臭いがするんだよ」としか説明してくれなかった伝説のテストエンジニアの思い出から始まり、才能だと思われがちな探索を再現可能な技術に還元する本書の価値を語っています。才能はスケールしませんが、技術はスケールします。

この本ができるまで

本書の翻訳は、スクラムフェス新潟の有志によるオンライン読書会から始まりました。機械翻訳の原稿を手掛かりに一章ずつ読み進めていたところ、翻訳権は取得済みなのに翻訳が止まっていると知り、それなら読書会の続きを出版まで持っていこう——と動き出したのがこの本です。実務者が実務者のために書いた本を、現場の実務者たちが自らの手で翻訳しました。『実践アジャイルテスト』のジャネット・グレゴリーは本書を「テスターだけでなく、開発チーム全員の机に置かれるべき本」と評しています。

原題の副題は「リスクを減らし、自信を高める」ですが、日本語版では「プロダクトの価値と自信を高める」としました。探索的テストは防御的な活動ではなく、プロダクトについてまだ誰も知らない情報を発見し、チームの意思決定を支える価値創造の活動だからです。

指示に書かれていない暗黙の期待は、AIがコードを書く時代にはますます伝わりません。今こそ、探索的テストを。

『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』 エリザベス・ヘンドリクソン著/スクラムフェス新潟訳/ZEN大学出版会(発売:KADOKAWA) https://www.kadokawa.co.jp/product/302607002898/

AIに聞いて身体の地図を作ってもらい、地名を学ぶ:五十肩リハビリの記録

ある日、右肩を上げると痛い、引っかかる、と感じるようになりました。動かなくなったというほどではないものの、可動域が明らかに下がっています。これは五十肩かもしれない、と思いました。

YouTubeで五十肩関連の動画をいろいろ見ました。理学療法士の方のビデオ、整形外科のお医者さんのビデオ、テレビ番組などです。例えば【5分!ガチガチの五十肩をゆるゆる】手が後ろに回らない五十肩の治し方【四十肩】 のような動画を眺めていました。

いろいろ見て分かったのは、「痛くない方法」というのは結局あまりなくて、お医者さんの場合は麻酔をして癒着を一気に剥がし、その後リハビリで動かしていく、というアプローチが基本らしいということでした。つまり五十肩の治し方は、結局のところ動かすしかない。多少痛くても、です。硬くなって動かさないのが一番まずいので、動かせるようにしてからまた動かしていく。楽な道はないんだ、と諦めがつきました。

そういう動画を眺めているうちに、肩の前面に「何とか突起」という出っ張った骨の構造があって、ここが痛みのポイントになることが多いらしい、というのが何となく頭に入りました。名前は覚えきれませんでしたが、場所は何となく分かる。そういう状態でした。

整体には通っていたのですが、間の日々を自分でどうケアしていけばいいか分かりません。そこで Claude に毎日身体の感覚を報告しながらセルフケアを進めてみました。結果、想像以上に回復が進んで、自分の身体の構造が「地図」として見えるようになりました。その記録をまとめておきたいと思います。

なお、以下に登場する私の発言は iPhone の音声入力で書いたものが多く、誤字脱字や変換ミスがそのまま残っています(「ボムんじゃなく」とか「肋間中隔」とか)。この記事では当時のやり取りの生々しさを残すためにあえて修正していません。Claude はこの程度の誤字なら気にせず文脈で読み取ってくれるので、AI に話しかける時は気を遣わなくて大丈夫だ、ということも伝えたくてそのまま残しています。

きっかけ:押さえたら痛くない、という発見

最初は手探りでした。痛い場所を探って、揉んでみたり、触ってみたり。そんな中で偶然見つけたのが、押さえたまま腕を動かすと痛くない、という感覚でした。

私「肩の前のとこですねなんとか突起のところだと思います...そこのところを脇の下からその場所に関してつかんで手を動かしたら、掴んでるとこは痛いんですけど手を動かすのは痛くないのが分かって、動かせることが分かった」

Claude「おっしゃっている肩の前側の痛い場所は、おそらく烏口突起だと思います。ここは上腕二頭筋の短頭や小胸筋が付着する場所で、五十肩で硬くなりやすいポイントとして知られています」

YouTubeで見た「何とか突起」の正体が「烏口突起」だと、この時に判明しました。曖昧な記憶を投げただけで、正確な名前が返ってきます。

身体の感覚と曖昧な記憶を言葉にして投げる、それだけでいいのです。解剖学を知らなくても、AI が翻訳してくれます。

名前が分かれば、YouTube でケアの方法を探すこともできます。

細い一本が痛い → 外側筋間中隔

ポイントを探っていくうちに、太い筋肉の間に細い筋が一本だけ痛いことに気づきました。

私「太い筋肉の間の奥に細い一本がとても痛いです」

Claude「上腕外側筋間中隔という筋膜の壁の可能性が高いです。上腕二頭筋側と三頭筋側を仕切っている硬い筋膜のラインで、まさに太い筋肉の間を縦に走る細い構造です」

「上腕外側筋間中隔」。聞いたこともない名前でしたが、調べてみるとまさにその通りの構造がありました。後で断面図を見つけて Claude に見せたら「身体の感覚で見つけたものが解剖学の図と完全に一致している」と言われました。

感覚を頼りに名前を当てるというのが自分にもできるのかと驚きました。

点が線になる:身体のラインが見えてくる

烏口突起、上腕二頭筋の奥、筋間中隔、と痛い場所を見つけていくうちに、Claude が「これは一本のラインで繋がっている」と教えてくれました。

私「手首の手の甲側にポイントが」

Claude「まさにラインが繋がっていますね。肩の前面→上腕外側筋間中隔→外側上顆→そして手首の手の甲側、これは前腕の伸筋群のラインそのものです」

点として認識していた痛みが、線として繋がります。さらに肩甲骨の外側→三頭筋→肘という後面のラインも見えてきて、最終的には鎖骨下の深層から手首まで、身体全体の地図ができました。

五十肩は肩だけの問題ではなく、肩を動かさないことで腕全体、さらにはマウス操作で前腕の伸筋群にも負荷が溜まっていました。前後・上下のラインが網の目のように繋がっていることが、自分の身体の感覚として理解できました。

やり方の核心:揉まない、押さえて動かす

ケアの方法も Claude が言語化してくれました。最初は揉むものだと思っていましたが、これは間違いでした。

私「ボムんじゃなく曲げ伸ばしね。なるほど」

Claude「揉むのではなく、押さえた状態で曲げ伸ばし。今日の会話で掴んだ一番大事な感覚ですね」

筋膜は強い圧で揉むより、押さえて固定した状態で関節を動かして滑走性を出す方が効きます。この「押さえて動かす」を体得したことで、すべてのポイントに同じやり方で対処できるようになりました。

整体の先生が施術しているときも、押しながら腕を動かしてもらっていることに気づきました。プロがやっていることを、自分の身体で再現できるようになったのです。

強度の判断:好転反応とやりすぎ

セルフケアを進めるうちに、調子に乗ってやりすぎた日がありました。

私「一夜明けました。棘下筋からの刺激が効きすぎて右肩全体が好転反応でだるいです。今日は仕事にならないかも」

Claude「やりすぎましたね。棘下筋は肩の動きの要なので、ここに強い刺激を入れると周辺の筋肉全体が反応してだるさが出ることがあります。

今日は触らずに完全に休める日にしてください。身体が刺激を受けて組織を再構築している最中なので、追加の刺激は逆効果です。温めるのはOKなので、お風呂でゆっくりする程度に留めて、ストレッチもボールも今日はお休みです。

だるさは1〜2日で引くことが多いですが、これは次回以降の刺激量の目安になります。棘下筋のボールリリースは効くけど、もう少し短時間・軽い圧にする必要があったということです。

整体まであと数日あるので、明日回復していたら軽めに再開、まだだるければもう1日休む。焦らなくて大丈夫です」

「効きすぎる」というのもあるんだ、と知りました。回復のために組織が修復反応を起こしているので、追加の刺激は逆効果になります。プロテインと水分を摂って完全に休みました。

この経験のおかげで、その後は刺激量を調整できるようになりました。痛みの種類(鋭い痛みか鈍い痛みか、触ると痛いか動かすと痛いか)で炎症か癒着か好転反応かを判断する基準も、会話の中で身についていきました。

整体との連携:プロにポイントを伝える

整体に行く時に、自分で見つけたポイントを具体名で伝えられるようになったのは大きかったです。

「上腕外側筋間中隔が痛い」「烏口腕筋が最後に残っている」「肩甲骨外側の付着部が硬い」と伝えると、整体の先生もピンポイントで施術してくれます。

整体は2週間に1回でも、間の日々を Claude と一緒にセルフケアで埋められます。プロの施術 → セルフケアで定着 → 次の施術でさらに進める、というサイクルが回りました。

決定的な瞬間:骨頭がハマる

整体を重ねて、セルフケアも続けて、ある日決定的な変化がありました。

私「直立したあと状態を前傾して腕を垂らすと肩が抜けるような痛みが少し。そこでコキッと骨がハマったような感覚があって痛みが消えました。その後ぶらぶらしても痛くないです」

Claude「それは上腕骨頭が関節窩の正しい位置にハマった感覚だと思います。長期間の拘縮で周囲の筋肉が不均等に引っ張っていたため、上腕骨の頭が微妙にずれた位置にあったのが、筋肉が緩んだことで前傾して腕を垂らしたときに重力で自然に正しい位置に戻った」

これがコッドマン体操の原理そのものだと教えてもらいました。重力で関節の隙間を広げて、骨頭が自然にあるべき位置に戻る。周囲の筋肉が緩んだからこそ起きた現象でした。

この日を境に、引っかかりがほぼなくなりました。

身体の地図と解剖学の答え合わせ

最後に、断面図を見つけて Claude に送ってみました。

私「断面図で見ると筋間中隔だと思います」

Claude「身体の感覚で見つけたものが解剖学の図と完全に一致している、素晴らしい答え合わせです」

太い筋肉の間の奥にある細い一本、と感覚で表現していたものが、図の中にしっかり描かれていました。「外側筋間中隔は上腕骨外側上顆の痛みに影響」と図にも注記があって、テニス肘との関連も裏付けられました。

身体の感覚と解剖学が繋がります。自分の身体が、地図として見えるようになりました。

まとめ:AIとセルフケアの新しい形

ポイントをまとめます。

  • 解剖学の知識は不要。感覚を言葉にして AI に投げるだけでいい
  • 名前が分かると関連する構造が芋づる式に見えてくる
  • セルフケアの方法と強度の目安も会話で得られる
  • 痛みの種類を判断する基準が身につく
  • 整体に行く時に具体名で伝えられて、施術の精度が上がる
  • 毎日の進捗を AI と共有することで、回復のサイクルを継続できる

整体は2週間に1回。けれど Claude とは毎日話せます。プロとAIとセルフケアの三位一体で、回復が加速しました。

もちろん Claude は医師ではありません。深刻な症状がある時は整形外科で診てもらうべきですし、自己判断で済ませず、専門家と併用する前提でこそ機能するアプローチだと思います。それでも、毎日の身体の変化を言葉にして対話することで、自分の身体への理解が深まり、回復の主体になれます。これは大きな価値がありました。

右肩は今、ほとんど引っかかりなく回るようになりました。最初は痛くて動かなかった肩が、ほとんど気にならないレベルまで戻ってきて、痛みが出ても軽くその日にケアができます。地図を教えてもらい、地名を知り、自分で調べて学び、対応方法について相談することも、近くして理解することも、以前より容易になりました。

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

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

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

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


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

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