前期の授業が終わると、暫くは夏休みってことで休講になるわけですが、漫然と過ごすわけにもいかず、何かしら勉強しないといけないわけで。
別に強迫観念じゃないですけど、目標を達成するには努力しなくっちゃね。程度の思考です。

さて、基本的に苦手なのがアカウンティング領域とファイナンス領域。
苦手という表現は正しくないかな？
「今まで業務を含めて、関わることがなかったもの」≒「苦手」という位置付け。

この間、財務会計の先生に「会計苦手っす。基本的な知識をおさえたいですが」と相談してみた。
そうしたら、やはり「質の良い本を読むしかない」ってことで、斎藤静樹先生と、醍醐聡先生の著書を紹介してもらった。

「簿記を勉強するってのは、アリですかねぇ？」と聞いてみたら、あまり効果的じゃないらしい。
財務会計の「本質」を勉強するのに簿記の知識はあまり重要でないというのが、先生のアプローチのようだ。
これは管理会計でも同じかもね。

ん？脱線した。

えーっと、夏休みはそんな感じで苦手な分野の強化に利用するのと、マーケティング知識の向上を目指します。
んでもって、英語力！

あとはギャグで「アロマテラピーの試験」なんて受けてみようかと。
一体何をやりたいんだか・・・

「プロジェクトって何？」

とプロジェクトマネージャに聞いたら全員きちんと答えられるのかなぁ？
所属する業界によって定義がブレてるんじゃないかと思うんですよね。
でも、PMBOKの冒頭には定義してあったから、一般論は答えられるのかな。きっと。

じゃあ、「経営とプロジェクトの違いは？」
という質問には、経営者も、プロジェクトマネージャも答えられるのかな？

実はこれがかなり興味深い。
「期限前提が無限か有限かの違い」ってだけの答えじゃ底が浅いし。
もっと実質的なガツンと「芯のある」答えが欲しいところ。

ちなみにManagementという言葉は、日本語に訳すと「管理」とか「経営」なんて言葉になりますね。
文脈によって、どちらかとして捉える必要があったりします。

果たして、プロジェクトマネージメントのManagementはどっちなんでしょうね？
広義では後者？
狭義では前者？
うーん、曖昧だなぁ。

企業の持つ資源（リソース）の代表的なものが「人」「モノ」「金」。
それを管理して、経済活動をして利潤を追求するための手法が「経営」だとすると・・・

「人」「モノ」「金」を管理して成果物を生み出すのがプロジェクト。
それを管理している人は・・・と思考すると「経営」になっちゃう。

とにかく「これを完成させろ！」という命題をクリアするために、限定された「人」「モノ」「金」を使うのがプロジェクト。
それを管理している人は・・・と思考すると「管理」になってしまう。

ってことはプロジェクトマネージメントは、やはり「経営的視点」と「管理的視点」の二面性を兼ね備ているんだろうね。
当然プロジェクト内容によっても大きく変わるので、Managementに含まれる意味の度合いが変化してしまうでしょうけど。

うん、本題とずれた！

考えたかった事は、そんな事ぢゃなくって、「組織とプロジェクト」ってどっちが主で、どっちが従なの？
ってことなんです。

「組織に依存した形でプロジェクトを行わなければならない」っていう図式は極めて普通のような気がします。
プロジェクトは、成果物を有限の資源で有限の時間内に完成させるのが目的ですから。

しかし、これはあまりにも「与えられた状況を甘受しすぎ」って感じなんですよね。
資源の調達はプロジェクト中に行えるとしても、この図式は「組織＞プロジェクト」ってことですよね。

じゃあ、逆のパターンを考えてみよう。
「プロジェクトのために、組織を変えました」なんで事が実際に起こりうるだろうか？
企業に１つのプロジェクトしか存在せず、企業ミッション＝プロジェクトという図式になっていれば可能な気がします。
が、企業ミッションを達成するために複数のプロジェクトを持つのが普通と考えた方がいいですよね。
ですがあえて無視して「プロジェクト＞組織」という関係を考えてみます。

なんで、こんな事を考えるのか？って？
うん、この図式に潜んでいる問題点を考えたいんですよ。

例えば「組織に何か欠陥がある」と仮定しましょう。
「欠陥って何よ？」と言うことになりそうなので、適当に思いつく例を考えてみると。

１．スキル高いチームと低いチームがあり、戦力バランス均一でない
２．組織の長のスキルが低く、チームメンバーのモチベーションが低く、業務効率が低い
３．業務プロセスが統一されておらず、バラバラのプロセスで業務を行っている

・・・など、まぁ色々あると思います。
いわば「組織のパフォーマンスを低下させる何かがある」状態だとしませう。
これが前提です。

さて、このような状態の組織に、ある「プロジェクト」を託したとしましょう。
このプロジェクトは果たして、成功するでしょうか？
それとも失敗するでしょうか？
図式は「組織＞プロジェクト」です。

プロジェクトなので、当然プロジェクトマネージャがいて、プロジェクトマネージメントされます。
どうでしょうか？成功するんですかね？
Fe+は「成功する」とはとても思えないんですよね。

じゃあ、逆のパターンはどうでしょうか？
あるプロジェクトを行う際、プロジェクトを遂行するために必要な人的資源をある程度自由な裁量でプロジェクトマネージャが決定できるとします。
プロジェクトマネージャが「こいつは最高だ！」という人材を何の問題もなく、プロジェクトメンバーにできます。
さて、この場合は成功するでしょうか？
それとも失敗するでしょうか？

・・・これも先程の「組織＞プロジェクト」同様に確率はあまり高くないような気がします。
どうしてそう思うのか？
それは、「プロジェクトマネージャが問題だったら本質的にあまり変わらない」からです。

ということは「プロジェクトが先か？組織が先か？」という問題ではなく、プロジェクトマネージャがプロジェクトのパフォーマンスを決める大きな要因になっている気がするんです。

さて、核心の核心。
「プロジェクトが破綻し始めたから、管理手法をCCPMにしよう」という考え方は、正しいか否か？
Fe+的回答は、明らかにNo！
迂遠な解決方法の様な気がするんですよね。
問題の本質は

「プロジェクトマネージャの問題を解決すること」

なんじゃないですか？

それが特に「組織＞プロジェクト」という図式ならば、なおのこと。
プロジェクト手法を変えたって、「組織が持つ根元的な問題」は解決しないでしょ。

この疑問が解消されないから、CCPMを利用することに疑問を感じちゃうんですよね。
CCPMについても正直「ソフトウェアに適用するには、なにか引っかかるものがある」と感じているんですよ。
CCPMのマインドや効果は理解しているんですが・・・
つまり、「CCPMに対する疑問」というよりも、「CCPMを利用すれば問題が解決すると考える人の考え」が疑問な訳で。

この疑問、解消してくれませんかね？
上司様。