技術にまつわる戦略思考@BCU30 2019

2019.7.6に登壇した、
BCU30の基調講演資料です。

Transcript

1. 技術にまつわる戦略思考 @BCU30 2019 @yfuka86 2019.07.06
2. 今⽇話すこと
3. 「戦略思考」 つまりは、技術にまつわる 経営のはなし
4. ⾃⼰紹介
5. ⾃⼰紹介 深澤雄太 @yfuka86 ## 株式会社AppBrew - 代表取締役 - リードエンジニア ## 経歴 - 現在24歳 - 東京⼤学⼯学部休学中 - 在学時よりフリーランスとしてスタートアップ数社に関わる - 2016年2⽉ 株式会社AppBrew設⽴ - 2017年1⽉ LIPSリリース - 2018年までに300万ダウンロード/16.5億調達
6. これまでやってきたこと
7. 創業期：プロダクトのリードエンジニアとして ・起業する前 - フリーランスとして様々なスタートアップに関わった - モバイル・ウェブフロント・サーバー⼀通り扱えた ・起業したきっかけ 社会にインパクトを⽣み出せるプロダクトを作りたい その最適な⼿段だと思ったのが起業だった ・起業してから - 「ユーザーニーズ」があるものを作ることの難しさを実感 - ４つのプロダクトを失敗させ、焦りはじめる →５つ⽬でようやく「LIPS」にたどりつく
8. 成⻑期：LIPSのテックリード兼経営者として ・プロダクトを伸ばすためなら何でもやった - エンジニア採⽤と、開発のディレクション、⼿を動かすところまですべて - マーケティングなど事業計画作成、それに基づく資⾦調達まで ・技術⼒も勿論⼤事だが、、、 - 事業成⻑のために、技術をいかに選択・運⽤するかがより⼤事と気づく - 採⽤したエンジニアにも指⽰出しではなく、 事業を理解して個々に判断してもらう
9. 僕の考える、エンジニアの「⽻化」
10. 戦略思考＝経営⽬線を⾝につけること
11. なぜエンジニアに経営⽬線が必要？
12. エンジニアが経営⽬線を⾝につけるべき理由 ・技術と経済発展は両輪 技術それ⾃体も尊いが、 - 技術を社会に実装し、経済発展を⽀える「経営」も必須 - 再投資できねば技術も発展しない ・技術の⾼度化により経営者側の技術理解が⾜りない 裏を返せば、 - 経営者に技術を伝えられる事業理解のあるエンジニアの不⾜ - ⾃ら経営者になるエンジニアの不⾜
13. 経営的⽬線で戦略的に技術を扱える エンジニアに
14. ⽬的→課題設定→仮説検証 これを、⻑期的・複合的に⾼い⽬線で
15. まず：⽬的を定める エンジニアの⽬標もいろいろ... だが、ほとんどの場合、資本主義に吸収されてしまう - 世の誰かのニーズを満たさねば⽣きていけない - どうせなら、世の中に⼤きなインパクトを出したい？ - 事業成⻑に関与できるエンジニアは価値が⾼い お⾦を稼ぎたい すごいプロダクトを 作りたい ただコードだけ 書いてたい … ⽬的 課題設定 仮説検証
16. ⽬的の定め⽅いろいろ 世の中へのインパクトを具体的な⽬標にすることをおすすめします - 今の会社でより成果を上げたい 例：今年度中に今の事業部の⽬標数値に〇〇でxx%貢献して、より責任ある仕事を獲得する - ある技術を勉強したい/広めたい 例： 3ヶ⽉以内にある技術に関するOSSを作って、1年以内に複数企業で採⽤される - ⼤きなプロダクトに貢献したい 例：1年以内に数百万⼈規模のユーザーがいるプロダクトの主要機能開発に関わる ⽬的 課題設定 仮説検証
17. 現状把握と課題抽出 ⽬的（例）：今会社で作っているプロダクトの収益増に貢献する 現状把握 - 会社の⽬標は、次の1年で1.5倍 - 今のユーザー数は⽉間100万、ユーザー単価は500円（広告300・課⾦200） - 流⼊経路は既存ユーザー・広告・検索・クチコミで、内訳がどれくらい - 滞在時間は⼀⼈当たり10分で、広告単価に影響する 課題抽出 - ユーザー数が⾜りない・ユーザー単価が⼗分でない - 検索とクチコミの流⼊が⾜りず、既存ユーザーが増えない - かなり場所を取っている機能の滞在時間が2分しかない ポイント - あまりに乖離が⼤きければ⽬標と時間軸を⾒直す - ⾃分のこだわり（特定の技術や機能）はできるだけなくす ⽬的 課題設定 仮説検証
18. 解決策を考える＝仮説をたてる 仮説を⽴てる - 課⾦ポイントの機能にたどり着く⼈を増やせばユーザー単価が上がりそう - ユーザーが⼊ってきた時の直帰率・離脱率を減らせば既存ユーザーが増えそう - その機能を改善する/他の機能をフィーチャーすれば全体の滞在時間も伸びそう ポイント - 解決策として成⽴しているか - コストパフォーマンスが最もよい仮説になっているか - 効果は測定できるか ⽬的 課題設定 仮説検証
19. 検証する ・ここまできたら、実際に試して検証するのみ ポイント - きちんと測って想定通りか確認する - 実際に数値が改善したか - 本当に意味のある変化になったか（A/Bテストなど⽐較を使う） ・仮説が外れていたら？ - 次に試す仮説に反映する・⾒直す ・とにかくこれを⾼速で繰り返し、⽬標に近づいていく ⽬的 課題設定 仮説検証
20. マッチョすぎませんか？ 「⾃分はプロダクトの⽅針を決める⽴場にない」 →もし決める⽴場になくても、理解し、意⾒を持つことは⼤事 「⾃分はある技術に貢献したいので、プロダクトのことはあまり関係ない」 →技術も、世の中にインパクトを⽣み出せないものは消え去っていく。 経済合理性のもと、その技術をどう活かしていくかを考える⽅がよい
21. より⼤きなインパクトを出すために
22. 技術の⾼度化に順応する 「技術の進歩はどんどん⾼速になっている」 マネージドサービス/OSSなど、技術が抽象化され簡単/短時間で扱えるよ うになり、それらを組み合わせて少⼈数でも⾼度な⽬標にアプローチでき る。 →特定の技術にこだわらず、あくまで⽬標に向かった学習と運⽤を 今まで経験がある技術に固執しない（サンクコスト）
23. 環境を選び取る どうしてもここまで⾔ってきたようなことが通⽤しない環境もある。 ⾃分の⽬標やキャリアに対して最適な場所を探し選ぶことも⼤事。 多くの⼈の会社選びに当てはまるポイント - 業績が伸びている・成⻑⾓度が⾼い会社 - 業績の根幹に技術が関わっていて、経営陣が技術を理解している - 経営⽬線を担保できるだけの情報が共有され、⾵通しよく議論できる - 事業に貢献できた時に、⾃分もまた経済的に豊かになれる （評価制度/ボーナス/SOなど）
24. ⾃ら掴み取る 実世界においてはどうしても、 「技術」よりも、「事業を動かせる」ことが⼤事な局⾯がある。 事業理解があれば、必要な時に声をあげたり、⼿をあげたりできる。 世の中・会社・⾃分をしっかりメタ認知し、 腰が引けないよう積極的に動くことを意識したい。
25. 経営⽬線を理解し、 よりよいエンジニアライフを