結局は、人 / In the end, people value

結局は、人
Developers Summit 2023
1
Masato Ishigaki
February 9, 2023

View Slide

2
About me
石垣雅人
DMM.com
PF事業本部第1開発部部長 / VPoE室 / α室
・エンジニア新卒入社
・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020）
・連携 : 『スモールチームが武器になる時代へ』（ProductZine）
@i35_267
@i35_267
@i35_267

View Slide

3
Outline

View Slide

4
- Target
- プロジェクトマネージャー / プロダクトマネージャー / クリエイター
- Outline
- 問題提起
- プロジェクトの失敗率は、69%
- 「人」に纏わるプロジェクトの失敗あるある
- アプローチ
- 集合知 / Swarmingを意識する
- 事例
- “Disagree & Commit”の精神
- チームの”存在価値”を振り返る
- 1 : n と 1 : 1
Outline

View Slide

5
- Outline
- 問題提起
- アプローチ
- 事例
- 1 : n と 1 : 1
Outline

View Slide

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%

View Slide

7
引用 : 図表 7-3-4 予定どおりにならなかった要因(複数回
答)(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)
プロジェクトの失敗率は、約69％
[仮説]
人・チームのあり方の
影響度が大きい

View Slide

8
- Outline
- 問題提起
- アプローチ
- 事例
- 1 : n と 1 : 1
Outline

View Slide

9
「人」に纏わるプロジェクトの失敗あるある
1. ブリリアントジャークの存在
- 優秀だけど、協調性を乱す人
- 「腐ったリンゴの実験」by オーストラリア
- 性格が悪い人
- 怠け者
- 周りを暗くする人
- といった特性をもつ人をチームに投入
- 結果として、攻撃的な人が1人入っただけで、チームの生産性は30〜
40パーセント低下する
- 特にリーダー層が当てはまるとプレゼンスに大きな影響力を与える
- 受け入れる側の問題もあり

View Slide

2. ホフスタッターの法則
- 「もうすぐできる」はだいたいウソ
- 作業にはいつでも予測以上の時間がかかるものである
- 「明日か、明後日には終わります」っていうのは、大抵明
後日になりますね
- それによってスケジュールが後ろへ
- = 不確実性の誤認。信頼度の未達。
3. パーキンソンの法則
- 「仕事の量は、完成のために与えられた時間をすべて満た
すまで膨張する」
- スケジュールを伸ばしても伸ばしても、結局ぎりぎりに
ローンチすることになる
- = スコープクリープ問題
- 技術負債とリファクタリング
10

View Slide

11
4. ブルックスの法則
- 遅れているプロジェクトに要因追加してもさらに遅れる
- 新しい人員へのオンボーディングコスト
- または、オンボーディングコストを避けないことからくる
生産性の悪化
- = マネージャーからチームへの信頼度の未達
さまざまな要因・法則はあるにしろ、
根底の部分では人と人との関わり合いの中が生まれる問題だと思っている
→ 人と人との関わり合い = 集合知を知ることでアプローチしてみる

View Slide

- Outline
- 問題提起
- アプローチ
- 事例
- 1 : n と 1 : 1
Outline
12

View Slide

Photo by David Clode on Unsplash
13
“群れ” として捉える
= Swarming　

View Slide

“群れ” として捉える
- 私たちは、”群れながら” 開発をしている
- 個人では限界があるため、人は複数人で作業をしてスケールさせている。
チーム開発が良い例
- なぜか。不確実性が高い事業環境下、予算が尽きる前にできるだけ早く市
場へ投入して、イテレーティブな仮説検証を経て稼がなければ、事業が死
んでしまう。
- 一方、自分たちを “群れている” と認識することは少ない
- 色々な「個」と「個」の集まりがチームだとすると、個のメンタルモデル
から来る “群れ方” は違う。私たちがチーム開発する上での問題（出来事）
は、”群れ方”の構造と行動パターンに起因する
- 氷山モデルを例とすると、そのチーム特有のメンタルモデル -> 構造 -> 行
動パターンがあって、はじめて出来事（事象）がある。
- 群れ方は、そこにいる人・構造・環境によって変わってくる
Photo by Amir on Unsplash
14

View Slide

15
群知能（Swarm Intelligence）
Photo by Johnny Chen on Unsplash
- なぜ、動物（鳥や魚）は統率された行動ができるのか。
- 群れ = 自己組織化している（無意識に自律的な秩序を持つ）
- 秩序の例。魚の大群。複雑系に見えて実はとてもシンプルな論理
- 1. 前の個体を追うこと
- 2. 横の個体と速度を合わせること
- 秩序の例。アリの群衆は、どうやって最短ルートで餌場にたどり
着くのか。なぜアリの集団は、遅いルートを選ばないのか
- マーキングによる行動の観察

View Slide

16
なぜ、群れているのか理解する
Photo by David Clode on Unsplash
- なぜ、私たちは群れているのか
- 生物学的に見ても、強い敵や難しい課題が目の前に現れたとき単独で行動する
よりも、統一された集団行動によって、1対1では敵わない敵に勝てるかもし
れないということを本能的に知っている。いわゆる、恐怖。
- どうやったら強い敵に勝てるかをフィードバックをもとに徐々に学習して理解
していく。
- 群れている状態とは何か
- “群れる"の本質は、何かの対象に対して集団が相互作用しながらも自然と同じ
方向を向いて、前に進んでいるということであり、個々がそのメリットを体系
的に理解していること。
- 本能的に「ひとりで進むよりも皆と協力して"群れ"ながら進んだ方が良い結果
を生む」と判断できることである。

View Slide

