top of page

プロジェクト管理

​

企業内の活動の全てが「プロジェクト」と言っても過言ではありません。つまり、プロジェクトの運営状況が企業の業績に影響を与えると言えます。

特に、システム導入に関するプロジェクトは、投資額が大きいだけではなく、失敗すれば大きな機会損失を被り、中長期経営戦略達成に打撃を与えることになります。

プロジェクト推進・管理に関する重要な点を記載します。

​詳しくお知りになりたい場合は、お気軽にご相談ください。

​

​プロジェクトは最初が肝心です

プロジェクトの始まりは、目標を達成するために行わなければならない仕事の内容を明確化し、管理できるサイズに分割し、その前後関係を明確にし、担当者を決め、順番に完了を確認する作業を行います。
​
ここでのポイントは、目標（ゴール）と期間、投入できる人材などを明確化することです。これが明確でないと、仕事内容の整理や分割、タイムスケジュール作成が「絵に描いた餅」になりかねません。明確化するには、決定権者を含めた関係者全員で協議する必要があります。
​
​プロジェクトの全体像が明確になった時点で、関係者全員が参加する「キックオフミーティング」を開催し、プロジェクトオーナーが「プロジェクト開始宣言」を全員の前で行い、責任者のやる気、意気込みを示します。（ここを軽く見るケースが散見されますが、心を一つにする大切な会議です）​
​

​コミュニケーション計画を立てる

プロジェクトの本質は、コミュニケーションです。
プロジェクトは、必ず課題が発生し、それを一つ一つ解決しながら完遂させます。そのためには、円滑なコミュニケーションと階層別意思決定機関が必要になります。
​
プロジェクトのサイズや進捗状況によりますが３階層程度の会議体が効率的であると思います。
​
一番小さな会議は、担当者グループ会議（ミーティング）です。朝会でも終礼でも良いですが、短時間、かつ、有意義な会議にするために、連絡事項、報告事項、相談事項を分けて進捗します。報告事項は、文書化することをお勧めします。口頭では忘却のリスクがあり、重大な課題を見逃す場合があります。前日の課題を責任者がチェックして、担当者に確認するという方法が良いでしょう。
​
二番目は、ミドルクラスの管理職を含む、プロジェクトの責任者会議です。サイクルは週間が良いでしょう。日々発生している課題や、未決事項を整理して、ミドルクラスの管理職が発表し、意思決定します。また、会議で発見された課題を文書化し、解決責任者と期限を明確にし、毎週進捗を管理します。課題の種類により、件数管理までとするか、明細単位とするか決めます。ここで決めた報告方法は、最上級の経営者会議への報告粒度となります。
​
三番目は、経営者会議です。本来、プロジェクト推進責任者と経営者との会議ですが、できれば、それに加えて、ミドルクラスの管理職と受託ベンダーの上位職（現場の責任者と本社の部門役員など）の参加を求めると、即決できる、実効性のある会議となります。
特に、進捗が悪い場合、組織を全体でフォローする体制を作ることもできます。
​
このように、プロジェクトをスタートする前に、どのような会議体を定義して、いつ、誰が参加するか決めておけば、仮に問題が発生しても、経営に対して説明する場が確保でき、円滑に解決できるようになります。​
​

進捗に気を配る

プロジェクトは、人間が行う仕事の積み重ねです。
だから、当初の予定通りに進捗しない事を、常態であるとの認識が大切です。
 
進捗には２つのリスクがあります。一つは想定よりも早く完了するリスクです。
仕事をアサイン（割当）られて、実際に着手してみると、思ったよりも簡単に完了してしまう場合があります。それが、本当に支持通りに行って完了した（課題見積もり）なのか、支持を取り違えて違う事を行ったため早く完了したのかを見極める必要があります。
 
その逆で、想定より遅れるリスクです。仕事のアサイン内容が、設計者（指示者）の想定を超える事務量であったり、作業者の勘違いで困難な道を歩んで遅れているのか見極めなければなりません。
 
