Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 #devsumi #devsumia

5,924 views

Published on

https://event.shoeisha.jp/devsumi/20200213/session/2390/

パネルディスカッションで利用したキャリアについての自分語りです。

Published in: Engineering
  • Be the first to comment

偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 #devsumi #devsumia

  1. 1. 偶然の出来事の流れに 身を任せエンジニアか らマネジメントの道に 進んだ話。 黒田 樹 @i2key #devsumi
  2. 2. 結論
  3. 3. 自分のキャリアにおいて 中途半端なビジョンを持たない 流れに身を任せる 巻き込まれ力を高める 好奇心を持ち食わず嫌いをしない
  4. 4. 一般論
  5. 5. キャリアアンカー理論 計画された偶発性理論 山登り型 川下り型 自分の適性などを見出した上で、あらかじめ設 定したキャリアゴールを目指してキャリアを積 んでいく考え方。目標を決めて登っていくこと から、登山に例えられる。 偶然の出来事にベストを尽くして対応する経験 の積み重ねで、よりよいキャリアが形成される という考え方。ある程度流れに身を任せること から、川下りに例えられる。
  6. 6. 計画された偶発性理論 川下り型 wikiより スタンフォード大学のジョン・D・クランボルツ教授らが 提案したキャリア論に関する考え方。 個人のキャリアの8割は予想しない偶発的なことによって 決定される。その偶然を計画的に設計し、自分のキャリア を良いものにしていこうという考え方。 その計画された偶発性は以下の行動特性を持っている人に 起こりやすいと考えられる。 1.好奇心[Curiosity] 2.持続性[Persistence] 3.柔軟性[Flexibility] 4.楽観性[Optimism] 5.冒険心[Risk Taking]
  7. 7. “良い波が来た時に沖にいることが大事” - 誰かの言葉 偶然の出来事 自分が対応可能である状態 海の状態は気象情報からざっく り分かるが、波自体をコント ロールすることは出来ない。 見立てることは可能。 ここはコントロール可能。 自分のできることを増やしてお く。素振りを繰り返すとか色々 なやり方はある。 波自体はコントロール出来ない (が、良い波が来そうな海に行くことはできる) コントロール出来る 自分の読み替え
  8. 8. 自分に当てはめて 振り返るアウトプットしてきたスライドがあると振り返りやすい (ということを今回実感した) https://www.slideshare.net/i2key/presentations
  9. 9. 22歳~30歳 SoR(しっかりかっちり系) & アーキテクト SIerに新卒入社 偶然の出来事(良い波) ・官公庁系の大規模開発のエンジニア。 ・メインフレームからオープン系への大規模なシステム更改。 ・当時のSOA/WS/Javaソフトウェアアーキテクチャ周りやる人いない。 偶然の出来事に対する自分の状態(沖にいるか) ・学生時代からずっとJavaしていた ・業務でもずっとJava(EJB/struts/spring/etc)だったので各論に周囲よりも相対的に詳しかった。 やったこと(波に乗る) ・業務エンジニアからアーキテクトへの染み出し ・8年くらいアプリケーションアーキテクト業務をやった  (アーキテクチャデザイン、FW実装、設計手法、開発手法のデザイン、共通処理、etc) ・見えないものを構造化して見えるようにしてハック可能にする原体験
  10. 10. 30歳~35歳 SoE(俊敏柔軟系)のエンジニア & ビジネス SIer→転職→リクルートホールディングス(当時リクルート)(別の波を求めて別の海域に移った) 偶然の出来事(良い波) ・新規事業、偶然の大ヒット。社内の投資が過度に集まり、組織のマネージメント能力を超えるまで急速 に組織が肥大化。数名のチームが50人の組織へ。 ・開発が正しく回っていないように見える。なんかビジネスと開発がギスギスしている。現場は疲弊。 偶然の出来事に対する自分の状態(沖にいるか) ・SIer時代に大小様々な開発を経験してたので、  現場でよくあるビジネスと開発の対立構造的な開発現場の力学を相対的に知ってる ・アジャイル開発に関して前職時代から日々勉強していた。知識はある状態。 やったこと(波に乗る) ・適切な優先順位付けを機能させるために、アジャイルコーチと共に組織にスクラムいれる ・P/Lを見る。減価償却とか残存簿価とか初めて知る。 ・アウトプットとして残す
  11. 11. PBL リリー ス プランニン グ 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 僕の考えた最強 の機能リスト 当時の視座・視野 適切な優先順位付け 開発の透明性 適切なリズム
  12. 12. 30歳~35歳 SoE(俊敏柔軟系)のエンジニア & ビジネス 偶然の出来事(良い波) ・開発チームのアウトプットがビジネスのアウトカムにつながっていない。 ・どんなに開発を効率化しても意味がない。 ・明らかにボトルネックが開発からビジネスにシフト。 偶然の出来事に対する自分の状態(沖にいるか) ・知的好奇心。 やったこと(波に乗る) ・ビジネスへの染み出し。 ・僕の考えた最強のアイデアをフルスイングするのではなく、失敗のリスクを最小化するための仮説検証 型価値観の定着。そのためのHOWとしての顧客開発、リーンスタートアップ、デザインシンキング、グ ロースハック。 ・アウトプットとして残す
  13. 13. PBL リリー ス プランニン グ 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 僕の考えた最強 の機能リスト やりっぱなし どんなに開発チームがスペシャルでも、チームに○○をインプットすると 結局、価値をうまない○○がチームからアウトプットされる PBLの質、超重要。 (やる必然性・エビデンスの有無) ボトルネックが 開発→ビジネスへ遷移 当時の視座・視野
  14. 14. PBL リリー ス プランニン グ 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計 測 構 築 学 習 デー タ アイ デア ビジネス仮 説リスト エンジニアリングビジネス 全部、思い込みだと前提におく。仮説検証型に移行。 染み出す 当時の視座・視野
  15. 15. 30歳~35歳 SoE(俊敏柔軟系)のエンジニア & ビジネス 偶然の出来事(良い波) ・出資先海外スタートアップの日本市場へのグロース支援する人いない。 ・日本市場へのグロースハック担当として出資先支援の話。 偶然の出来事に対する自分の状態(沖にいるか) ・新規事業のビジネスサイド、エンジニアサイド両方の経験がある。 ・アーリーステージからスケール期にかけるビジネスとエンジニアのサイド両方のかけ合わせは当時周囲 よりも相対的に得意。 やったこと(波に乗る) ・巻き込まれにいった。「やります」 ・アウトプットとして残す
  16. 16. Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 当時の視座・視野
  17. 17. 35歳~38歳 SoE&SoR 開発のマネジメント リクルートホールディングス→転籍→リクルートテクノロジーズ(別の波を求めて別の海域に移った) 偶然の出来事(良い波) ・内製開発組織において、若手の比率が高く既存事業のようなSoEとSoR両方の要素を含むような開発 組織を牽引していくおじさん枠が枯渇。 偶然の出来事に対する自分の状態(沖にいるか) ・内製開発、SIerとの開発等の過去の様々な開発現場経験を併せ持つ相対的価値 ・新規事業にて開発組織のPLを見ていた経験 やったこと(波に乗る) ・上司「マネージャーやらない?」 ・自分「やります。」 ・アウトプットとして残す
  18. 18. 35歳~38歳 SoE&SoR 開発のマネジメント 偶然の出来事(良い波) ・企画から開発を含め、組織全体におけるスループットが出ていない。(既視感) 偶然の出来事に対する自分の状態(沖にいるか) ・新規事業で散々経験したことの既存事業版。 ・既存事業がゆえ複雑に色々な力学が絡み合うが、因数分解すると同じ。 ・コードベースから事業KPIまでを接続して全体のスループットを見ることが周囲より相対的に得意。 ・ToCやリーンの感じ。極論、強くてニューゲーム。 やったこと(波に乗る) ・アウトカムにフォーカスする価値観の定着。強くてニューゲームなので、考え方も洗練されてきた。 ・フロー効率、リソース効率、ToC、システム思考的考え方の組織浸透。 ・アウトプットとして残す
  19. 19. エンジニアリングとビジネスアウトカムの関係 (コンバージョンレート改善がお題の場合) 例 当時の視座・視野
  20. 20. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 口コミ SEO SEM ETC 掲載枠検索 ¥0 利用者 クライアント 広告 ビジネス コンバージョンレート改善 = アウトカム 例:コンバージョンレート最大化に向けたUI/UX仮説検証 流入数 if(isBooked){ } アウトカム アウトカム 掲載料
  21. 21. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 複数のことをまとめて開発したときのビジネス上の実利 A B C 1つずつ開発してリリースしていくときのビジネス上の実利
  22. 22. 複数のことをまとめて開発したときのビジネス上の実利 1つずつ開発してリリースしていくときのビジネス上の実利 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える 複数の実験を 同時にやると濁る
  23. 23. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C ビジネス効果が根雪構造を取る場合、 アウトカムの積分値が最大化される取り組みをすればいい。 ・効果が同じであれば、開発規模を小さくするとか ・巨大な開発案件を砕くとか ・逆に確実に行ける(実証済み)案件はでかくてもやるとか ・開発リードタイムを短縮する(リファクタリング、自動化、etc)とか
  24. 24. 35歳~38歳 SoE&SoR 開発のマネジメント ←今ココ 偶然の出来事(良い波) ・上司「部長やらない?」 ・上司「執行役員やらない?」 偶然の出来事に対する自分の状態(沖にいるか) ・知的好奇心。 やっていること(波に乗る) ・「やります。」 ・みんなが見えていないぼんやりしていることを構造化/言語化して見えるようにして、適切な課題を設 定していく仕事。仕事内容が変わろうが、今まで、これの訓練をしてきていたように感じた。 ・アウトプットとして残す
  25. 25. → 予算構造的に自己組織化チームを成立させやすくする 例1 現在の視座・視野 予算コントロールからアジリティの高い組織構造を組み上げる
  26. 26. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟
  27. 27. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム
  28. 28. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務:コンバージョン率UP 予算ロック & 納期柔軟 責務:売上 + α 予算ロック & 納期コミット 責務:安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム 予算:目的:責任:チームが1対1の状態 投資側からすれば目 的が達成できればよ いのでHOWは自由。 あとは任せた! →チームに自治権 →現場裁量で推進 →精神論ではなく構 造的アプローチによ る自己組織化
  29. 29. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック (UI/UX改善) 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 予算枠 目的① チーム 例えば、予算枠とチームが目的単位でない場合 目的② 投資目的が混ざるの で、優先順位付けにお いて、一つ上位レイ ヤーの意思決定お伺い が発生するかもしれな い。 →現場で決めれない →現場に自治権が生ま れにくい
  30. 30. 参入する市場特性によりビジネス戦略も変わりそれが開発のやりかたに どう影響を与えるか等を俯瞰できるようになってきた。 → 参入市場におけるビジネス不確実性と開発スタイル 例2 現在の視座・視野
  31. 31. 参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制 新規市場 オーソドックスな 顧客開発 作るものがわからな い 競争なし 探索型 柔軟さに特化した開 発体制 既存市場 競合と戦う ・フォロワー戦略 ・同質化戦略 作るものが明確 当たり前品質の期待 値高い 競合で実証された機 能の実装 性能競争になる ため、経営資源 の投下量勝負に なる (経営のコミッ ト大事) 競合劣位解消の ための機能開発 を計画的になり やすい 高品質 高機能 計画駆動に特化した 開発体制で、いっき に全部盛りを作った ほうが効率が良い 既存市場 競合と戦わない 市場の再セグメント化 ・ニッチ化(例:サカゼン) ・低コスト化(例:LCC) からの顧客開発 作るものがうっすら みえている 競争なし 競争あっても勝 者はいない 探索型 柔軟さに特化した開 発体制 クローン 市場 コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した 開発体制 参入市場におけるビジネス不確実性と開発スタイル
  32. 32. →社内新規事業のアーリーステージにおいて  過度な売上目標をチームに持たせようとした場合 (アジャイルぽくやろうとして  結果的に重厚長大な計画駆動開発になっていく流れ) 例3 現在の視座・視野 上位の意思決定による力学が現場にどう伝搬するかのフォースが 見えるようになってきた。
  33. 33. Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ toC向け 新規サービス
  34. 34. Problem/Solution Fit Product/Market Fit Scaling CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention toC向け 新規サービス 事業成長を加速させ るために強めの売上 目標をもたせよう!
  35. 35. Problem/Solution Fit Product/Market Fit Scaling 売上CAC < LTV 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention 顧客単価の高いtoB サービスにしたくなる toC向け 新規サービス
  36. 36. Problem/Solution Fit Product/Market Fit Scaling 売上CAC < LTV 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention 顧客単価の高いtoB サービスにしたくなる toC向け 新規サービス 実際は・・・ toC向けの実験レベル のプロダクト品質 ただし、このまま 売っても、全く売れ ない・・・
  37. 37. Problem/Solution Fit Product/Market Fit Scaling 売上CAC < LTV 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention 顧客単価の高いtoB サービスにしたくなる toB向け機能が必要に なる。要件も高品質高 性能になる。 toC向け 新規サービス 実際は・・・ toC向けの実験レベル のプロダクト品質
  38. 38. Problem/Solution Fit Product/Market Fit Scaling 売上CAC < LTV 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention 顧客単価の高いtoB サービスにしたくなる toB向け機能が必要に なる。要件も高品質高 性能になる。 toC向け 新規サービス 実際は・・・ toC向けの実験レベル のプロダクト品質 売上計画から逆算した 計画駆動開発が始まる (かもしれない)
  39. 39. 売れるために、 ちょっとこの機能を 増やしたいんだけど 計画どおり作らねばなら ないので、変更は受け付 けません! 開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。 プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディ フェンスしたくなる。ギスギスしだす。 開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画 上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、基 本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長をス ローダウンさせていくことになる。(パーキンソンの法則:バッファはあるだけ使い果たす) (感じ悪いなあ・・) (計画どおりやれって いってんのお前だろ) (計画達成するために、 バッファいっぱい積んで おこう) 開発「側」 プランニング「側」 ←目的がすり替わる()
  40. 40. Problem/Solution Fit Product/Market Fit Scaling CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る アップセル/クロスセルに向けた性能品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って検証 最低限売れる 当たり前品質 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 売り物(プロダクト)を磨くフェーズ 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす 売り方を磨くフェーズ 売上目標の圧 デカい売上はよ Retention toC向け 新規サービス 事業成長を加速させ るために強めの売上 目標をもたせよう! 終わりの はじまり
  41. 41. その結果
  42. 42. 22歳~30歳 SoR領域 アーキテクト 30歳~35歳 SoE領域 エンジニア&ビジネス 35歳~38歳  SoE&SoR領域 開発マネジメント 受託開発:自社開発 既存事業:新規事業 SoR:SoE   開発:ビジネス エンジニア:マネージャ 計画駆動型:仮説検証型 受託開発:自社開発 既存事業:新規事業 SoR:SoE   開発:ビジネス エンジニア:マネージャ 計画駆動型:仮説検証型 受託開発:自社開発 既存事業:新規事業 SoR:SoE   開発:ビジネス エンジニア:マネージャ 計画駆動型:仮説検証型 こうなるぞ!という明確なビジョンを持たず、技術だけで はなく、何にでも興味を持ち、ひたすら川下りした結 果、意図せず、守備範囲が広がっていた。
  43. 43. 受託開発:自社開発 既存事業:新規事業 SoR:SoE   開発:ビジネス エンジニア:マネージャ 計画駆動型:仮説検証型 : : 往々にして二項対立構造(無意味かおいといて)になりがちな双方を経験したことにより、 それぞれの状況下におけるパラダイムを理解することが出来るようになり、 視座が局所最適から全体最適により向きやすくなってきた。 プログラミングをやるなら複数の言語パラダイムを理解するべきなのと近い印象。 様々なパラダイムを理解する
  44. 44. みんなが見えていないぼんやりしていることを構造化/言語 化して見えるようにして、適切な課題を設定していくことが 他の人よりもちょっとだけできるようになった。
  45. 45. Appendix ボツ案 (でもせっかく書いたのでもったいないから残しておく。)
  46. 46. 希少性自分のレアカード化 置かれている環境下での相対的な
  47. 47. 100万人に1人の存在になる方法 藤原-和博 https://www.amazon.co.jp/dp/B0822FGPHK
  48. 48. 1 100万 100万人中、1人というのは オリンピック選手と同等の希少性 100万人に1人の存在になる方法 藤原-和博 https://www.amazon.co.jp/dp/B0822FGPHK
  49. 49. 1 100 3 1 100万 100万人に1人の存在になる方法 藤原-和博 https://www.amazon.co.jp/dp/B0822FGPHK
  50. 50. 1 100人 100人中、1人になる希少性は 1万時間で到達できる見立て 例えば 1日6時間 * 240営業日/年で 7年 100万人に1人の存在になる方法 藤原-和博 https://www.amazon.co.jp/dp/B0822FGPHK
  51. 51. https://www.amazon.co.jp/dp/4873114799 プログラマが知るべき97のこと 和田 卓人 (監修), Kevlin Henney (編集), 夏目 大 (翻訳)
  52. 52. 1万時間の訓練 - Jon Jagger 「エキスパート」と呼ばれるだけの能力を身につけるには、一体、どのく らいの量の訓練が必要なのでしょうか。それについては次のようなことが 言われています。 ✓Peter Norvigは、何かでエキスパートになるには約1万時間の訓練が必 要と述べている。いわばこの1万時間というのが「マジックナンバー」と いうことになる。 ✓Mary Poppendieckも、著書「リーンソフトウェア開発と組織改革」 の中で「どんな専門的職業であれ、入念に計画された、集中的な訓練を 最低10,000時間積み重ねることとで専門家になると言う」と書いてい る。 専門的な技術や知識は、ゆっくりと徐々に身につくものです。1万時間が経 過した途端、急に身につく、というわけではありません。それでも、とも かく1万時間やる、ということが大切なのです。
  53. 53. 1 100万 1 100 1 100 1 100 * * 1万時間の投資を3回やると100万人中の1人の希少性を 論理的に作ることが可能 100万人に1人の存在になる方法 藤原-和博 https://www.amazon.co.jp/dp/B0822FGPHK 100万人と競争して1位になるのは無理ゲーでも、 100人中1位を3つなら現実感がまだ・・ある
  54. 54. 1万時間ごとにやること変えてみる 1万時間毎に逆サイドのことにトライしてみる。

×