2023/2/9 Developers Summit 2023 登壇資料
結局は、人Developers Summit 20231Masato IshigakiFebruary 9, 2023
View Slide
2About me石垣 雅人DMM.comPF事業本部 第1開発部 部長 / VPoE室 / α室・エンジニア 新卒入社・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020）・連携 : 『スモールチームが武器になる時代へ』（ProductZine）@i35_267@i35_267@i35_267
3Outline
4- Target- プロジェクトマネージャー / プロダクトマネージャー / クリエイター- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline
5- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline
6プロジェクトの失敗率は、約69％「工期」「予算」「品質」の3つのカテゴリーで分け、プロジェクト規模を「100人月未満」「100〜500 人月未満」「500人月以上」で分類したデータ引用 : 図表 7-3-1 プロジェクト規模別・年度別 システム開発の工期遵守状況(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)工数 : 34.4% 予算 : 37.0% 品質 : 23.0%3つの割合の平均 = 31%前後になります。何かしらの原因で満足いかない可能性が 約69%さらに、工数・予算・品質のすべてが予定通りに終わる確率は、工期（34.4％）× 予算（37.0％）× 品質（23.0％）で約3%
7引用 : 図表 7-3-4 予定どおりにならなかった要因(複数回答)(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)プロジェクトの失敗率は、約69％[仮説]人・チームのあり方の影響度が大きい
8- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline
9「人」に纏わるプロジェクトの失敗あるある1. ブリリアントジャークの存在- 優秀だけど、協調性を乱す人- 「腐ったリンゴの実験」by オーストラリア- 性格が悪い人- 怠け者- 周りを暗くする人- といった特性をもつ人をチームに投入- 結果として、攻撃的な人が1人入っただけで、チームの生産性は30〜40パーセント低下する- 特にリーダー層が当てはまるとプレゼンスに大きな影響力を与える- 受け入れる側の問題もあり
2. ホフスタッターの法則- 「もうすぐできる」はだいたいウソ- 作業にはいつでも予測以上の時間がかかるものである- 「明日か、明後日には終わります」っていうのは、大抵明後日になりますね- それによってスケジュールが後ろへ- = 不確実性の誤認。信頼度の未達。3. パーキンソンの法則- 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」- スケジュールを伸ばしても伸ばしても、結局ぎりぎりにローンチすることになる- = スコープクリープ問題- 技術負債とリファクタリング「人」に纏わるプロジェクトの失敗あるある10
114. ブルックスの法則- 遅れているプロジェクトに要因追加してもさらに遅れる- 新しい人員へのオンボーディングコスト- または、オンボーディングコストを避けないことからくる生産性の悪化- = マネージャーからチームへの信頼度の未達「人」に纏わるプロジェクトの失敗あるあるさまざまな要因・法則はあるにしろ、根底の部分では人と人との関わり合いの中が生まれる問題だと思っている→ 人と人との関わり合い = 集合知を知ることでアプローチしてみる
- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline12
Photo by David Clode on Unsplash13“群れ” として捉える= Swarming
“群れ” として捉える- 私たちは、”群れながら” 開発をしている- 個人では限界があるため、人は複数人で作業をしてスケールさせている。チーム開発が良い例- なぜか。不確実性が高い事業環境下、予算が尽きる前にできるだけ早く市場へ投入して、イテレーティブな仮説検証を経て稼がなければ、事業が死んでしまう。- 一方、自分たちを “群れている” と認識することは少ない- 色々な「個」と「個」の集まりがチームだとすると、個のメンタルモデルから来る “群れ方” は違う。私たちがチーム開発する上での問題（出来事）は、”群れ方”の構造と行動パターンに起因する- 氷山モデルを例とすると、そのチーム特有のメンタルモデル -> 構造 -> 行動パターンがあって、はじめて出来事（事象）がある。- 群れ方は、そこにいる人・構造・環境によって変わってくるPhoto by Amir on Unsplash14
15群知能（Swarm Intelligence）Photo by Johnny Chen on Unsplash- なぜ、動物（鳥や魚）は統率された行動ができるのか。- 群れ = 自己組織化している（無意識に自律的な秩序を持つ）- 秩序の例。魚の大群。複雑系に見えて実はとてもシンプルな論理- 1. 前の個体を追うこと- 2. 横の個体と速度を合わせること- 秩序の例。アリの群衆は、どうやって最短ルートで餌場にたどり着くのか。なぜアリの集団は、遅いルートを選ばないのか- マーキングによる行動の観察
16なぜ、群れているのか理解するPhoto by David Clode on Unsplash- なぜ、私たちは群れているのか- 生物学的に見ても、強い敵や難しい課題が目の前に現れたとき単独で行動するよりも、統一された集団行動によって、1対1では敵わない敵に勝てるかもしれないということを本能的に知っている。いわゆる、恐怖。- どうやったら強い敵に勝てるかをフィードバックをもとに徐々に学習して理解していく。- 群れている状態とは何か- “群れる"の本質は、何かの対象に対して集団が相互作用しながらも自然と同じ方向を向いて、前に進んでいるということであり、個々がそのメリットを体系的に理解していること。- 本能的に「ひとりで進むよりも皆と協力して"群れ"ながら進んだ方が良い結果を生む」と判断できることである。
17チーム開発でいう “群れる” とはPhoto by Hugo Rocha on Unsplash- チームは、”群れながら” 作ることを前提にしている- アジャイルには “Swarming” という概念がある。- ProductBacklog（作るべき対象）に対して、チームメンバーが “群がり” ながら、一定の秩序をもち（イベント）優先度順にゴールに向けて作り上げていく。- “群れ” = 自律的な秩序をもった自己組織化された集団でなければいけない。そうでなければ破綻する（うまくいかない）し、コミュニケーションはうまくいかない。逆に群れて作らなければ、それはアジャイルではない。- “群がる” 粒度を考える- アイテム単位でペアプロ / モブプロするのが良いのか、SprintBacklog単位で群がって作るのかは、組織 = 個と個、環境によって変えていく必要がある。- 可観測性を高めながら、観測していく。
タックマンモデルのフェーズを意識する形成期(forming)混乱期(stoming)統一期(norming)機能期(performing)t成熟度探り合い 混乱 役割 自己組織化必ず、ここからスタート→18それぞれに理想のチームは違うパターン・ランゲージが必要
19集合知（Swarming）や組織フェーズを意識しやすくするアプローチの勘所3つ紹介● 意識 : “Disagree & Commit”の精神● 定期 : チームの”存在価値”を振り返る● 運用 : 1:nと1:1
- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline20
21“Disagree and commit”の精神ベースのメンタルは、”Disagree and Commit”で行う==== 「私はある部下に事態を私の見方で見るようにと一生懸命説得を試みた。彼は容易に同調しようとしなかった。 そして最後にこう言った。「グローブさん、私を説得しようとしても無理ですよ。 それよりも、どうして私を説き伏せようと意地を張るんですか。私はすでにあなたの言うとおりにしますと答えているんですから」。私は黙ってしまった。困惑した。なぜだかわからなかった。ずいぶん時間が経ってからわかったのだが、私が言い張ったのは事業の運営にほとんど無関係のことで、単に自分の気分を良くするためだった。それだからこそ困惑したのである。」（p284） 「複雑な問題では容易に全面的な一致を見ることなどない。部下が自体を変えることを約束するなら、真面目に取り組んでいると考えるべきである。ここで重要な言葉は“呑める”ということばである。（中略）仕事上の必要と気持ちの安らぎとを混合すべきではない。事態を動かすのに、部下はあなたの側に立つ必要はない。あなたとしては、決められた行動のコースを追いかけると部下に約束させる必要があるだけだ。」（p283） 引用 : https://www.amazon.co.jp/review/R38KB2KFTPB457
22チームの”存在価値”をふりかえる- プロジェクトではなく、チームの”存在価値”を振り返る- チームに対する認識と期待値をすり合わせる- Q. タックマンモデルでいうと今はどこだと思うか？- Q. このチームに対して期待していることは何？- Q. 良いエンジニアの定義ってどんな人？- タックマンモデルでいう「機能期」はチームごとに違う- 期待値・価値観の共有を行い、認知とすり合わせを行う
23チームの”存在価値”をふりかえるQ. タックマンモデルでいうと今はどこだと思うか？形成期(forming)混乱期(stoming)統一期(norming)機能期(performing)実際の意見 - （機能期）完全な機能期ではないが、主語がチームやユーザー、プロダクトになっているのが良い。完全ではないが、エンジニアリングとしては機能期。 - （統一期）まだ、個人としてもリーダーに完全に頼ってしまっている部分がある。役割がふあふあしている。 認識のズレやメンバーの考え方を知ることができる
24チームの”存在価値”をふりかえるQ. このチームに期待していることはなに？- テックリードになりたい。 - スキルを上げながらも採用プロセスにも関わっていきたい 実際の意見- チームの仕事を回したい。チームをグロースさせていきたい - 再現性に強い組織、不確実性に強い組織を作っていきたい - 設計にこだわりたい。
25チームの”存在価値”をふりかえるQ. 良いエンジニアの定義ってどういう人？実際の意見- ちゃんと話しを聞ける人（妥協しない） - 突っ走んない人（妥協しない） - SNS・社内SNSに悪口を書かない人（妥協しない） - スキル的に向上心、成長率が高い人（妥協しない） - チーム開発が向いている人（妥協しない） - 問題を問題だと言える人 - プロダクト目線を持っている人 - 問題解決力が高い - 設計のサボらない人 - 自分が持っている意見を言える人 - 世の中のセオリーを含めてこういう風に寄せていくと良いというのが言える人 チームですり合わせることで、自分はそうならないようになるチームのカルチャードックになるので採用プロセスにも使える
26チームの”存在価値”をふりかえる3つのQで、理想のチームを理解していく- Q. タックマンモデルでいうと今はどこだと思うか？- → 現在地点の確認- Q. このチームに対して期待していることは何？- → 期待値の確認- Q. 良いエンジニアの定義ってどんな人？- → 価値観の確認
1 : n と 1 : 11 : n はキックオフでしかない文化形成は、愚直に1 : 1で伝える27
- Target- プロジェクトマネージャー / プロダクトマネージャー / クリエイター- Outline- 問題提起- プロジェクトの失敗率は、69%- 「人」に纏わるプロジェクトの失敗あるある- アプローチ- 集合知 / Swarmingを意識する- 事例- “Disagree & Commit”の精神- チームの”存在価値”を振り返る- 1 : n と 1 : 1Outline28
i35_267
dena_tech
sbtechnight
sagara
renjikari
line_developers_tw
stefafafan
makamaka
takakuni
aarron
phodgson
quramy
stephaniewalter
thekraken
hursman
notwaldorf
lara
malarkey
mongodb
davidbonilla
geeforr