selmertsxの素振り日記

ひたすら日々の素振り内容を書き続けるだけの日記

リーンスタートアップ + スクラム + デザインスプリントで進める開発プロセスについて

最初に

さて、いきなり私事ですが、転職しました。 転職した会社の名前については、まだ社のSNSポリシーなどを正確に把握していないため、 こういった場では書かないでおきます。

転職した会社は日本に古くからある製造業です。 ここ1〜2年でクラウドの利用を開始したとのことですが、すでにGKE&GO、AWS&サーバレスでシステムを開発しています。 日本企業の技術者の技術力の高さを改めて実感しながら、 僕がこの企業で成果を出すために色々と模索していかなければなぁと気を引き締め直しています。

新しい会社は、僕がこれまで経験してきた企業とは全く違う性格の会社です。 今の会社で歓迎されるスキル、使えるスキル、捨てないといけないスキルがあります。 ソフトウェアエンジニアのスキルについては、大枠としては企業毎に大きな差はないでしょう。 しかし、プロジェクトマネジメントに関しては、ビジネスの性質によって求められる能力や常識が異なると思います。 この点について適切に整理するために、一度僕が経験した開発プロセスの概要を書き下してみます。

前提

Lean Startupについて

この開発プロセスは、Lean Startup の思想に基づいて構成されています。 Lean Startupについて間違いを恐れずに一言で言うならば、 「スタートアップにおいて、ムダなくサービス開発を継続し続けるためのマネジメント論」です。 Lean Startupの源流はトヨタ生産方式です。 そのため、このムダという言葉は、トヨタ生産方式におけるムダから来ており、 「付加価値を高めない各種現象や結果」 と定義されています。

重厚長大な市場調査と企画書を用意するよりも、 価値が伝わるミニマムな製品を作成しユーザーに直接ぶつけてみるほうが時間・金額的コストが安く、学びが多いこともあります。 逆によく考えずに手当り次第に機能を開発し、それが使われなかったとしたらムダが発生します。 それらの失敗から何かを学び、次に活かせるような学習のプロセスがなければ、ムダを生産し続ける組織になってします。 Lean Startupはそれらのムダを最小化するためのマネジメント方法です。 ただし、Lean Startup自体には、厳密なプロセスが規定されていません。 そのため私は、再現性高く改善できるプロセスが構築できるように、 Lean Analyticsやユーザーストーリーマッピングなどのフレームワークを組み合わせています。 この記事では、全体像をより具体的に把握することを優先し、 Lean Startupの本質などに関する説明ではなく、それらを組み合わせたプロセスについて説明します。

この開発プロセスは1-10での利用を想定している

この開発プロセスは0-1ではなく、1-10での利用を想定しています。 すでに企画として立ち上がったサービスであり、PSFitは済ませており、 これからはユーザーの定着を目指していくところでの利用です。 それ以外のユースケースでは有効かどうかを確認できていません。

ソフトウェア自体の開発にはスクラムを採用している

この開発プロセスはすでに決まったものを時間掛けて作るのではなく、ユーザーの反応を見ながら作るものを決めます。 そのため、短い期間で適宜軌道修正をすることができるアジャイルを採用しています。 ただし、スクラム開発部分については、それだけで膨大になってしまうため今回は一旦簡単な説明だけに留めます。

それぞれのフレームワークについて詳細を記載すると全体感の把握が難しくなるため、今回は概要をざっくりと説明します。 もし、詳細を知りたいという方がいましたら、ブックマーク上でコメントいただけますと!

開発プロセスの全体像

開発プロセスの全体像はこちらになります。 なお、この開発プロセスは市谷先生の「正しいものを正しくつくる」という書籍をベースにしています。

f:id:selmertsx:20200705214843p:plain
開発プロセスの全体像

この章では全体の開発プロセスについて概要を軽く記載します。 それぞれのプロセスの詳細については、次の章にてまとめます。

最初に事業計画があります。 事業計画フェーズでは、サービスの性質とKGI/KPIの設計、ステークホルダーとのコミュニケーション設計を行います。 リーンキャンバスと、インセプションデッキを作成し、誰のためのどのようなサービスを作るのか。我々のサービスの競合優位性は何なのか。 サービス開発を進めていく上でのステークホルダーと、ステークホルダーの人たちのコミュニケーション方法を簡潔にまとめます。 そして、Lean Analyticsをベースに現在のサービスのステージを特定し、そのステージに適したKGI/KPIを設定します。 基本的にすべてのKPIを追うことは出来ません。そのため追うべきKPIの優先度も決めておく必要があります。 これらの資料は何度も作り直すことになるでしょう。 それはサービスを開発していくなかで、ユーザーや市場の解像度が上がるからです。 資料を修正する必要性が生まれるということは、チームが学習をしているということです。 それをポジティブに受け止めて、チームで話し合いながら更新していきましょう。

2番めの手順は仮説立案です。 仮説立案フェーズでは、事業計画フェーズで定めたKGI/KPIに対して、有効と思われる機能の仮説を出します。 仮説の立案は Design Sprintを利用して行います。 Design Sprintでは、KPIから逆算して達成すべき課題を定義します。 例えば、定着フェーズのECサービスを例に考えます。 KGIが 「90日以内に戻ってくる購入者の割合」として、 KGIに紐づくKPIの1つを「ユーザーが目的の商品を見つけることができた割合」としたとします。 このようにKPIを決めたとき、解くべき課題は2点に集約されると思われます。 1点目は「ユーザーが求める商品を用意することができる」であり、2点目は「ユーザーが目的とする商品に到達できる」になります。 Design Sprintでは、KPIにヒットしうるビジネス上の課題を予め建ててから、その課題に関連するユーザーの動きをインタービューを通して整理します。 整理する上でカスタマージャーニーマップのようなものを作ることもあります。 その後、チーム全体で課題を解決しうる機能の案を出し合い、簡単なモックを作って有効性を検証します。 詳細は追って説明しますが、Design Sprintはまず最初に、解くべきビジネス上の課題を明確にします。 また、開発物を決めるまでのプロセスも厳密に定められているため、迅速な意思決定が可能になります。

3番目の手順は、検証計画の作成です。 検証計画の作成は著書 Running Lean の8.5章にて説明されている「1ページの実験計画書」を用いて行います。 Design Sprintにより提案された案を、実験計画書に落とし込んでいきます。 実験計画書においては、開発する内容、求める成果、成果が得られると思われる根拠、成果の計測方法、実験の期間を記載します。 このとき、もし会社にデータ分析チームがいるのであれば、根拠の部分に関して定量的な裏付けを行うと良いでしょう。 また、世の中にはすでに同じ様な実験が行われている可能性もあります。 そういった実験結果が論文などで公開されていることもあるため、一度探してみても良いでしょう。

4番目の手順は、MVPの特定になります。 「1ページの実験計画書」で計画した実験を達成するために必要な最小限の機能を洗い出します。 この作業は「ユーザーストーリーマッピング」という手法を用いて行います。 ユーザーストーリーマッピングの「ユーザーストーリー」はスクラムで用いられる「ユーザーストーリー」と同じもので、 ユーザーがサービス上で目的を達成する上で発生するシーンと、それに対応した「ユーザーストーリー」をマッピングしたものになります。 全体を俯瞰することで、ユーザーに価値を提供するために必要な機能の一覧を把握できるようになり、目的を達成するための最小限の機能を認識できるようになります。 なお、MVPを特定する上では、セキュリティや法律の知識も必要になります。 例えば契約書を交わす上で必要な手順などを適切に把握していなければ、法律に違反するサービスを作ってしまうこともあります。 法律は機能単体で評価されるわけではなく、サービスの機能全体、そして実態で評価されます。 そのため、他のサービスの機能をそのまま自分たちのサービスに持ってきたからといって、法律上問題ないとは限りません。 また、法律を把握していれば、競合他者のサービスよりも、より良い機能を提案できることもあります。 そしてセキュリティについても意識する必要があります。MVPであるからといってセキュリティを疎かにすることはできないからです。

