【運営よりひとこと】
今年は新しい試みとして、去年まで開催していたOSTの代わりにチームで開発する様子を体感できるワークショップをオンサイト / オンラインのハイブリッド形式で開催してみようと思います。

参加したいと思った方は、11/4(金) 21:00までにこのスプレッドシートから申し込みお願いします！名前・オンライン / 現地・Discord IDを記入お願いします。

本ワークショップは全面的にやっとむさんのご厚意によって成り立っております、ありがとうございます！！

※「全員参加のOSTに代わる新しい試み」ということでより多くの方が参加できるように調整してまいりましたが、タイムテーブルやスタッフの都合上定員を設けることとなりました。ご了承ください。

ゲームの概要

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

「えっ、スキル足らなくないですか」
「ステークホルダーがぜんぶやれって言うから…」
「この案件、内容をこう見直して、ほらこれならできる！」
「やった、なんとかなりそうだね」
「おれ、これじゃなくてこっちやりたいんすけど」
「ちょっとー！」
「任せてください。実はこんなスキルを隠し持ってます」
「すごーい。あれ、でも品質良くなくない？」
「あっ…」

4人1グループで遊ぶゲームです。ルールが多いのではじめは大変ですが、わかると1回15～20分くらいで終わるので、3回くらい遊べると思います。札幌では、会場オンサイトとオンラインのハイブリッドでボードゲームを遊ぶ予定です。

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

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

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

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

ゲームの準備およびサポーター人数の都合で、参加人数に制限があります。会場オンサイトが20名まで、オンラインが16名まで参加できます。

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

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

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

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

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

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、やっとむ（yattom）、かっちゃん（katzchang）
今回もローカルレーサーに声かけするつもりです。

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

2022/10/12 追記
てやまぐ（teyamagu）選手は都合により出走取消となりました。
次節の出場をお楽しみに！

「あの人はなぜいつも元気に見えるんだろう？」
「あの人はどういう経験を経ていまのスタイルになったんだろうか」
「あの人の原動力はどこから来ているんだろう」
「あの人が凹むときはあるんだろうか」

と思ったことはありませんか？

プロダクト開発に携わっていると、日々さまざまな壁にぶちあたります。

考えの合わないチームメンバー、高圧的な上司、非協力的なステークホルダー、お通夜のようなふりかえり、フィードバックのないスプリントレビュー、重厚長大な組織の壁・・・

思わず「うっ」と歩みを止めたくなってしまうこともあるでしょう。

一方で、カンファレンスで登壇している人たちを見ていると、たとえどんな壁にぶつかったとしてもへこたれず、考え続け、行動し続けているように見えます。そして人は彼らを指して『元気だよね』と言います。

ここには、最強の元気しかいない

スピーカー2人の共通点は、人から『元気だよね』とよく言われることです。
ところが、本人たちは自分たちのことをとりわけ元気だと自覚しているわけではありません。

では元気とは何なのでしょうか？
ここでいう元気とは、性格や活動的である状態を指すものではなく、他者からの相対評価です。

同じような状況に面しても、人によってまったく違うアウトプット（行動、言葉）になります。このアウトプットを他者が見て、その人のことを元気だと感じているのです。

つまり、元気に見える人のメンタルモデルを解き明かすことで、元気とは何なのかの答えが見えてくるかもしれません。そして、メンタルモデルは理解することで自分にインストールすることができるかもしれません。

本セッションでは、スクラム界最強の元気たちが見ている世界を覗いてみる実験をします。最強の元気同士が、お互いにインタビューし合うことでお互いの思考、メンタルモデルを探ります。

一緒に元気を解き明かしましょう！

顧客を理解することが大切とはいっても、どのように考えればいいのかそれほどあきらかではありません。

これまで18年間、新規事業や新製品開発、リニューアルといったプロダクトの今後を左右する活動に関わってきました。2010年代からはソフトウェア開発でも、仮説検証やリーンキャンバスといった方法が認知され、プロダクトオーナーやプロダクトマネージャーにとって、顧客を理解するための様々な選択肢があります。

