新規要素の多いプロジェクトでは、変動を前提とした“やわらかい計画”を立てる必要がある。それには、計画からのズレを即座に検知・共有する仕組みが不可欠だ。ズレを補正するための計画変更を可能にするには、バッファーを計画に組み込んでおく。

Before
このプロジェクト、きっと失敗するよね

「最初に聞きたいんだけど、あなた、このプロジェクトが失敗するとしたら、どんな失敗だと思う?」

 総務システム更改プロジェクトの計画書案を差し出したプロジェクトマネジャー(PM)の田村玲奈に向かって、柳川グループ長が開口一番に言ったのは、こんなせりふだった。

 玲奈は、とっさに二の句が継げなかった。昨日、同僚の大下に言われた言葉が、脳裏によみがえる。

「今度のグループ長は、ガチガチの計画が嫌いらしいぜ」

 その点は、前任の吉瀬グループ長とは大違いだった。長くホスト基盤の仕事を担当してきた吉瀬グループ長は、「きっちり吉瀬」のあだ名通り、細部まで練り上げた計画を好んだ。玲奈がプリントアウトした計画書の原案は、いつも付箋だらけになって返ってきたものだ。標準化事項の確認や社内手続き、他部門宛ての作業依頼、説明会やプレレビューなど、どんな小さなタスクも見逃さず、きちんとWBS(Work Breakdown Structure)に組み込まれるまで許さなかった。進捗会議でも、1日の遅れが出ようものなら、原因と対策を執拗に追及されたものだ。

 今年になって着任したばかりの柳川グループ長は、対照的なタイプらしい。大下によれば、自社パッケージソフトの開発部門から転任してきた柳川は、アジャイル型の開発プロセスになじんでいるせいか、中長期的な開発スケジュールをあまり重視しないという。プロセスの緻密さよりも、プロダクトの実用性やプロジェクト目標の達成にこだわるタイプらしい。新し物好きで、前例や伝統という言葉が大嫌いなのだそうだ。

 であれば、新任上司の方針に合わせなければならない。そうは言っても、前の上司にとことん鍛えられた玲奈としては、これまでのやり方を簡単に捨てることはできなかった。柳川がこれまでやってきた商品開発とは違って、業務系の社内プロジェクトでは、フェーズごとの開始・完了基準がルールとして定められているので、アジャイル型のプロセスにはなじみにくいという事情もある。だから玲奈は、今日もA3判で数枚にも及ぶWBSを準備したのだ。

 ところが、柳川グループ長は、玲奈が苦労して作ったWBSには目もくれず、いきなり「失敗の要因」を聞いてきた。玲奈は、緊張して唇を湿らせた。「ええと、なるべく失敗しないように進めていこうと思っているんですが…」

 柳川グループ長は、励ますような笑みを浮かべた。「そうだね。でも、きっと失敗するよね」

 玲奈は、目を丸くした。このグループ長は、なんということを言うのだ。うまくいくように緻密な計画を立てているのに、失敗すると決めつけるなんて。

 玲奈が黙り込んだためか、柳川は慌てたように付け加えた。

「ごめんごめん。別にあなたの能力を疑っているわけじゃないんだよ。ただ、今度のプロジェクトは、初めてPaaS型のグループウエアを導入するわけだし、バックオフィスではRPA(Robotic Process Automation)ツールも検討してるだろう?読み切れない要素がたくさんある。なかなか、当初の計画通りにはいかないんじゃないかな。だから、最初から変動を考慮に入れておかないと」

「そんな。でも、そうは言っても、アジャイルプロセスで進めるわけにもいきませんよ」

 柳川グループ長はうなずいた。

「それは分かっているよ。あのね、ウォーターフォールとアジャイルの二者択一を求めているわけじゃないんだ。ただ、変動は計画の前提にしたほうがいいと言っているだけだ」

 変動を計画の前提にする、ですって?新任上司の要求に、玲奈はどうしたらいいか分からなかった。

アジャイル型やCCPMのアプローチ

 柳川グループ長は、前任の吉瀬さんが好んだガチガチの計画でなく、「やわらかい計画」を望んでいるようです。いったいどのような計画でしょうか(図1)。

図1●変動を前提とした「やわらかい計画」とは?
[画像のクリックで拡大表示]

 システム開発プロジェクトを進めるには、いろいろな方法論があります。最近のプロジェクトでは、いわゆるフェイズドアプローチ型のウォーターフォールモデルではなく、スクラムなどのアジャイル型や、CCPM(クリティカル・チェーン・プロジェクト・マネジメント)などのアプローチを求められることがあります(図2)。大雑把な言い方をすると、前者は要件や開発スコープの柔軟性を意識したもので、後者はプロジェクト計画そのものを柔軟に立案・トレースする手法といえます。

図2●やわらかい計画にするためのチェックポイント
[画像のクリックで拡大表示]

 アジャイル型では、仕様決定の権限を持つユーザーと一体になったチーム編成で、優先リリース事項を速やかに決定します。短い期間で実装と確認のサイクルを繰り返すことで、業務上求められる仕様を柔軟かつスピーディーに実現しようとします。

 CCPMでは、制約理論に基づいて全体のパフォーマンスを制約する要素を特定し、パフォーマンスを最適化しようとします。プロジェクト計画について言えば、「合流バッファー」という観点で、詳細な計画のあちこちに少しずつ潜んでいる期間バッファーを集約し、開発パフォーマンスを最適化しようとします。

 どちらも、プロジェクト立ち上げ時に全てのスコープやタスクを詳細化することは現実的ではなく、無理にそうしようとすれば遂行に無駄やムラが出るという考え方に基づいています。

 だからといって、開発プロセスをアジャイル型やCCPMに切り替えようとしても、諸般の事情から、すぐにはできないこともあります。そもそも、柳川グループ長が言っているように、各種の方法論は、本来択一式の関係にあるわけではありません。どれかが絶対的に卓越しているわけではなく、それぞれの特徴に応じて得手不得手があるだけなのですから、プロジェクトの特性によって、いいところ取りをして利点を組み合わせればいいのです。

 特定のプロセスモデルにこだわらず、プロジェクトの計画を「やわらかく」する方法を考えてみましょう。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら