2026-02-14T11:06:17+09:00 Tomoichi_Sato タイム・マネジメントとSCM専門家のエッセー・批評・考察集 Excite Blog http://brevis.exblog.jp/33888818/ 2026-02-08T22:36:00+09:00 2026-02-14T11:06:17+09:00 2026-02-08T22:36:15+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般


2017年の秋、わたしはシカゴで開催された『PMI Global Conference』に参加した。自分の研究成果を講演発表するためだ。テーマは、"Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions"。それまで10年以上にわたって続けてきた、リスク確率に基づくプロジェクト・マネジメントの手法論を簡潔にまとめたものだった。


考えてみると、PM関連の国際カンファレンスには、これ以来、参加していない（まあ、GAPPS Initiative のこぢんまりしたオンライン会合は別として）。2000年代の初め頃は、米国でも欧州でも、PMの国際大会への参加は楽しかった。新しい理論や手法の提案も多く、活気に満ちていた。だがシカゴでは、なぜかもはや、そうした興奮に浸ることはできなかった。ちなみに日本からの発表者は、わたし一人だった。


わたしは独立研究者である。PM研究は、わたしの勤務先の仕事ではない。上記PMI Global Conferenceには、渡航費も参加費も自費で負担した。だから気持ちが高揚できない大会には、それ以上行く気になれない。


わたしはその後、PMPの資格維持もやめてしまった。気がついたらコロナ禍の間に、更新期限が来ていたのを忘れていたのだった。うかつな話だ。だが維持にはお金も時間もかかる。日本で名刺にPMPと書くことに、どれだけの値打ちがあるのか。PMPとは、モダンPMを理解して使える能力を証明する資格のはずだ。だがPMI自身が、PMBOK Guideの第7版で大きな方針変更をはかろうと、右往左往していた時期だった。




モダンPMの特徴とは



1年ほど前から、本サイトに「モダンPMへの誘い」というシリーズを、断続的に書いている。モダンPMの最大の特徴は、専門的・計量的なマネジメント技術であることだ。 プロジェクト階層的に細分化してWBSを作り、ロジック・ネットワークを構築してクリティカル・パスを同定し、EVMSで進捗とコストをコントロールする。 結果は数字で表され、精度の良い予測が可能になる。


このような技術は、大規模で、コストやスケジュール制約の厳しいプロジェクトの方法論として、優れている。だから、どのような分野であれ、大規模なプロジェクトのマネジメントに適用可能だし、 必要だ。わたしのかつての部下の1人は、プラント建設のプロジェクトに従事していたが、結婚して米国にわたり、バイオ医薬品企業や、Googleのデータセンター建設プロジェクトなどに携わっている。それでも通用する。それがモダンPMだ。


ところで、このようなモダンPMの手法が 適用できるのは、主にスコープが「ハード」で明確である場合だ。 プロジェクトの任務がふわふわしていて、何を作り、どこまで行ったら終わりなのか、見定めることが難しいようなケースでは、あまりうまく使えない。最初にかっちりした計画もWBSも作れないからだ。


そしてPMI自身、しだいにPMBOK Guide第6版までのPM論への確信に揺らぎが出てきた。その理由の一つは、PMIの参加メンバーに IT系の人材が増え、マジョリティになったからではないかと推察している。ITプロジェクトでは、スコープが最初に十分確定していないことが多い。だから、アジャイル開発のような方法論が有効性を持つのだ。




プロジェクト型の企業と、ふつうの企業



PMBOK Guideの最初の基礎を90年代の初めに作ったのは、航空宇宙産業とエンジニアリング産業の人たちだったと聞いている。この人達の仕事は、航空機とかロケットとかプラントなど、典型的にハードなスコープの受注型プロジェクトだった。そして、こうした業界の企業はプロジェクト型だ。つまり、ビジネスの中心が受注型プロジェクトなのである。わたしの勤務先では（同業他社もそうだが）、全ての仕事が、プロジェクト受注番号に紐付く形でコントロールされる。


しかし、そういう会社は少数派だ。通常の会社は、定常業務がビジネスの中心である。多くの製造業も、サービス業も、流通業も金融業も、そうだ。定常業務の中に、まれにプロジェクト的な仕事がある形だろう。


もちろん中間型を考えても良い。たとえば、繰返し型業務がメインだが、時折、大型の受注型プロジェクトがある重工メーカーなどがそれだ。運用保守がメインだが、時折、それなりの開発プロジェクトが入る情報子会社などもこのカテゴリーに入る。


(A)プロジェクト型企業、(B)定常業務型企業、(C)中間型、とかりに分類したとき、動くプロジェクトの性格は少しずつ異なる。(A)では規模の大小はあれど、受注型でコスト・納期制約の強いプロジェクトが中心だ。とくに大規模ハード系のプロジェクトなら、まさにモダンPMがフィットする。




ふつうの会社のための、プロジェクト・マネジメント論が必要



しかし、プロジェクト型企業は、産業界全体で言えば少数派だ。定常業務中心の、つまり(B)に属する製造業やサービス企業の方がずっと多い。では、こうしたふつうの企業における、プロジェクトの取り組みはどんなものか？　それはたとえば、重要な製品開発（小手先の模様替えではないもの）、新工場づくり、新事業展開などで、いずれも自発型プロジェクトだ。


こうした自発型プロジェクトは、ふつうの会社にとって、競争と発展のための部門横断的な取り組みである。その目的は、「新しい能力の獲得」にある。新製品による競争能力、新工場による生産能力、新事業による市場開拓能力、などだ。ただ、その青写真は最初から明確とは限らない。スコープが「ソフト」なのだ。


(C)中間型として重工メーカーの例をさきに挙げたが、個別受注生産の製造業でも、多くの案件は部門間のバトンリレーで処理され、プロジェクトとしては扱われない。ただかなり大型の案件となると、誰かが責任を持って調整する必要が出てくる。それが本来はプロマネ役なのだが、「プロジェクト」という認識と、それに必要な体制・権限が曖昧な場合もある。


結局、プロジェクト型ではない普通の企業における問題とは、プロジェクトが「プロジェクト」として認知されていないところと、スコープが柔らかい点にある。プロジェクトと認識されていないのだから、プロジェクト・マネジメントの方法論などを期待しようがない。そういった企業に、精緻で定量的なモダンPMの技術を持ってきても、スコープの柔らかさのために役立たない。




プロジェクト・マネジメント能力の発展段階



「ふつうの企業」では、ほとんどが機能型組織の形態をとっている。部門が営業、設計、購買など専門的機能ごとに分かれている。プロジェクトは部門横断的な取り組みだが、プロマネの役割と権限が曖昧な「弱いマトリクス型組織」では、うまくプロジェクトを進められない。全体を見てコストや納期をタイムリーに決断する、意思決定の仕組みが欠けているからだ。


これこそが、日本の製造業が過去30年間の間、競争力を落としてきた原因の一つだと、わたしは考えている。なぜなら、製品開発や事業開発の取り組みが、スピーディーにうまく回らないからだ。そのために必要なのは、モダンPMとかEVMS以前の、基礎的な仕組みや人財側の能力であろう。


とくに、柔らかい（ソフトな）スコープの中で、どう意識決定し、どのように価値あるアウトカムを創出していくかが、問われる。ちなみにモダンPMが得意なはずの(A)型の企業だって、自社内で行う自発型プロジェクトは、必ずしも上手ではない。マネジメントの観点が違うからだ。


ふつうの会社にとって、プロジェクト・マネジメント能力の発展段階はこんな風なステップになるのではないか。


レベル１：「プロジェクト」を認知し「定常業務」との違いを理解する
レベル２：プロジェクト遂行に必要な組織・役割・権限・ツール類を整備し、、キーパーソン層のソフトスキルを高める
レベル３：プロジェクト・マネージャー職種を確立し、マネジメント技術を獲得・蓄積する（企業文化の中に組み入れる）


わたしのような外部コンサルタントは、レベル２・３のお手伝いはできる。しかし最初の１は、経営層の「気づき」が必要だ。自分の真の「ニーズ」を知ってはじめて、学びのステップを登ろう、との気持ちが起きるからだ。それがたとえ、失敗のペインを通した気づきであっても、学びのニーズこそ、組織と人を育てる原動力なのだから。





＜関連エントリ＞
「製造業のプロジェクトがうまく進まない、本当の理由」 (2024-12-01)
]]> http://brevis.exblog.jp/33821943/ 2025-11-09T12:24:00+09:00 2025-12-31T11:05:23+09:00 2025-11-09T12:24:12+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

リアル会場で1日かけて行うプロジェクト・マネジメントの研修セミナーを、久しぶりに開催します。今回は、内容も従来の形をかなり刷新したプログラムとします。企業の実務レベルの方に役立つよう、とくに製造業のような縦割り組織の強い職場で、どうプロジェクトを構想し進めるべきかも含めて、構成を組み直しました。


これまでもわたしは、PM研修をいろいろな形で行ってきました。大学でも1学期間の授業を持っていますし、職場でも教え、また依頼されれば企業や官庁向けにクローズドなセミナーも開催しています。昨年度までは、「P&PA研究部会」のPM教育分科会の仲間たちとの共同セミナーもありました。


そこでは主に、20世紀半ばに生まれたモダンPMの中心的概念を理解してもらい、プロジェクト計画とコントロールを客観的・定量的に進める技法の習得を、ねらいとしてきました。モダンPMの概念とは、プロジェクトをアクティビティから構成されるネットワークの「システム」として理解することです。そこから、スコープを表すWBS、スケジュールをおさえるPERT/CPM、コスト・コントロールのためのEVMSなどの技術が出てくる訳です。


ただし、PERT/CPMやEVMSのような技術は、プロジェクト・マネジメントの「ハード・スキル」と呼ばれる面であり、もう少しかみ砕いていうと、それなりに規模のある、スコープ（役務範囲）が明確なプロジェクト向きの手法です。


しかし世の中には、もっと「ソフト」なプロジェクト、すなわち目標や責任範囲が柔らかで不確実性の高い仕事に、取り組まれる方々も多いと思われます。こうした領域は、ハードなPM技術だけでは必ずしも十分に進められません。かと言って、最初から最後まで「リーダーシップの発揮！」の気合い一本槍では、やり抜けないのも事実です。


そこで今回のセミナーでは、不確実性の高いプロジェクトのマネジメントに焦点を当てようと決めました。製品開発や、DXなどの改革、それに伴うIT開発などが典型でしょう。そして、リスク予知やコミュニケーションなどの、ソフト・スキルからスタートします。そしてチームと組織デザインに進み、漏れのないタスクの洗い出しとWBS化、設計とミッション・プロファイリング、といった順序で解説を進めます。


知識のインプット学習だけではマネジメントは身につきにくいため、あえて自分で手を動かすグループ演習を取り入れます。そのため、リアル開催のセミナー形式としています。ソフト面を重視するといっても、モダンPMの知見を援用しますので、わたしが以前行ったハード・スキル中心のPMセミナーを受講された方にも、おすすめしたく思います。拙著「世界を動かすプロジェクトマネジメントの教科書」でも、ある製造メーカーを舞台に、誰がプロマネかさえ不明確な製品開発プロジェクトを、一担当のエンジニアが乗り切っていく話を書きましたが、実務ではソフト面とハード面の両立が望ましい訳です。


ちなみに、もうじき米国PMIからPMBOK Guide第8版が出ます。PMBOKは2000年刊行の第2版で大枠が固まり、その後はPMP試験と連携しながら第6版まで拡充しましたが、第7版で大幅に内容が変わりました。それは、ハードなPMからソフトなPMへの転身の試みだと言えるでしょう。第8版の予告された目次を見ると、再び構成がそれなりに変わり、ソフト面とハード面の両立・融合に苦心している様子がうかがえます。なお、わたしのセミナーは、用語概念などは可能な限りPMBOK Guideに合わせていますが、もちろんPMP資格試験をねらいとしたものではありませんので、その点ご留意ください。


＜記＞


「プロジェクトを成功させるマネジメントの実践とそのポイント」


日時：　2025年12月17日(水)　10:30～17:30


主催：　日本テクノセンター
会場：　〒163-0722　東京都新宿区西新宿二丁目7番1号 　　　　　小田急第一生命ビル22F


セミナー詳細：　下記をご参照ください（有償です）
　https://www.j-techno.co.jp/seminar/seminar-75763/



大勢の方のご参加をお待ちしております。





＜関連エントリ＞
「プロジェクトのスコープには硬軟がある」 （2018-09-20）
「PMPの資格はほんとうに仕事の役に立つのか」 (2015-05-15)




]]> http://brevis.exblog.jp/33710176/ 2025-07-05T20:29:00+09:00 2025-12-31T11:05:23+09:00 2025-07-05T20:29:53+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般



【導入文】
多くの人を束ねる「管理」を研究対象とする学問がある。「プロジェクトマネジメント」、英語の頭文字を取ってＰＭと呼ばれる分野だ。達成すべきアウトプットが決まっており、複数人が協力して行い、失敗のリスクもある。こうした〝一発勝負〟の仕事をプロジェクトと定義し、現場で誰もが使える〝負けないための定石〟を理論化する。エンジニアリング、ＩＴシステム開発などの現場で導入が進んでおり、近年、大きく発展している。多くの人が協力し、安全に工期内で現場を納めるには何が必要なのか。ＰＭのプロに、建設業の課題解決のヒントを聞いた。


【インタビュー】
佐藤知一　氏
日揮ホールディングス（株）チーフエンジニア、筑波大学教授（グローバル教育院）
Ｑ　ＰＭでの「管理」とは、何を意味するか。


Ａ　日本では、管理という言葉がとても幅広く使われる。ただ、英語にすると▽マネジメント▽コントロール▽アドミニストレーションと３つの言葉に分かれる。
　アドミニスレショーションは働く場所を維持する仕事を指す。総務課、庶務のようなイメージだ。例えば現場入場者の台帳制作、などの仕事を指す。
　コントロールは、工程表や予算表などの計画を立て、その進捗（しんちょく）を確認し、予定と実行を把握していくことだ。機械を運転・操作しているイメージだ。
　最後にマネジメントだが、これは暴れ馬を乗りこなすイメージがある。例えば、自分の車を前に「Ｉ　ｃａｎ　ｃｏｎｔｒｏｌ　ｍｙ　ｃａｒ」と言ったら、自分の車を正確に運転できるという意味になる。しかし「Ｉ　ｃａｎ　ｍａｎａｇｅ」だったら、古くて故障が多いといった問題を何とか乗り越えている、という感じになる。


Ｑ　マネジメントとは


Ａ　マネジメントの根本は人に働いてもらうことだ。施工図を書くのでも、リベットを打つのでもいいが、自分でやる仕事はマネジメントではない。人に設計図を書いてもらう、リベットやコンクリートを打ってもらう。これをマネジメントという。
　大きい構想を立て、人を組織化する。ルールを決める。当然お金のやり取りもある。構想が実現していくように持って行くのがマネジメントだ。その上で、実際のお金や進捗が予定通りに行っているかどうか確認する、これがコントロールの世界だ。出入金の伝票をつけるのはアドミニストレーションの仕事となる。
　このように三つは全部違うのに、一緒くたに管理と言ってしまうと、訳が分からなくなる。


