アジャイルを導入すると従来型PMOは仕事がなくなるのか

昨今アジャイルがまた脚光を浴びていて、比較的大手の企業や、大規模プロジェクトへの適用も進んでいるようです。この数年というか数十年、何か定期的にアジャイルがクローズアップされているようなのですが、気のせいでしょうか。IT業界に身を置いているものの実感としては、アジャイルがメインストリームになっている気がしない時期は、実際長かったと感じますが、今来ている波は、これまでとちょっと違った雰囲気のような感じがします。

このところのアジャイルの再考に関しては、IPA*1がプレス発表した、「第4次産業革命」に向けたスキル強化の指針“ITSS+(プラス)”に新たに「IoTソリューション領域」「アジャイル領域」を策定し、公開したことが、少なからず影響しているようです。というのはIPAには、大手IT系企業が名を連ねていて、平たく言えば「業界にそれなりの影響を与えている団体」であるからです。

これまでのシステム開発においてアジャイルは、なんとなく「マイナー」もしくは「インディーズっぽい」、または「ややマニアック」みたいな存在であったのが、経済産業省所管の中期目標管理法人のお墨付きをもらって、本格的に啓もう活動がなされ出した、ってところでしょうか。

*1日本におけるIT国家戦略を技術面、人材面から支えるために設立された、経済産業省所管の中期目標管理法人たる独立行政法人 関連記事はこちら。https://www.ipa.go.jp/about/press/20180409.html

で、実際のところPMO的にどうよ?どうアジャイルに食い込んでいこうか?アジャイルプロジェクトの体制にはPM(プロジェクトマネージャー)とかPMO(プロジェクトマネジメントオフィス)とかなくて、かわりにスクラムマスターとかプロダクトオーナーとかが配置されているけれども、全然違うのか?それとも同じようなものか?そのあたりを見ていこうと思います。

不確実性が増している

まず「そもそもアジャイル開発プロジェクトって、おこなわれているの?」ってことで、それなりの規模のITプロジェクトの現状を見てみると、実際問題、これまでアジャイルなんて見向きもしなかったような中~大企業が、関連する国家戦略、たとえば「働き方改革」や「ライフ・ワーク・バランス」とセットで、アジャイル開発を導入する例が増えているようには思います。

以前と比較するとよく聞こえてきますし、「え、あの企業が全面的に採用の方針?」と、ちょっとびっくりするようなことも、このところはあるからです。

とはいえ世界と比較すると、2016年時点の統計によれば、日本はまだまだアジャイル開発が普及していないようで、マイクロソフトのMicrosoft Visual Studioの開発におけるプロダクトオーナーを務め、日本に向けても数々のアジャイル導入に関する助言をおこなわれている、サム・グッケンハイマーさんが2016年当時に言及したところによれば、「2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると31%が導入済みに過ぎず、明らかに遅れをとっている」とのことです。年数にしたら「5年は後れを取っている」、とも言及されています。かつ彼は、以下の衝撃的な発言もおこなっています。

「ウォータフォールは一切メリットがないので止めておきなさい」
※マイクロソフト関係者の記事よりサム・グッケンハイマーさんの(議事録上の)発言を引用。http://simplearchitect.hatenablog.com/entry/2016/06/20/080807

何と大きく出たことか、というのが第一印象です。というのは、ウォーターフォールもアジャイルも、所詮は人間が集団でシステムを作るための枠組みというか仕組みであって、まともな人間がやればどちらもまともに進むし、まともでない人間がやればどっちにせよダメになる、と私は思っているからです。

システムの開発や導入とはいえ、基本的にはヒト依存の部分は大きいと(まだ)思っています。前述の彼の発言は、「まともな人がまじめにやっていても、いずれはウォーターフォールは立ちいかなる」ということなのか?それとも、過去においては有効だったけれども、近年はダメだ、ってことなのか?ここでは一旦「近年だからこそウォーターフォールはダメだ」という仮説を立てて、その理由を探求しくことにします。

 

