例えば、
・PJオーナーの本当のニーズ誤認
・納品物を事前に取り決めせずに契約
・曖昧な要件は設計しながら、、、と開始
・見積もりを誤る
・大雑把なWBSで作業管理
・品質計画を立てずメンバーに依存
・リスクを識別せずに問題発生時に初めて対処
・・・
挙げれば切りが無い程です。

会社の仕事で、庶務、経理、営業、・・・仕事の内容については
大体どこの会社においても同じであることが多く、

その職務の経験において転職しても活用する事は簡易です。

しかしながら、プロジェクトマネジメントに至っては、その業務を
定義した（整理された）ものは、長い間存在していませんでした。

業務が定義されていないと言うことは、企業によってその考え方が
まちまちで、プロジェクトマネージャはその知見・経験が豊富で
あっても、他社で担当した場合も同じように能力を発揮する事は困難です。
しかし、全ての会社のプロジェクトマネジメントの定義が同じで
あった場合はどうでしょうか。
マネージャはどのプロジェクトにおいても成功体験・失敗体験を
活用でき、経験を積む毎にその精度が増していくのではないで
しょうか。

プロジェクトマネジメント業務に新しい考え方が入ってきたとしても
それをPDCAで実行し、良い結果も悪い結果も知の共有にて新しい
マネジメント業務として取り込んで行けば、より高品質のマネジメントが
可能となって来るはずです。

ソフトウェアの開発においては、私がこの業界に入る前から、
テンプレートによる開発、フレームワークを活用した開発、
開発ツールを用いた開発などが盛んに行われて来ています。

設計書もテンプレート化されているのは普通でした。

これらは、開発の難易度を下げ、開発効率を上げ、成果物の
品質を高くするのにとても貢献しています。

プロジェクトマネジメントにおいても同様の事が言えるのでは
無いかと私は思うのです。
つまり、マネジメント業務の目的・目標・責務・権限の明確化、そして
マネジメント業務のフレームワークによる定型化です。
決して独自方式を定型化するのではなくです。

そうすることで、Jr.クラスのマネージャでもSr.クラスのマネジメントに
近い成果を出すことが出来るようになりますし、教育・訓練、指導に
要するコスト、品質、が向上し、期間の短縮も図れます。
つまり、利益が出安くなる、伝家の宝刀となりうると私は思うのです。

管理する側がフレームワークによって定型化されたマネジメントを
一生懸命やっても、管理される側がいい加減だと期待する結果とは
なりません。私がマネジメントしている際も、
・協力的なメンバー　<->　非協力的なメンバー
・自己管理できるメンバー　<->　できないメンバー
・マネージメント業務を知っているメンバー　<->　知らないメンバー
など、メンバーにもプロジェクトマネジメントを教育・訓練し、
マネージャの指示が理解でき、マネージャが欲する情報を適時提供
できれば、プロジェクトの一体化が図れる様になります。

マネージャだけが空回りしても良い結果は得られにくいと感じたのです。

つまり、プロジェクトマネジメントとは、ステークホルダー全員が
マネジメント業務を理解し協力して行くことがとても重要です。
お客様しかりです。

つづく

それぞれ、いつまでに何をするという目標を持っています。

プロジェクトとは、有期でその期限に必ず目標があります。
目標を達成する為に、チームメンバー、ステークホルダーがそれぞれの任務を
遂行します。

特に私が生業としているコンピュータシステム開発業界においては明確です。
プロジェクトには必ず、開始があり、終結があります。
プロジェクトの遂行に当たっては、WBS(Work Breakdown Structure)があり、
課題管理表があり、作業状況の見える化が図られます。
新人クラスであっても、ベテランであっても、WBSの作業定義に従って指示された
作業を遂行して行きます。
多くの失敗（或いは、火の吹いた）プロジェクトは、この当たり前の事を、
技術者の感や裁量に任せ、期限遅れになったり、違う方向に進んでいたり、
メンバー間の作業内容の同期がとれていなかったらり、それらの軌道修正を
余儀なくさせられます。

そうして、プロジェクトマネージャって言う仕事は、いつも大変で残業が多く
責任ばかり押し付けれられて、「もー、やだ」となってしまう。

この原因の一つとして、プロジェクトマネージャ自身がそれぞれの感と経験で、
マネジメントを行っている事も、プロジェクトが計画通りに進まない事の原因
の一つではないかと思います。

しかし、今の世の中経験豊富な技術者は開発現場よりマネジメント能力が期待

され、「もーやだ」と言っても開発の技術者としてSE業務をアサインされる機会が