Ｑ　現場管理はマネジメントであるのに、ＰＭが建設業界で馴染みが薄いのはなぜか


Ａ　マネジメントやコントロールには「技術がある」という認識が、特に日本では非常に乏しい。マネジメントやコントロール、つまり人の上に立つに当たって必要なのは気合いで、「それは本人の資質の問題だ」というのが、日本の古い考え方だ。


Ｑ　具体的には


Ａ　例えば「腹の据わったやつを現場所長に据える」とか、「有名な大学を出た優秀そうなやつを技術者のトップに据える」とか。これで物事がマネジメントできるというのが、日本の感覚だ。人格や出身、資質の問題で、「技術」の問題ではないと。その結果どうなるか。現場ごとにやり方が違い、デコボコの大きい業績になっていく。
　マネジメントが人格や、生まれつきの資質の問題なら、トレーニングの余地がないことになる。「生まれ変わってこい」としか言いようがなくなる。大勢の人を集めて、〝適任者〟だけを選別し、重要なポジションにつける。そうした考え方だったのだ。
　そうしたやり方は、人が無尽蔵にいた時代には成り立っていた。今は、人をきちんと育てていかなければいけない。マネジメントやコントロールを技術として教え、身につけさせる。その上で、技術を動かすための道具、ＩＴなどを充実させていく。これが今、建設業界が向かっていくべき方向性ではないだろうか。
 
Ｑ　エンジニアリング業界でＰＭが普及する理由は


Ａ　一般建設業界とプラントエンジニアリング業界は、非常に大きな違いがある。大手ゼネコンの多くは、江戸時代からある土着の業界だ。だがエンジニアリングは輸入業界で、アメリカで発達した産業の形を日本も導入した。日本のエンジ会社は、アメリカの同業のやり方を一生懸命学んできた。
　さらに、日本のエンジ業界大手３社（日揮ホールディングス、千代田化工建設、東洋エンジニアリング）の仕事の７、８割は海外だ。海外の顧客は「ちゃんと計画を最初に立てたか」「進捗（しんちょく）通りか、毎週・毎月レポートしろ」という。遅れたら「本当にこれで納期に間に合うのか。リカバリープランを出せ」と、こうくる。
　エンジ会社も建設業も、同じ日本人がやっているが、物の考え方、やり方が全然違う。それは海外のお客様と国内との、要求レベルの違いだ。だからプロジェクトマネジメントが重要視される。


Ｑ　建設業は取り残されているのか


Ａ　プラントの設計は技術、これは誰も疑わない。装置を設計するのは機械学科を出た人たちで、鉄骨を設計するのは土木学科を出た人たちだ。ところが、エンジニアリング会社には、プロジェクトマネジメント部門があり、プロジェクトマネージャーという職種があって、その下にプロジェクトエンジニアがいる、というピラミッドがある。
　「この人達はプロジェクトマネジメントという技術を担って、動かしている」。そうエンジ会社は思っている。しかし、おそらくほとんどの建設会社、あるいは設計事務所もだろうが、マネジメントは技術という感覚が薄く、昭和時代の感覚のままずっときているのではないだろうか。


Ｑ　難題は信頼関係と職人技で納める。そうした風土が足かせとなっているのか


Ａ　人が人を動かす、人に働いてもらうには、必ずヒューマンファクターが影響する。ただ、「属人的でない技術がある」という感覚を持っているかどうか。これが一番大事な違いだ。もしも、建設業界にその感覚が薄いのであれば、労働者が減少する国内市場で生きていくのは難しくなると思う。
　昔は働く人は日本人ばかりだったが、今は外国の方も沢山いる。指示の出し方も変わっていく訳で、そこの部分も含めて「技術」として、きちんと人に伝えられるようにしていく。これが一番基本的なポイントだと思う。




【略歴】
佐藤知一（さとう・ともいち）１９８２年４月日揮株式会社入社。設計部門・プロジェクトマネジメント部門にて、国内外の工場・プラントづくりに従事。２０１２年より経営企画部門。専門書に加え、対話形式でＰＭを解説する「時間管理術」（日本経済新聞出版）、「世界を動かすプロジェクトマネジメントの教科書」 （技術評論社）など、初学者が手に取りやすい著書も執筆する。

]]> http://brevis.exblog.jp/33391564/ 2024-12-01T21:19:00+09:00 2025-12-31T11:05:23+09:00 2024-12-01T21:19:32+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

先日、名古屋工業大学で開催されたプロジェクトマネジメント学会中部支部のシンポジウムに参加し、アビーム・コンサルティングの阿部さんと一緒に講演をする機会があった。メインテーマは「MES導入のための標準業務テンプレート」の紹介で、我々の研究会で開発リーダーである阿部さんが解説されたが、わたしはその前振りとして、製造業におけるプロジェクトの共通課題についてお話しした。


わたしが訴えたかった共通課題とは、一言でいうと『プロマネ不在問題』である。プロジェクトは必要があって発足し、進んでいくのだが、肝心のプロマネが誰だか分からない。大事な決断を誰が下し、誰が権限と責任を持つのか分からない。そんなバカな、と思う人もいるだろうが、しばしば見かける現実である。こんな状態では、ものづくり改革だとか工場スマート化などが、うまく進むわけがない。


プロマネが誰だかわからないのだから、「プロジェクト・マネジメント計画書」なども、きちんと存在するわけがない。当然ながら、ベースライン計画を前提としたマネジメント・プロセスも機能するわけがない。つまり、普通の意味でPM標準が規定するような知識や技術は、適用されない（適用しがたい）ことになる。


日本PM学会は、米国PMIが策定したPMBOK Guide(R)の紹介活動や、最近は欧州IPMAとの提携によるPM標準の普及などを進めている。そしてPM学会の構成員の大多数を占めるIT業界では、確かにプロマネなりプロジェクトリーダーなりの職種も、かなり確立してきた。しかし、プロマネすら不在の組織では、PMBOKの10のマネジメント領域どころではない。非常に大きなギャップが存在する。どうしてこうなのか？




製造業におけるプロジェクトとは


ずいぶん以前のことだが、プロジェクト・マネジメントの本を読んでいたら、


「『プロジェクトはタコ壺であり骨壺だ。一度入ると生きては戻れない』－－こんな感想をよく耳にする」


と書かれていて驚いたことがあった（「書評：『はじめてのプロジェクトマネジメント』近藤哲生・著」 ）。著者は製造業の重鎮・日立製作所のOBである。「そういう会社なんだなあ」と、当時思った（今は違うのかもしれないが）。


日立は製造業であり、かつIT受託開発の元請けもやる会社だ。だがIT受託の分野をもたない普通の製造業でも、実際には様々なプロジェクトに取り組む必要がある。それは新製品開発プロジェクトであり、新工場ないし製造ライン増設プロジェクトであり、新販路開拓プロジェクトであり、あるいは業務改革プロジェクト（これにはしばしば、ITシステム開発プロジェクトが付随する）であろう。ものづくり改革とか工場スマート化は、最後のカテゴリーの一つと捉えても良い。


これらのプロジェクトに共通する1つの特徴は、複数部門の協力がいる点だ。もちろんそれはプロジェクトの規模や複雑性に依存する。比較的シンプルな製品のバージョンアップに伴う新製品開発などは、設計開発部門だけで完結するかもしれないし、 小規模なラインの増設は、生産技術部門だけでほとんど終わるだろう。仮に他部門の協力が必要だとしても、業務上隣接する部門、例えば企画部門と設計部門、あるいは生産技術部門と製造部門といった、接点の多い部署との調整で良い。


ところが、新しい製品ファミリーを作るようなタイプの新製品開発では、企画・設計・研究・生産技術・調達・製造・物流・営業…といった、かなり多数の機能部門が関わることになる。 そして、それぞれの部門は、お互いに異なる目標やKPIの尺度を持っていて、意見調整が簡単にいかないことがある。大型の新工場建設や、未経験の地域や国での販路開拓などでも、似たような事情が起きやすい。




プロジェクトは部門横断（クロス・ファンクショナル）な取り組みである


日本企業は業務を回す実務レベルの人々が優秀で、それなりに権限範囲を持ち、隣接する部門同士の調整は上手にできると、前回の記事で書いた。 しかし、隣同士でのすり合わせで問題が解決しない場合、問題の全体構造を見た上で、誰かが決断を下す必要がある。それは本来、プロジェクト・マネージャーの役割である。


問題の全体構想とは何か。それはプロジェクトの予算であり、納期であり、またスコープ＝責任範囲（役務範囲）の制約である。 製造業の3大パフォーマンス目標値がQCDで、トリレンマの関係にあることを前回記事で書いたが、 プロジェクトでは、一般に品質の代わりにスコープ（役務範囲）をとる。これはスコープが全体の仕事量を表すからだ。品質を 確保するためのレビューやテスト等のアクティビティーもスコープの中に含まれるため、このようにする習慣だ。


そしてこの3つもトリレンマの関係にある。どれか1つを変更すると、他の2つに何らかの影響が及ぶ。だからプロジェクト・マネージャーの1番大切な仕事は、この3つの制約条件の中で、プロジェクトの価値を最大化するような選択肢を探して、決断することにある。


決断のためには、プロジェクト・チームの中で議論を戦わせ、様々な事実認識を共有し、いろいろな方策・オプションを提示し検討することが大切だ。だが、最終的には何らかの決断を下さなければならない。そして決断はタイムリーに行わなければならないのが、プロジェクトの現実である。


ところで、ほとんどの製造業は、機能別の組織になっている。1番上に経営者がおり、それを支える形で人事・財務といった本社機能と、研究開発機能があり、そしてライン業務を受け持つ部門が並ぶ。具体的には営業であり、技術、製造、物流などである。では、プロマネのいるべき部門はどこなのだろうか？







機能型縦割り組織と、プロジェクトの論理


ところで読者諸賢は、上のようなピラミッド型の組織図で、各部門を結ぶ線のことを、何と呼ぶかご存知だろうか？　英語では、これをレポーティング・ライン(Reporting line)という。 つまりレポートする（報告する）線である。「私の上司はジョンだ」を、英語では "I report to John"と表現する。 組織図の線は、報告及び指示を伝達するコミュニケーションのルートを意味している。


すなわち、組織における公式なコミュニケーションは、この線を経由しなければならないルールなのである。もちろん、昼食時に食堂でおしゃべりしたり、休日に一緒にスポーツを楽しんだりするような非公式のコミニケーションは、個人同士で直接行って構わない。


しかし例えば新工場プロジェクトで、検査部門の担当者が、生産技術部門の工程設計技術者に対して、新しい検査装置についての要望を出すとしたら、 本当は検査課長から製造部門長に上げて、技術部門長を通って、生産技術課長経由で下ろさなければならない。 これがピラミッド型機能別組織の、本来のルールなのである。


だがご存じの通り、部長同士が定例的に顔を合わせる部長会など、週1回か隔週である。プロジェクトの連絡調整を、いちいちそのルートでやっていたら、日が暮れてしまう。そして各部門は異なる目標値KPIと、異なる利害意識を持っている。それらが対立した場合、誰が意見調整をするのか？　まさか多忙な社長が、いちいちプロジェクトの個別の決断を下してはいられまい。


そこで本来は、経営者がプロジェクトに必要な権限と予算と責任を、『プロジェクト・スポンサー』という役職に委譲する。そしてスポンサーはプロジェクト・マネージャーを任命して、プロジェクト実務に専任させる、という建て付けでPMBOK Guideなどはできているのである。プロマネは、手を上げて自分でなるものではない。スポンサーが（あるいは、プロジェクトの上位にプログラムがある場合は、プログラム・マネージャーが）任命するものなのだ。


プロマネは、プロジェクト・チーム内の意見をとりまとめて、必要な決断を下す。決断を下すからには、その結果についても責任を持つ。それでも、周囲のステークホルダーが納得しないような重大な問題がもしも生じたら、スポンサーが経営層を通じて説得・調整を行う。これが欧米などのPM標準を貫く思考原則なのである。




製造業のプロジェクトは、「プロジェクト以前」に真の問題がある


ところが、日本の多くの製造業では、こうした思考習慣自体が存在しない。だから、プロマネ不在のまま、プロジェクトが始まってしまう。


拙著『世界を動かすプロジェクトマネジメントの教科書』 も、じつはこの問題を取り扱っている。本書の内容は元々、東大や静大の大学院でのPM講義がベースだが、講義そのままでは面白くないので、ストーリー仕立てに設定した。主人公は製造業の若手エンジニアである。年齢は30歳そこそこ。まだプロマネに立てるような年代ではない。


ところが彼の会社では、社長の思いつきで突如、アジア新興国の海外企業との「共同製品開発プロジェクト」が走り出すのだ。とはいえ、誰がプロジェクト・マネージャーなのかも、定かでない状態なのである。


主人公は設計部門に属していて、彼の直属上司の課長は本プロジェクトに大いに乗り気だが、その上の部長は腰が引けている、といったシチュエーションになっている。どう見ても、このままではプロジェクトはうまく行かない。そしてその問題は、担当者である自分の上に被さってくるはずだ。


危機感を覚えた主人公が、偶然空港で出会った大学時代の大先輩に、「プロジェクト・マネジメントの基本を教えてください」と他の頼み込むところから、本書のストーリーは始まる。単なる担当者の立場でありながら、主人公はどうプロジェクトを動かし、リスクを乗り越えていくべきか？


無論、著者としては主人公をこのまま放り出しておく訳にはいかないから、製造業の組織論に即した現実解の一つを、本には書いている（ご興味があれば、ぜひお読みくだされ^^）。でも、こういう風に進むかどうかは無論、個別の企業の状況によっている。


長引く不況の間、日本の製造業は、差別化を求めて新製品を開発し、新興国などの市場を開拓し、あるいは海外工場の移転などで活路を求めてきた。それらは皆、プロジェクトだ。だが、プロマネ不在の機能型組織でプロジェクトを進めたって、納期もコストも守れず、目指したアウトカムは得られまい。失われた30年は、製造業におけるプロジェクトの不調がもたらした結果である。


そして、その真の理由は、PMBOKみたいなPM標準が普及しない事にあるのではない。もっとそれ以前のところ、企業がプロジェクトを『プロジェクト』だと認知していないこと、決断が必要なのにプロマネが不在なことに起因するのである。




＜関連エントリ＞
「書評：「はじめてのプロジェクトマネジメント」　近藤哲生・著」 https://brevis.exblog.jp/10266445/ (2009-05-18)
「製造業のトリレンマ・QCDを決めるのは誰か」 https://brevis.exblog.jp/33340696/


]]> http://brevis.exblog.jp/32716767/ 2024-08-31T19:30:00+09:00 2025-12-31T11:05:23+09:00 2024-08-31T19:30:11+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

