Zenn
🐥

ベンチャーエンジニア1年目が知っておくべきこと ~前提知識編~

2022/10/31に公開
UX
アジャイル
ベンチャー
スタートアップ
リーン
idea

現代のベンチャー開発は大きく３の分野が影響しています。

  • UX
  • リーンスタートアップ(とデザインシンキング)
  • アジャイル開発手法とウォーターフォール開発手法

ただ残念ながらエンジニアの観点でこれらをいい感じにまとめたものは無かったため、僕の観点からまとめてみました。今後起業する人やベンチャーに入るエンジニアの参考になればと思います。

前提知識編

何を作るかとどう作るのか

まずは何を始めるにしても「何を作るのか」を決めるフェーズと「どう作るのか」を決めるフェーズを分割したほうがよいです。「何を作るのか」とは、「何を作るのが正解か」と言い換えてもいいかもしれません。多くのプロジェクトには目的があり、その目的を達成するために「何を作るのか」を探るフェーズです。対して、「どう作るのか」は作るものが決まっており、それをどのような手段で作るのかを決めるフェーズです。

なぜ、「何を作るのか」と「どう作るのか」を分けた方がいいのでしょうか？それはかけられるコスト(時間やお金)が有限だからです。基本的に「作る」ことには時間とお金がかかります。対して「何を作るのか」を調べることは「作る」ことよりも少ない労力で行うことができます。失敗するプロジェクトの多くは、「何を作るのか」の正解がわからないまま、とりあえず作り始め、とりあえずリリースし、そして売れず、気づけば予算がつきるのです。確実に目的を達成できそうな「何を作るのか」がわかった時や、自信が持てた時に「どう作るのか」というフェーズに行くことが、一番プロジェクトが成功しやすい道です。

UXには似た概念として「ダブルダイヤモンド」というものがありますが、これは「なにか問題(issue)か」「解決策(solution)はなにか」を順番に考えるやり方で、少し意味が違います。

https://uxdaystokyo.com/articles/glossary/doublediamond/

why-what-howの順番に物事を決める

物事はwhy-what-howの順番に決めましょう。なぜなら右側(how)に行けば行くほど、爆発的に数が増えるからです。例えば、whyが「奥さんを喜ばせるため」だとします。するとwhatは「美味しいものを食べる」「欲しがっていたアクセサリーをプレゼントする」「好きなアーティストのライブに行く」などがでてくるかもしれません。仮に「美味しいものを食べる」だった場合、さらにhowとして「外食する」「配達してもらう」などの選択肢がでてきます。howはwhatに依存し、whatはwhyに依存します。逆はないです。もし当初のwhyが覆された時、howを考えていた時間は無駄になります。そうならないために、why-what-howの順番で物事を考えるのが大事なのです。

目的と手段のグラデーション

実はwhy-what-howは厳密には区別することができません。なぜなら目的は手段になりえるし、手段は目的になりえるからです。

例えば「カーナビを買いたい」という目的があったとします。なぜ「カーナビを買いたい」のかというと「目的地の海まで迷わず行きたい」からです。なぜ「目的地の海まで迷わず行きたい」のかというと「子供を遊びに連れて行きたい」からです。なぜ「子供を遊びに連れて行きたい」かというと「子供を喜ばせたい」からです。

逆に「子供を喜ばせたい」ための手段として「子供を遊びに連れて行き」、またその手段として「海まで迷わず行き」、またその手段として「カーナビを買う」のです。

このように、目的と手段はグラデーションのようにつながっています。手段が目的化することは自然なことです。よく本末転倒という言葉が使われますが、これは下位の目的を達成することで、上位の目的を達成できなくなることを指します。

参考書

UX手法にのった分析

UXはユーザー体験(User eXperience)の略です。ユーザービリティ(使いやすさ)から発展して概念で、単に使いやすいことだけを目指すのではなく、ユーザーの情動的な体験に着目します。

UXではおもに３つのレイヤーを分析します。それは

  • 属性
  • 行為
  • 価値

です。そして分析結果から望ましいプロダクトやサービスを考えます。現状分析をas-is(アズイズ) 、望ましい状態をto-be(トゥービー) と言って区別します。

属性