しかし、いったいどのようになったら顧客を十分に理解できたといえるでしょう。

また、顧客理解の新たな課題も登場してきています。チームによる顧客理解です。2010年代中旬頃までは、プロダクト開発においては一人の強力なリーダーシップによって進められることが少なくありませんでした。しかし、チームによってプロダクト開発を進める流れが起こりつつあります。顧客への深い理解はプロダクトオーナーだけの仕事ではなくなり、スクラムマスターや開発者にとっても重要な関心事になりつつあります。

知識や関心にバラツキのあるスクラムチームで、いったいどのようにすれば顧客の理解を深められるでしょうか。

このセッションでは以下の様々な切り口から顧客の理解を深める方法を紹介します。
・顧客の理解を度合いから評価する
・チーム全員で顧客を理解する

・顧客との接点はどれくらい持ちやすいだろうか
・顧客をどれくらい理解しているだろうか
・顧客の悩みを考えよう
・顧客の悩みが解決されない理由を考えよう

顧客の理解を育み、よりよいプロダクトを提供していきましょう!

スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ（超生産的）チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。

各パタンの概要はこちらの記事で紹介しました。
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)｜note

筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト（通称フロリア）」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。

プロジェクトの概要やチーム体制は下記の記事で解説しています。

• kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
• 30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ

本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。

• Teams会議で呼びかけても反応がない・・・！みんな聞いているのかな・・・？
• こんな調子でチームのパフォーマンスは良くなるのだろうか？
• 直接会ったことのないメンバー同士がどうしたらポジティブに動けるだろうか？

皆さんはリモートワーク下でのチームビルディング、どのように乗り越えましたか？
それぞれの個性が見えづらく、自分の想いも伝えづらい。私は相当苦戦しました。

申し遅れましたが、現在リクルート様の採用管理サービス「Airワーク 採用管理」の開発チームで
マネジメント業務をしております、イイダカです！
昨年度漠然とした課題感を抱えるフロントエンドチームに飛び込み、改善活動を行いました。

飛び込んだチームは、プロダクトの忙しさやメンバー交代などから、日々メンバーに対して答えを与えがちになり、
メンバーの主体性を育てることができず、チームのスキルアップに繋げられないという状態から抜け出せなくなっていました。

そんなチームをなんとか負の連鎖から抜け出し、自走できるチームにしていきたい。
皆さんだったらどのようにこのチームを変えていきますか？

トップダウンのやり方もあるでしょう。でも、私は全員に考えを吸収してほしいんです・・・！
全員にマインドを吸収してもらう選択をとり、同じ目線で協力し合える関係性を築きました。

私は自身の経験から、チームづくり・改善活動には、メンバーの納得・協力が絶対であると考えております。
正直に現状を共有し、どういった意図でどういうチームを目指していきたいかを説明し、共通認識を持ってもらうところから始めていきました。
そこからはまるで小姑のような泥臭行動の連続・・・

本編ではより詳しく、リーダー依存脱却・新たなチーム文化の醸成にどのように繋げていったか、
考えたこと・工夫ポイントを交えながら、新米の私だからこそできた泥臭奮闘記をお伝えします！

皆さんがどこか懐かしい気持ちになり、良い刺激を与えられたら幸いです。

アジャイル／スクラムを採用するチームが増えたことで、ふりかえり（スプリントレトロスペクティブ）を行なうことが当たり前になりつつあります。しかし、ふりかえりの実践にはツールだけではなく、参加するメンバーの心構えも重要な要素であり、参加者から前向きな意見を引き出すのに苦労している方も多いのではないでしょうか。

このセッションでは、このような課題をお持ちの方が、前に進む勇気やヒントをお持ち帰り頂ければと思っています。

ふりかえりマニアのふたりが、それぞれのふりかえりの原点（オリジン）と、ふりかえりの未来像（ライジング）を語ります。

