プロダクト開発の合言葉は『横に並べて縦に切る』

この記事はレッドジャーニーのアドベントカレンダー18日目として書いています。

昨日はぺこーら（←という呼び名を本人は強く否定しているようだがw）がチームに頼る頼られる話をしていますね。馴れ合いではなく補完の関係になれるといいですね！

note.com

プロダクト開発のフレームはたくさんある

プロダクト開発をしているみなさん、お疲れ様です。

プロダクト開発をしているみなさんは、いろいろな書籍でそれこそたくさんのフレームをご存知だと思います。

しかし、それぞれのフレームをどう相関させて、実際の開発や検証にまでつなげていくのかを一気通貫に書いてあるものはあまり見かけません。

そこで、今回はそういった各種のフレームをつなぎ合わせ、どういう風に活用するのがいいのか、1つの考え方としてお話ししたいと思います。

Step1：As-Isカスタマージャーニーマップ

皆さんがユーザー行動を知ろうとする、すなわちUXの分析をするときによく使うのがカスタマージャーニーマップだと思います。

カスタマージャーニーマップはユーザーの行動だけでなく、感情も含めて表現することができます。

ポイントは2つありますね。

1つはジャーニーマップはコンテキストを同一にする1ユーザーパターンしか描けないところ。

もう1つはジャーニーのスコープをどう描くかで捉え方が大きく変わるというところです（アプリを触っているときのみなのか、それ前後の認知から利用完了までなのか等です）。

どちらにしても、これは、「ユーザーの行動やお気持ちを横に並べて、縦に切りだしてユーザーの期待や課題を抽出する」フレームということです。

Step2：To-Beカスタマージャーニーマップ

Step1で抽出した期待や課題に対して、ソリューションやアイディア出しを行い、それが実現された世界のTo-Beを描いたもの（すなわちUX定義）が、こちらのTo-Beカスタマージャーニーマップです。

こちらは、先程のAs-Isとは違い、「変容したユーザーの行動やお気持ちを横に並べて、縦に切り出してアイディアや他にはない価値を抽出する」フレームということです。

この切り出されたものがエピック一覧や機能一覧になっていきます。

Step3：エピックロードマップ

みなさんがどこまでこういうものを作っているかわかりませんが、プロダクト開発を考える上で、大まかなマイルストン設計、プロダクト戦略づくりというのはしたことがあると思います。

ここでは、それをエピックロードマップと呼んでいます。

このエピックロードマップでは、Step2で抽出された期待や課題のエピック一覧をもとに、「エピック単位の実現タイミングを横に並べて、線表に起こす」、ということをしています。

プロダクトバックログを使っているよ、という人もいるかも知れませんが、それだけだといつどんな機能がどうなっているのか、ということが見えにくくなるので、こういったロードマップを使って情報を整理して透明化をはかるのがおすすめです。

Step4：ユーザーストーリー

エピックのおおまかなスケジュールをプロダクト戦略から導いたところで、次にそのエピックに含まれるスコープを明確にしていく活動をしていきます。

つまり、「エピックごとにユーザーストーリーを縦に切り出していく」ことになります。

ユーザーストーリーは、基本的に、「〇〇が△△したい。なぜならXXだからだ」という形で表現していくものです。

これで、実際にそのエピックに含まれるシーンが明確化されます。

Step5：プロダクトバックログ

ここではプロダクトバックログと表現していますが、事実上のユーザーストーリー単位の中日程です。

「先程書き出した縦に切り出したユーザーストーリーを、線表の上に横に並べていき、どういった優先順位でプロダクトに実装していくのかを明示」します。

このときに、スケジュールにしばられる必要はありません。純粋に、プロダクト開発上の優先順位がわかるものであれば、上記のようなガントチャートのレベルまで落とす必要はありません。

Step6：スプリントバックログ

スプリントバックログはみなさんにもおなじみのカンバンを使ったタスクの粒度のものになります。

Step5で並べた「プロダクトバックログの優先順位に基づいて、スプリントや次のタームで行うタスクを洗い出し、縦に切り出した」もののことです。

ここから、1つずつのタスクごとにレーンを横に動かしていくことになります。

まとめ

どうでしょう、断片的なシーンを切り取っているのでプロダクト開発におけるすべてを表したわけではありませんが、イメージは掴めたのではないでしょうか。

皆さんも、「横に並べて縦に切る」を合言葉に素敵なプロダクト開発ライフをお過ごしください。

明日もお楽しみに！

どうして階層型OKRを運営するのは難しいのか

この記事はレッドジャーニーのアドベントカレンダー16日目として書いています。

昨日は田中くんがChatGPTセンセイをつくってみたお話しをしています。

ぺこーらと田中くんは『ChatGPTと学ぶ』シリーズなどのイベントもやっていますので、そちらも要チェックですよ！（来年もやるのかはしらないけどw）

note.com

OKRやっていますか？

なんか社会現象的に目標設定にはOKR！みたいな盛り上がりが数年前にあった気がしますが、みなさんの会社？組織？プロダクト？チーム？ではどうですか？

最近は少しその辺も落ち着いてきて、単なるバズワードからもう少し地に足がついた議論がかわされるようになってきた気がしています（気のせいかもしれません）。

海外でも日本でもいくつかの素晴らしい成果につながっている事例も見聞きすることはありますが、実際のところ、みなさんの体感として、OKRがうまく機能していると思えている人はどうでしょう？あまり多くないのではないかなという印象です。

では、なぜOKRがうまくいっていないと感じるのか、私の見てきた事例からパターン化して考察してみたいと思います。

階層型OKRには大別して3パターンある

Pattern1：やることに集中！型

これは見ての通り、上位で決めたKRを下位の層でまるっと受け止めるものです。

メリット

上位の階層で決めている指標をダイレクトに追いかけていくので、目標が明確であり、そのための主要な結果指標やタスクを考えるのが非常にわかりやすいです。

デメリット

上位のOを意識するわけではないので、普通にこの形をとらえると、自分たちが本当は何（大もとのOなど）を達成するためにこの下位層のOKRをやっているのかわからなくなりやすいです。

盲目的に指標だけを追いかけることになる可能性もあるため、定期的に上位層とゴールに向けた活動になっているかの相関をチェックすることをおすすめします。

相性の良い組織

比較的小規模、特に熱量の高い創業社長がぐいぐい引っ張っているベンチャーや、圧倒的ブルーオーシャンの中で方向性が目に見えている企業においてはこの形式をとることもわかりやすいと思います。

特に、ベンチャーなどで組織や社員がまだ若く、スキルを磨いている時期であれば、集中して目標に向かえる環境に役立つかもしれません。

Pattern2：上位憑依型

下位のOの設定には上位のOから落とし込むことで本質的なつながりを維持しつつ、その方向性は上位のKRに倣うので自分たちの意思というよりは上位の意思を自分たちの形にして纏うような形となります。

メリット

自分たちの活動がOの連続性が担保されることで目的を見失う可能性は低くなります。

