アジャイル

かつてソフトウェアは、家を建てるような進め方で作られていました。何か月もかけて何百ページもの分厚い設計書を完璧に書き上げ、その設計書に書かれた順番どおりに最後まで開発し、完成品をようやくユーザーに見せていたのです。水が滝の上から下へ一方向にしか流れないことになぞらえて、この方式を「ウォーターフォールモデル(Waterfall)」と呼びます。

ところがソフトウェアの世界では、ユーザーの好みも素早く変わり、新しい技術も毎日のように登場します。1年かけて計画どおりに作ったのに、いざリリースしたら「私がほしかったのはこれじゃないんですが…」と言われてしまえば、それまでの努力はすべて水の泡です。

アジャイルは、こうしたムダを防ぐために生まれました。出発前に道のりをすべて決めてしまう代わりに、小さくても実際に動く成果物をまず世の中に出します。そして実際のユーザーの反応を確かめながら、正しい方向へリアルタイムで羅針盤を修正していく方法です。

多くのアジャイルチーム、とくにスクラムを採用しているチームは、たいてい1~4週間ほどの短い反復期間を決めて仕事を進めます。この短い開発サイクルを「スプリント(Sprint)」、または反復(イテレーション/Iteration)と呼びます。スプリントが終わるたびに、チームは実際に動く成果物を作って見せ、フィードバックをもらいます。この成果物は、すぐにリリースできる状態を目指します。

たとえば新しいフードデリバリーアプリを作るとしましょう。最初から決済、レビュー、ポイント、クーポンの機能を1年かけて全部完成させようとはしません。まずはメニュー一覧を見て電話ボタンを押せるだけの、とてもシンプルな初代バージョンを作ってリリースします。そのうえで、ユーザーが本当に求めている機能は何かを観察するのです。

ユーザーが決済機能を先に求めるなら次のスプリントで決済を先に作り、おすすめ機能が必要だと言われればおすすめ機能を先に開発します。このように早いリリースと継続的なフィードバックを絶えず繰り返しながら、プロダクトを少しずつ賢く育てていくのです。

もう少し正確に言うと、アジャイルは「計画をまったく立てず、その場しのぎで働くこと」では決してありません。むしろ計画に盲目的にしがみつく代わりに、状況の変化に合わせて計画をずっと頻繁に見直し、機敏にアップデートしていく方式です。

またアジャイルは、固定された業務ルールやソフトウェアのことでもありません。コミュニケーションを大切にし、変化を恐れないようにしようという仕事の哲学・価値観に近いものです。そのため、この哲学を現場で実践するためのさまざまな具体的手法が一緒に使われます。

代表的なのが、スプリント、役割分担、振り返りミーティングといったルールをひとまとめにした「スクラム(Scrum)」です。毎日同じ時間に15分だけ集まり、スプリントのゴールに向かってうまく進んでいるかを確認してその日の計画を調整する「デイリースクラム」は、その中の一場面にすぎません(立ったまま行うことが多いので「朝会」や「スタンドアップ」とも呼ばれます)。作業の進み具合をボード上のカードで見える化する「カンバン(Kanban)」も広く使われています。結局のところ、アジャイルの本質はやみくもにスピードを出すことではなく、変化に合わせて方向を機敏に切り替える柔軟さにあります。