侍れっどの明日できることは明日やれ

徒然なるままに筆を書き連ねます。

明日、アジャイル経営カンファレンスのリアルイベントを開催します

こんな前日に書くような話ではないんですが。。。

 

明日、7/19に私が運営に関わっているアジャイル経営カンファレンス初の交流会イベントを開催します。

 

アジャイル経営カンファレンスは「経営にアジャイルを適用し、企業の未来を探究する」を掲げ、経営、ミドルを中心とした組織や組織運営にアジャイルを適用することをテーマに、日本の未来を切り拓いていこうというイベント、団体です。

 

そのアジャイル経営カンファレンスの交流会イベントですが、下記から申し込みができます。

https://akc-kouryuukai-001.peatix.com/

交流会という名前の通り、参加者同士の交流をメインにおいていますが、特に今回は軽食とお酒を含む飲み物をとりながらわいわいやっていこうと思っています。

 

今日の明日でもう残席はわずかですが、お時間のある人、アジャイルな経営、アジャイルな組織運営に興味のある人は、ぜひお申し込みくださいませ。

 

開催概要は以下のとおりです。

---

 開催日時 :2024年7月19日(金)18:00~20:30
 開催場所 :NISSAY IT Academy TREASURE SQUARE 
       日本生命グループ IT人材研修施設
 住所   :東京都大田区蒲田5丁目37-1ニッセイアロマスクエアビル3F
       (Map:https://maps.app.goo.gl/DWAsY24NwEyfxx2V8
 アクセス :蒲田駅徒歩約2分、京急蒲田駅徒歩約6分
 参加費  :5500円(税込)

---

 

みなさんのご参加、お待ちしております。

たぶん。。。リアルの私も参戦予定ですw

www.instagram.com

 

最後に、アジャイル経営カンファレンスのもろもろのリンクをおいておきますね。

agile-keiei-conf.jp

www.youtube.com

x.com

www.facebook.com

www.instagram.com

https://jp.linkedin.com/company/agilekeieiconf

スクラムフェス大阪 虎ノ門トラックで登壇してきました

長々とご無沙汰しております。。。

先日、6月の21-22で行われたスクラムフェス大阪の虎ノ門トラックで久々のガチ登壇をしてきたので、その記録です。

 

 

スクラムフェス大阪についてはこちら。

www.scrumosaka.org

 

虎ノ門トラックについてはこちら。

ksg.connpass.com

 

ひょんな経緯で登壇が決まり、当日は実質基調講演枠という謎のハードル上げの紹介を受けて、お話しをしてきました。

ただ、45分という枠の中で、どう考えても収まらないOutlineを書いていたので、どうしてもちょっとふわっとしてしまった感があるのはごめんなさい、です。

 

当日の資料はこんな感じ。1週間で10000Viewもいっていて、興味を持っていただいたことに感謝しています。

www.docswell.com

 

当日は、久々のオンサイトということもあり、コミュ障ガッツリ発動していましたが、基本的に僕は顔出ししていないのでw、本体に登場してもらっていました。



というわけで、等身大パネルです。

(狙ったわけではないですが、等身大パネルに耐えられる新しいビジュを作ってもらっていて、たまたまこの会が初お披露目になった感じですwww)

 

オンラインにはこんな感じでzoomのカメラをワイプできる機能使ってお話していました(もちろん動いていますよ)。

意外にいけるもんですねwww

(今回はここに顔出すために左下わざとあけてスライドを作りましたです!)

 

というわけで、お前はいったい誰なんだ感満載な登場になりましたが、samuraiRedはこういうやつなんだなっていうのが広められたので僕としてはよしとしますw

 

さて、ちょっと今回盛り込みすぎて薄まってしまった要素をもう一度再構築して自分の中で納得するお話しをしたいなと思います。

どこかで場所をくださる方がいたら、XなりFacebookなりInstagramなりThreadsなりLinkedInでご連絡ください。

全国津々浦々どこへでも飛んで行く気ありますので。

 

最後は記念撮影ですが。。。



もちろんこうなりますwww

(Photo by かりそめの姿のあたし)

 

スタッフの皆さん、参加者の皆さん、本当にありがとうございました!

僕の等身大パネルを見つけたらぜひ一緒に写真を撮ってあげてくださいwww

レッドジャーニーの有志メンバーで電子書籍を発刊しました

今年もよろしくお願いしますw

いやはや年末年始から家族で体調不良が続いており、松の内もほぼ家を出ないままでした。

私も1月前半はすべての会食等をスキップさせてもらう感じでご心配おかけしてすみません。

 

 

さて、話は変わりますが、1/10〜12に行われたRSGT2024に向けて準備していた電子書籍が無事に発刊できました(1/10の朝06:40に校正し直しとかしてたけどw)。

agile-handbook.booth.pm

 

現時点ではゼロ円に設定していますので、フリーに読んでいただければ幸いです。

感想などXやコメントなどいただければ嬉しいです!!

 

レッドジャーニーのメンバーを独断と偏見で紹介してみる

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

 

昨日のぺこーらにならって、「メリークリスマス!!」からはじめますw

note.com

 

 

画像

 

 

 

背景

アドベントカレンダーを単発で見ている人にはそれぞれメンバー個別には認識をしてもらえているかもしれないなーとは思うのですが、よくよく考えると我々が何者なのかがまとまって伝わっていないのではないか、ということに気づいてしまったのでした。

きっかけは、12/9の田中くんの「今はただ 君に感謝を」を読んだことにあります。

note.com

 

なので、今日はクリスマスらしく?独断と偏見でメンバーの紹介をしていこうと思います。

 

メンバー紹介

市谷聡啓

市谷 聡啓

言わずともしれた弊社の代表。

元政府CIO補佐官であったり、『正しいものを正しくつくる』、『デジタルトランスフォーメーション・ジャーニー』、『これまでの仕事これからの仕事』などなどの書籍を多数執筆している人。

仮説検証を語らせたら右に出るものはいない...かもしれない(可能性はゼロじゃないという程度の話)。

仕事が服を着ている、という表現がものすごくしっくりくるほどの働き者なのだけれど、それはその先に見据えている「日本を再定義するんだ!」という強い信念に裏打ちされている気がする。

気になることはものすごく気になってしまうし、興味をなくすのも早いと思うけど、その選択と集中が常人レベルではないところが魔性な魅力なのでしょう。

食べ物や宿にはなんだかんだうるさいので、合宿などのときにはよくよく意向を汲んであげると機嫌がいいですw

あと実物は背が高い。

 

新井剛

新井 剛

 

ヴァル研究所の新井さん、という認知はもうだいぶ薄くなったかしら。

開発現場だけでなく、全社をカンバンなどで見える化をして、多数の見学者が殺到したヴァル研究所ツアーのきっかけを作った人。

『カイゼン・ジャーニー』や『ここはウォーターフォール市、アジャイル町』などの著者でもある。

物腰穏やかで、でも大切なことははっきり言うところが「レッドジャーニーのおかん」というポジションを確立しているのでしょう。

多分...そんな「おかん」なところは仕事の中でも芸風としてあらわれていて、それがときに「センセイ」のようであったり、「コーチ」のようであったり、「家族」のようであったり、あらゆるロールになって人々に寄り添う姿に全人類が感動しているはず。

朝起きるのが早いおじさん1号。

 

中村洋

市谷と中村は盟友である、という風に捉えている人はそれなりに多そう。なんかずっと隣にいるイメージ。

「The・アジャイルコーチ」という言葉が彼を表現するには一番正しいのではないかと思う。

本をよく読み、サイトを徘徊して、インプットの量はレッドジャーニー内でも1〜2を争うのではないかな。

現場を愛しているので、ずんずん現場に入っていってばっさばっさと立ち回るスタイルが全国で人気...なのでは。

むっちゃ引き出しがあるので、スクラムやアジャイルを現場で困ったり悩んだりしたらとりあえず洋さんに聞いてみるとよさそう。

朝起きるのが早いおじさん2号。

 

濱口知也

濱口 知也

市谷さんに傾倒して、会社辞めて来ちゃいましたみたいな人だったと記憶している(が、間違っていても謝りません。ごめんなさい)。

多分、レッドジャーニーでは一番エンジニアリングから遠い世界の住人(みんななんかしらエンジニアの道を通ってきた人ばかり)。本人もちょっと気にしてる。

プロダクト開発や仮説検証の話になると目をキラキラさせて少女漫画の主人公のようになる純朴なところが人々に愛されるポイントなのではないかと思う。

一時期はnoteにもらうLikeをXX個集める!みたいなことを言っていた気がするけれど、最近のアウトプットは...常夏のビーチのような穏やかさと認識しています。

トランペットやらオーケストラやら多才なんだけど、とりあえず合宿中も毎日スプラトゥーンは欠かさないマメな日本男児

 

田中基淳

田中 基淳

満を持して...レッドジャーニーで一番まともにエンジニアができる人(僕は最前線のエンジニアリングはもう忘れたよ、パトラッシュ...)。

最近はものづくりからことづくりに少しずつスキルの幅を広げているのかなと勝手に感じている。

実はとてもストイックで真面目な上にセンスがいいので、イケメン過ぎて世界中の嫉妬をかってしまう罪深いところがある。

なんでも恐れず飛び込むことができるので、すぐに誰かに巻き込まれていく巻き込まれスキルのレベルが異常に高い。が、最近は巻き込まれることで自分の強みを増やしているようにも見えるので、もしかしたらスキルではなく単なるあざとさなのかもしれない、と思わせる罪深いイケメン

 

瀨川晋平

レッドジャーニー唯一の陽キャ属性

「はじめまして」の直後にはグループの輪に普通に入っていて、もうどこにいるのか見つからなくなるくらい馴染み力が高すぎる。

人との付き合いが上手で、どんな話を振っても自身のネタ話をちゃんと返してくる。もはやネタのために普段から生きているのではないか、と鎌倉近郊で噂されているとかいないとか。

ちなみに、彼はまだ一度も鎌倉のオフィスに出社したことはないはず。

サウナでテニスをするくらいサウナとテニスが好きなんだと思うのだけど、一緒にサウナもテニスもしたことないから真偽の程は不明。

現場の場数を踏むことで、スーパーアジャイルコーチに進化する可能性を秘めている全人類のうちの一人。

 

森實繁樹(私)

世界から社会的に自分の肉体を消し去りたい(死にたいといっているわけではないw)願望を持っているだいぶ変わった人。

メンバーのそれぞれの特性、スキル、能力の尖ったところには常に一歩足りないけれど、逆におそらくすべてのメンバーのサポートをできるレッドジャーニーのスーパーサブ、とどこかでは言われているかもしれない。

背の高さも市谷さんに次いで二番目。

かつては音楽系芸人としてアジャイル界隈に旋風を巻き起こしたことがあるとかないとか。最近の興味は地方創生と中小企業らしい。

寂しいと死んじゃううさぎさんと本人は自分を表現するが、飲みに誘うと十中八九断られるというメンヘラな一面をもつ。

 

まとめ

とりあえず盛った表現はなかったはずなので、こんな素敵なレッドジャーニーのメンバーに少しでも興味関心がわいてもらえたら幸いです。

2024年もレッドジャーニーを宜しくお願いいたします。

 

それにしてもみなさんそろそろアー写取り直した方がいいですよw

 

 

【2023年版】アバター生活ふりかえり

昨年、アドベントカレンダーネタとしてアバター生活についての記事を書いていたのですが、1年でだいぶ状況が変わったので2023年版を起こしていこうかなと思います。

ちなみに、なんのアドカレの記事でもありませんw

 

ちなみに、昨年の記事はこれ。

blog.samuraikatamaris.red

 

 

アイコンとアバターの変更

今年大きく変わったことが一つあって、ブログのアイコンもそうですが、かつてのお仕事仲間のデザイナーさんにアイコンとアバターを発注しちゃいました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)がチームに頼る頼られる話をしていますね。馴れ合いではなく補完の関係になれるといいですね!

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歩先まではせめて見据えてまわさないと、迷子になる可能性が高まります。

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