属性分析は「ペルソナ」が使われます。聞いたことがあるのではないでしょうか？　たとえばあなたがキッチンメーカーでより使いやすいキッチンを作りたいとします。その際に分析対象は「キッチンを使う人」になります。キッチンを使う人に対して、アンケートをとり、どのような人がキッチンを使っているのか、どのような目的で使っているのかを分析します。アンケート結果をカテゴライズし、変数化し、特徴的なキャラクター(ペルソナ)を複数人作っていきます。基本的にas-is分析で使います。

詳しいやり方は書籍などでしらべてみてください。

行為

行為分析は「カスタマージャーニー」や「ユーザーストーリーマップ」が使われます。横軸に時間軸を取り、時間軸に沿ってペルソナの行動を列挙していきます。例えば「朝のルーチーン」を分析したいなら、「目覚ましで目が覚める」「顔を洗う」などです。

できたものに対して、感情曲線をつけると、ユーザーがどこでペイン(苦痛)を感じているのか、どこでゲイン(幸福)を感じているのかを分析することができます。感情曲線のパターンはいくつかあります。

「カスタマージャーニー」はas-isとto-beのどちらでも使います。to-beでの感情曲線のデザインは、基本的にピークアウトを目指すことが多いです。

価値

ペルソナがその行為の何に対して「価値」を感じているのかを分析します。ツールには価値マップやKA方などが存在します（正直僕にとってあまりしっくり来るツールがないです）。ペルソナとカスタマージャーニーに紐づけて、どのような価値が存在しカテゴリ化できるのかをまとめます。as-is分析で他社を含めて分析し、自分たちはどの価値のポジションをとるのかを決めるto-beモデル作成でも役立ちます。

to-beモデルの作成

as-is分析が終わったらto-beモデルを作成します。

  • 作った複数のペルソナに対して、メインターゲット、サブターゲット、非ターゲットを決めます。
  • 価値のポジショニングを決めます。
    • 価値のカテゴリ(既存・新規)
    • ペインの除去系？
    • ゲインの作成系？
  • to-beカスタマージャーニーを作成します。
    • もしくはより簡単なアクティビティシナリオを作成します。

これはリーンキャンバスの価値提案(Value Proposition)に相当します。

to-beモデルの検証

検証にはプロトタイプを使います。プロトタイプとは実際に動くを作らずに、価値を検証する手法です。

プロトタイプには忠実度という概念が存在します。忠実度とは本物にそっくりな度合いのことで100%であれば、本物です。忠実度が高ければ高いほど、本物に近いフィードバックを得られますが、作るのに時間がかかります。忠実度が低ければ低いほど、大雑把なフィードバックが得られますが、作るのは簡単です。忠実度の低いプロトタイプの例としてペーパープロトタイプがあります。忠実度の高いプロトタイプの例としてツールプロトタイプがあります。

プロトタイプは２種類存在します。全体を薄く忠実度低く調査する目的の「水平プロトタイプ」とある機能を深く忠実度高く調査する「垂直プロトタイプ」です。場合に応じて使い分けます。

参考書

リーンスタートアップのアプローチ

リーンスタートアップはシリコンバレー発の起業メソッドです。起業の失敗を防ぐためのノウハウの塊みたいなものです。いくつかの鉄則があります。

  • 顧客は誰か、課題はなにか、解決策はなにか、プロダクトはなにかの順番で深ぼっていく
  • 顧客がたしかにその課題を抱えていると確信している段階をCustomerProblemFit(CPF)という
  • この解決策がたしかにその課題を解決できると確信している段階をProblemSolutionFit(PSF)という
  • このプロダクトがたしかに解決策を体現していると確信している段階をSolutionProductFit(SPF)という
  • プロダクトが完全に市場に受け入れられたと確信している段階をProductMarketFit(PMF)という
  • CPF-PSF-SPF-PMFの順番で達成する
  • できる限り最短でProductMarketFitする機能のみを搭載する。最小限価値のプロダクト(MVP)を作成する。

そしてこれらを一枚の表にまとめたのがリーンキャンバスです。リーンキャンバスの見方や埋め方は、顧客、課題、解決策の順番になります。リーンキャンバスの各項目を変更する決定をピボットと呼びます。

