頻発する納期遅延や予算オーバー、障害発生はプロジェクト管理の失敗に起因す ある部分が大きく、 その対応は急務だ。本章では、プロジェクト管理の具体的かつ現実的な改善プランを解説いたします。

我々ITエンジニアの世界は 武士が道場で稽古をするように、日々 技術力向上の研鑽を積むことはもちろん大切だ。しかし、組織的に有効な 「プロジェクト管理」を実践しなければ、1人1人の能力と努力が効率良くア ウトプットに結びつかない。

IT業界も一大産業に成長し、これからは企業レベル、個人レベルそれぞれ に競争が厳しくなることが予想される。 新しい競争の時代に打ち勝つためには、個人の技術を超えた科学的な手法が必要なのだ。 「自分はこんなに努力 したのにプロジェクトは失敗で･････」という空しい経験を繰り返さないため にも、「プロジェクト管理」 というものを “先端技術” としてきちんと理解 して実践することにしよう。

 

現状をもっと厳しく認識する

プロジェクトとは、 「ある目的を実現するために一定期間チームを組み、 「活動すること」だ。 システム構築の仕事はルーチンワークではないし、 共同 作業となることが多いため、基本的にプロジェクトという形態で行なわれる。 プロジェクトの “成功” とは、 「決められた期間と予算内に、 目標どおりの 効果をもたらす品質の良いシステムを構築すること」である。 つまり、 納期 遅延や予算オーバー、 障害の発生などがあれば、 程度の差こそあれプロジェ クトは“失敗” ということになる。

ここで目を閉じて、 みなさんのまわりで最近実施されているプロジェクト を思い浮かべて、それらが成功しているかどうかを考えてほしい。 「仕様変 更が多くて納期が1ヶ月遅れた」 「仕様が膨れて予定よりコストが掛かった」 「協力会社の品質管理が甘く、 カットオーバー後も障害が発生している」 どの問題はあるものの、 「概ね成功しています」と胸を張って言える方も多 いかもしれない。しかし、 原因が客先にあろうが協力会社にあろうが、厳しい見方をすれば これらは“成功” とは言えない。 我々IT業界には、このような失敗を 「仕方 のないこと」と暗黙的に認める “ぬるま湯” 的な風潮がある。

その認識の甘さは製造業と比べれば明らかだ。 例えば自動車産業では、 新 車が予定の日に発売されなければ大問題となるし、少しでも欠陥があればリ コールの対象となってしまう。 また、果てしなきコスト削減の努力は、我々の大雑把なコスト意識とは比べるまでもない。 この大きな差は、単に仕事の 性質が違うために生じるものではない。 IT業界と比べれば十分に長い歴史の 中で、品質向上、コスト削減という創意工夫を積み重ねて今日の姿になって いるわけだ。

「自分たちの国際競争力がまったくない」という現状は本当に悔しい限りだ。でも、あきらめてはいけない。 家電や鉄鋼、 自動車など他の分野でも、圧倒的な劣勢の中から必死のがんばりで逆転してきた。

IT業界が現状から巻き返すための切り札は「プロジェクト管理」 ではないかと考える。 1つの目的をチームワーク良く成し遂げるというのは、 本来は日本人が得意の分野のはずだ。 製造業を見習い、 1人1人が現状をシビアに客観視できるようになれば、きっとそこからチャンスが生まれるだろう。

プロジェクト管理力を向上させるには

自分たちのプロジェク ト管理力を向上させるために、 表1のような 「7ステップの強化策」 を描いて みた。 この7ステップの取り組みは、1回やればいいというものではない。 図1 のようなPDCAサイクル (後述) をまわし、継続的に改善してゆくという取 り組みなので、 定常的な実施体制が必要だ。 以降では、各ステップの強化プ ランを掘り下げながら見ていく。

                                                                   表1: プロジェクト管理力の7ステップの強化策

 

 

ステップ②:改善計画