環境の変化が激しく、早いこと

過去と違う点。。。まず浮かぶのが、スマホやタブレットといったデバイスの進化。それから、AWSやSFDCに代表されるような、クラウドの台頭。これらは、勝手にバージョンアップしたり、仕様変更してきたりする。デバイスやクラウドといった「外的な存在」、つまり「自社で作りこんでいるものではないが故に、その変化をコントロールできない存在」が、今の時代はすごい勢いで増えている。しかも、変化のサイクルは、過去よりも相当早い。これだけでも、現代のシステム開発が、ウォーターフォール型だと対応できない理由に、十分該当しそうです。

このことを端的に言えば、「不確実性が増えているから、長期的なウォーターフォール型開発はダメ」となります。開発対象以外の「外的な要素」、つまりウォーターフォールにおいては前提条件や制約条件で「変わらないこと」としていた要素が、平気でこちらの断りなしに変わってしまうという。ウォーターフォール型だと半年~1年、長いときには2年、3年以上になるようなプロジェクトも多く、日進月歩でテクノロジーやアーキテクチャが変化していく中で、時代に合わないやり方になってきているのは事実でしょう。

ウォーターフォールは途中の仕様変更が原則不可

さらに「ウォ-ターフォール型開発」では、全体が長期であろうがなんであろうが、システムプロジェクトの企画から始まって、①要件定義②設計③製造・テスト④リリースという工程を順に進むのが定石で、工程途中での仕様変更を原則認めないスタンスで進めていきます。このあたりも「ウォーターフォールはいまどきイケてない」といわれてしまう所以です。テクノロジーの中には、SNSやクラウドのしくみのように、半年とか1年単位でどんどん変わっていくものもありますから、ユーザー要件は「環境が変われば変わっていくものだ」という、「これまでの常識や思い込みの入れ替え」も必要になってきます。

従来型のPMOの仕事はどうなる?

で、ウォーターフォール型開発では重宝されていた「PMO」という仕事は、アジャイル型開発になるとどうなるのか?簡単に従来型の主な「PMOのお仕事」を紹介すると、①事務方(会議召集、会議室確保、議事録作成、入館証発行手続き代行、飲み会セッティング等)②プロジェクト計画立案支援(プロジェクト計画書、要員計画、コスト計画、WBSガントチャート、課題管理計画策定支援、等)③ドキュメント作成(②で合意した事象の可視化、各種報告書作成支援、等)④プロジェクト推進(進捗管理、品質評価、雇い主への報告支援、等)ってところです。

そのうち③ドキュメント作成は、アジャイルのイメージでは原則不要または少ない、とされていますが、ドキュメントの全くない集団行動というのはありえないですし、アジャイルでも要求事項を可視化したバックログや、スクラムマスターやプロダクトオーナー、開発チームなどを明記した体制資料などは必要となってきますので、まあ必要でしょう。①も②も、アジャイルだからと言って(少なくなることはあっても)なくなるわけではないことはおわかりでしょう。

アジャイルでは、「開発者を含めて、参加するメンバーすべてが自律的で前向きであれ」とされていますが、これが本当にできるのであれば、それこそウォーターフォールでもできているわけで、それができていないことが多いので、PMOが繁盛してきたわけです。「敵は本能寺にあり」ではないですが、本当の敵は、実はウォーターフォールではなくて、社風とか文化とか、業界の体質とかいう、「空気」や「社会」にカテゴライズされるような、得体のしれないものなのかもしれません。いや、そっちでしょう。ということで、ウォーターフォール型開発プロジェクトにおいて、「ザ・すきま産業」であるところのPMOは、アジャイル型開発プロジェクトになったら、もしかしたら「スクラムマスター支援」とか「プロジェクト推進」とか、名前は変わるかもしれませんが、おそらくニーズとしては消えないもの、つまり「PMOのお仕事はなくならない」、と思われます。今日はここまでです。頑張っていきましょう。それでは、皆さんさようなら。