17
チーム開発でいう “群れる” とは
Photo by Hugo Rocha on Unsplash
- チームは、”群れながら” 作ることを前提にしている
- アジャイルには “Swarming” という概念がある。
- ProductBacklog（作るべき対象）に対して、チームメンバーが “群がり” な
がら、一定の秩序をもち（イベント）優先度順にゴールに向けて作り上げてい
く。
- “群れ” = 自律的な秩序をもった自己組織化された集団でなければいけない。
そうでなければ破綻する（うまくいかない）し、コミュニケーションはうまく
いかない。逆に群れて作らなければ、それはアジャイルではない。
- “群がる” 粒度を考える
- アイテム単位でペアプロ / モブプロするのが良いのか、SprintBacklog単位で
群がって作るのかは、組織 = 個と個、環境によって変えていく必要がある。
- 可観測性を高めながら、観測していく。

View Slide

タックマンモデルのフェーズを意識する
形成期
(forming)
混乱期
(stoming)
統一期
(norming)
機能期
(performing)
t
成熟度
探り合い混乱役割自己組織化
必ず、ここからスタート→
18
それぞれに理想のチームは違う
パターン・ランゲージが必要

View Slide

19
集合知（Swarming）や組織フェーズを意識しやすくするアプローチの
勘所3つ紹介
● 意識 : “Disagree & Commit”の精神
● 定期 : チームの”存在価値”を振り返る
● 運用 : 1:nと1:1

View Slide

- Outline
- 問題提起
- アプローチ
- 事例
- 1 : n と 1 : 1
Outline
20

View Slide

21
“Disagree and commit”の精神
ベースのメンタルは、”Disagree and Commit”で行う
==== 
「私はある部下に事態を私の見方で見るようにと一生懸命説得を試みた。彼は容易に同調しようとしなかった。 
そして最後にこう言った。「グローブさん、私を説得しようとしても無理ですよ。 
それよりも、どうして私を説き伏せようと意地を張るんですか。私はすでにあなたの言うとおりにしますと答えているんですから」。私は黙ってし
まった。困惑した。なぜだかわからなかった。ずいぶん時間が経ってからわかったのだが、私が言い張ったのは事業の運営にほとんど無関係の
ことで、単に自分の気分を良くするためだった。それだからこそ困惑したのである。」（p284） 
 
「複雑な問題では容易に全面的な一致を見ることなどない。部下が自体を変えることを約束するなら、真面目に取り組んでいると考えるべきであ
る。ここで重要な言葉は“呑める”ということばである。（中略）仕事上の必要と気持ちの安らぎとを混合すべきではない。事態を動かすのに、部下
はあなたの側に立つ必要はない。あなたとしては、決められた行動のコースを追いかけると部下に約束させる必要があるだけだ。」（p283） 
 
引用 : https://www.amazon.co.jp/review/R38KB2KFTPB457 

View Slide

22
チームの”存在価値”をふりかえる
- プロジェクトではなく、チームの”存在価値”を振り返る
- チームに対する認識と期待値をすり合わせる
- Q. タックマンモデルでいうと今はどこだと思うか？
- Q. このチームに対して期待していることは何？
- Q. 良いエンジニアの定義ってどんな人？
- タックマンモデルでいう「機能期」はチームごとに違う
- 期待値・価値観の共有を行い、認知とすり合わせを行う

View Slide

23
Q. タックマンモデルでいうと今はどこだと思うか？
形成期
(forming)
混乱期
(stoming)
統一期
(norming)
機能期
(performing)
実際の意見 
 
- （機能期）完全な機能期ではないが、主語がチームやユーザー、プロダクトになっているのが良い。完全ではないが、エンジニアリン
グとしては機能期。  
 
 
- （統一期）まだ、個人としてもリーダーに完全に頼ってしまっている部分がある。役割がふあふあしている。  
認識のズレやメンバーの考え方を
知ることができる

View Slide

24
Q. このチームに期待していることはなに？
- テックリードになりたい。  
- スキルを上げながらも採用プロセスにも関わっていきたい  
実際の意見
- チームの仕事を回したい。チームをグロースさせていきたい  
- 再現性に強い組織、不確実性に強い組織を作っていきたい  
- 設計にこだわりたい。
 

View Slide

25
Q. 良いエンジニアの定義ってどういう人？
実際の意見
- ちゃんと話しを聞ける人（妥協しない） 
- 突っ走んない人（妥協しない） 
- SNS・社内SNSに悪口を書かない人（妥協しない） 
- スキル的に向上心、成長率が高い人（妥協しない） 
- チーム開発が向いている人（妥協しない） 
- 問題を問題だと言える人 
- プロダクト目線を持っている人 
- 問題解決力が高い 
- 設計のサボらない人 
- 自分が持っている意見を言える人 
- 世の中のセオリーを含めてこういう風に寄せていくと良いというのが言える人 
チームですり合わせることで、自分はそうならないようになる
チームのカルチャードックになるので採用プロセスにも使える

View Slide

26
3つのQで、理想のチームを理解していく
- Q. タックマンモデルでいうと今はどこだと思うか？
- → 現在地点の確認
- Q. このチームに対して期待していることは何？
- → 期待値の確認
- Q. 良いエンジニアの定義ってどんな人？
- → 価値観の確認

View Slide

1 : n と 1 : 1
1 : n はキックオフでしかない
文化形成は、愚直に1 : 1で伝える
27

View Slide

- Target
- プロジェクトマネージャー / プロダクトマネージャー / クリエイター
- Outline
- 問題提起
- アプローチ
- 事例
- 1 : n と 1 : 1
Outline
28

View Slide

結局は、人 / In the end, people value

結局は、人 / In the end, people value

Masato Ishigaki / 石垣雅人

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured

Transcript