MVPの特定まで終わってしまえば、あとはスクラムのプロセスに乗せて開発を行えます。 そして出来たものを評価し、学習によって得られた結果をもとに、次の開発物を考案していくという流れになります。

以降、それぞれの開発プロセスについてより詳しく記載していきます。

事業計画

サービスを開発する上で、最も重要なのは事業計画です。 事業計画がなければ、その事業に投資すべきか否かを判断することができません。 事業計画は企業毎にフォーマットがあると思いますので、承認者に見せる資料はそのフォーマットに従ったものを作ることになります。 しかし、一般的な企業における事業計画書では、開発に携わるすべてのメンバーが理解することには難しい場合がほとんどです。 そのため、チームの内外で共通認識を作るための別のフォーマットも必要になります。 そのフォーマットというのが、リーンキャンバスとインセプションデッキです。

リーンキャンバスは、「Running Lean」の著者で知られるアッシュ・マウリャ氏が提唱するフレームワークで、 ビジネスモデルの9つの要素を1枚の紙にまとめたものです。

f:id:selmertsx:20200705215314p:plain
Lean Canvas( leanstackの公式ページより引用 )

その9つの要素とは、 解決すべき課題、ソリューション、既存の代替品、主要指標、独自の価値提案、競合優位性、ハイレベルコンセプト、顧客セグメント、アーリーアダプター、コスト構造、収益の流れ、になります。 ビジネスはこの9つの要素の集合です。 どれだけ売上があったとしても、コスト構造が将来的にも掛かる見込みがある事業は継続することができません。 また、短期的に見てそれなりに利益が出たとしても、狙った顧客セグメントに利用して貰えなければ将来的に十分な成長を見込めない可能性もあります。 サービス開発当初は、この9つの要素はあくまでも仮説になります。 そのため、定期的にこのキャンパスを見直し、軌道修正をし続ける必要があります。 このあたりの詳細を知りたい場合は、こちらの書籍を参照してください。

リーンキャンバスの主要指標は、Lean Analytics の手法を利用して決定します。 Lean Analyticsについて一言で説明すると「サービスにおいて最も注力すべき1つの指標をビジネスモデルと現在のステージから導き出すためのフレームワーク」です。 Lean Analyticsは Lean Startupのマネジメント手法に対して、より厳密なデータ駆動の意思決定プロセスを追加します。 Lean Analyticsのフレームワークにおいて、スタートアップは「共感」、「定着」、「拡散」、「収益」、「拡大」の5つのステージで成長する としています。 共感ステージでは、顧客インタビューやソリューションインタビューを繰り返し、解決に値する課題と、ビジネスとして成立しうるソリューションの発見を行います。 定着ステージでは、顧客にとって必要不可欠である、定期的に正しく利用される機能を作ります。 拡散ステージでは、ユーザー獲得や成長にフォーカスします。 収益ステージでは、収益構造について見直して利益の最大化を行います。 拡大ステージでは、市場におけるシェアを拡大するために、競合他社を見て戦略を考えていきます。 それぞれのビジネスモデル・ステージ毎に最も重要視すべきとされている指標は下記のようになります。

Lean Startupでは、この最重要視する指標をOMTM(One Metric That Matters) と呼びます。 厳密に言えば違うかも知れませんが、私はこれをKGIとして扱っています。

KGIが決まったならば、それを扱える粒度まで分解していきましょう。 操作や計測が不可能なKPIは使うことができません。 その後、分割したKPIに対して、中期的に追うものの優先度を決めていきます。 優先度を決める上で大切なことは、書き出したKPIについてその性質を掴むことです。

f:id:selmertsx:20200705232018p:plain
KPIの性質を分解した図

開発チームとしてすべてのKPIを追うことは短期的にはとても難しく、1つないしは2つ程度のKPIに注力することになります。 しかし、KGIを分解したKPIといっても、そのKPIを上げることがKGIの上昇につながるというのは仮説でしかありません。 故にどの仮説から検証していくのかというのは、とても重要な問題になります。 大きな意思決定の軸としては、今すでに持っている情報からKGIを達成する確度が高いものを選ぶか、 持っていない情報を得るために探索することを選ぶのかの2つになります。 後者をないがしろにすると途中まで順調に成長するけれども、最後に伸び悩む問題に遭遇する可能性があります。 その場合、結果的にサンクコストが大きくなってしまうでしょう。

仮説立案

7/6 (月)に書く 5 whysを利用したトップダウンのアプローチと、Design Sprintを利用したボトムアップのアプローチを繰り返し、問題に対する解像度を上げて、複数の課題にアプローチできるアイデアを探し出す話しをする。

検証計画の作成

7/7 (火)に書く

MVPの特定

7/8 (水)に書く

最後に

Azitで学んだことの棚卸し(たぶんずっとWIP)

2019年7月から参加したAzitを、2020年6月30日をもって退職することになりました。

AzitにはSREとして参加しましたが、開発プロセスを設計したり、開発物を考えたり、データを分析してみたり、 振り返ればSRE的な仕事はほとんどしておらず、色んなことに手を出した一年でした。 「サービス開発」という物事に対して、ソフトウェアエンジニアとしてだけではなく、 様々な観点から考える機会を貰えたことに今はとても感謝しています。

んで、今は有給消化期間になりましたので、とりあえず頭の中に溜まってた諸々の学びを外に出していこうと思います。 やってきたことがとても幅広いので、どのように見せるのが適切なのかウンウン唸っていたのですが、 うなり続けても全然見つからないので、一旦思いつく範囲で具体的に書き下してみました。 とりあえずは読みやすさを完全に無視して、やったことや学びとなったことを箇条書きで、粒度も揃えずに書き出します。 そのうちこの記事に書いた内容を追記・修正して再編集していこうと思います。

ここに書いた内容について、詳細を知りたいという奇特な方がいましたら、ブコメとかでコメントください。 そこだけ切り出してブログにまとめられそうなら、やってみようかなと思いますー。

Azitでやったこと一覧

ソフトウェア開発

  • CREWサービスのRailsアプリケーションリファクタリング
  • CREWサービスのインフラを再構築
  • 新規サービスのバックエンド開発
  • SendGrid, Sentry等の各種SaaS導入

開発プロセスの設計

新規サービスの開発

  • リーンアナリティクスにおける共感フェーズ達成のための目標設計など

学びまとめ

開発プロセスについて

  • 開発プロセスで重要なのは目的と思想であり、漠然と手法を守ることではない
  • 理想とする開発組織の状態を考え、その状態にするために使える開発プロセスを採用する
  • 開発プロセスの「守破離」はもちろん大切
  • それ以上に、理想とする開発組織の状態とそこに至るための過程を考えることが重要
  • KPTはチームを目標とする状態に軌道修正するための場であり、目標とするべきチームの状態と、チームの現状を適切に把握する手段がなければ機能しない
  • 開発プロセスの改善においては、チームメンバーで同じ本を読み、共通認識を持つことができると難易度がぐっと下がる

