When you think of Scrum, you probably imagine its use in software development. I often hear these voices in many Japanese communities. However, my image is a little different.

あなたのScrumといえば、ソフトウェア開発での活用をイメージするでしょう。多くの日本のコミュニティで、こうした声をよく聞きます。しかし、私のイメージは、少し異なります。

This time, key staff members, especially Matsuura-san who made an enthusiastic love call to me, asked me to talk about examples and methods of utilization outside of software development.

今回は主要なスタッフ、特に熱烈なラブコールされた松浦さんから「ソフトウェア開発以外での活用事例、活用方法を話して欲しい」との要望を受けました。

In response to these requests, this session may change the image of Scrum a little, from examples of its use in projects other than software development and how it is used.

こうした要望を受け、本セッションでは、ソフトウェア開発以外のプロジェクトでの活用事例、活用方法から、少し Scrum のイメージが変わるかもしれません。

アジャイル開発の解説はたくさんあるので、逆に、アジャイル開発になれない方法をざっくり紹介します。
成功する方法を見つけるのは難しいけど、失敗する方法を知るのは簡単だったり。

ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

開催年月 開催地 チャンピオン
2022年6月 大阪 yattom
2022年5月 新潟 yattom
2022年1月 お茶の水 yattom

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
その他のドライバーにはこれから声をかけます。
出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します！

今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました！！！

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
https://forms.gle/oFih3o1mk6P8gTGK8

心理的安全性という言葉、皆様は聞いたことありますか？

心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う？」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ！」という声が帰ってくると思います。

しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか？心理的安全性という言葉がキャッチー（かつ、流行っている）こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

毎日ふりかえりをして、毎週ふりかえりをして、自分たちのこと、チームのこと、プロダクトのことに向き合い続ける。

毎回１つとて同じふりかえりはなく、その場に合わせて新しいふりかえりが自然発生し、チームによって生み出されていく。

そういったふりかえりを全力で行い、プロダクトを全身全霊で作るうちに、ふりかえりが日常に溶けていく。

そんなチームが出来上がるまでの2年間をふりかえると、ふりかえりだけでない、いろんな要素が絡み合っていました。

• ふりかえりを楽しむということ。
• チームの文化を作り続けるということ。
• ひとりひとりのオーナーシップ。
• メンバーそれぞれの価値観の共有。
• みんなが大切にしている想い。
• ゴールをともに作り上げ共有すること。

このセッションでは、ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素をお伝えします。

マネする必要は全くありませんが、少しでもふりかえりを身近に感じられたり、ふりかえりの周辺にある何かを感じ取っていただけたら嬉しいです。

チームが一致団結して開発する日々の様子を、メンバーの立場から体験できるボードゲームを作りました(作っています)。以下のような和やかなやり取りをしながら進めるゲームです(予定です)。

「ちょっとこのタスク誰がやるのよ」
「いまリファクタリングしとかないとヤバ…」
「依頼してよかったですよ、ありがとうございます。次のも楽勝ですよね？」
「品質に問題があります」
「これできる人いたっけ？」
「グロース！！」
「おれiOSしかやりたくないなあ」
「楽しく仕事しましょうね、楽しくね」

4人1グループで、90分～2時間くらいかけて遊ぶゲームになりそうです。仙台では、オンサイトで会場に集まってボードゲームを遊ぶ予定です。

各プレイヤーは、開発チームのメンバーとして、自分のスキルを表す手札を持っています。ボード上にはタスクカードが並んでおり、自分のスキルでこなせるタスクを選び案件として実施すると、開発が進みます。開発を進めるとチームは3種類の報酬を得ます。

• Growth - プロダクトや会社の成長と売上増
• Impact - ユーザーや社会に対する貢献
• Productivity - プロセス改善やリファクタリングによる作業効率化

メンバーは一人ひとり異なった「勝利条件」を持っています。あるメンバーはひたすら成長にコミットしており、別のメンバーは自分のスキルにしか興味がなく、また別のメンバーはプロダクトがバランスよく成長しながら社会に貢献することをモチベーションにしている。自分の勝利条件に近づくようにタスクを選んで案件を実施ししましょう。