僕らふたりも、最初からうまくふりかえりをできていたわけではありませんし、今でもいつもうまくふりかえりを行なえているわけではありません。多くの経験を通して様々な知見を得てきています。僕らの成功や失敗の経験談を伝えるとともに、ふりかえりの未来をみんなと一緒に考えてみたいと思います。

今年、私は新卒から慣れ親しんだスクラムチームを離れ、新天地でチャレンジし始めました。
フルリモート勤務という働き方や新チームで必要となる業界知識など、どんどん押し寄せる新たなものに立ち向かいつつ、新チームのことを観察していました。
その中には、職種に関わらず顧客価値につながる施策か議論する様子などアジャイルな精神が見えつつ、一方ではどうしてこうなってるのかと疑問に思うようなものもありました。

チームの人から相談を受け、一緒にカイゼンしようと活動する中で、前スクラムチームではどうだったか考える機会がたくさんありました。
考え続けるうちに、スクラムじゃなくてもできるけど、スクラムだともっと嬉しいことがあることに気がつきました。
今回は、そんな気づきについてお話ししたいと思います。

確約・集中・公開・尊敬・勇気、これら5つのスクラムの価値は何もアジャイル開発の現場に留まるわけではございません。スクラムの考えを実践することは、エンジニアであっても非エンジニアであっても、キャリアの形成や人生に大きく寄与する可能性を秘めております。

非エンジニアであり、人材育成・組織開発に関わる企業の経営者として、自身のキャリアを少しふりかえりながら、スクラムの価値基準がどのように人生に寄与したかをお伝えしたいと思います。

学びのポイントとして、「勇気を出して自身の目で一次情報として経験する（もちろんオンラインもOK）こと」です。どこかで誰かが話していたことを又聞きしたり評論したりするのではなく、現地・現物を大切にすることで、きっと見えてくる世界があると信じております。

そして経験したことは、せっかくなのでふりかえってみましょう。ポイントは一人でふりかえる内省だけでなく、仲間と一緒にふりかえってみることです。経験したことを仲間にオープンにすることで、きっと何かフィードバックを得られ、新たな気づきや学びに繋がるはずです！

本セッションでは、ふりかえって見たらスクラムの価値基準をもとにアレやコレやを個人や組織レベルで実践してきた経験を元に、皆さんのキャリアや人生がほんのちょっとでも豊かになるためのTipsをお伝えしたいと思います。

「エンジニア自身が品質を担保した状態でリリースできる開発組織」になる。

株式会社マネーフォワード HRソリューション本部プロダクト開発部では、上記の目標を掲げ、組織づくりに取り組んでいます。

マネーフォワード クラウド人事管理の開発チームに関わり出して早1.5年。

開発エンジニアのみなさんにどうやったら品質に関するスキルやマインドを共有できるのか、
また、アジャイル開発を進めていく上でテストがボトルネックにならないためにはどうすればよいのか試行錯誤してきました。

まだまだ道半ば。正解には全く辿り着けていませんが、この1.5年の軌跡とこれから見たい景色について、
具体的な事例をまじえつつお話できたらいいなと思っています。

「スクラムとはどういったものですか？」

そう聞かれたら、あなたはどう答えますか？

そのような質問があれば、おおよそ以下のようなスクラムのロールやイベントや成果物をベースに、スクラムの特徴を説明するのではないかと思います。

• 開発者、プロダクトオーナー、スクラムマスターというロールがあるんだよ
• スプリントという短い期間で開発を区切って、繰り返していくんだよ
• プランニング、デイリースクラム、スプリントレビュー、レトロスペクティブといったイベントがあるんだよ
• プロダクトバックログやスプリントバックログといった成果物があるんだよ

しかし、スクラムのフレームワークを長年利用していて親しみがある人でも、スクラムの"価値基準"をベースにスクラムを説明しようという人は少ないように見えます。

スクラムの"価値基準"とは、以下の5つです。

