アジャイルをオフショア開発に拡張する

ソフトウェア開発のオフショアとアジャイルを両立するためには，想定されていない環境下でアジャイルプラクティスを機能させるための時間を投資する必要がある。決して諦めてはならない，とXavier Rene-Corail氏とIonuț Baloșin氏は言う – 原則に立ち返ることでアジャイルプラクティスを拡張(stretch)し，分散環境で効果的に機能するようにスケールアップする方法を共同で見つけることが必要なのだ。

Mutexでソフトウェアエンジニアリングリーダとアジャイルカタリストを務めるXavier Rene-Corail氏と，Luxoftのソフトウェアアーキテクトで認定スクラムマスタのIonuț Baloșin氏は，XP Days Benelux 2016でこのアジャイルの拡張について講演した。同カンファレンスに関しては今後，Q&Aや要約，記事を通じてInfoQでお伝えしていく。

InfoQは両氏から，アジャイルを採用した理由と分散環境においてアジャイルプラクティスを適用した方法について聞き，そのような環境でアジャイルプラクティスの実施が困難になる理由は何か，そこで諦めずにプラクティスを拡張するにはどうすればよいのかを尋ねるとともに，異なる文化を持つ企業間で共同作業をする上でのアドバイスを求めた。

InfoQ: アジャイルの採用を決めた理由は何でしたか？

Ionut Balosin: 何年か前，私はいくつかのウォーターフォール/ミニ・ウォーターフォールのプロジェクトに関わっていました。当時はこのようなアプローチを行なっていたために，プロセスの非常に遅い段階，ほとんどの場合は開発の大部分が終了した後になって提供される，ステークホルダ(特にユーザ)からのフィードバックに対処しなくてはなりませんでした。製品のリリースも非常に遅く，頻度も低かったのです。何かを変えなくてはならないという結論に達した私たちは，より迅速かつ適切な対応をするために，アジリティと実用主義を目指すことにしました。

Xavier Rene-Corail: 私が初めてソフトウェアクラフトマンシップを知ったのは，“The pragmatic programmer” (Hunt & Thomas)という本を見つけた時です。クリーンなコードの記述やテストに関して，当時疑問に思っていたことの答がすべてそこにありました。そこで著者の推奨に従って，アジャイルマニフェストを読んだのです。私が当時直面していた状況を考えると，そこに書かれていた原則は良識だと思えました。当時の私は，速いペースで変化する世界の中で，極めて長い開発サイクルで作業していたのです。それ以来，同じような状況に直面するたびに，アジャイルプラクティスこそが進むべき道であると考えています。

InfoQ: 分散環境にアジャイルプラクティスを適用する方法について，実例はありますか？

Rene-Corail: Murexでは，製品部門がすでに分散しています(パリ，ダブリン，ベイルート)。当社では，ビデオ会議で毎日のスタンドアップを必ず実施しています。また，物理的ではなく仮想ボードを使ったレトロスペクティブや，リモートでのペアプログラミングを行なっています。分散チームでは，ほとんどのアジャイルプラクティスが問題を抱えることになるので，まず最初に同じ疑問に到達します – “プラクティスを放棄するべきか，あるいは効果的にするための投資をすべきだろうか？”そこで例えば，“ベイルートの開発者なしでスタンドアップを実施できないか？”，あるいは“ひとりのためだけにビデオ会議を行なうのはやり過ぎではないか？”といった選択が持ち上がります。スクラムマスタであるあなたは，プラクティスの価値を説明して，それらに時間を投資する価値があることを確かめるために，チームに試してもらうように説得しなくてはなりません。

Balosin: 私たちの組織編成も，柔軟性を示すよい例だと思います。私たちはチームに分かれていますが，現行のチーム能力に適合しないプロジェクトを管理しなくてはならない場合には，他のチームの支援を簡単に求めることができるのです。この方法でチーム間のサイロを破壊し，水平方向の連携を強化しています。

InfoQ: 困難を経験することによって，アジャイルプラクティスを諦める場合があります。そのような例はありますか？

Rene-Corail: そうですね，簡単な例としては，“国が違うので，ペアプログラミングはできない”というのがあります。古典的な例では，“レトロスペクティブの参加者が多過ぎる ... このレトロスペクティブはキャンセルしよう”といったものや，“毎日のスタンドアップの参加者が多過ぎる，時間がかかり過ぎるし，全員にすべての情報が必要な訳ではない”といった，スケールアップ時に直面する問題があるでしょう。

Balosin: 私たちも，ある人がアジャイルを使った作業や関連するプラクティスの実施を好まないために，別のプロジェクトに切り換える決定をした，という状況に直面したことがあります。孤立したケースでしたので，それ程落胆はしませんでしたし，逆に欠点を解決してプロセスをより効率的に運用することで，私たちのアジャイルプラクティスを継続的に改善していこうと決めることになりました。

チームのスケーラビリティに関しても，多くの対処をしなくてはなりませんでした。これに関しては，参加者の数や実施数の面でミーティングを再編成しました。最終的にはスクラムのスクラム，レトロスペクティブのレトロスペクティブ (つまり，各チームが内部のミーティングを実施した後に，別のレトロスペクティブを実施して分散チームすべてのレトロスペクティブを収集し，最初の結果を拡張した)，フォローアップミーティングなどを行なうことで落ち着いたのです。