しかし1人でできる仕事は僅かです。スポンサーの要求はどんどん高まっていき、チームが協力して開発しなくてはクビになってしまいます。チームとして案件を成功させながら、いかにして個々人の勝利条件を追求するのか。チームとしてのコミュニケーション、作戦、そして駆け引きがこのゲームの醍醐味です(予定)。

ゲームの準備の都合で、参加者は最大12名の予定です。見学だけの参加も可能です。

エンジニアとしてアジャイルなものづくりをし続けるためには、それを実現するだけのスキルが必要です。

そのスキルのひとつは"技術スキル"であり、私自身の弱さとなっている部分であり、向き合わなければいけないものでした。

あなたはどんな理由で、アジャイルを探求したり、スクラムを実践したり、コミュニティで学びを深めたりしていますか？

アジャイルの考え方が好きだったり、自分たちの開発に悩みを抱えていたり、より良い価値をユーザに届けたかったり、その理由は人それぞれだと思います。

私がアジャイルに興味を持ったのは、本質を突き詰めていくような考え方に深く共感し、自分たちもそんな風にものづくりをしたい、と思ったのがきっかけです。

思想を持ちながら、書籍、コミュニティ、カンファレンスでその理解を深めていくことで、本質的に価値を届けていくことはできる、と思いながら新天地へ足を踏み入れた私は、しかし思うように動けませんでした。

一方そこには、アジャイルのことはよく知らない、と言いながら自分なんかよりもよっぽどアジャイルな人たちがいました。

実践する前にアジャイルの思想を知り、頭の中で理想の世界が膨らみ続けていた私が、いざ実践となった時に突きつけられた「自分の弱み」の話をします。

いろんな痛みを伴ったので正直言語化するのもちょっと辛いですが、アジャイルであり続けるために頑張ります！！

「アジャイルチームで品質を作りこむ」
色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」（独自イベント）を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

### リファインメント

言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

• PBIのゴール
• 設計方針
• テストの方針＋影響範囲

POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

### 受け入れ

私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

お気づきでしょうか？
DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
良く見ると「実装」がスリーアミーゴスでサンドされています。
自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

• スリーアミーゴス
• 実装
• スリーアミーゴス

このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

• 作ってみたら変なモノができていた（修正）
• テストが足りていない（追加）
• お互いに期待値に達していなくてイライラする

スリーアミーゴスサンドぜひお試しを！