• 確約（Commitment）
• 集中（Focus）
• 公開（Openness）
• 尊敬（Respect）
• 勇気（Courage）

これら5つの価値基準はスクラムガイドでも明示されているのですが、それぞれの内容が何を意味しているのか・なぜスクラムの成功を左右するのかまでは踏み込んで説明されていません。

しかし、スクラムの"価値基準"はスクラムが成功するかどうかの重要なものであること、そしてスクラムの"価値基準"が具現化できていなければスクラムを支える「透明性」「検査」「適応」がハリボテになりかねないということも、スクラムガイドは示唆しています。

このセッションでは、Back to the basic of Scrum（スクラムの基本に立ち戻る）と称して、スクラムの根幹を支えるスクラムの"価値基準"についてふりかえってみようと思います。

スクラムガイドでは踏み込んで紹介されていない5つの価値基準ですが、XP（エクストリーム・プログラミング）と組み合わせて考えることで、これらの価値基準が何を意図しているのか・なぜ大事なのか・なぜスクラムの成功に関わるのかが見えてくると考えています。

アジャイル開発/スクラムを導入しているあなた、こんな発言を耳にしたこと、発言したことはないでしょうか？

• 「当事者意識を持って！」
• 「スクラムには階層は存在しないから、指示待ちせずに行動！」
• 「それはアジャイルじゃない！」
• 「ふりかえりはしなきゃダメだよ。」
• 「チームは自己管理型(※)なんだから～」

こんな言い方ですと、チームのメンバは委縮してないですか？あなたの「アジャイル」価値観を押し付けてないですか？

私は、複数のスクラムチームでの開発を通じて、アジャイルマニフェストを読んだだけ、スクラムガイドを読んだだけ、で出来るほどアジャイル開発/スクラムは甘くはないことを痛感してきました。

・ドキュメントの文面だけを捉えて行動しても、それは薄っぺらいものになってしまう

・背後にある理念を理解しないと、ただの「作業指示」になってしまう

・やらされ感を感じ、チームの雰囲気が悪化してしまう

その結果、Be Agileを目指しているつもりが、Do Agileになり、気づけば「押し付けアジャイル」になってしまった。

こうなってしまうと、負の連鎖は止まらない。なんとか悪循環から脱出したいと思い、押し付けアジャイルは「ダメ。ゼッタイ。」をスローガンにカイゼンを始めてみた。

このセッションでは、私がスクラムマスターとして、開発メンバとして、複数のスクラムチームで経験/目の当たりにしてきた

「押し付けアジャイル」による失敗事例、アンチパータンとそれらを生み出していた根本原因、

そして、悪循環からの脱出に向けた改善に向けた取り組みについて、お話します。同じ悩みを抱える方々のご参考になれば幸いです。

※自己管理型とは、

2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。

～スクラムガイド２０２０より～

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Global Day of Coderetreat は、仕事を離れて、ソフトウェア開発と設計を練習するイベントです。無料で参加できます。美味しいランチとおやつが付いてます。きっと、忘れていたプログラミングの楽しさを思い出す機会となるでしょう。

コロナ禍でオンラインイベントという選択肢が新しく増え、主催側も参加者側もより気軽にIT勉強会やコミュニティイベントにタッチできるようになりました。アジャイル界隈においては、本イベント：スクラムフェス札幌に代表されるように全国各地でRSGTの文脈を継いだイベントが開催されるようになってきています。

イベントの花形は何と言っても登壇者です。壇上に立ち堂々と語る登壇者のその姿は、経験のない人が見るとまるでキラキラと輝いて見えます。いつかあの煌めくステージに立ちたい、と思う人も少なからずいらっしゃるでしょう。

ですが、イベントは登壇者だけでは成り立ちません。企画段階から地道な準備を続け、当日もこまごまとイベントを滞りなく進められるよう動き回る裏方スタッフ、大きなイベントに限りますが、イベント主旨に共感し決して安くない金額を提供してくださるスポンサー企業、なによりイベントを盛り上げてくれる参加者、それらすべてがイベントを成功させるのには不可欠です。

