今年もよろしくお願いしますw
いやはや年末年始から家族で体調不良が続いており、松の内もほぼ家を出ないままでした。
私も1月前半はすべての会食等をスキップさせてもらう感じでご心配おかけしてすみません。
さて、話は変わりますが、1/10〜12に行われたRSGT2024に向けて準備していた電子書籍が無事に発刊できました（1/10の朝06:40に校正し直しとかしてたけどw）。
現時点ではゼロ円に設定していますので、フリーに読んでいただければ幸いです。
感想などXやコメントなどいただければ嬉しいです！！
レッドジャーニーのメンバーを独断と偏見で紹介してみる
この記事はレッドジャーニーのアドベントカレンダー25日目として書いています。
昨日のぺこーらにならって、「メリークリスマス！！」からはじめますw
背景
アドベントカレンダーを単発で見ている人にはそれぞれメンバー個別には認識をしてもらえているかもしれないなーとは思うのですが、よくよく考えると我々が何者なのかがまとまって伝わっていないのではないか、ということに気づいてしまったのでした。
きっかけは、12/9の田中くんの「今はただ 君に感謝を」を読んだことにあります。
なので、今日はクリスマスらしく？独断と偏見でメンバーの紹介をしていこうと思います。
メンバー紹介
市谷聡啓
言わずともしれた弊社の代表。
元政府CIO補佐官であったり、『正しいものを正しくつくる』、『デジタルトランスフォーメーション・ジャーニー』、『これまでの仕事これからの仕事』などなどの書籍を多数執筆している人。
仮説検証を語らせたら右に出るものはいない...かもしれない（可能性はゼロじゃないという程度の話）。
仕事が服を着ている、という表現がものすごくしっくりくるほどの働き者なのだけれど、それはその先に見据えている「日本を再定義するんだ！」という強い信念に裏打ちされている気がする。
気になることはものすごく気になってしまうし、興味をなくすのも早いと思うけど、その選択と集中が常人レベルではないところが魔性な魅力なのでしょう。
食べ物や宿にはなんだかんだうるさいので、合宿などのときにはよくよく意向を汲んであげると機嫌がいいですw
あと実物は背が高い。
新井剛
ヴァル研究所の新井さん、という認知はもうだいぶ薄くなったかしら。
開発現場だけでなく、全社をカンバンなどで見える化をして、多数の見学者が殺到したヴァル研究所ツアーのきっかけを作った人。
『カイゼン・ジャーニー』や『ここはウォーターフォール市、アジャイル町』などの著者でもある。
物腰穏やかで、でも大切なことははっきり言うところが「レッドジャーニーのおかん」というポジションを確立しているのでしょう。
多分...そんな「おかん」なところは仕事の中でも芸風としてあらわれていて、それがときに「センセイ」のようであったり、「コーチ」のようであったり、「家族」のようであったり、あらゆるロールになって人々に寄り添う姿に全人類が感動しているはず。
朝起きるのが早いおじさん1号。
中村洋
市谷と中村は盟友である、という風に捉えている人はそれなりに多そう。なんかずっと隣にいるイメージ。
「The・アジャイルコーチ」という言葉が彼を表現するには一番正しいのではないかと思う。
本をよく読み、サイトを徘徊して、インプットの量はレッドジャーニー内でも1〜2を争うのではないかな。
現場を愛しているので、ずんずん現場に入っていってばっさばっさと立ち回るスタイルが全国で人気...なのでは。
むっちゃ引き出しがあるので、スクラムやアジャイルを現場で困ったり悩んだりしたらとりあえず洋さんに聞いてみるとよさそう。
朝起きるのが早いおじさん2号。
濱口知也
市谷さんに傾倒して、会社辞めて来ちゃいましたみたいな人だったと記憶している（が、間違っていても謝りません。ごめんなさい）。
多分、レッドジャーニーでは一番エンジニアリングから遠い世界の住人（みんななんかしらエンジニアの道を通ってきた人ばかり）。本人もちょっと気にしてる。
プロダクト開発や仮説検証の話になると目をキラキラさせて少女漫画の主人公のようになる純朴なところが人々に愛されるポイントなのではないかと思う。
一時期はnoteにもらうLikeをXX個集める！みたいなことを言っていた気がするけれど、最近のアウトプットは...常夏のビーチのような穏やかさと認識しています。
トランペットやらオーケストラやら多才なんだけど、とりあえず合宿中も毎日スプラトゥーンは欠かさないマメな日本男児。
田中基淳
満を持して...レッドジャーニーで一番まともにエンジニアができる人（僕は最前線のエンジニアリングはもう忘れたよ、パトラッシュ...）。
最近はものづくりからことづくりに少しずつスキルの幅を広げているのかなと勝手に感じている。
実はとてもストイックで真面目な上にセンスがいいので、イケメン過ぎて世界中の嫉妬をかってしまう罪深いところがある。
なんでも恐れず飛び込むことができるので、すぐに誰かに巻き込まれていく巻き込まれスキルのレベルが異常に高い。が、最近は巻き込まれることで自分の強みを増やしているようにも見えるので、もしかしたらスキルではなく単なるあざとさなのかもしれない、と思わせる罪深いイケメン。
瀨川晋平
レッドジャーニー唯一の陽キャ属性。
「はじめまして」の直後にはグループの輪に普通に入っていて、もうどこにいるのか見つからなくなるくらい馴染み力が高すぎる。
人との付き合いが上手で、どんな話を振っても自身のネタ話をちゃんと返してくる。もはやネタのために普段から生きているのではないか、と鎌倉近郊で噂されているとかいないとか。
ちなみに、彼はまだ一度も鎌倉のオフィスに出社したことはないはず。
サウナでテニスをするくらいサウナとテニスが好きなんだと思うのだけど、一緒にサウナもテニスもしたことないから真偽の程は不明。
現場の場数を踏むことで、スーパーアジャイルコーチに進化する可能性を秘めている全人類のうちの一人。
森實繁樹（私）
世界から社会的に自分の肉体を消し去りたい（死にたいといっているわけではないw）願望を持っているだいぶ変わった人。
メンバーのそれぞれの特性、スキル、能力の尖ったところには常に一歩足りないけれど、逆におそらくすべてのメンバーのサポートをできるレッドジャーニーのスーパーサブ、とどこかでは言われているかもしれない。
背の高さも市谷さんに次いで二番目。
かつては音楽系芸人としてアジャイル界隈に旋風を巻き起こしたことがあるとかないとか。最近の興味は地方創生と中小企業らしい。
寂しいと死んじゃううさぎさんと本人は自分を表現するが、飲みに誘うと十中八九断られるというメンヘラな一面をもつ。
まとめ
とりあえず盛った表現はなかったはずなので、こんな素敵なレッドジャーニーのメンバーに少しでも興味関心がわいてもらえたら幸いです。
2024年もレッドジャーニーを宜しくお願いいたします。
それにしてもみなさんそろそろアー写取り直した方がいいですよw
【2023年版】アバター生活ふりかえり
昨年、アドベントカレンダーネタとしてアバター生活についての記事を書いていたのですが、1年でだいぶ状況が変わったので2023年版を起こしていこうかなと思います。
ちなみに、なんのアドカレの記事でもありませんw
ちなみに、昨年の記事はこれ。
アイコンとアバターの変更
今年大きく変わったことが一つあって、ブログのアイコンもそうですが、かつてのお仕事仲間のデザイナーさんにアイコンとアバターを発注しちゃいましたw
それが、これです。
あらかわいいwww
昨年まではアイコンを用意していなかったのと、アバターはVRoidHubから拝借したオリジナルではないアバターを使っていたので、ここが大きな違いです。
リアタイボイチェンは完全に廃止
結局いろいろ試した結果、まぁ声はそのままでもいいかなというのが僕の結論になったので、今後も当面はボイチェンが導入されることはないと思います。
アバターの2D化
これについては狙ったわけではないんですが、モデラーさんの都合とかいろいろあった関係で、VRM（3D）のモデルからLive2Dのモデルに今のところなっています。
そのため、いろいろ試行錯誤を経て、VRMを動かす環境としてWebcamMotionCaptureという素晴らしいツールに出会ったのですが、いったん凍結です（でもマジでおすすめ）。
Live2Dなので、現在はAnimazeを使っています。
個人的にはやっぱり手や指が自由に動かせるのはいいなぁと思うので、ちょっと2Dで使ってみて、どこかで3D化をはかる可能性はありますねー。
一応、2Dでも全身作ってもらってはいます。
参考画像
↑星街すいせいさんの画像の横に並べてみたけどおもったよりしっくりきました（推しとのツーショットに涎が出そうです）www
※クロマキーが雑なのはすみません、時間がなかっただけなのでご容赦ください。。。
2024年の展望
2022年の段階では、アバター生活1年やったらオリジナルのモデルを作りたくなるかなと思っていましたが、オリジナルモデルで1年やったらどうなるんでしょうねー。
やっぱり3Dに戻したくなっちゃうのかなぁ。
ソフトウェア的な開拓もそれなりにしまくったので、今は環境的に安定もしているし、そんなに大きな変更はないのではないかなと思います。
が、あまり僕の言うことはあてにならないので、また来年なんか書いていたら笑って読んでくださいw
おまけ
今回、実は先にできていたのは子どものYouTubeやらInstagramやらのアカウント用のアイコンでした。
もちろん同じデザイナーさんにお願いしています（僕が彼女のデザインが好きなので個別にお願いして描いてもらっています）。
ということで、こちらのキャラを使ってYouTubeのOPも作り直しています。
なかなかいい感じですよねー。
プロダクト開発の合言葉は『横に並べて縦に切る』
この記事はレッドジャーニーのアドベントカレンダー18日目として書いています。
昨日はぺこーら（←という呼び名を本人は強く否定しているようだがw）がチームに頼る頼られる話をしていますね。馴れ合いではなく補完の関係になれるといいですね！
- プロダクト開発のフレームはたくさんある
- Step1：As-Isカスタマージャーニーマップ
- Step2：To-Beカスタマージャーニーマップ
- Step3：エピックロードマップ
- Step4：ユーザーストーリー
- Step5：プロダクトバックログ
- Step6：スプリントバックログ
- まとめ
プロダクト開発のフレームはたくさんある
プロダクト開発をしているみなさん、お疲れ様です。
プロダクト開発をしているみなさんは、いろいろな書籍でそれこそたくさんのフレームをご存知だと思います。
しかし、それぞれのフレームをどう相関させて、実際の開発や検証にまでつなげていくのかを一気通貫に書いてあるものはあまり見かけません。
そこで、今回はそういった各種のフレームをつなぎ合わせ、どういう風に活用するのがいいのか、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）
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日目として書いています。
昨日は、ぺこーらによるチームの割れ窓理論の話でした。こういうのもなんだか慣れがもたらす症状として言われると気がつくものですよね。
はじめに
予防型プロジェクトマネジメントと聞くとどんなことを想像するでしょうか。
対義語で捉えると、事後対応型プロジェクトマネジメントということになると思います。
こうやって言われると一般的なプロジェクトマネジメントって事後対応型のマネジメントが多いと思いませんか？
課題管理、リスケジューリング。。。etc
いったん立ち止まって一緒にプロジェクトマネジメントを考えてみましょう。
最高のマネジメントに事後はない
予防型と事後対応型だったらどちらが安心できるマネジメントスタイルだと思いますか？
もちろん、起きたことをいかに素早く消火できるか、というのも一つのマネジメントです。しかし、もしそもそも火が起きなければ、その必要もなくなります。
つまり、最高のマネジメントの状態とは、火が起きる前に対応し、事後に行うことがない状態なのです。
プロジェクト計画ではなくプロジェクト運営計画を
では、予防型にできるか否かはどこから始まっているのか。
それは、プロジェクト計画をたてたときには既に始まっています。
プロジェクト計画を立てるときに検討する事項の大筋はおそらくプロジェクト計画書というものに準じて考えられていると思います。この"準じて"、というところが厄介で、本来プロジェクトは世の中に一つとして同じものはないのだから必ずゼロから考えて書きましょうとなっているはずです。しかし、だいたいのプロジェクトは、かつてのプロジェクト計画書のなにがしかを流用し、変更があるところだけ書き換える、みたいな運用をしてしまっているのが現実です。
別に、結果的なところを追いかけたい、達成したいゴールやドキュメントを羅列するだけでよいのであれば、個人的には（魂なんてこもっていないですが）それでも構わないと思っています。
しかし、それはあくまでもプロジェクトの結果指標を追いかけた計画（すなわち、デリバリーにあわせて線表を引いているだけ、課題が出たらこう管理すると定義しているだけ等）であり、これを書いたからプロジェクトがうまくいきそうかいかなそうかというのは全く読めません。
プロジェクト計画の中で考えたいのは、そういうプロジェクトの特性や特徴を鑑み、状況や状態に応じて何をどうやっていくことで安定をもたらすのか、です。
実態、チームとして朝会やりましょうか、はだいたいが計画当初から盛り込まれているよりは現場の温度感で始まるケースも多いと思います。
そういうことを、ケースとして見越しておく、あるいはチームに提案していく弾をいくつも想定しておくことをプロジェクト運営計画と私は呼んでいます。
私と一緒に仕事をしたことがある人であれば、「常にプランBを備えておく」という言葉は耳にタコができるくらい聞かされていることでしょう（実際にはCやDまで考えておかなくていいんですか？ということはよく言っています）。
課題管理より始めよ
私が気になっている最たるものが、課題管理及び課題管理表です。
課題管理表をみてみると、項目に「発生日」「課題内容」「対応内容」「担当者」「完了日」などが並んでいると思います。
普段はあんまり気にしていないと思いますが、これってすごく不思議ですよね。「発生日」がトリガーとなっている、すなわち事後対応型のマネジメントドキュメントになっていると思いませんか？（もちろん気がついている人はうまく活用していると思いますが）
では、まだ発生はしていないが後々課題になるかも、みたいなものはどう管理するのでしょう？
一般的には未来課題を書くのがリスク管理及びリスク管理表と言われます。しかし、リスク管理表の主な使い方は、QCDSに影響が出そうとか、クライアントや提供元とのネゴシエーションがうまくいかなかったらとかそういうレベル感のもので、プロジェクトへの影響度が高いものだけが管理されていませんか？
プロジェクトのほとんどは現場で行われていて、課題も現場で発生します。
そういった現場課題に対して、「常にプランBを備えておく」、すなわち予防型の課題管理はどうするべきでしょうか。
私の答えとしては簡単で、「対処開始予定日」という項目をいれることで解決できると考えます。
今までは「発生日」が基準でしたが、プランBを考えたほうがよさそうなことが見えた瞬間には、課題管理表に記載、事前対処が必要となるであろう「対処開始予定日」を予め埋めておきます（それもかなり悲観的に）。
そうすると、プランBを事前に動かしたほうが良さそうだというタイミングを逃しませんし、プランBを選択しないためにやっておいたほうがよいこともタスク化しやすくなります。
この場合、「発生日」は「記入日」レベルに変えて解釈する、あるいは変えてしまう方があとでふりかえったときに、いつ頃にはこの課題に手を打てていたっけということを確認することもできます。
はじめの一歩
ここまでは割とやり方の話を中心にしているので、じゃぁそれをどうやって運用すればいいんだよというのはあると思います。
今までそこまですべての営みにプランBを考えてきていない人たちには、そのプランBをいつ、何について考えておけばいいのか、というほうが難しいでしょう。
そこで、今日からできるはじめの一歩です。
チームのメンバーに朝会でも週次の進捗確認でもなんでもいいので、こう聞いてみてください。
「今日明日（あるいは今週来週）で起きたらいやだなーってことありますか？」
これがプランBを用意しておくべき種、すなわち予防型プロジェクトマネジメントの始まりにできます。
明日もお楽しみに！
ユーザーは会議室にいるんじゃない！現場にいるんだ！
この記事はレッドジャーニーのアドベントカレンダー4日目として書いています。
昨日は弊社のぺこーらが書いていますが、内容もさることながら最後に宣伝を忘れないというところが私と違ってさすがとしかいいようがありませんw
ユーザーはプロじゃない
もう15年くらい感じているプロダクト開発の現場における状況って未だに変わっていないなと思うことがあります（たぶん世界はもっと変わっていない）。
15年前（本当はもう少し前）といえば、私自身は某保険会社の立ち上げのプロジェクトに参画していました。
当然ながら当時の私のようなSIerのもつ保険業務知識やそもそもの保険に関する知識も事業会社である保険会社さんの人たちには到底及ぶわけはありません。
ただ、その頃から感じていたのは、この人たちはものすごく頭も良いし、業界や商品のことを本当にわかってらっしゃるということ。の反面、ユーザーはそんな商品知識や保険料の成り立ちについてわかっているわけではないので伝わるのかしら？という疑問でした。
あれから15年たち、最近はたくさんの業界の方とお仕事をしていますが、やはり同じような気持ちを感じるシーンがありました。
当然商品やサービス、プロダクトはプロである人たちが細部まで作り込んで考えることはとても素晴らしいことだと思いますが、ユーザーの大半はプロではないということを念頭に置くことは非常に大事なことです。
プロも道を外れればプロじゃない
事業会社の人はその道のプロかもしれませんが、例えばそれを売るとか、それを認知させるとかのマーケティングのプロかというとそうではないことは往々にしてあります。
先日もとても素晴らしいプロダクトの構想をもつクライアントさんとお仕事をしました。それはWebサービスで、比較的富裕層や年齢層の高い人向けのサービスを想定したものでした。
ある日、とある7人ほどが集まったミーティングで、
「で、これはどうやってユーザーにアプローチするのですか？」
という質問をしてみたのですが、返ってきた答えは、
「WebサービスだからXやインスタで広告流したり拡散してもらえばいいんじゃないですかね？」
でした。
私もすかさず打ち返します。
「ほほう、では皆さんのような年齢層の高い人がターゲットなので皆さんもターゲットに含まれると思いますが、この中でXを日常的に見たり拡散している人はどれくらいいますか？」
「。。。」
「だとするとなかなか難しそうですね。。。」
というやりとりがありました。
結局この件は、ターゲットを絞りに絞って検証するという意味でアプローチをし、最終的にはポスティングが一番効果があった、みたいなやりとりで一旦幕を引きました。
ユーザーは会議室にいない
会議室で仮説を考えたり、結果を吟味することはとても大切なプロセスです。
そして、自分たちが議論しているのが仮説なのか、事実なのかを切り分けることはその一番最初のプロセスになります。
得てして、自分たちはドメインのプロであるが故に、あるいは日常の何気ない"普通"にとらわれて、バイアスをかけてしまうことはよくあることです。
このバイアスに囚われているかもしれない、ということを疑うことは批判的な行動ではなく建設的な行動であるという共通理解をもちたいですね。
そして、事実に至っていない仮説の検証はユーザーに対して行う必要があるということになります。
別に「餅は餅屋」とは思っていない
一応誤解なきようお伝えしておくと、今回の事例のケースにおいて、マーケティングはプロじゃないんだからマーケティングのプロに任せたほうがよい、と言いたいわけではありません。
私たちは暗黙に、車は移動するもの、若者はインスタを使うもの、鉛筆は書くもの、という意識をもってしまう生き物であるがゆえに、車を個室と捉えるとか、鉛筆を束ねて折れにくい棒として使おうとか、あまり考えなくなってしまう生き物です。
そういう意味では、子どもたちのほうが柔軟に手元にあるもので自由な発想でカラフルなレゴを組み立てて恐竜を作ってみたり、ペットボトルを使ってロケットの工作をしてみたりしていませんか？
ユーザーというのはある種突拍子もないことをする人たちで、自分たちのはるか斜め上の使い方や行動をとる生き物だと思っておくのがいいのだと思います。
結局、ユーザーは普通こうやって使うでしょ、は某氏の「それはあなたの感想ですよね」と同じではないでしょうか。
仮説と事実にしっかり線を引き、本当のユーザー行動、ユーザーインサイトを手に入れる活動をできるかどうかが大事なのですよ、ということをお伝えしたかったのでした。
その上で、必要なら餅屋に頼んでみることをオススメします。
ということでしっかり読んでもらうとタイトルがただ言いたかっただけじゃん！と言われそうなくらい中身とずれましたがご容赦くださいw
明日は「はまぐちともやの落とし穴シリーズ」でおなじみの濱口くんの素敵なお話が聞けることでしょう！w
お楽しみに！
アジャイルはなにをするのか、なにを繰り返すのか
この記事はレッドジャーニーのアドベントカレンダー2日目として書いています。
はてさて、今年も気づいたら12月が来ていて、気づいたらアドベントカレンダー2日目が私ではないですか。。。
昨日は、田中くんがアジャパンのことを書いていますのでぜひよんであげてください！
前説
アジャイルの世界が日本に馴染み始めて早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
スクラムやってる？
みなさんの中でアジャイルの取り組み、主にスクラムを実践されている方は多いと思います。
スクラムをやる、ということについては、以前私のブログでも紹介しましたが、「スクラムのスクラムにスクラムをスクラムしないスクラムはスクラムではない？」というお話を読んでもらえると嬉しいです。
ところで、スクラムってスプリントというタイムボックスを使って運営していきますよね。その中には、いろいろなチームとしての活動があると思います。
もちろん、セレモニーやイベントと呼ばれる活動もそうです。
そんなスクラムの活動について少し考えていきたいと思います。
スクラムイベントとは
スクラムイベントとは「スプリント」「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ（ふりかえり）」の5つからなります。
スプリントプランニング
スプリントをまわす、という視点に立ったとき、一番最初に思いつくのはスプリントプランニングではないでしょうか。
スプリントプランニングでは、スプリント内で実現するスプリントゴールを掲げ、スプリント内で行うタスクをバックログとして抽出する活動です。
アジャイルは計画なしにやってみるのではなく、計画をたてて、計画を検証しながら前に進んでいくアプローチです。
そういう意味では、以前も書きましたが、スクラムやアジャイルのアクティビティのうち、いちばん大切なものはプランニングであると言えます。
デイリースクラム
通称「朝会」などと呼ばれることも多いですが、日次というタイムボックスにおける検査行為です。検査の対象はタスクボード上のものだけでなく、メンバーの状況やチームの状態などを確認する場所でもあります。
スプリントレビュー
スプリントレビューはスプリントで作成されたインクリメント（成果物）をステークホルダーにレビューしてもらい、フィードバックをもらう場です。通常はプロダクトオーナーが説明するものですが、現場によっては開発メンバーが説明している場面もよく見かけます。
一番気をつけたほうがいいのは、プロダクトオーナーへの初見レビューにする場にするものではない、というところですね。
スプリントレトロスペクティブ
こちらも通称「ふりかえり」などと呼ばれることも多いですが、スプリントの活動を通して学んだことを次に活かすために大切な活動です。
スクラム運営の質を上げていくためには、スプリントレトロスペクティブは欠かすことはできません。
スプリント
スプリントはもうそのままスプリントそのもの、想像を創造にかえることです。
上記4つのアクティビティはこのスプリントの中で実行されるもの、という位置づけになっています。
ここまで読んでみると、スプリントを円滑にまわすために今のスプリントにフォーカスしている成分が多めだなーということがよく分かると思います。
ちょろっとあるとすると、スプリントレトロスペクティブが先のスプリントの行動や計画に影響を与える要素があるかなーくらいですかね。
これはこれでとても大事なことです。
スプリントをまわすためにスプリント以外のことを考える
では、スプリントをまわすためにスプリントのことだけを考えていればよいのかというと、そうではありません。
スクラムイベントには含まれていませんが、プロダクトバックログリファインメントという大切な行為が必要です。
これは、今のスプリントや次のスプリントに閉じるのではなく、先々のスプリントをどんなふうに乗り越えていき、目指すべき山（ゴール）に到達できるのかを予測、プランニングする行為です。
じつはこのプロダクトバックログリファインメントが非常に難しいのですね。
あまり先のことすぎると、そこまで詳細化する意味ある？という会話に当然なりますし、次のスプリントのことしか深く考えないとすると、これは本当に山にのぼり切れるのか？ということになります。
このあたりのテクニックとして、よく私がつかうのが、スプリントを3つ先まで粒度を変えてプロダクトバックログリファインメントのゴールとして扱う、です。
こうすることで、例えば3スプリント先で着手しそうなものについて、調査や調整が必要だということで予めわかっているのであれば、そこまでの2スプリントの間になにかしらのタスク化をして準備することができます。
さぁはじめましょう！といってスプリントプランニングを始めるには、Readyとなれない事が多いのです。
よって、はじまらないものはおわらないことになり、山が全然近づいてこない、ということになります。最悪なのは、とりあえず突入して大炎上しながら駆け抜けることになるいわゆるデスマーチへの進行ですね。
これはあくまで、私がスプリントの開始条件を整えるためのアプローチの一例として、上記のようなゴール設定をしてみた、というお話です。
みなさんは、みなさんのチームで、どういう粒度でゴール設定をしておくとよいかについて考えてみるとよいのかもしれません。
まとめ
スクラムを始めたばかりの人、スクラムマスター初心者だったりすると、まずはスクラムをまわすんだ、ということにフォーカスして頑張りすぎる場面をよくみかけます。
でも、スクラムをまわすということは、その先まで見据えた3歩先まではせめて見据えてまわさないと、迷子になる可能性が高まります。
こういったテクニックについても、みなさんのスプリントをとおして、フィードバックを得ながら自分たちのものにしていくことをオススメします。
保険xアジャイルコミュニティをやっています
なんとなく気持ちが筆を運ぶときだけ書いています、れっどですw
7月は結構外出や移動、休日のお仕事なんかも多くて一年で一番忙しかった反動か、8月頭にコロナにかかりました。。。
そこから40度超え4日、2週間近くたつ今でも体力が戻ってこないでくらくらしている今日このごろです。。。
さて、2019年7月に保険xアジャイルコミュニティ『.insurance』を立ち上げてから早4年が経過し、5年目に突入しました。
もちろん2019年はコロナ前なので基本的に活動はオフラインでしたが、2020年以降、オンラインでの活動にシフト。。。がうまく波に乗れず、一度フェードアウトしてしまったんですよね。
2022年あたりからもう一度エンジンを掛け直して、オンライン開催且つ運営が無理をしないペースでやろうということで、たらたらやってます。
昨日も今年3回目の活動をしていました。
今は活動拠点をdiscord上に移し、作業場はmiroを使い、Facebookもプライベートグループにしているので、ほぼ外からは姿が見えないところでやっています。
※一応Peatixで参加者管理はしていますが、discord内で活動するのでPeatixだけ見ても活動には参加できません
このあたりは心のNDAを結んで業界の込み入った話もしていこうぜ！という形を取っているからで、基本はメンバーの紹介制でdiscordに入ってもらえればと思っていますが、もし保険業界に関わっている人（別に保険の事業会社やシステム子会社にこだわりはありません、SIerだろうが卒業生だろうがどなたでも保険業界をもり立てたい人が来てくれたら嬉しいです）がいたら、コメントでもお声がけくださいませ。
前置きが長くなりましたけど、昨日のテーマは「アジャイル型開発プロジェクトにおけるドキュメントどこまでつくってる？」でした。
Scrumを適用しているかどうかとかは別にどうでもいいなと個人的には思っていますけど、アジャイル型のプロジェクトってメンバーを減らして少数精鋭で仮説検証を繰り返して進めているケースが多いですよね。
また、「チーム」としての活動をとっているところも多いと思います。
そういう意味では、デザインをまるっとチームで受け持っていたりもするし、QAをチームに含んでいたりもするいろいろなケースがでてきている印象です。
つまり、今までは分業制でやってきたものが自分たちの手の内でやっていく形に変化してきており、いわゆる内製化みたいな流れも起きているのだと思います。
当然ながら、その流れの中でデザインを初めて自分たちのチームの中でやるケースもあるし、アジャイルかどうかというよりも自分たちの営みをどうしていくのがいいのだろうかを模索している。まさに自分たちのあり方の探索期の人たちが多い印象です。
そういう中で、うちはこうやっているけどみんなどうしている？って言うのも一つの事例としてとてもよい議題にもなるんだけど、みんな似たりよったりで悩んできているのであれば、すでに先行して轍を踏んでしまった知見もたくさんあると思うんですよね。
今はまだこう議論がポストモーテムみたいになっているところもありますが、もっともっと自分たちの未来の話をしながら、会社を超えたハンガーフライトな場になっていくといいですよねー。
そんなことを感じた療養中の2023、夏でした。
自分たちで自分たちのことを考える、を考える
久しぶりに書くのでだらだらいきます。
ご容赦くださいm(_'_)m
私の在籍するレッドジャーニーでは、数ヶ月に一度の頻度で全員参加の合宿をやっています。
全員といっても、フロントメンバーが7人なので、こぢんまりといえばこぢんまりです。
中身のことは、
あたりをみていただければ（他人任せw）。
個人的にレッドジャーニーの合宿で面白いなと思う一番の点は、自分たちで自分たちのことを考える時間を大切にしているところです。
上でPeko氏が書いている通り、アジェンダも予定調和もほぼないといっても過言ではありません。
逆に言うと、そもそもこの時間をどう過ごすかということから自分たちで考えるということです。
（考えるという言葉では表現として物足りないなと思うところもあり、あくまで自分たちの勝ち筋（または価値筋といってもよいかも）を見定めるために行う過去現在未来に至る透明性/検査/適応すべてのことかなー）
そういう部分を含め、メンバーがみな自己管理できるし、お互いを尊重しているし、自分たちのことを常に考えているので、居心地の良いプロ集団だと感じるのでしょうね。
（おや、はまちゃんが写っていない！！）
僕の知る多くの組織では、実はこの「考える」をスキップして、以前までのなにかを流用、適用しているだけのケースが多い気がしています。
あるいは、自分たちが達成すべきプロダクト、プロジェクト的なアウトプットや組織に課されたミッションばかりを追いかけ、そのために必要な準備や段取りや戦術を「考える」ことができていないケースも多い気がします。
それは、自分たちで自分たちのことを「考える」、すなわち「検査」できていないことの表れなのでしょうね。
確かに、過去の知識や経験や生み出してきたアウトプットはとても貴重な財産です。
だからこそ、まだそれをそのままでいいのか、状況が変わっている中で適用の仕方を「考える」ことが、大切なのだろうなぁと思います。
つまり、私たちが「自分たちで自分たちのことを考える」時間をとるということは、ある意味意図的に↑をやっている、ということなのですね。
さて、みなさんが「自分たちで自分たちのことを考える」と向き合うとき、何からはじめましょうか。
まずは「考えることを考える」からですかね。
意外と"あえて"と思うようなことについて「考える」のも面白いかもしれません。
携帯料金プランの世界が変わっていて、昔のプランのまま「適用」していたら未だに毎月何万円も払っていた、くらいの大きな気づきを得られるかもしれませんよw
