📊

慢心、崩壊、そして作り直し〜登壇4回目の失敗談〜

に公開

「これはちょっと...」

Slackの通知音が鳴った。

レビューをお願いしていた登壇資料へのフィードバックだ。画面を開いた瞬間、胃のあたりがキュッと締まるのを感じた。

「思想が強すぎて、裏付けとなる体験やエビデンスがない」

「話が飛び飛びで繋がりが薄い」

「言いたいことを詰め込みすぎている」

自信作だったはずの資料が、目の前で崩れていく。

4回目の登壇だった。「もう自分でやれる」と思っていた。1〜3回目はうまくいっていたから。でも、それが慢心だった。

すべては、登壇への憧れから始まった

話は少し遡る。

2025年、私はスクラムフェスやRSGTなどのアジャイルコミュニティに参加する中で、ある思いが芽生えていた。

「参加者としてだけでなく、登壇者としても関わりたい」

理由はいくつかあった。

  • コミュニティをもっと楽しむために、参加者から一歩踏み出したかった
  • 自分の学びや経験を体系的にまとめ言語化することで、自分の成長にも繋がると思った
  • 今後のキャリアのために、こういった実績を積んでおきたかった

これまであまり登壇経験がなかった自分にとっては、こういった大きめのカンファレンスで公募スタイルの登壇をするというのは、大きな挑戦だった。

そして実際に、4回もの登壇の機会を得ることができた。

順調だった1〜3回目

最初の3回は、順調だった。

1回目:JaSST Tokyo(2025年3月)
チームで取り組んだ品質改善活動を振りかえった発表。大きめのオフラインカンファレンスでは初めての登壇だった。緊張したけど、確かな手応えがあった。

https://speakerdeck.com/wooootack/quality-improvement-team-reflection

2回目:Scrum Fest Kanazawa(2025年7月)
大規模アジャイルフレームワーク「FAST」の導入経験を共有。表面的な課題と本質的な課題の区別について語った。いろんな人からフィードバックを貰えたし、資料も良いものが作れて少しだけ自信がついた。

https://speakerdeck.com/wooootack/fast-taught-me-large-scale-agile-hardships-and-fun

3回目:Loglass TECH TALK vol.6(2025年7月)
社内向けのイベントで、FAST導入1年間のアンケート結果を分析した。1/3くらいは、金沢での資料を持ってきたこともあり、そこまで大変ではなかった。少しずつ、登壇というものに慣れを感じ始めていた。

https://speakerdeck.com/wooootack/review-of-the-first-year-of-fast-implementation

そして迎えた4回目。Scrum Fest Sendai(2025年8月)

https://speakerdeck.com/wooootack/surviving-the-ai-era-lessons-in-a-decentralized-autonomous-organization-with-fast

ここで、私は大きな過ちを犯すことになる。

慢心という名の落とし穴

4回目の登壇。私には、以前書いた記事があった。

https://zenn.dev/loglass/articles/fast-with-ai-future-organization

「FAST×AIで考える、未来の組織像」という記事だ。AI時代における組織の変化、システムの変化、求められること、そしてFASTがどう貢献できるか——壮大なテーマを語った自信作だった。

「これを登壇資料にすれば面白いんじゃないか」

そう思った瞬間、私の中で何かが緩んだ。

「もう4回目だし、自分でやれるだろう」

そして、勘違いをした。これがすべての始まりだった。

いつもは社内の経験豊富なメンバーにサポートしてもらっていた「ストーリーから作る」というプロセスを、私は飛ばした。記事があるんだから、それをスライドにすればいい。そう考えた。

元々の記事では以下のような内容について自分の見解を書いていた。

  1. AIの進化に伴い組織はどう変化するのか
  2. システムはどう変化するのか
  3. 我々は何を求められるのか
  4. FASTはAI時代のスタンダードとなり得るか

そして記事の内容をそのままに、言いたいことを全部詰め込んだスライドが完成した。

「今回はだいぶ今までよりも短時間で作れたし、まあいい感じなんじゃないかな」

そう思いながら、社内外の登壇経験豊富な人たちにレビューをお願いした。

そして——冒頭のシーンへと戻る。

「結局何が言いたいの?」

Slackの通知が鳴るたびに、心臓が跳ねた。

返ってくるフィードバックは、どれも厳しい言葉だった。

「思想が強すぎる」

「〜と考えています」「〜だと思います」が多すぎる。AI時代の予測や組織の変化について、実体験や具体的なデータが弱い。仮説ベースで未来を語ろうとしすぎている。

