エンタープライズアジャイル勉強会で「Disciplined Agileやってみた」という発表してきた

はじめに

こんにちは、CX事業本部モダンオフショア推進担当の藤村です。

2023年3月30日に開催されたエンタープライズアジャイル勉強会2023年3月セミナーで、「Disciplined Agileやってみた」という発表をしてきました。

概要

クラスメソッドの受託開発事業では、多くのプロジェクトでスクラムを実践しています。新規開発の場合、スプリント1を開始する前のフェーズをスプリント0と呼び、各種準備を実施していますが、何をどこまでやるかが不明確のため、プロジェクトによっては準備不足のままスプリントを開始してしまうという課題がありました。 今回はその課題解決の一つの取り組みとして、Disciplined Agileの方向づけフェーズの選択肢を用いてプロジェクトを開始した事例や、実践してみた上での気づきをお話します。

登壇資料

私の登壇資料はこちらです。

登壇内容ダイジェスト

コンテキスト

私が推進しているモダンオフショアチームで実践している受託開発のコンテキストは、上記のとおりです。スクラムによる1チームでの開発がほとんどのため、プロジェクトの規模としてはエンタープライズとは言えないかもしれません。また、いくつかの受注パターンがありますが、今回お話する内容に関連するのは、機能要件がざっくり決まっている、もしくは明確に決まっているがスコープや優先順位が調整可能なパターンとなります。

現状の課題

現状の課題は沢山ありますが、その中の「スプリント0でやることが不明瞭」という課題に対して、Disciplined Agile(以下「DA」)をガイドラインとして導入し、スプリント０でやることの明確化を目指してみた事例についてお話ししました。

DAのライフサイクル

我々が採用しているDAのライフサイクルはアジャイル型です。

スプリント0と呼んでいる期間は、アジャイル型ライフサイクルにおける方向付けフェーズとほぼ同義と考えています。

方向づけフェーズのプロセス・ゴール

方向づけフェーズの各種プロセス・ゴールに対して、スプリント0期間中にどこまでどうやって検討するか、その時の選択肢としては何があるかを、DA Browserを使って説明しました。それぞれのプロセス・ゴールで検討した選択肢については、発表スライドをご参照ください。

これらのプロセス・ゴールをガイドラインとして活用した結果、現在進行中のプロジェクトにおいては、スプリント0（方向づけフェーズ）の準備不足に起因する課題は発生しなかったため、一定の成果は得られているのではないかと考えています。

気づいたらDA実践していたこと

ライフサイクルの進化

われわれのアジャイルな受託開発では、開発前の要件定義や、開発後のリリース前準備などをフェーズを分けてしっかり行なう「初期開発」、初期リリース後に同じチームが引き続きスクラムで積極的に機能開発を行なっていく「継続開発」、新規開発はある程度落ち着き、縮小したチーム体制において粛々とカイゼンを繰り返す「運用保守」という進化を辿ることが多く、それはまさにDAが想定している、「アジャイル型」→「継続的デリバリーアジャイル型」→「継続的デリバリーリーン型」というライフサイクルの進化と一致していたため、すんなりと理解することができました。

チーム体制

DAのチーム体制とモダンオフショアの２層スクラムによるチーム体制においては、上の図のように多くの共通点があると考えています。特にモダンオフショアにおいて肝と考えているグローバルアーキテクトが、DAにおいてもアーキテクチャー・オーナーとして明確に定義されていた点には非常に共感しました。 また、DAはスクラムマスターではなくチーム・リーダーとして役割を定義していますが、われわれの募集職種としてもオフショアチームリーダー(スクラムをやるときはスクラムマスター)として募集しています。

DAの所感

ウォータースクラムフォール？

DAへの批判として、ウォータースクラムフォールではないかという指摘があり、確かにその一面もあるのではないかと私自身も感じています。

しかしながら、アジャイルな受託開発の「初期開発」においては、このアプローチは顧客が望んでいることでもあると考えており、今までも当たり前にやってきていましたし、これからもこのアプローチが求められるコンテキストにおいては、DAのアジャイル型ライフサイクルとして実践していければと考えています。

アジャイルの一般化？

2023年3月16日に発行されたDX白書2023によると、

• 受託開発ソフトウェア業のIT人材は約75万人
• アジャイルを活用している割合は22.9%

ということで、単純に掛け合わせると約17万人のIT人材がアジャイルな受託開発に取り組んでいる可能性があります。一方で、Regional Scrum Gathering TokyoやAgile Japan、Scrum Festなどのカンファレンスやコミュニティで積極的に活動している人の数は約2,000人ぐらい?と考えると、実際はかなり多くのIT人材が、消極的アジャイル実践者なのではないかと考えています。

そういった消極的アジャイル実践者の方々に、スクラムガイドやアジャイルマニフェストを見せて、「あとは自分の頭で考えながら継続的に改善していこう！」と言っても、なかなか実践するのは難しいのではないでしょうか。

すべての人が積極的にアジャイルを実践しているわけではありません。私としては、実際の現場においてはかなり多く存在していると思われる消極的アジャイル実践者には、まさにDAの規律やガイドがフィットするのではないかと考えています。

私にとってのDA

私がDAとは何かと聞かれたら、上記のように「コンテキストに合わせたプラクティスの引出しを増やせるカタログ！」と答えます。これが私なりのDAの定義の一つです。

すでに多数の引出しを持ち、コンテキストに合わせてそれら引出しを組み合わせ、継続的改善ができている実践者、チーム、コーチなどにとっては、ぶっちゃけDAを活用しなくてもまったく問題ないのではないかと思っちゃっています。

一方で、アジャイルやスクラムを学び、何度か実践し、特定のコンテキストにおいては一定の成功体験を得た実践者が、それ以降もその数少ない引出しを、あらゆるコンテキストに当てはめようとしちゃっていないでしょうか？

あらゆるコンテキストで通用するような引出し(フレームワーク、プラクティスなど)はありません。それは多くの方が承知の上だと思います。そんなときによく言われるのは、「コンテキストに合わせて自分の頭で考えよう」です。もちろん自分の頭で考えられる人もいますが、やはり多くの人にとってはそれがとても難しいため、仕方なく合うかどうか分からない引出しを当てはめ、結果的にうまくいかず、アジャイル、スクラムがうまくいかなかったと考えちゃっていないでしょうか。

この本を海外の知人に勧められて読んだのですが、冒頭に書かれているこの一節がとても印象に残っています。受託開発のプロジェクト固有のコンテキストを旅人、自分が持っているソリューションをベッドと考えたときに、手持ちのベッドを調整するのではなく、コンテキストの方を無理やり切ったり伸ばしたりしちゃっていないでしょうか。

私自身がまさにこのプロクルーステースのような非道なアプローチを数多くしてきてしまったため、自戒を込めて発表させて頂きました。

まとめ

全体のまとめは上記スライドのとおりです。

さいごに

上記した『ブラック・スワンの箴言』からの引用は、以下のように続きます。

この話にはもっと邪悪な異聞もある(偽アポロドーロスの『ギリシャ神話』なんかにも入っている)。そっちだと、プロクルーステースのベッドは大きいのと小さいのの二つがあって、彼は背の低い人を大きいほう、背の高い人を小さいほうのベッドに寝かせたことになっている。

プロクルーステースとは真逆のアプローチで、各種大きさのベッド（選択肢）を用意しておき、旅人（受託開発のプロジェクト固有のコンテキスト）に合わせたベッドを都度提供し、その結果顧客に最高な寝心地を提供する、そのようなアジャイルな受託開発を、DAを活用しながら実現していきたいと考えています。