四苦八苦しながらも、未知の「アジャイル開発」と少しずつ仲よくなっていってる話
こんにちは！DIGGLEでPdMをやっております齋ノ内です！
この記事ではDIGGLEのプロダクトチームで採用されている「アジャイル」という開発手法に初めて関わる中で感じたギャップや、苦戦しながらもアジャイルと向き合ってきたお話をさせていただければと思います！
この記事で伝えたいこと
これまでのキャリアの中でも、PdMとしての役回りではないものの、プランニングや企画立案を行ってきた経験がありますが、アジャイルという開発手法に触れたのは本職が初めてです。
▼私の前職については前回の入社エントリーで少しだけ触れています
なので今回のこの記事は
これからアジャイル開発に挑戦するけど、成功談より失敗談を聞きたい
自分も何かしらの役回りでアジャイル開発に向き合ってるけど、なかなか慣れなくてまさに今苦労している(共感したい)
DIGGLE社の環境でどうやってアジャイルに順応しているのか気になる！
みたいな人を意識した記事になります！
「アジャイル開発とはこうや！！」みたいなナレッジ共有や持論を展開する記事ではないので、既にゴリゴリアジャイルで回している諸先輩方は、「自分にもこんなころあったわね」と菩薩のような面持ちで見守ってくださいませ。
アジャイル開発とは？
共通理解のため、一般的なアジャイル開発についてまずは触れておきます！
DIGGLEでも採用している”アジャイル開発”とは、顧客の持つ課題や開発する機能対象を小さな単位に分割し、段階的に進めていく手法です。
小さく分割することの何がよいのかというと、一つ一つの課題を解決できる機能や価値を「早く」作り、ユーザーに届けられることです。
これにより、変化する要件にも柔軟に対応できる点が大きな特徴です。
DIGGLEがアジャイル開発を採用している理由
めっちゃ端的にいうとSaaSプロダクトだからです。
SaaSプロダクトのビジネスは基本的に
価値があれば使い続けてもらえる
価値がないと判断されればその場で使われなくなる
という特性があり、常に顧客の求める価値を提供し続ける必要があります。
そしてこの「顧客が求める価値」は常に変化し、そのスピードは非常に早いものです。なので、「1回提供して終わり」なんてことはなく、このすぐ変わる「顧客が求める価値」をキャッチし、連続的に素早く提供できるかどうかが、SaaSプロダクトに求められる要件となります。スピード感を保ちながら、柔軟にプロダクトを進化させることができるため、SaaSではアジャイル開発が採用されている、というわけですね。
アジャイル開発とよく対比される手法が「ウォーターフォール開発」。 全体の計画を立ててから順に進めていくイメージで、要件が決まっていてゴールが明確な開発シーンで使われ、原則として一度決めた計画通りに進める必要があります。
それゆえ、流動性の高い顧客価値を事前に予測することの難しさから、一般的にSaaSプロダクトと相性がよくないとされているようです。
入社するまでに認知していた開発手法
前職では明確な開発手法が定義されていませんでしたが、今思えばウォーターフォール開発に近い進め方だったかもしれません。
良い悪いではなく、それ以外の方法があるということすら知らなかったので、特に疑問や課題感を持っていたわけではありませんでした。何なら「全部最初に決める以外にやり方なんてあるの？」くらいに思っていました。なかなかの世間知らずでしたね。
それゆえに、新しい「アジャイル」という開発手法に出会ったとき、この考え方の違いに驚き感動する一方で、正直順応するまでに四苦八苦することになります。
次項にてその詳細をお伝えしたいと思います。
アジャイル開発で苦戦したこと、悩んだこと
1.完璧さを手放す勇気
◆これまでの進め方
後戻りがないよう最初からすべての要件や計画を緻密に立てた上で進行することが多くありました。
「せっかく作った企画、後戻りしないようにしっかり調査して、理論武装しよう！」
という前のめりな熱量でたっぷり時間をかけてリサーチや情報収集を実施し、不確実なことを極力排除し、プランニングに何日も時間をかけていました。
今思えば「完璧で穴のない企画」を作ることが仕事のゴールだった感はあります。(実際穴だらけでしたが)
◆アジャイル開発での進め方
今の環境下では完璧さよりも、まず動いてみて、改善することで、少しずつ確実に正解に近づくことが求められます。 そのためプランニングにおいても、ユーザーが持つ課題を一定レベルの仮説で説明できればプランニングとしては完了し、素早く立案・提案することが重視されます。
◆直面したギャップ
完璧ではない状況でプランニングの方向性を”決める”ことの難しさにぶち当たりました。
素早いサイクルでの提案が求められるアジャイル開発下では、不確実な要素がある中でも、PdMとしては企画の方向性を方向づける必要があります。
「まだ十分に自信をもって進められないぞ……」と守りの姿勢に入りたくなる瞬間もあるのですが、いくらリサーチや理論武装をしても「完璧」にはなりません。 不確実な情報や制約の中でもどこかで決めきるという、大げさに言うと一種の「覚悟」をもってお客さんにデリバリーするマインドが必要なのですが、最初はどうしてもその決断がなかなかできずにいました。
2.スケジュール把握における考え方の違い
◆これまでの進め方
企画全体の計画を最初の工程で作り、それに従って各工程を進めていくという考え方でした。そのため、最初に「いつリリースするのか」ということを決めるため、プロジェクトのゴール時期と、現在その進捗がどのようになっているか把握することができていました。
◆アジャイル開発での進め方
しかしアジャイルでは、「常に変化する」ことが前提であり、顧客への提供スケジュールももれなく例外ではなく、この変化に順応することが求められます。
進行中の各企画は、他の機能進捗や顧客のフィードバックなどの影響を踏まえ、状況に応じて進行スピードや優先順位が頻繁に変わるので、いつリリースになるのかは厳密には約束されていません。
◆直面したギャップ
このため、「いつリリースされるのか」というのが追いづらく、常に変化し続ける状況に自分自身が適応する必要があるのですが、先の見通しが立たず、現在地を把握しづらい環境に戸惑いを感じました。
これまで、企画単位で設定されたスケジュールをウォッチすることが当たり前だったことからゴールの時間軸が固定されていないことに不安を感じ、「もしかしたら自分だけがリリースタイミングを知らないだけで、みんな知ってるのかもしれない……」なんて妄想までするようになりました。
3.企画が提供できる価値の違い
最後に、1企画あたりの提供価値にもギャップを感じました
◆これまでの進め方
これまでは、1つの企画で可能な限り多くの価値を提供することを重視していました。できるだけ広範囲のユーザーに対応できるような機能を一度に詰め込み、すべての課題を一度に解決しようとすることが多かったです。「あのユーザーも、あの問題もみんなこれで解決できる！」みたいな壮大な企画に熱を注いでいました。
◆アジャイル開発での進め方
アジャイルでは、「1つの機能を少しずつ改善していく」というアプローチが基本です。
最初からすべての課題を解決するのではなく、ユーザーが最も困っている部分を特定し、そこから段階的に解決策を最短で提供していきます。
小さな価値を積み重ねていくことで、結果的に顧客に確実に価値を届けるという進め方です。
◆直面したギャップ
気をつけてはいましたが、無意識に「あれもこれも解決したい！」と欲張りプランニングをしてしまうことがあります。 あとで読み返すと「読みごたえはあるんだけど、結局これって何を解決したい話なんだっけ？」という問いに明確に答えられないものになっていたりします。
ユーザーの課題をできるだけ広げず、「このテーマで解決したい課題は何か？」を明確にし、そこに向けた解決策が導き出せるようなミニマムな企画を積み重ねていくことが求められるのですが、どうしても1回で多くの成果を求めてしまう欲深さが出てしまい、「小さく作る」ってこんなに難しいんだ、と思い知ることが多くありましたね。
どのように克服しようとしているか
■アジャイルを体現した他メンバーの動き
まず「完璧さ」に固執した思考を少しずつ手放しつつあるのですが、これは、不確実な状態でも「とにかくやってみる」ということをチームとして体現し、実行している姿を常に見ていたからだと思っています。
「失敗したらまた考えましょう」
「ここは出してみないと誰にも分からないですね」
こんな会話や意思決定を常日頃から目の当たりにする中で、誰も完璧な状況ではなく、不確実性と戦っているんだということを自然と理解することができるようになりました。 アジャイルを概念として採用しているのではなく、日々実行に移している環境のため、生きたアジャイル思考を身近に感じることができます。
アジャイルは開発の手法ではありますが、一種の考え方や価値観と捉えることもできるため、具体的にどのように体現されているか、この目で見て理解することが重要な気がします。
■アジャイル思考は当たり前ではないという配慮
上記だけみると、私が自力でアジャイル思考を身につけたように聞こえてしまうかもしれませんが、神に誓ってそんなことはありません。実際にはチームのサポートがあってこそです。
チームでは、アジャイル思考を深めるための機会として「価値観の共有」や「輪読会」などの機会が定期的に提供されています。これらの場を通じて、アジャイルの概念に触れ、理解を深めていくことができました。
これらの機会も嬉しいのですが、実は一番助かっているのは、
アジャイルの考え方に慣れてないんだろうなという前提でのコミュニケーションをとってくれることです。
例えば、提案した企画に対してフィードバックをもらう機会があるのですが、
そのフィードバックは単に良し悪しを評価するフィードバックではなく、そもそも企画を立案する際にアジャイル思考に基づく企画にするためにはどういう考え方をすればよいか、という視点でフィードバックをもらえます。
どれくらいアジャイルと乖離している思考をしているのかは、個別具体で把握するのが一番理解できるので、非常に納得感があります。
アジャイルをプロダクトチームの基本思想としつつ、個々のメンバーの習熟度に合わせたサポートをしてくれるチームの姿勢にすごく救われています！
今後アジャイルとどう向き合っていくか？
今の私は率直に、まだアジャイル開発手法の考え方を習得した！とは言えない状態です。これまで染みついた考え方とのギャップにところどころ悩みつつも、少しずつアジャイルをベースにしたプロダクト作りにくらいついている、といった感じです！
悩むところも多いですが、この半年間アジャイル開発思考と向き合ってきたことで、不確実に向き合う耐性が以前よりはついたのかな？と思えるようになり、その点はすごくポジティブに捉えています。ゼロイチではなく、少しずつゴールに向かって行く考え方は、トライするチャンスも多く、自身の成長にも繋がりそうです。
何より人としての柔軟性も身についたんじゃないか、と期待したいですがここは自己評価するところではないので、近々家族にでも聞いてみようと思います。(笑)
あと、改めて考えると、仕事そのものが不確実で曖昧な状況の中で意思決定を下すことが多いと感じます。
今後は、開発に限らず「働く」という広い視点でアジャイルの考え方を取り入れ、日々の仕事に活かしていけたらいいな、と思っています！
さいごに
アジャイルって聞いたこともないけど本当に大丈夫かな？と思っている方も、この記事を見て、アジャイル開発への向き合い方が変わるようなヒントを得てもらえたえらとても嬉しいです。
もし仮にアジャイルの壁にぶち当たっても、チームでサポートし、私は一緒に悩むことができます！！笑
なので、アジャイルとの距離がある方もお気軽にお話しませんか？
興味があればぜひ、PdMとして一緒に働いてみましょう～！