エンタープライズアジャイル勉強会 NTTCom 岩瀬さん と リクルートテクノロジーズ黒田さん

昨日、長らくお手伝いさせていただいているエンタープライズアジャイル勉強会がありまして、今回は横道稔さんのホスト会で、NTTCom 岩瀬さん と リクルートテクノロジーズ黒田さん にお願いすることになりました。

実際に日本の大企業で仕事をやっていくうえで、一エンジニアやプロダクトマネージャーから一歩踏み出していくための、かなり解像度の高いヒントが得られるのではないかと思います。10数年前に、私がちゃんとスクラムをやり始めたきっかけは、当時初参加のデブサミで聞いた関将俊さんの講演だったのですが、同じようなきっかけや具体的なヒントを数多く得られる講演だったのではないかと思います。

っていうか、お二人の話を聞いていると、どんどん言い訳を失っていくんですよね。開発者の立場でも、マネジメントの立場でも、まだまだやれることがある感じがしてきます。大変だと思いますけどね。でもちゃんと成果を出していくために、必要なことをやっていこうと。つまりはそういうことにすぎないわけです(解像度最低)。

 岩瀬さんの資料

いくつかピックアップします。

f:id:wayaguchi:20201015164400p:plain

うまくいったアジャイルチームが定期異動で分散してしまったり、大きな会社のなかで様々なチームで取り組みが始まっているようなときに、結果的に既存の仕組みに各個撃破されてしまうリスクがあります。それが起きたときにおこることは、コアになったエンジニアが辞める、もしくは活動がチーム以下に縮小して個人活動になる、という感じでしょうか。それ、起こしちゃって本当に大丈夫ですかね?会社。と思うのですが、そういっていても伝わらないので、様々な活動をやっていく必要がありますね。とりあえずうまくいっている状況を守るための、チーム外へのアプローチが必要になってきます。講演でも触れていただきましたが、SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップでも中心になっているテーマがこれです。
f:id:wayaguchi:20201015164017p:plain

そして、多くの経営書で語られていますが、非公式組織、組織図に出てこない人々のつながりが大きく影響します。部署を超えた、人のつながりです。大きな会社で定期の人事異動をしたり、一括採用で同期のつながりを作ったり、ということは半分はこのため(半分は癒着の会避)だと思いますが、うまく活かす人が多数というわけではなさそうだなと思います。しかし、多くのイノベーション研究で語られているのは、非公式組織です。みんながやらなくてもいいけど、できる人はやればよくて。一部の人がやれば、論理的にはスケールフリーネットワークが実現できます(組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary

f:id:wayaguchi:20201015164049p:plain

意図的に人事(HR)にキャリアチェンジして、現在のトライが続いているそうです。いいですね。

f:id:wayaguchi:20201015164116p:plain

f:id:wayaguchi:20201015164155p:plain

 そして内製化問題を取り上げていく。内製化というと「それだけが答えじゃない」「そうはいっても人がいない」というような反応をいただきがちですが、そうした問題に一つ一つ、いい感じに会社のリソースを使いながら、答えを出していく。そうすることで、見えないところで多くの開発者やビジネスの人たちが、間接的にやりやすくなっていく。灯台の灯をともし続けて、組織全体として戻れないところまで、ちゃんと変化を定着させるの、すごく大変だと思いますが、そういう人を、組織の人たちはなんとなく手助けしていくのではないかと思っています。(足を引っ張る人のほうがだいたい先にいなくなりがち。)

頑張ってください。応援してます。

 

黒田さんの資料

いくつかピックアップします。

f:id:wayaguchi:20201015170538p:plain

アジャイルにならなければ、といっても、すでに動いている事業体の場合、現在のやり方を全部取り換える、という話にはなりえません。現在うまくいっていないわけでもないし、そうやってビジネスは回ってきて、だから人が雇えている。急になにかにかぶれて一気にいじるのは、足元を突き崩すようなものです。ということで、システム全体を、向き不向きで分けていきます。これは組織ごとに持っているコンテキストが違うでしょう。

f:id:wayaguchi:20201015170825p:plain

そして、各個別の機能は、できる限り短いリードタイム(≒コスト)で、届けてコストを回収したい。一番右の if (isBooked) がTrueになったところで課金が発生するので、そこまでのステップをなるべく短くする方が、ROIが高い、ということになります。このあたりを、プログラミングの用語とビジネスの用語の両方でちゃんと理解しておく必要があると思います。

f:id:wayaguchi:20201015171137p:plain
そして、アジャイルで(DevOpsやマイクロサービスを援用して)やっていくことでリードタイムを縮小していくことが、一つ一つの施策のレベルで重要です。最後に一気にやっても作れるのですが、リスクは上がってしまう。もちろん施策が当たるとは限らないので、途中でさらに収益機会は変わっていきます。その途中の情報が早く得られることも重要です。

f:id:wayaguchi:20201015171318p:plain

強い売上目標を課してしまうことで、結果的に開発部隊のマインドがディフェンシブになってしまって、バッファを積んでROIを下げてしまった事例があったそうです。一見正しそうな経営陣のオーダーも、実際に何が現場で起きているのかを理解していないと、思わぬ副作用を呼んでしまう、ということです。

 

続きは RSGT2021 で!

お二人の話を聞き逃しちゃったー、直接質問したかったわー、という方は、きっとRSGT2021 に参加していただければ、聞けるのではないかと思います!