はじめに

最近図書館によくいくのですが、その中で『誰も教えてくれなかったアジャイル開発』という本がありました。
試しに少し読んでみて、実際に私が参画したプロジェクトで遭遇したケースを例に挙げていて非常に興味深いソリューションが紹介してあり思わずページを捲る手が止まりませんでした。
少しだけですが内容を共有したいと思い執筆しました。
日本企業でなぜアジャイル開発が浸透しないのかなどがわかるような内容になっているかと思います。

アジャイル開発とは

「迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称」 のこと

『短い開発サイクル』でプログラムをリリースし続け、エンドユーザーにフィードバックを受けながら改修を重ねることでプロダクトを洗練させていくことができる特徴がある

開発サイクルは2週間から1ヶ月ほど
開発サイクルのことはイテレーション または スプリント と呼ぶのが一般的
プログラムの開発要件を分解して、各開発サイクルに割り振る
1スプリントの中で実装したプログラムをエンドユーザーがその都度確認するというサイクルを繰り返し、ユーザーにとって価値の高いものを短期間でスピード感を持って提供し続けることができる
DXの風潮を受け、ビジネスシーンの変化に柔軟に対応できるアジャイル開発が再び脚光を浴びている

アジャイル開発の特徴

最大の特徴はエンドユーザーのフィードバックを受けながら要件やゴールを柔軟に変更できること
ウォーターフォールとの相違点
- ウォーターフォールはプロジェクト開始前に全体の作業計画を立てるが、アジャイル開発ではプロジェクト開始時点では全体の作業計画は概要にとどめる
- アジャイル開発ではウォーターフォールと異なり網羅的にドキュメントを作成しないためチーム外からはプロジェクトの状況把握が難しいとされている
  - 上記のため、アジャイルでは中央集権型で計画重視の組織にはフィットしにくいと言われている
  - そのためアジャイル方法論としてアジャイル開発を採用するためにはまずは企業の組織や文化の変革が必要だとされている

基礎編

アジャイル開発「事始め」で抑えるべき5つの要点

1. アジャイルの解釈は人それぞれ

アジャイルに対する認識の違いが組織内のメンバー間に軋轢を生む
- 誤解されがちな「早い」「安い」
  - 「早い」 については、動く最低限のものをエンドユーザーに使ってもらいフィードバックを「素早く」得ることで完成に近づけるサイクルを繰り返すという認識が正しい
    - すなわち、ウォーターフォールと比較してアジャイル開発が早いというのは誤解である
  - 「安い」 についてはアジャイル開発は素早くフィードバックを得ることで必要な機能に絞り込んで開発することで目標予算内で開発をコントロールするという認識が正しい
    - よって、「システム構築の保守運用の費用の『総額』が下がる」というのは誤解である
- その他よく誤解されがちなイメージ
  - ドキュメントがいらない
    - ウォーターフォールでは網羅的にドキュメントを作成するが、アジャイル開発では必要最小限のドキュメントを作成する。いらないわけではない
  - 計画を立てない
    - ウォーターフォールはプロジェクト開始前に詳細な全体計画を立てるが、アジャイル開発では概要計画のみを立て、詳細は各イテレーションで決定する
  - 要求を自由に変更できる
    - 変更は可能だが、プロダクトバックログの優先順位付けを通じて管理される
  - 統制が取れない
  - プロジェクトマネージャーが必要ない...など

プロジェクトを取り巻くプロジェクト関係者、特にプトジェクトを評価する関連部門担当役員・部門長層がこのような誤った先入観を持っていると、期待値が一致しないままプロジェクトが進んでいくことになる。

その結果 「当初予定したスピードや内容でプロジェクトが進捗していない」 と判断さされてしまい、アジャイル開発では本来必要ないリカバリー作業や報告などに現場の工数が取られるケースも生じてしまう。

このようなことを防ぐため、まずはプロジェクトの開始段階で時間をかけてアジャイル開発の特性について理解を一致させておくことが必要

2. 教科書通りは存在しない

前提としてアジャイル開発とは、単一の開発手法ではなく、複数の開発手法の総称として用いられる

よく採用されているのは 「スクラム」 と呼ばれる手法で、アジャイル開発プロジェクトの約6割がスクラム開発を採用している

スクラムとは？
日本企業でよくありがちなアンチパターン
- 本来であればプロダクトオーナーは1人が良いとされているが、複数の兼任者で構成されがちな点
  - イベント開催の調整に時間がかかり、本来の開発スピードを出せなくなることがある
- スクラムマスターや開発メンバーの役割をITベンダーの社員に割り当てる際に、「会社間の責任範囲を明確化した請負契約を結んでしまう」点
  - ⇨「自己組織化したチームへの権限の委譲こそがアジャイル開発成功の鍵」
  - 日本企業の組織や文化を踏まえた上でやり方を考えていく必要がある

3. まずは小さい成功事例を作る

日本企業によくある中央集権型のピラミッド組織において、アジャイル開発のような自律的に活動するチームが課題を自己解決しながら仕事を進めていくと以下の問題が発生する可能性

上から「何をやっているかわからない」という不信感を抱かれる
下からは「十分な指導を受けられていない」という不安を抱かれる

つまり、中央集権型組織の中で自立型のアジャイルチームが独自方針で活動しようとすると、さまざまな軋轢が生じる結果になる

⇨ではどうするか？「小さな成功事例を作る」

中央集権型の組織内で、アジャイル開発が圧倒的な説得力を持つためには身近なアジャイル開発の成功事例が必要
まず社内でどんなに小さくても良いのでアジャイル開発の成功事例を作り、それを積み重ねて周囲を動かしていく
- 上からの不信感、下からの不安感を抱かせないようにコミュニケーションを取ることは欠かせない
- こうして徐々に周囲に「大丈夫そうだ」と慣れていってもらうのが、実は定常的にアジャイル開発を推進していくための一番の早道

4. 段階的リリースは業務プロセスと全体整合性を重視

既存システムのリプレースにおいて、アジャイル開発は難しいとされている

理由
- ①「現行機能保証」の考え方が根強い
  - 例えば社内の業務システムは長年の度重なる仕様変更や機能追加を経て今の業務プロセスを支えているという長い歴史があり、ユーザーは現行の仕様の踏襲を求める傾向がある
  - アジャイル開発は、プロジェクトの目的に照らして価値の高い機能を優先的・段階的にリリースしていく手法となるため、現行機能保証を求めるリプレースと相性が悪い
- ②「全体整合性」を取る必要がある
  - リプレースでは「システム全体」を初期段階から一段と意識して、機能を実装する優先順位と段取りをあらかじめ設計しておく必要がある
  - ウォーターフォールと同じように、既存システムとの連携機能の意向やデータ移行、ユーザーテストなどのタスクが生じる

5. 「開発し続ける」体制に変える

アジャイル開発では、開発フェーズと保守・運用フェーズを明確に分けない
⇨つまり、発注側と開発ベンダーとの双方が意識的にチームを「存続」させるように取り組む必要がある。