2019.08.21 ϓϨΠυͷΤϯδχΞ͔ΒΈͨ ʰਖ਼͍͠΋ͷΛਖ਼ͭ͘͘͠Δʱ גࣜձࣾϓϨΠυ໳࿬߃ฏ

⾨脇 恒平 @kadoppe 2017.04 - 現在 プレイド - 顧客体験プラッ トフ ォーム 「KARTE」 の 開発 - 開発チーム全体のプランニング - ⽣産性向上の仕組み検討 プロフィール Software Engineer / Head of Engineering 2012.02 - 2014.01 シェアウィズ - CTO / Co-Founder - 無料オンライン学習プラッ トフ ォーム 「ShareWis」 の開発 ・ 運営 2014.04 - 2017.03 リクルートテクノロジーズ - タウンワーク開発チームTech Lead等 - 事業⽬標達成のための技術課題特定 と解決推進

アジェンダ - プレイドの開発スタイル - 正しいものを正し く つくれているか？ - 正しいものを正し く つく るために 今⽇の内容 - 「正しいものを正し く つく る」 と聞いたときに
 個⼈的にあたまに浮かんだことを共有します - ふんわりしてるので皆さんと壁打ちしたいです - このあとのパネルディ スカッション / 懇親会で
 議論のネタにしていただけると

プレイドの開発スタイル

前提：これが唯⼀の正しい⽅法ではない
 状況が変われば最適な⽅法も変わる

プレイドの開発スタイル 前提 ・ 環境 - 正解がない中でつくる - 世の中にも⾃分たちの中にも答えがない - 世界観や市場を⾃分たちがつく る - タイムリミットがある中でつくる - 崖の上から⾶び降りながら、 
 ⾶⾏機をつく る その上で世界に通⽤する強いプロダクトを素早く作りたい

プレイドの開発スタイル そのために必要なこと - トライ＆エラーを繰り返す - どれだけ⾼速に回せるか - どれだけ学びの質を⾼められるか - 個⼈の創造⼒ ・ 発想を最⼤限活かす - プロセスではなく⼈を信じる

プレイドの開発スタイル 開発チームの
 プランニングをする上で
 ⼤事にしているポイント - ルールをできるだけ決めない - 硬直化してしまう要因は極⼒なく す - 常にゼロベースで考える - 前提にとらわれず常に最適な選択をする - プロダクトアウトを⼤事にする - よいと思うものをつく って出す - だめなら壊してつく りなおす

例） フォーカス 〜プレイドにおける開発サイクル〜 - ２−３ ヶ⽉の期間で開発サイクルを区切る - プロダク トとして“いま”注⼒すべきテーマ
 をもとにチームをつく る - テーマは決めきらない （余⽩をつく る） - 最適なパフ ォーマンスを出すためのやり⽅を
 各チームで考えて決める - 次フ ォーカスは改めてゼロベースで考える プレイドの開発スタイル フォーカス1 フォーカス2 フォーカス3 SRE Performance Redesign API Self-serve App Dev Environment Product Datahub Platform Core API

プレイドの開発スタイル さらに詳しく知りたい⽅は - https://speakerdeck.com/kadoppe/ huratutoxing-zu-zhi- niokeruenziniaringumanezimento - https://blog.plaid.co.jp/n/n21725f77231c

正しいものを正しくつくれているのか？

前提にとらわれない形でチャレンジはできている でも、まだ⾃信を持って "YES" とはいえない

正しいものを正しくつくれているのか？ プロダクトの理想と現実
 ギャップはまだまだ⼤きい - コンセプトがまだ⼗分に実現できていない - 例) あなたのサービスに今誰がきて、 どうしてい るか知っていますか？ - より直感的に知り、 理解するためには⼤きな ジャンプアップが必要 - プロダクトアウトのクオリティが⾜りてない ֬ೝ͢Δ جຊαʔϏε΍͝ར༻ํ๏Λ͝঺հ͠·͢ɻ ͓ಘͳಛయ΍໾ཱͭ৘ใ͕ຬࡌͰ͢ɻ ॳΊͯͷํ΁ 6*رؠ؎ش٦׌ֽוזַזַ♳麦׃זְծ➙ ״׶إٔؗ،حف׃׋ְהְֲ倯䗳铣דׅկ UIرؠ؎ش٦ָ濼׏גֶֻץֹ 7אךرؠ؎ٕٝ٦ٕ DESIGN RULES » CHECK ׆׏ה⢪ִ׷،؎ذي׌ֽ׾䲧ִת׃׋կ ֿך堣⠓׾ֶ鋅鷕׃זֻկ 窫㼎ծ 妜׃ְ ౙͷओ໾ɺ Ξ΢λʔ COLLECTION OUTER 嗚稊勴⟝׾㼰׃㢌刿ׅ׷׌ֽדծ֮ז׋ך椚 䟝ך暟⟝ח⳿⠓ִ׷〳腉䚍ָ넝ֻז׶תׅկ 勴⟝׾㢌ִג嗚稊׃ג׫גֻ׌ְׁկ ׀䋞劄ך暟⟝כ 鋅אַ׶תׇ׿ד׃׋ַ ꟗׄ׷ ⼀⼈⼀⼈に合わせた 顧客体験を提供 Webサイト/アプリユーザの⾏動を
 顧客ごとにリアルタイムに解析