読書会について

  • 開発プロセスの改善にあたって、共通認識となる知識の土台が欲しかったので、めちゃくちゃ読書会をやった
  • 全盛期は週5で毎朝やっていた
  • 「正しいものを正しく作る」「ユーザーストーリーマッピング」「図解リーンスタートアップ」「リーンアナリティクス」「SPRINT 最速仕事術」などをチームで読んだ
  • 結果として、チームの中で普通にリーンスタートアップ/リーンアナリティクスの用語が普及し、開発プロセスの改善に大きく役立った
  • 普通に仕事をしている中で、あるべき開発の姿について、定期的に腰を据えて話し合うことができるチームは少ない
  • 読書会をし、チーム全体で議論をすることによって、あるべき形はどうなのか。我々は何ができてて、何が足りないのかを定期的に考える機会が生まれた
    • これによりKPTの質も上がった
  • 書籍に書かれている情報をもとに各々の経験を持ち寄って話し合うなど、ハンガーフライト的な役割も果たしてくれた

Azitでやったことについて

ソフトウェア開発

基本的にはあんまり目新しいことは出来ていない。箇条書きにするとこんな感じ。

  • AWS上のインフラリソースをterraformやaws-cdkを使って大体コード化した。
    • 基本的にはTerraformを利用する
    • Lambdaに関連するリソースはテストやデプロイの容易さという観点からaws-cdkを利用して管理する
  • Datadog等の監視用SaaSもTerraformで管理して、監視基準の設定を変更するときはPR上で意図を残すようにした
    • 監視設定については、SRE WorkbookとDatadogのmonitoring 101 を参考にした
  • AWSアカウントをAWS Organizationを利用して、staging/production/管理用と3つのアカウントに分割した
  • G Suite + AWS ALBの組み込み認証の導入
  • メール送信を自前のメールサーバーからSendGridに移行した
  • 新規サービスを Rails & React(redux)を利用して構築した

Rails & Reactを利用する上で書いたブログ記事はこちら。

selmertsx.hatenablog.com

もっと沢山書いておけばよかったですね。CDK周りについてはもうだいぶ忘れている。 SendGrid周りについては、まだ知識が新しいのでブログに書こう。

開発プロセスの設計

開発プロセスは、リーンスタートアップアジャイル・デザインスプリントの3つを軸として設計しました。 具体的にはこんな感じ。

リーンスタートアップで解くべき課題を選定する

selmertsx.hatenablog.com

selmertsx.hatenablog.com

selmertsx.hatenablog.com

上記に、リーンスタートアップで機能を開発するときに考えた諸々をブログでまとめています。 ざっくり説明すると、リーンアナリティクスが提供してくれるフレームワークに則って現状を整理することによってサービスと注力すべき課題を一つに絞り、 サービス全体のライフサイクルに関わる数値をすべて書き出すことによってボトルネックを見つけ出し、 OMTMを定めることによって、部署の垣根を超えて全体で一つの目標を追うことができるようにします。

ここで私が学んだこととしては、10~15人くらいのチームであれば 目標を一つに絞って職種の垣根なく協力することが、最も良い結果を生むということです。 全員で一つの目標を追うことはコミュニケーションコストも掛かりますし、マネジメントコストもかさむでしょう。 だからと言って安直に職種ごとに目標を設定すれば、結局は局所最適化が発生します。 局所最適化による組織的な負債は、把握が非常に困難です。 見えないボトルネックほど怖いものはないので、ここはマネジメントする人間の踏ん張りどころだと思います。

この他にも具体的に開発物を考えていく上で学びになったことがたくさんあるんですけど、力尽きたので一旦ここまで。

Design Sprintで課題を解決するのに有効な機能を見つけ出す

www.axismag.jp

  • デザイン思考について様々な意見があることは知ってる
  • ただ、デザインスプリントはチーム開発において、再現性高く課題解決が可能な開発プロセスであると思っている
  • デザインスプリントにおいては「権限」を持つ人が参加し、適切に権限を行使することが求められる
  • 「達成する責任はあるけど、決める権限はない」という人間が多く存在する現場は少なくない
  • 現場においては権威がない人間の素晴らしいアイデアよりも、権威がある人間の的を外したアイデアの方が採用されうる
  • 意思決定プロセスを明確にし、不健全な責任と権限のバランスによる機能不全を防ぎ
  • イデアと発案者を明確に分離し、評価することができるという点において、デザインスプリントはよく練られた開発プロセスだと思う
  • デザイン思考に対する批判の中に、答えはユーザーの中にないというものがある
  • それはそのとおりだが、サービスによって成し遂げたい世界観とユーザーの間には「課題」が必ずあるはず
  • その「課題」を見つけ出し、課題に適切な「解決手段」を見つけ出す上でデザインスプリントは効果的
  • また、仕事の9割は卓越したイノベーションにより解決されるのではなく、現場の課題の泥臭い改善であり
  • その改善の速度と精度が競合優位性を作るのだと思う
  • 大抵の失敗は、ユーザーを理解したつもりになっていることによって起きている
  • 課題はサービスを作る人間が頭の中だけで考えるよりも、現場にいって直接目で見ることが大切
  • この点はリーンと非常に親しい開発の思想な気がする。徹底した現場主義
  • このあたりはもうちょっと本を読んで比較・整理してみる

アジャイルで作る開発チームを考える

  • 基本的にはアジャイルで作ることにした
  • アジャイルを推進していくにあたっては、最初に最終的なチームの成長目標を描いた
  • そして目標状態に至るためのフェーズを書き出した
    • Phase 1. アジャイル開発のインストール
    • Phase 2. ユーザーストーリーマップの導入とQCDのハンドリング
    • Phase 3. 仮説検証型の開発への移行
    • Phase 4. リードタイムの短縮
  • Phase3の方がPhase2よりも大切だが、いきなりチーム全体で行うことは難しい
  • 先に限られたメンバーでPhase3をある程度形にする
  • Phase3を少人数で実施できたら、チームメンバー全体でやる
  • 自分たちのフェーズを認識し、そのフェーズの目標を達成できているか振り返る
  • スクラムマスターは、振り返りに必要な定量・定性的情報を常に整理する
  • スクラムマスターはチームの補助輪であることを認識し、自らが積極的にファシリテートしなくても回るチームを作るのが理想

開発チームの目標とする状態

  • 自分たちが作るべきサービスについて、その存在意義、届けるべきユーザー、届けるべき価値について正しく理解している
  • 自分たちが作るものに対して、開発チームが主体となってQCDをコントロールして開発ができている
  • チームの全てのメンバーが、無駄なく目的とするサービスを作れている
  • 自分たちが届けたい価値について、どのような方法で届けるのか精度が高い仮説を出せる
  • 自分たちが作った機能について、事前に建てた仮説が正しかったのか検証することができる
  • 上述した取り組みについて、新しい知識を積極的に取り込み、改善し続けることができる

Phase1の目標状態

  • アジャイルに対する体系的な理解とその実践ができてる状態を目指す
  • プロジェクト管理をする上で必須となるスキルの習得
    • プロダクトオーナーから開発チームに齟齬なく要求を伝えられるようにする
    • 完了の定義を明確にし、届けるべき価値について認識に相違ないようにする
    • タスクを細分化し、それらを相互確認することによって無駄な仕事をしないようにする
    • タスクを見積もり、いつまでにどのような価値を届けるのか、ステークホルダーと合意を取りながら進めることができる

Phase2の目標状態

  • 開発チームが作るべき機能について、その仕様を自分たちで決めることができる
  • そして、開発チーム外のステークホルダーと協力して開発できる状態を目指す
  • 取り込むべき知識は下記2点