InfoQ: 講演では困難なプラクティスを外す代わりに拡張することにした，という話題がありましたが，なぜそのようなアプローチを取ったのでしょう？

Balosin: 2008年に起きた金融危機は，ソフトウェア開発市場に大きな影響を与えました。経済的，政治的，技術的な制約を考慮した時，私たちのプラクティスより強く，よりスケーラブルにする必要がありました。選択肢や手段の数は限られていたのです。私たちの技術的な専門知識を向上させ，より柔軟で予測可能性の高い開発パイプラインを提供して技術的イノベーションの余地を生み出すためには，分散型コラボレーションをサポートする方法が必要でした。

Rene-Corail: 私たちは急速に変化するビジネスの中にいます – Murexは金融市場向けのソフトウェアを開発していますが，サブプライム危機以降，このビジネスは急激な変化を遂げました。意欲的な期限が設定された新たな規制がますます増えて，技術的な課題も新たに生まれています。このような条件の下で，ウォーターフォールに戻るようなことは許されませんでした。ですから，分散チームやオフショアといった，本来ならば機能しないような条件下でアジャイルプラクティスを実施することが，唯一可能な選択肢だったのです。

InfoQ: アジャイルプラクティスの拡張は，あなたにとってどのような結果をもたらしたのでしょう？そこから何を学びましたか？

Rene-Corail: 分かったのは，それが非常に高価だということです – 採用したプラクティス(管理の可視化，テスト自動化フレームワークの拡張など)をサポート可能なようにカスタマイズされたツールを提供するため，3人の開発者からなる専門チームを設けました。ミーティングも，当初のSCRUMのものより多く行わなければなりませんでした。そのような困難な条件の下でしたが，しかしながら，コラボレーションがいかに有効かを学ぶことができました。ですが，何よりも重要な教訓は，それが可能だということです！プラクティスを支える原則を本当に理解していれば，それを再構築し，拡張することで，目標は達成できます。例えば，私たちはBDD(ビヘイビア駆動開発)を使用しました。BDDでは，開発者がストーリの実装前にPOが提供した受け入れテストを使うことで，テストを自動化することができるのですが，開発者とPOに距離のあるオフショア環境では，これはうまく行きませんでした – 自動受け入れテストはPOの希望を100%反映している訳ではないので，テスト結果がOKとなっても，ビジネス要件が満たされていなかったのです。つまり，このプラクティスの背景にある重要な原則は，POと開発者が共同でユーザストーリを記述することであって，自動化ではないということが分かったのです。POと開発者が離れていたため，このコラボレーションができていませんでした。そこで私たちはこのプラクティスを，POが自動化テストを直接記述できるようにして，POと開発者が同じ対象で作業のイテレーションを実施可能なように適用しました。この結果，ビジネス要件に対する理解を共有するとともに，シナリオから自動テストに落とし込む際に要件が失われることもなくなりました。もうひとつの例は，視覚的な管理プラクティスの改善です – 旧式のダッシュボードでは，効果的な情報を得ることはできまかったため，しばらくすると誰も見なくなってしまいました。そこで私たちは，Toyota Production Systemの基本である“あんどん”の原則に立ち返って，独自のダッシュボードを再設計しました。生産ラインを止めて問題を解決しなければならない場合(にのみ)，赤色のアラームが明確に示されるようにしたのです。

Balosin: 異なる文化を持つチームによる分散型開発のような要因がある場合，アジャイルを拡張するのは簡単なことではありません。意識と自己責任を作り上げる方法の基本はコミュニケーションである，というのが私の意見です。その他のアドバイスとしては，作業上の合意を確固たるものにしておくこと，関係グループの確立とレビューを行なうこと，強制や押し付けではなく，全員がメリットを理解すること，などです。

InfoQ: 異なる文化を持った企業間の共同作業をする上で，何かアドバイスはありますか？

Balosin: 最初に言いたいのは，文化や他の人たちの振る舞い，反応，話を理解することが基本だということです。第２に，顔を合わせてのミーティングやサイト間の訪問を頻繁に行なうことが大切です。お互いを知ることによって，より協調的な方法で仕事ができるようになるのです。人間とはそういうものです。タイムゾーンや文化的な類似性は，また違う課題をもたらすかも知れませんが，最初の２つが克服できていれば対処することは可能です。

Rene-Corail: ダンスのカップルに例えて説明しましょう。まず，あなたが練習しなければなりません。お互いを知らないのですから，最初のうちはお互いの足を踏むことも受け入れる必要があります。練習の対象として相手を考え，受け入れるのです。第２には，同期することに集中する必要があります。状況をリアルタイムに，同じように理解するのです。ここでは視覚的な管理が重要になります。最後に，相手にインプロビゼーションの余裕を与えることが必要です。チーム(あるいは企業)のどちらかがすべてを課された場合，コラボレーションはもう一方の創造性からメリットを得ることができません。しかしリーダがパートナに十分なインプロビゼーションの余地を提供すれば，一緒になって新たなダンスステップを考案して，素晴らしいショーにすることができるはずです。