・・という訳で、2013年に「コストとリスクのトレードオフ問題​​」を、2015年に「コストとスケジュールのトレードオフ問題​​」を、そして2020年には「プロジェクトのコスト超過と崩壊現象の問題​​」について取り組み、研究成果を発表しました。問題を解決したとまでは言いませんが、理論的なアプローチの方針は示せたと思っています。


しかし、今でもよく覚えているのですが、2015年にスケジューリング学会でこの研究を発表した時の聴衆は、7人でした。そして2020年の発表の時の聴取は、わずか3人でした。この時点で、この種の研究を続ける意義ってあるのかなと、正直、思うようになりました。


日本でこの種の研究をしても、誰も関心を持たない。たまたま最後の二つは、スケジューリング学会で発表したのですが、この学会に集まるのは、非常に優秀な人たちです。理論もそうだが、それなりに現実の問題に興味がある人たちですけど、それで3人ですよ。


わたしのPM研究は全部、自分の勤務以外の時間を使って、自分の手金でやってる研究です。やり続ける意義って何なんだろう​​？　という思いになった。ここら辺が、この研究部会を続ける意義に関連してくるんですよね。


ついでながら、先月、あるオーストラリア国立大学のプロジェクトマネジメントの専門家が、わたしに会いたいと言ってきたんです。大阪の国際学会で基調講演をやるために、日本に来ていて、帰り道に東京によるんだけど、ちょっと会って話しないかって言われました。そこで慶応大学の松川先生に同席していただいて、簡単なディスカッションをしました。


この人の研究論文をあわてて見てみたら、非常に面白い。プロジェクトのアウトプットとアウトカム、プロジェクトの価値、プロジェクトのインパクトなどが、どういう関係に成り立っているのかを簡潔にまとめたエディトリアルを、International Journal of Project Managemen (JPMA) に書いている。


プロジェクト・マネジメントの分野では、ヨーロッパのJPMAという論文誌と、アメリカのPMIが出しているProject Management Journal (PMJ)、この二つが最高峰です。そのヨーロッパの方の最高峰の雑誌にエディトリアルを載せている人が、なんで佐藤に会いたいって来たのか。理由をたずねたら、


「JPMAのレビューアー・リストを見たら、日本ではお前しかいなかった」


というんですね。たしかに、わたしの知っている限り、過去十年間でこのジャーナルに論文を投稿したのは、わたしともう一人、神奈川大学にいる石井信明先生だけです（石井先生は、実は日揮で同僚だった人です）。


日本には、世界に発信できる PM研究者が少ないのです。わたしは欧州IPMAのWorld Congressも行きましたし、PMIのGlobal Conferenceにも行って、研究成果を発表しましたけど、日本人発表者の姿はほとんどないです。聴きに来てる人、取材に来てる人は、いましたよ。でも発表する人がほとんどいない。


まあ残り時間も15分を切りましたから、ここから先は、今後どういうことを考えなきゃいけないか、という課題の話をします。


プロジェクトの計画とは、普通は WBS を展開して、アクティビティ・ネットワークを作り、コスト・時間・リソースを計算して、最後にリスクアセスメントをやる、というステップでスタンダードなプロジェクト計画を作るわけです。


総合的にリスクアセスメントを行って、リスク事象を洗い出し、スコアリングをして、重要なものにリスク対策を取り、プロジェクト計画を最適化しろ、と。これは世の中の標準的な教科書に、みんな書いてある。こういうことは、ちゃんとした企業だったらやってるわけです。


問題は、そのプロジェクト計画の最適化です。先ほど、ガレージ・カンパニーのケースを説明しましたよね。あのケースでは、どんな製品を作るのかを知らなくても、アクティビティ・ネットワークの設計を変えることによって、プロジェクト価値が上がるんです。そのアクティビティの中身を知らなくてもいい、というところがポイントです。





方策としては、例えば、冗長化（パラレル・ファンディング戦略）によるリスク低減だとか、リワークの許容によるリスク低減とか、あるいはアクティビティの分割・工程順序の変更によって投下費用のタイミングを改善する、などがあります。こうしたネットワーク設計 によって、プロジェクト計画を最適化していくことができます。このやり方を、今は、非常にスキマティックに書いているだけですけれども、もっとちゃんと工学的にディベロップするべきだと思うんです。


プロジェクトとは、アクティビティに分解することができ（それがWork Breakdown Structureです）、その一番下のアクティビティ（ワークパッケージ）よりも下側については、プロマネは普通、立ち入りません。それは固有技術の領域なので、担当者に任せる。


逆にプロジェクトより上位の問題、このプロジェクトを進めるのか、やめるのか、みたいなことは、プログラム・マネジメントの領域です。


なので、プロジェクト・マネジメントとは、上下に挟まれた領域において、プロジェクト計画を策定し、進捗をコントロールし、問題解決して、完了分析していく、というような仕事です。この領域の仕事をより良くするためには、技術が必要で、そのテクノロジーのためには科学的研究が必要ですよね、というのが、わたしが今日、通して言いたいことなんですね。


それではこの先、プロジェクト・マネジメント研究で、どういうテーマが必要になるのかを、最後にお話ししようと思います。


この絵は2018年、つまりもう6年前ですが、日揮が発表した「IT Grand Plan 2030」のロードマップ図です。その時点で、2030年までの12年間のグランドプランを、わたしが中心になって作ったんです。



この右上の方に、「プロジェクトデジタルツイン」とあり、「着地点の予報円」と書きました。これは何かというと、その当時、すでに「デジタルツイン」って言葉が流行り始めたのですが、物理的なプラントのデジタルツインを作るのは当たり前だろう。それは図の途中でやると表明しました。


でも、我々は目に見えないプロジェクトというものの、デジタルツインの構築を目指そう。 そういうふうに、この時に決めたんです。では、着地点の予報園とは何かというと、コストとスケジュールの座標軸で、このプロジェクトが先々、どういうルートを通っていくだろうか？ ということを表示するものです。ちょうど台風の予報円です。プロジェクトには振れ幅・リスクがあるので、台風のように、点じゃなくて予報円になる。


ここで問題は、それを予測するための予測方程式って何か？　です。





現代のモダンPMには、実は足りないものがいろいろあります。大きく三つ挙げるとすると、1つ目はこれです。まず、今のモダンPMには、第一原理がない。


第一原理っていう言葉は、実は今日来られてない副幹事の串田さんに、教えてもらった言葉です。串田さんはもともと、阪大で材料研究をしてドクターをとった人なんですけど、要は材料の物性を予測する時に、第一原理計算を行う。第一原理とは、具体的に言うと波動方程式ですね。波動方程式から材料の物性が予測できる。


プロジェクトのデジタルツインを構築して、挙動を予測するためには、つまり、その対象系を予測するための、基礎式がいるんです。でも、今のモダンPMの世界には何もない。


プロジェクトはアクティビティからなるネットワークだから、アクティビティ・ネットワーク上のダイナミック・シミュレーションになるだろう、とぼんやり予測してますけど。そういうものが、本当は必要です。それがないと、予報円などいうことはできないのです。


そして二番目は、13年前から言ってることの繰り返しになりますけど、プロジェクトの価値論がいる。今のモダンPMには、プロジェクトの価値論がない。あるいは最近やっと、ベネフィットとかアトラクティブネスという形で、プロジェクトの価値論にだんだんシフトしてきている。


少なくとも欧州のプロジェクトマネジメント研究はそうです。オーストラリアはどちらかというと、欧州に近い。PM研究で価値論というものを、だんだん考えるようになってきている。
価値論としては、最低でも、お金とリスクが取り扱えることですけれども、それは必要条件だけど、十分条件ではありません。当たり前ですけど、非金銭的価値も重要ですから。価値とは多元的であることをベースにした、判断基準が必要になるでしょう。


そして三番目のテーマは、設計論です。


そもそもプラント屋だから言うわけじゃないのですが、プロジェクトの遂行計画の骨格って、実はプロジェクトが作り出す成果物の、アーキテクチャによって、相当程度に左右されます。


プラントを現地に行ってゼロから組み立て作るのか、それともどこかの造船所のヤードで、モジュールを組み立ててから、現地に運んで据え付けるのか、ということが、プラントの世界では重要なんです。そのアーキテクチャの違いによって、プロジェクトの遂行計画は全然違うわけですよ。


成果物の設計とプロジェクト計画って、表裏一体の関係になっている。だから設計論もいるんです。ところが今のモダンPMには、設計論がない。


でついでに言うと、プロジェクト計画を作るっていうこと自体も、一種のデザインなんですね。このデザインという行為は、必ずサイエンスの部分と、アートの部分があります。とはいえ、できれば自動設計を追求していくべきであるっていうのが、わたしの考えです。




以上の結びとして、最後に申し上げたいことがあります。学生への講義の時などでも、最後にいつも説明することですが、マネジメントとは、目的を達成するために人に仕事をしてもらうことです。人が人を動かすので、必ずそこにはヒューマンファクターがかかわってきます。あの人の言うことだったら、ついていこうとか、あいつの言うことだけは聞きたくない。そういう部分は、マネジメントには必ずあります。


しかし、マネジメントを誰もが一定レベルで遂行できるようにするための、計量的・客観的なテクノロジーもあるわけです。


つまり、世の中の技術は、2種類に分けることができます。1つ目は、『固有技術』です。固有技術とは、対象固有の科学法則に縛られる領域のテクノロジーです。つまり機械設計であるとか材料開発とかねシステム設計、これみんなこういう技術です。


わたしは、もともと大学の専攻は化学工学、ケミカル・エンジニアリングでした。すなわち化学プラントの設計論ですが、これも固有技術です。


ところが、それ以外にもう1種類、技術がある。それが『管理技術』とわたしが呼んでるものです。これは、人間の作業の集合に対して適用するテクノロジーです。それは業種・分野固有の部分がないので、汎用的です。その代表例が、例えばWBSとかクリティカル・パスです。あるいは在庫理論なんかもある意味そうです。在庫するものが、お水だろうが、ダイヤモンドだろうが、共通して使えます。


それで、問題は、日本の大学教育が残念ながら、この管理技術＝マネジメントテクノロジーを、ずっと軽視してきたことです。管理技術を大学で学ぶ機会が、非常に少ない。だから、経営工学の先生方はみんな、非常に悔しい思いをしておられる。


わたしは化学工学は勉強しましたけど、今日お話したことは、すべて全部、社会人になってから学んだことばかりです。でも、それは何とばかげていることか。本当は、マネジメント・テクノロジー＝管理技術を、ちゃんと教育の中に確立しないといけないと思ってます。


まあ、慶応大学は管理工学科があるぐらいだから、ちゃんとわかっておられる。問題は、東大と京大ですよ。まあ、東大と京大が悪いというよりは、文科省がわかってないことの現れです。文科省はなんでわかってないかというと、実は財務省が管理技術ということを理解していないからです。


マネジメントには独立した領域があり、独自の技術があるっていうことを、日本の法学部出身の人たちが理解していない。そのために、管理技術の教育にも研究にも、お金を使わないのです。


だから、我々はこういう状態で集まって勉強しなきゃいけないということなんです。


でもまあ、愚痴っぽい話はさておき、今申し上げたように、モダンPMには、まだまだ付け加えるべき領域があるのです。それを一緒に研究したいと思って、この研究部会を始めたわけですけれども、なかなかこの国では、そういう活動に対して興味を持ってくれる人が多くないという現実があり、この研究部会を一旦たたもうと思います。


でもわたし自身は、こういう研究が必要だという旗を下ろすつもりはないので、また何らかの形で、この先も続けていきたいと願っています。


ということで、ちょうどお時間になりました。皆様、本日は本当にどうもありがとうございました。




＜関連エントリ＞
「研究部会・最終講演『プロジェクト＆プログラム・マネジメントの過去・現在・将来』より(1)​​」 https://brevis.exblog.jp/32702011/ (2014-08-26)
]]> http://brevis.exblog.jp/32702011/ 2024-08-26T00:54:00+09:00 2025-12-31T11:05:23+09:00 2024-08-26T00:54:30+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

研究部会に参加された方も、ご都合で参加できなかった方も、あらためて御礼申し上げます。ありがとうございました。


◇- — -◇- — -◇- — -◇- — -◇


今日が最終回ということで、若干残念ではありますけれども、まあ13年間、続けてこられたのは皆様のおかげだと思っています。まずは御礼申し上げたいと思います。


スケジューリング学会の下でずっと続けてきた研究部会で、主査はわたし、それから副主査として、静岡大学の八巻直一先生、それから慶応大学の松川弘明先生に、ずっと幹事をお願いしてきました。あと、今日は残念ながら参加できないんですけれども、副幹事として未来生活研究所の串田悠彰さんにご尽力いただいています。


この研究会の目的、もともとやろうとしていたことは、次の3つのことです。ですが、この目的に向かって、ほとんど 1mm も進んでないなという反省があって、この研究部会の形を今のまま続けるのは問題があるかなと思い、最終回にしているのです。


一つ目は：
「プロジェクトとその上位概念であるプログラムの価値、スケジュール、リスクなどの客観的な分析と評価手法を工学的に確立する」


この「工学的」が大事なんです。主観的に評価するのは簡単です。でもそれを工学的にやりたいと思った訳です。


二つ目は：
「それによって組織におけるプロジェクトあるいはプログラムの意思決定に資するとともに、プロジェクト・アナリストという専門職域を構想したい」


と考えたわけですが、残念ながらそう願う人は、ほとんどいなかった。少なくともこの国には。これが、13年間やってみた感想です。


三つ目が：
「現実のプロジェクト／プログラムの事例検討を行う。それを可能にするクローズドな場をつくる」


これはこれで少しは実践し、意義もあったと思うんですけれども、学会というのはオープンが原則なので、学会活動の一部としてやることができない、という矛盾を最初からはらんでました。まあ、ここら辺もプロジェクト・マネジメントの分野に取り組む難しさだとは思っています。


ちなみに、2016年から始めたPM教育のための分科会がありまして、いろんな方に協力いただきながら、仕組みを作り上げました。また、八巻先生には教育を実践する場として、浜松ソフト産業協会と橋渡しいただいて、毎年続けてきました。それは2日間のプログラムとして、八巻先生、串田さん、それからわたしの3人で、実施してきました。


ともあれ今日は、初心に帰って、この研究部会で何ができて、何ができていないのかを振り返りたいと思ってます。


2011年の5月に研究部会の第1回を開催しました。まだ、関東全体が毎日、余震におびえていた時期でした。第1回の研究講演はわたしがやったので、その時のパワポを今日は持ってきました。その主要部分を振り返り、その後のわたし自身の研究の進展を多少ご紹介します。


そして最後に、タイトルは大きく構えちゃいましたけど、今のプロジェクト・マネジメントについての課題、まあマネジメント自体もそうですけど、特にPM研究での課題、ないし必要な部分は何かについて、かなり個人的な意見を入れてお話しさせていただこうと思います。