いづれの場合も、日々のミーティングで、顔尾を突き合わせて（または、メールなどで）こまめに確認するしか方法がありません。毎日コーディングのライン数を報告させたりする技法が過去にはありましたが、現在は客観的な評価基準を設けることが難しいため、担当者の感覚と成果物の状況を現場責任者が直接確認するしかありません。​
​
また、テストケースの内容を確認すると、かなりの確率で、業務の理解度が分かります。また、テスト結果で発見された修正箇所の数で、プログラミング技術や論理的な思考の強弱が判断できます。
​
​毎日の進捗は、マスタースケジュールの中に収まっているのか、いないのか。収まっていない場合の他部門への影響はどの程度か。キャッチアップできるのか。などに気を配らなければなりません。
​
​

エスカレーションが大切

プロジェクトを推進してゆくと様々な問題、課題が発生します。
問題が発生する事は、状態であり、解決することが当たり前の仕事と捉えなければなりません。
​
問題は、プロジェクトが進捗している証です。何にも問題が発生しないプロジェクトは稀だと思います。逆に極端に課題や問題が少ない場合は、テスト方法や進捗に重大な問題が潜んでいる可能性が高いと判断すべきです。
 
課題には、本人が頑張れば解決するものと、本人の努力では解決できないものがあります。
これを明確に判断しないと、プロジェクトが大幅に遅れる原因となります。この判断は、現場の責任者が行う大切な仕事です。そして、その責任者が自分が任されているリソースでは解決できないと判断したら、速やかに上席にエスカレーションしなければなりません。
 
仮に誤報であっても問題は、ありません。それより、リスクを感じているのに何も行動を起こさない管理職は、管理職として不適切です。誤りを恐れず、報告し、みんなで状況を確認し、最善策を執るという職場文化が大切です。
​
​

立場を超えた協調・マネージメント

問題は、立場の違う関係者と利益相反する場合が多々あります。場合によっては、特定の問題がネックとなり、プロジェクトが立ちいかなく場合も想定されます。
​
そのような場合、現場と委託側・受託側の経営層の狭間にあるプロジェクトマネージャーは何ができるかですが、逆に、プロジェクトマネージャーでしかできないことが沢山あります。
​
「開発費用が当初想定より○○円超過しそうです。了解いただけなければ開発を先に進めません。」と営業担当から話があった場合、そのまま経営に「○○円の決済をお願いします」とエスカレーションすべきでしょうか。
​
私は、その前に行うことが山のようにあると思います。まず最初に「なぜ、先に進むことができなくなるまで相談がなかったか」をベンダーに説明してもらいます。次いで「○○円の根拠」を聞きます。また、その増額の原因になった内容を聞き、原因を作った人に事情を聴きます。
​
ここまで来ると、予算超過の理由が明確になり、また、ベンダー側の対応のまずさも浮き彫りになります。その様々な要因を「因果関係」を明確にして、ベンダー、依頼元、両方が納得できる着地点を見つけるのです。
​
​文書で表すのは、難しいですが、要は、常にプロジェクトの異変を探知するアンテナを張り、できるだけ、プロジェクトの内容を理解し、関係者の状況を把握しないと、不測の事態に対応できないということです。
​

プロジェクト運営に定石あり

「プロジェクト運営に定石あり」と書きましたが、それは、経験と実績から得られる定石であり、教科書通りではうまくいきません。
 
小さなプロジェクトでも、今まで書いてきた観点からプロジェクトを立ち上げ運営し、悩みながらでも完成して、成功体験を積み上げる事が重要ですが、最初は指南役がいた方が遠回りすることがなくなります。
​
​社内にプロジェクト運営できる人財を育てるためにも、新しいプロジェクトを立てる場合には、ITCの活用をご検討して頂ければ幸いです。
​
​
bottom of page