今回のセッションでは、あまりフォーカスの当たらないイベントの裏方スタッフのお話をさせていただきます。

筆者は登壇者としては2012年にDevLOVEというコミュニティで初めて社外登壇を果たしましたが、近年はほとんど登壇はおこなっておりません。一方でイベント運営側は社内の小さな一部署で開催した小さなイベントから現在まで様々なイベント開催を行い続けており、現在まで15年以上のイベント裏方スタッフのキャリア(？)があります。現在も3つのコミュニティのイベント運営スタッフとして携わっており、オンライン・オフライン、定期・不定期に関わらずイベント開催を続けております。そんなことを続けてたせいでうっかりテレビに出ちゃったこともありました。

前述のように近年コミュニティイベントは増加傾向にあり、それに伴ってイベントの裏方スタッフの必要数も増加しています。また、自身でイベントを立ち上げたいという熱意を持った際に以前より気楽に立ち上げられる環境もが整っていることもあります。自分がコミュニティイベントを主催・運営するという選択肢は以前からもありましたが、より手近にその選択ができるようになった、という状況です。

そういった状況の中で、これからイベント運営に携わりたい、イベントを主催してみたい、という人に向けて、筆者の経験が役立つのかもな、と思い、今回プロポーザルを出させていただきました。

イベント運営は予測不可能かと思われるような物事の連続ですが、それらを上手にコントロールして、自身も楽しめるイベントを開催することは可能です。20分という短い発表時間ではありますので、おそらく筆者の持つイベント開催ノウハウの1/10もお伝え出来ないとは思いますが、そのエッセンスだけでもお伝えできれば幸甚です。

テスト駆動開発を実践していると自然なのか意識してなのかは分からないですが
テストや品質保証活動についての知見に近づいていきます。

たとえばSQuaRE(ISO25000シリーズ)で示されている品質モデルやソフトウェアテストの国際規格である「ISO/IEC/IEEE 29119」などがその例に挙げられます。

ところでみなさんの中で、4次元って聞くとワクワクする人はいませんか？
わたしは厨二心が揺さぶられます。

そこで、上記規格で示されている事柄を4次元で整理した上で、昨今のアジャイルなテスティングの話を取り入れて事例と共にお話したいと思います。

なお、上記規格の話は以下の本の内容を参考にさせて頂いております。
ソフトウェアテスト規格の教科書(ISBN978-4-9911379-0-7)

高速な仮説検証により多くの価値を提供し続けることを目指した営業部門のみのチームがノーコード開発（ソースコードを書かない開発）とスクラムの掛け算に挑戦した事例をアジャイルコーチとして支援した立場からお話しします。
そこではノーコード開発の理想と現実のギャップ、営業部門ならではの想定外の強みと弱みがありました。
IT人材の不足や内製化需要の高まりの中で注目される市民開発、ノーコード開発がスクラムとどのような化学反応を起こすのか、そこで見えた未来の姿を紹介します。

変化がますます激しくなりリニアに先が予測できない状況において、強い組織、強いチームとはどういったものなのか、そして、どのように醸成すれば良いか。
多くのマネージャーやリーダーの方が悩まれています。

そのヒントの1つに自己組織化があると考えます。

では、チームの自己組織化を促進するには具体的にどうすればよいのでしょうか？
その解決策として、Management 3.0では多くの手法が紹介されています。

本セッションでは実際に手を動かして手法を体験する事で、勘所をご理解頂き、現場に持ち帰っていただく事を目的としています。

どんな手法を体験するかはルーレットで決定しますので、当日までのお楽しみです。
ただし、どんな手法でもきっとみなさんの組織やチームの円滑な運営、組織変革の推進に役立ちます。

私たちは ”明日から使える” 手法をより多くの方にご体験頂き、現場で活用頂き、少しでも現場が良く成る事を目指しています。
そして現場で実践した結果をフィードバックして頂き、良いチームを一緒に増やしていきましょう！