デメリット

上位KRに倣うため、下位KRの指標が下位のスコープに応じた按分の指標となりがちです。また、上位KRに倣って下位KRを定めることになるため、上位KRの設定が絶対的に正しいと思えるものでないとやる意味があるのかの疑問を生じるかもしれません。

その場合の修正には上位のOKRを含めて通しでアライメントをとる必要がある点が注意です。

相性の良い組織

多くの組織はかなりこれに近いパターンを採用していそうですが、このパターンを採用することで違和感を覚える人たちが多いようにも感じます。

プロダクトと企業の姿勢でいえば、企業の姿勢に共感を覚える社員が多い会社にこのパターンが合いそうです。企業の姿勢としての目的と結果指標を共有することがそもそも容易だからです。

Pattern3：上位下位合意型

これは一見すると複雑ですが、目的と指標のすり合わせで考えると、一番理にかなっています。下位が上位のOを見たときに、上位のKRはこうであるほうがいいのではないか、という提案をし、複数の下位からあがってくるKR候補を総じて眺めて大事なKRを選定あるいは修正して確定する、というもので、上位の視点での意思だけでなく、下位からみた意思も反映されているところがポイントです。

もちろん、OKRはやることすべてを書き出すわけではないので、別に上位KRに採用されなかった下位の提案したKRをやらなくていい、ではなく、より上位KRに定義されたものを大事にした上で必要ならやる、というものと理解することになります。

メリット

上位が上位の視点だけでOKRを立てるのではなく、下位が上位Oを意識したときにどんなKRを定めるべきか視点と視座をあげて提案することで、下位OKRとも強い結びつきが得られます。納得度という意味では増しやすくなるでしょうし、否が応にも上位を意識しなければいけないので、結果も自ずと上位につながる結果を出すことが約束されやすいはずです。

デメリット

図では上位と下位の組織が1:1で描いているのでシンプルに見えますが、実際は上位と下位は1:4などの場合もあるわけですね。
さらにその下にも下位の組織がついてきて同じ活動をしていくとなると、とんでもなく時間がかかります。

とにかくこのパターンの一番のデメリットは決定までのプロセスにおける登場人物が増えれば増えるほど決定に異様に時間がかかるところです。

相性の良い組織

Pattern2の逆で、プロダクトへの愛着や意識で強く結ばれている組織に合うのがこのパターンだと思います。特に上位はプロダクトの言いなりになるのではなく、組織戦略からの調整役として機能することで、方向性を強く打ち出すことができます。

結局どうしたらいいのか

なにが階層型OKRの運用を難しくさせているのか。

それは、同じOKRというフレームだったとしても、運用一つで効いてくるポイントがぜんぜん違うものになってしまうところです。

上に書いた分類は、あくまで一つの私の見方にすぎませんが、もしかしたら同じ組織だからといって全社統一で同一のPatternを描けないケースもあるのかもしれません。

一番大切なのは最上位Oという目標に対してどうしていくのがよいのか、なのでその観点で自分たちの組織に最適なPatternを見つけるしかないと思います。

借りてきたフレームやPatternでうまくいく可能性は。。。残念です。

付録

Oの定め方の設計は検証のスパンとの間で詰めていくことになります。

例えば、組織で年度の計画的目標を遂行するようなケースをイメージしてOKR設定のフレームを作ってみたものが下になります。

特に今回の3パターンとは関係なく、OKRの決め方やOKRの追いかけ方の一つの例なので、どのパターンでも使えるでしょう。

ゴールをどう据えて、どのタイミングで何をするかをしっかりと設計しておくこともOKRの運営の大事なポイントです。

さて、12月も折り返しを過ぎました。

今年もあと少し。

明日のぺこーらにもご期待ください！

予防型プロジェクトマネジメントのすゝめ

この記事はレッドジャーニーのアドベントカレンダー11日目として書いています。

adventar.org

昨日は、ぺこーらによるチームの割れ窓理論の話でした。こういうのもなんだか慣れがもたらす症状として言われると気がつくものですよね。

note.com

はじめに

予防型プロジェクトマネジメントと聞くとどんなことを想像するでしょうか。

対義語で捉えると、事後対応型プロジェクトマネジメントということになると思います。

こうやって言われると一般的なプロジェクトマネジメントって事後対応型のマネジメントが多いと思いませんか？

課題管理、リスケジューリング。。。etc

いったん立ち止まって一緒にプロジェクトマネジメントを考えてみましょう。

最高のマネジメントに事後はない

予防型と事後対応型だったらどちらが安心できるマネジメントスタイルだと思いますか？

もちろん、起きたことをいかに素早く消火できるか、というのも一つのマネジメントです。しかし、もしそもそも火が起きなければ、その必要もなくなります。

つまり、最高のマネジメントの状態とは、火が起きる前に対応し、事後に行うことがない状態なのです。

プロジェクト計画ではなくプロジェクト運営計画を

では、予防型にできるか否かはどこから始まっているのか。

それは、プロジェクト計画をたてたときには既に始まっています。

プロジェクト計画を立てるときに検討する事項の大筋はおそらくプロジェクト計画書というものに準じて考えられていると思います。この"準じて"、というところが厄介で、本来プロジェクトは世の中に一つとして同じものはないのだから必ずゼロから考えて書きましょうとなっているはずです。しかし、だいたいのプロジェクトは、かつてのプロジェクト計画書のなにがしかを流用し、変更があるところだけ書き換える、みたいな運用をしてしまっているのが現実です。

別に、結果的なところを追いかけたい、達成したいゴールやドキュメントを羅列するだけでよいのであれば、個人的には（魂なんてこもっていないですが）それでも構わないと思っています。

しかし、それはあくまでもプロジェクトの結果指標を追いかけた計画（すなわち、デリバリーにあわせて線表を引いているだけ、課題が出たらこう管理すると定義しているだけ等）であり、これを書いたからプロジェクトがうまくいきそうかいかなそうかというのは全く読めません。

プロジェクト計画の中で考えたいのは、そういうプロジェクトの特性や特徴を鑑み、状況や状態に応じて何をどうやっていくことで安定をもたらすのか、です。

実態、チームとして朝会やりましょうか、はだいたいが計画当初から盛り込まれているよりは現場の温度感で始まるケースも多いと思います。

そういうことを、ケースとして見越しておく、あるいはチームに提案していく弾をいくつも想定しておくことをプロジェクト運営計画と私は呼んでいます。

私と一緒に仕事をしたことがある人であれば、「常にプランBを備えておく」という言葉は耳にタコができるくらい聞かされていることでしょう（実際にはCやDまで考えておかなくていいんですか？ということはよく言っています）。

課題管理より始めよ

私が気になっている最たるものが、課題管理及び課題管理表です。

課題管理表をみてみると、項目に「発生日」「課題内容」「対応内容」「担当者」「完了日」などが並んでいると思います。

