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

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

kadoppe
March 27, 2019

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

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

kadoppe

March 27, 2019
Tweet

More Decks by kadoppe

Other Decks in Programming

Transcript

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

    / Tech Lead - タウンワーク開発チームで事業⽬標達成のための
 技術課題特定と解決のための体制構築 ・ 推進 - Software Engineer / Head of Engineering - CXプラッ トフ ォーム “KARTE” の開発 - 個⼈ ・ チームが常に最⾼のパフ ォーマンスを出すための
 環境づく り プロフィール
  2.  フラット型組織 %FW #J[ "DDFMFSBUPS 組織階層がフラット(に近い) - 固定的な上下関係が存在しない - 有機的にチームが形をかえていく

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

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

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

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

    であることを認識する
 =普通にやってたらゴールに到達できない - ⾃分達が良いと思うものをつく ってだす
 だめなら壊して作り直す (トライ&エラー) - 頂いた要望を汎⽤的に⼤き く解く ϙΠϯτ̏
  7.  フォーカス 〜選択と集中のための開発サイクル〜 - プロダク トとして“いま”注⼒すべきテーマ
 をもとにチームをつく る - テーマは決めきらない

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

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

    ① ② ③ ④ ⑤ ①「こんな事できたらいいのに」 「つかいづらい」 
 「つかいかたわからない」 ② フィードバック/問い合わせを頂く ③ すぐに最終回答をせずエンジニアに
 まずフィードバック ④ プロダク トの全ユーザーに価値を返せる形が ないか検討してプロダク トに反映 ⑤ 多くのクライアン ト様に価値を届ける
  10.  難しい(⾯⽩い)ポイント 組織のスケールにあらがう
 (あらがうこと⾃体が重要なわけではないが) - メンバーの多様性があがる - コミュニケーションが複雑になる - コンフリク

    トやお⾒合いがおきやすくなる - ルールやプロセスで解決しようとする - 組織を細分化 ・ 階層化して解決しようとする ਓ਺͕૿͑Δͱɾɾɾ ⾃然に⾝を任せると硬直化したスピードの遅い
 チームができあがる(=開発チームは⾃然と死ぬ)
  11.  難しい(⾯⽩い)ポイント 個⼈的に学んだこと
 〜スケールにあらがうことは可能〜 - 課題じゃないものを課題にしない - ⽬的がなんだったのかを思い出す - ルールやプロセスで安易に解決しない

    - ⾃分達や今の状況にと って最適なやり⽅で ⽬の前の課題を解き続ける ͋ͨΓ·͚͑ͩͲେ੾ͳ͜ͱ 今の形をすこしずつ変えながら ⽬的を達成するために⾃分たちを調整していく
  12.  アジェンダ まとめ - 世界に通⽤するプロダク トをつく る - 本質的なことに向き合うための組織 -

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