日米でのProject Manager のプライオリティの違い
12月に研修を受けて、認定スクラムマスターを取得したことは以前のブログでも話したとおりです。私は一応、Project Management経験は10年以上、スクラム開発経験も4年以上はありますが、ここ数年はビジネス開発や "Product" Managementがメインでした。このタイミングで「開発プロジェクトを効率よく回す」ということについて復習の機会が得られてよかったと思っています。研修を受けて改めて感じるのは、プロジェクト運営というのは、経験や印象に基づくArtistic な面と、データや分析に基づくScientific な面と、両方使ってうまく回るんだよなぁ、ということ。我々が開発しているSleeek も、たぶんScientific な面には貢献できていると思うのですが、もっとArtistic な面にも貢献できるように製品開発しないといけないと思いました。なかなかチャレンジングなことではありますが。
さて、この研修を通じて、もう一つ再認識した重要事項があります。表題にもある「日米でのProject Manager のプライオリティの違い」ですね。これは、正確にはアジャイルとウォーターフォールの違いと言えるのですが、USではほとんどのソフトウェア開発プロジェクトは、全面的、あるいは部分的にアジャイルプロセスを導入していることを鑑みても、日米での違いと言っても言いすぎじゃ無いんじゃないかと思っています。まずはScrum Master 講習で配られたテキストにもあった、以下の図を見てください。
一部、私の下手な字でのメモがありますが、解読いただけると助かります。図で書かれていることは
- Scope と Time & Cost はトレードオフの関係にある
- 従来手法(Plan Driven) では、Scope を固定し、Time とCost を変数(Variable)として取り扱う
- 対してAgile (Value Driven) では、Time とCost を固定し、Scope を変数として取り扱う
ということです。どうですか？これはスクラム開発では基本の「キ」にあたるものなので、Scrum Master であればほぼ誰でも知っていることなのですが、ソフトウェア企業のPMや経営陣を務めてらっしゃる方にとっては、正直「厳しい！」と唸ってしまう方も多いのではないでしょうか。私はこれまで、Sleeek の開発を通して日米で数多くのPMやSMにインタビューしてきましたが、日本では、スクラム開発を採用している企業であっても"Scope" を堅守する意識が非常に強いと思います。これは、「コミットした機能の開発は全てやりきろう」という強い責任感の裏返しともいえます。しかしながらアジャイルプロセスにおいては、リリース時期や投入するリソースは変えず、真に必要な機能にフォーカスする。逆に言えば「いかにやらないことを決めるか」が重要になります。
日本では、多くのソフトウェア開発プロジェクトがアウトソースされていることが、この問題に更に拍車をかけています。私自身、ソフトウェア開発サービス、いわゆる「受託開発」でプロジェクトを行ってきたのでその辺りは痛いほどわかります。いわゆるアジャイルやスクラムというプロセスは、受託開発とは決定的に相性が悪いんですね。簡単に言えば、プロジェクトを始める前に契約書に記載されている納品物の記述にガチガチに縛られてしまうのです。しかしながら、ソフトウェアの開発というものはそもそも見積もりが難しいものです。開発期間は本来、「だいたいxx日からxx日の間」などと幅をもってしかるべきであり、「開発期間は xx日です」と開発期間や完了日が固定されてしまっているのは、見積もりというよりはむしろ目標というべきものです(あるいは必要以上にバッファーが含まれているか)。もし開発プロジェクトにおけるTime, Cost, Scope の全てを動かすことができず、必ず完了日までに決められた機能開発を全て完了することを義務付けられた場合どうなるか。いわゆる炎上プロジェクトとなり、リソースの追加投入でなんとかしたり(Cost が超過して開発側は赤字)、最も大事なソフトウェア品質を犠牲にすることになります。発注側、開発側、どちらも幸せになれない結果となってしまうでしょう。。。
では、そのような「受託開発」において、アジャイルプロセスを採用するにはどうするか。簡単ではないですが、発注者やその他のステークホルダーを開発プロセスに巻き込むことです。発注側、開発側は、スクラム開発のロールで置き換えればそのままProduct OwnerとDev team の関係になります。半年や一年のプロジェクトであっても、最小の開発期間を1週 or 2週の「スプリント」と呼ばれる単位で区切り、スプリントの最後にはProduct Owner (ここでは発注者)に対してそのスプリントの成果をレビューしてもらいましょう。それにより、開発チームが発注者の描くBig Pictureに沿って動けているか、常に確認できます。また、プロジェクト開始時点ではわからなかったリスクが顕在化した場合、Time やCost、さらになにより大切な「品質」を保つため、どの機能を諦めるか、早めに議論ができます。
改めて強調しておきますがScope の縮小は「逃げ」ではありません。Product Owner とDev team が一丸となって、プロジェクトの成果として何が最も重要なのかを常に考え、タスクの優先順位を決め、最優先開発項目を高い品質でリリースすることで、ステークホルダー全員にとって好ましい結果を得ることができます。Time やCost を動かさず、Scope をUpdate するアジャイル方式が、日本でさらに広まればいいなと思っています。