ところでちょっとだけイントロを。今日は実は、この前に、東京海洋大学でPM講義をしてきました。大学でプロジェクト・マネジメントを教える際に、いつもつかっているクイズ問題があるのです。そこからスタートさせて下さい。


（注：以下は、当サイトに掲載した『モダンPMへの誘い　〜　この質問の意味が分かりますか？ 』 2024-01-14 と同じ趣旨の説明のため、こちらもご参照いただきたい）


問題プロジェクトが起きたとき、その状況をどう調べるか。皆さんが化学企業の経営者だとしたら、プロマネに何をたずねるべきか。今は21世紀なので、2000年前の始皇帝と同じことを聞いてちゃおかしいんですよね。


皆さんが経営者だったら、部下のプロマネを呼び出して聞くべきことって、実はこういうことなんです。



（1）プロジェクトの『スコープ』はどうなっているのか。WBSを見せろ。

（2）このプロジェクトの『クリティカル・パス』は何か？　Activity networkの上で示せ。 主要なリスクは何か？

（3）現在までのPV, AC, そしてEVはいくらか。完成時のCost EACを計算せよ！



少なくともわたしの会社の経営者だったら、言葉遣いは少し違うかもしれないけど、こういうことを聞きますよ。ここに出てくる三つ用語が分かるようになってくれ、っていうのがプロジェクト・マネジメントの大学の講義の目的・狙いです。


それぞれ、WBSはスコープをコントロールする道具であり、クリティカル・パスはスケジュールを予測するためのツールであり、EVMSとはコストのコントロールの仕組みなわけです。これらは最低限、必要条件として、理解してないとモダンPMが分かったとは言えない。


もちろんこれら三つが分かったからといって、プロジェクトを上手くマネージはできないですよ。必要条件であって、十分条件じゃない。でも、少なくとも、ここに出てくることが何か分からない状態では、とてもじゃないけど、ある程度の大きさのプロジェクトを計量的にマネジメントすることはできないわけです。


そのモダンPMの基本概念とは、「大きくて複雑な仕事も、単位となる要素業務、すなわちアクティビティの連鎖によって表現できる」ということです。1950年代のアメリカ人が、この事に初めて気がついたんです。それはデュポンのエンジニアたちでした。この時から、やっとモダンPMが始まった。 ほぼ同時期に、ブーズ・アレン・ハミルトンの人たちも、ポラリスミサイルの開発で、似たような概念に到達するんです。


つまり、紀元前215年から1950年までの、2000年以上の間、人類はプロジェクトって、まるごと一個しか理解できず、このでっかい丸ごとを、どうにかしようとしてきた。 それを、アクティビティと、その論理的な順序関係で表現された、ネットワークだと気がついて、そこからモダンPMが始まったわけです。


アクティビティの連載によって作られる一過性の仕事が、「プロジェクト」ということなんですね。 だからプロジェクト・マネジメントには、アクティビティ・ネットワークのシステム工学の理解が必要だとこういうことになるわけです。なるんですけれども、話は実はそれだけで済まないんですね。


というのは、プロジェクトにはいろいろなネイチャー（性質）があるからです。システム工学の立場から言うと、システムはどれぐらいの規模・スケールなのかが大事です。またもう一つは、そのシステムのいわば構造、ないしシステムのドライバー（駆動力）がどこにあるのかが、大事になります。


それをプロジェクト・マネジメントに当てはめると、こういうチャートになる。




縦軸は規模を表します。上に行くほど大きく、下は小さい。ただし異なる分野のプロジェクトの規模を、お金で比較することは難しいので、ここでは技術分野が単一に近い均質なものか、多数の分野の技術が変わるか、と書いてます。
横軸は何かというと、右側にあるのは自発型のプロジェクトです。つまり、スコープは自分で決めることができる。 自分がイニシエートできるプロジェクトです。そして左側にあるのは受注型です。わたしの勤務先、日揮みたいなエンジニアリング会社がやってるプロジェクトは、ほとんど全部これです。受注型では、スコープはお客さんが決めるっていうタイプです。
そして、この4象限のどこにあるかによって、実はプロジェクト・マネジメントに必要とされるものが変わってくるんですよね。
この右下の小型プロジェクトは、単一分野で自発型のプロジェクトです。こういう種類は、端的に言って、管理技術ぬきで、リーダーシップと気合いで、なんとか行けちゃうんです。
これが受注型になって、スコープ制約が厳しくなると、基礎的なプロジェクト・マネジメント技術が必要になってきます。
さらに、これが大型になると、専門的プロジェクト・マネジメントの技術が必要になります。そして上の右側になると、もうプログラム・マネジメントの領域になるんです。
たとえるならば、左上はオーケストラであって、いろんな専門の人たちがいて、プロジェクトマネージャーという名前の指揮者のもとに、タクトに合わせて動いてる。じゃあ右下はどうかっていうと、ジャズバンドで、指揮者がいなくても、お互いのインタープレイで動いていける。
プロジェクト・マネジメントを議論する時に、もう一つ注意しなきゃいけないのは、リーダーシップとマネジメントの区別ということです。これも経営学の世界では、いろんな流儀の定義があるんですけど、とりあえずここではこういうふうに整理しています。

マネジメントって何かっていうと、それは他人に働いてもらって目的を達することです。つまり、スポーツでいえばチームの監督の仕事です。監督は自分でバット振ったりしないですよね。指示を出すだけです。かつ、英語のマネージって、どっちかというと、御しがたい対象をなんとか乗りこなすみたいな、暴れ馬を乗りこなすイメージです。

またマネジメントってのは、普通は強制力を持ってるんですよ。いうことを聞かないと、どうなるかわかってるだろうな。こういうことを言える強制力です。 そして一番の特徴は、これです。マネジメント・システム化ができる。皆さんの会社にもクオリティ・マネジメント・システムとか、なんとかマネジメントシステムって、いろいろおありになるでしょう。システム化できるんです。

これに対して、リー ダーシップって何かというと、スポーツチームのキャプテンの役割みたいなもので、対等な仲間を動かしていくことです。 だから、マネジメントとリーダーシップの両者は、人を動かす力というところが、共通してるんです。

でもリーダーシップってのはどちらかというと、自分が強制力を持たない相手を動かすことに普通は使うので、その時には影響力を使うしかない。 かつリーダーシップっていうのは、普通は属人的で、システム化できません。リーダーシップ・システムなんて、聞いたことないでしょ？

今ここで議論したいのは、プロジェクト・マネジメントです。それは特に、図の左側の、リーダーシップと重ならない、非属人的なマネジメント技術の領域です。そして技術を開発するためには、工学的研究が必要だということで、この研究部会を始めたんですよ。 今から13年前です。

ここからしばらくですね、この13年前の研究について、少しご説明しようと思います・・




（→この項続く。ただし研究の部分の説明は省略し、次は課題と展望の部分のお話をご紹介します）

＜関連エントリ＞『モダンPMへの誘い　〜　この質問の意味が分かりますか？』 https://brevis.exblog.jp/30687052/ (2024-01-14)




]]> http://brevis.exblog.jp/32669484/ 2024-08-06T11:18:00+09:00 2025-12-31T11:05:23+09:00 2024-08-06T11:18:21+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

「プロジェクト＆プログラム・アナリシス研究部会」は、8月19日の最終例会をもちまして、活動を終了いたします。最終回は、主査を務める小職が、講演をいたします。


当研究部会は2011年5月、まだ首都圏が東日本大震災の余震で苦しんでいた時期に、スケジューリング学会下の部会として、発足いたしました。以来13年間にわたり、活動を続けてこられたのは、ひとえに参加者の皆様、そして貴重なお話をいただいた講演者の皆様のおかげと、感謝しております。


当研究会が目的として掲げたことは、以下の3点でした：

プロジェクトと、その上位概念であるプログラムの、価値・スケジュール・リスクなどの客観的分析と評価手法を工学的に確立するこれにより、組織におけるプロジェクト／プログラムの意思決定に資するとともに、「プロジェクト・アナリスト」の専門職域を新たに構想する現実のプロジェクト／プログラムの事例検討を行う。それを可能にするクローズドな場をつくる

そして例会では外部講師をお招きして、プロジェクトとプログラムに関わる様々なテーマを幅広くお話しいただき、会員でQ&Aとディスカッションを行ってきました。このディスカッションが非常に楽しく、恒例となった講師を囲んでの懇親会を含めて、有益な意見交換の場になったと思っています。テーマ設定については、あえて分野・業種を問わず、また特定のPM標準や限られたマネジメント領域に集中しないよう、工夫してきたつもりです。


日本でプロジェクト・マネジメントの考え方が受容されてきたのは2000年代に入ってからですが、その多くはIT業界における問題解決の文脈でした。そして処方箋として、内外の標準ガイドブックが紹介され、資格制度が広まった訳です。それは十分意義のある事でしたが、他方、「教科書のお勉強と暗記」「語られるのはITプロジェクト系の話題が中心」という弊害も生みました。


他方、プロジェクトの上位概念であるプログラムに目を転じると、日本ではほとんど理解もされず現実に適用もされない状況が続いています（東京オリンピックの顛末を見ればお分かりと思いますが、あれは本来、ロンドン・オリンピックのように『プログラム』としてマネージされるべきものでした）。そしてプログラム論は、経営思想やイノベーション談義という、実務にどう用いたらいいか不明瞭な領域に拡散し留まったままに見えます。


当研究会は、そうした状況に風穴を開けるべく、方向性を模索してきました。とくに2016年ごろから分科会活動として始めた、「PM教育」のためのシステム（仕組み）作りは、一定の成果を上げたと自負しています。ネットワークとしてのプロジェクトの全体像を、手を動かし目で見渡して理解する事は、プロマネのスキルを育てる上で大切な要素だと信じます。


しかしながら、当初掲げた「プロジェクトの客観的評価」「アナリストの職域確立」という目標に向かっては、ほとんど一歩も進めない状況が続いてきました。端的に言って、日本社会では初級プロマネの養成と職域確立がいまだに課題であり、投資としてのプロジェクトを第三者が価値評価し裏書きするニーズは全く無いのだ、と結論せざるを得ません。


プロジェクトの価値を考えて発進すべきかどうかを決め、また問題プロジェクトの状況を評価して撤退すべきかどうかを決めるのは、上位にあるプログラム・マネージャー（ないしプロジェクト・スポンサー）の責任です。こうした関係性の認識を広め、マネジメントの中心課題である評価と決断を、より良いものにしたいと願ってきた訳ですが、力不足もあって、進捗らしい進捗をえることはできませんでした。


最終例会では、小職が第1回例会で発表した「リスク確率に基づくプロジェクト・マネジメントの研究」の提案内容をふりかえり、その後の進展も加味しながら、プロジェクトのこれからについて率直な議論をしたいと思っています。


第1回は、副主査である静岡大学・八巻先生のお力添えで、田町にあったキャンパス・イノベーション・センターで開催しました。最終回は、同じく副主査である慶応大学・松川先生のご厚意により、新川崎にある慶応の新しくモダンなキャンパスに隣接した会議室で開催します。東京の中心部からは少し離れているため、リアルとオンラインのハイブリッド形式で開催する予定です。


大勢の方のご来聴をお待ちしております。


＜記＞
■日時：2024年8月19日（月）　18:30～20:00　（ハイブリッド形式）


■講演タイトル：
「プロジェクト＆プログラム・マネジメントの過去・現在・将来」


■概要
1. リスク基準プロジェクト価値（RPV）の概念：第1回研究部会講演の主要部分振り返り
2. その後の貢献価値理論の進展：時間短縮の価値評価、サプライチェーンの移転価格等
3. 日本のプロジェクト・マネジメントの課題と提案
　上記のような主題を中心に、ある程度自由な意見交換を行いたいと思っています。


■講師：佐藤知一　（研究会主査、日揮ホールディングス（株）勤務）


■講師略歴：
日揮ホールディングス（株）チーフエンジニア（ビジネス・アナリスト）、戦略企画オフィス経営企画ユニット所属。1982年に入社、内外の製造業とエネルギー産業の工場作りの設計とプロジェクト・マネジメントに携わる。博士(工学)、筑波大学教授（グローバル教育院）、静岡大学客員教授


■会場：AIRBIC　会議室5
〒212-0032　神奈川県川崎市幸区新川崎７－７　AIRBIC
（JR新川崎駅 徒歩10分）



■参加希望者は、小職までご連絡ください。オンライン希望の方には、後ほど会議のリンクをお送りいたします。


]]> http://brevis.exblog.jp/30687052/ 2024-01-14T23:31:00+09:00 2025-12-31T11:05:23+09:00 2024-01-14T23:31:09+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

そして、これはと思う部下をプロマネに任命し、現地に派遣する。しかし、プラントはなかなか完成しない。それどころか、現地のパートナー企業の不満の声も、あなたの元に届いてくる。そこでTV会議で現地のプロマネを呼び出し、話すことにした。では、あなたがまず質問すべき事は何だろうか？


・・これは、わたしが大学などでプロジェクト・マネジメントを教える際に、よく最初に出す問いかけだ。出席者に尋ねると、いろいろな答えが返ってくる。例えば「工事はどこまで進んでいるのか」「資材は十分に足りているのか」「労働者の質はどうか」などなど。


ここでは、プロジェクトに問題が起きている時、その全体状況を把握するには、どんな事柄を確認すべきか、を聞いている。そして、こうしたプロジェクトの状況把握の必要は、どんな業種の仕事でも、時々起こり得る。


わたし達の社会で、大きなプロジェクトにトラブルが生じた時、メディアや世間の人々が問題にするのは、どんなことか。典型的には、以下の3つの問いになるだろう。


−　いったい今まで、いくらのお金を使ったのか？
−　その仕事は、いつ完成するのか？
−　そもそもこの仕事のリーダーは、どういう人物か？　はたして信用できるのか。


例をあげよう。何年か前になるが、新国立競技場の建設プロジェクトが、世間の耳目を集めた。建築家ザハ・ハディドの超モダンなデザイン案が、国際コンペの結果、選ばれたが、当初からその実現が危ぶまれた。はたして、ほどなく経たぬうちに、建設コストの見積もりがみるみる増えていき、当初の予算を大幅に超えることが判明した。


建設工事的にも、極めて難易度が高い。本来この新国立競技場は、2020年に予定されていた東京オリンピックではなく、その前年・2019年のラグビー・ワールドカップに間に合うべく、建設する構想だった。果たして、本当に間に合うのか？　そして、そもそもこの事業を引っ張っているのは、どこの誰なのか。


一体いくらのお金の話をしているのか、いつになったら終わるのか、リーダーは果たして信頼できるのか・・こうしたことが世間で問題とされ、メディアで識者と呼ばれる人たちが指摘しあった。日本では経営資源を人・モノ・カネ、そして時間、と考える傾向が強いけれども、プロジェクトの金と時間と人を問うているのだから、まあ、平仄はあっているのかもしれない。