普段はあんまり気にしていないと思いますが、これってすごく不思議ですよね。「発生日」がトリガーとなっている、すなわち事後対応型のマネジメントドキュメントになっていると思いませんか？（もちろん気がついている人はうまく活用していると思いますが）

では、まだ発生はしていないが後々課題になるかも、みたいなものはどう管理するのでしょう？

一般的には未来課題を書くのがリスク管理及びリスク管理表と言われます。しかし、リスク管理表の主な使い方は、QCDSに影響が出そうとか、クライアントや提供元とのネゴシエーションがうまくいかなかったらとかそういうレベル感のもので、プロジェクトへの影響度が高いものだけが管理されていませんか？

プロジェクトのほとんどは現場で行われていて、課題も現場で発生します。

そういった現場課題に対して、「常にプランBを備えておく」、すなわち予防型の課題管理はどうするべきでしょうか。

私の答えとしては簡単で、「対処開始予定日」という項目をいれることで解決できると考えます。

今までは「発生日」が基準でしたが、プランBを考えたほうがよさそうなことが見えた瞬間には、課題管理表に記載、事前対処が必要となるであろう「対処開始予定日」を予め埋めておきます（それもかなり悲観的に）。

そうすると、プランBを事前に動かしたほうが良さそうだというタイミングを逃しませんし、プランBを選択しないためにやっておいたほうがよいこともタスク化しやすくなります。

この場合、「発生日」は「記入日」レベルに変えて解釈する、あるいは変えてしまう方があとでふりかえったときに、いつ頃にはこの課題に手を打てていたっけということを確認することもできます。

はじめの一歩

ここまでは割とやり方の話を中心にしているので、じゃぁそれをどうやって運用すればいいんだよというのはあると思います。

今までそこまですべての営みにプランBを考えてきていない人たちには、そのプランBをいつ、何について考えておけばいいのか、というほうが難しいでしょう。

そこで、今日からできるはじめの一歩です。

チームのメンバーに朝会でも週次の進捗確認でもなんでもいいので、こう聞いてみてください。

「今日明日（あるいは今週来週）で起きたらいやだなーってことありますか？」

これがプランBを用意しておくべき種、すなわち予防型プロジェクトマネジメントの始まりにできます。

明日もお楽しみに！

ユーザーは会議室にいるんじゃない！現場にいるんだ！

この記事はレッドジャーニーのアドベントカレンダー4日目として書いています。

adventar.org

昨日は弊社のぺこーらが書いていますが、内容もさることながら最後に宣伝を忘れないというところが私と違ってさすがとしかいいようがありませんw

note.com

ユーザーはプロじゃない

もう15年くらい感じているプロダクト開発の現場における状況って未だに変わっていないなと思うことがあります（たぶん世界はもっと変わっていない）。

15年前（本当はもう少し前）といえば、私自身は某保険会社の立ち上げのプロジェクトに参画していました。

当然ながら当時の私のようなSIerのもつ保険業務知識やそもそもの保険に関する知識も事業会社である保険会社さんの人たちには到底及ぶわけはありません。

ただ、その頃から感じていたのは、この人たちはものすごく頭も良いし、業界や商品のことを本当にわかってらっしゃるということ。の反面、ユーザーはそんな商品知識や保険料の成り立ちについてわかっているわけではないので伝わるのかしら？という疑問でした。

あれから15年たち、最近はたくさんの業界の方とお仕事をしていますが、やはり同じような気持ちを感じるシーンがありました。

当然商品やサービス、プロダクトはプロである人たちが細部まで作り込んで考えることはとても素晴らしいことだと思いますが、ユーザーの大半はプロではないということを念頭に置くことは非常に大事なことです。

プロも道を外れればプロじゃない

事業会社の人はその道のプロかもしれませんが、例えばそれを売るとか、それを認知させるとかのマーケティングのプロかというとそうではないことは往々にしてあります。

先日もとても素晴らしいプロダクトの構想をもつクライアントさんとお仕事をしました。それはWebサービスで、比較的富裕層や年齢層の高い人向けのサービスを想定したものでした。

ある日、とある7人ほどが集まったミーティングで、

「で、これはどうやってユーザーにアプローチするのですか？」

という質問をしてみたのですが、返ってきた答えは、

「WebサービスだからXやインスタで広告流したり拡散してもらえばいいんじゃないですかね？」

でした。

私もすかさず打ち返します。

「ほほう、では皆さんのような年齢層の高い人がターゲットなので皆さんもターゲットに含まれると思いますが、この中でXを日常的に見たり拡散している人はどれくらいいますか？」

「。。。」

「だとするとなかなか難しそうですね。。。」

というやりとりがありました。

結局この件は、ターゲットを絞りに絞って検証するという意味でアプローチをし、最終的にはポスティングが一番効果があった、みたいなやりとりで一旦幕を引きました。

ユーザーは会議室にいない

会議室で仮説を考えたり、結果を吟味することはとても大切なプロセスです。

そして、自分たちが議論しているのが仮説なのか、事実なのかを切り分けることはその一番最初のプロセスになります。

得てして、自分たちはドメインのプロであるが故に、あるいは日常の何気ない"普通"にとらわれて、バイアスをかけてしまうことはよくあることです。

このバイアスに囚われているかもしれない、ということを疑うことは批判的な行動ではなく建設的な行動であるという共通理解をもちたいですね。

そして、事実に至っていない仮説の検証はユーザーに対して行う必要があるということになります。

別に「餅は餅屋」とは思っていない

一応誤解なきようお伝えしておくと、今回の事例のケースにおいて、マーケティングはプロじゃないんだからマーケティングのプロに任せたほうがよい、と言いたいわけではありません。

私たちは暗黙に、車は移動するもの、若者はインスタを使うもの、鉛筆は書くもの、という意識をもってしまう生き物であるがゆえに、車を個室と捉えるとか、鉛筆を束ねて折れにくい棒として使おうとか、あまり考えなくなってしまう生き物です。

そういう意味では、子どもたちのほうが柔軟に手元にあるもので自由な発想でカラフルなレゴを組み立てて恐竜を作ってみたり、ペットボトルを使ってロケットの工作をしてみたりしていませんか？

ユーザーというのはある種突拍子もないことをする人たちで、自分たちのはるか斜め上の使い方や行動をとる生き物だと思っておくのがいいのだと思います。

結局、ユーザーは普通こうやって使うでしょ、は某氏の「それはあなたの感想ですよね」と同じではないでしょうか。

仮説と事実にしっかり線を引き、本当のユーザー行動、ユーザーインサイトを手に入れる活動をできるかどうかが大事なのですよ、ということをお伝えしたかったのでした。

その上で、必要なら餅屋に頼んでみることをオススメします。

ということでしっかり読んでもらうとタイトルがただ言いたかっただけじゃん！と言われそうなくらい中身とずれましたがご容赦くださいw

明日は「はまぐちともやの落とし穴シリーズ」でおなじみの濱口くんの素敵なお話が聞けることでしょう！w