なお本セッションは、「人に優しい組織マネージメント」勉強会で6月に実施し、大盛況だったセッションの拡大版です。
勉強会の様子はリンク欄からご参照ください。

プロダクトマネージャーがどのように世界を見ているのかを紹介するセッションです。

まわりを見渡してみるとプロダクトばかりなはずです。何気なく過ごしている日常でも、プロダクトオーナーやプロダクトマネージャーにとっては刺激的な情報であふれています。

コンビニに入れば3000点もの商品が目に飛び込んできますし、道を歩けばお店の看板が目に入ります。何気ない駅構内の広告からは、そこを商圏にしている様々な企業を想像でき麻酔。

このセッションでは、このようなプロダクト開発する人は普段の日常をどのように見ているのかを紹介し、プロダクトに関するインプットを10倍にする見方を紹介します。

・周りにあるもの
・家を出てから出社するまでに出会うもの
・家電量販店で出会うもの
・コンビニでの過ごし方
・プロダクト開発のヒントの見つけ方

あじゃてく（Agile Tech Expo)のみなさんと発行した「ぼくのアジャイル100本ノック」
めでたく8月に発行に至りましたが、結果的に100章、450ページの本になりました。

本書の内容は、
「アジャイルの具体例を知りたい」「成功例も、失敗例も、困ったことも」「実体験を！聞きたい！」
「スクラムやってみた」「JTCでスクラムって無理じゃね？」etc…
参加者の経験、体験、知見のぎっしり詰まった、パワーのある本になりました。

アジャイルに関する色々をまとめるという本企画を通じて、
・参加者が得た体験
・コミュニティが得たこと
・本がもたらした成果、届いた先　という観点でお話しします。

普段とは違う「アウトプット」をして、参加者（寄稿者）が得た体験、
自分の知識の棚卸や整理ができたといった大きなメリットがありました。

コミュニティで本を作るということの意義の点では、
活動記録としての本という媒体、そしてコミュニティで発行することにより、
パワーのある本を作り、広く届けることができました。
また、コミュニティがそのスキームを獲得・経験することで、次回企画にも活用できます。
約60人の参加者がゆるく、でも一つのテーマについて考える機会にもなりました。

「本の執筆」という形のアウトプットの意義と、それがもたらす効果、ブログや登壇との違いをご紹介します。
インプットも重要ですが、知識・経験をアウトプットしてみましょう。
それが、聞いてくれた人の背中を押すことになれば最高です。

本を作り上げるという行為は、様々な技術要素を含む「プロダクト開発」そのものです。
本に取り上げる（文字になる）技術的内容以外にも、
ネタ出し（≒伝えたいネタを探す、想定した読者に届けるためのマーケ）、執筆≒開発、
それ以外にも、デザインやプロモーション（SNS告知など）を小規模に実体験できます。
通常のプロダクト開発では「全体のごく一部」にしか関われないことも少なくありませんが、
一気通貫にすべてを体験できるレアなチャンスです。

さらに、「合同誌」であれば、複数の著者、あるいはデザイナーや校閲など様々な立場でチームができます。
今回は企画・編集（+本文執筆も）という立場でしたが、
スケジュールの設定や、著者へのフィードバックなど、
約60人の執筆者みんなが原稿を気持ちよく出すための工夫もあります。

また、本書をはじめいくつかの技術同人誌を持ち込んで、
現地で頒布もする予定ですので、ぜひ見てみてください。

https://oyakata.booth.pm/
これまでに作った合同誌はこちら。様々なコミュニティのメンバーがいます。
合同誌ならではの内容面での広さや、いろいろなトピックスで本が書けるということを見ていただければと思います。

https://note.com/ayanaru/n/n07a5bf761d42
https://note.com/oyakata2438/n/nf62de9a7f0ff
ぼくのアジャイル100本ノックの概要・理念