ところで、この3つの問いは、プロジェクトという大きな仕事を、丸ごと全体として捉えている。全体でいくら、全体でいつ、全体を誰が、と言うわけだ。こうした物の見方は、現代のみならず、戦前でも、あるいは江戸時代でも、さらに遡れば中世や古代でだって、同じだったはずだ。平安京の建設は、古代のビッグ・プロジェクトだった。そこで、問題が起きたら、人々は同じ3つの問いを語り合っていただろう。


だが、今は21世紀だ。わたし達は1000年前の人たちと同じような議論をしていて、いいのか。


それではまずい、と考えた人たちがいた。21世紀中盤、アメリカでの事だ。化学企業・デュポン社で、プラント建設プロジェクトに携わっていた人たちは、プロジェクトを丸ごと全体で捉えるだけでは、らちがあかないと気づいた。彼らはプロジェクトを、より小さな、コントロール可能な単位要素の作業に、分解することを思いついた。


逆の言い方をすると、大きくて複雑な仕事も、単位要素の作業（Activity）の連鎖によって表現（合成）できる。そしてActivity間には、論理的な順序関係（Aが終わらなければBが開始できない、等）がある。そして、Activityの連鎖によって作られた一過性の仕事を「プロジェクト」とよぶのだ、と彼らは考えたわけだ。


ほぼ同じ頃、海軍でPolarisミサイルの開発プロジェクトに関わっていたコンサルタント会社ブーズ・アレン・ハミルトンの人たちも、同様の概念にたどり着いた。「大きすぎる問題は分解して考えろ」という大数学者ガウスの格言があるが、こうした西洋の合理的思考の系譜に従ったのかもしれない。


ともあれ、プロジェクトを「Activityの連鎖からなる一過性のシステム」とモデル化したことから、真に現代的なプロジェクト・マネジメントの考え方が始まったのである。これを『モダンPM』と呼ぶ。プロジェクトまるごと全体を、「リーダーの資質」「カネと時間」「気合いと根性」などで動かそうとする、旧来のマネジメントのやり方と区別するための用語である。





モダンPMは1950年代にアメリカで現れ、’60年代のアポロ計画などによって育てられ、以後、成長と発展を続けている。その中心になっているのは、システム工学の理解＝システムズ・アプローチだ。そして定量的な理論と技法が付随している。


もしも、あなたが現代の化学企業の経営者で、部下のプロジェクト・マネージャーに対して、モダンPMの考え方で状況把握をしたいならば、上に挙げた3つの問いに代わって、次のような質問をするはずだ。


・プロジェクトの『スコープ』はどうなっているのか。WBSを見せろ。
・このプロジェクトの『クリティカル・パス』は何か？　Activity networkの上で示せ。 主要なリスクは何か？
・現在までのPV, AC, そしてEVはいくらか。完成時のCost EACを計算せよ！


これらの質問の意味が、おわかりだろうか。ここに現れる用語や概念が、現代のモダンPMの柱なのである。プロジェクト・マネジメントを学ぶとは、いいかえれば、この質問の意味を正確に理解して、きちんと答えられるようにすることなのだ。



モダンPMなど知らなくても、もちろんプロジェクトは運営できる。実際のところ、数人がかりで数ヶ月程度の社内プロジェクトだったら、気合いと根性だけで回していけるだろう。しかしプロジェクトの複雑性が増したり、規模が大きくなり、あるいは制約条件がきつくなったら、そうはいかない。単なる出金管理以上の、何らかの定量的な考え方と道具立てが必要になる。


大規模で複雑なプロジェクトに関しては、少なくとも、わたしの勤務先の経営者だったら、（言葉遣いは多少違うかもしれないが）上のような3つの問いを発するだろう。だが、こうしたことを、経営者はおろか実務レベルのマネージャー層でさえ、理解していない組織が、わたし達の社会にはたくさん存在するのである。このような面での知的貧困が、わが国の産業競争力を大きく阻害しているとさえ、言えるだろう。


そこで本サイトではこれから時々、モダンPMのいくつかのトピックを取り上げ、わかりやすい簡潔な解説をしてみたいと思っている。題して、「モダンPMへの誘い（いざない）」。拙著『世界を動かすプロジェクト・マネジメントの教科書』https://amzn.to/2FFXbkf のサプリメント版と思っていただいても良い。


小規模のプロジェクトに携わる人でも、モダンPMの基本的な理解を持っているのといないのでは、それなりの違いが出る。そしてキーとなるのは、システムズ・アプローチ＝システム工学の理解である。システムとプロジェクトに関心のある方々への、興味を引けば幸いである。


（→この項つづく）
]]> http://brevis.exblog.jp/30628158/ 2024-01-05T18:59:00+09:00 2025-12-31T11:05:23+09:00 2024-01-05T18:59:20+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般 昨年は主査である小職の多忙のため（あるいは怠けすぎて？）、6月以降に例会を開催できずにおり、まことに申し訳ありませんでした。


さて、新製品開発・新事業開発プロジェクトは、どの組織にとっても非常に重要な、しかし同時になかなか成功しにくい仕事です。とくに成熟市場を相手にした我が国の製造業は、自社の生き残りと成長をかけて取り組む訳ですが、途上には多くのハードルがあります。


今回は、航空機業界における新製品開発プロジェクトについて、（株）SUBARUの野中剛志様にお話しいただきます。周知の通りSUBARU（元・富士重工）は、中島飛行機の流れを継承する企業で、自動車のみならず、航空機とヘリコプターの製造事業も柱として続けておられます。


航空機開発は、巨額の費用と長い年月がかかり、その成否が企業自体の存続や成長を左右することは、欧米の有名航空機メーカーの例を見ても明らかです。しかも部品点数は、自動車の100倍(!)という複雑さです。こうしたプロジェクトにいかに取り組むべきか、どこが難所かを、実務経験に基づいて語っていただきます。ぜひご期待ください。




＜記＞


■日時：2024年1月24日（水）　18:30～20:30　（オンライン形式）




■講演タイトル：
「航空機開発におけるプロジェクト・マネジメント」


■概要
　航空機の開発は、大規模かつ長期間のプロジェクトになることが多く、プロジェクトマネジメントの重要性は高い。しかし、大きな開発は10年に1度程度と間隔も広く、過去のノウハウや実績データの継承、およびPM人材の育成などの面で課題も多い。
　このような航空機開発におけるプロジェクトマネジメントの実態と課題を、実務経験を踏まえてご紹介いたします。




■講師：野中 剛志　様　（株式会社SUBARU 航空宇宙カンパニー）


■講師略歴：
SUBARU航空宇宙カンパニー調達部担当部長。2002年から約10年間、P-1/C-2開発においてSUBARU分担部位（主翼等）のプロジェクト管理に約10年間従事。その後も一貫して生産管理畑。現在は調達部でSCMのDXに取り組む。




■参加希望者は、小職までご連絡ください。後ほど会議のリンクをお送りいたします。


■参加費用：無料。
ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（￥1,000）は免除されます。


以上、よろしくお願いいたします。






佐藤知一＠日揮ホールディングス（株）


]]> http://brevis.exblog.jp/30418309/ 2023-08-20T22:26:00+09:00 2025-12-31T11:05:23+09:00 2023-08-20T22:26:22+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

それは研修に何を求めるかによって、異なるはずだ。知識伝達型の座学は、資格試験の合格を目指すケースに多い。資格制度ではなくても、社内や業界内で確立されたプロジェクト・マネジメントの手順や書式について、伝授するような目的にフィットしている。


テーブルを囲んで議論するグループ演習タイプの研修は、 もう少しソフトで不定形な、 もやっとした種類のプロジェクトを、どうやって乗り切るかが主題になる。テーマは、デザイン思考だったり、ステークホルダー対応だったり、リスク対策だったり、あるいは部下の使い方一般に関することだったりする。新兵訓練型トレーニングは、PM界では最近ほとんど見かけないので、略そう。


ちなみに、座学で伝達可能な情報や技法を中心としたスキルを「ハード・スキル」と呼び、 創発的でやや定性的な問題解決などの能力を「ソフト・スキル」と呼ぶ。 後者は「人間力」などと呼ばれたりもする。ハードスキルは、ペーパーテストでの評価に向いている。後者は、状況の個別性に依存する分が大きいので、ペーパーテストで判定するのは難しく、経験した時間数や年数等でおよそ推察されることが多い。


もう少し言い方を変えれば、座学による情報伝達中心の教育プログラムは、「インプット学習」のためのものだと言える。 他方、グループ編集による問題解決の研修方法は、「アウトプット学習」に向いている。 そしてインプット学習とアウトプット学習の2つは、本来上手に組み合わせて使うべきものだ。


わたしは15年ほど前から、大学でプロジェクト・マネジメントの講義をずっと続けている。法政を皮切りに、東大、静岡大学、そして筑波大学と、都合により時期や場所を変えつつ、学部や大学院で1学期単位の授業を持ってきた（他の先生と2名で分担するケースもあるが）。いずれのコースでも、全体の前半はインプット学習、後半〜最後の部分は、グループ単位でのアウトプット学習を活用している。


悩ましいのは、むしろ社会人相手の研修だ。大学生よりも、社会人の方が、ずっと研修意欲が高い。 実際のプロジェクトで苦労した経験があるだろうから、当然のことだ。しかしその代わりに、研修を受けるまとまった時間がなかなか取れない。 丸1日か、せいぜい丸2日。それが限度らしい。


だがこれでは、大学1学期分の講義を教えることはできない。PMBOK Guideが長らくカバーしてきた、10の知識エリア・5つのフェーズを、本当ならば全部触れておきたい。そうしないと、10エリアの中心に位置する「プロジェクト統合マネジメント」が、うまく理解できないからだ。そしてここがわからないと、プロジェクトで良い決断を下すことができない。


プロジェクトになぜ、「統合マネジメント」が必要なのか？　それは、プロジェクトにおけるスコープやコスト、スケジュール、品質、リソース、リスクといった要素が、お互いに関係し、あるいはトレードオフを形成しているからだ。


つまり端的に言って、プロジェクトとは「システム」なのだ。システムだから、その中の1つの要素は、他とつながりあいながら機能している。ただしプロジェクトと言う名のシステムは、携帯電話や人工衛星と違って、目に見えない。アクティビティ（単位作業）のネットワークによって構成される、一過性のものだからだ。


この「システム的なプロジェクトの見方」を理解してもらうには、二つのアプローチがある。一つは、プロジェクト計画立案のステップを順次追いながら、それぞれの関係性を学ぶ方法。もう一つは、自分の目や手を動かしつつ、議論を通して、体得する方法。前者は座学セミナー的な枠組みになんとかはまる。後者は、リアルなグループ演習の方が望ましい。


わたし自身は、1日オンラインセミナー形式で前者を、そして2日間のリアルセッション形式で後者を、カリキュラム開発して提供してきた。今年も、9月28日に1日オンラインセミナーを、そして10月25日と11月3日に浜松で2日間リアルセミナーを開催することになった。


今回はまず、9月28日のお知らせをさせていただこう。浜松のセミナーについても、近々詳細が固まるはずなので、決まり次第こちらでご案内するつもりだ。




記


来る9月28日（木）に、プロジェクト・マネジメントに関する1日セミナーを行います。プロジェクト計画と遂行の基本となる、PM「7つ道具」をはじめ、プロマネが身につけるべき基本的なスキルと技術について、解説します。


オンライン形式ですが、グループ演習などもできる限り取り入れて、具体的な学びにつながるセミナーにするつもりです。遠隔地の方も参加しやすいと思いますので、ご検討ください。


「プロジェクトを成功させる実践マネジメント技法とそのポイント」（9月28日）


日時：　2023年9月28日（木）　10:30 ～ 17:30
主催：　株式会社日本テクノセンター
セミナー詳細：　下記のURLをご参照ください（受講申込もここからできます）
https://www.j-techno.co.jp/seminar/seminar-56392/



大勢の方のご来聴をお待ちしております。




佐藤知一@日揮ホールディングス（株）






]]> http://brevis.exblog.jp/30137978/ 2022-10-06T22:48:00+09:00 2025-12-31T11:05:23+09:00 2022-10-06T22:48:21+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般


「システム・インテグレーター（SIer）というビジネスは、本当に今後も存続できると思いますか？」——この問いを、わたしはときどき、IT業界の人に聞いてみている。


ご存じとは思うが、SIer（エスアイヤーと読む）は、ITシステムを受託開発する企業のことだ。分野は業務系システムが多いが、ECサイトや組込系のこともある。運用もときには受託するが、Integration（＝まとめあげる）の語が指すように、構築が主な仕事である。そういう点で、同じIT業界でも、パッケージソフトを販売したりSaaS提供したりするビジネスとは区別される。


SIer企業は、デジタルに関わる高度な知識や技術を有しているし、今のDXブーム時代に、ユーザ企業から受託してシステム開発を行う、花形的産業であるはずだ。そのビジネスの将来性を問うているのだが、誰に聞いても答えは今ひとつ、かんばしくない。理由は、なかなか儲からないからである。


なぜ、儲からないのか。それなりに価格競争が激しい上に、ときどき手痛い赤字をこうむることがあるのだ。受託IT開発ビジネスは、毎回異なるシステムを設計し、作る商売だ。そういう点で、ビルや学校やマンションなどの建物を受託建設するゼネコン業界と、少し似ている。そして多重下請け構造である点も、建設業に近い。


毎回異なるものを作って提供する。それも複数の人間や企業が協力しなければならない。失敗のリスクもある。こういう仕事を『プロジェクト』という。SIとはプロジェクト・ベースのビジネスなのである。プロジェクトがときに失敗してひどい赤字になるのは、「プロジェクト・マネジメント」が上手くないためだ。だからIT業界は、プロジェクト・マネージャー人材を育てなければならない。こういう問題意識は、米国では90年代から広まり、日本では少し遅れて2000年代に言われるようになった。


プロジェクト・マネジメント(PM)への期待と不安



米国発で世界最大のPM団体であるPMI (Project Management Institute)が、'90年代初頭に策定した標準書「PMBOK Guide」が広く読まれ、それに基づく資格試験制度PMP (Project Management Professional)に大勢が取り組んだのは、こうした背景があるからだ。


だが、それでSI業界の問題が解決したのか？　そこは難しいところだ。たしかに大手や中堅SI企業では、PMの考え方や手法を確立・普及するために、PMO (Project Management Ofiice)等と呼ばれる専門組織を作った。また見積時点でリスクレビューを行い、危ない仕事は受託しないようになった。そういう点では、一定の効果があったと言えよう。


しかし、まだ多くの案件で顧客要求と契約条件の折り合いに苦労している。またプロジェクト規模が大きくなると、外注先の納期や品質のコントロールに手を焼いているのが実情だ。


他方、受託開発の赤字で火傷を負った中堅以下の企業では、自社でのプロジェクト・マネジメントをあきらめ、ITエンジニアの実質的派遣業であるSES (Systems Engineering Service)にシフトした会社も少なくない。しかしこれはこれで、人材のモチベーション維持が難しくなる。業界は若手の人材流出に悩んでいる。