「話が飛び飛び」

組織の変化→システムの変化→求められること→FAST、という流れが唐突。各セクションの関連性が見えにくい。聞き手が置いてけぼりになる。

「詰め込みすぎ」

テーマが壮大すぎる。メッセージが絞られていない。「結局何が言いたいの?」が不明瞭。

複数の人から、同じ指摘を受けた。

作成したスライドを見つめながら、私は途方に暮れていた。登壇日まで、あまり時間がない。

それでも、作り直す

正直、最初は受け入れられなかった。

「そんなに悪いか?」「伝えたいことは間違ってないはずなのに」——フィードバックを読みながら、言い訳が頭をよぎった。

でも、複数の人から同じ指摘を受けている事実は重い。しかも、レビューしてくれた人たちは、忙しい中で時間を割いてくれた人たちだ。

一晩寝て、改めてスライドを見返した。

すると、不思議なことに、指摘された問題点が自分でも見えてきた。確かに、話が飛んでいる。確かに、「で、結局何が言いたいの?」が分からない。

認めるのは悔しかったが、彼らの言う通りだった。

落ち込んでいる暇はなかった。登壇日まで、あまり時間がない。

私は資料を根本から作り直すことを決めた。

これまでのやり方を思い出し、大上段に当たる部分を改めて考え直した。本来、最初にやるべきだったことだ。

  • 何を伝えたいのか?
  • 何を理解してもらいたいのか?
  • 誰に向けて話すのか?

これらを考え直した結果、壮大な「AI時代の未来予測」ではなく、自分の1年間の実践経験を軸に据え直した。

そこからは時間との戦いだった。

日中は仕事をしながら、夜はひたすらスライドと向き合う日々。気づけば深夜1時、2時。それでも終わらない。最終的には、登壇当日の朝までPCに向かっていた。

なんとか形にはなった。でも、この経験はとても苦い思い出として残っている。

なぜ、最初の3回はスムーズにスライドを作れたのか

ここで疑問が湧くかもしれない。「なぜ最初の3回はスムーズにスライドを作れたのか?」

ここまで書いたように、答えは明確だ。正しい手順で資料を作っていたからだ

成功パターン:ストーリーから作る

うまくいった3回の登壇では、以下の手順を守っていた。

1. 最初に「目的やターゲット」を詰める

スライドを作り始める前に、まずこれらを考える。
この段階では、まだスライドは一切作らない。メッセージを明確にすることだけに集中する。

今回のスライドは、最終的には以下のように整理した。

2. FigJam/Miroで付箋を使ってストーリーを作る

目的とメッセージが固まったら、次はストーリー作り。

付箋で「概要→話の流れ→要点」を整理しながら、どういう順序で、何を伝えれば聴衆が理解しやすいかを考える。
特に意識したいのは、それぞれのセクションの接続詞だ。全体を通して、違和感がなく話が続いているかを意識しながら作り込む必要がある。

この段階でストーリーの骨格ができあがる。

今回のスライドの一部を抜粋して紹介する。青色の付箋がキーメッセージで、その間の点線が話の繋がり、下に伸びていくツリーが根拠や事例となる。まだこの段階でもスライドは一切作らない。

3. 具体化していく

ここまで進めると、自分の伝えたいこととだけでなく、そのために必要なストーリーが見えてくる。

そして、ようやくスライドの具体化に入る。ストーリーにとって重要でない部分をひたすら削り、重要な部分に補足を入れてより詳しく解説していくようにスライドを調整する。

最終的に、FigJam上に貼った付箋のうち、実際に使ったのは半分程度だった。それでも、伝えたいことはシャープになり、聴衆の納得度も向上したはずだ。

4回目との決定的な違い

Scrum Fest Sendaiでは、このストーリー作りを飛ばしてしまった。

「記事の内容をそのままスライドにすればいいや」

そう考えて、最も重要なフェーズを省略した。その結果、何を伝えたいのかも分からないし、ストーリーも繋がっていない、ただ思想を語るだけのスライドが完成した。

これではただの自己満足だ。 すべて、自分の慢心が引き起こした失敗だ。 さらに、見落としていたことがあった。

最初の3回の登壇は、すべて体験ベースの話だった。

  • JaSST Tokyo:チームで取り組んだ品質改善の実践
  • Scrum Fest Kanazawa:FAST導入で直面した課題の実体験
  • Loglass TECH TALK vol.6:1年間のアンケート結果という具体的なデータ