お楽しみに！

アジャイルはなにをするのか、なにを繰り返すのか

この記事はレッドジャーニーのアドベントカレンダー2日目として書いています。

adventar.org

はてさて、今年も気づいたら12月が来ていて、気づいたらアドベントカレンダー2日目が私ではないですか。。。

昨日は、田中くんがアジャパンのことを書いていますのでぜひよんであげてください！

note.com

前説

アジャイルの世界が日本に馴染み始めて早20年以上たつと言われている今日このごろなわけですが、やはりまだまだアジャイルへの理解、アジャイルとは、みたいなところが噛み合っていないのだなぁということを感じることがたびたびあります。

ちょっとだけそこの誤解を紐解くきっかけになったらとおもい、今日のお話を書いていきます。

アジャイルは小さく繰り返す？

「アジャイルは小さく繰り返すんでしょ？」

これはしごくよく言われるフレーズです。

言っていること自体はわかりますが、実際"何"を"どれくらい"で"なぜ"繰り返すのでしょう？

何を繰り返す

アジャイルが”何”を繰り返すのか。それは、「実験」と「実装」です。

実験

よくアジャイルコーチが「ちょっとだけチームで実験してみたらいいよ」みたいな声掛けをする現場を目にします。

ここでいう実験とは、例えば効果があるかよくわからないけどよさそうだからちょっとだけやってみて検証してみる、みたいな活動です。

例えば、「毎週このフォーマットで報告しているけどやめてみる」とか、「ふりかえりをKPTでしかやったことがないけど、Timelineにしてみる」とかそういう日常の営みから一歩外れた『非日常』に踏み込むことです。

そういう意味だとそれくらいのことやっているよって思いますよね。おそらく皆さんには"アジャイルをやろう"とするカイゼンマインド自体は持ち合わせているからです。

なぜ実験という言葉を使うのか。それは、実験は成功が保証されていないことを前提とするからです。実験の先にあるのは、成功か失敗かと、実験からの学びだけです。

実験なのだから、うまくいかなかったことを反省会する必要などありません。やってみたら（あるいはやめてみたら）よさそう、という何かしらの筋をちょっとだけ辿ってみて、それが勝ち筋なのか負け筋なのかをはかる短期の学習プロセスだと思うことが大切です。

実装

じゃぁ実験をしてみたものの、その結果を受けてどうするのか。それが「実装」です。

実装というと言葉はかたいかもしれませんが、実験したものをチームや組織の営みに定着させる必要があります。

チームや組織によって形は異なりますが、それをワーキングアグリーメントに追加したり、開発プロセスを修正したり、スクラムイベント（セレモニー）に手を入れたり。。。そういったカイゼンを『日常』に落とし込むことで”アジャイルになろう”とする活動のことです。

あえてこれを明示的に行いたい場合は、ふりかえりのプロセスの中で、「スタート、ストップ、コンティニュー」などを使っていくとよいかもしれません。

どれくらいで繰り返す

小さくという言葉があらわすものは定量的ではなく定性的なものです。

但し、今より小さければよいという相対比較をすればよいものでもなければ、小さければ小さいほどよいというわけでもないというところが難しさでもあります。

ここでいう難しさとは、何も考えずにやれるわけではない、ということです。

では、どれくらい小さければいいのか。それは、結局実験の大きさによります。

実験をすることで得られるフィードバックが検証できるサイズでやれていないと意味がありません。その最小単位、プロダクトでいうところのMVPかどうかが小ささの基準になります。

そうすると、小ささには物事ひとつひとつに実験の大きさがかわるから、イテレーティブなタイムボックスに収まったり収まらなかったりするじゃないかとなりますよね。

そうなんですよ、そんななんでもかんでも1スプリントで検証しきれるとかあるわけありません。個別最適化が必要なのです。

ただ、一つだけ言えるとしたら、1スプリントで検証できるサイズで実験できないか、を考えてみることは、もっとMVPを尖らせられないかと考えるのと同じく、アプローチの一つとしては受け止めてもいいのかなと思います。

なぜ繰り返す

ここまで、実験と実装を繰り返し、日常から非日常に踏み出して、良きものを日常に取り込むのだという話をしてきました。

これはすべて、チームや組織の学習プロセスの1つであり、成長のためのカイゼン活動だからです。

学びや成長を不要とするならば、カイゼン活動もいらないですし、アジャイルである必要がない、ということなのかもしれませんね。

まとめ

私としては、チームや組織の中における文脈を前提に読めるようここまで書いてきました。

ただ、視野の広げ方というのは多分にあって、「実装」は自分たちの『日常』にする活動なのでどうしても主体は自分たちですが、「実験」は別に必ず自分たちで行わなければいけない理由はありません。

「隣のチームのカンバンボードをみせてもらおう」みたいな話はよくありますが、見るべきは「カンバンボード」ではなく、「カンバンボードに工夫されたポイントのその裏にある背景、コンテキストを教えてもらおう」ということを意図しています。

つまり、何かしらのおかれた「状況」に基づいて、『非日常』に踏み出した「実験」をした結果、よきものを「実装」し『日常』としているわけで、自分たちと「状況」が近しいほど他者の「実験」もインプットにしてよいのです（自分たちの「実装」に値するかの「実験」は必要ですよ）。

これがハンガーフライトということなのですね。

みなさんがアジャイルをやってみて、アジャイルになっていくという実験と実装の繰り返しを楽しんでくれることを期待します。

いやー長かった！

明日はレッドジャーニーのぺこーらですねw

お楽しみに！

濃密なひと月

ちょっと久しぶりに戯言を垂れ流します。

いやー昨日アジャイルジャパン2023が終わって僕の中でもいったん小休止という感覚です。

この1カ月、弾丸で福岡に何度も行き、東京某所で共創ビジネス創造のワークを何度もし、子どもの学校のイベントも目白押し、弊社レッドジャーニーのカンファレンスも3日開催して、更に合宿もし、福岡からのPodcastからの筑波大学で3h授業、そして昨日までの二日間、アジャイルジャパンにスポンサーと公募登壇者として参加とかめちゃくちゃ濃密すぎる1ヶ月でした。

三男を9月からカブスカウトに入れたことも相まって月に2日はボーイスカウト関連で日曜日がつぶれるようになり、公私ともにかなり忙しなかったなと思います。

気がつけば11月も半分を過ぎ、外はだいぶ涼しくなりました。

僕は基本的にNGなし芸人として来る者拒まず全部受けるスタンスで生きているので、仕事が忙しいかというとそんなことはなく、単に自分の関わろうとしているものがいろいろあるから可処分時間の配分がときにこうやってパツパツになることがある、というだけなんですよね。

今の自分はレッドジャーニーの平社員であるとと同時に、SWiseとPlusLabの外部顧問、筑波大学の非常勤講師、XPJUGのスタッフ、アジャイル経営カンファレンスの実行委員、保険xアジャイルコミュニティの運営、そして社外の人のメンターを10人弱とやっています。

