- 講演資料：アジャイルを「ふりかえる」
アジャイル開発そのものについて振り返りを行う「#RetroOnAgile」
オーストラリアのシドニーに本社を置くAtlassian社は、アジャイル開発を支援するための各種ツール製品を開発・提供するソフトウェアベンダー。特に同社のアジャイル開発管理ツール「Jira Software」は広く知られた製品で、世界中の多くのアジャイル開発者に利用されている。
そんな同社は2018年以来、「#RetroOnAgile」と銘打ったユニークなキャンペーン活動を展開している。アジャイル開発では、定期的にチームメンバー全員が集まって過去のチーム活動を評価する「振り返り（Retrospectives）」を行う。Atlassianでは、自社製品の今後の開発方針を検討するに当たり、「アジャイル開発を扱う製品なのだから、アジャイルそのものに関する振り返りを行って、その結果を製品に反映すべきだ」との結論に至った。そこで、世界中の英語圏のアジャイル開発者を対象に、アジャイル開発そのものの振り返りを行う#RetroOnAgileのキャンペーンを展開している。
Wong氏によれば、このキャンペーンではさまざまな意見が集まったが、中でも3つの問題領域において多くの声が寄せられたという。
「『アジャイルの意味が歪んできた』『継続的な向上のために何をすればいいのか』『チームの健康状態に課題を抱えている』という3つの問題領域において、多くの声が寄せられました。そこでまずはこの3つうち、最初の2つの課題の解決策を探るために、アジャイルソフトウェア開発宣言に記されている『4つの価値』にいったん立ち戻って考えてみたいと思います」（Wong氏）
アジャイルソフトウェア開発宣言の「4つの価値」に立ち戻る
アジャイルソフトウェア開発宣言に記された4つの価値のうちの1つに、「計画に従うことより変化への対応に価値を置く」というものがある。アジャイル開発がうまくいかないプロジェクトの中には、この文言を「計画はそもそも無価値で不要である」と勝手に拡大解釈し、無秩序な開発を行ってしまうケースが散見されるという。これはまさに「アジャイルの意味が歪んできた」典型例の1つであり、本来のアジャイル開発の価値を曲解している。
また「包括的なドキュメントより動くソフトウェアに価値を置く」「プロセスやツールより個人や対話に価値を置く」という価値に関しても、歪んだ解釈が多く見られるとWong氏は指摘する。
「よく、アジャイルとスクラム開発を同一視して、スクラムのプロセスに従えば必ずアジャイルが実現できると考える人がいます。しかしスクラムは、あくまでもアジャイルの精神を具現化するためのプロセスの1つに過ぎません。アジャイルそのものはプロセスではなく、『アジャイル（agile：俊敏）になる』という行動様式のことを指しています。つまりアジャイルのプロセスを実行するのではなく、自らがアジャイルになることを目指すべきなのです」（Wong氏）
しかし実際には、多くの開発現場においてプロセス偏重の傾向が見られる。その背景には、「アジャイル vs. ウォーターフォール」という「プロセスの二項対立」の文脈でアジャイルをとらえる人が多い事情がある。しかし開発プロセスには本来「善と悪」は存在せず、適材適所で最適なものを選択して適用すればいい。決して「アジャイル以外のプロセスは悪」だととらえるべきではないとWong氏は指摘する。
「例えば、既に手順が決まり切っている簡単な問題を扱うのであれば、昔ながらのウォーターフォール手法が最も効率がいいでしょう。逆に問題領域が複雑で、しかも周囲を取り巻く環境が刻一刻と変化するような課題を扱うような場合にはアジャイルが適しています。また、どっちとも判断できないような場合には、必要に応じてアジャイルとウォーターフォールを使い分ければいいでしょう。あるいは、複雑を通り越してもはや『カオス状態』になってしまった問題領域を取り扱う場合には、Kanbanのようなプロセスを適用するのがいいでしょう」（Wong氏）
顧客とのハッカソンで交渉より“協調”に価値を置く
さらに4つめの価値として、アジャイルソフトウェア開発宣言では「契約交渉より顧客との協調に価値を置く」が挙げられているが、これに関しても従来のソフトウェア開発のビジネスモデルでは「開発側と顧客側のどちらがリスクを負うか」「どちらが多く利益を得るか」といった観点から契約交渉が行われることが多く、このことがアジャイルの本来の価値を損ねてきた。そこでWong氏は、「細かな条件を契約で取り決める代わりに、開発側と顧客側の双方に共通のインセンティブを設けることで両者が協調し、アジャイル的な働き方ができるはずだ」と提言する。
なおAtlassianでは、Atlassian Market Placeにアプリを登録しているサードパーティと合同でハッカソンを行ったこともあるという。例えば、とあるクラウド移行プロジェクトでは、事前にAtlassianと企業のプロジェクトメンバーが一堂に会して、いくつかのチームに分かれてクラウド移行のシナリオを競い合うハッカソンを1週間にわたって開催した。
「ハッカソンはやるのは簡単ですが、きちんと結果を出すのは難しいものです。そこで今回は、1週間のハッカソンを行う前に、参加者全員に『ハッカソンの目的やゴール』についてアンケートフォームに記入してもらい、参加者全員がハッカソンの目的やゴールをきちんと共有できるよう工夫しました。また、社内のさまざまな関連部署の協力を仰いだほか、ハッカソン終了後には参加者全員が参加して振り返りを実施しました」（Wong氏）
こうした取り組みを行った結果、このプロジェクトでは先に挙げたアジャイルの原理の1つである「契約交渉より顧客との協調に価値を置く」を実践できたという。
プロダクトではなく「サービス」を開発することの意味
以上のように、アジャイルの原点であるアジャイルソフトウェア開発宣言のビジョンに立ち戻り、ここに記された4つの価値それぞれの意味を問い直すことによって、「アジャイルの意味が歪んできた」「継続的な向上のために何をすればいいのか」という課題を解決する糸口が見つかるのではないかとWong氏は述べる。
一方で、冒頭で挙げたもう1つの課題点「チームの健康状態に課題を抱えている」については、これらとは異なるアプローチが必要だという。
「不健康なチームは、不健康なソフトウェアしか開発できません。従って健全なプロダクトを開発するには、チームの健康状態を定期的に振り返ってチェックする必要があります。具体的には、チームメンバー全員で定期的に集まって、『チームのバランス』『共通理解』『価値と指標』といったいくつかのチェック項目ごとに『緑（健康）』『黄色（やや不健康）』『赤（不健康）』で採点し、チームの健康状態をセルフチェックします。アトラシアンでは、健康状態をチェックする方法と、その際にConfluenceで利用することができるテンプレートをセットで提供しています」（Wong氏）
加えて、近年ますます進展する「ソフトウェアのサービス化」のトレンドも、アジャイルの真の価値を見直す上でいい契機になるのではないかと同氏は提言する。「アジャイル（agile：俊敏）」というネーミングから、アジャイル開発ではとにかくスピードや効率を重視する傾向があるが、ソフトウェアをサービスとしてとらえた場合は、スピードと同時に「ユーザーに提供する価値」を常に意識する必要がある。
Wong氏はこうした考え方を、「Stay lean, stay loveable, be agile」と表現する。「無駄なく（lean）、俊敏（agile）に開発すると同時に、人々に愛されなくてはなりません（loveable）。そのためには、日本の『おもてなし精神』はとても参考になるかもしれません」（Wong氏）
こうした境地に至るためには、まずはアジャイル手法の適用から出発して、次に品質の高いソフトウェアを継続的にリリースできるプロセスを確立し、最終的に成果物の価値が上がるようプロセスを反復する必要がある。そのためにWong氏は、「結果より成果に価値を置く」べきだと提唱する。
「私は個人的にこれを、先に挙げたアジャイルソフトウェア開発宣言の4つの価値に並ぶ『5つめの価値』として提唱したいと思います。その実現のために最も大事なのは、開発の過程を社内だけでなく社外にも公開する『オープン性』です。Atlassianもこうした考えにのっとり、オープンな企業文化と価値観のもと、今後もアジャイルの発展に貢献していきたいと考えています」（Wong氏）
お問い合わせ
アトラシアン株式会社