一方、4回目は仮説ベースで未来を語るという、難易度の高いテーマだった。

体験ベースの話なら、自分の経験という明確なストーリーがある。あとは、そこから何を伝えるかを選択すれば良い。

でも、仮説ベースの話では、より丁寧にストーリーを構築しないと、ただの「思想語り」になってしまう。

この失敗から学んだこと

この経験から、いくつかの重要な学びを得た。

1. 記事を書くことと、スライドを作って登壇することが全く違う

記事に書くだけなら、自分の考えを整理するために、自分のためにという比重を高くしても構わない。その記事を読者自身が読むかどうかを選べるし、仮におもしろくなければ、冒頭で離脱すればいい。

しかし、登壇するとなったら話は違ってくる。話を聞いてくれる人々の貴重な時間を奪ってしまう。記事は読者が自分のペースで読み返せる。でも、プレゼンテーションは一度きり。聴衆を置いてけぼりにしたら、もう取り返しがつかない。

自分のためではなく、聴衆のためにという考え方をより強く持つ必要がある。

2. 体験ベースと仮説ベースは難易度が違う

体験ベースの話は、比較的作りやすい。

  • 何が起きたか
  • どう対処したか
  • 何を学んだか

この流れは自然で、聴衆も理解しやすい。

一方、仮説ベースで未来を語る話は、難易度が格段に上がる。

  • なぜその仮説を立てたのか
  • どんなエビデンスがあるのか
  • 聴衆にとってどう関係するのか

これらを丁寧に説明しないと、ただの「思想語り」になってしまう。

初心者のうちは、まず体験ベースの話から始めるのが賢明だ。

3. 相談するタイミングを見誤らない

「4回目だから自分でやれる」という慢心が、相談のタイミングを遅らせた。

しかし、経験豊富な人からのフィードバックは、何物にも代えがたい価値がある。特に、新しいタイプの登壇に挑戦するときは、早めに相談すべきだった。

一人で頑張りすぎた結果、最終的により多くの人に迷惑をかけることになった。慣れというのは怖い。

4. 言いたいことを詰め込むのではなく、メッセージを絞る

「あれも伝えたい、これも伝えたい」と欲張ると、結局何も伝わらない。 今回の資料は、まさにその典型例だった。

一つの登壇で伝えられることは、驚くほど少ない。

むしろ、メッセージを一つに絞り、それを様々な角度から繰り返し伝える方が、聴衆の心に残る。

おわりに

ここまで読んでくれたあなたに、一つ告白がある。

実は、この記事自体がある実験だった。

最近、『パーフェクト・ストーリー』(カレン・エバー著)という本を読んだ。脳科学に基づいたストーリーテリングの本だ。

https://pub.jmam.co.jp/book/b653573.html

この本では、効果的なストーリーには4つの要素が必要だと説いている。

  1. 共感できる登場人物 — 聴衆が親近感を覚え、感情移入できる人物
  2. 心を揺さぶる葛藤 — 問題や課題に直面し、それを乗り越えていく過程
  3. 五感を通じたつながり — 具体的な描写を通じて追体験できること
  4. 最終的に達成したい目標 — ストーリーを聞いてもらった後に求めている結果

そして、ストーリーの構造として以下の4つのパートに分かれていると説いている。

  1. 文脈 — 設定は?誰が関わっていて、人がそれに関心を抱く理由は?
  2. 葛藤 — 何かが起きたとき、そのポイントは?課題は?これがストーリーの燃料となる。
  3. 結果 — 結末は?
  4. 収穫 — 話を聴いたあとで聴衆にどんなアイデアを得てもらいたい?それがあなたの決めたペルソナに望む結果と、どうつながる?

具体的には、この記事ではこのような内容にしてみた。

  • 文脈:登壇への憧れ、順調だった1〜3回目、そして4回目への慢心
  • 葛藤:Slackの通知音、胃が締まる感覚、崩壊するレビュー、途方に暮れる自分
  • 結果:それでも作り直し、当日の朝までスライドと向き合った
  • 収穫:ストーリー作りを飛ばすな、体験ベースから始めろ、という学び

どこまで書籍で紹介されていた効果を皆さんが実感できたかは分からないが、少なくとも自分にとっては失敗談をただの反省文で終わらせずに済んだと思っている。

私と同じような初心者の方にとって、この記事が登壇資料やブログを作るときのヒントになれば幸いだ。興味があれば、紹介した書籍もぜひ読んでみてほしい。

GitHubで編集を提案
株式会社ログラス テックブログ

Discussion