このような状況になった理由の一端は、PMBOK Guideだけを学んでも、あまり現実の役に立たないからだ。そういう声が次第に、米国でも強くなったようだ。日本と米国では、IT業界のあり方が大きく異なるが、ITプロジェクトが難しい点は、共通している。米国のPMやBA（ビジネス・アナリスト）の大会に参加すると、それを肌身で感じる。


かくてPMBOK Guideは、昨年の第7版から、内容を大きく改訂した。それは初期の"Do things right"＝効率的なプロジェクト遂行、から、"Do right things"＝プロジェクトのアウトカム重視、へのシフトだった。この変化の背景には、IT業界の不満があったはずだ。アジャイル手法を大きく取り入れたのも、その一例だ。ただしその分、プロジェクト・マネジメントの技術論が薄れ、背景に退いたと言えなくもない。そして前景の主文の方は、なんだか米国流の精神論を読んでいるような感触におそわれることがある。


新しい、日本人向けのPM教育へ



わたしが主催する「プロジェクト＆プログラム・アナリシス研究部会」で、PM教育分科会を立ち上げ、新しいプロジェクト・マネジメント教育の仕組みをつくり始めたのは5年ほど前のことだった。活動の背景には、既存のPM教育や標準書に対する不満があった。対象分野はITに限らないつもりだったが、興味を持って参加してくれたメンバーの多くは、IT系のエンジニアだった。


ただし、最初に決めた方針が一つあった。それは、「火消しの演習」にはしない、ということだ。IT業界にはどこか、プロジェクト・マネージャー＝プロの火消し人、といったイメージが残っている。でも、火事を防ぐのがプロマネ本来の仕事のはずである（ちなみに火消しの方が目立つので会社で評価されやすい、という状況はあるが、それは人事評価に関する別の問題だ）。苦労しない方が、自分にとっても関係者の誰にとっても良い事である。


そこで、わたし達が重視したのは、プロジェクトの状況を把握し、問題を予見（予防）する能力の醸成である。そのためには、プロジェクトの構造を理解しなければならない。どういう要素から成り立ち、どこをどう押すとどう動くのかが、ある程度客観的・定量的に見通せなければならない。そこには技術的な頭の働かせ方が必要である。


プロジェクトを目に見えないシステムとして理解する



もともと現代PM理論の発端は、1950年代の米国にさかのぼる。大きくて複雑なプロジェクトも、単位的な作業（Activity）のネットワークによって表現（合成）できる。このことに気がついたのは、化学プラント建設に携わっていたデュポン社の人達だった。


それ以前は、プロジェクトを全体ひとまとまりを事業として、マネージしようとしてきた。それを単位要素とその機能的なつながりとして、すなわち目に見えないシステムとして理解し、予測できると気がついた点が、真のブレークスルーだった。


ほぼ同時期、海軍のポラリス・ミサイル開発プロジェクトに関連して、コンサルのブーズ・アレン・ハミルトン社が、プロジェクトを構成するActivityの期間や費用に三点見積法を導入することを思いついた。彼らはこの手法をPERT (Project Evaluation and Review Technique)と名付けた。PERTは後にデュポン社のCPM (Critical Path Method)と組み合わさって、PERT/CPMと呼ばれるようになった。


プロジェクトの構造を理解するとは、Activityのネットワークとその挙動を理解することである。これはまさに、システム工学に他ならない。だから本当は、システム・エンジニアこそ、PMに最も適した人達であるはずなのだ。


わたし達のPM教育の仕組みは、何回かの試行錯誤を経て、Activityのカードを実際に目の前に並べて、ネットワークを作る演習に仕上がっていった。手を動かすことで、本当に頭に残る事柄もあるのだ。もちろんネットワークを作るのが最終目的ではなく、それを見て、どこに弱点があり、どう改善すべきかを考えられるようになることがゴールである。



お知らせ：10月26日・11月3日に2日間コースのPM研修を開催します



という訳で、お知らせです。10月と11月にかけて、われわれの研究部会が開発したカリキュラムによる2日間コースのPM研修を開催します。今年は4年目で、毎年バージョンアップしてきていますので、内容は自信を持ってお勧めできます。


初日は、静岡大学名誉教授の八巻直一先生によるPERT手法入門と演習です。八巻先生は日本のOR学会の大家ですが、実は元々ソフトウェア企業の経営者から学者に転じられた方なので、実務にも良く通じておられます。


二日目（祝日）は、わたしと串田悠彰氏が、PERT／CPMのケーススタディとリスクマネジメント演習を行います。串田氏もソフトウェア企業出身です。ケースは生産管理システム導入を題材とする予定ですが、もちろんIT以外の業種の方でも参加できるよう、工夫しています（例年、とくに製造業の開発設計に関わる方が参加されています）


有償セミナー、かつ直前のお知らせになってしまい恐縮ですが、まだ残席がありますので、ご興味がある方はぜひご参加ください。今年はハイブリッド開催ですので、浜松の会場参加も、オンライン参加でも可能です。また（自分で言うのも何ですが）講師との、Q&Aによるライブな意見交換も、セミナーならではの価値だと思っています。


開催案内と申込みは、下記をご参照ください：
「プロジェクトマネジメント研修～リスクマネジメント編～」ご案内　（株式会社 浜名湖国際頭脳センター）


プロジェクト・マネジメントに感心のある皆様の、積極的なご参加を心からお待ちしております。




佐藤知一@日揮ホールディングス（株）
]]> http://brevis.exblog.jp/30077041/ 2022-08-20T11:56:00+09:00 2025-12-31T11:05:23+09:00 2022-08-20T11:56:25+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

あなたがまず、やるべき事は何だろうか？


まずはプロジェクト・チームの部屋に行き、前任者のプロマネの席に座ってみる。周囲のメンバーはあなたを、怪訝そうな、あるいは不安と好奇の混じった目で見ている。


とりあえずは皆を集めて、ミーティングを開く。席上であなたは、前任者が都合でプロジェクトを離れざるを得なくなったこと（それは皆も知っていたが）、自分がその役割を引き受けたこと、まだ様子が分からないから皆に教えてもらいながら前に進みたいこと、心配しないでこれまで通り職務に邁進してほしいこと、などを伝える。そしてあなたからはじめて、順に時計回りで自己紹介をしてもらう。だが、親しい人間は残念ながら一人も居なかった。


席に戻って、小さなため息をつく。ともあれ、プロジェクトの状況を知らなければならない。でないと、何についても決断は下せないのだ。でも、プロジェクトの状況を知るとは、具体的にはどこからどう、手をつけたら良いのだろう？　何が分かれば、「このプロジェクトの状況は大体分かった」と言えるのだろう？


あなたはもっと小さなプロジェクトのリーダーをやったことはあった。また、その時の体験から、少しはプロジェクト・マネジメントについても知っておく必要があるなと感じて、手の空いたときに勉強もしてみた。そこで、プロジェクトで一番大事なのは、スコープ・コスト・スケジュールの三要素だ、と学んだ。


コストは、もちろん原価のことだ。プロジェクトが守るべき予算は決まっている。それを超えることは原則、許されない。またスケジュールはいうまでもなく期間で、これも完了期限が決まっている。とくにこのプロジェクトの場合は、会社単位のイベントに紐づけられているので、期日の縛りは大きい。つまり、コストもスケジュールも、守るべき制約条件なのだ。


では、スコープとは何か。スコープとは制約条件なのか？　あなたは勉強した内容を思い出してみる。スコープとは、プロジェクトが果たさなければならない責任範囲を示す。「スコープが増えた」といったら、それは責任範囲が、つまりやるべき仕事が増えたことを意味する。


ただし、コストは円単位で、スケジュールは日数の単位で、計量化することができる。じゃあスコープは？　これは数値化するのが難しそうだ。ただ、増減や大小は比較できる。だからまあ、制約条件だと言えなくもない。


とにかく、まずはスコープ・コスト・スケジュールを知らなくてはならない。あなたの前任者は、一応「プロジェクト・マネジメント計画書」という書類を作って本社に登録してあったが、中身を見ると、完了期日と予算枠の金額以外は、ひどく抽象的なことしか書いていない。これで会社はよく承認したな。


ともあれ、スコープ＝責任範囲を知るには、どうしたらいいか？　そのためには、このプロジェクトが生み出すべき成果物、アウトプットは何なのかが、分かれば良いはずだ。何を作れば、このプロジェクトは終わることができるのか？　


そう。プロジェクトとは、終わりのある仕事なのだ。プロマネたる自分の任務とは、この仕事が無事に終わるよう、頑張ることだ。だからまず、ゴール地点の姿を理解しなければならない。


あなたはチームの中でもチーフ格にみえたメンバーに、成果物の全体像が分かる資料がないか、たずねた。すると、「プロジェクト開始時点にもらった仕様書です」という書類をすぐに出してくれた。あなたはざっと目を通してみる。うーむ、こんなものを作るのか。


それは一種の、環境モニタリング・システムだった。複数地点に計測器を配備し、継続的にCO2排出その他の環境負荷データを収集、専用サーバに記録保持する。SDGsとカーボンニュートラルが重視される今日、重要な仕組みだ。


ただ、そうなると、現地での設置作業や調整なども必要になる。成果物としてのハードやソフトを作って、誰かに渡したらお仕舞い、という訳にはいかない。関係者との調整作業も必要だ。成果物づくりに関わる以外の仕事もそれなりにある、ということだ。おまけに技術的に見ても、従来やったことのない機能を含んでいるようだ。つまり、技術開発要素があるのだ。だから試験も必要だ。


ともあれ、いつまでに、何を、いくら以内で作って動かさなければならないかは、分かった。ゴール地点の姿は、少しは見えてきたようだ。

だが、これでプロジェクトの状況把握が終わった訳ではない。今、プロジェクトはどこの地点にいるのかが分からなければならない。つまり、進捗と出費の実績を把握する必要があるのである。


プロジェクトの工程表を探したが、あなたの前任者は、線が4本引いてあるだけの、非常にラフな線表しか残していなかった。いやはや。予算表も、探したけれど見つからなかった。一体何を、マネージしていたのだろう？


仕方がないので、あなたはプロジェクト・チームのメンバーと、グループ毎に面談することにした。ところがこのミーティング、状況把握の目的のはずが、技術の問題や人間関係の問題を訴える場になっていき、毎回、決めたりなだめたりしなければならない事が、あなたの前に積み上がるばかりである。


数日後、元のオフィスに戻って上司をつかまえる。状況報告をして、方針やアドバイスをもらいたいと思ったからだ。だが、他にトラブル案件を抱えているらしい上司は見るからに多忙で、「後はよしなに」というだけだった。


まいったな。こういうとき、プロジェクト・マネジメントの標準では、何と何をおさえるべき、と書いてあるんだっけ？　あなたは、昨年買ったが、読まずに積ん読になっていた『PMBOK Guide』第7版をめくってみた。何なに、プロジェクト・パフォーマンスには８つの領域があるって？　これかな？


その8領域とは、ステークホルダ、チーム、開発アプローチとライフサイクル、計画、プロジェクト作業、デリバリー、パフォーマンス計測、不確実性、の８つだった（ちなみにあなたは、英語版を入手して読んでいたので、上記の用語は日本語訳とは一部合致していない）。


うーん、何だか分かったような、分からないような・・ステークホルダやチーム員の把握が大事なのは当然だろう。だが計画はメロメロだったし、プロジェクト作業の把握って？　それにパフォーマンス計測が別にあるのか。心配なのは設計の品質なのだが、それは計測できるのかな。なんだか頭がぐらぐらしてきた。


10日ほど過ぎ、飛び石連休がやってきた。あなたは、以前知り合った、別の会社のベテラン・プロマネを訪ねることにした。自分の仕事の内実を話すのは恥ずかしかったが、せめて何かアドバイスをもらえないかと思ったのだ。


もちろん技術面の詳細や予算枠など、社外の人には話せない部分もあった。が、とにかく自分が曖昧ながら把握したプロジェクトの状況を、あなたはその大先輩に説明してみた。そしてPMBOK Guideも参照してみたが、適用の仕方がよく分からなかった、とつけ加えた。するとその先輩は、意外な事を質問してきた。


「あなたは自分のプロジェクト・チームに、誰を配員するかについて、権限はあるんですか？」


——いえ、ありません。それは上の人間が決めることです。


「チーム員の人事的な査定はするんですか？」


——いえ、それもしません。僕は彼らの直属の上司ではありませんから。参考意見を聞かれることはありますが。


「じゃあ、あなたは予算の枠内で、発注先を選んで、自分の権限で発注できますか？」


——発注には上司の承認が必要です。文房具とか小さなツール類は別として。


「なるほど、そうですか。だいたい分かりました。あなたは人事権、つまりアサインメントや人事評定の権限もなく、発注先を自分一人で選んで発注書を切れる訳でもない、と。」


——はい。


「そしてスコープ（成果物の機能範囲）も、コアの技術も事前に決まっている。最終期限も決まっている。できるのはスコープの若干の調整と、人とタスクのアサイン配分によるスケジュールの調整だけだ、と。そういう理解でいいですね。」


——その通りです。それでは何かまずいでしょうか。


「いいえ。ただ、もしそうなら、あなたはプロジェクト・チームの実務レベルのリーダーではあっても、『プロジェクト・マネージャー』とは呼べないですよ。マネージャーというからには、プロジェクト目的の達成に責任を負う訳です。その責任を果たすには、当然ながら権限が必要です。権限なしに責任はない。PMBOKは、マネジメントのための標準体系です。あなたの仕事がマネージャーでないなら、適用できる訳がないと、思いませんか？


——たしかに、しばらく前までは会社ではプロジェクト・リーダと呼んでいました。でもその後、マネージャーという呼び方に変わったんです。


「呼び方がどうであれ、中身が変わらないなら同じですよ。」


——でも、僕はプロジェクトの達成には責任を持っていますよ。


「良い心がけです。では、教えてください。あなたのプロジェクトの目的は何ですか？」


——目的は、環境モニタリングシステムを作って、立ち上げることです。


「それはゴールに過ぎません。つまりプロジェクトの完了条件です。お伺いしているのは目的です。」


——・・目的って、ゴールじゃないんですか？


「違います。マラソン競技の目的は、42km離れたゴール地点にたどり着くことだと思いますか？　長距離走をやる人間なら、ゴールにはたいてい、入れます。大事なのは、なぜマラソンに参加したかです。それと同じで、なぜ環境モニタリングシステムが必要なのか、それでどんな良いアウトカムが生まれるかを、考えなければなりません。それが目的というものです」


——うーん・・そうですか。でも、自分が仮にマネージャーでなく単なる実務リーダーだとしても、プロジェクトの状況を把握しなければならない事に代わりはありません。いったい、何と何をおさえたらいいか、教えていただけませんか。


