大手企業におけるアジャイル開発と導入時のポイント

ソフトウェアを取り巻く環境は変化に富んでおり、それに対するニーズも当然刻々と変化していきます。このような状況下において事前に開発すべきものを詳細まで洗い出し、リリースまで変更せずに、計画的に開発を進めるスタイルでは環境やニーズから取り残されてしまい、リリースする頃には時代遅れになってしまうことも少なくありません。昨今、開発のアジリティを高く保つことが競争力の源泉の1つになっており、SquadやLeSS、​​SAFeなど、アジャイル開発においても拡張性に議論の焦点が集まり始めています。 こうした環境を鑑み、ソフトウェアを開発していく上で、その開発手法もウォーターフォール開発からアジャイルに主戦場が移り変わってきています。本記事では大手企業におけるアジャイル開発とその導入に焦点を当て、ポイントを解説していきます。

アジャイル開発とは

まず、アジャイル開発とウォーターフォール開発を比較することで、アジャイル開発の特徴を浮き彫りにし、認識を深めていきます。開発を進めていく上で、変数となる要素は大きく3つ（時間、リソース、開発要件）あります。 ウォーターフォール開発とは開発要件が決まっており、その要件を実現するために、必要なアサインを行い、スケジュールを引いて開発を進めていくものです。つまり開発の完了に焦点を当て、プロジェクトマネジメントを厳密に進めていくアプローチになります。他方、アジャイル開発では機能開発やイテレーションを進めていく上で、一定の時間とリソースが確保されており、その範囲で何を開発していくべきか考えながら、進めていくことになります。そのため、中長期的な開発計画を引くことなく、スプリントと言われる開発単位（主に1週間から1ヶ月程度）ごとに、プロダクトビジョン実現に向け、何を開発するか決め、ソフトウェアを進化させていくことになります。

上記の比較だけ見ると、状況に応じて柔軟に開発を進められるアジャイルの方が優位に捉えがちですが、そうとも限りません。環境変化に影響を受けず、事前に計画しまとまった時間とリソースを確保した上で開発を進められるのであれば、ウォーターフォール開発が適していると言えます。逆に、まだ明確な正解を見出し切れておらず、探索しながらプロダクトを進化させていく場合、一定のリソースと時間に制限を設けて、正解に近づけていくアジャイル開発の方が親和性が高いと言えるでしょう。

大手企業におけるアジャイル開発の導入

一般的に、大手企業ではIRや予算編成の制約があることが多く、事業計画を綿密に作り上げ、それに沿った事業運営が必要になります。また日本において、エンジニアを抱えて内製でプロダクト開発を行うことは少なく、社内で要件定義まで行い、開発を外注する傾向が強かったと言えます。このような背景から事前に計画を立て、実行していくウォーターフォール開発を採用するケースが多いように思います。

では、そもそも大手企業においてもアジャイル開発を導入すべきなのでしょうか。確かに、大手企業が数十年に渡って磨き込んできた基幹事業については予見可能性が高く、ウォーターフォール開発が適している可能性が高いでしょう。 他方、新規事業はいかがでしょうか。基幹事業とシナジーが生まれやすい周辺領域で事業展開するとは言え、その事業に対する解像度は基幹事業に劣ります。また、すでに収益化ができている基幹事業に比べ、これから立ち上げる事業については時間、リソースともに最小に抑えられることがほとんどです。そのため、一定の時間とリソースの範囲で、探索を進め、ソフトウェア開発を進めていく必要があり、不確実性に対して柔軟性が高いアジャイル開発の方が適切な選択と言えるでしょう。

アジャイル開発導入時のポイント

大手企業が強みとするウォーターフォール開発とアジャイル開発は大本のコンセプトや実現すべきゴールが明確に異なります。そのため、ただアジャイル開発というフレームワークを導入するだけではその本質は浸透することはないでしょう。ここでは、大手企業でアジャイル開発を導入していく上でのポイントを5つに集約し、説明していきます。

1. 経営陣のコミットメント

ウォーターフォール開発からアジャイル開発への移行は開発に対する発想を大きく変える取り組みになります。そのため、パイロット段階から経営陣の覚悟が必要不可欠になります。アジャイル開発によって実現したいことを明確にし、メンバーはもちろん、管掌する経営陣が把握し、コミットメントを示し続けることが成功に向けた第一歩になります。

2. メンバーの最小化と専任化

組織が大きくなると、専門性が上がり、組織のサイロ化が進みます。このような組織では何を進めるにあたっても、関係者が多くなり、膨大なプロジェクトマネジメントが余儀なくされます。他方、アジャイル開発では開発プロジェクトごとに必要なメンバーを最低限に絞り、専任にするのが原則です。つまり、少人数で専任のチームを組むことで、情報格差をなくし、開発効率を上げることができるのです。 大手企業にとって既存の組織設計とは相反する思想かもしれませんが、パイロット的に導入するなどの工夫を行い、メンバーの最小化と専任化は避けては通れない道なのです。

3. 意思決定フローの簡素化

また、組織が大きくなると、サイロ化だけでなく、ヒエラルキーも重厚長大なものになり、意思決定フローが複雑になります。このフローが複雑なままだと、仮にアジャイル開発を導入しても、本来の目的である環境変化への対応を実現できません。チーム内の意思決定は基本チーム内で完結するようにし、チームの自律性を担保することが重要です。チームを横断するような論点を扱う場合もプロダクトオーナーからのエスカレーションフローをできる限り簡素化した形で構築しておくべきでしょう。

4. アジャイル開発は作り上げていくもの

アジャイル開発は開発を回していく上でのフレームワークですが、原則は遵守しつつも、チーム内でプランニングやレトロプロスペクティブなどのプロセスを少しずつカスタマイズし、自分達にあった形にしていくことがゴールの1つです。そのため、教科書どおり導入して終わりではなく、各社、もしくはチームにあったアジャイル開発の形に進化させ、考え方を浸透させて初めて成功にたどり着くのです。

5. アジャイル開発は万能薬ではない

ウォーターフォール開発との比較で見たとおり、案件によってはアジャイル開発ではなく、ウォーターフォール開発の方が適していることがあります。時として、アジャイル開発は予見できないことを棚に上げ、計画せずに開発を進めるための言い訳に使われることがあります。そのため、全てアジャイル開発にすればよいというわけではありません。むしろ、案件によっては、大手企業が強みとしてきたウォーターフォール開発（計画を立て、予算を確保し、外注を駆使して、開発を進め、期限通りに行うこと）が生きることもあるので、注意が必要です。

まとめ

ソフトウェア開発やDXを推進していく環境は変化が激しいので、アジャイル開発の活用が不可欠です。大手企業ではいきなりアジャイル開発に全て移行するのではなく、新規事業などアジャイル開発と親和性の高い案件からパイロット的に導入を検討していくとよいでしょう。ウォーターフォール開発からアジャイル開発への移行は大きな考え方の変化を伴うので、トップリーダーシップが音頭をとり、しっかりとアジャイルの本質を見極め、フレームワークだけではなく、その考え方まで組織にインストールしていくことが重要です。ただし、アジャイル開発は万能薬ではなく、ウォーターフォール開発がアジャイル開発に劣後するわけではないので、時と場合によって使い分けが必要です。

参考文献

• Linkedin/ Agile's Big Problems in Big Companies
• signature / Top Agile Pitfalls & Why Agile Fails in Large Enterprises
• TechBeacon / 10 companies killing it at scaling agile
• Mckinsey&Company / How to mess up your agile transformation in seven easy (mis)steps
• 翔泳社/ ALL for SaaS SaaS立ち上げのすべて