アジャイル開発の誤解とは（後編）
クラウドネイティブNow

はじめに

私は1998年に現在の会社に入社してから、ソフトウェア製品の開発に長年携わってきました。最近ではアジャイル開発に取り組むプロジェクトに関わることも多くなりましたが、アジャイル開発はその特徴から多くの誤解があり、アジャイル開発に失敗するプロジェクトも多く見てきました。
本特集では、まずはアジャイル開発が登場する背景として従来のソフトウェア開発の実態を説明し、アジャイル開発で陥りやすい誤解について解説します。前編では、アジャイル開発の誕生に至る経緯からアジャイルソフトウェア開発宣言に記された4つの中核となる価値について解説しました。後編ではアジャイルソフトウェア開発宣言の背後にある「12の原則」とアジャイル開発の本質およびアジャイル開発と技術について解説します。

12の原則（12 principles）

前編でご紹介したアジャイルソフトウェア開発宣言の背後にある「12の原則」は、『アジャイル宣言の背後にある原則』に以下のように記載されています。

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2週間～3週間から2ヶ月～3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャー・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

【参考】

• アジャイル宣言の背後にある原則（Manifesto for Agile Software Developmentのウェブサイトへ）

4つの価値が理解できれば、12の原則のほとんどは理解できると思いますが、4つ目の「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」の原則はいかがでしょうか？
従来の開発では、開発者がビジネスのことを理解することは難しく、逆にビジネス側の人がシステム開発のことを理解するのは難しいため、開発を行うSEと顧客の間には営業やアカウントSEと呼ばれる顧客担当のSEが仲介となり、意思疎通を行うのが一般的でした。ビジネス側の要件はシステム開発の要件にかみ砕き開発者に伝え、逆に開発者からの報告はビジネス視点の言い方に変換してビジネス側の人に伝えるのです。しかし、この言い換えは非常に煩わしい作業になるため、なるべくビジネス側の人と開発者のコミュニケーションが発生しないように分業するのが一般的でした。

しかし、このようなやり方は顧客ニーズの変化に柔軟に対応できないため、アジャイル開発の原則ではビジネス側の人と開発者は一緒に働きコミュニケーションを取ることを原則としているのです。

アジャイル開発の本質

ここまで説明してきたように、アジャイル開発に対しては非常に多くの誤解があることがお分かりいただけたでしょうか？「アジャイル」という言葉に抱く開発スピードが速まる・開発生産性が高まるというイメージにも誤解があると感じていただけたのではないでしょうか？

2001年の会議に参加した一人であるマーティン・ファウラー（Martin Fowler）氏は、自身のブログで2019年に公開した『Agile Software Guide』のページで、「However, like any popular technique, agile software development has suffered from semantic diffusion, so much of what we see under the name of agile doesn't bear much resemblance to what the early pioneers were doing.」と記載し、現在議論されているアジャイルの大半は2001年当初のパイオニア達が思い描いたものとはかけ離れたものとなっていると述べています。
このブログの中で、アジャイルの本質を、従来の計画主導型ソフトウェアと対比して以下の2つに基づいていると改めて定義しています。

1. 予測的ではなく、適用的／is adaptive rather than predictive
2. プロセス指向ではなく、人指向／is people-oriented rather than process-oriented

以下の表では、Martin Fowler氏の2つの本質、4つの価値、12の原則の対応表を示します。これらの対応関係は私がまとめたものであり、別の側面から見ると異なる対応関係となる可能性がありますので参考レベルで参照してください。

アジャイル開発と技術

ここまで説明してきたように、本来のアジャイル開発は利用する技術は決められていません。しかし、アジャイル開発を円滑に進めるためには、開発を支える技術の活用は不可欠です。ここでは、アジャイル開発を進める上で有効な技術を紹介します。

タスク管理ツール

顧客要件の変化に素早く対応して短い時間間隔でリリースするためには、チーム内でリリースに向けて完了・未完了のタスクを見える化し、リリースに向けて計画通りに作業できているか確認し、遅延しているタスクについては素早く対策を検討する必要があります。このようなタスクの状況を管理するためには、RedmineやGitLabのIssue管理などのタスク管理ツールが必要となります。

ソース管理ツール／バージョン管理ツール

動くソフトウェアを、2週間～3週間から2ヶ月～3ヶ月というできるだけ短い時間間隔でリリースするためには複数のソフトウェア開発者が分担して一つの機能を開発することが必要となります。ソースを修正してチームメンバーとレビューし、場合によっては修正を元に戻す必要も発生します。このようなソース修正を効率的に行うためには、GitHubやGitLabなどのソース管理ツール／バージョン管理ツールが必要となります。

CI/CD

ソフトウェアを短い時間間隔でリリースするためにはソースを実装するだけでなく、ソースのコンパイル・テストの実施・セキュリティー検証など各種付帯作業が必要となります。これらの作業をソース修正のたびに手動で実施するのは非常にコストがかかり、リリース時間の短縮の阻害となります。このような各種付帯作業を、ソースが変更されたタイミングなどのタイミングで自動的に実行するための仕組みがCI/CDです。

