優れたエンジニアリングプラクティスによって"常に出荷可能な製品”を実現する

優れたエンジニアリングプラクティス(Good Engineering Practice)は，アジャイルチームが出荷可能な製品を提供するためのツールだ- スクラムとアジャイルコーチのMohammad Nafees Sharif Butt氏はこのように主張する。効果を証明されたエンジニアリングプラクティスはたくさんあるが，期待されるほど広くは活用されていないのが実情である。結果として，アイスクリームコーン型ソフトウェアテストなどアジャイルのアンチパターン，技術的負債の蓄積，機能的サイロが，スプリントの終了時におけるリリース可能な製品の提供を妨げている，とNafees氏は言う。アンチパターンには，定期的な検査とシステム思考を適用することで対処することができる。

Nafees氏はSwanseaCon 2016で，リリース可能な製品のインクリメンタルな開発について講演を行なう予定だ。InfoQは氏にインタビューして，アジャイルのアンチパターンと対処方法，技術的な洗練が重要な理由，推奨されるエンジニアリングプラクティス，優れたエンジニアリングプラクティスを備えた文化を確立するために企業ができること，などについて聞いた。

InfoQ: あなた自身が企業で体験したアジャイルアンチパターンには，どのようなものがありますか？

Mohammad Nafees Sharif Butt: 技術的な観点から言えば，最も多かったアジャイルアンチパターンは次のようなものです。

a) アイスクリームコーン型テストの自動化: テストの大部分がUIを要するために，均整の取れたテストピラミッドの概念が失われているケース。この状態になったチームや企業は，受け入れテストをできる限り自動化しようと試みますが，そのようなUIテストは，その非決定論的な性質のためにエラーを返したり，実行や維持にコストを要したり，ミニ・ウォーターフォールを形成したり，チームへのフィードバックに遅延を発生させたり，将来的なUI改良に対する柔軟性を損なったりします。

b) 技術的負債の暴利は，よく見られるもうひとつのアンチパターンです。これは(今日という革新の時代においては，すべての製品開発グループが抱く)切迫感と，設計のための十分な時間がないという誤った前提に由来します。このアンチパターンのバリデーションとして，実践者がクラフトマンシップに従わず，ボーイスカウトのルールも実勢しないために，コードベースが朽ちたまま放置される状況もよく見られます。

c) 継続的インテグレーションとビルドサーバの利用が等価であるという認識: 継続的インテグレーションと継続的デリバリに関わるツール類はこの10年で成熟しましたが，継続的インテグレーションの“継続”の部分が失われつつあります。長く存在していた機能ブランチがマージ時のコンフリクトによって台無しになる，というのが，このアンチパターンの一般的な症状です。

d) 機能的サイロ: 必ずしも技術的制限ではありませんが，このような構造的障害にも重大な技術的波及効果があります。ビジネス分析と“開発”との乖離，アーキテクチャグループとN+1の設計スプリントによる大規模アーキテクチャ変更のステージゲート(stage-gate)などは，基本理念を理解しないカーゴカルト(cargo cult)としてアジャイルプラクティスを適用したことの副作用です。いずれにせよ，これらの結果は — プロセスでも製品でも — すべてが無駄なのです。

InfoQ: そのようなアンチパターンには，どのように対応できるのでしょう？

Nafees: ソリューションを見出すための，２つの攻撃ベクトルがあります — ひとつは調査と適応の重要性を常に強調すること，もうひとつはシステム思考です。今日見られる技術的プラクティスのアンチパターンのほとんどは，木を見て森を見ない企業の姿勢と，部分最適化に終始する意思決定に起因しています。学習するチームや企業に必要なのは全体論的な視野だけではありません。行動とシステムの状態との因果関係の理解も不可欠です。この調査を定期的に行ない，適切な対応を実施することで，こういったアンチパターンに対処することができます。

具体的な例が，私が２年ほど前に働いていたチームにあります。そのチームでは，開発中の新分野の製品でのスプリント毎の手作業による回帰テストを避けるために，Selenium Webブラウザオートメーションを使った受入テストを始めたところでした。シナリオの自動化には成功したのですが，いくつかのスプリントの中で，その欠点が明らかになってきました。そのためチームは，スプリントのレトロスペクティブのひとつを使って状況を分析して，自動化自体が目的なのではない，テスト自体が(実行に時間がかかるために)フィードバックを遅らせていて，余分な作業を発生させている(UIが変更されると，テストをリファクタしなくてはならない)のであれば，それは，別の手段が必要だという結論に達した，ということです。ある経験豊かな実践者が，UIに依存せずにAPIのテストを実行する皮下テスト(subcutaneous test)を導入することで，フィードバック時間の改善とUI変更時のリファクタが不要になるのではないか，と指摘して，チームに方向性を与えてくれました。レトロスペクティブではメンバからさまざまな主張があったのですが，彼らが継続的改善に注力することで全体的な改善を達成しているという自負を得られていなかったことが，結果としてこの問題への対処を可能にしたのです。

Sandro Mancuso氏はソフトウェアクラフトマンに関するQ&Aで，技術的卓越性(technical excellence)の問題について次のように説明している。

アジャイルはソフトウェアデリバリの方法を改善するために生まれました。私たちが技術的卓越性にフォーカスしないのであれば，ソフトウェアの品質は苦痛を覚えるまでに低下し，簡単には変更できなくなるでしょう。こうなってしまっては，もはやアジャイルプロセスが何であるかの問題ではありません。開発はそれ以上先に進まず，企業はアジリティを失うことになります。

