-アジャイルは単に「速く開発する方法」ではない-
ソフトウェア開発の現場では、「アジャイル（Agile）」という言葉をよく耳にします。
しかし、アジャイルを単に
「開発を速く行うこと」
「スプリントを2週間単位で回すこと」
「毎朝デイリーミーティングを行うこと」
程度に理解していると、アジャイルの本質を見失いやすくなります。
アジャイルの出発点は、2001年に発表されたアジャイルソフトウェア開発宣言（Agile Manifesto）です。
アジャイル宣言では、次の4つの価値を重視しています。
-
プロセスやツールよりも個人と対話
-
包括的なドキュメントよりも動くソフトウェア
-
契約交渉よりも顧客との協調
-
計画に従うことよりも変化への対応
プロセス、ドキュメント、契約、計画も必要ですが、それ以上に人とコミュニケーションを取り、実際に動く成果物を作り、顧客と協力し、変化に対応することを重視するという意味です。
アジャイルの12の原則
アジャイル宣言には、4つの価値とともに、それを実践するための12の原則があります。
1. 顧客満足を最優先する
価値あるソフトウェアを可能な限り速く、継続的に提供し、顧客を満足させることを最も重要とします。
2. 要求事項の変更を受け入れる
開発の後半であっても、要求事項の変更を受け入れます。
変更を無条件にプロジェクトの妨げとみなすのではなく、顧客に競争力を提供できる機会と捉えます。
3. 動くソフトウェアを頻繁に提供する
数か月かけて開発した後にまとめて見せるのではなく、短いサイクルで実際に動く成果物を提供します。
4. ビジネス担当者と開発者がともに働く
企画担当者、現場担当者、開発者は、プロジェクトの初期にだけ会うのではなく、プロジェクト全体を通じて継続的に協力しなければなりません。
5. 意欲のある人を中心にプロジェクトを構成する
チームメンバーに必要な環境と支援を提供し、自ら業務を遂行できるよう信頼します。
6. 最も効果的なコミュニケーションは直接対話である
ドキュメントやメールだけをやり取りするのではなく、必要に応じて直接対話し、問題を迅速に解決します。
7. 動くソフトウェアが進捗の最も重要な基準である
「どれだけドキュメントを作成したか」よりも、実際に動く機能がどれだけ作られたかを重視します。
8. 持続可能な開発速度を維持する
特定の期間に残業や時間外労働を繰り返して速度を上げるのではなく、長期的に維持できる開発速度を追求します。
9. 技術的な完成度と優れた設計を継続的に追求する
単に機能を速く作るだけで終わりではありません。
優れたコードと設計、技術的な品質を継続的に改善しなければなりません。
10. シンプルさを追求する
しなくてもよい作業をできる限り減らします。
つまり、「何をさらに行うか」だけでなく、「何を行わないか」を考えます。
11. 優れたアーキテクチャと要求事項、設計は自己組織化されたチームから生まれる
すべてを管理者が一方的に決めるのではなく、実際に業務を行うチームが問題を解決し、意思決定に参加します。
12. 定期的に振り返り、改善する
プロジェクトが終わった後にだけ問題点を分析するのではなく、一定の周期でチームの仕事の進め方を振り返り、改善します。
これがアジャイルの レトロスペクティブ（Retrospective）につながる重要な原則です。
それでは、SIプロジェクトにもアジャイルは可能なのでしょうか。
ここで、現実的な問題が一つあります。
SIプロジェクトは、一般的なスタートアップや製品開発とは環境が大きく異なります。
たとえば、SIプロジェクトでは次のような状況がよくあります。
-
契約期間と終了日が決まっている。
-
顧客企業が別に存在する。
-
提案書と契約書に開発範囲が明記されている。
-
分析・設計・開発・テストなどの工程が存在する。
-
数多くの成果物を提出しなければならない。
-
顧客の要件変更には、追加費用やスケジュール変更が必要になる場合がある。
-
複数の協力会社が一つのプロジェクトに参加する。
したがって、SIプロジェクトにアジャイルを適用するからといって、既存のプロジェクト管理体制をすべてなくし、「今日からScrumで進めます」と言うのは現実的ではありません。
むしろSIでは、アジャイルの哲学と一部の実践方法を既存のプロジェクト管理方式に組み合わせる方法が現実的です。
SIプロジェクトに適用しやすいアジャイルの方法
① Scrum
最も代表的な方法がScrumです。
Scrumは経験主義を基盤としており、複雑な問題を一度に完璧に計画するのではなく、実際の結果を確認し、点検し、その結果に応じて次の行動を調整する方法です。
Scrumの経験主義は、大きく三つに分けて説明できます。
透明性 → 点検 → 適応
つまり、
何をしているのかを見えるようにし、
→ 実際の結果を確認し、
→ 結果に応じて計画と方法を修正する。
という構造です。
SIプロジェクトではどのように適用するのでしょうか。
たとえば、6か月間のプロジェクトがあると仮定してみましょう。
従来の方法であれば、
要件分析
↓
全体設計
↓
全体開発
↓
統合テスト
↓
ユーザーテスト
↓
リリース
という方法で進めることができます。
この場合、開発初期に定義した要件が実際のユーザーに適しているかを、かなり遅い段階で確認することになる可能性があります。
Scrum方式を一部適用するのであれば、これを小さな単位に分けます。
例えば、2週間を1つのSprintとして設定します。
Sprint 1
会員登録 + ログイン
Sprint 2
会員情報の照会 + 修正
Sprint 3
商品の照会
Sprint 4
注文
Sprint 5
決済
このように開発し、各Sprintが終了するたびに、実際に動作する成果物を顧客または業務担当者に見せます。
すると顧客は、
「想像していた画面と少し違いますね？」
と言うことができます。
まさにこの時点で修正します。
プロジェクト後半に発見する場合よりも、はるかに低いコストで修正できます。
② 経験主義（Empiricism）をSIプロジェクトに適用する
個人的には、SIプロジェクトで最も重要なアジャイル概念の一つが、経験主義だと考えています。
経験主義とは、簡単に言えば、
計画や推測だけを信じず、実際の経験と観察を通じて判断しよう
ということです。
Scrumでも、複雑な業務は事前にすべてを完全に予測することが難しいため、実際の結果を観察し、その結果に基づいて次の行動を決定する方法を用います。
例えば、顧客が次のように要求したと仮定してみましょう。
「ユーザーが簡単に使える注文画面を作ってください。」
文書だけを基に開発すると、開発者は「簡単に」という言葉をそれぞれ異なる意味に解釈する可能性があります。
しかし、実際の画面を一つ作ってユーザーに見せると、話は変わります。
ユーザーが実際に使ってみて、
「このボタンは見えにくいです。」
「この手順はわざわざ必要ないようです。」
「モバイルではこのように使うほうが便利です。」
と話すことができます。
これがまさに、経験 → 観察 → フィードバック → 改善です。
SIプロジェクトで経験主義を適用するということは、結局のところ、
文書だけで要件を確定せず、できるだけ早く実際の成果物を作って確認すること
だと言えます。
③ ペアワーク（Pair Work）を活用する
アジャイル開発で活用できるもう一つの方法が、ペアプログラミング（Pair Programming）です。
2人の開発者が一つの作業を共同で行う方法です。
一人がコードを書き、もう一人がそれをリアルタイムでレビューしながら共同で開発します。
もちろん、SIプロジェクトですべての開発業務を常にペアで進める必要はありません。
むしろ、人員とコストの面で非効率になる可能性があります。
したがって、重要またはリスクの高い業務に選択的に適用する方法が現実的です。
例えば、次のような業務です。
-
中核業務ロジック
-
決済モジュール
-
セキュリティ関連機能
-
複雑なSQL
-
大規模なデータ変換
-
共通フレームワーク
-
障害が発生する可能性の高い機能
-
経験の浅い開発者による中核機能の開発
例えば、開発者Aが決済モジュールを開発し、開発者Bが後からコードレビューを行う従来の方法ではなく、
A + Bが最初から一緒に設計・開発することです。
このようにすれば、知識が特定の開発者一人に集中するのを減らすことができます。
④ デイリーミーティングを短時間で運営する
SIプロジェクトでアジャイルを適用する際、最も簡単に始められるのがDaily Scrumです。
ただし、ここで注意すべきことがあります。
デイリーミーティングをチームリーダーへの業務報告の時間にしてはいけません。
良いデイリーミーティングは、
「昨日は何をしましたか？」
「今日は何をしますか？」
だけを繰り返す会議ではありません。
重要なのは、Sprint Goalに向けて進んでいるかを確認し、必要に応じて計画を調整することです。
例えば、開発者が
「APIの開発が80％ほど完了しました」
と報告するよりも、
「A画面とB画面は完了しましたが、C APIで外部システムとの連携に問題が発生しました。この問題が解決しなければ、今回のSprintで決済機能を完成させるのは困難です」
と共有するほうがはるかに有用です。
つまり、デイリーミーティングは報告会ではなく、問題を早期に発見する場でなければなりません。
⑤ Sprint Reviewを顧客と一緒に行う
SIプロジェクトでは、特に重要な部分です。
Sprintの終了時に開発チーム内だけで成果物を確認するのではなく、可能であれば顧客または業務担当者に実際に動作するシステムを見せることです。
例えば、
「会員管理機能の開発完了」
と文書で報告するのではなく、
実際のシステムで
会員登録 → ログイン → 会員情報の照会 → 編集
を実際にデモします。
そして顧客に尋ねます。
「実際の業務でこの画面を使うとしたら、不便な点はありますか？」
このようにすれば、要件と実際の業務との間にある違いを素早く見つけることができます。
⑥ Retrospective、つまり振り返りを行う
アジャイルでもう一つ重要なのが振り返り（Retrospective）です。
Sprintが終わると、チームで次のことを問いかけます。
うまくいったことは何か？
問題だったことは何か？
次のSprintでは何を変えるか？
例えば、最初のSprintで
開発環境の構築に3日かかった。
場合、次のSprintでは
共通の開発環境をあらかじめテンプレート化する。
という改善策を決めることができます。
重要なのは、振り返りを単なる反省会にしてはいけないということです。
「誰が悪かったのか？」ではなく、「次はどうすればもっとよくできるか？」について話し合う必要があります。
アジャイルの12番目の原則でも、一定の間隔でチームが自分たちの仕事の進め方を振り返り、より効果的な方法に調整することを強調しています。
SIプロジェクトに適用するなら、このように組み合わせることができる
結局のところ、SIプロジェクトでアジャイルを適用する現実的な方法は、次のように整理できます。
|
アジャイルの方法 |
SIプロジェクトへの適用 |
|---|---|
|
Scrum |
2～3週間単位でSprintを運用 |
|
経験主義 |
実際の成果物を素早く作成して検証 |
|
Daily Scrum |
短時間で進捗状況と障害要因を共有 |
|
Sprint Review |
顧客・現場担当者に実際の機能をデモする |
|
Retrospective |
Sprint終了後に仕事の進め方を改善 |
|
Pair Work |
中核的・高難度の業務に選択的に適用 |
|
Backlog |
要件を優先順位ごとに管理 |
|
Increment |
Sprintごとに動作する成果物を確保 |
|
Self-Organizing Team |
開発チームが詳細な作業方法を自ら決定 |
アジャイルSIプロジェクトの核心は「アジャイルに考えること」
SIプロジェクトにアジャイルを適用するからといって、必ずしもすべてのプロジェクトをScrumで運用しなければならないわけではありません。
むしろ重要なのは、アジャイルの考え方をプロジェクトに適用することです。
例えば、次のような違いがあります。
従来の方法
“要件をまず完全に確定したうえで開発する。”
アジャイル方式
“可能な限り早く作ってみて、実際の結果を通じて要件を具体化する。”
伝統的な方式
“スケジュールが変更されたら、プロジェクトは失敗したということだ。”
アジャイル方式
“変更が発生したら、まず優先順位を調整し、より価値のある成果を生み出す方法を探す。”
伝統的な方式
“開発者が作業を完了したかどうかが重要だ。”
アジャイル方式
“ユーザーが実際に使える機能が作られたかどうかが重要だ。”
まとめ
アジャイルは単に Scrumを導入したり、JiraにBacklogを作成したりするプロジェクト管理手法ではありません。
核心は次の4つに要約できます。
素早く作り
↓
実際に確認し
↓
顧客からフィードバックを受け
↓
次の開発に反映する。
そして、このプロセスを繰り返しながら、プロジェクトを少しずつより良い方向へ進めていくのです。
特にSIプロジェクトでは、契約、スケジュール、成果物、顧客企業など、さまざまな制約があるため、アジャイルのすべての要素をそのまま適用することは困難です。
したがって、現実的なアプローチは SIの既存の管理体制を維持しながら、Scrum、経験主義、短い開発サイクル、顧客からのフィードバック、振り返り、ペアワークといったアジャイルの実践方法を、必要な部分から選択的に適用することです。
結局のところ、アジャイルの核心となる問いは
“最初に立てた計画をどれだけうまく守れたか？”
ではなく、
“プロジェクトが進行する間に、私たちはどれだけ早く学び、変化し、顧客に価値を届けられたか？”
にあると言えます。
Luke