CustomerProblemFit(CPF)までの段階

顧客と課題を深ぼっていきます。基本的にプロダクトは作りません。調査がメインになります。ジャベリンボードなどのツールがあります。また、UX手法によるas-is分析も利用できます。

ProblemSolutionFit(PSF)までの段階

課題の解決策を深ぼっていきます。プロダクトを実際に作ることはせずに、既存のツールを組み合わせたり、プロトタイプを作ったりして検証していきます。もし検証していくなかで実はCPFできてないなと感じたら、前の段階に戻ります。UX手法によるto-beモデル作成も利用できます。

SolutionProductFit(SPF)までの段階

実際にプロダクトを作成していきます。リスクを最大限に抑えるため、できる限り小さくリリースし、市場の反応を確かめて、軌道修正を繰り返します。すべての機能を一気にリリースするウォーターフォール開発よりも、機能ごとに作ってリリースするアジャイル開発が好まれます。また、使い捨て前提のプロトタイプを作成するよりも、本物のコードで実験する曳光弾のアプローチ を取り入れることもできます。ちなみにこの段階は「何を作るか」ではなく「どう作るか」のフェーズです。

もし市場にプロダクトを投入していくなかで実はPSFできてないなと感じたら、前の段階に戻ります。もしくは、今まで得られた知見をもとに、ピボットすることもあります。

https://atmarkit.itmedia.co.jp/ait/articles/1706/01/news169_2.html

ProductMarketFit

SPFを達成し、あとは市場受けも良さそうだと確信する時がきたら、あとはグロース（資金調達と広告)する段階です。グロース前になるべくバケツの穴を塞いでおきましょう。ここらへんはグロースハックの本を一読することをおすすめします。

MVP

PMFを達成するまでの最小の機能をのせたプロダクトです。機能を選択するときに、must(必須機能)なのかそれ以外なのかを判別することが大切です。MoSCoW(モスクワ)を使うこともできます。

よくチームで、この機能はMVPだ、いや違うといった論争が起きたりします。

https://ssaits.jp/promapedia/method/moscow-method.html

参考書

予測型アプローチと適応型アプローチ

「どう作るのか」の大きく２つの方法。予測型アプローチと適応型アプローチです。

予測型アプローチ

一番最初に綿密な計画を立てて、それをもとに開発を進めていきます。ウォーターフォールはこのアプローチです。また、機能ごとにリリースするイテレーション開発でも、最初に綿密な計画をたてるのであればこのアプローチです。「何を作るのか」を要件定義と呼び、外部設計と内部設計をして詳細な見積もりを考えます(僕的には外部設計も「何を作るのか」に入ります)。タスクをWBSで分割し、各タスクにどれくらい時間がかかるのかを見積もり、ガントチャートを作成します。見積もりには他にもファンクションポイント法と呼ばれるものも存在します。

メリット

  • 経営者はいつできるのか常に気になるので、アジャイルの流れを理解しつつも予測型アプローチを好みます。
  • WBSを作成する過程で、ある程度のタスク網羅性が強くなります。
  • 外部要因が絡むとき(例えばいついつのイベントまでにリリースする必要がある)、適応型アプローチよりも予測型アプローチのほうが、比較的計画を立てやすいです。成熟したチームなら適応型アプローチでも自信をもって計画を立てることができます。
  • ガントチャートで工程管理されているので、チームのマネジメント力やメンバーのセルフマネジメント力が弱くても、ガントチャートがその分サポートしてくれます。
  • ウォーターフォールはその工程の中に品質を担保する仕組みがあります。
  • 見積もりの過程でタスクの網羅と内部設計まで行っている場合、外注しやすいです。

デメリット

  • 未来の内容ほど見積もりの精度が落ちます。
  • リリースを1回しかしないのであれば、ユーザーに価値を届けるのが遅くなります。
  • 最初の綿密な計画に基づいて予算とスケジュールが組まれるので、何かしらの要因で前提が崩れたとき（もしくは実際やってみたら違ったなどの学びのアップデートがあったとき）、計画が破綻する可能性があります。

適応型アプローチ

