アジャイルで変化を味方につける

1.本当に必要なものは何か？

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
引用：アジャイルソフトウェアの12の原則(https://agilemanifesto.org/iso/ja/principles.html)

上記は「アジャイルソフトウェア開発の12の原則」の一節です。アジャイルを実現するための行動指針の中でも、特にポイントになる所だと思います。

①「要求の変更」はよく起こる

ソフトウェア開発は要求から出発します。開発側が課題を正しく把握できていないと、お客様の満足は生み出せません。コミュニケーションをとり認識齟齬を減らすことはできますが、そもそも、お客様が表明している「欲しいもの」は「本当に必要なもの」でしょうか？
お客様が自分自身の課題を理解して言語化できているとは限りません。そのため、プロダクトを触ることで「欲しいもの」と「本当に必要なもの」のギャップに気付くことになるのです。

定番の開発手法であるウォーターフォールの場合、工程を分けて段階的に進めていく流れをとるため、お客様が動くソフトウェアを目にするのは開発の後期になります。 この段階で「本当に必要なもの」が発覚し仕様変更となると、上流工程まで遡る大幅な修正が発生してしまいます。前工程に間違いがないことを前提とした開発モデルのため、変更に弱く、要求から乖離したまま作りこんでしまうリスクがあるのです。

一方、アジャイルではスプリント（開発の間隔、1～4週間程度）ごとにリリースを繰り返す戦略を取ります。早期から動くソフトウェアを触りながら認識を合わせ、小さく軌道修正をまめに行うことで、大きな手戻りを防ぐことができるのです。
「機敏さ」を語源に持つアジャイルですが、これはゴールまでの到達速度のことではありません。 アジャイルが大切にするスピードとは、「起こった出来事に対してすばやく反応し、意思決定する」「方針の変更やニーズの変化などに臨機応変に対応する」ことを指します。 アジャイルを導入さえすれば作業速度が上がり開発工数の削減がかなうというわけではないということです。

②「歓迎」が価値を高める

仕様書にばかり固執しても、「本当に必要なもの」からはますます遠ざかってしまいます。変化に対処できず、お客様の欲しいものに合わせるのではなく仕様に合わせて作ることになり、下手な推測や誤った前提を招き寄せ、多くの時間を無駄にすることになります。そのためアジャイルではお客様との対話を大事にしています。
お客様にとって価値のないシステムを作っても意味はありません。課題解決に役立たないソフトウェアは開発しても残念ながら使われることはないのです。 しかし、お客様に言われるがまま変更を受け入れるべきではありません。要求の本質を見抜き、変更の受入を判断する必要があります。 お客様のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉えましょう。

2.立ち止まれないビジネス

ITはビジネスにとって不可欠なだけでなく互いに影響を与え価値を高めあっています。

完成品リリースでプロジェクトが終了する場合、リリース後は開発の手を離れているため、環境の変化に伴ってビジネス価値は下がっていくことになります。 IT技術の発達もあり、ソフトウェアビジネスは売り切り型から継続的に価値を提供する提供形態へと変化をしています。

消費者は物の所有からサービス利用にシフトしつつあります。サブスクリプションサービスでは、ユーザーに解約されない必要なソフトウェアであり続けるためにも、リリース後のサービス向上とタイムリーな需要を満たすことが求められています。

このように刻々と変化するビジネス要件に迅速に追従していける組織体制が必要です。 扱える情報量が増え、変化が激しく複雑で不確実なこの状況では、従来のような「問題を分析して論理的に解決するパラダイム」よりも、「観察とフィードバックによって探索と適応を繰り返す未来創出型のパラダイム」が有効なのです。

3.まとめ

アジャイルは変化に対応するための柔軟さを失わないための心構えだとも言えます。変化する複雑な世の中において、お客様に寄り添って改良を重ねていきたいプロジェクトには、アジャイルが役に立つかもしれません。
当然すべてのプロジェクトがアジャイルになるべきだとは言いません。ですが、いま一度ご自身のプロジェクトを振り返っていただきアジャイルが向いているか再考されてはいかがでしょうか。