※この記事は、Speee Advent Calendar24日目の記事です。
昨日の記事はこちら
こんにちは、DX事業本部エンジニアのさとーる（@satotoru2000）です。
先日、学生たちにアジャイル開発によるプロダクト開発の立ち上げを体験してもらうインターンを開催しました。インターンというコンパクトな形で行うことでかえってエッセンスを抽出することが出来たと感じているので、当日にアドリブで色々喋ったことを改めて言語化して整理しようと思います。
Speeeのプロダクト開発ではインセプションデッキやユーザーストーリーなど、アジャイル開発でよく使われれるツールを駆使しながら進めていくのですが、こういったツールは漫然と利用しても意味がなく、事業の成功と紐付けて考える必要があります。形式としてアジャイルの方法論を取り入れても、目的を理解し、勘所をしっかり抑えていなければプロジェクトは上手くいきません。(タイトルの「なんとなくアジャイル風」は、そういった状況を指しています)
その辺りを踏まえつつ、アジャイル開発を進める上で気をつけるべき観点をまとめてみました。ここに書ききれない話もたくさんあるのですが、今回は特に開発スタート前の計画段階の話に焦点を当てています。
どんなインターンだったのか？を簡単に
詳しく書くとネタバレしてしまうので、簡単にインターンの内容を説明します。
今回はDX領域の仮想のサービス立ち上げを題材に、新規事業立ち上げのSprint0を体験してもらう2日間のインターンです。
事業責任者は本気の事業プランを説明するのですが、プロダクトとしてどう作っていったら良いかは分からないので、その辺りを全て担って開発スタート可能状態まで持っていく、というものでした。
つまり、実際のプロダクト開発の立ち上げフェーズをキュッと圧縮したような内容だったといえます。
気をつけるべき観点
まずは要求をありのまま正確に理解すること
事業責任者からの要求は極めて抽象度の高いものです。様々な解釈の余地があり、事業責任者が思い描くものを理解するのは簡単なことではないです。特に、開発はチームで行うものなので一人が正しく理解していてもダメで、全員が認識を合わせて望む必要があります。
まずは要求されたことをありのまま正確に理解する、というのが非常に重要です。
この辺りが不十分だったチームは、議論が紛糾したり、後半になって勘違いが見つかってやり直しが発生したりしていました。
難しい問題を正しく解釈することに向き合いきれず、「自分の意見」という分かりやすい答えに安易に飛びついてしまうが、そもそも前提が擦り合ってないので折り合わず平行線のまま紛糾する、といったケースはしばしばありました。
要求を理解するために、
- 要求をユーザーストーリーマップに書き出してみる
- 簡易なペーパープロトタイプを作って製品イメージをザックリわかせる
- 要するに何がしたいのか？をエレベーターピッチの形式に書き直してみる
などのツールを使っていきます。
状況に合わせてとにかくアウトプットして、認識を擦り合わせていくのが良いと思います。
一貫した判断軸を持つこと
プロダクト開発の最初の段階は、最初のリリースに必要なものを見極めて、価値のある最小のプロダクト(MVP)を定義していくことが重要です。つまり、やりたいことに優先順位をつけて、MVPに必要ないものをリリーススコープから落としていく必要があります。
これらの意思決定は一貫性をもって行われる必要がありますが、検討が進むにつれて一貫性が崩れてきてしまうケースがしばしばあります。そうなると「あれも、これも」大事に思えてしまって、不必要にスコープが肥大化したり、意思決定が遅れて進捗に悪影響が出たりします。
そういった事態を回避するために、インセプションデッキなどを用いて判断軸しっかり言語化し、認識を合わせておくことが重要です。
「エレベーターピッチ」をちゃんと書くことで、何の価値提供を重要視しているかの認識が合うようになりますし、 「トレードオフスライダー」や「やらないことリスト」があると、具体的なケースで判断に迷わなくなります。
一貫した判断軸を持てているか？を確認するために、具体的な問いを投げてみるのも有効だと思います。例えばインターンでは私から学生に以下のような問いを投げていました。
- フォームは「簡単に入力できる方が良い」か「詳細に入力できる方が良い」か
- 企業向けツールは「リッチな方が良い」か「シンプルな方が良い」か
- 社内向け管理画面は「自動化されている方が良い」か「柔軟に対応できる方が良い」か
一見すると判断軸が作れているように思えても、具体的なケースに照らすとそうでもなかったり認識がずれていたりします。
「変化を受け入れる」ことは一貫した軸がないと成立しない
アジャイル開発は「変化を受け入れる」開発プロセスです。言い換えれば、市場という混沌の海の中にその身の一部を晒し続けるということです。その状況下では、荒波の中で舵を取り続けなければ溺れてしまうように、判断軸をもって変化に向き合わなければ翻弄されてしまいます。その結果、無数の要求や矛盾を抱え込むことになります。
こういった事態を回避するために「われわれはなぜここにいるのか」をきっちり言語化し、認識を合わせておくことが重要です。
機能を減らしても価値提供のトップラインを落とさないこと
最短でのリリースを目指すために、リリーススコープから機能を減らすことは最初に考える選択肢です。ただ、機能を減らした結果、ユーザへの価値提供も減ってしまうようなケースがあります。ある機能を作らない判断をしたり、求めている時間軸より遅らせたりする場合、その背後には必ずトレードオフが発生します。トレードオフをそのまま受け入れてしまえば事業計画はビハインドし、成長は鈍っていきます。
仕方ない部分もあるのですが、「トレードオフをそのまま受け入れず、価値提供のトップラインを落とさない方法を考える」という姿勢を持つことが重要です。無思考に機能を減らすことをせず、何とかやる方法を考えたり、代替手段がないか検討したり、頭をひねっていきましょう。
「ユーザーストーリーはアウトカムで書きましょう。Whyを書きましょう」といった話はよく言われますが、こういった場面で効いてきます。ユーザーストーリーに機能を書かずにアウトカムを書いていれば、機能を作ること以外の代替手段を開発チーム全員で考えることが可能になります。
プロダクトにとってソフトウェアが占める領域はほんの一部です。ソフトウェアの周りには営業・マーケ・CSなどさまざまな人が関わっています。そのため、視点を広げると代替手段が見えてくることがあります。
例えば、
- 管理ツールを作る代わりにスタッフを雇うことで解決する
- ユーザー訴求のためのコンテンツを作る代わりに広告を出す
- toB側の機能を提供する代わりに、営業やCSの体制を強化する
- 自分たちで作るのをやめて、第三者のサービスを利用する
などです。
期日とスコープのよくある話と個人的見解
開発プロセスにおいて、期日とスコープはトレードオフとして扱われることが多いです。「見積もり上だと期日に間に合わないのでスコープ削るしかないですね」といった会話はよくある話かと思いますが、個人的にはこの考え方が好きではありません。
この考え方は、スコープを減らしてビハインドした分の価値提供をどうリカバリしていくか？に関して何も答えていないからです。これだけでは、ユーザに価値を届けることに対して半分しか考えられていないと思います。
本当に重要なのは、そのトレードオフを受け止めた上で、どうやったら目指している時間軸で価値を届けることが出来るか？を考え、あらゆる手を尽くすことだと思います。この矛盾を乗り越えようとする姿勢にこそ創造性が宿るのだと思っています。
不確実さが大きくてもキッチリ意思決定すること
プロジェクトには不確実性やリスクがつきものであり、開発プロジェクトも例外ではありません。
計画する段階でどんなに検討を重ねたとしてもリスクをゼロにすることはできません。特に開発プロジェクトにおいては、不確実性コーン が示すように、プロジェクト開始時に最も不確実性が高くなります。この段階で毅然とした姿勢で意思決定をするのは非常に難しいことだと思います。
そのような状況下で、どのように意思決定すれば良いでしょうか？不確実性を抱えた状態で、どうしたらリスクを抑えることが出来るでしょうか？
アジャイル開発における計画策定と実行の方法論は、こういった課題を解決するために存在しています。例えば、イテレーションの計測を重視する姿勢や、学びを得て計画を柔軟に修正していく考え方がこれに当たります。
不確実性に絞っていうと、以下の2点を事前にやっておくのが重要だと思います。
- 「(どういう問題が起きるかは分からないが)少なくとも〇〇という不確実性がある」ということは明らかにしておく
- 問題を顕在化させ対処する方針だけは定めておく
例えば今回のインターンだと「開発速度を高めるため、認証系の機能は内製せず外部サービスを導入する」という意思決定をしたチームがありました。この場合、上手くいけば早く安全なシステムを作ることが出来る一方で、外部サービスで本当にやりたいことを実現できるのか？はこの時点では分かりませんでした。
そこで、「プロジェクトの最初の1週間で外部サービスの調査を行う。その結果やりたいことが実現できないと判断した場合は、内製に切り替える」という対応方針を定めました。
アジャイル開発と意思決定
アジャイル開発はイテレーションごとに意思決定が求められる高負荷な開発プロセスであり、アジャイルと意思決定は切り離すことが出来ません。この認識が不足したまま開発にのぞむと、非常に危険な状況が生まれていきます。
よくある例でいうと、「アジャイルは計画が変わるので、計画を決められない」という誤解です。計画は絶対に最初から決めたほうが良いです。現実を計測した学びを経て、よりベストな形に計画を変更することはあるし、変更されることを受け入れる姿勢は必要ですが、あらかじめ計画を立てたり、計画したゴールにコミットメントすることを否定する要素はどこにもありません。計画を決めなければ、当初の理想と現実との差分も分からなくなるので学習も進まないし、前述した期日とのトレードオフも認識できないので創造的な仕事も阻害されます。
設計などの技術的な意思決定も先送りすべきではありません。不確実な要素を受け止めながらその時点でベストだと思う意思決定をして、経緯をドキュメントに残すのが重要です。その時点でのスタンスをしっかり決めていれば、後から正解・不正解を検証出来るので、より良い形に直すことが出来ます。スタンスが不明瞭な設計は結果を評価できないので、何の学びも蓄積されないし、直すことも難しくなります。
このようにあらゆる場面で意思決定が求められるので、覚悟をもってのぞむ必要があります。
終わりに
今までは、こういった新規開発の混沌とした現場でのノウハウは言語化を怠っていた部分もあったのですが、改めて言葉で伝えていくことの重要さに気づきました。ここで挙げた内容はまだほんの一部だと思うので、またどこかのタイミングでアウトプットできればと思います。
ちなみに、実際に混沌の中で意思決定した話はコチラにも書いていますので、よかったらご覧くださいませ。
tech.speee.jp
また、Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁
Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
