このコラムシリーズでは、開発組織をリードする方にとって必要な「プロダクト作りの在り方」をテーマに置きます。プロダクト作りにおける「正しいものを正しくつくる」とはどういうことなのかに向き合っていきます。今回は、まずその入口である「アジャイル開発」を捉えます。
アジャイル開発なんて当たり前
「開発は当然アジャイルにやる。スクラムが基本。」アジャイル開発について、そう捉えている方は多いように思います。私は様々な開発現場、開発チームにメンタリングや支援で関わることが多く、そこで見えてくるのは認識の隔たりです。アジャイル開発について「全く自信が無い」か「自分たちは出来ている」の2つです。
さらに後者の皆さんの話を聞いていくと、いわゆるスクラムの教え、プラクティスを理解しているという内容が大半です。ただし、理解の仕方にも幅があります。実際に実践しているという現場もあれば、見たり聞いたりして理解しているという現場も少なくありません。見聞きレベルでは、まだアジャイルへの取り組みのスタートラインに立った段階です。これから数多くの実験と失敗を繰り返す中で、実践知を自分たちに刻み込んでいく過程が必要になるでしょう。
「実践」についてもう一歩踏み込んで捉えてみることにしましょう。実践にも2つの捉え方があります。いわゆる「Do Agile」「Be agile」という2つです。「プラクティスを実践している」というのは、「Do Agile」段階の場合があります。「Do Agile」すなわち「アジャイル開発をする」というのは、まだアジャイルの本質に辿りついていません。アジャイルの本質は「Be agile」の方にあります。
Be agileとはどういうことか？
「Be agile」とは、「アジャイルである」ということ。つまり、自分たちの状態、在り方についての捉え方です。在り方がアジャイルであるということは、プラクティスを忠実に実行していくことに重きを置くのではなく、常に自分たちの開発に向き合い、より良くするために工夫を重ねていこうとする意思と行動が伴っているということです。「スクラムしている」という表現とは開きがありますよね。
私達が取り組むソフトウェア開発は容易ならざるものばかりです。不特定多数のユーザーを相手にするようなサービス開発では、「これを作れば良い」という正解がなく、探索的にならざるを得ません。一方、エンタープライズなシステムであっても、関係者が複雑に絡みあい、どのような機能性を備えれば良いかの合意形成が一筋縄でいかない場合があります。
こうした状況に対して、一つの定められたやり方で臨んで事が済むはずがありません。自分たちのやり方や在り方を模索し、状況に適応していくことが求められます。もしアジャイルへの取り組みの入り口が「Do Agile」だったとしても、やがて「Be agile」に向いていかなければ、行き詰まったり、問題を乗り越えられないという事態を迎えてしまうでしょう。
さて、「Do Agile」は「何ができていて、何ができていないか」という見方で課題が見えやすいと言えます。一方、「Be agile」というのは、どうあるか？という漠然とした問いかけに向き合う必要があり、捉えづらさがあります。この問いに自分たちなりの答えをどのようにして出していくのか。切り口は、「Why」を考えることです。
「なぜ、アジャイル開発なのか？」に向き合う
ゴールデンサークルという概念は有名なので、ご存知の方も多いでしょう。サイモン・シネックという方が提唱した思考のフレームワークです。この考え方では、「なぜ（Why）」を考えるところから出発することを基本と置いています。
「何をするか（What）」や「どうやってやるか（How）」から出発すると、やること自体が目的となってしまって、何を狙いたかったのかがぼやけてしまう恐れがあります。「Do Agile」は「What」レベルの思考と行動と言えます。
このフレームワークに習って、「なぜ、アジャイル開発なのか？」というWhyを捉えることから始めましょう。それはつまり、アジャイル開発の意義について考えるということです。アジャイル開発の意義を踏まえた上で、自分たちの現場としてどうありたいのか？を見出していく。そのような思考の過程を辿りましょう。
アジャイル開発9つの意義
アジャイル開発の意義として、次の9つをあげましょう。
- フィードバックに基づく調整で、目的に適したソフトウェアに仕立てられる
- 形にすることで早めに関係者の認識を揃えられる
- つくるものやチームについての問題早く気付ける
- チームの学習効果が高い
- 早く始められる
- 結合のリスクを早めに倒せる
- Time to market が短い
- サンクコストが小さくできる
- 開発チームのリズムを整えられる
これらはあくまで私が捉えている意義です。もちろんこれら以外の意義も考えられるでしょう。
では、9つの意義について一つずつ掘り下げておきましょう。
1. フィードバックに基づく調整で、目的に適したソフトウェアに仕立てられる
これは、アジャイル開発の最も根本的な目的と言えます。先に述べたように「プロダクトとして何を作るべきかの正解を誰も持っていない」ような開発は探索的になります。そのような状況では、想定しているユーザーからのプロダクトへのフィードバックは、何を作っていくかを知るための大切な手がかりです。逆に言うと、何らかの事情により「これを作れば良い」という内容が決まっている開発では、アジャイル開発の意義が薄れていきます。ただし、「これを作れば良い」という内容が関係者の思い込みであったり、想定に依るところが大きい場合は、そもそもその開発を進めるべきなのかという判断を精査したいところです。
2. 形にすることで早めに関係者の認識を揃えられる
早期に形にする、触れるものをつくれると、「何を作るべきなのか」という関係者の気づきや理解を促すことができます。そして、「われわれは必要なものは何か」についての合意を形成していく取り掛かりになるでしょう。
3. つくるものやチームについての問題早く気付ける
これも、早く形にすることで得られる効用です。1スプリント目から何か動くものができる。そのためには、何が準備できていないといけないか、どういう役割が必要かが突きつけられるはずです。その結果として、作り進めていくための問題にも早く気づくことができる。それが1スプリント目から分かれば、その後巻き返しする時間も十分にあります。
4. チームの学習効果が高い
チームを固定することで得られる効果です。同じメンバーで、スプリントの活動を繰り返すことで一つのプロダクトを作り上げていく。その過程で得られる学びは、すぐに次のスプリントで活かすことができます。
5. 早く始められる
プロダクトを作り進めるための詳細な準備を最初の数スプリント分に限定することができる、つまり準備を最小限にできるということです。早く始められれば、当然早く形を作り出すことができます。早く形作ることの意義はすでにここまで挙げてきたとおりです。
6. 結合のリスクを早めに倒せる
これは作り方に関する利点です。チームメンバーがバラバラに作り進めていき、どこかの時点でインテグレートする、というやり方では、その結合時になってはじめて思い違いが明らかになるということが珍しくありません。そうした認識の相違をリカバリするための開発は、相応の手戻りを必要とし、プロダクトづくりを足止めすることになります。
7. Time to market が短い
少しずつ形づくっていく開発であれば、ある程度機能性が構築できた段階（例えばMVP(Minimum Viable Product)を仕上げた時点）で市場に投入ができるということです。早期に市場に投入できれば、最初の意義のとおりそのフィードバックが早く得られる、また収益化を早期に期待できるなどの利点が考えられます。
8. サンクコストが小さくできる
一気に全ての機能を揃えていくような開発ではないため、プロダクトに見切りをつけた段階で開発を止められる。必要なコストはそれまでのスプリント開発の分に留めることができると言えます。
9. 開発チームのリズムを整えられる
1スプリント目から開発に必要な行為や準備、チームに求められる協働が明らかになっていくため、開発の進め方自体を早期に整えられるということです。
以上が、アジャイル開発で考えられる意義です。こうした意義がすべて備わっていないと「Be agile」ではないというわけではありません。ですが、9つの意義が一つも見いだせない状態では、アジャイル開発を志向する必然性があるのか問い直した方が良いでしょう。あるいは、現場として相当な問題を抱えているのかもしれません。
どこへ向かうのか？
さて、こうした「どうあるか」という捉え直しは、どんな方向へと向かっていくのでしょうか。私は、アジャイルの意義はやがて「ともに考え、ともにつくる」という方向へ向かっていくと考えています。「ともに考え、ともにつくる」とはどういうことなのか。このコラムシリーズで扱っていきたいと思います。
