カテゴリー別アーカイブ: 3プロジェクトマネージャとは

プロジェクトマネージャとは何か?

用語:パークとソリューション

業態やその組織の性質によってパークベースなのかソリューションベースなのか違うと思います。

ソリューションベース
特定のよく使われる技術があってどこでも同じような業務がある場合、ソリューションベースで事業を展開していくことが多いように感じます。この場合でも使われる技術によっては業界が限定されることもしばしばであろうかと思います。
「人事給与ソリューション部」「財務・経理ソリューション部」「BWHソリューション部」「防災ソリューション部」等のような名前になることが多いと思います。

パークベース
官公庁系ではどこもオリジナルの業務を行っており、ソリューションとしての使いまわしができないことが多いです。縦割り行政の影響でしょうか、似たようなシステムであっても中身は大きく違っていることがほとんどです。
その場合はどうしても特定のお客様につくパークベースの仕事の進め方になります。お客様の指定する進め方や、納品物などに対応することが重要だからです。
「○○社担当部」「○○省事業部」「○○県庁営業部」等特定のお客様のお仕事であればとりあえず引き受けるタイプです。

どっちを採用するか
民需の作業では業務遂行ができてプログラムが動けば納品物はあまり言われないのかもしれませんが、官公庁の場合、前例踏襲主義や会計検査院の検査対応、無謬性の証明の証拠、各種ガイドライン等へのプロジェクト遂行の順守の必要から、プログラム以外の納品物が大変多いです。
そのために、慣れないと失敗することが多く、パークごとに担当者がつくパークベースのプロジェクトが多いように感じます。

どちらが良いというものではありません。適切な切り口でプロジェクト遂行をするのが良いと考えます。
どちらかを選ば根ければならないということもないでしょう。縦糸と横糸の関係ですから、立野役割をもつ縦糸と横糸の役割を持つ組織が両方あっても構いません。
うまく連携できるような仕組みつくりは必須ですが、共存可能です。事業幹部はじっくりとよく考えて組織を構成してみましょう。

混ぜる必要がある場合も
構造としては営業部門などの顧客と密接なところはパークベース、開発部門などは技術で分けるソリューションベースがよいように感じます。とはいえ、営業ではない技術者も顧客の業務に詳しい必要があり、中間的な立場としての組織として両方の仲立ちをしつつパークを見る技術者も必要になって、きれいにすっきりした組織にできないことがあります。(技術者なのにパーク付き・・・)

皆さんの組織はどうですか?

パーク:対象とする市場、顧客
ソリューション:対象とする要素技術、システム製品、業務分類

プロジェクトマネージャのいろいろ

ここでいう「いろいろ」はいろいろな管理手法のことではなく、いろんな役割を持つPMがいることを話します。
これらのマネージャは組織やどんなプロジェクトであるかによってあったりなかったりします。どれが偉いとかというものはありません。規模に応じて組織や役割を分割統合して責任を果たせるようにするものです。つまり広くすべてを行うか分割して少しづつ担当するかの違いになります。

① 与えられたプロジェクトの遂行のみをするマネージャ
案件が持ち上がったらその都度ごとにプロジェクトマネージャを選定しそのプロジェクト全体を遂行してもらうタイプのマネージャです。大抵の場合、営業部門か上司が仕事をとってきて、それを人に割り当てていく感じで進めていくタイプです。
ある意味イベントドリブンで、PJの遂行に責任を持ち、与えられた範囲内で成功させていきます。
ソリューションベースの特定のノウハウや技術を元にそれに関するプロジェクトを遂行していくマネージャにこのタイプが多いですね。
ここでイメージしているタイプは1PJ1マネージャ程度の規模のものを想定しています。技術者上がりのマネージャはこのようなタイプの仕事が向いているかもしれませんね。

② パークを与えられ、営業戦略を含め策定していくマネージャ
特定のお客様や業界を自分のパークとしてその中での様々なお客様の課題を解決していくタイプのマネージャです。あるパーク(市場)を担当として与えられていますから、その行う範囲は各PJの成功のみならず、そのパークでの事業の拡大が入ります。大抵の場合範囲を与えられると一PJではありえませんから、複数のPJを並行してみていくことになります。
そうなってくると部門の管理的なもので、複数のリーダを使って複数のプロジェクトを管理することになります。規模によって、マネージャと呼ぶのか部門規模であれば部門責任者ということになるのでしょう。
複数プロジェクトを並行して管理していく技術が必要になります。組織作りの技術が強く要求される立ち位置ですね。
ここではパーク(市場)を範囲として与えられるものとして書きましたが、ソリューション(技術・製品)という範囲もあり得ます。同じように、そのソリューションを利用する複数のお客様のPJを管理する必要がある場合もあります。あたえられている「範囲」の概念が違うだけで同じ話です。

