自分で言うのもなんやけど、改めて物理本読んでみるとガチ業務で使う時の重要ポイント整理されてるし、読んでておもろいわ。まじ山本さん優秀すぎる、未だ一位なのもありがたいなぁ。

学生チームさんからの挑戦状「私たちにスクラムを叩き込んでください」に応えるために集まった達人の皆さま。学生さんとの対戦を前に作戦会議。その後の対戦は大変有意義なものになりました。 ちゃんと伏線回収できてよかったー。　 #scrumkanazawa#

“福田：確かに「我々独自のアジャイル開発を定義しました」といった枠組みを作れば、特に経営層などからは安心され、喜ばれるのは分かります。 ですが、アジャイルなアプローチの本質はそこにはありません。大切なのは「何のためにこうするのか」という価値観や原則を共有して進めていくことです。”

たぶん前回の来日はカンファレンス会場が地元江東区の文化ホールで、うちの子が保育園のお遊戯会で立った舞台にマーチン・ファウラーが立っててむちゃくちゃ感激した記憶があります。今回も楽しんで行っていただきたいです。

いよいよ明日スクラムフェス金沢2026が開幕します。 参加者のみなさん、Discordへの参加はお済みですか？ まだの方はDiscordの参加方法をチケット入手時の確認メールに記載していますので確認をお願いします。 明日みなさんに会えることを楽しみにしています。 #scrumkanazawa#

ノートパソコンと会議室の暗いプロジェクターでは、パワポとExcelぐらいでしか読めなくて、意思決定は３案から選ぶだけ、ってなりがちだったりしないかな。効率的な意思決定だと思っている内実は、偉い人をつまみやすい料理で接待してノブレスオブリージュ(予算配賦)を勝ち取ることだったりとか (空想

大きな変化の時期なので、確立されたメソッドなんてものはなくて、でも部分的に使える考え方がたくさんある。いま他の人たちがどう捉え、どう取り組んでいるかは参考になりやすいんじゃないかと思います。ツールよりも、人と組織の適応が課題になると思いますので、スクラムフェス、いいと思います。

RoomA、続いてのセッションは YesNoBut株式会社　川口 恭伸さん（@kawaguti）のご登壇です🙌 「AIエージェントが教えてくれたプロダクトオーナーシップの本質」をお話しいただきます！QAタイムもございます～！ ▼発表資料はこちら✨ #役割の変化con_findy#

スタックの誤謬、いい記事だったので全文訳します！ —— なぜ大企業は失敗し続けるのか：スタックの誤謬 Stack Fallacy（スタックの誤謬）は、非常に多くの企業が新しい市場を獲得しようと試みては派手に失敗する原因となってきた。データベース企業がアプリは簡単だと考えたり、VM企業がビッグデータは簡単だと考えたりするのを目にしたとき——彼らはスタックの誤謬に陥っているのだ。 スタックの誤謬とは、自分の層の一つ上の層を作るのは些細なことだという誤った思い込みである。 数学者はしばしば、自然界全体を数学的な言葉で記述できると信じている。ゆえに、物理学はすべて応用数学にすぎない。そしてそれが延々と続いていく。 スタックの誤謬——「ただのアプリでしょ」 ビジネスの世界にも、同様の幻想が存在する。データベース企業は、SaaSアプリは「ただのデータベースアプリ」だと信じている——これが、この新市場で簡単に作って、競争して、勝てるという誤った自信を彼らに与える。歴史が示してきたように、AmazonはクラウドのIaaS市場を支配し続けている。一方で、その素材となる下層の技術を作る技術ベンダーたちは競争に苦戦している。VMwareはAWSに勝つには程遠い。AWSのすべてが、VMwareの中核的な強みである仮想マシン技術の上で動いているにもかかわらず、だ。OracleはCRM SaaSでSalesforceに勝てずにいる。OracleはSalesforceを単なるホスト型のデータベースアプリだと見なしているにもかかわらず、である。それどころか、Salesforceは彼らのデータベース上で動いているのだ！ Appleはスタックを垂直に下へと統合することには成功し続けている——チップやプログラミング言語などを作っている——が、ここでもまたスタックを上へ登って、ああいった単純なアプリ、たとえば写真共有アプリや地図のようなものを作るのは非常に難しいとわかった。 歴史はこうした例で満ちている。IBMは、自社のPCというハードウェア層を動かすソフトウェア層を大したものではないと考え、MicrosoftにあっさりとOS市場を握らせてしまった。 90年代、ラリー・エリソンはSAPがプロセス自動化ソフトウェア（ERP）を売って途方もない額の金を稼ぐのを目にした——彼にとって、ERPは一連のテーブルとワークフローにすぎなかった——そこで彼は何億ドルも費やしてその市場を獲りにいったが、結果はまちまちだった。最終的にOracleはPeoplesoftとSiebelを買収することで、アプリ市場に金で参入した。 なぜ我々は繰り返しスタックの誤謬に引っかかるのか？ スタックの誤謬は人間の本性の産物だ——我々は自分が知っているものを（過剰に）高く評価する。具体的に言えば、あなたが大手データベース企業で働いていると想像してほしい——そしてCEOがこう尋ねる——うちはIntelやSAPと競争できるか、と。リレーショナルデータベースのソフトウェアを作れるからといってコンピュータチップを作れると想像する人はほとんどいないだろう。だが、一つ上の層の構成要素に馴染みがあるために、ERPアプリなら作れると信じてしまいやすい。なにしろ、テーブルとワークフローなら知っているのだから。 成功のボトルネックは、しばしばツールに関する知識ではなく、顧客のニーズに対する理解の欠如である。 データベースエンジニアは、サプライチェーンソフトウェアの顧客が何を望み、何を必要としているかをほとんど何も知らない。そのために人を雇うことはできるが、それは中核的な強みではない。 意外なことに、スタックを上へ向かって革新するよりも、下へ向かって革新するほうがはるかに簡単なのだ。 その理由は、自分自身が下層の自然な顧客だからである。Appleは、理想的な未来のマイクロプロセッサに自分が何を求めているかを知っていた。それを作るのに必要なスキルは持っていなかったが、顧客としてのニーズはよく理解されていた。技術的なスキルは買ったり獲得したりできるが、市場ニーズの深い理解をただ買ってくることは非常に難しい。 したがって、Appleが半導体チップを作るほうが、Apple Mapsを作るよりも楽だったのは何の驚きでもない。 Google、Facebook、WhatsApp Googleはここでの絶好の例だ。Googleは我々のメールのグラフを握り、我々の興味関心のデータ（検索）を握っていた。それでもなお、「作るのは些細なこと」に見えるアプリ——ソーシャルネットワーク——で成功するのは非常に難しいとわかった。 実際のところ、これこそがスタックの誤謬の完璧な皮肉である。スタックの上のほうにあるものは作れる。ただ、何を作るべきかが明確でないことが多いのだ。 プロダクトマネジメントとは、何を作るべきかを知る技術である。 スタックの誤謬は、企業がなぜ明白なこと——あまりに手の届くところにあって、確実に作れそうなこと——で失敗し続けるのかについての洞察を与えてくれる。その答えはこうかもしれない。「何を」は「どうやって」よりも100倍重要なのだ、と。

12時からの出番になります。 「AIエージェントが教えてくれたプロダクトオーナーシップの本質」というタイトルでお話しさせていただきます。全員が変化の波に飛び込まざるを得ない時代ですので、同じ波をかぶっている人間として気づいたことをお話しできればと思います。