Phase3の目標状態

  • アジャイルリーンスタートアップを結合し、効果的に運用できている状態を目指す
  • リーンアナリティクスにおけるOMTMや、課題・仮説キャンパスを設定し、そこから開発物を考案できる状態にする

Phase 4の目標状態

  • DevOps的な概念を導入して、諸々自動化し、リードタイムが短縮される状態を目指す
  • まだ解像度は高くないが、チームとして目標とする状態の順番を示すための書いた
  • もちろん開発効率の向上はどのフェーズでやっても良いが、全体をみる人はこの優先度で頭を使った方が良いと思っている

最後に

他にも色々ありましたが、一旦疲れたのでここまで。 また記事を書いていくなかで、追記していこうと思います。

react-railsを利用したRailsアプリケーションにてCSRFの対策を行う

はじめに

最近久しぶりに Rails で Web アプリケーションを開発しました。その中で React でフォームを作ることになったため、CSRF に関する対策について調べました。そのとき調べた内容を記載します。

なお、React の利用は SPA などではなく、react-rails を利用してページごとに React Component を読み込ませています。

CSRF について

CSRF (Cross Site Request Forgeries) とは、悪意のあるユーザーが、任意の Web アプリケーションを利用しているユーザーの認証情報を用いて、任意の Web アプリケーション上の機密情報を盗む、または意図しないコードの実行をしようとする試みのことです。

具体的な攻撃方法について、Rails ガイドに記載されている例を元に説明します。

<img
  src="http://www.webapp.com/project/1/destroy"
  width="0"
  heigth="0"
  border="0"
/>

上記のような img tag が含まれたページをブラウザが表示するとき、ブラウザは http://www.webapp.com/project/1/destroy に対して GET リクエストを実行します。

もし攻撃を受けた側のユーザーが www.webapp.com のサービスを利用しており、 web.webapp.comの認証情報がセッションや Cookies に残っていた場合、その認証情報を利用して GET http://www.webapp.com/project/1/destroyAPI を実行することができます。

JavaScript を利用すれば、POST リクエストも行うことができます。次のように作られたリンクをクリックすると、POST http://www.example.com/account/destroy が実行されてしまいます。

<a
  href="http://www.harmless.com/"
  onclick="
  var f = document.createElement('form');
  f.style.display = 'none';
  this.parentNode.appendChild(f);
  f.method = 'POST';
  f.action = 'http://www.example.com/account/destroy';
  f.submit();
  return false;"
  >To the harmless survey</a
>

Rails における基本的な CSRF 対策について

Rails における CSRF の対策は、基本的には authenticity_token というパラメータを form 毎に埋め込み、POST リクエストの中でその token を検証するというものです。次のような形で、form に authenticity_token というパラメータを埋め込みます。そして、これと同じトークンをセッションにも保存します。

<form action="/login" accept-charset="UTF-8" method="post">
  <input type="hidden" name="authenticity_token" value="xxxxx==" />>
  <input type="email" name="sessions[email]" id="sessions_email" />
  ...
  <input type="submit" name="commit" value="OK" data-disable-with="OK" />
</form>

token の検証方法について、rails のドキュメントでは下記のように記載されています。

Returns true or false if a request is verified. Checks:

・Is it a GET or HEAD request? GETs should be safe and idempotent
・Does the form_authenticity_token match the given token value from the params?
・Does the X-CSRF-Token header match the form_authenticity_token?

実際の Rails のコードと合わせると、下記のような条件を満たしたとき token の検証は問題ないと判断されます。

  • request が get/ head である
  • CSRF の保護が有効になっており、かつ下記の条件を満たしている
    • request の origin が nil である。もしくは、同一 origin からのリクエストである
    • 下記パラメータのいずれかが、セッション内に格納されている authenticity_token と一致している
      • authenticity_token パラメータ
      • request.x_csrf_token

CSRF の保護は test 環境以外ではデフォルトで有効になっています。そのため、通常の Web アプリケーションの利用においては、GET リクエストでリソースの更新等をしていない限り、別段意識せずとも Rails 側が対応してくれることになります。

action/method毎に トークンの設定をする

ただし、CSP(Content Security Policy) を利用しているサービスにおいては追加で対応が必要となります。下記のような HTML が渡されたとき、後者の /innocuous にリクエストをする form 要素は無視され、前者の /user/change_password の方が優先されると報告されています。これにより、ユーザーのパスワードを変更するなどの攻撃が可能となります。

<form method="post" action="/user/change_password">
  <!-- xss -->
  <form method="post" action="/innocuous">
    <input type="hidden" name="authenticity_token" value="thetoken" />
  </form>
</form>

この問題は、この Pull Request において言及され、対策が取り込まれました。対策内容はaction/method ごとに authenticity_token を作成するというものです。これにより、上述の form hijacking により生成された POST リクエストは無効となります。

今回の対処方法

今回 CSRF 対策をする上で行ったことは下記2点です。

  • config/application.rb にて per_form_csrf_tokensを true とする (参考)
  • React Component の引数に action, method を指定した authenticity_token を渡す

authenticity_tokenの渡し方については下記のようになります。

# app/views/sessions/new.html.erb
<%= react_component("LoginForm", {
  loginUrl: admin_password_reset_url,
  token: form_authenticity_token(form_options: { action: session_path, method: "post" }),
}) %>

最後に

今回 SPAではないReactを利用したRailsアプリケーションで、CSRFの対策を行う方法についてまとめました。 この方法の問題点や、もっと良い実装方法がありましたら、コメント等をもらえると嬉しいです!

アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第3回 ライフサイクルとOMTM~

前回の記事では「事業計画とのすり合わせ」のステップについて記載しました。

selmertsx.hatenablog.com

今回の記事も、引き続き「事業計画とのすり合わせ」のステップについて説明しています。

TL;DR

  • 顧客のライフサイクルを書き出し、課題の解像度を上げましょう
  • サービスの最重要指標 ( One Metric That Matters ) を定めましょう
  • ( Lean StartupにおけるOMTMとKGIの関連付け等について、まだまだ理解が整理できていないので詳しい人教えて欲しい )

ライフサイクル

改善する前に現在のサービスの見える化をしましょう。 見える化をする上で、Lean Analyticsにはいくつかの方法を提供してくれています。 今回は、よくありそうなECサイトを例に見てみます。

f:id:selmertsx:20200206005604p:plain

上記の図の各ステップごとに、必要な数値をすべて出していきましょう。 まずはユーザー全体でデータを出してみましょう。 その後、もし分析可能なリソースがあれば、ユーザーをセグメントごとに分けて、 セグメントごとに上記のデータを出してみることをおすすめします。 ユーザーセグメントは、インセプションデッキに記載されたペルソナを元に下記のように4つに分割すると良いかと思います。

  1. ターゲットユーザーかつ、LTV > CAC を満たすユーザー
  2. ターゲットユーザーかつ、LTV > CAC を満たさないユーザー
  3. ターゲットユーザーではなく、LTV > CAC を満たすユーザー
  4. ターゲットユーザーではなく、LTV > CAC を満たさないユーザー

インセプションデッキを元にターゲットユーザーを設定するのは、誤った最適化を防ぐためです。 誤った最適化について説明をするために、またフリマアプリを例にします。 フリマアプリにおいて、最も購入してくれるユーザーの中には、おそらく「転売」を目的にしている人もいるでしょう。 もし、ここでターゲットユーザーをインセプションデッキから決めずに、 トラクション最適で進めてしまった場合、「転売」最適のサービスに誘導されるリスクがあります。 その結果、サービスは誤った方向に進んで行ってしまい、貴重な時間を無駄にしてしまいます。 出品者ユーザーのニーズを満たすために、一時的に「転売」ユーザーの力を借りるという選択をすることもあるでしょう。 ただし、 そういった成長は不健全なものであることは認識しておく必要があります。