正しいものを正しくつくれているのか？ 優先順位の問題 やりたく てもやれてないことが多い - ⼈数は限られているがやるべきこと/
 やりたいことは無限⼤にある - フ ォーカスすることを決めること
 =フ ォーカスしないことを決めること - ⾯を広げるための新機能開発
 vs 既存機能の磨き込み - こういうことをプロダク トで実現したい - もっと簡単に使いこなせるようにしたい - 管理画⾯がもっとサクサク動いてほしい - 不具合なく安定して動いてほしい ྫʣ͍͕ͨ͑ͨͨ͑͜͜ΒΕͯͳ͍ϓϩμΫτ΁ͷϑΟʔυόοΫ 現時点でみえている「正しいもの」にプロダクトが 追いついていない

正しいものを正しくつくれているのか？ チームのチャレンジと学習 理想に到達可能なスピードで進めてる ？ - チームや個⼈が攻めた⽬標にチャレンジできて いるか - さらに攻めた⽬標にチャレンジできるよう
 チームに学びが蓄積されているか - ⼿なりの進捗 ・ 成⻑の連続では理想に到達でき ない感 - チームはフォーカスの⽬標に向かって進む → 短期的な視点に引っ張られる - フォーカスごとに体制が頻繁に変わる
 → 学びは個⼈に暗黙的に蓄積される - エンジニアの⼈数が少しずつ増えてきた
 → 過去の学びのキャ ッチアップが難しい

正しいものを正しくつくるために

適切な⽬的のもと 適切な⽅法・順番で 問題を適切に解いていくしかない

そのために最近個⼈的に ⼤事だと思う考え⽅・スタンス

正しいものを正しくつくるために 開発⼒はすべてを癒す - 問題が解けないなら解けるようになるしかない - スピードが遅いなら速めるしかない - 優先順位の問題もその他感情的な⾊々も
 個⼈やチームの開発⼒が⾼まれば誤差になる - どうやるかよりも"誰"が"どんな環境"でやるか - 個⼈ - 必要な知識 ・ 技術を⾝につける - ⼿戻りのない設計や実装 - 単純に⼿を速く する - 環境 - ムダをなく す / 本質的な時間を増やす

正しいものを正しくつくるために いろんな視座を⾏き来する - 視座をあげると⾒えなかったものが⾒える - 取りうる選択肢が広がる - ちいさな問題が問題じゃなくなる - 測定できたり、 ⾒えてるもの以外の要因で、 物 事は成功したり、 失敗したりする
 -「この会社をどうつく っていくか」 -「このプロダクトをどうつく っていくか」 -「このチームをどうつく っていくか」 -「⾃分をどうつく っていくか」

正しいものを正しくつくるために 結果/学びが伴う形で⾏動する - 正しいことを⾔う: -200点 - Issue をつく る: -100点 - Issue を解く/推進する: 0点 - 結果を出す: 50点 - 結果から学びを得て次に繋げる: 100点 - ⾃分が正しいと思うものを正しいと思うや り⽅で、 まず⾃分がやってみる - ⾏動することで結果を残す - 結果から⾃分や周りが学ぶ

おわりに

おわりに プレイドのエンジニア (@kadoppe) からみた
 『正しいものを正しくつくる』 - 正しいものを正しくつくれているか？ - 前提にとらわれない形でチャレンジ中 - まだまだギャ ップは⼤きい - 正しいものを正しくつくるため⼤事だと
 思う考え⽅ ・ スタンス - 開発⼒ / 視座の移動 / 
 結果 ・ 学びが伴う⾏動

No content