０→１フェーズの実録!アジャイル開発
本記事は株式会社パタンナー アドベントカレンダー 2021 10日目の記事です。
前回の記事では、エンジニアさんと一緒に取り組んだ技術選定について振り返った。使う技術が決まったら、実際にプロトタイプ開発に進む！開発を通じてリーンスタートアップできるチームの作り方を経験で学習していく。
本記事は、アジャイル宣言に対する自分なりの解釈と実際に取り組んだアジャイル開発プロセスの紹介をおこなう。前回の記事は下記のリンクから読めるよ。
はじめに
アジャイル開発とは何か
説明不要。素晴らしい考え方は原典にあたるほかない。
1. プロセスやツールよりも個人と対話を
Individuals and interactions over processes and tools
2. 包括的なドキュメントよりも動くソフトウェアを
Working software over comprehensive documentation
3. 契約交渉よりも顧客との協調を
Customer collaboration over contract negotiation
4. 計画に従うことよりも変化への対応を
Responding to change over following a plan
俺が考えたアジャイル開発の前提条件
1 チームでおこなう
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
じゃないほう起業家であれば、ソフトウェアを早く継続的に提供するためには継続的に力を貸してくれるエンジニアが必要不可欠だ。資金に余力があるならば、フルタイムのエンジニアと一緒にプロダクトをつくりたい。
０→１フェーズで避けたほうがいいことは二つある。まず、海外にアウトソーシングすること。つぎに、受託開発企業に依頼すること。理由は明確だ。じゃないほう起業家が外部の開発チームを自己組織化できるわけがない。思い上がりも甚だしい。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
2 リリース日にコミットする
アジャイル開発で注目すべきは、ドキュメントよりも動くソフトウェアという点ではない。動くソフトウェアをいつリリースするか？と考えた。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
弊社の場合は、複業のエンジニアさんが週2~3日力を貸してくれる開発体制だ。そのため、1ヶ月の稼働自体がフルタイムエンジニアの2~3週間に相当する。そこで、リリース日はキックオフから約2ヶ月後の7月とした。
3 動かすことで検証したいことを一つにしぼる
機能をひとつに絞るのではない。検証したいことをひとつに絞る。例えば、ログイン機能を実装したところで、何が検証できるだろうか？解決したい課題を抱えている顧客を救うだろうか？答えはノーだ。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
たとえば、弊社の場合は検証したいことは5つの情報を1つにまとめることで、データ分析を依頼した人と実際にデータ分析をおこなう人の生産性が上がるかどうか？だ。（厳密には、生産性という言葉をより具体的に記載する必要がある）
データサイエンスのプロジェクトにおける5つの情報
（1）分析目的をはじめとする「概要」
（2）実際に取り扱う「データの仕様」
（3）ver.1から最終版まで一覧化された「レポートリスト」
（4）プロジェクトに関する「ディスカッションの記録」
（5）実際にアウトプットが役立ったのかの「評価」
上記の検証したいことは、ローコード開発では再現がむずかしかった。
1 開発定例をおこなう
1. プロセスやツールよりも個人と対話を
エンジニアさんと対話しながら開発するスキームをつくった。毎週必ず開発に関するオンライン会議をおこなうシンプルなスキームだ。
1.1 チケットの着手開始日を合意する
開発のチケット（タスクのことだよ）は、期日ではなく開始日を設定する。期日はアンコントローラブルだから、そもそも管理しやすいものじゃない。
要求の変更はたとえ開発の後期であっても歓迎します。
また、アジャイル開発は要求の変更を認める。要求の変更は予め合意した期日とトレードオフ関係にある。
世の中で最もかっこ悪いマネジメント手法は期日に間に合っているかどうか確認する作業だ。もはやマネジメント（管理）ですらない。
期日というアンコントローラブルなものを管理しても、建設的な対話は生まれない。だってもう間に合ってないから。そのうえ、メンバーはマネージャに対して「すみません、間に合わせます。」という宣言しかできない。そんな不文律がうまれる。この宣言は、無理やり宣言させただけである。合意になっていないから遅延リスクが高い。結局管理できない。（だってはじめからアンコントローラブルなのだから）
1.2 お互いに相談したいことを話す
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
開発定例のメイン議題はおおきく二つある。１つ目は、進捗状況の確認。前述の通り、計画通りに開始できているか？を厳密に確認する。完了していればステータスを「完了」に変更する。「未完了」チケットは完了予定日をエンジニア相談し合意し、その後合意した日付に修正する。
二つ目は、お互いに相談したいことを話す。
じゃないほう起業家はエンジニアに開発の力を借りている。アジャイル開発において起業家はプロダクトマネージャーだ。同じチームメンバーとして俺でもできることを最大限見つけて、全力でやっていく。
（実際は前半部分だけエンジニアさんが同席してくれたので、めっちゃ助かった）
弊社の場合、エンジニアは本業が終わってから開発を進めてくれている。AWSのサポートは手厚いものの、平日の営業時間の範囲内である。起業家である自分が役立てる部分だ。エンジニアさんのように端的な質問文は作れない。でも、問題の大枠を理解して平日の営業時間内にソリューションアーキテクトに相談できる。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
1.3. フェイス・トゥ・フェイスで話す
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
開発定例は完全オンラインで実施している。でも顔を出して話すようにしている。Slackで伝えたことも、開発定例では重ねて伝えるようにしている。
2 すぐにユーザに届ける
2. 包括的なドキュメントよりも動くソフトウェアを
アジャイル開発宣言に不足しているのは、リリースの定義だとおもう。どの程度で「動いている」と判断するのか基準が見えなかった。
アジャイル開発しているのに上手くいかないケースを振り返ってみた。プロダクトオーナーがとにかく品質に対してノーという。ゴーサインがでない。だから短い間隔でリリースできなくなる。
逆に言えば、動いてさえいればゴーサインを出そう。これを続ければ、アジャイル開発をほんとうの意味で実行できる。そう考えた。
2.1 バグや課題は事前に把握していれば問題ではない
実際に不完全な要素があっても、検証したい動作を実装できていたのでリリースした。大きな気づきがあった。ユーザからのネガティブフィードバックを2つに分けて理解したほうがいいという気づきだ。
たとえば、α版には削除機能を実装していない。そして戻るボタンも実装していなかった。また、ディスカッション機能は実装してもいつ投稿されたのかを把握するための通知機能も実装していなかった。検索機能も検索範囲をアップデートする必要があった。やっていないことなんて沢山あった。
ユーザのフィードバックを見ると、「そうそう、そうなんだよ。実装していないんだよ。」といった事前に我々が把握していた内容に関する想定内のフィードバックと、「え？マジで？そんなことあった？テストしたはずなんだけどなぁ〜」「ほ〜そういう機能が欲しいのか！」といった想定外のフィードバックがあった。
アジャイル開発の最大の魅力は、早い段階で開発側が想定しなかったフィードバックを得られること。体験から学んだ。
2.2 ユーザーを信じる。ユーザーの力を借りる
3. 契約交渉よりも顧客との協調を
ゲーム業界だとコアなユーザにテストモニターとして発売前のゲームで遊んでもらうことが当たり前だ。アジャイル開発において、プロダクトオーナーやプロダクトマネージャーにこういうスタンスを持ったほうがいいとおもった。
「今まで無かった。今それがある。」この事実だけでで感謝してくれるユーザーがいる。発売前なのに触れることができる。そういう特別感に喜んでくれるユーザーがいる。
正直、自分自身が想像した以上にユーザーは建設的なフィードバックをくれたとおもう。これからも、逆にプロトタイプ触れるなんてチャンスだよ？今だけだよ？貴重だよ？メンタルでいこう。
3 ガチで変化に対応する
4. 計画に従うことよりも変化への対応を
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
実際問題、要求の変更を歓迎するためには相当パワフルな開発力と開発体制が必要だとおもう。この点においてはアジャイル開発ってだいぶストイックというか、そもそも選ばれた開発チームしか挑戦できない開発プロセスであり思想なんじゃね？とすらおもった。
3.1 できる範囲でいいから確実にアップデートする
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
アジャイル開発宣言の背後にある原則を繰り返し繰り返し読む。持続可能ってなんだろう？自分の頭で考えた。今の開発チームができる範囲でやっていくことだとおもった。無理があると持続できない。
そこで、一つ一つの改善を小さく小さくできる範囲のチケットに分解していく。たとえば、「作成したストーリーが探しづらい」という課題に対して、表示件数を増やすといった、一覧性を高めるという解決策で一次アップデートした。
アップデートする姿勢をテストユーザーに見せる。そういうスタンスを持った開発チームになることが、これから素晴らしいプロダクトに進化させていく上で重要だとおもった。
その次に、二次アップデートをおこなった。
3.2 小さなフィードバックに全力でよろこぶ
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
アジャイル宣言はかなりハイレベルな宣言だ。高度なチームカルチャーが前提条件になっているから。意欲に満ちるためにできることってなんだろうか？自己組織的に「もっとこうしたほうがいいと思うんだけど、どう？」って言い合えるチームになるためにできることってなんだろうか？
リリースしたプロダクトの利用ユーザー数が急速に増えたり、その結果売上も急増。会社自体が急激に成長する。これ以外にないだろう。それがスタートアップの現実だとおもう。あくまでもビジネスの上に成り立つものだから。
０→１フェーズはどうだろう？あくまでも検証段階だ。俺は小さなフィードバックも全力で喜んだ。フィードバックが得られたことに脳汁が流れるように意識した。使ってもらえただけでどれだけ進捗だろうか。2ヶ月動くソフトウェアがデプロイされて、ユーザーに使ってもらえたんだもん。すごくね？ビール飲んでおｋまる！
おわりに
アジャイル開発は、自分の頭で考えて最適化するもの
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイル開発って宣言だぜ？笑っていう記事とか、ウォーターフォール型との違いを説明する記事なんかはある。
でも、アジャイル開発を具体的に発信している情報がなかった。そういうわけで、弊社なりのアジャイル開発を振り返った。自分たちの頭で考えてやってきた。じゃないほう起業家の役に立ったら嬉しいとおもう。
バーニングニーズは捉えていない現実
よーくみると、フィードバックの回答者は4名（利用者は20名弱）。プロトタイプは限定利用だった。
リーンスタートアップ理論的にはバーニングニーズ（喉から手が出るほど欲しい。今すぐに買いたい。）を捉えていないプロダクトを開発していたことになる。これは紛れもない事実だ。弊社の重要な課題である。
4月に採用活動をおこない、5月から7月までアジャイル開発を実践してプロトタイプを限定リリースした。リーンスタートアップ理論を実践するためにチームを作り、チームで効果的にプロダクトを作るプロセスを経験した。
前準備が終わった。このチームで遂に向き合うべき時がきた。弊社の第３四半期（8~10月）、顧客開発フェーズだ。（続く）
この記事が気に入ったらサポートをしてみませんか？