ライフサイクルを書き出すと、どのセグメントのユーザーが、どこでチャーンしているのかを整理することができます。 これにより、プロダクトの課題を可視化することができるようになるでしょう。 プロダクトづくりは1,2番のセグメントのユーザーに対して注力します。 3番のセグメントのユーザーについては、そのセグメントのユーザーが1,2番のセグメントにいるユーザーに悪い影響を与えない限りにおいて、静観することになるでしょう。 ただし、ターゲットユーザーに悪い影響を与える場合は、排除するという選択肢を取る可能性もあります。

最重要指標 ( OMTM: One Metric That Matters )

スタートアップの成功の鍵は、本当の意味でフォーカスすること、それを持続させるための規律を持つこと。
フォーカスしていないのに成功したとすれば、それは単なる偶然にすぎない。
あてもなくさまよい、膨大な時間をムダにして、苦痛や徒労を経験した末の成功だ。
スタートアップの成功に秘訣があるとすれば、それは「フォーカス」である。
「Lean Analytics 6章 最重要指標の規律」

私はこれまで、プロダクトを成長させるために数多くのKPIを設定する企業を見てきました。 PMFitを達成し、十分に大きくなった企業においては、数多くのKPIを設定することもあるでしょう。 しかしながら、1=>10, 10 => 100 フェーズの企業においては、 多くのKPIを設定することは能力の分散や局所最適化に繋がり、デメリットが大きいと考えています。 例えば下記資料においては、CPAに責任を持つ人と、LTVに責任を持つ人が異なったため、 エロバナーが量産されたという失敗が記載されています。

www.slideshare.net

似たような失敗は枚挙に暇がありません。 例えば、営業は目標達成のために質の悪い顧客を大量に獲得してしまい、CSの対応コストが増加。 そして売上は上がらずにコストだけがかさみ、プロダクトの利益を奪ってしまう。 または、マーケターがCPAを下げるために本来のターゲット層とは全く異なる層に対してアプローチをする広告を出し、 全く異なる層のユーザーがプロダクトに広がり、既存の優良ユーザーがチャーンしてしまう。 KPIを個別に設定した結果、個別のKPI自体は上昇していても全体としては大きな損失を出してしまうという失敗はよくあることです。

このような問題を避けるために、チーム全体で最重要指標 (OMTM) を定めることが重要です。 OMTMは、現在のステージや投資家からの期待で定まります。下記資料のP87にサービスの性質と、ステージに合わせて見るべきOMTMの例が記載されています。

例えば、ECサービスにおいて現在のステージを「定着」とした場合、OMTMは「CV数」と「ロイヤリティ: 90日以内に戻ってくる購入者の割合」の2つのどちらかになります。 もちろん、プロダクトの状況によってはこれらの指標が適切でないケースがあります。 もしも適切な指標が見当たらなければ、自分たちで設計しましょう。 定着フェーズのゴールは、「顧客にとって必要不可欠である、定期的に正しく利用される機能の提供」です。 自分たちで指標を用意する場合、そのゴールを計測することができる指標であるかを注意しましょう。

さて、漠然と「このOMTMを追う」と決まったとしても、具体的なアクションはまだ浮かんで来ないでしょう。 次の記事では、OMTMを関係各所と協力しながらアクションに落とし込む方法について、記載させていただきます。

まとめ

  • 前回の記事において、投資家の期待、現在のフェーズに関する定量的な裏付けをしました
  • 今回の記事において、プロダクトのライフサイクル把握と、OMTMを定めました
  • 次回は現在のライフサイクルとOMTMを元に、アクションに落とし込むための方法について記載していきます。
  • 次回で「事業計画とのすり合わせ」ステップが終了です.... 長かった....

アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第2回 数値目標の認識合わせ~

先日書いたこちらの文章における、「事業計画とのすり合わせ」のプロセスについてのお話です。

selmertsx.hatenablog.com

一口にスクラムマスターと言っても、事業計画に関わる深さは人によって異なります。 会社の文化や、その他様々な要素によって変わるでしょう。 ただしどんな会社においても、数値目標をたてて、それを開発チームに共有するというステップは踏むはずです。

それら数値目標の作成に関して、あなたがどれくらい関与できるかは分かりません。 あなた自身が作るかも知れないし、ビジネスオーナーが中心となって決定し、あなたは共有されるだけかも知れません。 どのような形で共有されるにせよ、あなたが開発チームについて責任を持つ人のひとりであれば、 それらの数値目標を開発チームに渡す前に、適切に理解・検証し、ときにはステークホルダーと調整する必要があります

この記事では、そのために必要な知識や方法について記載していきます。 なお、この記事は ビジネスオーナーが立てた事業計画を受け取る側の、サービスに最近ジョインしたスクラムマスターの観点から書かれています。

TL; DR

  • Lean Analyticsのフレームワークを用いて、現在のサービスのステージについて認識合わせをしましょう
  • 投資家・経営陣の意思決定の指標とその理由を正しく把握しましょう
  • 現在のステージについてデータを元に裏付けをし、ステークホルダーと合意をとりましょう

ビジネスオーナーと認識をすり合わせるためのステップ

ビジネスオーナーから共有される数値目標を開発チームのものとする前に、下記のステップで認識のすり合わせをしていきます。

  • プロダクトのステージに関するビジネスオーナーの現状認識
  • プロダクト継続可否のチェックポイント
  • 主要KPIの分析

以下、それぞれのステップで行うことについて説明をします。

プロダクトのステージに関するビジネスオーナーの認識

私は事業のデータを見る上で、Lean Analyticsのフレームワークを活用しています。

理由としては、スタートアップの成長ステージに合わせて見るべき指標と、その解釈方法について具体的に示しているフレームワークだからです。 Lean Analyticsのフレームワークにおいて、スタートアップは「共感」、「定着」、「拡散」、「収益」、「拡大」の5つのステージで成長する としています。 それぞれのステージの詳細な説明は書籍に譲りますが、簡単に説明すると下記のようになります。

共感ステージでは、顧客インタビューやソリューションインタビューを繰り返し、解決に値する課題と、ビジネスとして成立しうるソリューションの発見を行います。 定着ステージでは、顧客にとって必要不可欠である、定期的に正しく利用される機能を作ります。 拡散ステージでは、ユーザー獲得や成長にフォーカスします。 収益ステージでは、収益構造について見直して利益の最大化を行います。 拡大ステージでは、市場におけるシェアを拡大するために、競合他社を見て戦略を考えていきます。

このフレームワークに基づいて、自分たちがどこのステージにいるとビジネスオーナーは判断しているのか確認します。 ビジネスオーナーがそのように判断するに至った定量・定性的なデータもあれば合わせて確認します。

プロダクト継続可否のチェックポイント

どのようなプロダクトにおいても、継続可否の判断をするためのチェックポイントというものが存在します。 審査をするのは、スタートアップにおいては投資家であり、企業においては自社の経営陣になります。

このチェックポイントに関して、その時期と観点、基準値とその理由をビジネスオーナーに確認します。 ここが擦り合っていないと、後々の数値目標の温度感について共通認識をつくることが出来ません。 ステークホルダー間でのMTGの議事録や、各種文書があれば確認しておきます。

