|
2005年12月16日、東京、芝浦の(株)オージス総研にて、PCM 手法の紹介セミナーを開催しました。 (株)オージス総研は、さまざまな企業の情報化ニーズに対して、コンサルティング、情報化戦略、情報システムの設計・開発・運用・管理などを行なう、トータルソリューションプロバイダーです。 PCM Tokyo グループからは、大迫と三好の2人が講師として参加しました。三好は、アフリカから一時帰国中で、PCM Tokyoには6ヶ月ぶりの登板です。
|
![]() |
例によって、PCM Tokyo
恒例、飴を交換しながらの自己紹介です。
すでによくご存じの職場の同僚ですので、いまさらの自己紹介は少し照れます。 |
![]() |
服装もそうですが、自由闊達な会話がはずむ、リラックスした雰囲気です。
IT企業の企業文化をかいま見る思いがします。 |
![]() |
まずはPCMの理論編。概要説明です。 赴任先のザンビア(アフリカ)から一時帰国中の三好が登場。 アフリカのプロジェクト現場での苦労が言葉の端々に滲みます。その分、言葉の重みが増して、またひとつ大きく飛躍をしようとしている、という感じがします。 |
![]() |
理論編の次は実践編です。
PCM の計画立案のステップを、ひととおり演習します。 まずは関係者分析。 プロジェクトの関係者(ステークホルダー)をすべて書き出し、分類します。
|
![]() |
関係者分析の発表です。
今回の参加者は9名と、比較的少人数でしたが、ふたつのグループに分かれて、それぞれプロジェクトを計画しました。 相互に発表しあうことで、自分たちとは異なった視点に気づきます。 |
![]() |
関係者分析の次は問題分析です。
問題を原因−結果の関係で整理し、系図の形にまとめます。 ずいぶん大きな系図ができました。 それだけ、詳細で網羅的な分析ができたということです。 |
![]() |
問題分析の発表です。
発表にも熱がこもります。 |
![]() |
熱弁をふるう三好。
聞き入る参加者。 |
![]() |
目的分析の発表です。
問題を解決するための手段を、手段−目的の関係で、系図の形に整理します。 このあと、「プロジェクトの選択」と「PDM の作成」を行ないましたが、演習に夢中になって、うっかり写真を取り忘れました。失礼しました。 |
![]() |
今までの半日セミナーではモニタリング・評価の説明はしていなかったのですが、今回、特にご要望がありましたので、ごく簡単に、ご紹介しました。
この絵は、PCMで標準化されている「モニタリング・システム」の情報の流れを概念図で示したものです。
|
![]() |
「モニタリング・システム」はこれです。
詳しくお知りになりたい方は、本HPの「ライブラリ」にあります、「PCMハンドブック(日)」を参照してください。 |
![]() |
プロジェクト評価は、PCM
では「評価5項目」という5つの視点から評価をします。
評価5項目の概念はこの図の通りです。 同じく、本HP「ライブラリ」の、「PCMハンドブック(日)」を参照ください。 |
![]() |
最後に、三好から、ザンビアのプロジェクトでのモニタリングの現状について紹介してもらいました。
今回はODAの現場の話もたくさん出て、盛りだくさんなセミナーになりました。 オージス総研のみなさん、ありがとうございました! (左の写真はザンビアのみなさんです。念のため。) |
アンケートの結果です。(有効回答9名)
|
Q1. 今回のセミナーの内容に 1. 非常に満足した。 ・・・・・・・・・・・・・・・・・・・ 4 名 2. 満足した。 ・・・・・・・・・・・・・・・・・・・ 5 名 3. あまり満足しなかった。 ・・・・・・・・・・・・・・・・・・・ 0 名 4. 全然満足しなかった。 ・・・・・・・・・・・・・・・・・・・ 0 名 コメント ・ 演習が多くあり、それぞれ何を行なわなければならないか理解できた。 ・ 演習があるので、聞いているだけのセミナーより理解しやすいと思いました。 ・ 説明、進行が分かりやすく、ワークショップも有意義でした。 ・ 最近PCMを知ったときの期待通りでした。 ・ 分かりやすかったです。住民などのプロジェクトでは有効なアプローチだと思います。 ・ 体感できたので、雰囲気をざっくりと掴めたのがよかった。 ・思っていた以上にいろいろなアウトプットが作りやすく、有効そう。
Q2. PCM手法は自分の仕事に 1. 使えそうだ。 ・・・・・・・・・・・・・・・・・・・・ 8 名 2. あまり使えなさそうだ。・・・・・・・・・・・・・・・・・・・ 0 名 無回答 ・・・・・・・・・・・・・・・・・・・・ 1 名 コメント ・ 今まさに問題解決型のアプローチでプロジェクトを立ち上げて進めないといけない立場だから、ぜひ使ってみたいと思った。 ・ プロジェクトの立案にかかわる仕事をしているが、関係者間で問題の共有化がうまくされていないため。また、プロジェクト評価のフレームワークも利用してみたい。 ・ プロジェクトでははく、問題解決の手段としてワークショップを利用することはできると思う。 ・ お客様が抱えている課題をどのように整理していくか、という場面で使ってみたいと思いました。 ・PCMのアプローチやロジックは、ソフトウェア開発プロジェクトのマネジメントの一手法として参考になりそうです。 ・IT系のプロジェクトも最近は机上でプロジェクト計画というわけにもいかなくなったと感じます。 ・ある意味、BSCのアプローチと似ていると思いました。やはりもう少し時間をかけて十分な整理が必要だと思いました ・問題を詳細化する際の留意点など、そのまま生かせそう。演習テーマが身近で、仕事の課題にも生かせそう。
Q3. PCMの本格的な研修を 1. 受けたい。 ・・・・・・・・・・・・・・・・・・・・ 7 名 2. 受けたくない(興味ない)。 ・・・・・・・・・・・・・・・・・・ 1 名 無回答 ・・・・・・・・・・・・・・・・・・ 1 名 コメント ・ とても楽しかったが、やはり半日は短かった。じっくり演習をして、腹に落としたい。 ・モニタリング・評価のところをもっと詳しく知りたい。 ・ODA以外の企業向け等あれば。 ・もう少しじっくりできたらよいと思います。ひとまず書籍で学び、小さいところから実践していきますが。 ・興味ないということはないです。余力があればということで。(「受けたくない」のコメント) -------------------------------------------------------------------------- 質 問 ・質問 : 評価の自立発展性はいつ評価を行なうのか。プロジェクト終了直後か、ある程度期間がたってからが、その評価法は? 終了直後なら仮説でやらなければいけないのか? ・回答 : PCMは評価手法を提供していますが、それらの手法を使ってどういう評価をどのタイミングで行うかは規定していません。それはプロジェクト実施機関がポリシーとして決めるべきこと、という考え方です。たとえばJICAは、PCMの評価手法を使って、プロジェクトの計画時、中間時、終了時、終了後の4回のタイミングに分けて自立発展性を評価しています。計画時はまだプロジェクトは始まっていませんから、自立発展性を確保するような計画になっているかどうかを評価します。中間時、終了時は、おっしゃるとおり仮説で行ないます。仮説というと語弊がありますが、要するに、自立発展させていくだけの体制ができつつあるかを評価します。終了後は、プロジェクト終了後3〜5年後に、まさに自立発展性を評価します。評価法は、プロジェクトがもたらした効果は持続している(する見込み)か、それを自立発展させていく責務を担っている組織の財務状況、技術力等、組織の体制は整っているか、といった点を評価します。 ・質問 : ステークホルダーで共同してプロジェクト計画するのはIT系のプロジェクトでも適用できそうだと思いました。事例があればご紹介ください。 ・回答 : IT系で実際にPCMが使われた事例は、我々の知る限りありません。ぜひオージス総研で最初の事例をつくってみてください。PCM Tokyoも協力を惜しみません。ステークホルダーで共同してプロジェクト計画する、特にエンドユーザーまで入れて議論をするということは、ODAでは行なわれていますが、民間企業では画期的なことなのではないでしょうか? 試してみる価値はありそうですね。 ・質問 : 予算の見積もり方法について教えてください。実際のプロジェクトではどのようにして予算の見積もりを行なうのでしょうか? ・回答 : 既存のPCM手法に予算の見積もり方法は含まれていません。現在、PCM Tokyoで、立案以降の計画、実施、終結部分の手法の開発・整理を行っています。いずれまとまりましたらご報告しますので、そちらを参照ください。 ・質問 : PDMを入れ子にして作成することはありますか? 基本的にブレークダウンしていっている形式なので、細分化したいと思うこともあると思ったのですが。(大きなプロジェクトの中に、小さなプロジェクトをいくつか・・・という形式) ・回答 : 大きなプロジェクトの中に小さなプロジェクトをいくつかという形式は、プログラム・アプローチと呼ばれており、昔から概念はありますし、最近はODAでも盛んに議論されています。面白いことに、1週間前に半日セミナーを実施した「日本野鳥の会」でも、まったく同じ質問が出ていました。世の中はプログラム・アプローチに向かいつつあるということでしょうか。プログラム・アプローチにPDMを適用する場合は、プログラム用のPDMと、レベルが一段低いプロジェクトごとのPDMを作成して管理します。入れ子にするとPDMが複雑になりわかりにくくなるので、やはり別個にしたほうが良いように思います。
|
ばりばりのIT企業の皆さんとのPCMセミナーでしたが、直面する問題はODAと共通しているところも
多く、我々も非常に勉強になりました。
企業向けPCM本格研修のご要望もいただきましたので、PCM Tokyoの課題として検討させていただ
きます。
参加者の皆様、どうもありがとうございました。
2005年12月19日
PCM Tokyo
大迫正弘 & 三好崇弘