③ 巨大プロジェクトの一部を担い責任を果たしていくマネージャ
大きなプロジェクトとなると一人では管理しきれなくなることがあります。その場合、複数のマネージャに役割を分割して管理させることがあります。
開発と基盤と運用とQCD管理に分けて、それぞれマネージャが付き、その上にさらにプロジェクト統括責任者(これは部長だったり・マネージャだったり)が付くことが多いです。
それぞれマネージャはメンバーを持って行動しますが、実態はプロジェクトマネージメントチームとして行動することになることが多いです。
サブシステム事態が巨大である場合、サブシステムを管理職が管理することもあります。この場合は、そのサブシステムの専門家であると同時に、サブシステムをPJと同じにとらえ、その中のQCDをはじめとして、人材育成・人事管理等も範疇として行っていく場合もあります。

あなたはどれになりたいですか?

ほかにもPJタイプでの分類もあります。

用語説明:パークとソリューション

3プロジェクトマネージャとは

サブシステムリーダまでで語られた技術などを身に着けるとプロジェクトマネージャーになれるのでしょうか?
いえいえ、「ただのプログラマー」を脱出しただけです。「では、どうしたら!」まずはプロジェクトマネージャーってどんなものなのかを知りましょう。

ここでいうプロジェクトマネージャは一人かもしれないし複数の人で構成されるかもしれません。
大きなPJになるとプロジェクトマネージメントチームというのを作ってプロジェクトマネージャとしての役割を果たしていくことになります。
その場合でも統括責任者としてのプロジェクトマネージャは存在しており、全体の意思決定を担っていくことになります。

(ア) 顧客と直接対峙してプロジェクトを推進していく
(イ) プロジェクトマネージャのいろいろ
(ウ) 上位からマネージャに期待すること
(エ) 自立鼓動と、適切な報告
(オ) 商売!(我々はアスリートでもボランティアでもない)
(カ) 使えないマネージャとは
(キ) マネージャは「たいへん」か

についての書きます
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

コラム:官公庁・公共系と民需では要件定義の立場上の考え方が逆

かならずしもあてはまるものではありませんが、官公庁と民間では要件定義の持っていきたい方向が逆になります。
何が逆かというと、要件定義において、ベンダー側のアプローチとして民需ではどんどん機能を入れるようにアプローチをします。しかし、官公庁では機能を減らしていく方向にドライブしなければなりません。
なぜかというと、調達方法の違いに原因があります。
私は民需系のシステム開発経験はないのですが民需では多く、先のコンサルや要件を確認する中でやることを決定していき、やることが明確になった段階で再度見積もりを提出し、協議していく形になります。この時、良い機能やほしい機能がたくさん盛り込まれていれば、要件を削るのではなく、予算を増やしてもらえるかもしれません。
官公庁系の場合、調達は入札になります。完璧に作った仕様書に基づき、それを実現するのにいくらでやってくれるかを入札します。要件定義でこの仕様書項目で具体的になにをどこまでやるのかを協議しますが、やることが増えても費用は増えません。入札で金額が決まっているからです。
官公庁側担当者は、これはこういう解釈だこういうものだと言いながらできる限りの要件を盛り込もうとします。ベンダー側は仕様書からはそのようなことは読み取れない、書いてないと主張して、やることを予算に収まるように極力少なくしようとします。なかなかにお互いに苦しい交渉です。官公庁側もわざとそうしているのではありません。仕様書では書ききれなかったり、その時には決まっていないことも多いのです。官公庁系の場合要件の齟齬で大赤字プロジェクトになることもしばしばです。お客様に合わせた仕様書の読み取り方など慣れていないと危険ですね。

経営者としては無駄な失敗をしないためにも官庁・公共の案件では慣れた人を当てることが重要です。







イギリスの経済学者が役人の考え方や予算のかけ方を解説!本当かウソか、こんな風に国家予算は膨れていく。


政府の働きなど、間違えない政府の考え方を述べています。