「そうですね。そういう時、PMの実務では、7つ道具というか、整理すべき図表が７つほどあるんです。まあ、８つの場合もありますが。それによって、あなたのおっしゃった、スコープ、コスト、スケジュールの他に、組織やリスクなどを含めて、プロジェクトの現在位置を総合的に把握できるようになります。」


——それを、ぜひ教えてください。


「いいですよ、多少説明に時間はかかりますが。ただ、その前にもう一つ、念を押しておきたいことがあります。ゴール地点と、現在位置が分かったとして、それからどうします？」


——それから、って・・そりゃゴールへの道を邁進するのみです。他に何をするんです？


「あなたは前任者からの引き継ぎもなしに、見知らぬプロジェクトに放り込まれました。会社も、今のプロジェクトの状況を把握できていないでしょう。だとしたら、全速力で残りの道を邁進する前に、もう一つ考えるべき事があります。それは、本当に今のままプロジェクトを続ける価値があるのかどうか、です。


——続けるか、どうか・・？


「そうですよ。現在位置とゴールとの距離が分かったら、いつ、たどり着けるのか、それまでどれくらい労力がかかるかも、想定できるはずです。その上で、ゴールで得られる価値と、この先にかけなければならない労力やコストを比較するべきです。それが明らかに不釣り合いなら、プロジェクトは中止すべきでしょう。


——それを、僕が決めるんですか？


「いえいえ。決めるのはあなたの上司であり、会社です。ただ、あなたはご自分のアセスメントを報告する訳です。プロマネは一般に、自分に付託されたプロジェクトを途中で止める権限はありません。ですが、もうこれ以上、努力する価値がないと考えられるなら、率直に報告すべきです。」


——・・そんなの、前代未聞です。ギブアップ宣言じゃないですか。クビになりかねません。


「すでに失敗が見えているプロジェクトを止めなかったら、それは経営の失敗になります。経営の失敗の方が、ずっと被害が大きいのです。別にあなたの今のプロジェクトが失敗だと言っているのではありませんよ。一般論として、です。」


——もちろん、分かりますけれども、ただ・・それって自分の仕事なのかな。


「プロジェクト・マネジメントの目的って、何だと思います？」


——え？　プロジェクトの目的と同じじゃないんですか。


「違います。プロジェクト・マネジメントの目的とは、プロジェクトの価値を最大化することにあるのです。」


——プロジェクトの価値を最大化、ですか・・


「プロジェクトの価値には、金銭で測れる部分と、人材育成や顧客の信頼など、無形の価値があります。ですから、単なるコスト計算だけで決められるものではありません。ともあれ、仮にもし人員や費用を追加投入することで、それを上回る価値増大が期待できるなら、追加すべきですし、自分に権限がないのなら、会社に理解を求めるべきです。逆に、万が一プロジェクトを継続することで、かえって価値を毀損するならば、止める勇気を持つ方が良いのです。


——プロマネって、そこまで考えるべきものなんでしょうか。


「まあ現実には、ここまでできる人は少ないでしょうね。ただ、プロジェクトとは価値創出のための活動であることを忘れないでください。そしてプロジェクト価値を総合的に判断することは、現場で最も情報の集中している、プロマネにしかできないことなのです。」




◇- — -◇- — -◇- — -◇- — -◇


ここからは、お知らせです。来る9月29日（木）に、久しぶりにプロジェクト・マネジメントに関する1日セミナーを行います。上に書いた、プロジェクトの状況を把握するための、PM「7つ道具」をはじめ、プロマネが身につけるべき基本的なスキルと技術について、時間をかけて解説します。


オンライン形式ですが、グループ演習などもできる限り取り入れて、具体的な学びにつながるセミナーにしたいと考えています。遠隔地の方も参加しやすいと思いますので、ご検討ください。




「プロジェクトを成功させるマネジメント技法とその実践ポイント」（9月29日）


日時：　2022年9月29日（木）　10:30 ～ 17:30
主催：　株式会社日本テクノセンター
セミナー詳細：　下記のURLをご参照ください（受講申込もここからできます）
https://www.j-techno.co.jp/seminar/seminar-50594/


大勢の方のご来聴をお待ちしております。


佐藤知一@日揮ホールディングス（株）


]]> http://brevis.exblog.jp/29805683/ 2022-01-10T15:24:00+09:00 2025-12-31T11:05:23+09:00 2022-01-10T13:26:05+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

さて、年初なので、少し基本的な問いを考えてみよう。プロジェクト・マネジメント・システムは存在するのか、しうるのだろうか、という問いである。


「マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。


わたしがここで問題にするのは、後者である。つまり、プロジェクトをマネジメントしてくれるソフトウェアは存在しうるか？　との問いだ。この問いに答えるには、プロジェクト・マネジメントとは何か、あるいは、プロジェクト・マネージャーの仕事とは何なのか、を考えねばならない。


プロマネの仕事の中心には、「決めること」がある。したがって、少なくともプロジェクト・マネジメントの重要な要素として、何らかの「決断」があるはずだ。


今の世の中には、データさえ蓄積できれば、AI・アナリティクスで自動判断できるようになる、という楽観的な信憑がある。したがって、将来はAIがプロマネのかわりに判断してくれるようになる——のだろうか？　ちょうどAIによる自動運転が、人間を車の運転から解放してくれるように。


そういった将来像を描く人もいるだろうが、とりあえず、まだそれは現実ではない。では現時点でのプロジェクト・マネジメント・システムとは、何をするのか。プロマネの判断を「助けてくれる」のだろうか？　そして将来的には、自動判断に発展する可能性を持つものなのだろうか。そんなシステムは存在しうるのか。


別にわざわざ、そんな問題を立てる必要は無い。現にお前さんの働く会社だって、プロジェクト・マネジメント・システムを持っていると、言っているじゃないか。そんなご指摘が、読者の間から聞こえてきそうである。


ごもっとも。日揮のPMS(Project Management System)については、Webサイトでも情報を公開している。
https://www.jgc.com/jp/business/project-management/


このPMSはどのようなITシステムなのだろうか。本システムは主に、プラント系のプロジェクト向けに作られている。プラント系プロジェクトは普通、EPC (Engineering=設計, Procurement=調達, Construction=建設）の3フェーズ（3業務）からなっている。そこで日揮のPMSも、
Engineering Management SystemProcurement Management SystemConstruction Management Systemの大きな3つのサブシステムと、それを取り巻く周辺システム群からなっている。


そしてそれぞれが、プラント系プロジェクトを動かす主要素である、「設計文書・図面」「資機材」「建設工事作業」について、いわばマスターリストを保持し、それらにまつわるコスト・スケジュール・リソース等の、データを集約する機能を持っている。


（ただし、今ウェブサイトを見てみたら、英語の説明の図はちょっと内容が古いなぁ。直してもらわなければ。連休明けにやらなければいけない仕事が増えてしまった・・）


日揮のPMSは、長い歴史があるため、ほとんどが自社製（一部パッケージベース）の作り込みである。


では、このシステムがあるため、日揮のプロマネは大船に乗ったような気分で、着実に心配なく仕事ができるのか？　自分は要所高所の判断だけを下し、後はシステムが皆を采配して仕事を進め、結果として納期も守り、利益も上がるのか。そうだ、と答えたいところだが、現実は全然違う。


現実のプロジェクトはリスクの塊である。プロジェクトとは、最初に労力や資金を投入して、最後に価値あるアウトカムや利益を得る、一種の賭けなのである。プロマネの仕事とは、プロジェクトをマネジメントするとは、上手に賭け（仮説）を仕立てて、人々をそれに向けて動かし、見事にその果実を得ようとするところにある。


マネジメントは管理ではない。このことは何度か、このサイトでも書いた。英語のマネージManageとは、御しがたいものを、自分の意図や目的に沿うように動かすことである。暴れ馬を乗りこなすイメージだ。英語で、I can manage my car.といったら、その人の車には何か問題があるのだな、ときいた人は思う。


仕事におけるマネジメントの概念の中核には、「人を動かす」「人に働いてもらって目的を達する」という意味がある。自分自身で手を動かして、具体的な成果物を作ることは、マネジメントではない。成果物を作ること自体は立派な仕事で、それがなければプロジェクトは前に進まない。だがマネジメントとは、そうした仕事を方向付けし、組合せ、采配して、総体として機能し価値ある成果をインテグレーションすることにある。


もちろん、日揮のプロマネはPMSがなかったら、仕事にならない。そうでなければ10万点を超える図面や仕様書、100万点近い資機材を、どうやってコントロールするのか。ただ、それはプロジェクト・マネジメントにとって必要条件だが、十分条件ではないのだ。PMSがあればプロマネが不要になる訳ではない。


（あなたが製造業の人なら、たとえば考えてみて欲しい。生産管理システムは生産をマネジメントしてくれるのか？　工場長は不要になるのか？　もちろんそんな事はない。生産管理部長が不要になることだって、まったくない）


そもそも、プロマネの仕事とは何か。プラント系プロジェクトの枠を離れて、少し一般化して考えてみると、以下のような要素からなることが分かる：


プロジェクトをデザイン（計画）し、組織とルールと手順をつくりゴール・目的・目標などビジョンを示してチーム員を引っ張り人に仕事をアサインし、指示を出しステークホルダを説得してプロジェクトに協力してもらいリスクを予知して事前対策を講じ途中途中で進捗やコストや中間成果物の品質を確認し外部環境変化や内部状態の変化から生じる問題を検知・分析し予測と価値評価を行い適切な決断を下しプロジェクトの着地点を見据えて皆をモチベートしプロジェクトの成果物や所産をアウトプットを、適切なアウトカム（運用や価値など）につなげ経験からの学びをLLとしてまとめる

こうした職務を進めるのための要件をまとめると、５つくらいに集約できそうだ。


1. 価値観が必要


決断を下すためにも、人にビジョンを示して引っ張るためにも、何が価値あることなのかについての基準をしっかり持つ必要がある。え？　企業活動ならば、利益を最大化することで、すべては尽きるはずって？　そうだろうか。たとえば、実績づくりや人財成長など、非金銭的価値はどうするのか。これらも含めて、決断が必要なのだ。


2. プロジェクト・デザインの能力が必要


プロジェクト初期における計画や組織づくりにおいては、全体の仕事をどのように分割し（あるいはモジュール化して）、どこを誰にやってもらうのが適切かを考える仕事がある。妙な切り方をするとインタフェースが増えて、トラブルの原因になる。手配可能なリソースには限界もあるし、適性もある。こうした仕事（Work framingとも呼ぶ）は、一種のデザインに属する。デザインは本質的に、サイエンスとアートの中間領域にあって、センスを要求される。


3. 対人的なコミュニケーション能力が必要


プロマネはその時間の半分を、人とのコミュニケーションに費やす、とよく言われる。マネジメントが人を動かす仕事である以上、ある意味で当然なのだろう。それも、相手はチーム員だけでなく、社内外の種々のステークホルダ達である。したがって人を動かすといっても、単なる命令ではなく、説得とリーディングが要求される。おまけに、人と人の間には、どうしても面子や好き嫌いといった、ヒューマン・ファクターが大きくからむ。何を言うか、だけでなく、誰を通じてどう言うか、までが賢慮の範疇である。


4. 予測（あいまいさ＝リスクを含む状況下で）の能力が必要


プロジェクトはリスクのかたまりであり、また現状把握それ自体も案外難しく、曖昧さの残る状況で、先を見通さなくてはならない。もちろん、誰しも100%先のことが分かるはずはない。ただ、洞察力は、環境変化への適応性を高める上で、必須である。


5. 結果を引き受ける責任感（覚悟）がある


うまくプロジェクトをデザインし、先を見通し、価値観を持って人を説得したとしても、そのプロマネが最終的な結果を、良し悪しを含めて引き受ける責任感が必要だ。そうでなければ、そうでなければ、誰がプロマネの言うことを聞くだろうか？


以上、どうみても、この５つの要件全て、機械化・自動化は困難だろう。賭けたっていいが、10年、いや100年たっても、AIではできっこない。そのような意味では、プロジェクトをマネジメントしてくれるシステムは、存在しないと言っていい。


では、現実のソフトウェアは何ができるのか、何をさせるべきか。それについては、IT分野の人たちは、様々な業務型システムでの経験から言えることがあるはずだ。


普通は、まず記録（実績）系の機能からスタートする。


プロジェクトで言えば、まず受発注からだ（日揮でもそうなっていた）。企業として、外部企業とのインタフェース記録を残す必要があるからだ。入出金については、会計ソフトがある前提としても、モノの入出荷の実績は（ものを扱うプロジェクトならば）必須だろう。


さらに記録と言う面では、情報（ドキュメント）の登録保管、人の実績工数（タイムシートからの集計）なども機能として欲しくなる。


実績系のつぎは指示（計画）系の機能が来る。


プロジェクトと言えば、実行予算計画が必要だ。また、モノの種類と数量に関する指示（計画）が、加工や移動にともなって、ほしくなる。


さらに、人のかかわる作業＝アクティビティに関する指示（ワークオーダー）へと、機能面の要望は進むだろう。とくに、モノに関わる現場的作業だけでなく、設計等の知的作業についても、計画と指示の必要性が出てくる。


ところが、実は日本ではこれが難しい。まず、日本の商習慣のために、顧客や外部からの変更要求が多い。もう一つ、日本では働く人がおおむね優秀なので、自分から指示を待たずに動いてくれる。それはとても大事でありがたいことだが、逆に指示する側が、多少曖昧で大雑把でも、仕事が動いてしまう。これはアジアを含む海外ではあまり期待できないことだ。


おまけに実際の遂行段階で、問題が生じると、計画していなかった作業が頻繁に発生する（設計変更対応等はその良い例である）。こうした問題があるために、ざっくりとした工程計画だけ立てて、詳細は現場で担当者同士が、別のExcel表などを使って調整したりする。


こうなると、現場にいちいち確認しないと、進捗の途中経過が見えなくなる。負荷も余力も分からない。だから納期も見えない、という状況になりがちだ。


まあ日本では工場ですら、細かな製造指図がなく、現物中心で動いていたりする国である。「それで動いているんだから何が問題なんだ」と大勢の人が思い込んでいる。結果として、後で振り返って分析しようにも、詳細なデータが何も履歴として残っていない状況になる。


だからこそ、今後はオフィスワークを含む指示（オーダー）の概念や、それを可視化するチケットが重要になるはずである。


実績系・指示系と進化してきたら、さらにはデータ保守・交換・分析系の機能に進むだろう。マスタデータの保守、外部システムとのI/F、そしてデータ蓄積などである。


ただし、この3つは、実績形が完全に終わってから指示系に進む、といった形ではなく、ある程度重なり合いながら、機能を少しずつ充実化していくのが普通だろう。


以上が、今の世の中における、プロジェクト・マネジメント・システムの有り様である。プロジェクトをマネジメントしてくれるシステムは存在しない。今後も多分存在しないだろう。プロマネの決断をサポートする数値やデータを、提供してくれる機能はあると思う。いわば実行コントロール系の機能である。


だが、それは船の航海にたとえれば、GPS付きの操舵システムのようなものだ。船の現在位置、速力、これまでの航路や、積荷の上げ下ろしは、正確にわかる。だが空模様と海象をにらみながら、船団を率いて航路を決めていく任務は、常に船長という人間に残されているのだ。




＜関連エントリ＞
　「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ (2017-12-18)
]]> http://brevis.exblog.jp/29783566/ 2021-12-19T18:31:00+09:00 2025-12-31T11:05:23+09:00 2021-12-19T18:31:26+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