つまるところ半分くらいは特にお金にならない活動です。

でもまぁそういうのはあんまりどうでもよくて、いかに自分にできることを最大限社会に返せるかという意味では今は最高に輝いている状態だと思います。

と思うところはあるのですが、私は家の中ではどちらかといえば主夫です。

そういう意味で、ちょっと家にいる時間が限られてくるとどうしても家事が疎かになり、子どもらにも「洗濯溜まってるよ」とか言われてしまいます。

そういうところは、もう少しバランスをとらないといかんですね。

改めてちょっとやりすぎだったところもある1ヶ月だったなと思います。反省。

とはいえ、割と僕の中ではいろんな詰め込みがいったん解消されたこのひと月の最後の最後に、アジャイルジャパンの登壇を気持ちよく、燃え尽きるがごとく終われたのは幸せなことだったなと思っています。

運営さん、参加者さん、同じスポンサーのみなさん、本当にお疲れ様でした。

ハイブリッドではあるものの久しぶりの現地開催、非常に楽しかったです。

ありがとう。弥栄。

スプリントをまわすためにスプリント以外のことを考える

はてさて、社内のプロジェクトの一環でしばらく投稿が増えますw

スクラムやってる？

みなさんの中でアジャイルの取り組み、主にスクラムを実践されている方は多いと思います。

スクラムをやる、ということについては、以前私のブログでも紹介しましたが、「スクラムのスクラムにスクラムをスクラムしないスクラムはスクラムではない？」というお話を読んでもらえると嬉しいです。

blog.samuraikatamaris.red

ところで、スクラムってスプリントというタイムボックスを使って運営していきますよね。その中には、いろいろなチームとしての活動があると思います。

もちろん、セレモニーやイベントと呼ばれる活動もそうです。

そんなスクラムの活動について少し考えていきたいと思います。

スクラムイベントとは

スクラムイベントとは「スプリント」「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ（ふりかえり）」の5つからなります。

スプリントプランニング

スプリントをまわす、という視点に立ったとき、一番最初に思いつくのはスプリントプランニングではないでしょうか。

スプリントプランニングでは、スプリント内で実現するスプリントゴールを掲げ、スプリント内で行うタスクをバックログとして抽出する活動です。

アジャイルは計画なしにやってみるのではなく、計画をたてて、計画を検証しながら前に進んでいくアプローチです。

そういう意味では、以前も書きましたが、スクラムやアジャイルのアクティビティのうち、いちばん大切なものはプランニングであると言えます。

blog.samuraikatamaris.red

デイリースクラム

通称「朝会」などと呼ばれることも多いですが、日次というタイムボックスにおける検査行為です。検査の対象はタスクボード上のものだけでなく、メンバーの状況やチームの状態などを確認する場所でもあります。

スプリントレビュー

スプリントレビューはスプリントで作成されたインクリメント（成果物）をステークホルダーにレビューしてもらい、フィードバックをもらう場です。通常はプロダクトオーナーが説明するものですが、現場によっては開発メンバーが説明している場面もよく見かけます。

一番気をつけたほうがいいのは、プロダクトオーナーへの初見レビューにする場にするものではない、というところですね。

スプリントレトロスペクティブ

こちらも通称「ふりかえり」などと呼ばれることも多いですが、スプリントの活動を通して学んだことを次に活かすために大切な活動です。

スクラム運営の質を上げていくためには、スプリントレトロスペクティブは欠かすことはできません。

スプリント

スプリントはもうそのままスプリントそのもの、想像を創造にかえることです。

上記4つのアクティビティはこのスプリントの中で実行されるもの、という位置づけになっています。

ここまで読んでみると、スプリントを円滑にまわすために今のスプリントにフォーカスしている成分が多めだなーということがよく分かると思います。

ちょろっとあるとすると、スプリントレトロスペクティブが先のスプリントの行動や計画に影響を与える要素があるかなーくらいですかね。

これはこれでとても大事なことです。

スプリントをまわすためにスプリント以外のことを考える

では、スプリントをまわすためにスプリントのことだけを考えていればよいのかというと、そうではありません。

スクラムイベントには含まれていませんが、プロダクトバックログリファインメントという大切な行為が必要です。

これは、今のスプリントや次のスプリントに閉じるのではなく、先々のスプリントをどんなふうに乗り越えていき、目指すべき山（ゴール）に到達できるのかを予測、プランニングする行為です。

じつはこのプロダクトバックログリファインメントが非常に難しいのですね。

あまり先のことすぎると、そこまで詳細化する意味ある？という会話に当然なりますし、次のスプリントのことしか深く考えないとすると、これは本当に山にのぼり切れるのか？ということになります。

このあたりのテクニックとして、よく私がつかうのが、スプリントを3つ先まで粒度を変えてプロダクトバックログリファインメントのゴールとして扱う、です。

こうすることで、例えば3スプリント先で着手しそうなものについて、調査や調整が必要だということで予めわかっているのであれば、そこまでの2スプリントの間になにかしらのタスク化をして準備することができます。

さぁはじめましょう！といってスプリントプランニングを始めるには、Readyとなれない事が多いのです。

よって、はじまらないものはおわらないことになり、山が全然近づいてこない、ということになります。最悪なのは、とりあえず突入して大炎上しながら駆け抜けることになるいわゆるデスマーチへの進行ですね。

これはあくまで、私がスプリントの開始条件を整えるためのアプローチの一例として、上記のようなゴール設定をしてみた、というお話です。

みなさんは、みなさんのチームで、どういう粒度でゴール設定をしておくとよいかについて考えてみるとよいのかもしれません。

まとめ

スクラムを始めたばかりの人、スクラムマスター初心者だったりすると、まずはスクラムをまわすんだ、ということにフォーカスして頑張りすぎる場面をよくみかけます。

でも、スクラムをまわすということは、その先まで見据えた3歩先まではせめて見据えてまわさないと、迷子になる可能性が高まります。

こういったテクニックについても、みなさんのスプリントをとおして、フィードバックを得ながら自分たちのものにしていくことをオススメします。

保険xアジャイルコミュニティをやっています

なんとなく気持ちが筆を運ぶときだけ書いています、れっどですw

7月は結構外出や移動、休日のお仕事なんかも多くて一年で一番忙しかった反動か、8月頭にコロナにかかりました。。。

そこから40度超え4日、2週間近くたつ今でも体力が戻ってこないでくらくらしている今日このごろです。。。

さて、2019年7月に保険xアジャイルコミュニティ『.insurance』を立ち上げてから早4年が経過し、5年目に突入しました。

blog.samuraikatamaris.red

もちろん2019年はコロナ前なので基本的に活動はオフラインでしたが、2020年以降、オンラインでの活動にシフト。。。がうまく波に乗れず、一度フェードアウトしてしまったんですよね。

2022年あたりからもう一度エンジンを掛け直して、オンライン開催且つ運営が無理をしないペースでやろうということで、たらたらやってます。