最初にすべての計画をたてることを諦め、相対的な見積もりを採用します。アジャイルはこのアプローチです。「何を作るのか」が最初は大きく変わる可能性を想定し、小出しにリリースして、市場の反応を見て、軌道修正を行っていきます。タスクはカンバンとバックログで管理し、イテレーションごとにリリースを行います(もしくは随時リリースする)。カンバンを使ったフロー制御で、フロー効率を上げることも可能です。また、バーンダウンチャートをつかって進捗管理やいつ終わるのかの見積もりをします。相対的な見積もりはストーリーポイント法を利用し、そのイテレーションで消化したストーリーポイントをもとにチームのベロシティを測ります。ベロシティが安定してきたら、チームが成熟してきており、見積もりの精度が上がりあります。

メリット

  • 自律したチームを作れます。
  • 予測型アプローチのような絶対的な計画に支配されることなく、各リリースで得た知見を反映させることができます(心理的ハードルが予測型アプローチよりも下がる）。
  • 曳光弾(えいこうだん)のアプローチと相性が良いです。
  • 見積もりはそもそもかなりの時間を使う作業。もし「何を作るのか」に修正が発生する場合、総合的な見積もりに費やす時間が予測型アプローチよりも減ります。

デメリット

  • ベロシティが安定するまではいつまでにできるのか見積もりが不正確です。
  • アジャイルはその工程の中に品質を担保する仕組みがないため、回帰テストの充実や、QAフェーズの採用など工夫する必要があります。
  • チームのマネジメント力やメンバーのセルフマネジメント力が弱い場合、タスクの進め方や余分な技術検証に時間をとってしまい、タスクあたりの時間が伸びる可能性がある。セルフマネジメントが弱いチームの場合は、マネジメント専門の人がいると安定します(PMやスクラムマスターなど）。

外部設計と内部設計

設計には、開発に当たり最初にしっかり決めたほうがよい設計と、あとからでもなんとかなる設計の２種類が存在します。例えば、アプリケーションサーバーまわりは、インフラに何を使うのか、言語やフレームワークに何を使うのかは前もって決めておいたほうがいいですが、APIの実装詳細などは、あとからでも考えることができます。またDBのモデルは最初に決めておいたほうが、スムーズに開発しやすくなります。

最初に決めておいたほうが良い設計を外部設計、あとから決めても構わない設計を内部設計とここでは呼ぶことにします(一般的には外部設計は画面やインターフェースなどお客さんがいないとできない設計を、内部設計は自分たち開発者だけでできる設計のことを指すみたいです)。

ただし、予測型アプローチの場合は、最初に全て決めておかないと、見積もりができないので、内部設計も外部設計のあとに行います。適応型アプローチの場合は、イテレーションごとに、機能ごとに外部設計と内部設計を行いますが、インフラなどのアーキテクチャは一番最初に決めておきます。

内部設計よりも外部設計のほうが設計力を要するので、外部設計を行う際はお客さんを巻き込んで設計になれた人とモビングすることをおすすめします。

要件定義と外部設計が「何を作るのか」を明確にします。できれば、内部設計に入る前にプロトタイプを通して、本当に作りたいものはこれか確かめておくと出戻りが少なくなります。

僕は要件定義と外部設計は分けてないので、ひとくくりに扱っています。

外部設計(最初に決めておくべき「何を作るのか」を体現したもの)

  • ユースケース
  • 概念モデリング
  • 画面
  • 非要件定義とアーキテクチャ
  • 外部システムとの連携
  • バッチ
  • レポート機能(帳票やcsv)

内部設計(あとからでも考えられる「どう作るのか」を体現したもの)

  • DB設計(テーブル設計)
  • API設計(シーケンス図)

スコープ管理

スコープには２種類存在します。「広さ」と「深さ」です。広さは機能の網羅性、深さは機能の作り方における技術選択です。MVPを作成するなら機能はMust以外は作成しないので、スコープの「広さ」を限定できます。深さは、後々大変になるけど単に簡単に作れればよいのか、工数はかかるが汎用性の高い技術を採用するかで決めます。

スコープの広さと深さの画像

残り時間的に、工数を短縮しないといけないとき、これらのスコープを調整することができます。

参考書

Discussion