メインページに戻る
顧問業務並びにスポット・コンサルティング
パイロットへの道 航空行政
ADS-Bアンテナ工学 天文 その他個人的なおススメ
|
プロジェクト・マネージメント・マネージャ考 プロジェクト・マネージメントProject Management 永年Project Management（以下PM）職にあった自己を省みて、日本に於けるPM業務について述べる事とする。 実際業務で2000年よりモトローラ（以下Moto）でProject Management手法をISO、SEI-CMMプロセス指向で手がけてきた。 又、Motorola開発によるSix-Sigmaについても社内展開を行なった経験も合わせた経験に基づく持論を以下に展開する。 日本に於けるプロジェクト・マネージメントの問題点 プロマネ： 巷でよく耳にする、”あぁ、プロマネね”。 このような言葉を使う人間に限って、プロジェクト・マネージメントを理解していないか、又は知らないと想像する。 （個人的に、馬鹿にされたような気がして我慢ならない呼称である） プロジェクト・マネージメント手法は大多数の外資系優良企業で使われている手法である。 従って、そのような企業のトップ（CEO）は、その重要性と有用性を充分に理解し活用していると断言できる。 有能なトップ： しかしながら、多くの外資日本支社組織に於いては本社程には活用されていないと感ずる。 批判を受けることを臆せずに申せば、日本組織のトップが無能で活用できないからであると思わざるを得ない。 言い換えれば、ローカルPMチームを使いこなしている経営トップは有能である証でもある。 PMマネージャですら知らないProject： 瑣末な事ではあるが、ProjectとProgramの違いをはっきりと述べられる人間（特に日本人）は少ない。 この事実からも、言葉としてのプロジェクトは知っていても、それは漠然とした理解でしかない。 この程度の意識（Awareness）で適切な効率的なProject推進ができるはずもない。 Motoでの教育定義で、5つの基本フェーズで構成される。 すなわち、 ・Initiation（開始） ・Planning（計画） ・Execution（実行） ・Align（修正） ・Close（クローズ） （表記の違いはあるものの、概ねどこの団体に於いても、PMの定義は同じである） そしてProjectの集合体をProgramと定義していた。 PMの目的（成果物）： 一般的なこの問いに適切に答えられるプロジェクト・マネージャが、どれ程居るだろうか？ 今抱えていProjectに対しては期待されている成果物は具体化されていて、それを要求成果物として業務を遂行している。 間違いではないが、このような限定状況では本来のPMは出来ない。だがこれが日本の現状である。 
PMとISOの連携（点と点を結んで線となる）： PMとは品質を担保する為のプロセス手法である。 以前は製品（ソフト、ハード共）に対する製品品質を上げるためにのクオリティー・プロセスであったが、現状ではビジネス・クオリティーも含まれる。 Motoでは独自のM-GateなるQualityプロセス・チェック・ポイントを設定し、それに沿ってPM手法を適応した。 又詳細管理項目（例えば文書管理等）についてはISO9001をモデルとし、管理手法を確立した。 全体で15（だったと思う）のチェックポイント（M-Gate)があり、中間地点でプロジェクトのGo/No-Goを決めるContract-Bookのリリース（Sign-up)があり、これがPM実行フェーズに相当した。 プロジェクト全体に関わる、文書管理、議事録、外部業者管理等は具体的な手法をISO9001に則り実施状況を公認オーディターによって定期的に監査され、活動維持されてきた。 又、Motoではプロセス＝社内憲法との位置付けをし、全ての社員（Galvin CEOから生産直接部門のスタッフに至るまで）に教育実施を義務付けていた。 少なくとも労働環境の世界規模での均一性が担保されており、発展途上国の拠点であっても完全な履行が求められた。 蛇足ながら、スタッフの就業環境も統一で、個人用キューブと椅子ですら米本社からの世界中へ輸出され、Motoのオフィースは世界中でこの拠点でも、同じ景観であった。 本社が徹底的に公平さを実現した結果、地域であるが故の言い訳は全く通じない事となった。 米系vs欧州系： 多くの米系企業では、Moto同様なスキームでPMが行なわれていると感じる一方、欧州企業では、MS系OutlookとIBM/Lotus系Notesの違いのように、少々異なった手法が採られていると感じる。 ドイツ系有名企業ではプロセスと詳細規定が企業ごとに定義され、ISOを重視する米企業とは少し趣が異なるが、正しく機能している。 仏企業では、お国柄か、独善的なPM手法が定義される傾向にあり、決して直感的には理解し難い面があると感じる。（Cynicalな表現だが分かるかな？直感的とはIntuitiveだが） 米系文化（お馬鹿でも分かる）と対比すると興味深い。 実際の海外本社構築システムのワールドワイド展開運用は本国以外では上手く働かない感じもした。 これは、前記したトップの能力に依存する処が大である故もあると感ずる。 日本の多くの企業が管理項目規定（例えばISO9001)を策定し、PM手法に則ってプロセスも定義され実運用されている。 最低限の結果は出しているようだが決してそれ以上ではない。 何故なら点と点を結んだ線でしかなく、単一的な結果ならざるを得ないからだと感ずる。 PMとリスク管理： 一般の方や多くのPMマネージャにPMの目的を問うと、訳の分からぬ”プロジェクト管理”とか”リスク管理”との答えが返ってくる。 あまり頓珍漢な回答”プロジェクト管理”は無視して、では、このリスク管理って何だ？ 経験上、具体的に適切に回答をしてくださった方は殆ど居なかった。 日本での大方の実際は問題が発生して行なう対処療法ではなかろうか？ リスク管理ではなく、発生後のトラブル対処が大方の業務である気がする。 勿論、トラブル対処はPMの大きなタスクで（関連で後述する）であるが、ここでは”リスク管理”に集中する。 持論を展開すれば、”外部依存性の極小化”につきる。 自動車業界ではあまり好まれないようであるが、個人的にはガントチャートのクリティカルパスを用いて依存性を洗い出し、先手先手で可能な限り、外部依存性を内部依存性に変えてゆく事こそ、リスク管理であると自己定義している。 クリティカルパスで主要な依存性の影響が明らかになる。 大きなマイルストーンに対して、外部依存が支配的であれば、プロジェクト全体に及ぼす影響が懸念される。（外部故に直接のコントロールが利かない） 反対に内部依存が支配的であればあるほどプロジェクト全体についてのマネージメント・コントロールは比較的容易になる。 例えば電子部品といえど、箱（収納ケース又はハウジング）に収納して納品する事がTier-1サプライヤーであれば殆どである。 この場合、社内でメカニカル部門がハウジング設計を行い、外部発注する。 外部受注者は設計図を基にツール（型）を設計し、製作し予定期日までに納品する。 言うまでもなく、これは大きな重大構成要素であり同時に外部依存要素である。 不測の事態で納期遅延が発生すれば、顧客（OEM）へコミットした、納期遅れにも成りかねない。 PMマネージャとして、発注先（この場合ハウジングメーカー）に於ける型設計、試打、調整等人間が関与する行程は短縮が期待できるが、型製作の時間短縮は、ほぼ不可能であると知っておかねばならない。 逆説的になるが、理想的にはPMマネージャが発注先の標準納期ブレイク・ダウンを把握していることである。 又、発注前に購買部門やメカニカル部門マネージャ等と調査を行い、発注先候補の稼動状況も選定段階で考慮すべき点である。 例えばハウジングメーカーでは健全に業務稼動（恒常的に過度の残業が発生していない）しており、全行程として物理的に緊急対応可能である事を予め確認しておくべきである。（余裕がなければ緊急対応を依頼しても受け入れられない） 又、PMマネージャとして外部依存性要素をクリティカルパスから外す工夫をすべきである。 プロジェクト開始時点では考慮しなかったファクターや不測の事態は大なり小なり生じる。 ここで、PMマネージャは関係各所と連携してプロジェクト全体の修正（alignment）をかける作業を適宜行なわなければならない。 このAlignment Cycleを行いつつ、外部依存性要因（External Dependency Factors)を管理（影響を極小に）する事こそ、PMの本質であると認識する。 蛇足ながら日本人的には、修正時に於いても、下駄をはかしておくことが可能であれば望ましい事は言うまでもない。 コミュニケーション： PMマネージャは会社経営者、購買責任者と違い、権限は付与されていない。 言い換えれば、全ては”交渉”であり”御願い”である。 周囲からは”頼りになる知恵袋”や”腕の立つ解決屋（Solution Provider）”である事がPMマネージャの姿であると感じる。 実際の交渉・御願い時には、問題を客観的真摯に説明し、こちらの状況を理解していただき同時に相手の状況も理解して、双方が実現可能な解決策を探り、最終合意を得なければならない。 書く事は容易だが、実行は難しである。 営業職と同じで、対人折衝に向き不向きがあるのが実際である。 
線から面（SEI-CMMを追加）： SEI-CMMとは中規模以上の組織での、プロセスのMaturity（習熟度）レベルを測る指標である。 元来、ソフトウェア作り込み時のクオリティーと組織に於けるプロセス成熟度をレベル-1からレベル-5で評価される。 近年ではSEI-CMMIとして改定され、ソフトウェアのみでなく、周辺を含めたアセスメント評価となっている。 Motoに於けるSEI-CMM活動（組織でレベル-3取得）を通して得た、PM的なメリットを記す。 個人的に最大の新たな認識はFAR、トレーサビリティー、CCBの三つであった。 FAR（Function Area Representative）とは夫々のFARに於ける責任・目的・機能が明確に定義されている。 例えばManagement FARであれば、端的にいえばEngineering FAR（実行部隊）に対して、人・モノ・カネを用意しなければならない。極めてシンプルである。 ここで言うトレーサビリティーとは、作業指示の根幹と責任の所在を明確にし、文書その他のエビデンスで残し必要であれば、完全にBack-Traceが可能なことを示す。 全てのアクションやタスクに対し、誰からの指示であるかが明示的にトレースが可能で、責任の所在が明確になる。 例えばソフト開発であれば、”これこれの仕様のソフトを何時まで完成させる”といった場合、各FARの代表はStakeholder （Management FARの更に上層部）からの明示的な指示が無ければならない。 具体的には会議議事録、メールでの指示、書面での伝達等であるが、それ等を全て記録保管対象としなければならない。 いい換えれば、エンジニア一人の今行なっている業務について最上層までのトレースが可能であり、責任の所在が明確にされる。 Manegement FARとしてのPMマネージャの責務として、Engineering FARに対しての必要な支援（人・モノ・カネ）を用意しなければならない。 PMマネージャは月例Managhement Review以外に、最低でもウィークリーベースで、Steakholderに対し、予定・予測され期待される支援を事前報告して、 必要とされる時期に確実にEngineering FRAに対し提供する義務を負っている。 CCB（Change Control Board）とは変更管理を司るグループで、変更管理対象に対し関係する利害関係者の全てが参加し討議して結論を出す機関である。 Motoでは、検出されたディフェクトの担当者振り分けが主目的で、当時はClearDDTSか何かを使っていたが大いに役立った。 CCBを開催する事で、各部署に於ける製品開発進捗がリアルタイム共有できた事は重要な結果であった。  面から立体（Solid-Geometry）へ（Six-Sigma way）： SEI-CMMでは、組織に於いて就業時間中の概ね20％程をプロセス改善に充てるべきとのガイドラインがある。 ”組織に於いて”の意味するところ、は所属する全員が現在実施されてるプロセスの改善（再現性、効率等）を行なう事が期待されている。 プロセス改善にあたり、Six-Sigmaの思想を取りいれ、MeasurableかつSustainableなパラメータを策定し、プロセス改善の指標とすることを目指した。 要件としては、視点を変えて新たなパラメータでデータを採取し、総合結果にどのように反映されるかを観測する作業である。 身近な実例経験としては、Motoに於いて年初にCEOからA4一枚の年間Corporateゴールが示される。（これは同時に株主へCEOのPersonal-Commitmentとなる） 各部門、各個人はその目標達成に対してのアクションプランを策定し、MeasurableかつSustainableな目標をPersonal-Commitmentとして設定していた。 求められるPMマネージャ像： 独断で申せば、以上のような知識・経験・姿勢を持ち合わせたPMマネージャが、あるべき姿だと感じる。 総じて、米国系会社では上記のようなPMマネージャが多いと感ずるが、比して日本にあっては外資系を含めて流石と思わせる方にお会いした経験が無い事に、危機感を感ずる次第である。 会社が良質なプロセスを実施することにより、直接・間接で得られるメリットは計りしれない。 その実行に必要なのがプロセス指向PMマネージャの存在であって、今後の日本でも優秀な人材が育つことを願ってやまない。 以上 SG Lab主宰 記 |
お意見、ご質問等がございましたら、下をクリックにて御連絡を御願い致します。
ページトップへ戻る
SG Labメインに戻る