📝

明日の開発カンファレンス2023参加報告

2023/11/01に公開

明日の開発カンファレンス2023に参加したので報告します。

https://fod.connpass.com/event/296513/

質の高い内容の発表ばかりで、良いカンファレンスでした。

明日の開発カンファレンスとは

・明日の開発カンファレンスだけど今日やっているカンファレンス
・他では話していないような実際の業務・経験ベースのキレイじゃない(生々しい)話を聞けるかもしれない
・2017から開催しているカンファレンス。久々のオフライン開催

こんな方におすすめです!
・システム開発のリーダー、CTO、テックリード
・開発組織に属する方
・これからリーダーを目指す方
・数々のチャレンジを経た現場経験からの、生の声をたくさん聞きたい方
・非技術者でも、開発者や開発チームとのコミュニケーションを改善する糸口をつかみたい方

会場ではWifi、コーヒーの配布や充電エリアがあったりして、長時間のイベントを快適に過ごせるようになっていました。会場も広く、密にならない配慮がされていました。
いくつかのセッションのあとには短時間の休憩時間があったのも良かったです。中身の濃い発表が多かったので休憩なしでは集中力が続かなかったと思います。
あとはお昼スタートなのは早起きが苦手なエンジニアにとってはありがたい配慮です。

来年も開催されるようであれば参加したいです。

メモ

資料は共有されていないので、メモの共有だけ。

開発組織を立て直す技術

尾藤さん。

4回のcto経験を経てどうやってctoのスキルをみにつけていったのか。

1回目のctoは正論を振りかざす。周りの失敗を攻める。 開発中心でマネジメントやってなかった

人望を失い自分から人が離れているのを感じた

大きく反省して自分自身を変えることを決意

アンガーマネジメントに着手

5.6年かけてコントロールできるようになってきた

二回目のctoでマネジメントに向き合った

営業系の会社にしてはよい開発組織を作れたが、 ビス側との溝ができてしまった。

技術的な事情を理解してもらうのが難しく、悪い意味でサンクチュアリをつくってしまった

ビズとテックがタッグを組むことが重要

スキル

マネジメント

非itとの向き合い方やコミュニケーションのやりかた

を身に着けた

どうやって成長していくか

成長とはなにか?

スキルを身につける

できないことができるようになる

良質な成果を一定の再現性をもって出せる能力がスキル

  • まぐれはスキルに入らない

経験学習のサイクルを回す

開発組織をどうやって立て直すのか

制約理論toc

ザゴールとかにのってる有名なやつ

ビズとテックは最初は仲良いけど、だんだん仲悪くなる。

開発が遅くなりビズの不満がたまる

あしのひっぱりあいになる

推論のはしご

不都合な結果がおこる

無意識の偏見から相手の裏を推論する

不遜な態度をとっていると思い込み怒りの感情を感じる

推論のはしごをのぼってはいけない。

共同して真の課題に向き合う。

戦う敵を間違えずに味方を増やす。

ブリリアントジャークへの対処。

組織全体の生産性が下がる

そもそも採用しない。どうやって?

嫌われてでも対処しないといけない。

4時間くらい1on1したこともある。

ネガティブフィードバックするのも大事だけど、人事評価も反映させる。

開発組織作りについて

かえがきくか、有能か無能の中で一番価値がないのは、

換えが聞かない有能。

換えがきく有能を組織においていくのが重要。

これを実現するには仕組み化していく。

開発組織の仕組み化

4つのマネジメントをごちゃごちゃにしない。

RACIチャート?

計画的偶発性理論の話。

開発生産性の可視化、改善はじめました

秋好さん。sayanetさん。

グロースチームの中には2から3人のチームが5つある。

Four Keysに近しいけいそくとのことだったが…よくわからないので社内外に相談

FourKeysとは。

デプロイの定義?

やってみたけど課題がわかりづらい

チームや個人でモニタリングするとわかるようになった。

プルリクのリードタイムが長い。長いってどれくらいだろう。

モブプログラミング、モブレビューは大事

Tech Leadの役割とチームとは何かをもう一度考えてみる

増森さん。神戸からきている。

本当にあったチームの問題

ペアの片方が多忙で崩壊したケース

決定力がなかった。タスク分解がうまくいかなかった。

技術力にたけていたがチームが崩壊

マインドセットが足りなかった。

Tech Leadの役割に関する勘違い

実は半分はコミュニケーション。

失敗から学ぶ、建設的な横断組織の作り方

栗田さん

DBRE = DBのSRE
CCoE = 企業などで情報システムのクラウド利用を推進するために設置される、全社横断型の組織

横断は0-1より1-10が求められがち (案件ノウハウ共有など)

横断組織に気軽に相談できるようになっているかどうか?

モチベーションや価値貢献の課題がある。モチベについてはコニュニティへの参加が良い。

SREチームビルドと開発組織との関わり、そしてPlatform Engineeringへの取り組み

橋本さん

インフラの上位職的なポジションとしてSREを活用

Platform Engineering = 開発者の生産性を加速させる

なんでもSREという状況に対して、Platform Engを足すと、多少解消できる

業務の境界はどんどん曖昧になっているので、業務分掌を整理する

SWE、PE、SREのゆるい三層構造を目指したい

Discussion