偽アジャイルの見分け方（DIB Guide: Detecting Agile BS)

皆さんは、ウォーターフォールとアジャイルの違いを説明できるでしょうか？何となく説明できるかもしれません。ではスパイラルとアジャイルの違いは何でしょうか？アジャイルのことを単に短いサイクルを繰り返すという観点のみで考えているとスパイラル開発との違いがなかなか説明できないように思います。

そこでご紹介したいのが、以下のQiita の記事です。ウォーターフォールとアジャイルの違いをより深く理解する上で、とても勉強になります。

ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話

記事の内容としては、ウォータフォールの歴史を紐解いてわかりやすく解説しており、更にお硬いイメージのある防衛分野で、実際にウォーターフォールでうまく行かなかったという経験から、国防権限法でアジャイルを義務化し、アジャイルへ移行しているという内容を細かく解説しています。アジャイルが重要であるということを万人に理解してもらうのに非常に良い具体的な事例だと思います。アジャイル開発を今後進めていくという方や既にアジャイル開発をしている方にも、今一度アジャイルの考え方を振り返るのに非常に良い内容かと思います。

この記事の最後でDefense Innovation Board(DIB: USAの国防イノベーション委員会)が出しているDIB Guide: Detecting Agile BS という文書の紹介があります。この文書はUSAの国防という特殊な枠にとらわれずに、アジャイルに取り組もうとしている方や、既に取り組んでいてやり方を見直したいという方にとってもすごく良い文書だと思いましたので、図以外の文章の日本語訳を掲載しておこうと思います。(わかりやすくするために意訳している箇所もありますので、正式な内容は英語の文書を参照してください。）

DIB Guide: Detecting Agile BS の日本語訳

DIB ガイド: 偽アジャイルの見分け方

「アジャイル」はソフトウェア開発におけるはやり言葉(buzzword) であり、そのため、すべての国防総省のソフトウェア開発プロジェクトは、ほぼデフォルトで「アジャイル」であると宣言されています。この文書の目的は、国防総省のプログラム幹部や買収担当者に、本当にアジャイル開発を使用しているソフトウェアプロジェクトと、アジャイルを装った単なるウォーターフォールやスパイラル開発のソフトウェアプロジェクト(“agile-scrum-fall”)を見分ける方法についてガイダンスを提供することです。

原則、価値、ツール

アジャイル開発の文化やアプローチを特徴づける重要な「価値」を専門家や支持者が宣言しています。DIBはその活動の中で、真のアジャイルがおく価値とほぼ一致する以下のような独自の指針を開発しました。

プロジェクトが真のアジャイルではないことを示す重要なフラグ:

• ソフトウェア開発チームは、ソフトウェアを使う実際のユーザーと話したり、その様子を観察したりしていない(※)。ここで言うユーザーとは、実際にそのソフトウェアを使用するユーザーのことであり、PEO（Program Executive Office）やソフトウェアを実際には利用しない指揮官はユーザーに含まれない
  ※ユーザとの会話の代替となり得るもの: ユーザーが作業している様子を観察したり、プロトタイプを使ってもらいそこからフィードバックを得るなど
• ユーザーから開発チームへ継続的なフィードバック（バグレポート、ユーザー評価）ができていない。プログラムの最初に要件を確認するために一度だけ話すことは含まない
• 実際に使えるものを素早く現場に出すことよりも、要件定義書に沿うことの方が重要視されている
• 関係者(開発、テスト、運用、セキュリティ、契約者、請負者、エンドユーザーなど)は、大体の場合において相互に独立して行動している（例：「それは自分の仕事ではない」などと壁を作る）
• ソフトウェアを利用するエンドユーザが、開発中に不在(最低でもリリース計画とユーザー受け入れテストには参加してもらう必要がある）
• プロセスが自動化できる、もしくは自動化すべき状況においても、手動のプロセスが容認されており、DevSecOpsの文化が欠如している（例：自動テスト、継続的インテグレーション、継続的デリバリーなどに取り組まない）
  

アジャイル開発を行っているチームが使用している一般的なツール(なお、より良いツールが出てくれば利用されるツールは変遷する):

• Git、ClearCase、Subversion – ソースコードの変更を追跡するためのバージョン管理システム
• BitBucket、GitHub – リポジトリのホスティングサイト。また、課題追跡、継続的インテグレーション・アプリ、その他の生産性向上ツールも提供している。オープンソースコミュニティで広く利用されている。
• Jenkins、Circle CI、Travis CI – BitBucketやGitHubのソフトウェアプロジェクトの構築とテストに使用される継続的インテグレーションサービス
• Chef、Ansible、Puppet – システム構成の「レシピ」を作成し、サーバ群の構成と保守作業を合理化するソフトウェア
• Docker – オペレーティングシステムレベルの仮想化を行うコンピュータプログラムで、”コンテナ”としても知られている
• Kubernetes、Docker Swarm – コンテナオーケストレーションのためのツール
• Jira、Pivotal Tracker – 課題の報告、追跡、管理

プログラミングチームへの質問

• コードをどのようにテストしていますか？(良くない回答例: 「テスト専用の部門があります」「OT&Eがテストを担当しています」)
  • 上級編: ユニットテスト、リグレッションテスト、機能テスト、セキュリティスキャン、デプロイ承認などにどのようなツール郡を使用していますか？
• 開発、テスト、セキュリティ、デプロイのパイプラインはどのくらい自動化されていますか？
  • 上級編: 継続的インテグレーション（CI）、継続的デプロイメント（CD）、リグレッションテスト、プログラムドキュメンテーションにどのようなツール群を使用していますか？インフラはコードで定義されていますか(= IaC の実践ができていますか)？
• あなたのユーザは誰ですか？またユーザとどのように対話していますか？
  • 上級編: ユーザーから直接フィードバックを得るために、どのような仕組みを使っていますか？課題の報告と追跡にどのようなツールを使用していますか？課題をプログラミングチームにどのように割り当てていますか？課題が対処された、または解決されたことをどのようにユーザーに伝えていますか？
• ユーザーへのリリースサイクル（現在と将来）はどのくらいですか？
  • 上級編: サポートしているソフトウェアプラットフォームは何ですか？コンテナを使用していますか？構成管理ツールは何を使っていますか？
• プログラムの予算やマイルストーンを担っている組織には、何人のプログラマーが所属していますか？(良くない回答例: 「わからない」、「ゼロ」、「プログラマーの定義による」）
• 開発と運用の管理指標(メトリクス)はなんですか？その管理指標は、優先順位を決定したり問題を発見する時にどのように使われていますか？リーダーはその管理指標を、どのくらいの頻度で活用していますか？
• 過去3回のスプリントサイクルで何を学び、それに対して具体的に何をしましたか？(良くない回答例: 「スプリントサイクルとは何ですか？」「経営陣の承認を待っている状況です」）
• スプリントサイクルごとに価値を提供するユーザーは誰ですか？彼らと話すことはできますか？（良くない回答例: 「私達がコードを直接ユーザーに配布することはありません。」）

お客様・ユーザーへの質問

• 開発者とのコミュニケーションはどのように行っていますか？開発チームはあなた方の作業を観察しニーズを深く理解するための質問をしましたか？実装を望む機能について開発チームと話したのはいつですか？
• 新機能の提案やコード上の問題やバグの報告はどのように送りますか？また、要望や報告に対して開発チームからどのようなフィードバックがありますか？新機能のプロトタイプを試し、それを使っている様子を見てもらうことはありますか？
• リクエストした機能がアプリケーションに反映されるまでの時間はどのくらいですか？

プログラムリーダーへの質問

• イテレーションごと(最初のイテレーションも含む)に、実際のユーザー(少なくともユーザの一部)に実際に動作するソフトウェアを提供し、フィードバックを集めていますか？(例：2週間ごと)
• ミッションや戦略的目標に沿った製品憲章(製品の目的や意義をまとめたもの、例: インセプションデッキ など)がありますか？チームのすべてのメンバーがそれを理解し、ミッションや戦略的目標に対して、自分の仕事がどのように貢献できているかを確認できますか？
• ユーザーからのフィードバックは、スプリントチームの1ヶ月以内の具体的な作業アイテムに落とせていますか？
• ユーザーのフィードバックに基づいて要件を変更する権限がチームに与えられていますか？
• チームは学んだことに基づいてプロセスを変更する権限を与えられていますか？
• プロジェクト全体がアジャイルになっていますか？(開発段階でのみアジャイルに実施ししていても、その後に続くテストや本番へのデプロイなどが、従来どおりの直線的で官僚的な仕組みで実施していてはアジャイルとしては失敗)

アジャイルに取り組むチームは、これらの質問に対する答えはすべて “イエス “でなければなりません。

以上です。