投資家や経営陣の判断軸において、Lean Analyticsのステージと紐付けられていることはあまりありません。 投資観点では、そのサービスがどれくらいの規模になりうるのかがとても大切です。 TAM (Total Addressable Market)、SAM (Serviceable Available Market)、SOM (Serviceable Obtainable Market) の観点で、数字を作る必要がでてきます。 TAM/SAM/SOM については、下記の記事がとてもわかり易く説明されているので、こちらを参照してください。

medium.com

投資家の観点で、どのような数字が見られるかというと、例えば○○Pay系のサービスにおいては、決済単価も見られる指標の一つになりうると思います。 実際の決済単価のn%を収益とする〇〇Pay系のサービスにおいて、少額決済のみに利用されているのか、それとも高額な決済にも利用されているのかはSOMが大きく変化しうる要素です。 このように投資家の観点と、Lean Analyticsのステージは必ずしも完全に一致しないものの、ある程度リンクさせて考えないと健全でないサービスの成長をしかねません。

主要KPIの分析

これまでのステップで、ビジネスオーナーの現状認識と、投資家(自社の経営陣含む)からの期待値について把握しました。 このステップでは、現状を定量的に捉えることによって、目標とのギャップを正しく認識していきます。

Lean Analyticsではステージごとに分析するべき指標について、いくつか例を出してくれています。 例えば、定着フェーズにおいてはユーザーがサービスに費やした時間やチャーンレートに復帰率など、 拡散フェーズにおいてはバイラル係数などを見ることを推奨しています。

ここではビジネスオーナーの認識が拡散フェーズであるとして、データを確認していきましょう。

データの見方について

最初に、自分たちが認識している前のフェーズについて、本当に完了させることが出来たのか確認していきましょう。 例として、自分たちが定着フェーズを本当に終わらせることができたのかを確認します。 このとき、ユーザーの登録日時でコホート分析することをおすすめします。

ユーザー傾向変化を掴むためのコホート分析その1

例えば、メルカリのようなフリマアプリを例にデータを見ていきます。 例のためにユーザーの継続率を示す表を作りました。 横軸がユーザーの登録月、縦軸が分析対象月を示しています。

201807 201808 201809 201810 201811 201812
201807 1.0 NaN NaN NaN NaN NaN
201808 0.8 1 NaN NaN NaN NaN
201809 0.7 0.7 1 NaN NaN NaN
201810 0.6 0.5 0.6 1 NaN NaN
201811 0.6 0.4 0.4 0.5 1 NaN
201812 0.6 0.4 0.3 0.3 0.5 1

このような形で確認すれば、サービスが良い方向に向かっているのか、それとも悪い方向に向かっているのかを確認することができます。 この表でみると、ユーザーの継続率は徐々に減少していると言えるため、定着フェーズは終了できていないと見ることができます。 ユーザーのnヶ月目継続率を表現しており、そのような数値は大半の方が見ていると思います。 この表はわかりやすいので、次はもう少し複雑なデータを見てみましょう。

ユーザー傾向変化を掴むためのコホート分析その2

こちらも横軸がユーザーの登録月、縦軸が分析対象月を示しているデータです。

201807 201808 201809 201810 201811 201812
201807 1.0 NaN NaN NaN NaN NaN
201808 0.9 1 NaN NaN NaN NaN
201809 0.8 0.9 1 NaN NaN NaN
201810 0.8 0.8 0.9 1 NaN NaN
201811 0.8 0.8 0.8 0.9 1 NaN
201812 0.8 0.8 0.8 0.8 0.9 1

上の表を見ると、半年後チャーンレートが2割になっています。この結果を見ると定着フェーズは終わっているので、次に進みたくなりますね。 その誘惑をぐっとこらえて、次は一人あたりの平均売上という観点でコホート分析をしてみましょう。

201807 201808 201809 201810 201811 201812
201807 25000 NaN NaN NaN NaN NaN
201808 32000 30000 NaN NaN NaN NaN
201809 28000 25000 20000 NaN NaN NaN
201810 29000 23000 19000 15000 NaN NaN
201811 30000 20000 18000 13000 11000 NaN
201812 31000 18000 15000 11000 9000 9000

一人あたりのユーザーがサービスに使ってくれるお金は徐々に下がっていることがわかります。 次は、購入者が販売者から商品を買うまでに必要なやりとりの平均値についても見ていきましょう。

201807 201808 201809 201810 201811 201812
201807 3.1 NaN NaN NaN NaN NaN
201808 28 2.1 NaN NaN NaN NaN
201809 2.1 2.8 6.2 NaN NaN NaN
201810 2.8 2.7 6 7.2 NaN NaN
201811 2.4 2.6 5.8 7.3 8 NaN
201812 2.3 2.4 5 7.6 8.1 9.1

購入者が商品を購入するまでに、販売者とやりとりをする回数が劇的に増加していることが見て取れます。 フリマアプリにおいて、購買者の大多数が何度も値切り交渉を販売者に行い、かつ購入後にも何らかの連絡をして、 いかに品物を安く購入するか考え続ける人であったとします。 そのような購入者が大半を占める場合、販売者は少しくらい安く売れてしまったとしても、 違うフリマアプリに流れてしまうことが考えられます。

四半期もあれば、ユーザーの傾向は十分に変わりえます。 次のフェーズに進むには、今いるユーザーが当初予定していたペルソナと一致するのか、 ビジネスとして成立しうる優良なユーザーなのかを慎重に確認する必要があります。 可能であれば、 ユニットエコノミクス の観点でもデータを見ておくことをおすすめします。

どれだけユーザーが定着していたとしても、そのユーザーがサービスにとって望ましいユーザーでない場合はサービスを次のフェーズに進ませることは正しくありません。 ここを理解せずに次のフェーズに進んでしまっても、お金や時間をムダにするだけでなく、当初のターゲットとしていた優良ユーザーは離れ、優良でないユーザーのみが残ってしまい、元に戻ることができなくなる可能性があります。 (ただし、SNSなどは、ユーザー数がクリティカルマスに到達しなければ適切に価値を提供できません。そのため、定着・拡散フェーズの移行の判断は、より難しくなると思われます。)

データの分析方法について

もしあなたが小さいスタートアップに所属している場合は、データ分析者がいなかったり、いたとしても他の重要な案件にかかりきりで、これらのデータ分析に工数を割くことができない可能性があります。 その場合は、あなた自身がこれらのデータを出すことも検討しましょう。私としては、Pythonで簡単なデータ分析ができるようになることをおすすめします。 Python公式のチュートリアルと、「Python実践データ分析100本ノック」という書籍を一通りやれば、必要最小限のデータは見れるようになっているかと思います。 ちゃんとやれば一月程度で十分学習可能なので、時間を見つけては学習しておきましょう。

私がPythonをおすすめする理由としては、スタートアップにおいては十分にデータがクレンジングされていないし、データが様々な場所に散らばっていることが珍しくないからです。 たとえば、アプリ側のデータはFirebaseを利用してBigQueryに格納されていて、サーバー側のデータはAWSのRDSに格納されており、それらを統合して見る環境が整えられていないなどの状況がありえます。 Pythonであれば、BigQueryとRDSのデータをコード上でジョインしたり、複雑な条件でデータをクレンジングすることも難しくありません。 そのため、SQLについて学習することももちろん必須ですが、Pythonとそのデータ分析用ライブラリであるpandasについても、データ分析者ほどの専門性は不要だとは思いますが、身につけておくと良いでしょう。 ちなみにSQLについて学ぶのであれば、こちらの書籍がおすすめです。 私はSQLを実行してBigQueryとRDSからざっくりと必要なデータを取得し、その後Pythonでクレンジングや加工、グラフ作成などを行っています。

