Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フラット型組織におけるエンジニアリングマネジメント
Search
kadoppe
March 27, 2019
Programming
1
1.2k
フラット型組織におけるエンジニアリングマネジメント
Startup Meetup Ginza #2 「エンジニアリング・マネージャーが語る、スタートアップのリアル」での登壇資料です。
kadoppe
March 27, 2019
Tweet
Share
More Decks by kadoppe
See All by kadoppe
一年間スタートアップのCTOをやってきて学んだこと
kadoppe
1
560
未知の顧客にとっても価値あるプロダクトを生み出す
kadoppe
2
1.6k
プレイド開発チームにおけるチーム・ジャーニー ver.202010
kadoppe
4
900
不確実性の高い世界のなかで、非連続な成長を生み出す / Developers Summit 2020 Summer
kadoppe
1
1.7k
プレイド開発チームにおけるチーム・ジャーニー
kadoppe
12
4.9k
プレイドのエンジニアからみた「正しいものを正しくつくる」
kadoppe
0
1.9k
Pebble + JavaScriptでつくるスマートウォッチ
kadoppe
0
190
Firefox OSでSVGをつかってみた
kadoppe
0
95
まだ間に合うHTML5 - Yeomanで追いつけ!高速Webアプリ開発
kadoppe
0
130
Other Decks in Programming
See All in Programming
Elm Form Validation
bkuhlmann
0
510
CA.swift19 恋するAIアプリ開発の裏側
oskmr
0
360
見た目から始める生産性向上
ikumatadokoro
7
840
Site Reliability Engineering for GMO
pyama86
8
1k
Node.js v22 で変わること
yosuke_furukawa
PRO
9
3.4k
Java 22 Overview
kishida
1
180
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
0
240
雑に思考を整理する技術と効能
konifar
60
29k
Anthropic Cookbook のおすすめレシピ
schroneko
7
970
What We Can Learn From OSS
inouehi
0
420
Hanami and htmx
bkuhlmann
0
210
VSCodeでのDatabricks開発もお勧めしたい/I would also recommend Databricks development with VSCode.
kazumain
0
250
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
2
3.4k
Why Our Code Smells
bkeepers
PRO
331
56k
A designer walks into a library…
pauljervisheath
200
23k
GraphQLとの向き合い方2022年版
quramy
32
12k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
GraphQLの誤解/rethinking-graphql
sonatard
50
9.2k
Web development in the modern age
philhawksworth
202
10k
In The Pink: A Labor of Love
frogandcode
138
21k
Designing the Hi-DPI Web
ddemaree
276
33k
Ruby is Unlike a Banana
tanoku
96
10k
Code Reviewing Like a Champion
maltzj
514
39k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Transcript
2019.03.27 Startup Meetup Ginza #2 ϑϥοτܕ৫ʹ͓͚Δ ΤϯδχΞϦϯάϚωʔδϝϯτ גࣜձࣾϓϨΠυ߃ฏ
⾃⼰紹介
⾨脇 恒平 @kadoppe 〜2017年3⽉ 株式会社リクルートテクノロジーズ 2017年4⽉ 株式会社プレイド ⼊社 - Software Engineer
/ Tech Lead - タウンワーク開発チームで事業⽬標達成のための 技術課題特定と解決のための体制構築 ・ 推進 - Software Engineer / Head of Engineering - CXプラッ トフ ォーム “KARTE” の開発 - 個⼈ ・ チームが常に最⾼のパフ ォーマンスを出すための 環境づく り プロフィール
None
アジェンダ 今⽇の内容 - プレイドのフラッ ト型組織とその⽬的 - プレイドのエンジニアリングマネジメン トの ポイン
ト - 具体的な例 - 難しい (⾯⽩い) ポイン ト
今の組織や⽂化は⾊んな⼈の努⼒と⼯夫の積み重ね ⾃分の解釈を伝えます これから⼤いに変わる可能性あり
フラット型組織?
フラット型組織 %FW #J[ "DDFMFSBUPS 組織階層がフラット(に近い) - 固定的な上下関係が存在しない - 有機的にチームが形をかえていく
- ビジネスサイドとの境界が曖昧で いろんな視点から物事を⾒れる - 流動的なリーダーは存在
フラット型組織 %FW #J[ "DDFMFSBUPS 機会がフラット - 個⼈の裁量が⼤きい - 議論は常にフラッ
ト - 個⼈の発想⼒、 学習⼒、 モチベーションを 最⼤限活かす - 責任と情熱とやりきる⼒があるという前提
フラット型組織 なぜフラット型組織? 〜フラットにすることが⽬的ではない〜 - プロダク トで実現したい⼤きな世界観がある - ⾃分達 /
世の中に答えがあるわけではない - プロダク トはまだまだ未完成 - 「崖の上から⾶び降りながら⾶⾏機を作る」 - 個⼈のとがった発想を最⼤限活かす - 学習のためのトライ&エラーを繰り返す - これまでの前提に囚われず壊しながら進む ੈքʹ௨༻͢ΔͭΑ͍ϓϩμΫτΛz͘͢zͭ͘Δ これらに本質的に向き合う時間を 極⼒増やすための組織 લఏ
プレイドにおける エンジニアリングマネジメント
やってることはシンプル
プレイドにおけるエンジニアリングマネジメント 世界で通⽤するつよい プロダクトをすばやくつくる ⊗ 個⼈のパフォーマンスを 最⼤化する - ルールを決めない -
常にゼロベースで考える - プロダク トアウ トを⼤事に ࣮ݱ͍ͨ͜͠ͱ ポ イ ン ト
プレイドにおけるエンジニアリングマネジメント ルールを決めない(できるだけ) 〜プロセスではなく⼈を信じる〜 - 個⼈の発想⼒を最⼤限発揮させる - ガチガチのプロセスで硬直化させない - ルールを作りたくなった場合は⽴ち⽌まる
- 必要最低限の仕組みだけ⽤意 ϙΠϯτ̍
プレイドにおけるエンジニアリングマネジメント 常にゼロベースで考える 〜これまでの前提にとらわれない〜 - これまでのアウ トプッ トを壊すことも視野に - “いま”解くべき課題にフ
ォーカス - 最⾼の結果を出すためのやり⽅を探す - 前提にとらわれず⽬的に⽴ち返って考える - 社外や過去にうまくいったことを鵜呑みに しない ϙΠϯτ̎
プレイドにおけるエンジニアリングマネジメント プロダクトアウトを⼤事に 〜⾃分達で答え ・ 価値をつく りにいく〜 - まだ進捗 0.2%
であることを認識する =普通にやってたらゴールに到達できない - ⾃分達が良いと思うものをつく ってだす だめなら壊して作り直す (トライ&エラー) - 頂いた要望を汎⽤的に⼤き く解く ϙΠϯτ̏
具体的な例
フォーカス 〜選択と集中のための開発サイクル〜 - プロダク トとして“いま”注⼒すべきテーマ をもとにチームをつく る - テーマは決めきらない
(余⽩をつく る) - 最適なパフ ォーマンスを出すためのやり⽅を 各チームで考えて決める - 次フ ォーカスは改めてゼロベースで考える 具体例 フォーカス1 フォーカス2 フォーカス3 SRE Performance Redesign API Self-serve App Dev Environment Product Datahub Platform Core API θϩϕʔε ϧʔϧΛܾΊͳ͍
KARTE Live 〜 冬休みの宿題 〜 具体例 ϓϩμΫτΞτ - あるエンジニアが冬休みにつく
ってきたのが きっかけ - エンジニアが良い / 必要だと思う機能を 想像してつく って、 まずはすぐにリリースする - 気軽な発想から⽣まれたものが ブラッシュアップされてプロダク トなっていく
フィードバックの反映 〜フィードバックをプロダク トアウトに〜 具体例 ϓϩμΫτΞτ ΫϥΠΞϯτ ϓϩμΫτ 1-"*%ϝϯόʔ ΤϯδχΞ
① ② ③ ④ ⑤ ①「こんな事できたらいいのに」 「つかいづらい」 「つかいかたわからない」 ② フィードバック/問い合わせを頂く ③ すぐに最終回答をせずエンジニアに まずフィードバック ④ プロダク トの全ユーザーに価値を返せる形が ないか検討してプロダク トに反映 ⑤ 多くのクライアン ト様に価値を届ける
難しい (⾯⽩い) ポイント
難しい(⾯⽩い)ポイント 組織のスケールにあらがう (あらがうこと⾃体が重要なわけではないが) - メンバーの多様性があがる - コミュニケーションが複雑になる - コンフリク
トやお⾒合いがおきやすくなる - ルールやプロセスで解決しようとする - 組織を細分化 ・ 階層化して解決しようとする ਓ͕૿͑Δͱɾɾɾ ⾃然に⾝を任せると硬直化したスピードの遅い チームができあがる(=開発チームは⾃然と死ぬ)
難しい(⾯⽩い)ポイント 今の開発チームはどうか? 「⽇々問題は起きる」 「でも死んでない」 「もっといい形はあるだろうが」 「あらがいながらチームは成⻑している」 「なぜだろう?」
難しい(⾯⽩い)ポイント 個⼈的に学んだこと 〜スケールにあらがうことは可能〜 - 課題じゃないものを課題にしない - ⽬的がなんだったのかを思い出す - ルールやプロセスで安易に解決しない
- ⾃分達や今の状況にと って最適なやり⽅で ⽬の前の課題を解き続ける ͋ͨΓ·͚͑ͩͲେͳ͜ͱ 今の形をすこしずつ変えながら ⽬的を達成するために⾃分たちを調整していく
まとめ
アジェンダ まとめ - 世界に通⽤するプロダク トをつく る - 本質的なことに向き合うための組織 -
ルールをつく らない - ゼロベースで考える - プロダク トアウ トを⼤事に - スケールにあらがうこと (でもあらがえる) ϓϨΠυͷϑϥοτܕ৫ͱͦͷత ϓϨΠυͷΤϯδχΞϦϯάϚωδϝϯτͷϙΠϯτ ͍͠ʢ໘ന͍ʣϙΠϯτ
None