コンテナ技術

CI/CDで開発環境の検証作業が自動化されても、実際に本番環境にソフトウェアをリリースする場合には開発環境と本番環境の違いにより、開発環境で動いたものが必ずしも本番環境で動くとは限りません。この環境の違いによる差異を軽減する技術がコンテナ技術です。
コンテナ技術はソフトウェアとその実行環境を1つにパッケージングする技術です。開発環境で品質保証したコンテナをコンテナイメージとしてパッケージングし、ステージング環境や本番環境にコンテナイメージを持っていき、ステージング環境や本番環境でコンテナを復元することで、開発環境と同等のアプリケーションとその実行環境を復元できます。このため、ソフトウェアをリリースする時間の短縮につながります。

マイクロサービス

システムが密に連携している場合、システムの機能を一部修正した際に他の機能への影響調査に時間がかかり、短期間でのリリースが困難です。このため、システムの機能を複数の小さいサービス（マイクロサービス）に分割し疎結合で連携するように構築することで、リリースの向上が期待されます。これは、マイクロサービス間のインターフェイスに変更が無ければ、修正対象の機能を実装するマイクロサービスに変更を加える場合の影響調査が局所化されるためです。
マイクロサービスについては特集「クラウドネイティブNow」に掲載されている『今注目される「マイクロサービス（Microservices）」とは』の記事も合わせてご覧ください。

• 今注目される「マイクロサービス（Microservices）」とは（クラウドネイティブNowのページへ）

ドメイン駆動設計

ビジネス側の人とシステム開発者の間のコミュニケーションは容易ではありません。使う言葉が違うため、言葉を合わせることから始める必要があります。
そこで改めて注目されているのが「ドメイン駆動設計」です。開発するシステムをドメインとして抽象化し、その抽象化し表現した設計書をビジネス側の人とシステム開発者の共通言語として、コミュニケーションを取るというものです。特に顧客と協力してアジャイル開発にチャレンジする人は、「ドメイン駆動設計」を参考にされるのが良いかと思います。
また、既存システムを上述のマイクロサービス化する場合、どのような単位でマイクロサービスとするかを議論する場合にも、ドメイン分割により議論するのが有益とされています。

最後に

アジャイル開発は単なる開発手法ではないことを理解いただけたでしょうか？

最後にアジャイル開発でよく議論される話題を取り上げておきたいと思います。

まずは、アジャイル開発チームではスペシャリストとジェネラリスト（多能工技術者）のどちらが必要かという議論です。私は基本的には今までよりもジェネラリストが求められると思っています。従来のように十分な計画を作って開発をする場合には、計画段階でどんな人材が必要なのか分かるため、必要なスペシャリストでチームを作る方が良いでしょう。しかし、多様な顧客ニーズに適用するアジャイル開発では、特定の作業はスペシャリストに頼まないと作業が進まないような状況はボトルネックとなります。当然ながらWebデザインやセキュリティー設計などスペシャリストが必要となる部分はあるにせよ、アジャイル開発ではジェネラリストが求められるケースが多くなるでしょう。

次にアジャイル開発で課題になるのがスキルのバラツキです。短いサイクルで開発するため、スキルの差が見えやすく、1人の作業の遅延や低品質な作業により計画通りにリリースできず、それが繰り返されることが発生する場合があります。このようなケースでは、スキルの高いメンバーに負荷が集中することで不公平感が露呈し、チームの雰囲気が悪くなることもあります。このため、アジャイル開発ではスキルのバラツキが少ない方が当然うまくいきますが、12の原則の中に「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」という原則があるように、アジャイル開発では意欲さえあれば各個人のスキルの飛躍的な向上が期待されます。ペアプログラミングやモブプログラミングなどを使って、スキルの高い人がフォローしてチーム内で成長を支援すれば、スキルのバラツキも解消されるでしょう。

必ずしもアジャイル開発が適するものばかりではないと思います。最初に緻密な計画を立ててから開発を進めた方が良いものは当然あります。しかし、アジャイル開発の本質を考えることは、現在当たり前のように実施してきた開発プロセスが本当に顧客価値に繋がるプロセスなのかを考えるきっかけとなります。
本特集を参考に、ぜひ皆さんの組織に適する開発方法を改めて考えてみてください。

関連製品・サービス

当社が提供するデジタルトランスフォーメーションを支えるアプリケーションサーバー「FUJITSU Software Enterprise Application Platform」の詳細は下記ページをご覧ください。

• FUJITSU Software Enterprise Application Platform

当社が提供するDX実現の課題にお応えするハイブリットITサービスの詳細は下記ページをご覧ください。

• FUJITSU Hybrid IT Service Digital Application Platform

• FUJITSU Hybrid IT Service