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

⾃⼰紹介

⾨脇 恒平 @kadoppe 〜2017年3⽉ 株式会社リクルートテクノロジーズ 2017年4⽉ 株式会社プレイド ⼊社 - Software Engineer / Tech Lead - タウンワーク開発チームで事業⽬標達成のための
 技術課題特定と解決のための体制構築 ・ 推進 - Software Engineer / Head of Engineering - CXプラッ トフ ォーム “KARTE” の開発 - 個⼈ ・ チームが常に最⾼のパフ ォーマンスを出すための
 環境づく り プロフィール

No content

アジェンダ 今⽇の内容 - プレイドのフラッ ト型組織とその⽬的 - プレイドのエンジニアリングマネジメン トの ポイン ト - 具体的な例 - 難しい （⾯⽩い） ポイン ト

今の組織や⽂化は⾊んな⼈の努⼒と⼯夫の積み重ね ⾃分の解釈を伝えます これから⼤いに変わる可能性あり

フラット型組織？

フラット型組織 %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-"*%ϝϯόʔ ΤϯδχΞ ① ② ③ ④ ⑤ ①「こんな事できたらいいのに」 「つかいづらい」 
 「つかいかたわからない」 ② フィードバック/問い合わせを頂く ③ すぐに最終回答をせずエンジニアに
 まずフィードバック ④ プロダク トの全ユーザーに価値を返せる形が ないか検討してプロダク トに反映 ⑤ 多くのクライアン ト様に価値を届ける

難しい （⾯⽩い） ポイント

難しい（⾯⽩い）ポイント 組織のスケールにあらがう
 （あらがうこと⾃体が重要なわけではないが） - メンバーの多様性があがる - コミュニケーションが複雑になる - コンフリク トやお⾒合いがおきやすくなる - ルールやプロセスで解決しようとする - 組織を細分化 ・ 階層化して解決しようとする ਓ਺͕૿͑Δͱɾɾɾ ⾃然に⾝を任せると硬直化したスピードの遅い
 チームができあがる（＝開発チームは⾃然と死ぬ）

難しい（⾯⽩い）ポイント 今の開発チームはどうか？ 「⽇々問題は起きる」 「でも死んでない」 「もっといい形はあるだろうが」 「あらがいながらチームは成⻑している」 「なぜだろう？」

難しい（⾯⽩い）ポイント 個⼈的に学んだこと
 〜スケールにあらがうことは可能〜 - 課題じゃないものを課題にしない - ⽬的がなんだったのかを思い出す - ルールやプロセスで安易に解決しない - ⾃分達や今の状況にと って最適なやり⽅で ⽬の前の課題を解き続ける ͋ͨΓ·͚͑ͩͲେ੾ͳ͜ͱ 今の形をすこしずつ変えながら ⽬的を達成するために⾃分たちを調整していく

まとめ

アジェンダ まとめ - 世界に通⽤するプロダク トをつく る - 本質的なことに向き合うための組織 - ルールをつく らない - ゼロベースで考える - プロダク トアウ トを⼤事に - スケールにあらがうこと （でもあらがえる） ϓϨΠυͷϑϥοτܕ૊৫ͱͦͷ໨త ϓϨΠυͷΤϯδχΞϦϯάϚωδϝϯτͷϙΠϯτ ೉͍͠ʢ໘ന͍ʣϙΠϯτ

No content