東京理科大発(理科大VC出資)ベンチャーShinonome(https://shinonome.io/)を学生創業してから、はや６年。

現在では、全国の大学と提携をして大学生にIT実践教育の仕組みを提供できるようになり、500名以上のエンジニア・デザイナーを教育・輩出しています。

しかし、創業期は...

「金がないので、寸胴で炊き出し？！」「20時間/312日、開発体制！？」

ソフトウェアとの出会いから、学生起業、今に至るまで赤裸々なストーリーをお話しします。 

J. Richard Hackman著の書籍Leading Teamsによると「安定したチームほど良いパフォーマンスを発揮する」とあります。

まったく異論はありません。

ただ、嬉しくもあり、残念でもあるのですが、チームでの活動がうまくいった結果、プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。

そうすると、いつまでも安定したチームで居続けられなくなるのもまた事実です。

安定したチームがよいパフォーマンスを発揮するとはわかっていても、なかなか許してもらえない。

そんな状況を受け身になげくのではなく、それを受け入れ、不確実な状況に適応するために、積極的にチームや組織をダイナミックにリチーミングすることはできないでしょうか？

 Heidi Helfand 著の書籍Dynamic Reteamingより、チームをダイナミックにリチーミングするための５つの方法を、実際に現場でチームと関わるなかででてきた事例とともにご紹介します。

もうリチーミングは、怖くない！

• 今日は本を読むぞと決めたけど、結局ゲームをやってしまった

• 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

• 貯金をしたいのに、欲しいものがあると思わず買ってしまう

このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか？私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

みなさん、こんにちは！

アジャイルコーチの清水弘毅です！
日本在住だとおそらく３人ほどしかいない、CTC認定をスクラムアライアンスから受けています！

本セッションでは、スクラムマスターやアジャイルコーチの方の、必要なスキルの探求をしていきます。

私自身がどんな場面に遭遇し、どのように考え、どのような道を辿ってきたかお伝えしますので、スクラムマスターを極めたいと考えている方たちの一助になれば幸いです。

CSM, A-CSM, CSP-SM, CTC, CECで求められるコンピテンシーに照らし合わせながらお話する予定です。

スクラムマスターを極めたい方は集まってください！

当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ（コーラス：haradakiro）でお送りします。
いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

前回のプロダクトバックログ（https://slide.meguro.ryuzee.com/slides/107）に引き続き、今回はスプリントプランニングのすべてを完全解説!!

スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

• (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
• (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
• (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
• (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
• (e) スプリントプランニングの前に、先にタスクに分解しておく

もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば（SCRUM BOOT CAMP THE BOOKも是非読んでみてください）、陥りがちな罠は避けられます。

本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

なお、望ましくないものは、(c)以外のすべてです。

私は筑波大学の情報系の学生です。３年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。

３年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。

そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。

スクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。

そういった方々に向けて、誰しも親しみのある「料理」を題材に、完成の定義（Definition of Done）の理解を助けるワークショップを作りました。

スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう！

※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。→ 直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

過去の放送

https://youtu.be/5BZI9A3jhsY

https://youtu.be/0JDjMDSLqrE

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

概要

私たちは、これまで外側の世界に対してなにか働きかけをしなければいけない、と考えて改善を行ってきました。

しかし、本当に私たちが向かうべきは外側ではなく内側だったのです！！

本講演は、NVC（非暴力コミュニケーション）、ザ・メンタルモデルの知見から、主にスクラムマスターの内側の世界（感情、ニーズ、痛み）に目を向けます。

生命的な進化を遂げる組織の人間関係において必要とされるのは、表面的なコミュニケーションテクニックではなく、他者に対する理解や共感です。そして、更に重要となるのが、コミュニケーションを行う自分自身に対する理解や共感、つまり自己理解 です。

これまでアジャイルに20年間向き合ってきて到達したいきいきとしたチームの結論が、自己理解に基づく個人の変容です。

チェンジ・エージェントたるスクラムマスター自身が、自分自身に対しての共感・理解をすることが、チームの生命構造を生み出す最短距離ではないかという仮説をご紹介した後、自己共感・自己理解についての概要、なぜチームの生命構造を生み出すのに自己理解が必要なのかの説明した後、実際に自己理解を体験するためのワークを行います。

本講演の最後に、引き続き自己理解・自己共感を行っていく上でのポイントをお伝えします。

すべてがフィードバック、なんでもフィードバック - Feedback is Life

フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない！と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

• すべてがフィードバック、なんでもフィードバック。
• テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
• フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
• フィードバックでは自分自身を大事にすることが大切です。
• フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
• 「フィードバックください！」とよく言ったり言われたりしますが、実は……

みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

ぜひ、楽しい時間を皆さんと分かち合いましょう！

自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。

1年半前、自分はみんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みます。

自分が変革をはじめる最初の一人でした。
初学者でしたが書籍から学び、知識は万全。きっとなんとかすると前のめりでした。

ところが、憧れた会社や書籍のようにうまくいきませんでした。
そこにはシンデレラストーリーがあるのではなく、ただただ現実的な問題ばかりがありました。
その問題の乗り越え方は書籍には載っていません。
自分で悩み考え、取り組んでみて学習する必要があります。
形式知ばかりを学び、「最初の一歩」を実践したことのなかった自分は見事に頭でっかちになっていました。
頭ごなしに知識を押し付けたところで、とうとう組織の支援を受けることはできませんでした。

初学者が組織の変革をはじめる最初の一人になる場合、経験したことがないため乗り越えられないような問題が出てくることがあります。
そう考えると、むしろ最初は組織から協力を引き出せないほうが、自然なのではないでしょうか。
では、初学者が組織の変革をはじめるべきではないのでしょうか？自分はそんなことはないと思います。

最初の一人が躓いたとき、その後の歩みを止めないためにできることは何でしょうか。

このセッションでは、組織を変革する最初の一歩の道のりをふりかえり、自分が学んできたことをご紹介します。
なにぶん昔のことなので、思い出せないところもありますが、書籍には載っていないような自分の実践から学んだお話をご提供できれば幸いです。