昨日も今年3回目の活動をしていました。

今は活動拠点をdiscord上に移し、作業場はmiroを使い、Facebookもプライベートグループにしているので、ほぼ外からは姿が見えないところでやっています。

https://exagile.peatix.com/

※一応Peatixで参加者管理はしていますが、discord内で活動するのでPeatixだけ見ても活動には参加できません

このあたりは心のNDAを結んで業界の込み入った話もしていこうぜ！という形を取っているからで、基本はメンバーの紹介制でdiscordに入ってもらえればと思っていますが、もし保険業界に関わっている人（別に保険の事業会社やシステム子会社にこだわりはありません、SIerだろうが卒業生だろうがどなたでも保険業界をもり立てたい人が来てくれたら嬉しいです）がいたら、コメントでもお声がけくださいませ。

前置きが長くなりましたけど、昨日のテーマは「アジャイル型開発プロジェクトにおけるドキュメントどこまでつくってる？」でした。

Scrumを適用しているかどうかとかは別にどうでもいいなと個人的には思っていますけど、アジャイル型のプロジェクトってメンバーを減らして少数精鋭で仮説検証を繰り返して進めているケースが多いですよね。

また、「チーム」としての活動をとっているところも多いと思います。

そういう意味では、デザインをまるっとチームで受け持っていたりもするし、QAをチームに含んでいたりもするいろいろなケースがでてきている印象です。

つまり、今までは分業制でやってきたものが自分たちの手の内でやっていく形に変化してきており、いわゆる内製化みたいな流れも起きているのだと思います。

当然ながら、その流れの中でデザインを初めて自分たちのチームの中でやるケースもあるし、アジャイルかどうかというよりも自分たちの営みをどうしていくのがいいのだろうかを模索している。まさに自分たちのあり方の探索期の人たちが多い印象です。

そういう中で、うちはこうやっているけどみんなどうしている？って言うのも一つの事例としてとてもよい議題にもなるんだけど、みんな似たりよったりで悩んできているのであれば、すでに先行して轍を踏んでしまった知見もたくさんあると思うんですよね。

今はまだこう議論がポストモーテムみたいになっているところもありますが、もっともっと自分たちの未来の話をしながら、会社を超えたハンガーフライトな場になっていくといいですよねー。

そんなことを感じた療養中の2023、夏でした。

自分たちで自分たちのことを考える、を考える

久しぶりに書くのでだらだらいきます。