分析の際においては、極端に悪いユーザーのデータだけでなく、極端に良いユーザーのデータも除外することを意識しましょう。 無意識に都合の良いデータだけを見てしまうのは、分析の際によくあります。  ここは強い意思を持って、信頼区間内のデータだけを分析対象としてください。

さて、ここで現在のステージの再確認が終わったら、次は再確認したデータを元に目標値とのギャップを正しく認識します。 そのギャップの大きさを把握できたら、どのようなコスト・リスク・体制で戦っていくのか、ビジネスオーナーと共通認識を作ります。 その具体的なプロセスについて、次の記事に記載します。

まとめ

プロダクトの目標について期日と具体的な数値・理由について把握して、プロダクトの現状について正しい共通認識を作って、それで初めてプロダクトの開発方針を定めることができるようになります。 最初のプロセスで失敗するとあとでリカバリーができないので、このプロセスは慎重、かつ迅速にすすめていきます。

アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第1回 概要~

2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。

バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。

ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。

この開発プロセスは市谷先生の「正しいものを正しくつくる」という書籍をベースに、手を加えたものであることを最初に伝えておきます。 私が市谷先生の本を誤って解釈している部分があれば、コメントを貰えると嬉しいです!!!

最初に

Lean Startup、XP、スクラム、Kanban、DevOps、SRE、Lean Analytics、デザインスプリント。 プロダクトを開発していく上で、先人達が考え出した、様々な考え方、フレームワーク、方法論があります。

それらの手法を把握し、確実に守って運用できていれば、必ずプロダクトを成功させられるわけではないことをエンジニアの人ならよくご存知でしょう。 結局の所、私達はそのときそのときに、真剣に課題に向き合い、適切な学習を継続し、最適と思われる意思決定を積み重ねるしかありません。 その意思決定の深さ、観点、施策実行の精度、そしてときには運によって、プロダクトの成否は決まります。

それでも、プロダクトを開発していく中で、知ってさえいれば防ぐことができた問題。 無駄にせずに済んだ時間。避けることが出来た衝突があるはずです。 私はプロジェクトを成功させるために、様々な本を読み込みました。 それらの知識とこれまでの経験を、この記事に残そうと思います。

TL;DR

  • サービス開発は、リーン・スタートアップ、デザイン思考、アジャイル開発 ( スクラム、eXtream Programing 以降 XP )を組み合わせて行う
  • リーン・スタートアップを用いて、追うべきKPIの設定や検証すべき仮設を設計し
  • デザイン思考を用いて、仮説を検証するため何を作るべきか考え
  • アジャイル開発を用いて、デザイン思考で得られた施策を形にしていく

背景

アジャイル開発 ( スクラム + XP )

ベンチャー界隈において、アジャイル開発という手法は有名です。 そのなかでもスクラムは、軽量であり導入しやすいため最もよく利用されています1

スクラムを導入すれば、開発物の内容や優先度、届けたい価値について、PBI(Product Backlog Item)という形で可視化されます。 また、このスプリントで何をしなければならないか、誰が何に取り組んでいるかもSBI(Sprint Backlog Item)やカンバンによって可視化されます。 誰が何をやっているのか、どの程度進捗しており、どこで詰まっているのか可視化するこの手法によって、 チームは優先度が高い課題に集中して取り組み、協力し合いながら機能的に活動できるようになります

スクラムは様々な職種にまたがって開発していくための軽量な開発手法であり、ソフトウェアエンジニアとしての技術的な制約をその中に含めません。 そのため、開発チームはXPのエッセンスを取り入れ、それらを共通認識として開発することがあります2。 一般的によく取り入れられるXPのエッセンスの中には、TDDやペアプログラミングリファクタリング、自動テスト、インクリメンタルなリリースなどが挙げられます。 これらの取り組みについてはすでに一般的になっており、特別に意図せずともXPの取り組みを行っていたという開発チームは珍しくはないでしょう。 XPとスクラムに細かい違いはあります。それらの差分に関して、どちらのフレームワークの概念を優先するかはチーム毎に意思決定することになるでしょう。

リーン・スタートアップ

スクラムにおいて、ビジネスと開発チームをつなげる役割はプロダクトオーナーが担っています。 「アジャイルエンタープライズ3では、プロダクトオーナーには下記の役割があると記載されています。

プロダクトオーナー(PO)は、顧客価値を考慮しながら、作業の特定と優先順位付けに責任を持ちます。 また、プロダクトの進化に合わせて顧客からのインプットとフィードバックを取り込み、顧客価値を向上させていくことに責任を持ちます。 (中略)... POは顧客の代弁者であり、顧客が本当に必要としている方向にプロダクトを進めるために、顧客フィードバックを取得します。

また、プロダクトオーナーは顧客価値だけでなく、事業に利益をもたらすことの責任も持ちます。 つまり ビジネスとプロダクトをつなぎ、顧客価値を最大化させつつも、事業に貢献する責任を持つのがプロダクトオーナーの役割と言えます。 顧客価値に責任を持つプロダクトオーナーと、ビジネスに責任を持つビジネスオーナーと役割を2つに分けている会社もあります。 スクラム開発におけるプロダクトオーナーの責任をどのように分担するにせよ、誰かが何らかの判断基準に基づいて開発物を決める必要があります。 スクラムガイドラインにおいて、プロダクトオーナーの持つ責任は明確に定義されているものの、遂行するための具体的な方法については触れられていません。

プロダクトオーナーはプロダクトバックログの内容や優先度という形で、開発したいサービスの機能や、それぞれの機能の重要度についてメンバーに伝えます。 とはいえ、プロダクトオーナーも何が正解なのか、把握している訳ではありません。 「正しいものを正しくつくる」4 において、この問題は下記のように説明されています。

現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解イメージがあってそれをうまく取り出してコードにしていくという開発ではない、ということだ。 (中略...) つまり、いま私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく」、そういう開発になる。

プロダクトオーナー1人にそういった「不確実性」に向き合う役割をもたせるチームは少なくないでしょう。 事業がうまく行っているときは、プロダクトオーナー1人が仮説立案、及び意思決定をしても問題が起きることはそうそうありません。 けれども、事業が上手くいかなくなったとき、1人だけで適切な意思決定をし続けることができる人間は多くありません。 小さくともリターンが得られるリスクの低い選択肢を選びがちです。 そして事業はじわじわと後退し、メンバーはプロダクトオーナーの実力に疑いを持ちはじめ、チームは徐々にまとまりを失っていきます。

私としては、チーム全体でそれらの「不確実性」に向き合っていくべきと考えています。 もちろん、最後の意思決定はプロダクトオーナーが行います。 しかし、検証すべき仮説の立案、及び何を作るかについてはチーム全体で考えます。 リーン・スタートアップ開発は、チーム全体で、検証すべき仮説を作成し、検証、学習の一連のプロセス実施していくための方法を提供してくれます。 そのため、私達はリーン・スタートアップ開発を取り入れて開発をすることにしました。

私は、リーン・スタートアップの開発プロセス全体については「図解リーン・スタートアップ成長戦略」5を、 施策の評価方法については「Lean Analytics」6を参考にして、開発プロセスを設計しました。

デザインスプリント

