アジャイル開発はもちろん、ウォーターフォールだってシステムエンジニアの誰でもができるシステム開発手法ではない


システムエンジニアもプロジェクトマネージャも顧客が使うシステムを提供したいのであって、それに適したシステム開発手法を選べば良いのです。


第一、システム開発手法なんて顧客から見たらどんな手段でも良いわけだ。ITの専門家が要件を実現する道具にすぎないのだから。システム開発手法であっちが良いとかこっちが良いとか、そんなのは内輪揉めというかわがままというか、何にしても顧客の要件を実現するに際して適切なシステム開発手法を選択すれば良いのですよ。繰り返すけど、実現するための道具だからね。


ウォーターフォールアジャイル開発もこのままやれば良いという決まった手順はない
ウォーターフォールアジャイルも「ここに書いていあるままにやって」という手順はありません。ざっくりしたというか雛形みたいなものはある。パッケージのシステム開発と同じで、カスタマイズしないと使えない。この点は同じ。違う点を探すとすれば、ウォーターフォールの方が古いので手垢のついた誰が作ったかわからない過去のやり方を使いまわしているくらい。あと10年もしたらアジャイル開発だって同じように誰が元を作ったかわからない擬似標準があるにちがいない。


ウォーターフォールのドキュメントは減っていくだろうし、アジャイル開発のドキュメントは増えていく
ウォーターフォールで作成するドキュメントはちびっとずつ減っていくにちがいない。コストプレッシャーによって。いや、もともと作っていないプロジェクトも世の中にはあるらしいから、そういうプロジェクトは相変わらずひどいままの開発を続けるのだろう。


ドキュメントなしで。アジャイル開発が世の中に広まっていくと、ウォーターフォールのエリアを置き換えるわけで、そうした背景を考えれば顧客の顧客内での説明が成り立たない限り、アジャイル開発であってもドキュメント作りは増えるだろう。だって、契約書に書いてあるから。契約書を取り交わす、営業、購買、法務関係者が成果と対価を取り交わすためのエビデンスを簡便なもので済ませられるほどの契約形態を、発注者側と受注者側で握れるまでは。


ウォーターフォールアジャイル開発もプロジェクトマネジメントをするのは変わらない
ウォーターフォールはプロエジェクトマネージャが、アジャイルは全員で(かな、思想的には)、そのロールを担うのであって、プロジェクトマネジメント自体、マネージャサイドからの管理単位によるプロジェクトのコントロールが目的だから、プロジェクトである限りなくなるものではないのですよ。


全員で担うところの方が、明示的にメンバに要求するなら好ましいわけです。全員の意識がプロジェクトマネジメントに向くわけですから。逆に言えばアジャイル開発でプロジェクトマネジメントを担うための素地としてのスキルレベルの基準が必要ってことです。全員がプロマネをやったことがるとかだと新規参入者が入れないですから。結局、誰かが足りないところを追いつくまでの期間補うってところは役割分担をしてしまうウォーターフォールと近しいですが、アジャイル開発の方が、ある時期になるとメンバのレベルが合うので仕事が早くなるわけです。


一つ目はプロセス、二つ目は成果物、最後はプロマネを取り上げたのですが、まあ、びっくりするほどの違いってないんですよ。運用でプロマネやマネージャが早い開発が必要ならウォーターフォールベースでも工夫することでできるんです。実体験を振り返ってみても。


どっちにしても、要件を実現する方法を選べば良いのです。あぁ、その実現できる方法には、メンバがそれをできるというのも入っているので忘れずに。アジャイル開発はもちろん、ウォーターフォールだって誰でもできるわけではないのですよ。