RSGT2024ふりかえり
RSGT2024が終了し、ふりかえりブログを書くところまでがRSGTということで振り返っていきたいと思います。
所属するログラスでは今回からロゴスポンサーをさせていただきました。
#RSGT2024 3日間現地参加予定です！
— Yoshiki Iida / ログラス (@ysk_118) 2024年1月9日
ギャザリングしていくぞ！！！
ログラスは今年からロゴスポンサーもしております！
ジョブボードにも貼りますがエンジニア、QA、スクラムマスター等々全方位積極採用しております！
ちょっとしたノベルティもおいてますのでよければお取りください！
社内からは全日程フル現地参加は私ともう一名くらいでしたが、トータルでは7名の参加となっており、昨年対比で広がりを感じる回となりました。
Day1
たまたまですがほとんどMain Hall Westにいました。
Keynote
Keynoteについてはきょんさんの予習noteがわかりやすく、事前に公開していただいたことで話に入って行きやすかったように感じました。
チームメンバーの変更に悩んでいるすべての人におすすめのDynamic Reteaming 2nd Edition｜kyon_mm
スクラムの視点からでは理想的には安定的なチームを作る方がパフォームさせやすいと言われますが、実際にはチームの変更は起きるよね、という現実的な課題からじゃあどうやるの？というお話しだったと思っており、EMの実務にも生かしやすい話かなと感じました。
特にパターン分けした上で観点やアクション、前提の注意事項など非常にわかりやすく整理されていたように思います。
書籍の日本語版はまだないとのことでそこにも期待が高まりますね。
最終的に忍耐が必要という、泥水っぽい話が出てきたのも個人的には刺さりました。
ランチ
まえけんさん、SODA林さんとご一緒しました。
まえけんさんは今回はじめましてで、お一人だったので一緒にどうですか？と声をかけて、そこに林さんが来て3人で話しながら食べました。
林さんは昨年の開発生産性Confなどで薄く接点あったのですが、しっかりお話しするのは初めてでした。
お互いのバックグラウンドや、まえけんさんの沖縄での活動の話などについてお話ししました。
ジョブボード
ジョブボードにも情報を貼っておきました。
おおひらさんとEmiさんと立ち話をしましたが、Emiさんから弊社のスクラムマスターのJDも見ていただいており内容についてほめていただけたのが嬉しかったです。
界隈の方から見てどう見えるのかは感心あるのでぜひコメントいただけたらうれしいです。
背景はこちら↓
エンジニアも募集しているのでアジャイルな開発に感心ある方はぜひDM等くださいませ。
午後セッション
午後イチはカケハシさんのお話しを聴きました。
今回のRSGTの個人的な目標としてしいばさんとお話しするということを掲げており、まずはセッションを聞きに行こうと思っていました。
しいばさんとまだ直接お話したことがなく、どこかでお話したいです！
— Yoshiki Iida / ログラス (@ysk_118) 2023年12月1日
昨年末にカケハシメンバーとXで盛り上がるイベントがあり、なんとしても回収したいという思いでした。
登壇を聞いて思ったのは内容も新規事業においてしっかり価値を出しにいくためのプロセス設計をされていたなと感じましたが、それ以上にこういう場でいいチーム感が生で感じられるのが非常にいいなと思いました。
普段からXでいちゃいちゃ仲良さそうな雰囲気が流れてきていますが、オフラインでみると改めてチームの空気感を感じることができ広報的にもよさそうだなと思いました。
来年はログラスでもこういうチーム登壇をしたいなと感じました。
ここ最近アウトカムシリーズでお話しされている中村洋さんの発表を聴きました。
アウトカムを定義する上でインパクトとの違いの整理や短期的な指標と遅効指標の取り扱いなどわかりやすく整理されていたと感じました。
一方遅効指標を具体的にどう取り扱うかはプロジェクトによって大きく変わりそうなので結局その点についての解は各チーム頑張ろうね、という抽象度高めのところにとどめていた感もあり、具体例も知りたいなと感じました。
アウトカムに向き合う人事制度観点からのインセンティブ設計はログラスでもより深く考えたいなと感じました。
（カードが何故か表示されなかったのでリンクで）
Risaさんの金融系システムにおけるアジャイルの取り組みのお話しを聴きました。ミッションクリティカルなシステムの開発におけるチーム設計の観点と安定性や信頼性vsアジリティは非常に難しいものがあると思っており、どうやっているのか関心があったので聞いてみました。
外部と会社をまたいでアジャイルなチームを組成できている点が非常に素晴らしいなと思ったのと、マネジメント層の理解が非常に重要な要素であるということが後から追加でお話しをきいて理解できました。
久しぶりにおよべさんの話を聴きました。
彼のチームはチーム転職をしながらここまできており、安定的にパフォームするチームを作るというスクラムの理想型を体現してきている印象でしたが、そのチームの内部的な視点から大きく会社や経営からの視点でそうしたチームをどうやって増やすの？という内容でこれまでのコンテキストと少し変化したな、という印象でとても気になったため聴きにいきました。
発表スタイルもさすがとしか言えないスムーズな流れで、課題やもやもやの共感を会場と共有しながら、そこにどう向き合ったかというプロセスと結果の話も非常にクリアで、会場も満席に近かったのでマネジメントに興味を持つ人もいたのではないか？と感じました。
Deep Diveシリーズも聴きました。これまでのDeep Diveシリーズは後追いでみていたのですが、今回は生で聴きたいなと思い参加してきました。
初手でベロシティYAMEROというパワーに満ち溢れた展開でしたが、順を追ってなぜメトリクスに囚われることがよくないのか？を解説されている良い内容でした。
なんとなくよくなさそう、だけどそれが何故なのか？はうまく説明できない・・という人は地味に多いと思っていて、このような本気の言語化は非常に価値があるなと感じました。
【資料公開】ベロシティ Deep Dive | Ryuzee.com
夜の部
初日はここまで聴いて夕方1本MTGが入ったためそちらに出てから集まっているところに合流させていただきました。
ちなみにMTGはこちらのブースを予約して使いましたが、ソラシティからは地味に遠かったです。
飲みの場は入れ替わりがありすべての言及が難しいですが、最初はおよべさん、中村洋さん、稲野さんの会に混ぜてもらいました。
およべさんと直で話すのはめちゃくちゃ久しぶりで発表内容で自分が感じたことなどをお伝えしました。また、今回マネジメント系の発表をするのは緊張感もあったとのことでしたが、その中で以前からそういった発信をしている私に対しても尊いと言っていただけてとてもうれしかったです。
いずれかの経験だけで語るとポジショントークになってしまう懸念もありますが、現場もマネジメントもどっちもやっている人が言うから説得力があるいう話になり、これからも取り組んでいきたいなと思いました。
中村洋さん稲野さんとはとしっかりお話しするのは初で、とてもありがたい場でした。
スクラムというフレームワークそのものが実は顧客に向き合えていないのでは？や、現場のコミュニティ参加へのハードルがどうか？など興味深い話で盛り上がったのが印象的でした。システムコーチングはHeidiの話の中でも出てきたようにまだまだこれから盛り上がって行きそうですね。
その後は日浅さん、石原さん、藤村さん、酒井さん、上戸鎖さん、今川さんと話していました。日浅さんは去年ぶり。藤村さんはめちゃくちゃ久しぶり！ということもありいろいろな話が聴けました。EM Oasisの由来や、上戸鎖さんと藤村さんはクラメソ同士ということもありどんなかんじで事業に取り組んでいるか？など伺いました。
石原さん、酒井さんははじめまして、今川さんはオンラインでお話ししたことはあるが対面は初ということでこちらでもどんな事業やどんな開発をしているかを聞かせていただきました。
みなさんそれぞれのドメインごとの課題など、興味深い話を聴けました。
Day2
Keynote
会社にノベルティを取りに行くタスクが発生したことと、鉄道のトラブルにより遅れての参加となりました。
Day2 Keynoteはレガシーコード改善ガイドのMichael Feathers氏のお話しでした。
事例を交えつつ、全体としてコードと付加価値の関係についての話だと解釈しました。事例としてのテスラがやはり存在感があるのかなと思うところはありましたが、ソフトウェアに止まらない領域においてどうやって付加価値を作っていくのか？はメッセージングとして強いものになるのだろうなと感じました。
また、質疑にてスタートアップのような環境において短期的な成果指標が価値を置き去りにしてしまう問題について、VC側の視点がアップデートされていく必要があるということは興味深い話題だなと感じました。
ランチ
誰と食べようか迷ってうろうろしていたのですが、Day1のRisaさんを見つけ声をかけてランチ同席させていただきました（Day1登壇のところでいろいろ話をききたく声をかけてみました）。ことねさんと約束されていたとのことでお邪魔した形になってしまったのですがありがとうございました！（ことねさんはじめましてだったのにきちんとご挨拶できずすみませんmm）
Day1感想にも書きましたが、ミッションクリティカルなシステム開発をする中で、外部も含めたチームビルディングは非常に難しいはずで、マネジメント層の理解や初期の推進があり現在のチームに繋がっているということがお話しを通して感じることができました。
午後セッション
ログラスにて現在専任スクラムマスターを担っていただいているbonotakeさんの発表を聴きました。
社内でもちらっとお話しされているところではあったのですが、発表はやはりリアルタイムできいてよかったと思う内容でした。
私のポジション的にもマネジメントの存在価値について研究側面から言及があったことは興味深いと思いましたし、そもそもこうした組織論について体系立ってまとめられているものは少ないと思いますので学術的なところからのアプローチがあることの価値の可能性を大きく感じる発表だと思いました。
2つ目は林さんの発表を聴きました。
CTOとしてQA組織をどう作ってきたか？という観点ですが、現職の状況とも重ねて考えられるところがあり興味深いセッションとなりました。
主題としては開発のすべてのフェーズでテストを実施しよう、とそのために職種の壁を壊すということが主題となっていましたが、行うは難しの典型の領域でもあるため、やはり社内で最適解を考えていくしかないと改めて感じました。
その後はしばらく廊下でうろうろするタイムとしました。
新卒の会社で一緒だった宮崎さんと毎年の近況報告をしたり、KAGの方（すいません顔は覚えているのですが名前思い出せず・・）とお話ししたりしました。
廊下では他にもosawataさんと初めましてをして、一人スクラムマスター兼QAの大変さを聞いたり、アドベントカレンダーの言及にも繋がって嬉しかったです。
おもしろいなー。やっぱりスクラム道のlv2とかlv3って、EMとかそんなロールと似てくるんだなぁとふんわり思ったりした。今の自分はlv1.5くらいかな。 https://t.co/9NFBwZbTOM
— osawata(sammy) (@osawata36) 2023年12月10日
Kaoriさんともリアルでお話しするのは初めてで、アジャイルチームを支える会からの伏線回収ができました。現職でのトライの話などまた続報が聴きたくなるお話しができました。
ご挨拶させてください！！
— Kaori (@running_kao) 2024年1月10日
(去年遠慮して遠目&心の中で、飯田さんだ！！ありがとうございます！！って念じました。笑)
その後サイボウズさんのスポンサーセッションを聴きに行きました。
システムコーチングを軸に横連携を深めるという点と場としてどのような設計をしているか？という話がメインだったと思います。
発表の中で扱っている時間軸の関係上難しかったかもしれないのですが、プロセスの設計思想や得られたアウトカムに対してのより深い洞察があるとよりよかったのかなと感じました。
現時点でスクラムマスターをここまでスケールしている会社は他にないと思うのでまたどこかでお話しを聴きたいと感じました。
↑に関連して天野さんがコーヒーエリアにいたので話しかけて現在考えていることなどお聞きさせていただきました。
スクラムマスターの採用基準、評価基準など難しいポイントについていろいろ聞かせていただきました。
X上では接点ありましたがリアルでは初だったのでお話しできてうれしかったです！ありがとうございました。
登壇の内容ともかぶるとのことでしたが、すいません、ウクライナの話が気になりすぎてそっちを聴きにいってしまいました！
#RSGT2024 は今年も多彩な海外ゲストが来日する予定です。レガシーコード改善ガイドのMichael Feathersさん、Dynamic Reteaming の Heidi さん、モブプロの Woodyさん、ウクライナ従軍経験のDmytoさん、急遽、Joe Justiceさんも来場予定です。セッション以外での通訳さんもお願いしたのでぜひ群がって
— Yasunobu Kawaguchi (@kawaguti) 2023年12月21日
ウクライナでITコンサルやってた人が戦争に入って、連隊長になって、Turn the Ship Around 読んで指揮をしていく話を聞いてる。 pic.twitter.com/sZFmgaeqbc
— Yasunobu Kawaguchi (@kawaguti) 2023年10月10日
リアルではここでしか聴けない話だと思い、Day2最後はこちらのセッションを聴きました。
なかなか感想を言葉にできないというのが正直なところなのですが、この話をここで聴けるということが大きな価値だと感じるお話しでした。
自分が同じ立場になったら何ができるだろう・・
夜の部
今川さんがアレンジしてくれた会に混ぜていただきました。えーちゃんさん、Risaさん、ぞみさん、鈴木さん、（すいません、あと何名か失念してしまいましたmm）とお話しさせていただきました。
スクフェス福岡の話やカメラの話、ミッションクリティカルな技術の話で盛り上がりました。福岡間に合うか微妙ですが、スクフェス関連の露出増やして行きたいので今後もよろしくお願いします！
Day3
ネックストラップ忘れたところから始まり、移動中はZoom越しに参加する形になってしまいました。
OST
OSTではどのテーブルも盛況で、議論に入るの難しそうだなーと思ってうろうろしてたところで、黄色い森さん、Ryoさん、石原さんが話していた野良OSTに混ぜてもらいました。
インプロの軽いセッションをRyoさんにやってもらい少し理解が進みました。また、森さんからは現在チームのスケールに悩んでいるとのことで組織的な意思決定のプロセスなどについて相談いただきいろいろ壁打ち的に答えていました。
途中からきょんさんも合流し経営や日本をどう変えていくか？というスケールの大きい話をしていました。きょんさんのところでは主に地方の行政側からアプローチしていきたいとのことで自社のアセットとエンジニアリングでやれることの解像度が高く非常に面白い考えだなと思いました。
森さんからは社内で組織改革をリードできる人は限られており、コミュニティでそういったチャレンジをしている人に話を聞けるのが良いと言ってもらえてうれしかったです！
Keynote
Kano Modelの狩野先生の発表を聴きました。
正直なところ概念レベルの浅い理解しかなかったので、リアルで話を聴けたことがとても貴重だったなというのが一言目の感想です。
品質について言語的な解釈から入り、魅力品質を理解するための具体例など多くのエッセンスが散りばめられていました。あと2時間くらいは聴けそうな内容だったためもう少し自分でも調べてインプットしにいかないと全容が見えないなと感じました。
学術的な背景も含めてキーワードを知るくらいしかないのですが、QA的視点からの知識レベルをもっとあげる必要性を強く感じました。
夜の部
カケハシ組に混じって下のタイ料理に行きました。
場は関さんがアレンジしてくださっており、カケハシ以外の方も多く、たくさんの方とお話しでき、非常にうれしかったです。
非常にたくさんの方がいたので言及が部分的になってしまい申し訳ないですが、しいばさんと飲む実績を解除しDDDなどの話ができたこと、笹さん・白い森さんとはじめましてでお話しできたこと、稲野さんにRSGT2018の発表が非常に参考になったことのお礼を伝えられたこと、aki.mさんとじっくり話して採用のこととか現職の話をできたこと、まっつんさんとはじめましてでEMチャレンジのお話しができたこと、関さんが転職後のチャレンジのお話し、おぎじゅんさんとRuby界隈のネタを話せたこと、ゆのんさんいしげさんが抜けた後で頑張っている細矢さんの話を山浦さんと聞いたこと、ゆのんさんにもっとリーダーシップ取れ（意訳）と言われたこと、おーのさんに一年前のこの場で話せたから今があるって感謝されたことなどなど・・非常に多くの方とお話しさせていただきました。
思うのはやはりここの中だけでも、「あの時のあの発表が役に立ってて」とか「あの時かけてもらったあの言葉があってチャレンジできました」とか、そういう恩が飛び交うのがこの場が特別な場であることを証明する要素だなと書いていて思いました。
その後はなぜかパウリさんとサシ飲みになって、かなり記憶があいまいな時間帯になっていましたが、結婚式の準備をするのにうってなるところをどう捉えるといいか？という話をしていました。
Xにスクフェスパウリ開催決定と書いたのはノリではあったのですがただの冗談ではなくて、昔西村直人さんが自身の披露宴をデブサミにちなんで雅叙園でやっていたところに実際に参加していたので、自分が面白いと思う形でやったらええんじゃないの？という話をしていました。
まとめ
セッション全体を通してアウトカムや価値というキーワードが共通してあったように感じます。
そして、Dynamic Reteamingやおよべさんの発表から感じるところとしては、スクラムという熟練した小さなチームから見える理想と、会社全体からみる事業活動・経済活動にはやはりギャップがあって、理想を捉えつつも現実にどう落とし込んでいくのか？という実践的なエピソードが増えたのかなと感じるところがありました。
アウトカムからインパクトに繋げていくところに、スクラムチームのメンバー自身が責任持って向き合わなければいけない、それがどこかの進んだチームだけでなく、業界全体としてそういう機運が高まっている、そんな感想を抱いたRSGT2024でした。
今年もどうぞよろしくお願いいたします。
これから求められていくジンジニア
この記事はジンジニアアドベントカレンダー25日目の記事です。
ジンジニアとそのコミュニティについて
エンジニア出身の人事という説明が最もシンプルですが、最近はEMやDevRel文脈などもう少し広いバックグラウンドの人が界隈に集まっていると感じています。
私自身、これまでのキャリアで開発と人事と二足の草鞋を履いていたこともあり、いつのまにかジンジニアコミュニティに所属するようになっていました。
ジンジニアという言葉自体はもう少し前から存在していたようですが、コミュニティとして活動を開始したのは @tbpgr さんが発起し2019年に開始したのが最初です。
特に人事面に関わると言うことで公開のイベントではなかなかお話しできないネタを相談したりすることができる場は非常に貴重な場となりました。
これまで不定期に開催する座談会がメインの活動でしたが、今年の夏にはタイミーさんのオフィスをお借りしてイベント開催も実現しました。
懇親会まで含めて非常に盛況となり、ジンジニアへの関心の高さが伺える会となりました。
自分の発表は色々な方にリアクションいただき嬉しかったです。
個人的に今日イチのパワーワード
— tweeeety (@_tweeeety_) 2023年8月4日
「泥水をすする」#ジンジニアMeetup
これから求められていくジンジニア
さて、このような形で直近認知を広げて行っているジンジニアですが、個人的には今後以下のような人が求められていくのではないかと感じています。
※具体例として人物イメージをつけてみましたが、ご本人がジンジニアと名乗っているわけではないのでその点のみご注意ください。あくまでこのような動きをする方がジンジニアとして活動したら強力だろうなという想像です。
組織開発をリードするスクラムマスタージンジニア
スクラムマスターはスクラム開発における一つのロールですが、プロセス改善やチームのコンディションを主な関心ごととして持っています。
EMなどのマネージャー職も領域がかぶるところはありますが、特に組織開発を全社視点からみた時にスクラムにおける改善の回し方や、組織に対するコーチ的な振る舞いを考えられる人は人事視点でも非常に価値があります。
特に組織が急成長している中でアラインメントしたり、逆に大きくなって小回りが効きにくくなったときにも組織を大きく動かすためのレバレッジを効かせる動きができます。
動き方のイメージ：Amanoさん
組織の基本単位を自己管理型チームにしていくために、こんな方針でチーム作ると良いよ〜というのをまとめたチーム作成ガイドを作りました。健全なチームが増える一助になれば嬉しいです！https://t.co/nIIUc9MuFh
— ama-ch / Yusuke Amano (@ama_ch) 2023年7月26日
組織戦略と経営戦略を接続し攻めの投資を行うEMジンジニア
これはどちらかというとマネージャーとしての意思決定にフォーカスしたジンジニアの動き方です。
EMとして組織の色々な決め事に関わると不確実性の中でどうにか意思決定をするという機会があると思います。
そうした組織的な投資の意思決定は人事の立場から考えても重要で、特にトップダウンの大きな意思決定に現場視点を反映させ精度の高いものにできるというところが最も大きな価値となります。
開発経験がない人事の場合、思い切った投資をしようとした際に現場に受け入れられるか不安に思ったり、逆に一切考慮せずに推し進めてネガティブなリアクションをもらってしまうことも考えられます。
現場を知っているジンジニアが人事に入って大きな施策を動かせることは大きな強みになるはずです。
HRBPやDevHRも近いところだと思いますし、EMからジョブチェンしそれを名乗って活動している人も最近は多くいると感じています。
動き方のイメージ：serimaさん
#LXベッテク月間、本日は僕の番でした！HR<>エンジニアリング組織のお話です！
— serima | LayerX (@serima) 2022年6月6日
シュッと読めると思うのでスキマ時間にでもぜひご覧ください〜😎
プロダクトチームの HRBP として、なめらかに情報を行き来させる価値に気付いた話 - LayerX エンジニアブログ https://t.co/PoE6LPtE5h
技術広報・採用広報をリードする"前に立てる"ジンジニア
ジンジニアと名乗る人の中でも最も多くの人が関わっているのが採用だと思います。
採用については短期長期で施策は変わりますが、その中でも技術広報というその会社が社外のエンジニアからみてどう見えているか？という認知を作りにいく活動が非常に重要です。
名前も聞いたことない、何をしているかもわからない会社からスカウトが来ても開かない人が多いのではないかと思いますが、これが日々の発信やカンファレンススポンサーで名前を目にするということだけで印象は大きく変わるのです。
その中で色々なコミュニティに出て行ったり、そこでコミュニケーションしたり、実務としての経験を元にした発信をやりつつもコミュニティへの還元と自社の認知形成をリードできるという人は採用を踏んでいきたい企業ではどこでも求められるのではないでしょうか？
人と話すことが好きで前に立つことが苦でない人であればこれを目指すのもありだと思います。
動き方のイメージ：パウリさん
本日の #QiitaNight での登壇資料はこちらです！https://t.co/UFe5kbgqfI
— パウリ (@pauli_agile) 2023年12月8日
まとめ
ジンジニアの必要性は以前にも増して高まっているし、チャレンジのハードルが下がってきているようにも感じるのでまた新しくトライする人が増えたらうれしく思います。
2024年はさらに盛り上がることを楽しみにしています！
テクノロジーマネジメントとビジネス成長と自己組織化の罠
この記事は Engineering Manager Advent Calendar 2023 19日目の記事です。
以前書いた記事が思いの外伸びてしまいびっくりしたのですが、以前の話題にも続く話を書こうと思います。
ビジネスの成長に組織が追いつかない！を回避したい
私が初めてマネジメントにチャレンジした時感じた学びとして最も大きかったのがこの観点でした。
読んでくださっている方の中にも会社として成長を作り出したいのに舵を切ろうとしても組織がなかなかついてこないという悩みをもったマネージャーもいるかと思います。
いくつか要因がありますが、最も難しいのが「信頼されていない」という課題です。
（魅力的に伝える発信力などはスコープアウトします）
ブレークダウンすると、「リーダーの言葉が形骸化している」や「リーダーの方針のもと頑張っても報われない」といった感情が組織に広がっている場合組織を動かして成果を出すことは難しい状況と言えます。
私自身過去メンバーから「何を話しているのか自分でもよくわからなくなっているのでは？」「頑張りは認めてもらえるけど報われている感はない」という声をリアルでもらったことがあり、力不足を痛感したことがありました。
こうした問題は個々人のマネージャーの力量によっても解決しうるものですが、点の解決策になるので再現性は生まれません。根本解決の観点では、組織全体の問題と考える必要があります。
しかしながら、ある時からいきなりそういう状態になるものではなく、何年もかけてじわじわ醸成されるものだと感じています。
組織内に発生する負の引力というのは人が集まって仕事をしていれば自然に発生するものだと思いますが、状態のいい組織ではそれが自浄作用によって自然治癒していきます。
しかし、組織の状態が悪くなったり、特に組織に対して責任を持つポジションの人がその対処をやり切れないとその問題は負債となってどんどん大きくなっていきます。
それに対処するための基盤としてのマネジメント組織については以下の登壇でお話ししているので関心があればみてください。
ビジネスの成長にテクノロジーが追いつかない！を回避したい
さて、ビジネス成長に耐えられる組織があればその会社は安泰と言えるでしょうか？
いくらいいマネージャーがいても、いくら組織エンゲージメントが高くても、組織全体として技術的課題*1の増大に対抗する力を持っていない場合は厳しい、という話を次にします。
ビジネス成長に対して組織が安定的に追従したとしても、技術的課題が大きくなるスピードがビジネスの成長速度を上回ることはあり、この状態になるとその時点からビジネスを継続するための技術的課題への対処が発生し続けるためビジネスの成長角度に対して大きく影響を与えてしまいます。
技術的課題の内訳はいろいろありますが、最も事業に影響のある課題を一言で言うと「開発生産性が落ち、機能リリースが思うようにいかなくなる」が最悪の状態として言えるのではないでしょうか。
- コードの保守性・可読性・変更容易性
- パフォーマンス
- セキュリティ
などが具体例として挙げられるかと思います。
私のマネジメントの考え方
少し横道に逸れます。
私は現在はマネジメントを主な責務として担っていますが、バックグラウンドとしてはスクラムで改善をゴリゴリ回すのが好きなエンジニアです。
2018年頃にCope先生のCSM研修を受けたときの言葉が今でも記憶に残っており、（文脈は割愛しますが）「マネージャー？チームにマネージャーは要らない！」と力強く言っていた（笑）のが今でも私のマネジメントの考え方に大きな影響を与えています。
つまり、チームが自己組織化し、必要な知識や情報が揃っていれば究極的にはマネジメントは必要なくなるという考え方です。
現実的には会社という箱の中で活動するので評価などピープルマネジメント要素は残るのですが、それでもプロダクトマネジメント、プロジェクトマネジメント、テクノロジーマネジメントはチームで完結できるはずです。
自己組織化を推進した結果としての機能不全アンチパターン
話を戻しますが、自己組織化を推進してマネージャーがチームから離れていき、さらにそうしたチームをスケールさせていくとします。
その時にチームがテクノロジーマネジメントの観点をしっかり強化できていればいいのですが、上の図で書いたように技術的課題が急激に増大するとチームの内部では対処が難しい状況が生まれてしまいます。
結果的にマネジメントとチームの間に大きな問題が残り、組織全体の機能不全に陥っていきます。
この問題に対処するためには、戦略的にテクノロジーマネジメントに投資し続けることが必要です。
結局プロダクト戦略・技術戦略・組織戦略を紐付けて回していきましょうという当たり前の話になってしまうのですが、具体的な問題構造の整理が進んだので記事として言語化してみました。
いろんな会社のやり方・考え方も聞いてみたいのでX的なところで感想いただけたらうれしいです。
*1:この文脈で出てくるワードとして技術負債というものもありますが、意識的・意図的なネガティブ影響というよりかはビジネス成長によって順当に発生する課題も含めて純粋に技術的課題と表現します。
マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について
Engineering Manager Advent Calendar 2023 7日目の記事です。
結論ファーストで書きます
マネージャーは答えを持っていません。
大事なことなのでもう一度言います。
持っていません。
この問題ってそもそもなに？
細かくみてみましょう。
マネージャーに全てを決められたくない
マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。
ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck
こちらのスライドにあるような「私考える人」的な動きになっているマネージャーは、Howはやらずとも現場の自己組織化を阻害している可能性もあります。
マイクロマネジメントは論外として、マネージャーが何から何まで決めるということに対して違和感を持つチームもあるのではないかと思います。
抽象化して考えると、チームのケイパビリティの見積もりを見誤り、デリゲーションが合意できていない場合にこのような問題が発生しているのではないかと思います。
うまく噛み合っている例では、
このようにチームのケイパビリティに対してチームのやっていることが一致している例です。
噛み合わない例でいうと、実際にやることややりたいことがバッティングする例です。
マネージャーとしてはチームのケイパビリティを考慮してその少し外側を守備範囲にするとよさそうです。
マネージャーには答えを持っていてほしい
一方で、マネージャーには答えを持っていて欲しい！という声もあると思います。
なぜこれをやるんですか？会社の状況は今後どうなりますか？今のチームはこの先どうなりますか？・・などなど。
マネージャー視点では、Whyを自分の言葉で話せるようにするということは非常に重要な要素ではあると理解しつつも、正直あまり見えていないこともあるのではないかと思います。
組織を動かすために一定蓋然性のある戦略を力強く発信するケースもありますが、実際にはやってみないとわからないことだらけなのです。
だから、この先どうなりますか？と聞かれてもなかなか回答が難しいケースもあるかと思います。
じゃあマネージャーがやっていることって何なの？というと、
「現場の情報をかき集めて蓋然性の高い方向性を示す」
ということかなと思います。
この「方向性を示す」ことと「答えを持っている」ことが混同されやすいのです。
だから改めて言います。
マネージャーは最初から答えを持っていることはほとんどありません。
しかし、一つ意識しておきたいことは、答えに辿り着くための思考は誰よりもすべき、ということは言えます。
戦略というのは最も考え抜いた人が一番いいものを出せると思います。
「マネージャーだから答えを持っているだろう」という期待には応えられないですが、「マネージャーだから一番考えているだろう」という期待には応えるべきだなと思っています。
理想的には、現場もマネージャーも具体から抽象までのケイパを備えており、効率的な役割分担としてデリゲーションが整理されている状態が理想かなと思います。
また実際にはWhatやHowは不確実性にまみれているため、その点でも一緒に検証を進められるような状態が理想だなと思います。
まとめ
マネージャーあるある？かもしれないネタを取り扱ってみました。
雑にまとめるとチームの状況をみてマネージャーとして発揮するバリューをアジャストするといいんじゃないかな、あとアジャストしか結果も明示的に期待値コントロールしないとダメだよ！ということかなと思います。
これ以外にも一見矛盾したような問いにぶつかることは多いと思いますが構造的にみるとうまく整理できるものもあると思います。
良きマネージャーライフを！
RSGT2022 ふりかえり
RSGT2022に行ってきましたのでそのふりかえりです。
私自身は2018から参加し始めて2019,2020と参加をしてきました。
今回初めてプロポーザルが通り、個人的には感慨深い参加となりました。 （昨年はプロポーザル出していたものの自身の環境の変化が大きくあり結局参加を見送ってしまいました）
発表してきた内容は以下です。
発表は現職での取り組みに基づいたものですが、やはりその転機になったのは2020〜2021で自分が今後何に取り組んでいくのか非常に悩んだことが大きかったと思います。
マネジメントに振り切ってからまた現場に戻りがっつりエンジニアとして手を動かしたことでそこでの取り組みをこうして対外的に発表できたことはまさに幸運としか言えず、ご縁に感謝しています。
発表に関してフィードバックなどあればぜひTwitter上で言及くださればと思います。
さて、久しぶりに参加したRSGTはどうだったかという話もしていきます。
登壇体験の良さ
今回初登壇でしたが、オンライン・オフラインのハイブリッド開催2年目ということで運営的には昨年からのアップデートがしっかり盛り込まれているのだと感じました。
こちらにもあるように、オンラインの登壇側もZoomで画面共有するだけで始められるようになっているというのは非常にやりやすかったです。 クライアント側の差分をZoomが一定吸収してくれるし、切り替え的にもスムーズで理にかなった仕組みだなーと尊敬しました！
目的・ゴールに向かう
Keynoteなどで言われていたメッセージとしてプロダクトの目的やゴールにフォーカスしようという話が多くなされていたように感じました。
#RSGT2022 Day1の感想としては、プロダクトの目的について共通認識作っていきましょうという話が多かったように感じる。
— Yoshiki Iida / ログラス (@ysk_118) 2022年1月5日
言葉にすると自明感すごいんだけど人が増えてくると地味に難しいところでもある。
意識的にやっていかないといけないところ。
このへんの話は言葉にすると当たり前だけど実践するのが難しいところで今もちょうど向き合っているようなところなのでせやな、、となりました。
プロセスとかマインドセットの話からビジネスにフォーカスされてきているのはとてもよいことだなと思います。
セッションでもゴールに関する話が多くありました。
リーダーシップの実践者の発表が増えて欲しい
発表や参加者の反応などをみていてもっとリーダーシップの実践の発表が増えてきたらいいなーと思っています。
初日の冒頭で川口さんが言っていたように、ここにいるみんながえらくなってリーダシップを発揮してくれたらいいんですよ、という話がもっと実践知として集まる場になったらいいなと思ったりしています。
反応とかをみていて、「うちのマネージャーはこうではない」みたいな反応もあったなーと個人的には感じていて、「自分がマネージャーやりました！」みたいな話が増えてくると個人的には面白い。
現場vsマネージャーみたいな構図が消えて現場もマネージャーも同様に苦悩しているし楽しんでいるみたいなギャザリングをみてみたい。
どうしても経営とかの領域になるとよくわからない何かという扱われ方をされがちなのだけど、そこをうまく巻き込んだりそこに侵食していくことは全然できるので個人的にはそういう話を継続的にしていこうと思う。
ゴールや目的はしいては会社の存在意義につながるのでアジャイルにやる範囲を広げて行った時に避けては通れないんだよな。
終わってからの会話
RSGTは終わってからもDiscordでゲリラ的に会話がなされていることも多く、面白い特徴だなと思ったりしています。
ふらっと入ってもいい話がきけたりするので、夜中とかにみてみるとよいかもしれません。
こんな会も開催されていました。
いつも知り合いとばかり話してしまってなかなか増えてなかったのですがこちらでいろいろな人と話せたので主催いただいたなべさんありがとうございました。
言葉にできない何か
今回はDiscordで運営の話や昔のアジャイル界隈の話などもたくさん聞くことができ、RSGTに関わる人がどんな思いでこれに関わっているのかというところを知れたのがとてもよかったです。
ブログ的には、
これも、これから飛べる以下も最高だったのでぜひ読んでみてほしい。
やっぱり何かを長く続けるというのは頑張りすぎると長続きしない、ではどうするかというとやる人自体が楽しめるようにするということと期待値をコントロールする、ということなんだろうな、と思った。（思ったというかそういう話も聞いた）
自分もコミュニティ的にはアジャイルチームを支える会にしばらく関わっていて毎月アジャイルに関する相談室的なことをしているわけですが、運営方針は徹底してエコ、です。本業が忙しすぎるので準備が極力いらない形に収束していて、それでいて少しでも何かしら価値のあることを届けられているというちょっとした貢献感で成り立っています。
一方で自分自身は会場で積極的に場を盛り上げたりとかは苦手なので基本的には乗っかるスタイルだったりするのですが、それも懇親会でKiroさんから乗っかってくれる人がいるから場が成り立つのであってそれも大事だよって言ってくれてそれもそうやなと思ったりしました。
何度も出てますが、やりたくなったらやればよくて、そういった人の取り組みがつながってできているのがRSGTという場で、、言葉にできないのですがこの場を作ってきてるすべての人にリスペクトです。
久しぶりにポエムポエムした文章を書いたな。。
今年も1年よろしくお願いいたします。
現場に戻って1年が経った
この1年の草の状況です。
2020年7月1日からフリーランス化、2020年10月1日からログラスjoinというかんじで現場に戻ってから1年が経過してました。
その前の1年は完全に砂漠でしたのでだいぶ緑化に成功したかんじです。
やったこと
- フリーの間はまずRails比率高めで物量をこなすかんじにした
- とにかく手を動かすことに慣れる
- プロジェクトの中で手を動かすことに慣れたらKotlinなど未知の分野にも手を広げる
- 手を動かすために必要なこと（プロジェクトの交通整理など）も積極的に進めて手を動かす状況を作り出す
よかったこと
- これまでのキャリアの中で型のある言語に触れてこなかったので型のある開発体験を知れたこと
- 「何を受け取るのかわかる、何を返すのかわかる」ことがこんなに素晴らしいとは・・！
- IDEのパワフルさを知った
- フルスタック（死語？）にいろいろ手を出せたこと
- 現職では元々サーバーサイド得意勢が多い中、フロントもやれるようにならんとな、というところで率先して手を出しにいけた
- GASやデータ基盤まわりもやれた
- 地味にシェル芸が役に立った
- 雰囲気でやっていた設計の議論が腹落ちしてきたこと
- ドメインを駆動するとはなんなのか？
- それぞれのレイヤの責務
- 責務に対してどのようなテストを書くべきか？
- など
課題
- まだ雰囲気でやってることは多い
- 特にフロント
- 覚えゲーみたいなところもあるので
- 覚えれば使えるけどちょっと踏み込んだ設計やパフォーマンスチューニングとかはそれがどういう思想でどう作られているかみたいなところも知らないといけない
- Kotlinもまだ使いこなしているとは言えない
- 依存関係を使いこなして責務や知識をうまく整理するみたいなところがまだおぼつかない
- Spring Bootはもう無限に大地が広がっているかんじ
- 何をどう伸ばして行くか定まっていない
- チョットデキル領域を持ってみたいと思うがまだイメージ持てていない
- こうやって書き出してみるとできていないことが整理されるのでこれを継続していくでもいいかもしれない
- アウトプットしてない
- コミット的な意味でのアウトプットはもちろんしてるのだが
- 対外的なプレゼンス向上という意味では全然アウトプットしてないのでそろそろしていく
ということで2週目駆け出しエンジニア引き続きがんばります。
2020年末近況
お久しぶりです。
前回はフリーランスになった時点でフリーランス視点での記事を書いていたのですが、気付いたら会社員に戻っていました。
そしてこんな記事を書きました。
これがそこそこ読まれまして、自分のやってきたことも多少は関心持ってもらえるようになったのだなとしみじみ思ったわけです。
改めて何もわからないなと思った
が、しかし、最近現場に戻ってみて自分のやってきた活動をもう一度よく見直してみる機会が何度かあったのです。
知り合いからのお声がけで他社でマネジメントのことを話したり、
このへんの記事を読んだりして、具体的なレベルで自分のやったことと他の人のアウトプットをフラットな立場から比較できるようになったわけです。
そうすると、思ったより自分のやっていたことが大したことではないなと思うようになりました。
マネジメントに関わっているときは常にプレッシャーがかかるので、どこかで「俺も頑張っているし・・」と実際のアウトプットの評価を歪めてしまっていたように思いました。
ただでさえしんどいのにこれ以上しんどい思いなんかしたくないわけです。
しかしながら、いざ環境を変えてフラットな視点でふりかえってみると結構見えていなかったものや見えないようにしていたものがあったのだな、と感じました。
これ自身は短期的にはそれでいいようにも思うし、でもその状態でずっと続けるのは良くないだろうなと思います。
結果的に自分が分かったような気になっていたアジャイルもマネジメントもまだまだわかってないことが多そうだなと感じた次第です。
学びを追求していくこと
おそらく、現時点でもこれまでの経験を元にどんな質問に対しても自分なりの解釈は述べられるとは思います。
しかし、このままではその回答内容がなかなかアップデートされないかもなと思い始めました。
新しい価値や発見へのアプローチが滞っているからです。
目の前のことに追われていくとだんだんそういう活動が減っていきます。
大変なことをこなしているのになぜか成長感は得られない。そして他人に説明するのが難しい。でもとても仕事をしたかんじはする。
こういう良くない状態になっていきます。
仕事の中で学びを設計する余裕が取れなくなるとただ時間を浪費してしまいかねないので外からの視点を意図的に入れる必要があるのだろうと思います。例えばコーチングとか。
- 作者:ロナルド・Ａ・ハイフェッツ,マーティ・リンスキー
- 発売日: 2018/10/03
- メディア: Kindle版
この本に出てくる「バルコニーに立つ」がまさにそれなんだろうと思います。
現場でもがくということと、バルコニーから現場を俯瞰してみるということ。これらを同時にできるようになるとよいと書かれてはいるがとても難しい。
なんなら自分は自力ではバルコニーに立てなかったので、何らか手を打つ必要があったのだと思うくらいです。
両方の視点でみる
逆に今はどうかというと、割と両方の視点で自分の行動も組織の動きもみていたかもしれないと気付きました。
Githubの草をみてもわかるとおりここ数年で一番ちゃんとコードを書いているし、一方で組織的な話をしないでもない。
この両面をセットでどこまでスケールさせられるかチャレンジになるのだろうなと思っています。