InfoQ: 技術的卓越性がそれほど重要なのはなぜでしょう？

Nafees: かつてウォーターフォールの時代には，事前の設計やアーキテクチャに何ヶ月も費やす贅沢が許されていましたのですが，もはやそれは許されません。リーンによる湖や岩のメタファ，さらにはアジャイルで一般的になった頻繁なイテレーションが，非効率なプラクティスを痛切に明確化したからです。事前にスコープを固定せず，段階的な変更の提供を確約することは大事業であり，技術的な卓越性を秘めた強固な製品構築をその基盤とします。技術面での卓越性なくしては，コードベースの悪化という負担の下で，クライアントの要件を段階的に提供し続けるという約束を維持できない，ということが分かるでしょう。こうした努力は，結局は口先だけのアジャイルに行き着くだけで，真のアジャイルの兆しとはなり得ません。

クリーンアーキテクチャの概念を例にしましょう。依存性ルール(Dependency Rule)とは，アプリケーションがレイヤ化されていて，ジャストインタイムの意思決定が可能であることだけでなく，修正や拡張において自明でない作業を必要としないオープン性と柔軟性を備えていることを保証するものです(詳しくはSOLID原則のOCPを参照)。私は以前，医療保険を統合するイニシアティブで，ゲートウェイを段階的に開発するためにクリーンアーキテクチャを採用したのですが，最終的には国の医療保険データの70%を処理するまでになりました。

InfoQ: エンジニアリングプラクティスとして何を推奨しますか，また，その理由は何ですか？

Nafees: 私の最近の大規模な製品開発を中心とした経験から，中堅から大手の企業が競争上の優位に立つ上で必ずものにする必要がある，２つのプラクティスを(出発点として)お勧めしたいと思います。

ドメイン駆動設計の必要性は，いくら強調しても足りません(と言っても，何もマイクロサービスを推している訳ではなく，ドメインの定める継ぎ目を越えるものならば，簡素な製品設計でも何でも構わないのですが)。技術者の数の限られているスタートアップならば，革新的なアイデアを素早く提供することも容易いのですが，グループのサイズが何十人(あるいはそれ以上)に増えるにつれて，複数のチームによるアプリケーションのさまざまなコンポーネント間の調整や依存関係が，変化するマーケットニーズに応える企業の能力を損ない始めます。ドメイン駆動設計のコンセプトでアーキテクチャされた製品ならば，スタートアップと成功企業の間のキャズムを越えた後も，その能力を維持することができるのです。

私が経験したもうひとつの常習犯は非機能要件の軽視です(2016年のオーストラリア国勢調査をご存知でしょうか?)。私の意見として，製品が一定の負荷の下で，一定の応答時間の制約で動作する必要があるならば，それは機能仕様の一部なのであり，最初から考慮しておく必要があります。機能要件に適用されるATDD(受入テスト駆動開発)と同じ厳格さを，このような，いわゆる非機能要件にも適用しなくてはなりません。正直なところ，これらを非機能要件と呼んで２級市民として扱うことは，製品のこの面を無視する結果にしかなりません - 手遅れになるまで無視され続けるのです。

以前にInfoQでは，TDDと“コードの臭い”についてJames Grenning氏にインタビューして，技術的卓越性の向上を目的とした技術的プラクティス適用のために何ができるのかを尋ねたことがある。

失敗の一因は，単独作業と専門化の文化にあると思います。自分のコードだけを見ていると，それで問題ない，新たに学ぶものは何もない，という考えを持つようになります。開発サイクル後半のコードレビューでは，改善は非常に難しくなります。お互いがより緊密に協力するように奨励することが必要です。ペアプログラミングは技術的卓越性を広める方法として，双方向であるという点でも，非常に優れた手法です。

InfoQ: 優れたエンジニアリングプラクティスを備えた文化を確立するために，企業としては何ができるでしょう？

Nafees: 将来を見据えた採用ですね。新たな才能はいつでも，既存の均衡状態に波風を立てます。エンジニアリングプラクティスに関わる企業文化が未熟な状態であれば，既存の文化に合った人材よりも，成熟を目標とした採用をするべきだと思います。この方法で，現状に前向きな影響を与える成熟の触媒として，新たな才能を使うことができます。

もう一つ重要なのが，外部の支援を得ることです。ほとんどの企業において，現在のアーキテクトは過去10年間プログラマだった人材です。そのランクを強く希望する者がいたとしても，既存の階層構造においてこの技術分野に習熟することは，非常に難しくなっています。外部の支援を得ることは，それが既存の官僚主義に対抗するものであったとしても，組織の現在の状態を映し出す契機になります。

最後に，エンジニアが解決すべき問題を与えられず，代わりにソリューションの実装を依頼されている場合には，反復型開発が終わりのない悪循環のように思われるかも知れません。作業者に権限を与えて自己組織化(自己流であっても)し，背景にある目標を与えることで，当事者意識が向上し，結果として作業者の積極性が得られます。従来型のマネジメントが認める以上に，作業者はチャレンジを求めています。自律性と目標提示をうまく組み合わせることで，彼らは積極的にすべてのエネルギーを提供してくれるでしょう。

SwanseaCon 2016は英国のLiberty Stadiumで9月12日と13日に開催される。2016年版は第２回のアジャイル開発およびソフトウェアクラフトマンシップの会議として，サウスウェールズ州のソフトウェア開発者，ソフトウェアアーキテクト，プロジェクトマネージャ，コンサルタントらが集う予定だ。カンファレンスの様子はInfoQでもQ&Aや要約，アーティクルを通じて伝えて行く予定だ。