昨今アジャイルがまた脚光を浴びていて、比較的大手の企業や、大規模プロジェクトへの適用も進んでいるようです。この数年というか数十年、何か定期的にアジャイルがクローズアップされているようなのですが、気のせいでしょうか。IT業界に身を置いているものの実感としては、アジャイルがメインストリームになっている気がしない時期は、実際長かったと感じますが、今来ている波は、これまでとちょっと違った雰囲気のような感じがします。このところのアジャイルの再考に関しては、IPA*1がプレス発表した、「第4次産業革命」に向けたスキル強化の指針“ITSS+(プラス)”に新たに「IoTソリューション領域」「アジャイル領域」を策定し、公開したことが、少なからず影響しているようです。いうのはIPAには、大手IT系企業が名を連ねていて、平たく言えば「業界にそれなりの影響を与えている団体」であるからです。これまでのシステム開発においてアジャイルは、なんとなく「マイナー」もしくは「インディーズっぽい」、または「ややマニアック」みたいな存在であったのが、経済産業省所管の中期目標管理法人のお墨付きをもらって、本格的に啓もう活動がなされ出した、ってところでしょうか。https://www.ipa.go.jp/about/press/20180409.htmlで、実際のところPMO的にどうよ?どうアジャイルに食い込んでいこうか?アジャイルプロジェクトの体制にはPM(プロジェクトマネージャー)とかPMO(プロジェクトマネジメントオフィス)とかなくて、かわりにスクラムマスターとかプロダクトオーナーとかが配置されているけれども、全然違うのか?それとも同じようなものか?そのあたりを見ていこうと思います。不確実性が増しているまず「そもそもアジャイル開発プロジェクトって、おこなわれているの?」ってことで、それなりの規模のITプロジェクトの現状を見てみると、実際問題、これまでアジャイルなんて見向きもしなかったような中~大企業が、関連する国家戦略、たとえば「働き方改革」や「ライフ・ワーク・バランス」とセットで、アジャイル開発を導入する例が増えているようには思います。以前と比較するとよく聞こえてきますし、「え、あの企業が全面的に採用の方針?」と、ちょっとびっくりするようなことも、このところはあるからです。サーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると31%が導入済みに過ぎず、明らかに遅れをとっている」とのことです。年数にしたら「5年は後れを取っている」、とも言及されています。彼は、以下の衝撃的な発言もおこなっています。※マイクロソフト関係者の記事よりサム・グッケンハイマーさんの(議事録上の)発言を引用。http://simplearchitect.hatenablog.com/entry/2016/06/20/080807何と大きく出たことか、というのが第一印象です。いうのは、ウォーターフォールもアジャイルも、所詮は人間が集団でシステムを作るための枠組みというか仕組みであって、まともな人間がやればどちらもまともに進むし、まともでない人間がやればどっちにせよダメになる、と私は思っているからです。システムの開発や導入とはいえ、基本的にはヒト依存の部分は大きいと(まだ)思っています。前述の彼の発言は、「まともな人がまじめにやっていても、いずれはウォーターフォールは立ちいかなる」ということなのか?それとも、過去においては有効だったけれども、近年はダメだ、ってことなのか?ここでは一旦「近年だからこそウォーターフォールはダメだ」という仮説を立てて、その理由を探求しくことにします。環境の変化が激しく、早いこと過去と違う点。浮かぶのが、スマホやタブレットといったデバイスの進化。それから、AWSやSFDCに代表されるような、クラウドの台頭。これらは、勝手にバージョンアップしたり、仕様変更してきたりする。デバイスやクラウドといった「外的な存在」、つまり「自社で作りこんでいるものではないが故に、その変化をコントロールできない存在」が、今の時代はすごい勢いで増えている。変化のサイクルは、過去よりも相当早い。これだけでも、現代のシステム開発が、ウォーターフォール型だと対応できない理由に、十分該当しそうです。このことを端的に言えば、「不確実性が増えているから、長期的なウォーターフォール型開発はダメ」となります。開発対象以外の「外的な要素」、つまりウォーターフォールにおいては前提条件や制約条件で「変わらないこと」としていた要素が、平気でこちらの断りなしに変わってしまうという。ウォーターフォール型だと半年~1年、長いときには2年、3年以上になるようなプロジェクトも多く、日進月歩でテクノロジーやアーキテクチャが変化していく中で、時代に合わないやり方になってきているのは事実でしょう。ウォーターフォールは途中の仕様変更が原則不可さらに「ウォ-ターフォール型開発」では、全体が長期であろうがなんであろうが、システムプロジェクトの企画から始まって、1要件定義2設計3製造・テスト4リリースという工程を順に進むのが定石で、工程途中での仕様変更を原則認めないスタンスで進めていきます。このあたりも「ウォーターフォールはいまどきイケてない」といわれてしまう所以です。テクノロジーの中には、SNSやクラウドのしくみのように、半年とか1年単位でどんどん変わっていくものもありますから、ユーザー要件は「環境が変われば変わっていくものだ」という、「これまでの常識や思い込みの入れ替え」も必要になってきます。い主への報告支援、等)ってところです。そのうち3ドキュメント作成は、アジャイルのイメージでは原則不要または少ない、とされていますが、ドキュメントの全くない集団行動というのはありえないですし、アジャイルでも要求事項を可視化したバックログや、スクラムマスターやプロダクトオーナー、開発チームなどを明記した体制資料などは必要となってきますので、まあ必要でしょう。1も2も、アジャイルだからと言って(少なくなることはあっても)なくなるわけではないことはおわかりでしょう。アジャイルでは、「開発者を含めて、参加するメンバーすべてが自律的で前向きであれ」とされていますが、これが本当にできるのであれば、それこそウォーターフォールでもできているわけで、それができていないことが多いので、PMOが繁盛してきたわけです。「敵は本能寺にあり」ではないですが、本当の敵は、実はウォーターフォールではなくて、社風とか文化とか、業界の体質とかいう、「空気」や「社会」にカテゴライズされるような、得体のしれないものなのかもしれません。いや、そっちでしょう。いうことで、ウォーターフォール型開発プロジェクトにおいて、「ザ・すきま産業」であるところのPMOは、アジャイル型開発プロジェクトになったら、もしかしたら「スクラムマスター支援」とか「プロジェクト推進」とか、名前は変わるかもしれませんが、おそらくニーズとしては消えないもの、つまり「PMOのお仕事はなくならない」、と思われます。頑張っていきましょう。それでは、皆さんさようなら。