英国のコーンウォールで開催された第５回‘Agile on the Beach’カンファレンスでは，アジャイルソフトウェアデリバリの著名な実践家たちが，この分野における最先端の新たなトレンドをテーマとしたプレゼンテーションを行った。そこで語られた主なメッセージは，ソフトウェアデリバリのライフサイクル全体を通じた科学的手法と‘仮説駆動設計(hypothesis-driven design)’のより厳密な適用の必要性，製品開発プロセスに対するアジャイルの原則と継続的改善実施の必要性，急激に変化するエコシステムの中でのソフトウェア開発の方法論および原則の選択における，情報に基づく意思決定によるメリット，といったものだ。
カンファレンスの初日は，‘Continuous Delivery’の共著者であるDave Farley氏による，価値あるソフトウェアの継続的デリバリに関して，特に人間観察力と意思決定と直感の減退に注目した基調講演で始まった。その中で氏は，“Farleyの３原則”を紹介した。簡単に言えば，(1)人には欠陥がある，(2)スタッフはあなたが思うより有能だ，(3)すべてのスタッフは興味深い(あなたの見方が正しければ)，というものだ。
Farley氏は講演で，目の錯覚を防ぐことによる人の意思決定特有の弱点や欠点の見事な例，頭を使うパズル，ソフトウェアデリバリライフサイクルにおける我々の意思決定ヒューリスティックがいかに誤った選択に導くかを実証したケーススタディなどを示してみせた。講演で氏が強く訴えたのは，ソフトウェアの設計と提供において厳密な実験を行うことの必要性である。Richard Feynman氏を引き合いに出しながら，氏は，実験的証拠なしにソフトウェア設計上の決定を行えば，いとも簡単に思い違いをしてしまうことを示唆した。
インテリジェンスの程度が問題なのではありません。何かを推測して，その推測に実験的証拠がなければ，それは推測に過ぎないのです。
Farley氏の第２法則の解説では，浮動小数点演算エラーを抱えて出荷されたPentium CPUチップ，打ち上げ40秒後に爆発したAriane 5宇宙計画，Knight Capitalの4億4千万ドルの損失など，コンピュータプロジェクトの失敗例がいくつか紹介された。知り得る情報が最小限である場合に，氏が強く推奨するのは，アジャイルプラクティスの利用，厳密な科学的実証，継続的デリバリによるフィードバックサイクル時間の最小化と，製品のライフサイクルに存在する複雑性の顕在化だ。
基調講演の後は，５つのトラックによる分科会セッションが行われた。InfoQはまず‘Product’トラックに出席し，Melissa Perri氏による‘Continuous Product Improvement’の講演を聞くことにした。Perri氏の講演は，継続的インテグレーションや継続的デリバリといった技術的プラクティスが広く普及したにも関わらず，継続的製品開発がいまだ主流になっていないのはなぜなのか，という疑問から始まった。継続的な製品開発を行わなければ，いとも簡単に誤ったものが出来上がってしまう，というのが氏の主張だ。
不要な機能がどの程度作られるのか，という問題ではありません。すべてが不要なのです ...
Toyota Kata(カタ)の‘継続的改善の４ステップ’を紹介した後，Perri氏は，プロダクトマネージャとプロダクトオーナがビジネスの上で技術チームのリードに従うこと，製品設計でアジャイル方法論を実践すること，この２つを強く推奨した。一般的に採用されている，機能リストを作成し維持するというアプローチは，実は適切ではないのかも知れない。ほとんどのユーザは，形になった製品を見るか，あるいはMVP(Minimum Viable Product)でない限り，自分たちの望むものや必要とするものを認識できないからだ(そしてその時になって，それが望んだものではないと気付くのだ)。Perri氏は，継続的改善 ‘Product Kata’を使用することにより，よりよい製品を科学的かつ体系的に構築することが可能になる，と提案する。
Product Kataの実践に関しては，詳細なケーススタディが紹介された。その中でPerri氏は，実装チームによる受諾(buy-in)を得る必要があること，実験の設計が容易ではないこと，成功基準の確立(あるいは評価)が困難である場合が少なくないことなどを警告した。Product Kata製品開発アプローチに関するその他の詳細情報やガイダンスは，氏の‘Product & UX’ブログにも紹介されている。
Always Agile Consultingに籍を置くアジャイルコンサルタントのSteve Smith氏は，‘Continuous Development’ カンファレンストラックの次のスロットで，‘The Death of Continuous Integration’と題したプレゼンテーションを行った。ソフトウェアの継続的デリバリというアプローチに対する人気の興隆が，継続的インテグレーションに依る部分が大きいというのは，多くの人の同意するところだ。しかしながら多くのチームが，リリース機能別のブランチなどの開発プラクティスを採用することで継続的インテグレーションの実施を困難にしている，と氏は指摘する。さらに氏は，ローカル開発のメトリック(ベロシティなど)を追跡することで，グローバルな共有コードベースによる開発が無意味であることと解釈されれば，それが負のインセンティブになるのではないか，とも述べている。
[共有コードベースで]チームのベロシティを計測するのは無意味です。システムレベルでの進捗を追跡する，グローバルなメトリックが必要です。
Smith氏の講演は，継続的インテグレーション(CI)はJenkinsを使ったCIビルドサーバを単に実行してコードベースを統合し，テストを毎日1回実行することで実現できるものではない，という話題で始まった。CIとはそうではなく，理念であり哲学なのだ。開発者は，自身のコードをマスタあるいはトランクのブランチに継続的に統合し，ビルドパイプラインに棄損があればすかさず修正する。さらには，実行時間を要するテストといった，インテグレーションへのフィードバックを即時に受け取る能力そのものに影響を与えそうな問題に対処すべく，注意を払うのだ。
講演ではリリース機能別ブランチやトランクベース開発，ビルド機能別ブランチといった，コード統合に対する一連のアプローチが公開され，それぞれが評価された。Smith氏は，トランクベース開発がCIのアプローチとしては最も効率のよい(機能によるブランチの使用では任意となるような，有益なプラクティスを必須にすることもできる)場合が多いものの，現実には高度なスキルと規律を必要とするため，実践は簡単ではないと述べている。ビルド機能別ブランチは，作業する上では好都合なことが多いが，このプラクティスを(実際にはどのプラクティスでも)採用するには，情報に基づいた意思決定が必須になる。そして最後に氏は，Jenkinsの利用が‘CIの実践’と認識されるという最初の説明に戻って，ツールはプラクティスに従うべきであって，それ以外の意味はない，と警告した。
おいしい食事に加えて，講演者や参加者仲間との議論の機会がたくさん提供された昼食の後は，ThoughtworksのプリンシパルコンサルタントであるJames Lewis氏による“Building systems that are #neverdone”という講演が，‘Craftsmanship’トラックで開催された。故Terry Pratchett氏の“The Fifth Elephant”という物語の中の“my families axe”の引用から始まったLewis氏の講演では，いくつかのハイパフォーマンス企業が，明確に定義されたコンテキスト境界(bounded context)とAPIを持ったモジュラ(マイクロサービス)アプローチを採用して，ソフトウェアを提供していることが紹介された。柄や刃を何度も直したり，取り換えたりした物語の斧(axe)と同じように，これらソフトウェアシステムもそのライフタイムを通じて，関連するビジネスの成長や変更に伴ってサブシステムの改良や置き換えを行うという発想で考えられているというのだ。
氏の講演の根幹をなす前提は，多くの企業が将来を恐ろしく，予測不能で，突然の混乱に見舞われるものだと考えていることだ。そのような状況下でのソフトウェアシステムは，企業にとって‘可能な限り早く’運用できるように設計されていなくてはならない。そこでは安価に置き換えられる，短期間でスケールアップできる，障害に耐えることができるといった特性が不可欠なものとなる。Lewis氏は“DRY(don’t repeat yourself)”のような古い格言は，新たな開発スタイルの下で見直すべきだと主張する。マイクロサービスアーキテクチャを実装することによって，コンテキスト境界間で自身の作業を繰り返すというのは，完全に受け入れる行為になる。ただしコンテキストの中においては，同じ作業を繰り返さないような注意も必要だ。ソフトウェア開発におけるジャストインタイムの中心をなす原則も，コードのレベルからアーキテクチャ設計のレベルに‘格上げ’されることになるだろう。
YAGNI[“you ain’t gonna need it / そんなものはいらない”]はコード設計から飛び出して，システムアーキテクチャのレベルに達することでしょう。
最後にLewis氏は，開発者は今こそ‘わが家の斧(my families axe)を作る’，すなわち，モジュール化された置換可能なシステムを構築し，小規模で独立した(マイクロ)サービスをデプロイして，単独でサービスをテストすることを学ばなくてはならない，と提案した。マイクロサービスベースのシステムは，その複雑性と新規な動作のため，運用環境でテストするのがベストである。そのために継続的インテグレーション環境は，滅びゆく恐竜の道をたどるかも知れない。Lewis氏の講演の詳細は，‘Agile on the Beach’ Webサイトにある，Tony Edward氏によるセッションのライブブログで見ることができる。
ThoughtworksのStefan Smith氏は，'Continuous Development’トラックの午後の部で，“Escape the integration syrup with contract tests”と題したプレゼンテーションを行った。モジュラーシステム(部分を独立的に，分離して改良可能な)の開発で，サブシステムを統合する時には注意が必要だ，とSmith氏は言う。開発者(およびビジネス)の生産性維持のためには，アンチパターンとしての‘リリーストレイン’，あるいは‘ゴム印(rubber stamp)’承認によるステージゲート型のコラボレーション方法を回避しなくてはならない。
任意の２システムが通信する時，その間には，暗黙的であれ，何らかの契約(contract)が常に存在する。コンシューマ駆動型コントラクトを用いるなどの方法で契約を明示的にすることにより，通信を行うコンポーネント同士で契約の遵守を検証することが可能になる。非互換的な変更が必要な場合は，開発者チーム内での検討が実施される。契約の実施範囲に関する選択肢を検討するために，一連のケーススタディが提示された。外部コンポーネントを担当する開発チームに対して実行可能なスタブと契約テストを提供することによって，ビルドパイプライン内で契約テストを実行したり，あるいはコンポーネントの新バージョンがリリースされるテスト環境全般で契約テストを実行するなどの方法だ。
ソフトウェア開発のほぼすべてがそうであるように，契約テストによって‘フリーランチ’が入手できる訳ではない。特にこのアプローチを実施するための学習曲線やテスト検証のための‘ゴールデンデータ’を確立することの困難さ，契約を共有するためのインフラストラクチャ構築という課題などが存在する，とSmith氏は警告している。
‘Craftsman’トラックの当日最後の講演は，UnrulyのBenji Webber，Alex Wilson両氏による，ソフトウェアベースの製品を‘Unruly mob’によって開発する方法についての論議だった。Wilson氏の，Unrulyでの作業に従事する開発者の大半が‘Pro Dev Ops’である，という話題から講演は始まった。これは必ずしもDevOps思想に関連したものではなく，開発者が製品，開発(品質保証を含む)，そして運用を担当するという意味だ。従ってUnrulyチームにはハンドオフというものはなく，開発者がソフトウェアシステムの運用操作にも責任を持つことになる。これによってチーム全体が責任と義務を共有することになる，とWilson氏は説明している。
Webber氏は，Unrulyが最近‘モブ(mob)プログラミング’の概念を導入したことを発表した。モブプログラミングはペアプログラミングを発展させたもので，ひとりの開発者が一台のコンピュータで開発を‘ドライブ’して，3人から8人の開発者グループ(モブ)がその‘ナビゲータ’の役割をする，というものだ。モブプログラミングのドライバは，ソリューション実装とコード開発の中間の役割を担う。一方のモブは，設計，議論，コード評価，アーキテクチャの記述に責任を負う。モブプログラミングの利用を通じて，作業を実施するために必要な時間を見積もる上での‘理想的な’一日が，現実として実践されるのを目の当たりにした，とWebber氏は述べている。
私にとって理想的な[見積]日の実現に最も近い体験は，モブプログラミングを通じてのものです。
Unrulyのすべてのソフトウェア開発がこの方法で行われてる訳ではないが，最初に‘モブの金曜日’による‘週１日’実験を実施して以来，この方法論が，非開発チームを含む会社全体に口コミで拡がっている，とWilson, Webber両氏は述べている。継続的コーチングやレトロスペクティブの実施といった優れたアジャイルプラクティスには，すべての人たちがそのアプローチに貢献し，ハッピーであるという確証が必要である。Unrulyのチームはたまに外部の団体を会社に招いて方法論の教義を仰いだり，モブ初心者の疑問を通じて不必要なプラクティスを明確化する，という作業を行っている。
Urulyのモブプログラミングプラクティスに関しては，XP2015カンファレンスで行われたプレゼンテーション“Mob Programming: What works, what doesn’t”の記録や，Wilson氏による関連資料に詳しい。今回のセッションについては，Tony Edwars氏によるAgile on the BeachカンファレンスWebサイトのライブブログでも取り上げている。
‘Agile on the Beach’の初日は，アジャイルソフトウェア開発のさまざまなトピックを取り上げた，参加メンバによる有益で面白く，刺激的な一連のライトニングトークで幕を閉じた。夜にはすべての参加者を招待した‘party on the beach’が開かれて，代表者や講演者を交えたアジャイルに関する議論が早朝まで続けられた。
‘Agile on the Beach’に関する詳細な情報は，カンファレンスのWebサイトや，Twitterのハッシュタグ‘agileotb’でフォローすることができる。