ご容赦くださいm(_'_)m

私の在籍するレッドジャーニーでは、数ヶ月に一度の頻度で全員参加の合宿をやっています。

全員といっても、フロントメンバーが7人なので、こぢんまりといえばこぢんまりです。

中身のことは、

note.com

note.com

あたりをみていただければ（他人任せw）。

個人的にレッドジャーニーの合宿で面白いなと思う一番の点は、自分たちで自分たちのことを考える時間を大切にしているところです。

上でPeko氏が書いている通り、アジェンダも予定調和もほぼないといっても過言ではありません。

逆に言うと、そもそもこの時間をどう過ごすかということから自分たちで考えるということです。

（考えるという言葉では表現として物足りないなと思うところもあり、あくまで自分たちの勝ち筋（または価値筋といってもよいかも）を見定めるために行う過去現在未来に至る透明性/検査/適応すべてのことかなー）

そういう部分を含め、メンバーがみな自己管理できるし、お互いを尊重しているし、自分たちのことを常に考えているので、居心地の良いプロ集団だと感じるのでしょうね。

（おや、はまちゃんが写っていない！！）

僕の知る多くの組織では、実はこの「考える」をスキップして、以前までのなにかを流用、適用しているだけのケースが多い気がしています。

あるいは、自分たちが達成すべきプロダクト、プロジェクト的なアウトプットや組織に課されたミッションばかりを追いかけ、そのために必要な準備や段取りや戦術を「考える」ことができていないケースも多い気がします。

それは、自分たちで自分たちのことを「考える」、すなわち「検査」できていないことの表れなのでしょうね。

確かに、過去の知識や経験や生み出してきたアウトプットはとても貴重な財産です。

だからこそ、まだそれをそのままでいいのか、状況が変わっている中で適用の仕方を「考える」ことが、大切なのだろうなぁと思います。

つまり、私たちが「自分たちで自分たちのことを考える」時間をとるということは、ある意味意図的に↑をやっている、ということなのですね。

さて、みなさんが「自分たちで自分たちのことを考える」と向き合うとき、何からはじめましょうか。

まずは「考えることを考える」からですかね。

意外と"あえて"と思うようなことについて「考える」のも面白いかもしれません。

携帯料金プランの世界が変わっていて、昔のプランのまま「適用」していたら未だに毎月何万円も払っていた、くらいの大きな気づきを得られるかもしれませんよw

スクラムのスクラムにスクラムしないスクラムはスクラムではない？

この記事はレッドジャーニーのアドベントカレンダー21日目として書いています。

adventar.org

昨日の20日目は新井さんの「同時に発話して会話が成り立つなんてありえない」でした。最近オンサイトの仕事も増えてきていたので身にしみましたね。

背景

さて、何を言っているのかわからないタイトルだと思いますが、最近某所でのスクラムマスター相談会で出てきた「スクラムマスターがスクラムガイドを使った自己検査の具体的なアクションってどういうものがあるだろう」という質問を元にしています。

アドベントカレンダー11日目の中村洋さんの「スクラムマスター自身で自分自身を検査する1つのアプローチ」からもつながっている話ですね。

www.yohhatu.com

まぁ細かいことはおいておいて話をすすめましょうかw

意味

「スクラムのスクラムにスクラムしないスクラムはスクラムではない？」

という文章をちゃんと伝わる文章に直します。

「スクラム（チーム）のスクラム（を通じた活動）にスクラム（の考え方を適用）しないスクラム（チーム運営）はスクラム（をやれているチーム）ではない？」

というお話です。

解説

スクラムのスクラム

スクラムチームのスクラムを通じた活動。

すなわち、3つの柱（透明性、検査、適応）と5つの価値基準（確約、勇気、尊敬、公開、集中）を実現、実践している活動のことです。

しごくわかりやすく考えるなら、いわゆるスクラムチームとしての活動（セレモニー（スクラムイベント）やそれ以外を含むチームの営み全般）ということになります。

スクラムしない

スクラムの考え方を適用しない。

すなわち、自分たちの活動に対して経験主義的なアプローチで「ふりかえり」と「むきなおり」を行っていない（行えていない）ということです。

スクラムはスクラムではない？

スクラムチーム運営はスクラムをやれているチームではない？

すなわち、スクラムを適用して活動していればスクラムをやれているチームである、というわけではない？ということです。

どうでしょう、分解してみたら伝わりましたか？？

結論

スクラムチームがスクラムやってますっていうのに、スクラムチームの活動そのものにスクラムの考え方を適用していないスクラムチーム運営なんて全然スクラムじゃなくない？ってことです。

なので、答えはYesです。

（補足）

ここからはかなり蛇足感がわたしにはあるので読まないことをおすすめします。

スクラムマスターがスクラムマスター足り得ているかを問うとき、立ち返るのはスクラムガイドです。

スクラムガイドのスクラムマスターの活動に例えばこういうのがあります

効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。

スクラムマスターがこれができているかできていないかを考えるとき、いきなりさぁできているかな？どうかな？ってできなくないですか？

スクラムをまわそうとしている人なら当然、タスクを進める前に、Readyの定義を作って、Doneの定義を作って、プランニングして、活動して、ふりかえりをしてむきなおるわけですよね。

同じことを例えば上の問いに当てはめてみたらどうでしょう。

効果的ってどういう状態なのかを「たぶんこんな状態」というゴールを設定して、今の自分たちの位置を把握して、どうやってゴールに向かうかプランニングして、そのために活動をしてみて、立ち止まりふりかえって、ゴールに正しく近づいていなければむきなおって、もう一度進み直すのではないでしょうか。

つまり、「スクラムマスターの活動をやる」のではなく、「スクラムマスターの活動をやること」に「スクラムを適用」しなければ「スクラムマスターやれている」とはならないよねってことです。

会社や組織は定量的な結果指標を欲しがるので、ベロシティが何倍になったとか、そういうことがスクラムマスターの成果、効果だと言わせたがる節はあります。

が、本質は3つの柱と5つの価値基準の実現と実践にこそ宿るものです。

最後に、今回の文章をチームだけでなく、組織（組織運営）なり企業（経営）なりに置き換えてみて読んでみることをおすすめします。

スクラム（アジャイル）な組織運営の〜、スクラム（アジャイル）な経営の〜...はてさて。

生配信イベントを実現する裏側の話

この記事は、レッドジャーニーのアドベントカレンダーの19日目として書いています。

adventar.org

昨日は、弊社の中村洋さんが効果的な会議のために取り組んでいる3つのことという記事を書いていました。とてもよいTipsですね。

背景

さて、一昨日のAgileJapanEXPO Advent Calendar 2022の17日目の記事として、Agile Japan 2022の表と裏の話というお話をしました。

blog.samuraikatamaris.red

わたしとしてはレッドジャーニーという会社としてのガチ生配信イベントは実はすでに今年3回目（子どものYouTube活動でゲーム実況とか前職で配信とかいろいろしてますが）でして、さくっと↑のような配信もできています。

1〜2回目は、レッドジャーニー主催のカンファレンス、Red Conferenceが3月と4月にありました。

こちらのイベントは、『日本の組織をRe Designする、をテーマに様々な業種のクライアント企業さまにDXの取り組みを発表していただく』という活動でした。

詳細は、下記にレポートが多数上がっていますので、よろしければみてみてください。

redjourney.jp

今日はそんなオンライン生配信をどのように行っているかについてお話したいと思います。

配信の構成

基本、今のイベントはオンラインで行うことを前提としているので、登壇者やスタッフがロケーションもばらばら、それぞれの場所から参加して配信が構成されています。

下記は4月のRed Conferenceのときの一例です。

基本的には、わたしの家が配信の中心となり、Zoomのネットワークを通して濱口くんがZoomのホストとして画面制御や動画再生を担当、市谷さんや各社の登壇者はZoom1内に接続して順次登壇、わたしがZoom1の情報をYouTube Liveに流す、という形をとっています。

また、基本的にはZoom1の中でも、ブレイクアウトルームを設けており、本番環境としてはブレイクアウトルームを利用、配信中に途中で誰かがZoom1に入ってきてしまっても、まずはメインルームに行くようにして事故を防いでいました（ちょっと上の図のコメントと違っているけどそうしています）。

また、配信にあたっては、Sli.doというサービスを使って質疑応答をしていたので、そこはこのネットワークの外でメンバーが行いました。

配信環境（Red Conference）

生配信って大変じゃないの？カンファレンスってプロのイベンターとかいるんじゃないの？って思う人もいると思います。

ただ、わたしたちは完全に個人で、しかもほぼ私の部屋一つで配信しています。

まずは環境の写真をみてくださいませ。

まぁこんな感じ＋スマホを使った構成で我が家からは配信しています。

①メイン端末。RealPlayer経由でマイク音声を取り込んでスイッチャーに流しています。当日の司会進行などをわたしが行っているものです。上図でいうMC端末。

②サブモニター1。こちらに司会で使うスクリプトなどを表示しています。

③サブモニター2。こちらに内部連携用のDiscordなどを表示しています。

④スイッチャーモニター。配信切り替えの制御に使っています。

⑤サブ端末1。こちらでスイッチャー制御とYouTube Liveの配信状況管理をしています。上図でいうSW制御PC端末。

⑥サブ端末2。これが配信用のZoomクライアントの親玉。上図でいう配信用PC端末。

⑦サブ端末3。配信の前後やイベントに関する説明などの資料投影用に使っているスライド投影PC。

⑧iPad。わたしのZoom1内状況確認用端末。上図でいうMCの状況確認用端末。Zoom1にはわたしの声は基本的には流れないので天の声が聞けたときはこちらから流れていますw

⑨スイッチャー。画面へのヘッダ・フッタ加工などや画面切り替えを行うもの。ATEM Mini Pro。

これにプラスして、スマホでYouTube Liveの配信確認をおこなっています。

ちなみに、YouTube Live向けのマイクはamazonのセールで買った安物のコンデンサマイク。

Zoom1内向けのマイクはAftershockzのOpenCom。

カメラはVLOG用カメラでおなじみSONYのZV-1。

ね、そんなたいしたことないでしょう？w

一応これだけあればとりあえず必要な情報は全部揃えられるし、ひとしきり一人で環境の制御ができます。

配信環境（裏あじゃぱん）

裏あじゃぱんは実はもっと楽でした。

ディスプレイにウルトラワイドを導入したので、今までメイン端末に2画面の外付けにしていたものを、1画面にできています。

裏あじゃぱんでは説明スライドが必要なく、司会もZoom1内に入り込んでしまって本当にただそれをヘッダ・フッタつけてYouTube Liveに垂れ流すだけでよかったので、iPadやスライド投影用PCを省き、配信前後の表示はスイッチャーに任せる構成をとったため至ってシンプルです。

また、カメラをZV-1からLUMINAに変更、マイクスタンドをいわゆる音楽スタジオにあるものからフレキシブルアームの机に固定できるものに変更したため広く感じますね（毎度突貫でこの構成をつくるので配線がごちゃごちゃするのはご容赦）。

まとめ

もう何をいっているのかわからない人もたくさんいると思いますが、別にそんなに頑張らなくても生配信ってのは簡単にできるんですよってことを伝えたかったのでしたw

で、気にしたほうが良いポイントは、ここで説明した構成では実は無いんです。

ポイントは2つ。

まず、演者に立つなら正面からの照明は絶対に用意したほうがいいです。

もう一つは、ネットワーク。生配信を行うためだけに、この書斎にもハブを設置してスマホ以外のPCやiPad系は全部有線LAN化しました（それまでは日々の仕事用に1本だけ有線を出していた）。

今後のことを考えたほうがいいとすれば、すべてが我が家に集中するのでシングルポイントしかない、ということですね。

また2023年もいろいろやっていくと思いますが、すこしずつ進化させていければと思っています。

それでは2023年も配信イベントをお楽しみに！

Agile Japan 2022の表と裏の話

この記事はAgileJapanEXPO Advent Calendar 2022の17日目の記事として書いています。

adventar.org

表のアジャイルジャパン

Agile Japan 2022が11月15日、16日に行われましたが、わたしの所属するレッドジャーニーもゴールドスポンサーをしていました。

そういうこともあり、わたしもスポンサーとして、一参加者として、Day0からDay2までを楽しませてもらいました。

スポンサーの役割

Agile Japan EXPOが主催するイベントとしては、このAgile Japan（以下あじゃぱん）とAgile Tech EXPO（以下あじゃてく）の大きく2つがあります。

かつてmedibaにいた頃は、あじゃてくの方でスポンサードさせてもらっていました。

当時からオンラインでのスポンサーのあり方について、ということで運営さんにいろいろ提案をして、隙間時間にミニセミナーをスポンサーチャンネルで開催して登壇者の露出を増やすことに貢献したり、イベントの前から定期的な投稿でDiscordやTwitterなどを通して盛り上げる活動をしたりしてきました。

そういう意味ではわたし自身はこのあたりの活動のパイオニア的な存在だと自負しています。

詳細は過去に書いているこちらをご覧ください。

blog.samuraikatamaris.red

当然、スポンサーはスポンサー登壇枠を埋めればよいとは考えておらず、イベントを一緒に盛り上げて成功させて初めてスポンサー活動になると考えます。

つまり、以下の3つが大事なポイントです。

• 集客への貢献
• 参加者の期待の喚起
• 良質なコンテンツの提供

あじゃぱんでやったこと

今回、あじゃぱんでも同じようにいろいろと考えましたが、あじゃてくとはイベントの開催フォーマット（タイムテーブルとか）、規模の大きさ、参加者の客層などが違い、かつてのあじゃてくでうまくいったミニセミナーの形式は正直難しいと考えていました。

そこで今回のあじゃぱんスポンサーでは、実は裏アジャイルジャパンという設定で、レッドジャーニー主催Agile Japan併催イベント（以下裏あじゃぱん）、というものをあじゃぱんと同日同時刻に開催していました。

そして、あじゃぱん本体のスポンサーミニセミナーの時間枠にはこの裏あじゃぱんでのイベントをYouTube LiveとDiscordを通して同時生配信したのです。

もちろん、これについては事前に運営さんに相談、許可を得た上で行っています。

イベント詳細はこちら。

redjourney.doorkeeper.jp

こんなことをやるスポンサーもほかにはいないのではないでしょうかw

今回裏あじゃぱんを開催した理由はいくつかあります。

 

集客への貢献

この資料自体は当初いろいろとあじゃぱんでのスポンサーのあり方について社内で若者とディスカッションしていたときに書いていたものなのでラフですみません。

今回の裏あじゃぱんは、この図でいう「通常イベント」のことです。

わたしたちは比較的こじんまりとした会社イベントの開催を頻繁に行っており、通常zoomで行っています。

簡単に言うと、こちらの通常イベントに参加してくれるのはレッドジャーニーという会社自体や会社の取り組み、あるいは社員の誰かに興味を持ってくださっている方です。そして、それは必ずしもあじゃぱんを知っている、あるいはあじゃぱんに興味がある人ではないということです。

そこで私たちは、裏あじゃぱんをあじゃぱんのオフィシャルな併催イベントとすることで、あじゃぱんの周知に貢献し、Doorkeeperなどから出すお知らせなどにもあじゃぱんのアピールや参加登録を促してきました。

結果的にどれくらい効果があったかは捕捉できないですが、少なくともイベントにあわせてあじゃぱんを周知するには、企業のお知らせやスポンサー告知だけでなく、広くユーザー個人個人に届ける活動として集客貢献できたのではないかと思います。

余談ですが、この2つのイベントを同時に成立させることについて、社内では「福山雅治、横浜アリーナから紅白生出演」というメタファで会話していましたwww

参加者の期待の喚起

この裏あじゃぱんには、セッションを4つ用意しており、それぞれがあじゃぱんで登壇してもおかしくないくらい、素晴らしい事例を発表してくださる企業や行政の方を揃えました。

それもあり、事前にTwitterやLinkedIn、Facebookといった媒体を使って期待を煽るようなコンテンツのお知らせを流しましたし、すでに参加登録されてDiscordにいらっしゃる方々に向けてもお祭りを楽しみましょうという意味合いで喚起できたと思います。

【アジャイルジャパン併催】レッドジャーニーセミナー
セッション情報解禁①‼️
パーソルホールディングス株式会社様による「変化に強い組織になるために、パーソルホールディングスのIT組織で取り組んでいる「アジャイル組織運営」とは 」です。#redjourney #agilejapan https://t.co/lkJFfd96e5 pic.twitter.com/sdRRtaCbiP

— RedJourney (@RedJourney_Inc) 2022年11月11日

良質なコンテンツの提供

スポンサーセッション枠としては、弊社代表の市谷が「組織を芯からアジャイルにする」話をしたのでこちらは鉄板ですし、先程も記載したような裏あじゃぱんも本家のあじゃぱんに負けないようなラインナップと内容を準備したつもりです。

redjourney.jp

多分、多くを語るよりもこちらをご覧いただいたほうが早いのでぜひ当日の動画をみてみてください。

www.youtube.com

www.youtube.com

www.youtube.com

www.youtube.com

ちなみに、zoomで開催している通常イベント側とあじゃぱんのスポンサーミニセミナーセッション向けにYouTube LiveやDiscordに流している画面は、実はヘッダ・フッタを変えていたり、ちゃんとこだわりを持ってやりましたw

感想など

相変わらずオンラインでのスポンサー活動というのはまだまだ試行錯誤で難しいことばかりだなというのは2〜3年たっても変わらない印象です。

ただ、カンファレンス当日だけでなく、ストック型コンテンツが大切になってきているとも思いますし、当日以外にコンテンツを楽しもうとする人も圧倒的に増えていると思います。

そういう意味では、今回上のように、わたしたちもアーカイブとして動画としてコンテンツを提供することができ、繰り返し好きな時に観ていただけているので、わたしたちの真新しい取り組みも成功したといえるのではないかなと思っています。

これからも既存の概念や制約にとらわれず、新しいやりかた、あり方を模索しながらスポンサー活動や各種イベントなどやっていければと思います。