私は、人は基本的に「アイデア」と「アイデアを発案した人間」を分けて評価することができないと考えています。 権威ある人間による的を外したアイデアと、権威のない人間による素晴らしいアイデアであれば、選ばれやすいのは前者です。 恐ろしく口がうまい人間は、アイデアの魅力を実際の何倍にも膨らませ、現実歪曲空間を作ることもあります。 アイデアをアイデア自身ではなく、発言した人間や話し方によって評価してしまうことは、サービス開発において一般的によくあることです。 特にあなた自身がスクラムマスターやリーダーである場合、あなた自身の意見にチームメンバーが誘導されてしまい、 アイデアの多様性が損なわれるリスクがあることを理解する必要があります。

良いアイデアを提案者によらずに正しく評価し、事業に役立てなければなりません。 そうしなければ事業を成長させることはできませんし、さまざまな観点で物事を捉えることのできない、視野狭窄で不健全なチームになってしまいます。 先入観にとらわれずに良いアイデアを考案し、発案者のバイアスを取り除いて選出し、事業に役立てるためには、そのための適切なプロセスが必要となります。 私は、そのプロセスを「SPRINT」7というデザインスプリントについて書かれている書籍を元に設計しました。

提案する開発フロー

f:id:selmertsx:20191222203844p:plain
開発プロセスの全体像

開発プロセスの全体像を上の図に示します。「正しいものを正しくつくる」のP.8に書かれている図を元に私たちのチームに合わせて修正しました。 違いは、事業計画の一部も開発プロセスの中に取り込んでいる点です。 その理由は、1プロダクト1ベンチャーの小さいチームにおいては、開発チームも事業計画に関わり、その方向性に影響を与え、 そこで決まった内容は開発チームの中に過不足なく共通認識を作られなければならないからです。

次の記事において、開発プロセスの詳細について記載していきます。

参考資料

エンジニア面接において構造化面接を取り入れる際に色々考えたときのメモ

前提

このドキュメントは、Work Rules失敗の科学 、そして Google re:Workに記載されている面接方法をベースに書いています。上記の資料について、既に古い認識になっている。またはより良い知識がある場合は、このドキュメントは既に古いものになっている可能性があります。

構造化面接とは

構造化面接とは、同じ職務に応募している応募者に対して、同じ面接方法を使って評価しようという取り組みです。 すべての応募者に同じ質問をして、同じ尺度で回答を採点し、事前に定めた評価基準に基づいて採用を決定します。

構造化面接を採用する理由

私達エンジニアは面接のプロという訳ではありません。 また、基本的にエンジニアはアピールがうまい訳ではなく、相手の良いところや、技術的な強みを見つけ出すのは面接官の力量に掛かっています。 面接に専門性を持たない我々が直感に従って面接をすれば、相手の良いところを見つけ出すことが出来ずに、誤った意思決定をしてしまうことでしょう。 そのため、面接官の力量に強く依存せずに、網羅的に相手の良さを見つけ出すための仕組みが必要となります。

Work Rulesという本において、構造化された面接を行わない場合、面接官は最初の5分で相手を判断し、残りの時間はその判断を補強することに利用してしまうと言われています。 これは人事のプロでない私達では、より顕著に出てしまう傾向だと思われます。

こうした予測は、ある人物を本当に評価するというより、その人に関する自分の考えを確証するために面接するという状況を生み出す。 心理学者はこれを確証バイアスと呼ぶ。つまり「自分の信念や仮説を確証できるように、情報を探し、解釈し、優先順位をつける性向」だ。 ごくわずかなやりとりをもとに、私達はすでに持っているバイアスや信念に強く影響された判断を、即座に、無意識にくだす。 続いて、知らず識らずのうちに、受験者を評価することから自分の第一印象を確証する証拠を探すことに重心を移してしまう。

Work Rules 5章 直感を信じてはいけない P149 

また、面接方法とその後のパフォーマンスについて分析した研究によると、構造化面接は一般的な非構造的面接と比べて2倍程度の決定係数を持つことが示されています。 さらには構造化面接は、受験者にとっても満足度が高いと言われています。

1998年、フランク・シュミットとジョン・ハンターは、面接時の評価からパフォーマンスをどこまで予測できるかという85年にわたる研究をメタ分析し、 その結果を発表した。19の異なる評価方法を調べて分かったのは、よく行われいる非構造的面接の決定係数は0.14であり、社員の職務能力の14%しか説明できないことになる。(中略)

一般認識能力テストと並ぶのが構造的面接だ(26%)。受験者は、回答の質を評価する明確な基準を備えた一連の質問に答える。調査研究ではつねに構造的面接が利用されている。その基本的な考え方は、評価の変化は面接を受ける側の回答の良し悪しの結果であり、面接者の持つ基準が高いか低いか、発する質問が優しいか難しいかは関係ないというものだ。(中略)

構造的面接は受験者と面接者の双方にとって良い経験となるうえ、最も公正だと受け取られることも分かった

Work Rules 5章 直感を信じてはいけない P156

構造化面接で用意した質問により、相手のエンジニアとしての良さを、精度高く見つけられる仕組みを作り出すことができます。 そして、事前に作成して想定回答集により、相手の技術力の評価について、チームで一貫した判断基準を持つことができます。 相手の技術的な強みを正しく見つけ出せない場合は質問項目を見直し、正しく評価できな場合は判断基準の更新します。 これらの取り組みによって、面接の精度を改善することが可能となります。

面接の基本的な流れ

事前準備: 役割分担

  • 候補者の成果物は事前に見れるようにしておく
  • メインの面接者とサブの担当者は決めておく
  • メイン担当者は質問と相手の反応の確認に注意する
  • サブの担当者は議事録の作成に注力する

事前準備: 確証バイアスの洗い出し

自分がどのような先入観を相手に持っているのかを自覚することは、先入観を取り除くためにも重要です。 そのため、事前に提出された書類やGitHubのコードから、相手に対するポジティブ・ネガティブな先入観について書き出します。

そして、それら先入観を取り除くためにどうすれば良いのか、質問に対して相手がどのように答えれば、 その先入観は誤りだったと言えるのかを確認するためにチェックリストを作ります。

面接

ここで構造化面接を行います。 もし仕組みを整えることができれば、コードを書いてみてもらうのも良いでしょう。 この内容については別の機会に書きます。

最後に

2~3ヶ月前、面接方法を考えるために僕が情報収集したときのメモを公開してみました。 採用面接については奥が深すぎて、考えると本業がおろそかになってしまう可能性もあるため、 どこまで深ぼるべきなのか...というのが人の少ないベンチャー企業にて、採用に関わっているエンジニアの正直な気持ち。 このあたりはとてもむずかしい...。

本来ならば、入社後のパフォーマンスチェックもしたいです。

しかし、まったく異なる研究結果も出ている。職種によっては、訓練や経験が何の影響ももたらさないことが多いという。何カ月、ときには何年かけても、まったく向上しないのだ。たとえば心理療法士を対象にしたある調査では、免許を持つ「プロ」と研修生との間に治療成果の差は見られなかった。同様の研究結果は、大学入学審査員(入学希望者の勧誘・選考などを行う専門職)、企業の人事担当者、臨床心理士についても出ている (マシュー・サイド. 失敗の科学 失敗から学習する組織、学習できない組織 )

とあるように、面接に関してもフィードバックループが適切に回っていなければ、自分の判断が良かったのか。悪かったのかを判断することができません。 とはいえ、人の評価はとてもむずかしいです。成果に対するその人間の貢献度合いなんて、正しく計測することはできません。 そんな中でどうやってパフォーマンスチェックするのかというのが、最近の悩みです。

構造化面接についても、自分の知識が足りなすぎて相手の良さを引き出しきれてないケースを日々実感しているので、日々精進していかなければな〜と思う所存です。

参考資料