プロジェクトマネージャがリリースサイクルが短くなったときに最初に考えないといけないこと

プロジェクトは、日々、短くなるばかりです。これはプロジェクトのスポンサーへのビジネス上にある様々なプレッシャに由来するものです。
短い期間でシステムをリリースしたい、というスポンサーの要求は、所謂、SIプロジェクトばかりでなく、維持管理プロジェクトにも影響を与えています。

では、プロジェクトマネージャ、或いは、プロジェクトメンバであるアナタがその事態に直面したときに何を品けれならないのでしょうか。

ちょっと待って。これから話すことがアプリケーション開発だけの話だと思った？いいえ、インフラ基盤のプロジェクトにだって、短納期、低コストの要求はあるものです。どちらかというと、アプリケーションの方に予算が多く振り分けられしまい、インフラ基盤の方には余った予算で何とかしてよ、と無茶振りされていることの方が多くないですか？そんなインフラ基盤の人にだって、多分、参考になると思うよ。

プロジェクトのリリースサイクルが短くなった！
いや、日に日にプロジェクト期間が短くなっていませんか。短いですよねー。多分に、モバイルアプリなどサイクリックにアプリをアジャイルなシステム開発手法を取り入れてリリースすることを短納期化した成功事例が増えたことも一因にあるのではないかと思います。アジャイルも日本に根付いて10年ほどになりましたし。

スポンサーである顧客は、デフレ対策とグローバル化をセッセとしたいので、SIerに「早よリリースしてよ。」と彼らのミッションを達成するために言うのも、彼らの立場からしたら道理があるものです。
＃顧客も大変ですねー。

リリースサイクルが短くなったら最初に意識すること
プロジェクトのサイクルが短くなったとき、プロジェクトマネージャは、何よりもコレを意識しないといけません。

“自分のタイムスパンを短くする”

何を言っているかというと、例えば今まで6ヶ月でプロジェクトを回していたら、6ヶ月なりの時間軸で物事の確認や判断をしていたと思います。それを

“短くなった時間軸で考えなさい”

ということです。新しいプロジェクトが3ヶ月でリリースすることになったら、今までと同じタイムスパンで薦めてはいけないよ、短いタイムスパンで、すべての物事を考えるように頭の中を切り替えよ、ということです。

今までなら、メンバの進捗の確認は週1回でよかったかもしれません。でも、これからは週1回では、遅れに気付いたとき既に手遅れです。

プロジェクトを成功に導く要因の一つに時間があります。高いリスクが発現しても、プロジェクトの期間があれば、製品不具合なら修正パッチのリリースをリクエストし、リリースされることをトレースして、適用すれば良いわけです。

しかし、プロジェクト期間が短ければ、修正パッチのリリースをリクエストしても、リリース前に出てくるか分かりません。多くの製品は、間に合わないでしょう。その製品不具合が主要機能でワークアラウンドで回避策も見つからなければ、プロジェクト自体が頓挫することになります。

今までの価値観や判断基準は、すべて、一掃するつもりくらいがいいです。それは、プロジェクトマネージャであるアナタだけではなく、プロジェクトチーム全員に浸透させなければなりません。

リリースサイクルが短くなるときに考える対策は
時間に対する価値観を変えたほか、何を考える必要があるでしょうか。今までの、これからのプロジェクトより遥かに長い期間のプロジェクトでは、プロジェクトの中では、さまざまな暗黙の作業が見えない形の固定費として内在されているものです。しかし、これからキャリーする“短いプロジェクト”では、時間と人的リソースは切実な問題です。リリースに必要なプロセスはやらないといけませんが、その作業で価値が生まれないなら、本当に必要かどうか見直す契機でもあります。

注意しなければならないことは、作業で付加価値を生まないことは止めよう、ということであって、余裕を削りなさいといっているわけではありません。

同じチームか
プロジェクトの人的リソースは、顧客に届けるためのdeliverable(＝成果物)を作るためのプロセスをチームでまわすために多く割いていることに気付いているでしょうか。
幾つかのプロジェクトを同じチームで経験してきたなら、プロジェクトチームの中の“意思疎通”するために費やされるリソースは、これまでのプロジェクトでメンバの関係に構築されていることから、直近のプロジェクトより多く掛かりません。

しかし、プロジェクトメンバの一部でも代わると、新しいメンバと既存のメンバとの間で関係を再構築するために、新規の人的リソースを割かなければなりません。

プロセスの点検
以前のプロジェクトのリリースでは当然のように出来ていたことが、これからのプロジェクトでは出来ないかもしれません。今まで6ヶ月あった時間が3ヶ月になっても、同じシステム開発プロセスのまま採用すると自分で自分の首を絞める可能性が高いです。ただ、契約自体は、前の6ヶ月のプロジェクトからシームレスに3ヶ月に変わることも考えると、まったく新しいシステム開発手法を取り入れることは博打であって、失うものはあっても得るものはないでしょう。
大きく変えるのではなく、システム開発手法をフレームワークととして捉え、その中の運用を少しずつ継続的に変えていく手法にしたほうがメンバのアレルギを抑えられるほか、確実に実行できます。

正味のワークロードの把握
SIプロジェクトでも維持管理プロジェクトでも、リリースする機能の設計、開発、テストに費やすことが出来る時間はそれほど多くありません。それでも、以前の6ヶ月のプロジェクトで費やせるリソースの面積は、3ヶ月のプロジェクトの面積より遥かに小さいデス。

プロジェクトマネージャは、これを視覚的に実感しないと、プロジェクトメンバに今までとおりのつもりでそれ以上の作業負荷を掛けてしまいます。これは、WIP(Work In Progress)を理解していないことに由来するものです。今までは、長い時間の中で、恰も並行して作業を流せていたようなことも、短い時間の中では、並行して流している間に時間切れになるよ、という危険性を孕んでいることを識別しなさい、ということです。短いタイムスパンになったからこそ、

“一つひとつの作業に集中させて、完了させるように導く”

ことを意識しなければなりません。

維持管理ならプロダクトシステムとして稼動しているシステムのトラブル対応に幾ばくかリソースを割くことも意識しなければなりません。そこまで、日頃のオペレーションを思い巡らし、正味の作業時間を把握しておかなければ、維持管理をしつつ、プロダクトシステムにトラブルが起きてそちらにリソースを投入した途端、次期リリースの機能は、約束の日に開放することが難しくなります。

これは、期間が短くなったことで、リリースできる機能の量も相対でリリースできるものではなく、必要な固定費の上に限られたスベースでしか確保できないものだということを顧客と共有するためにも必要なことです。