さて、 自分たちがきちんと管理できていない箇所を認識できたら、 そこを 強化するための具体的なプランを立てよう。 表4は、ステップ①で洗い出し た問題点に対して改善プランを整理したもののサンプルだ。 ここでのポイン トは、問題点に対する対策だけでなく、 その対策を実現するための具体的な ツールの作成も計画する点だ。 ツールの作成担当者も決めてしまい、 作成期 も明記すれば、迅速にことが運ぶはずだ。「プロジェクト計画書を作成していない」ということを問題 点として掲げ、その対策として 「プロジェクト計画書の作成を義務付ける」 という方針を立てている。 そして、それを実現するための具体的ツールとし て「プロジェクト計画書」のテンプレートを作成することにしている。

「見積もり算出基準がはっきりしていないので、人により大きく見積もり がぶれる」という問題点に対しては、「開発ツール単位の見積もり算出基準 を作成する」ことと「開発終了時に実績をフィードバックして基準を見直す」 という2つの対策を立て、「見積もり基準書」 と 「工数実績報告書」 をテンプ レートとして作成する。ステップ② ではこのような表を作成して、 プロジェクト管理力強化のために何をなすべきかを具体的にする。

 

ステップ⑤:リーダー育成

さて、ステップ ④で普及促進プランを策定し、あとは実行あるのみだが、 最 初に行なうことは管理者の育成である。 組織管理のところで「リーダー教育を 「行なっているか」というチェック項目があったが、今のIT業界ではきちんとし たリーダー教育を受けずにプロジェクトリーダーになっている例が多い。

プロジェクトリーダーに対する教育、啓蒙活動では、単に管理手法を説明 するという技術面だけではなく、 なぜプロジェクト管理が大切かというメン タル面も重要なのだ。 半期に1度くらいのペースで、 新任のリーダーと表2の 実施状況の悪いリーダーに対して、リーダーの心構えとやるべきことを伝え るようにしよう。

 

ステップ⑥: 実行

さて、リーダーもその気になって、現場のマネージャもやらなければとい う意識が芽生えた。 あとは実行あるのみだ。 ステップで計画したとおりの スケジュールで地道に根気良く実施してほしい。

ここでのポイントは「毅然として」 「粘り強く」 ということに尽きる。現 場から不平不満があがったり泣き落としが入ったとしても、メジャーリーグ の審判のように毅然とした態度で接することにしよう。 正義はこちらの手に あるのだから、安易な妥協は禁物だ。 それが相手のためと信じ、 自信を持っ て説得し続けてほしい。

 

ステップ⑦: 評価・レビュー

プロジェクト管理力は間違いなく企業力となる。 オラクルマスターの資格 取得者が多いとかJavaエンジニアがたくさんいるとか、とかく数値で見える ものに目を奪われがちだが、本当の強さとはプロジェクト管理力のような 合的なものだ。

では、企業のプロジェクト管理力とはどういうものなのだろうか。もちろん、PDCAサイクルを回しながらブラッシュアップされたテンプレートや管理手法が武器になることは明白だ。

しかし、本当のところは、管理サイクルをスパイラル状に絶えずまわすことにより現場部門の意識が高まり、効率的なプロジェクト管理ができて行く という過程が、真の強さにつながるのだ。

 

まとめ

プロジェクト管理に関する話は当たり前のことばかりなので、正直なとこ ろ「そんなこと知っているよ」 という感想を持つだろう。 「飲みすぎは身体 に悪い」 とか 「夜更かしはやめましょう」 などというのと同じことだ。 しか し、その当たり前を誰も実践できていないことが深刻な問題なのだ。 そこで 最初に、 「プロジェクト管理とは」 というよくあるテーマではなく、「どう やったら組織のプロジェクト管理力をアップできるか」というアプローチに 重点を置いて話をした。

NALでは、現在プロジェクト管理能力を向上するために「プロジェクト管理入門」について社内で授業を行なっております。

詳しくはNALまでお問い合わせください。