『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をした

こんにちは。増田（id:masutaka26）です。発表が無事終わり、何かゲームでも買おうかなと思ってます。

さて、フィードフォースでは毎週金曜日 16:00 から、社内技術勉強会を開催しています。当番制の持ち回りで技術に関連したことを発表します。

先週金曜日は私の当番で『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をしました。

技術チーム以外の方もたくさん聞きに来てくれて、ありがたかったです。🙏

発表の内容

前回含めて、これまでの発表は全てコードが登場していました。今回のようなコードが登場しないマネジメントの話は、内容が拡散しがちで難しかったです。結局まとまりませんでした...。

今回は敢えて後から読めるプレゼン資料にしました。なのでプレゼン資料としては冗長な書き方になっています。

まとめるとこんな内容です。

コミュニケーションの不確実性を解消することが、マネジメント（やチームビルディング）に必要なはず
そのため自ら場に飛び込んで、情報の非対称性を解消していった
これからもソフトウェアを書くこと以外に課題解決の手段があればやっていく
そして徐々にマネジメントにかける時間を減らし、コードを書く時間を増やしていく

今思えば、話し忘れたことがポロポロと出てきます。

そもそもチームメンバーは自走できる方々で、ホワイトボード整理の時も方針だけ話したら勝手に整理されていった
- 私は方向性を決めただけ
チームに入りたてのときは少々オーバーリアクションを心がけ、徐々に普通に戻していく。
- 何考えている人か分かってもらうことで、その後のコミュニケーションをスムーズにする

完璧な発表などありませんね。

発表の感想

付箋紙に感想を書いてくれました。は私からのコメントです。

ジョハリの窓の紹介ありがとうございます。勉強になります！
- 私も『エンジニアリング組織論への招待』で初めて知りました。数年前にプロダクトオーナーの学習をした以来ですから...
自分はまだマネジメントからは程遠い存在なのですが、話しかけやすいオーラを出すことや、くだらないと思うことも質問することなどは、今すぐにでも実行出来るし、目指すことだと思いました。ありがとうございました！
- はい、個々が意識することが自走するチームや、個々のリーダーシップに繋がると思います
共感できる良い話でした
- あざす！
初公開の画像が見られて良かったです
- お粗末さまでした...
早くインフラ朝会にもどって来てください
- 今回の件が落ち着いたらインフラ朝会にもどりますよ。待っていてくださいね！
必要な情報とそうでもない情報の整理はものすごい HP/MP を消費しそう
- そうですね...
マネジメントの成果はすぐには結果に現れないかも？どの位の頻度で振り返るべきなのか？
- イテレーションごとの振り返りで、チームを観察すれば良いです。マネジメントの成果かどうかは重要ではないと思います
◯◯を支える技術
- 次回はコードの話をしよう...
知識科学やり直さなきゃ・・・
- 私は今回で終了ですw
チームの問題点を発見して、それを解決する手段を選ばないスタンスがすごい
- もう必死ですよ（笑）
「内心ではなく行動に注目する」は、認知行動療法などでも使われていますね（最近のトレンド？）
- へぇ〜
なかなかボリュームある資料でしたが、作るのにどれくらいかかったのか気になります
- 先週土曜日の夜に草稿を作り「これでいけそう」という感触を得て、今週は平日の夜２日くらいで整理をしました。話す内容については一ヶ月くらい前から頭の中で考えたり、『エンジニアリング組織論への招待』を全部読んだりしてました
最近疲弊してそうで心配でしたが、今日の発表で色々アウトプットしてもらって安心しました
- 気にかけて頂いてありがとうございます。これからも安心安全のマスタカをお届けして参ります
うなずきすぎて首もげる
- ありがとうございます。参考になったことが各チームに還元されるとうれしいです
マスタカさん自体はマネジメントよりコード書く方が好きなんでしょうか？
- そうですね。引き篭もってコードを書きたいです
ますたかさんのおかげでチームがちゃんと回りはじめた気がします
- そう言って頂けるとうれしいです。今がスタート地点だと捉え、精進してまいります
増田さんが参加されてから何かがスムーズになった実感があります（情報や知識だけでなく）
- うれしいですね。マネジメントは空気のような存在が良いと考えています
マネジメントってどうやるか？のテクニックの面もあるけど、誰がやるか？の面も大きい気がしてます
- そうですね。例えば入ったばかりの職場だと、信頼関係を築くことから始まると思います。今回は同じ会社ということと、過去に一緒に働いたメンバーがいたことに助けられました
EC Booster のこれからに期待しています！
- 💪
「場に飛び込む」「正しく伝わったと思わない」肝に銘じます！
- よろしくお願いします！
「エンジニアが発見した課題の解決フロー」読みたいです
- Slack で書いたとおり、割と普通のフローです。発表で話したエンジニア以外の方からの依頼と整合性を合わせてこうしました。まだ始めて間もなく 1 イテレーションも回してない状態ですがね...
  1. Issue を作ると EC Booster waffle.io の Planning カラムに入る
  2. 次の開発ミーティングで Planning カラムを空にする
  3. スプリントでは Sprint Backlog に集中する
feedforce だとマネジメントオンリーじゃなくて、開発+マネジメントが最強という話を昨日クリストフとした
- 最強かは分かりませんが、コードも分かったほうが捗ると思います
仕事でもプライベートでも、コミュニティ内でオープンな発信をする人が多いと、円滑に物事が進みやすいなと考えられました。その逆もまた然りだったので...。かつ、人に伝えるときは具体的にするというのも大切かと思いました
- 他人は自分でないので、分かりやすく具体的なコミュニケーションが大事ですね
- え、誰？（困惑）