読者です 読者をやめる 読者になる 読者になる

arclamp

ITアーキテクト 鈴木雄介のブログ

アジャイルがビジネス価値を作るわけじゃない - 改めて開発手法としてのアジャイル

"アジャイル"は単なる開発手法というだけでなく、その出自からして「ビジネス価値にコミットする」というような意味を含んでいるように思います。なので「アジャイルだけがビジネス価値を作ることができる」、その逆として「ウォーターフォールではビジネス価値を作れない」というような言い方が出てしまう場合があります。

もちろん「ビジネス価値を作ること」と「ソフトウェアを作ること」は無関係ではありませんが、それがすべてではありません。ビジネス価値にとって重要なのは「どういうソフトウェアを作るか」ということであって「どうソフトウェアを作るか」ではないからです。

というわけで、改めてアジャイルウォーターフォールを純粋な開発手法として整理したいと思います。

f:id:arclamp:20130902134924j:plain
from Choices by Caleb Roenigk


基本は計画、実行、調整
ソフトウェア開発に限らず、プロジェクトマネジメントの基本は「計画し、実行し、調整する」です。プロジェクトマネジメントには必ず計画があり、それを実行します。そして実行しながら計画とのズレを把握し、調整を行います。完璧に計画通りなら調整というプロセスは不要ですが、世の中そうはうまくいきません。だから、計画だけではなく、調整が重要なのです。

そして開発手法とは「計画、実行、調整をどのような考え方で行うのか」であり、特に重要なのは「いかに計画と実行のズレを発見し、どのように調整するか」ということです。この点に注目してウォーターフォールアジャイルを比較してみます。


ウォーターフォールは「計画を正として調整」
ウォーターフォールは全体計画を重視し、それを正しいものとしてスケジュールやリソース配置が組み立てられます。よって、実行が開始されると、ズレは計画を基準にして把握され(進捗管理)、タイミングを計って調整(変更管理)していきます。

前提は「計画が正しい」ですが、計画変更をしてはいけないわけではありません。ただ、調整が少ないほど効率は良いのは確かです。調整が多発するような状況になると、基準がブレてしまうためズレの把握が困難になっていきます。いわゆる「進捗が信用できない」という状況です。

このようにウォーターフォールでは計画精度が低いと実行段階での調整が間に合わずプロジェクトが崩壊します。よく聞くのはビジネス要件の決定が曖昧、技術的な検証が曖昧というような場合でしょうか。

逆に、十分に計画精度が高いと効率的で最適化されたプロジェクトが実現できます。そのドメインに十分な知識がある、あるいは、パッケージ導入や法律に定められたような機能のように繰り返し実行してノウハウが蓄積されているなどが考えられます。


アジャイルは「再計画によって調整」
一方アジャイルでは「調整が不要なぐらい計画を小さくし、その次の再計画によって調整を行う」という考え方をします。

まず、計画が小さくなれば計画精度は高まります。1年後ではなく数週間先のことだけを検討するのです。次に、実行しはじめたら調整をせずに「期間の完了後に棚卸を行うことでズレを把握」し、「次の計画に反映することで調整」させます。

ポイントはタイムボックスと呼ばれる「計画の期限が来たら必ず棚卸をする」という点です。これによって強制的に調整を働かせることができます。

ウォーターフォールが適宜調整していくのに比べると、アジャイルの強制調整は乱暴な考え方にも思えますが、実際にプロジェクトで調整が多い場合には効果を発揮します。つまり、調整を定期的なプロセスとして織り込んだわけです。かつ、再計画というのは調整幅が非常に大きく、どんな状況にも柔軟に対応することができます。これはウォーターフォールが計画を変えない前提に立つのとは大きく異なります。

ただし、逆にいえばアジャイルでは全体計画と個別計画の整合性を検証することが困難です。そのため個別計画はうまく行っていても、全体として問題が生じてしまい、崩壊することがあります。

アジャイルで全体と個別のバランスを取るのは職人的です。エンジニアと顧客が十分にコミュニケーションを行い、つねに全体感を共有する必要があります。双方が十分に対象ドメインに詳しければ、もっとも効率的な問題解決方法でしょう。

なので、改善や保守あるいはサービス運営などの「既に全体的な基盤が安定しているが、問題が突発的に発生してしまう」ような状況においては比較的簡単に導入できますし、逆に新規の大型案件のように「安定した基盤もなくコミュニケーションパスが大きくなりすぎる」ような状況では不利になります。


局面に合わせた選択を
こうして考えてみると、多くのプロジェクトが完全にどちらかの状況にあるわけではありません。よく言われるように近年はビジネス環境の変化が激しいため、一見するとアジャイルが適するような状況が多いでしょうが、一方でアジャイルは全体整合性が取りにくいのも事実です。

ビジネス環境の変化は大きいからといって事前の綿密な計画が不要なわけではありません。計画できることは十分に計画して効率的に進め、不明瞭な部分は先行的にトライ&エラーをしてフィードバックを得ればよいのです。残念ながら絶対的な銀の弾丸は存在せず、敵に応じて弾の詰め替えをするしかないのです(写真はレゴを前に悩む女の子)。


ビジネス価値を作るのは「姿勢」
ビジネス価値を作るのに大事なのは、それを実現しようとするプロジェクトチームの姿勢です。それが開発手法によって決定するわけではありません(もちろん、助けにはなります)。これは請負受託だろうが自社開発だろうが、まったく同じことです。

プロジェクトはアジャイルだから成功するわけでも、ウォーターフォールだから失敗するわけでもありません。「ビジネス価値があるシステムを作りたいからアジャイル」という短絡的な考えに陥り、色々な制約を無視してプロジェクトを進めても成功することはありません。

チームはビジネス価値に貢献するという姿勢を忘れず、そのうえで、局面や状況にあわせた開発手法を選択してください。