アジャイル活用が最も遅れているフィールドは？
アジャイルのマニフェストが発行されてから20年近い歳月が経過した。今日、アジャイルの手法は、ソフトウェア開発の領域を超えてさまざまな分野で応用され始めている。例えば、マーケティングのチームが“スプリント”を試みたり、オペレーションチームが“スクラム”の考え方を取り入れたり、人事部のチームがアジャイル手法によって、人事戦略に柔軟性を持たせようとしたり、といった具合である。
そうした中で、ITの保守運用の世界に目を転じると、いまだに、アジャイルの手法をどう取り込むのが正解かの答えが出ていない状況にある。巷（ちまた）では、「アジャイル開発にどのフレームワークを適用するのがベストか」の議論がさかんに行われていたりする。
実のところ、こうした議論を深めたところで、あまり意味はない。というのも、アジャイルは、巨大で複雑化した問題を解決するための原理・原則であって、開発環境ではないからである。
アジャイルでいくか、いかざるべきか？
ITプロジェクトの中には、「全社で使う請求処理システムを刷新する」といった、業務横断的な調整が必要なものがある。このような複雑で、大がかりなプロジェクトを推進するに当たり、アジャイル的なアプローチの採用を検討する情報システム部門は少なくない。だが、実際にアジャイルが採用されるケースは稀である。というのも、ビジネスのあらゆる側面に影響を与える開発プロジェクトでは、考慮すべき要件がきわめて膨大で多岐にわたるからである。
周知のとおり、アジャイルのアプローチでは、システムの構築作業を始める前に、詳細な要件を固めたり、プロジェクトのフルスコープ（全対象領域）を定めたりはしない。それに対して、業務横断型、あるいは部門横断型の大がかりなプロジェクトにおいては、通常、細部にわたる要件定義やフルスコープの設定が必要とされ、関係者間で共通理解を確立する必要がある。理由は、プロジェクトチームの全員が、詳細な要件と目指す成果を理解していないと、出来上がったシステムが機能せず、すべての業務が滞る恐れがあるからである。
ならば本当に、このようなプロジェクトにアジャイルは使えないのだろうか─。私たちは可能だと考えている。ただし、そう考える理由は、一般的なアジャイルとは少し異なるかもしれない。
ここで思い起こしていただきたいのは、アジャイルとはそもそも何なのかである。言うまでもなく、アジャイルは行動規範・規則に類するものではない。それは、チームが日々の仕事の中で常に念頭におき、その考え方に沿って行動すべき方法論であり、一連の原理・原則であり、価値観である。
ソフトウェア開発チームはよく、“スクラム”や“カンバン”のフレームワークを自分たちのガイドとして活用する。ときとして、そうしたフレームワークが運用部門が携わるプロジェクトのシナリオにフィットしない場合があるが、だからと言って、アジャイルがまったく使えないというわけではない。システム構築のフェーズに発生する機能追加／変更要求への対応でアジャイルが役立つことがある。その考え方は、プロジェクトの目標を見定めて、それを小さな達成可能な作業に分割し、そこから反復して構築を進めるのと同じぐらいシンプルなのである。
ウォーターフォールが効く場面
ではここで、先ほど触れた「請求処理システムの刷新」のシナリオを想定しながら、アジャイルについて考えてみることにしたい。
考えられるアプローチの一つに、アジャイルの原理・原則に則った「プロダクト・バイ・プロダクト」のアプローチがある。このアプローチを取る場合、請求処理に必要な機能・システムを、商品ごとに逐次的に開発していく。言い換えれば、1つの商品に関する開発を終えたのちに、次の商品に関する開発に移る。こうする利点は、1つの商品に関する開発で学んだことが、次の開発に活かせる（あるいは、流用できる）点にある。
ただし、このアプローチを請求処理システムの刷新のようなプロジェクトに適用しようとすると数々の問題に直面することになる。商品の構造が単一ではなく、システム全体の要件が相互に複雑に絡まり合うからである。
例えば、ある商品は、他のある商品とバンドルされる場合もあれば、単独で販売される場合もある。また、ある商品はSaaSソリューションとして提供される場合、そのライセンス料がディスカウントされるかもしれない。あるいは、メーカーに対して、複数の商品をバルクで注文する場合もある。
プロダクト・バイ・プロダクトのアプローチを採用していると、こうした種々の要件に、いつ、どの段階で対処するかを決められなくなる。例えば、最初の商品のスコープや請求処理のプロセスを構築し始めるときに、すべての要件に対応しようとすれば、ほかの商品を担当するチームも、最初の商品の担当チームに参加させなければならなくなる。これでは、そもそもプロダクト・バイ・プロダクトのアプローチを採用する意義が薄れる。さらに言えば、複数商品にまたがってバンドルやバルク注文のオプションがある場合、その要件に、どの商品の担当チームが対処すべきかが見えなくなる。
このように考えていくと、請求処理システムの刷新にプロダクト・バイ・プロダクトのアプローチを適用するのは現実的に無理であることが分かってくる。もちろん、そうだからと言って、ウォーターフォールのアプローチでプロジェクトのすべてを回す必要はなく、ビジネス要件とソリューション要件が完璧に固まるまで、プログラムコードを1行も記述してはならないというルールはない。ただし、多種多様なビジネス要件と技術要件を満たすソリューションを実現するには、すべての要件をつなぎ合わせられるようにしておかなければならない。加えて、ミッションクリティカルになりうるエッジケースの徹底的な動作検証やストレステストを行う必要もある。
これは、金融やヘルスケア、エネルギーといった規制産業に属する企業においては、より重要な要件となる。システムの構築を開始する前に、法令順守や規制の枠組みを要件の中に取り込むことも、リスクマネジメント上、必須のプロセスである。
その一方で、システムを構築し始めてからも、ビジネス要件やソリューション要件は絶えず変化する。また、新しい法令が施行されるたびに、コンプライアンス上の要件も変わっていく。そうした変化に対応し、ビジネス上の付加価値として新しい機能やシステムを追加していくうえでは、アジャイルの原理・原則が有効に活用できることが多くある。
スムーズさが速さを生む
「急がば回れ」という言葉があるが、モノゴトをより早く進めるためには、動きのペースをスローダウンしたほうがいい場合がある。その逆に、動きのスピードを追求するあまり、物事がスムーズに進まなくなり、結果として、ゴールにたどりつくまでに多くの時間を費やしてしまうことも珍しくない。要するに、大切なのはスムーズに物事を進めることであり、動くスピードの高低ではないということである。
また、近年では、情報システム部門の役割が、社内の業務を安定して支えることから、ビジネスの成長と繁栄をサポートすることへとシフトしている。それに伴い、これらのチームには、“正しいモノを作る”ことがより強く求められている。したがって、どのアプローチを採用するかは重要なことではない。それよりも大切なことは、自社の顧客にどのような価値を提供するかであり、そのための早道がウォーターフォールか、アジャイルかの問題と言えるのである。
