Upgrade to Pro — share decks privately, control downloads, hide ads and more …

フラット型組織におけるエンジニアリングマネジメント

45a72486b4481b73b963a74ecaefc76f?s=47 kadoppe
March 27, 2019

 フラット型組織におけるエンジニアリングマネジメント

Startup Meetup Ginza #2 「エンジニアリング・マネージャーが語る、スタートアップのリアル」での登壇資料です。

45a72486b4481b73b963a74ecaefc76f?s=128

kadoppe

March 27, 2019
Tweet

Transcript

  1. 2019.03.27 Startup Meetup Ginza #2 ϑϥοτܕ૊৫ʹ͓͚Δ
 ΤϯδχΞϦϯάϚωʔδϝϯτ גࣜձࣾϓϨΠυ໳࿬߃ฏ

  2.  ⾃⼰紹介

  3. ⾨脇 恒平 @kadoppe 〜2017年3⽉ 株式会社リクルートテクノロジーズ 2017年4⽉ 株式会社プレイド ⼊社 - Software Engineer

    / Tech Lead - タウンワーク開発チームで事業⽬標達成のための
 技術課題特定と解決のための体制構築 ・ 推進 - Software Engineer / Head of Engineering - CXプラッ トフ ォーム “KARTE” の開発 - 個⼈ ・ チームが常に最⾼のパフ ォーマンスを出すための
 環境づく り プロフィール
  4. None
  5.  アジェンダ 今⽇の内容 - プレイドのフラッ ト型組織とその⽬的 - プレイドのエンジニアリングマネジメン トの ポイン

    ト - 具体的な例 - 難しい (⾯⽩い) ポイン ト
  6.  今の組織や⽂化は⾊んな⼈の努⼒と⼯夫の積み重ね ⾃分の解釈を伝えます これから⼤いに変わる可能性あり

  7.  フラット型組織?

  8.  フラット型組織 %FW #J[ "DDFMFSBUPS 組織階層がフラット(に近い) - 固定的な上下関係が存在しない - 有機的にチームが形をかえていく

    - ビジネスサイドとの境界が曖昧で
 いろんな視点から物事を⾒れる - 流動的なリーダーは存在
  9.  フラット型組織 %FW #J[ "DDFMFSBUPS 機会がフラット - 個⼈の裁量が⼤きい - 議論は常にフラッ

    ト - 個⼈の発想⼒、 学習⼒、 モチベーションを
 最⼤限活かす - 責任と情熱とやりきる⼒があるという前提
  10.  フラット型組織 なぜフラット型組織? 〜フラットにすることが⽬的ではない〜 - プロダク トで実現したい⼤きな世界観がある - ⾃分達 /

    世の中に答えがあるわけではない - プロダク トはまだまだ未完成 - 「崖の上から⾶び降りながら⾶⾏機を作る」 - 個⼈のとがった発想を最⼤限活かす - 学習のためのトライ&エラーを繰り返す - これまでの前提に囚われず壊しながら進む ੈքʹ௨༻͢ΔͭΑ͍ϓϩμΫτΛz͢͹΍͘zͭ͘Δ これらに本質的に向き合う時間を
 極⼒増やすための組織 લఏ
  11.  プレイドにおける エンジニアリングマネジメント

  12.  やってることはシンプル

  13.  プレイドにおけるエンジニアリングマネジメント 世界で通⽤するつよい
 プロダクトをすばやくつくる ⊗ 個⼈のパフォーマンスを 最⼤化する - ルールを決めない -

    常にゼロベースで考える - プロダク トアウ トを⼤事に ࣮ݱ͍ͨ͜͠ͱ ポ イ ン ト
  14.  プレイドにおけるエンジニアリングマネジメント ルールを決めない(できるだけ) 〜プロセスではなく⼈を信じる〜 - 個⼈の発想⼒を最⼤限発揮させる - ガチガチのプロセスで硬直化させない - ルールを作りたくなった場合は⽴ち⽌まる

    - 必要最低限の仕組みだけ⽤意 ϙΠϯτ̍
  15.  プレイドにおけるエンジニアリングマネジメント 常にゼロベースで考える 〜これまでの前提にとらわれない〜 - これまでのアウ トプッ トを壊すことも視野に - “いま”解くべき課題にフ

    ォーカス - 最⾼の結果を出すためのやり⽅を探す - 前提にとらわれず⽬的に⽴ち返って考える - 社外や過去にうまくいったことを鵜呑みに しない ϙΠϯτ̎
  16.  プレイドにおけるエンジニアリングマネジメント プロダクトアウトを⼤事に 〜⾃分達で答え ・ 価値をつく りにいく〜 - まだ進捗 0.2%

    であることを認識する
 =普通にやってたらゴールに到達できない - ⾃分達が良いと思うものをつく ってだす
 だめなら壊して作り直す (トライ&エラー) - 頂いた要望を汎⽤的に⼤き く解く ϙΠϯτ̏
  17.  具体的な例

  18.  フォーカス 〜選択と集中のための開発サイクル〜 - プロダク トとして“いま”注⼒すべきテーマ
 をもとにチームをつく る - テーマは決めきらない

    (余⽩をつく る) - 最適なパフ ォーマンスを出すためのやり⽅を
 各チームで考えて決める - 次フ ォーカスは改めてゼロベースで考える 具体例 フォーカス1 フォーカス2 フォーカス3 SRE Performance Redesign API Self-serve App Dev Environment Product Datahub Platform Core API θϩϕʔε ϧʔϧΛܾΊͳ͍
  19.  KARTE Live 〜 冬休みの宿題 〜 具体例 ϓϩμΫτΞ΢τ - あるエンジニアが冬休みにつく

    ってきたのが
 きっかけ - エンジニアが良い / 必要だと思う機能を
 想像してつく って、 まずはすぐにリリースする - 気軽な発想から⽣まれたものが
 ブラッシュアップされてプロダク トなっていく
  20.  フィードバックの反映 〜フィードバックをプロダク トアウトに〜 具体例 ϓϩμΫτΞ΢τ ΫϥΠΞϯτ ϓϩμΫτ 1-"*%ϝϯόʔ ΤϯδχΞ

    ① ② ③ ④ ⑤ ①「こんな事できたらいいのに」 「つかいづらい」 
 「つかいかたわからない」 ② フィードバック/問い合わせを頂く ③ すぐに最終回答をせずエンジニアに
 まずフィードバック ④ プロダク トの全ユーザーに価値を返せる形が ないか検討してプロダク トに反映 ⑤ 多くのクライアン ト様に価値を届ける
  21.  難しい (⾯⽩い) ポイント

  22.  難しい(⾯⽩い)ポイント 組織のスケールにあらがう
 (あらがうこと⾃体が重要なわけではないが) - メンバーの多様性があがる - コミュニケーションが複雑になる - コンフリク

    トやお⾒合いがおきやすくなる - ルールやプロセスで解決しようとする - 組織を細分化 ・ 階層化して解決しようとする ਓ਺͕૿͑Δͱɾɾɾ ⾃然に⾝を任せると硬直化したスピードの遅い
 チームができあがる(=開発チームは⾃然と死ぬ)
  23.  難しい(⾯⽩い)ポイント 今の開発チームはどうか? 「⽇々問題は起きる」 「でも死んでない」 「もっといい形はあるだろうが」 「あらがいながらチームは成⻑している」 「なぜだろう?」

  24.  難しい(⾯⽩い)ポイント 個⼈的に学んだこと
 〜スケールにあらがうことは可能〜 - 課題じゃないものを課題にしない - ⽬的がなんだったのかを思い出す - ルールやプロセスで安易に解決しない

    - ⾃分達や今の状況にと って最適なやり⽅で ⽬の前の課題を解き続ける ͋ͨΓ·͚͑ͩͲେ੾ͳ͜ͱ 今の形をすこしずつ変えながら ⽬的を達成するために⾃分たちを調整していく
  25.  まとめ

  26.  アジェンダ まとめ - 世界に通⽤するプロダク トをつく る - 本質的なことに向き合うための組織 -

    ルールをつく らない - ゼロベースで考える - プロダク トアウ トを⼤事に - スケールにあらがうこと (でもあらがえる) ϓϨΠυͷϑϥοτܕ૊৫ͱͦͷ໨త ϓϨΠυͷΤϯδχΞϦϯάϚωδϝϯτͷϙΠϯτ ೉͍͠ʢ໘ന͍ʣϙΠϯτ
  27. None