#1-2 「プロジェクトマネジメント」とは？
プロジェクトマネージャー（PM）歴10年程の私。
まだまだキャリアとしてはこれからな位置にいますが、そんな私でも「プロジェクトマネージャーは問題解決屋さん」という持論があります。
一般的な定義として、PMの責任はプロジェクト目標を達成することにあります。
そして、問題の発生しないプロジェクトは、ほぼ存在しません。
プロジェクトというのは、限られた時間の中で、ユニークなモノやサービスを創る活動です。
つまり、
「それまでになかった所産」を、
「人の活動」を通じて、
「創り出す活動」です。
それまでなかった所産を生み出すのに、完全に見通しを立てることは困難ですよね。
未知なモノを生み出す、ということは不確実性が伴います。
不確実性からは、必ず解決すべき問題が発生します。
プロジェクト目標を達成するためには、ほぼ必ず問題やリスクをコントロールする必要が出てきます。
決められた正解を正しい道で確実に進む活動ではないので、想定外のことが起こります。
逆に、問題を解決する需要が必ず発生するから、PMという職業があるのだと、私は思います。
どの領域で問題やリスクが発生するかは、プロジェクトによって変わります。
なので、異なるプロジェクト同士で似たような問題が起こることがあっても、「全く同じ問題」は発生しません。
プロジェクトの目的が「ユニークな価値」なので、対応すべき問題もユニークになるのです。
職業としてのPMは、
・どんな業界の
・どの会社で
・何の所産を創造しようとしているか
で、求められる知識やスキル、アウトプットが変わります。
同じIT業界でも、金融システム開発とスマホアプリ開発では、開発工程が異なります。
また、同じスマホ業界でも、
・スマホ本体（ハードウェア）のシステム開発
と
・スマホアプリ（ソフトウェア）開発
だと、求められるアウトプットが変わります。
しかし、業界やジャンルは違っても、プロジェクトマネジメント（プロマ
ネ）として共通する考え方やセオリーがあります。
それを体系的にまとめたのが、『PMBOK（ぴんぼっく）』というプロマネの教科書的な本です。（アメリカで発行されています）
そして、プロマネのグランドセオリーは、基本的にどんな方にも参考になると思います。
「プロジェクトマネジメント」のナレッジ
プロジェクトマネジメントのセオリーは、人類が長い歴史の中で、プロジェクトの活動を通じて、多くの方々が「こうすれば、より良くなるのではないのか？」という仮説を検証を行ってきた集合体です。
そして、テクノロジーの発展と人の活動が変化に合わせて現在進行形で更新され続けています。
PDCAサイクル
プロジェクトマネジメントで出てくる考え方で、有名なセオリーは色々あるのですが、その中でも認知度が高いのはPDCAサイクルかな、と思います。
プロジェクトは、５つプロセスで構成されます。
立上げ
↓
Ｐ（計画）→D（実行）→ＣＡ（監視・コントロール）→ＰＤＣＡ……
↓
終結
「Check」と「Action」の日本語訳は色々種類がありますね。Checkは「振り返り」や「測定」、「評価」、Actionは「対策」や「改善」など。
『PMBOK』（プロマネの知識の体系書）では、CheckとActionをまとめて「監視・コントロールプロセス」と表記しています。
元々アメリカで発行されているので、日本で『PMBOK』の勉強をすると「翻訳の差異」にぶち当たるのですが、本質的な部分だけ理解して、あまり細かく覚えようとする必要はないと思います。
つまるところ「見直して、出来るところは改善していきましょう」という考え方です。
そして、このPDCAサイクルは回すことに意味があります。
最初から高い効果を出せる計画なんて、実際は最初からは出てきません。
なので、後から何かを変更する前提でどんどんサイクルを回すこと、具体的には行動することが大事です。
「行動することが大事」というのは、プロジェクトマネジメントにおいてでなくても、あらゆるところで説かれていますよね。
世界にも日本にも”行動が大事”という名言は沢山あります。
Action is the foundational key to all success.
(行動がすべての成功への基本的な鍵だ)
The secret of getting things done is to act.
（物事を成し遂げる秘訣は行動することだ）
そして、行動していくうちに、しっくりくる・こないというものを感じてきたら、振り返りの合図。
失敗する人には二種類ある。
考えたけれども実践しなかった人と、実践したけど考えなかった人だ。
振り返りの際には、うまくいかなかった要因を分析して、仮説を立てて、また新たな計画を立てます。
何度もクルクルとサイクルを回す過程で、体制や形がブラッシュアップされていくイメージです。
私がPMとしてPJの業務改善をしていた際、「限られた期間の中でいかにこのサイクルの回数を増やせるかでアウトプットが変わる」という経験をしたことがあります。
その時は、チームとしての総合力や経験値が圧倒的に少なく「何が問題かがわからないのが問題」状態でした。
なので、いかに早く問題を特定するかが鍵だと思い、サイクルを早く回すことを優先しました。
私個人としては、サイクルの”回数”に重きを置いていますが、じっくりとサイクルを回すことに重きを置く方もいるかもしれません。
どちらにも、メリット・デメリットがあります。
大事なのは、問題解決に向けたよりベターなやり方を模索していくことかな、と思います。
この記事が気に入ったらサポートをしてみませんか？