とても少なくなって来ていますから、わがままも言ってられないし、若い技術者に

混じってガリガリ開発できる体力なども少なくなっていますから、マネジメント業務

を希望するしか道がないのかもしれません。

要約すると、
・マネジメント業務が個人のやり方に頼りすぎている
・プロジェクトのWBSが適切な内容ではなく、作業者の裁量や経験に
　任せられている。
・これらにより、プロジェクトの見える化ができていないので、
　プロジェクトの把握に手間取り、プロジェクトマネージャや会社が正しい
　意思決定ができなくなる
結果として、プロジェクトが破綻へと一歩一歩近づいていく。
最後は、人海戦術、プロジェクトメンバーの残業。。。。

一人減り、二人減り、もうーやだ。
となる。

殆どの会社では、会計部門、総務部門などの管理部門を有していると思いますが、

プロジェクトマネジメントを補佐する部門が有っても良いかもしれません。

プロジェクトマネジメントの定型化をやってみると分かりますが、
・如何にマネージャが独自の方法で行っているか
・部門や、お客様のタイプ、上司の考え方で、マネジメントの
　品質に対する考え方が違うか
・同音異義語、異音同義語が沢山あるか
など、これじゃーマネジメントの品質そのものを図るのも難しい。。。と。

納得がいくはずです。

ここで、提案してみたいと思います。
１．プロジェクトマネジメント業務をできるかぎり定型化する
　経験が少ない人や、経験豊富でも独自方法を使用する人たちでも安定した

　マネジメント結果が得られるようにする

２．WBSややリスク管理などは、経験知を有効活用する。

　各社運営しているプロジェクトは、それぞれ多少の違いは有っても、

　同種のプロジェクトであれば、知の横展開を図る

自社がプロジェクトのオーナー企業となっているのであれば、

尚更チャレンジして見て欲しいと思います。

つづく

今度こそは、ちゃんと続けてみよう！
プロジェクトマネジメントについて思いついた事を書いてみます。

PMBOKと言うと、最近はPMPの資格保持者も増えかなりメジャーな資格に
なって来ていますが、現場で使用しようとしてもなかなかうまく行かないですね。

開発現場において、昔は組織張が予算管理して、リーダが進捗管理して、
様々なテンプレートを使用しウォータフォール型でそれなりに品質担保したり、
効率化を図ったりしてきた。

今はと言うと、スパイラル開発や、アジャイル開発などを多くの企業が
取り組むようになり、組織力～＞個の保有能力が重要視されるように
なってきていると感じるのは自分だけでしょうか。

最近の開発案件をザーッと眺めると、
マーケティングが３．０の動きに変貌していく過渡期の現象として
ソフトウェア開発のPJも引きずられている気もします。

アジャイルの１機能の開発も含めてどんなに小さなプロジェクトであっても
次の一手の意思決定する為に、プロジェクト管理技法を使って現状把握する
事はとても重要であると改めて認識します。

一歩間違えると破綻の道へ。

プロジェクトのメンバーの多くは、能力不足や失敗原因を認めたくない為に、良い報告をしたくなる。
更に、悪い情報を出したがらない。
プロジェクト全体から見ると、誰がと言う事は問題ではないのであるが、
人の心情とは難しいものである。

正しい意思決定ができる様にプロジェクトのメンバーはあるがままを
報告すべきであると思うし、マネージャはその様な仕組みを設けておく
必要があると思う。

自分が経験した最大の失敗は、自分でマネジメントをせず、
PJのリーダとして開発を任せていたエンジニアにマネジメントを
任せてしまった事です。大失敗でした。
元々かなり無理を承知で始めたプロジェクトでありましたが、
リスク管理や、WBS、コスト管理、機能設計など基本的な事が
本当に悲惨でした。

また、その様な人に限って悪い情報を表に出したがらなかったり、
重要なキーとなる情報を抱え込んだり、問題が本当に大きくなるまで
詳細を把握できないと言う状況でした。結果として大赤字です。

自分がマネージャをやっていればこんな事にはなっていないのに。。。
終わってから悔やんでも仕方がないですが。

少なくても、誰がマネジメントをするにしても、マネジメントのルール化、
テンプレート化などで、個人の意見ではない形で運用する事が大切である
事を改めて認識しました。
マネジメントを上手く運用する事は、お客様に対しても様々な条件を
出さなければならない状況になるかもしれません。
それによって、PJが成功すると言うことは結果的にお客様の利益拡大に
繋がる重要な事と思う。

終わりよければ全て良し。

つづく