一つ目は「プロジェクト＆プログラム・アナリシス研究部会」で、小川明彦様にRedmineを応用した「チケット駆動開発の解説」のご講演をいただきます（1/11夜）。


二つ目は1年ぶりの、BOM/部品表に関する1日セミナー（1/27、オンライン・有償）のご案内です。


「プロジェクト＆プログラム・アナリシス研究部会」（2022年1月11日）開催のお知らせ


プロジェクトは、単位要素的な仕事の集積である、というのがモダンPM論の基本的認識です。その要素的な仕事を『アクティビティ』と呼ぶのが、PMBOK Guideのお約束です。ただしIT業界ではアクティビティの代わりに『タスク』という言葉を使う習慣も強いため、お互いに会話する際は注意が必要でしょう（ちなみにPMBOKでは、ずっと細かな日常的課題・To doを「デイリータスク」と呼んでいます）。



いずれの名前で呼ぶにしても、プロジェクトとは「やるべき仕事」の集合であり、それはさらに、事前に計画可能な（プロジェクト計画書に含まれる）種類のものと、遂行途上で生まれてくる計画できないものに分かれます。これらをうまく、相互に協調した形で進められるかどうかが、プロジェクトの成否を決めていきます。


Redmineはチケット管理をベースとした、プロジェクト・マネジメントのためのオープンソースのソフトエウェアです。プロジェクト・マネジメントを標榜するソフトウェアは多数ありますが、「やるべき仕事」をチケットという仕組みで可視化し、コントロールしていく点がユニークです。


今回は、redmine.tokyo のアクティブなメンバーで、関西をベースとした「NPO法人 IT勉強宴会」でも活躍されている、小川明彦様に「チケット駆動開発」についてご講演いただきます。


Redmine自体はIT開発プロジェクト向けツール、とのイメージが強いですが、単なるチケットによるタスク管理を超えて、製造業などにおけるプロセス改善にまで視野を広げたお話を聴ける機会です。年明け早々ではありますが、皆様ぜひご参加ください。




＜記＞


■日時：2022年1月11日（火）　18:30～20:30　（オンライン形式）


■講演タイトル：
「チケット駆動開発の解説～タスク管理からプロセス改善へ」


■概要：
チケット駆動開発とは、チケットと言う仮想カードでソフトウェア開発のタスク管理を俊敏に行う開発手法である。日本ではチケット駆動開発を実践する為に、オープンソースのチケット管理ツールRedmineが広く使われている。昨今、高機能化したチケット管理ツールがとても便利なので、製造業などIT業界以外のタスク管理に適用し、プロセス改善を通じてDXを支援する事例も増えている。
本講演では、チケット駆動開発が生まれた背景と意義、プロセス改善へ発展した経緯と留意点について述べる。



■講師：小川明彦
　所属：redmine.tokyoコミュニティ
　
■講師略歴：
2001年に大学院(数学専攻)を卒業後、IT業界の受託側・発注側のプロジェクトマネージャとして業務系Webシステムの企画提案/設計/開発/保守を経験してきた。ソフトウェア開発のプロジェクト管理に苦労した経験からアジャイル開発に興味を持ち、オープンソースのチケット管理ツールRedmineを使ってチケット駆動開発と言う開発プロセスを独自に探求している。現在は、PMOの立場で社内のプロジェクト管理の標準化や品質管理に従事している。
技術士(情報工学)、情報処理技術者（データベーススペシャリスト）、認定スクラムマスター。



■参加希望者は、三好副幹事までご連絡ください。後ほどオンライン会議のリンクをお送りいたします。


■参加費用：無料。
　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。
　




次は、BOM/部品表に関する1日集中セミナー（有償）のお知らせです。


製造業のDXという言葉が、世間を賑わせています。それが何を意味するかは諸説紛々ですが、製造現場のデジタル化や自動化（機械化）を除外して、本社や営業所だけで考えられるものでない事だけは、確かです。顧客からの受発注や仕様・要望、そしてクレームなどを、どのようにスムーズに製造現場に伝えられるかが問われていますし、また逆に現場の進捗や納期・コスト見積情報を、いかに素早く顧客に返せるかも大事です。そしてサプライヤーへの発注手配も、品質・コスト・納期（QCD）と不可分の関係にあります。


これら情報をつなぐインテグレーションの中核となるのが、基準情報としての『BOM/部品表』のデータであることは、言うまでもありません。とくに最近は、「トレーサビリティ」（＝追跡可能性）が、多くの製造業の分野で求められるようになりました。これもまたBOMデータと切っても切れない関係にあります。


製造業ならば、どの企業もBOMを持っています（そうでなければ材料が購入できないはずです）。しかし、BOMデータのマネジメント悩む会社は、少なくありません。BOMには、受注・製品設計・工程設計・購買・生産管理・製造・品管・物流・保全・サービス・会計と、数多くの部門が、いろいろなフェーズとタイミングで関わるからです。


相互につながっていない複数のシステムを抱え、その間のつなぎを、人間が手作業で行っているのが、多くの企業の現実です。しかしますます加速する多品種化と、頻繁な計画変更のため、「すり合わせ」能力も限界に近づいているのではないでしょうか。しかも日本のIT業界には、製造現場のITシステムに強い企業がとても少ない、という状況が困難に拍車をかけています。


では、どうすべきか。もちろん答えは、企業の生産方式やBOMの特性、そして現状システムのあり方に応じて、千差万別でしょう。しかし、共通の基本概念を理解し、BOM特有の各種テクニックを学んだ上で取り組まなければ、あまりにも非効率です。さらに近年では、BOP（Bill of Process＝工程表）概念の普及や、先に述べたトレーサビリティ要求、そして製造実行システム（MES/MOM）の普及など、新しい進展もあります。


こうした事柄を理解しながら、自社のBOMデータのあるべき姿について、考えるきっかけにしていただければと願う次第です。BOM/部品表マネジメントに関心のある方のご来聴を、心よりお待ちしております。




＜記＞


(2) 「BOM／部品表の基礎と生産管理に効果的なBOM構築のポイント」


日時：　2022年1月27日(木) 10:30〜17:30
主催：　日本テクノセンター


本セミナーでは、BOMの基本概念の再整理からはじめて、マテリアル・マスタの統一、BOMの応用テクニック、そしてBOM構築プロジェクトの進め方について、演習をとりまぜつつ、平易に解説します。特に、BOM構築の３つの難所について重点的に説明し、トレーサビリティに関わる課題などについても、詳しく述べます。一日セミナーですので、じっくりと学ぶには最適です。


なお講義はオンライン形式ですが、自分で考えて身につけていただくため、グループ演習形式も多少取り入れて進める予定です。もし可能であれば、マイクとカメラ付きの端末をご用意ください。


セミナー申込み：　下記をご参照ください（有償です）
https://www.j-techno.co.jp/seminar/seminar-46773/


以上、大勢の方のご参加をお待ちしております。





佐藤知一@日揮ホールディングス（株）
]]> http://brevis.exblog.jp/29709960/ 2021-10-10T17:32:00+09:00 2025-12-31T11:05:23+09:00 2021-10-10T17:32:38+09:00 Tomoichi_Sato B1 プロジェクト・マネジメント全般

この言葉が流行る前は、じつはKYは労働安全分野の略語だった。『危険予知』の略である。「KY活動」などとも使う。KYが「空気読めない」の意味で流行してしまった後は、あえて「KYK」とよんだりもしているらしい。まあ、地味なおじさん用語では、ネットやJKの影響力に勝てないし。


本サイトの読者で、労働安全に関心のある人は、正直あまり多くないと思う。だから「KY活動」だって、初耳かもしれない。製造業や建設業の現場では、危険を伴う作業を行うので、事故やケガが起きがちだ。いわゆる労災である。そこで雇用者に、労働安全のための監督義務を課している。


労働安全の分野では、「度数率」というモノサシで、安全を測る。これは労働時間100万時間あたりの労働災害の発生件数で、人は年間2000時間近く働くから、ざっくり言って500人規模の事業所で、年間何回くらい災害が起きるかを示している。まあ1〜2程度の数値と思えば良い（全産業平均で1.8程度）。


そして、度数率を下げるために取組をする訳である。労働災害の原因は、本人や周囲の「不安全行動」（これくらい大丈夫だろう、と考えて行うリスキーな行動）であることが多い。そこで安全衛生活動として、4S活動（整理・整頓・清潔・清掃）などと並んで、「危険予知（KY）活動」を行うのである。


典型的なKY活動は、たとえばミーティングで、作業の状況を示すイラストや図面を見せたり、実際の動作をしてみせたりしながら、どこに危険があり得るかを話し合う。そして重点項目や指さし確認などの対策を皆に理解してもらうのである。これをやることによって、危険性（＝可能性）が皆の意識の中に、視覚的イメージとして植え付けられるので、それなりに災害防止の効果がある。


危険予知活動は、リスクアセスメント活動の一環であり、その現場レベルでの取組とも言える。じつは日本では2006年に、労働安全のためのリスクアセスメントが法律で導入された。法的な枠組みなので、経営者が主導し、管理職レベルの安全管理者を任命し、推進チームを組織して、職場におけるリスクを評価することになっている。


だが、こうした取組は、現場レベルできちんと実装され、皆の行動習慣に落とし込まれなければ、効果は上がらない。そしてまあ、ここのところが難しい。なぜなら現場とは、納期だの売上だの利益だのといった、別のモノサシでドライブされることが多いからだ。


そしてこれは、オフィスで行うプロジェクトでも同様なのである。PMBOK Guide(R)などを見ると、プロジェクトでは計画段階でリスクアセスメントを行うのが良い、と書いてある。またSIなどの受注型プロジェクトでは、見積提出段階で、一応のリスク評価がなされることとも多いだろう。会社としても、あまりリスキーな、赤字覚悟の仕事は受けたくないからだ。


だが、実際のプロジェクトの現場では、しばしば避けるべき問題が発生する。オフィスだからケガや事故は滅多にないだろうが、病気で倒れるとか、メンタルで休みがちになる人が出て、チームの戦力が落ちる。また疲れや不注意で、品質が低下する。結果として納期が遅れ、赤字に陥るなど、残念ながら珍しくない話だ。


もちろん、プロジェクトを率いる立場になったら、誰だってこうした出来事は避けたいと願う。そのためには、やはりプロジェクトの開始時点で、実際に働くキーパーソン達を巻き込みながら、より具体的なリスクアセスメント、すなわち一種の危険予知活動を行うのが望ましい。


ところが、プロジェクトにおけるリスク・マネジメントは、案外、ガイダンスとなる良い教科書や手本が少ない。その理由は、製造現場の労働安全などと違って、プロジェクトが非定型業務だからだ。毎回、顧客も作るモノも道具立ても違う。プロジェクトには、何らかのチャレンジ的な要素が、必ずある。すべてのチャレンジを、未経験だからリスクと認定して回避したら、プロジェクトが成立しない。


そもそも、深刻な問題はたいてい、二つ以上の原因が重なって起きる。たとえば「冒険的な行動」と「危険な環境」といった組合せだ。だが、トラブルが起きて原因分析をする際、どちらを根本原因とみるべきかについて、じつは判断基準のない組織が多い。こういう企業では、過去に起きたトラブル事例などのLessons Learned（教訓）が、なかなか次に活かしにくくなっている。



「熱気球の浮上、または原因分析のシステムズ・アプローチについて」(2016-06-15)より再掲

また、リスクの洗い出し方法も問題だ。「このプロジェクトで考え得るリスクを出してください」というと、『納期遅延のリスク』などと言う人が、よくいる。だが、納期遅延は結果事象でしかない。何かの理由があって納期が遅れるのであり、それを防ぎたかったら、結果ではなく原因にしたがって、リスクを洗い出す必要がある。たとえば「不慣れなツールによる生産性の低下」とか、「海外調達の機器の納期が不安定」とかいった風に。



しかも、海外調達の機器の納期が不安定だとして、それがプロジェクト全体の工期に影響を与えるかどうかは、それがスケジュール上のクリティカル・パスに乗っかっているかどうかにも依存する。つまり、リスクを評価するためには、プロジェクトの全体像を理解していなければならないのである。


おまけに、プロジェクト・リスク・アセスメントでは普通、リスクの優先度を、
　【発生確率】×【影響度】
で評価する。そう、教科書に書いてある。だが、プロジェクトは毎回個別で、発生確率は統計で得られないことも多い。それに、そもそも、無理な価格や納期で受注したプロジェクトの場合、それ自体がリスク源ではないか。あるいは任命されたプロジェクトのリーダーが頼りなかったら。いずれも確定した事実で、すでに確率＝100%である。じゃあリスクと見なさなくても良いのか？　等々。


こういう風に、実際に現場で適用しようとすると、悩んでしまう事があまりに多い。


そこで、プロジェクトを率いる立場になった人達を対象に、プロジェクト・スケジューリングとリスクアセスメントを柱とした、二日間のトレーニングコースを、下記の通り実施することにした。これは、わたしが関わっている「プロジェクト＆プログラム・アナリシス研究部会」のPM教育分科会で開発した、最新のカリキュラムでもある。


主催は浜松ソフト産業協会なので、セミナー開催地は従来、浜松だった。しかし、幸か不幸か、今年はzoomによるオンライン形式で行う。そこで、全国からご参加いただけることになった。有償で、かつ休日に開催するセミナーなので、個人参加には多少ハードルがあろうかと思うが、もし職場のOKが出るようなら、そしてプロジェクトのスケジュール計画やリスクアセスメントの能力を伸ばしたいと思われるなら、ぜひご参加いただきたい。


＜記＞


研修セミナー名称：
「プロジェクトマネジメント研修　～リスクマネジメント編～」


日時：11月16日・23日 各10:00～17:00
講師
　 八卷 直一氏（静岡大学工学部 名誉教授）
　 佐藤 知一氏（日揮(株) 博士(工学)/静岡大学 客員教授）
　 串田 悠彰氏（(株)未来生活研究所 博士(工学)）


参加申込み：
https://www.hamanako.jp/info/0146.html





＜関連エントリ＞


　→「リスクに対する新しいアプローチ」 (2010–09-01)
　→「熱気球の浮上、または原因分析のシステムズ・アプローチについて」 (2016-07-19)


]]> https://www.excite.co.jp/ https://www.exblog.jp/ https://ssl2.excite.co.jp/