<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:thr="http://purl.org/syndication/thread/1.0">
    <title>コンセプチュアル・マネジメント: オピニオン</title>
    <link rel="self" type="application/atom+xml" href="https://mat.lekumo.biz/ppf/cat9747341/atom.xml" />
    <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/" />
    
    <id>tag:bb.lekumo.jp,2003:weblog-417743</id>
    <updated>2010-03-28T18:50:55+09:00</updated>
    <subtitle>マネジメントの本質を考え、イノベーションやプロジェクトの効果的な方法を提案する、コンセプチュアルリーダーのためのメールマガジン</subtitle>
    <entry>
        <title>【補助線】エンジニアからマネジャーへのトランジション</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2010/03/transition.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2010/03/transition.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49470535</id>
        <published>2010-03-28T18:50:55+09:00</published>
        <updated>2013-03-01T18:21:40+09:00</updated>
        <summary>エンジニアがよいプロジェクトマネジャーになること（トランジション）は意外なくらい...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="ディスカッション" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロジェクトマネジャーの秘密" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロフェッショナル" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>エンジニアがよいプロジェクトマネジャーになること（トランジション）は意外なくらい難しい。この記事はエンジニアの仕事とプロジェクトマネジャーの仕事はどう違うのかを明確にした上で、トランジションの障壁になっているものを整理し、どうすれば変わることができるのかを、著者のコンサルティング経験に基づき、整理したい。</p><br />【１】仕事の違い
<p>プロジェクトは課題を設定し、解決する活動である。この中でプロジェクトマネジャーの仕事とプロジェクトで働くエンジニアの仕事は本質的に異質なものである。エンジニアの仕事は課題解決の仕事であり、自分自身の力で成果を上げる仕事である。これはチームを率いるチームリーダーの場合も、変わらない。自らが中心になり、チームメンバーを指示しながら課題を解決し、成果を上げる。</p>
<p>これに対して、プロジェクトマネジャーの仕事は、チームメンバーを通じて成果を上げることである。そのために、プロジェクトマネジャーは、課題解決ではなく、メンバーの行う課題解決が経営的な成果につながるような課題の「設定」を求められる。課題解決自体はメンバーが行う。このように、似ているようで全く異なる仕事である。</p>
<p><br />【２】なぜ、変われないのか</p>
<p>エンジニアからプロジェクトマネジャーへのトランジションの最大の阻害要因になっているのは、課題設定の仕事ではなく、課題解決の仕事をしていることにある（これは、エンジニアとプロジェクトマネジャーの違いを認識できないという問題でもある）。この阻害要因は、仕事の評価の考え方など、組織や制度の問題に起因する部分も少なくないが、プロジェクトマネジャー個人の問題として捉えると、３つの大きな問題により起こっている。「決めれない」こと、「任せられない」こと、そして、「動けない」ことである。</p>
<p>これらの問題の根本原因は、「言われたこと」をやるというプロジェクトマネジャー自身の受け身のスタンスにある。つまり、「プロジェクトは自らが何かを実現したいために行うものだ」と考えず、「プロジェクトとは与えられた課題を実現するものだ」と「考えている」、あるいは「考えておきたい」というプロジェクトマネジャーのスタンスにある。</p>
<p>「考えている」プロジェクトマネジャーの問題は思考停止に陥っていることである。「考えておきたい」プロジェクトマネジャーの問題は、責任をとりたくないとか、失敗をしたくないといった心理を持っていることである。いずれにしても、自ら課題を「決める」ことができず、上位組織や顧客から与えられた課題をそのままプロジェクトに受け流している。</p>
<p>課題を決めることができないと、メンバーと同じ土俵、つまり課題解決としてものごとを考えようとする。特に顧客相手の課題解決に注意がいく。課題解決は経験がものをいう仕事であるので、当然、メンバーよりプロジェクトマネジャーの方が能力が高い。そこで、自然とメンバーのパフォーマンスに不満をもち、失敗しないように「指導」をする。つまり、失敗を恐れて任せることができないので、メンバーが育たず、いつまでも指導は完結しない。また、メンバーにも言われたことしかやらない風潮がはびこる。結果としていつまでも「任せることができない」という悪循環に陥る。</p>
<p>さらに、任せることがでいないと、時間的余裕がなくなり、「考えられない」、「動けない」という状況が生じる。ここにもう一つ、「決めれない」ことに起因する問題が絡んでくる。仕事の優先順位づけが定義できないことだ。課題を明確に決めることができないので、仕事の優先順位を決める基準がない。このため、時間がない中で、不適切な優先順位により仕事をしていき、「アクティブノンアクション」＝一生懸命仕事をしているのに成果が出ないという状況に陥る。もちろん、プロジェクトも、アクティブノンアクションになる。</p>
<p><br />【３】どうすれば変われるか</p>
<p>このような問題を乗り越え、エンジニアがプロジェクトマネジャーに変わっていくためには、適切なトランジションプロセスが必要である。ウィリアム・ブリッジズという経営学者が、トランジションのステップとして</p>
<p>第一段階：何かが終わる時<br />第二段階：ニュートラル・ゾーン<br />第三段階：何かが始まる時</p>
<p>の３つの段階からなるステップを提唱した。これは、おそらくトランジションの明確なステップを示した唯一の理論である。</p>
<p>この理論を応用して、エンジニアからプロジェクトマネジャーへのトランジションプロセスを考えてみよう。これまでのコンサルティングの経験から、そのプロセスとしては、</p>
<p>第一段階：エンジニアとしてのキャリアを終える<br />第二段階：マネジャーとしてのキャリアに必要なものを、プロジェクトマネジメントの活動の中で探していく<br />第三段階：プロジェクトマネジャーとしてのキャリアを始める</p>
<p>が有効である。</p>
<p>多くのプロジェクトマネジャーは、第一段階を経ないで第二段階に進んでいこうとし、上のような苦労している。もう一度、第一ステップを踏む、つまり、エンジニアとしてのキャリアを明確に終了することが重要である。このためには、エンジニアとしての考え方、発想を捨てることだ。たとえば、著者のキャリアコンサルティングの経験では</p>
<p>・すべてを自分の手の内に入れるという発想を捨てる<br />・ものごとは計算通りに行くという発想を捨てる<br />・問題を技術的に解決するという選択肢を捨てる<br />・時間と成果は比例するという発想を捨てる<br />・品質がすべてに優先するという考え方を捨てる<br />・顧客がすべてに優先するという考え方を捨てる<br />・１００％やらないと意味がないという考え方を捨てる</p>
<p>などを捨てることが有効である。エンジニアであったことを過去とする。これができない限り、プロジェクトマネジャーとしての新しいやりかたを身につけることはできない。<br />その上で、第二段階では今、行っているようなトレーニングや経験をしていく。この中では、実際にプロジェクトマネジメントを経験してみて、何が必要であるかを自分自身で考えることが求められる。同時に、上に述べた「決める」、「任せる」、「動く」という基本スキルを身につける必要がある。そして、タイミングを計って、プロジェクトマネジャーとしてのキャリアを始めることをお奨めしたい。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】失敗が「恥」と結びつく文化を克服しよう</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2010/03/shame.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2010/03/shame.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49470543</id>
        <published>2010-03-23T12:13:13+09:00</published>
        <updated>2014-07-23T16:37:45+09:00</updated>
        <summary>◆「２１世紀枠に負けたことは末代までの恥です」 第８２回選抜高校野球大会で監督が...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="「守破離」のプロジェクトマネジメント" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>◆「２１世紀枠に負けたことは末代までの恥です」</p>
<p>第８２回選抜高校野球大会で監督が騒動を巻き起こしている。騒動を起こしたのは、開星（島根）の野々村直通監督（５８）。新聞によると、３月２２日、第１試合で「２１世紀枠」の向陽（和歌山）に１―２で敗れたあとのインタビューで、「２１世紀枠に負けたことは末代までの恥です」などと発言したらしい。</p>
<p>スタンフォード大学のアントレプレナー・センターでエグゼクティブ・ディレクターを務めるティナ・シーリグ氏が自身の集中講義の内容を紹介した書籍「What I Wish I Knew When I Was 20（邦訳「<a href="http://mat.lekumo.biz/books/2010/03/innovation.html" target="_blank">20歳のときに知っておきたかったこと</a>」（阪急コミュニケーションズ、2010）」で面白い指摘をしている。</p>
<p><br /> 
</p><p><br />◆シリコンバレーはなぜ強いのか</p>
<p>シリコンバレーがなぜ、強いのかという議論の中で、</p>
<p>リスクを取ろうとする意欲と、失敗に対する反応は、国によって大きなばらつきがあります。失敗をしたときの悪い面が多すぎて、個人がリスクに対して過敏になり、どんなリスクも取ろうとしない文化があります。こうした文化では、失敗が「恥」と結びついていて、若い頃から、成功の確率が高い決まった道を歩くように教育されます。失敗したら恥をかくようなことには、挑戦しようとしません。タイのように、失敗をすると、人生をやりなおすために、名前を変える社会もあります（同書、91ページ）<br />（中略）<br />こうした文化の対極にあるのがシリコンバレーです。</p>
<p>と指摘している。</p>
<p><br />◆失敗と恥を結びつける文化を持つ国　日本</p>
<p>シーリグ氏の指摘の中に、日本の話は出てこなかったが、日本も失敗が「恥」を結びつけた文化を持つ国であることは明らかだ。野々村直通監督の発言はまさにそうだ。</p>
<p>日本人の行動基準の中で、「恥」をかくかどうかは大きなものである。「恥」をかくかどうかによって、行動するかどうかを決める。これは幼いころから刷り込まれている。親は「そんなことをしたら恥ずかしいでしょ」と子供をしつける。</p>
<p>さらにいえば、失敗したときに下のものが、自分を指導する上のものに「恥をかかした」として責任をとるといった恥文化さえある。</p>
<p>いろいろな「正当化」をしているが、失敗したくない本当の理由の大半は「恥」だと思える。</p>
<p>たとえば、会社の中を考えてみよう。主任、課長、部長と役職が上がっていくにつれて、だんだん、失敗を恐れるようになる。これは、失敗を「恥」と結びつけて考えているからだ。もちろん、本人たちの言い分は違う。「失敗の影響が大きく、責任が重くなるから」なのだが、本当にそう思うのであれば、不作為（機会損失）による失敗についてもっと敏感であるべきだからこの理屈はおかしい。</p>
<p><br />◆失敗と人格を結びつける「恥」</p>
<p>この議論の中で昔からよく言われるのが、行為と人格の混乱である。行為と人格というのは本来別ものである。行為に至った事情、環境があるからだ。犯罪のような極限の行為でも、罪を憎んで人を憎まずという。ところが、行為と人格を結びつけているものがある。それが「恥」を重んじる文化だ。</p>
<p>「恥」というのはあくまでも個人に帰属する感情である。従って、失敗が恥に結びつけられると、「あの人は失敗して、恥ずかしい人だ」という人格攻撃になる。</p>
<p>ここに会社の中で職位が絡むともっと話は複雑になる。「部長という立場にありながら、そんな失敗をするようでは、部下に恥ずかしいだろう」となる。これ、実は、親が「そんなことをしたらみんなに笑われますよ」としつけするのと同じ原理だ。</p>
<p>失敗を、恥を介して、人格の問題にされてしまうと、もう立ち直れない。再チャレンジ可能な社会を作るためには、この問題に取り組んでいく必要がある。</p>
<p>きっとここまで読んで、自分の会社では失敗に対してそんな扱いはしていないと違和感を感じていらっしゃる方もいると思う。それは僕も認識している。しかし、改めて考えてみてほしいのは、では、不作為による機会損失はないのか、あるいは、リスクを恐れて機会損失をしていることはないのかということだ。さらには、大きな失敗をした人が、その後に大きな成功をしたケースがどのくらいあるかだ。</p>
<p>不作為はなく、また、失敗した人が失敗を挽回するような仕事をしていれば、僕の勘違いである。そうであれば、このあとの部分は読む必要はないだろう。</p>
<p><br />◆負け方を知る</p>
<p>では、どうすれば恥と失敗を切り離すことができるのか？</p>
<p>興味深いのは、アスリートの世界である。外人のコーチや、海外で学んできたコーチに指導される選手が国際的な舞台でよい成績を上げている。共通して見られるのは失敗に対する対処である。試合の直後に、もう失敗を冷静に受け止め、原因を分析し、次の機会へのチャンスに変えている。優勝候補で敗れても、そのように振舞っているのはすごい。要するに、常に自分を客観化し、もう一人の自分がどうすれば最大のパフォーマンスを発揮できるかを常に考えている。程度はスポーツによると思うが、試合中もである。</p>
<p>もうひとつ、アスリートといえるかどうかわからないが、競馬の世界で第一人者である武豊騎手がスポーツバラエティ番組で面白いことを言っていた。競馬は馬８騎手２で、騎手の立場でみれば乗る馬によって成績が大きく左右される。トップの騎手でも勝率２割、つまり、５回に４回は負けている。さらに、強い馬に乗ってまけたようなケースは、負けるという結果だけではなく、馬券に投票した人に大損をさせているという事実も受け止めることになる。そこで、どのように負けるか、負けを引きずらないかが勝ち方よりも大切で、そのためには、勝ち負けにこだわらず、納得できる騎乗をすることが大切だという。</p>
<p>これは、トップアスリートを見ていても感じることだ。</p>
<p><br />◆「立場」を考えるのではなく、「役割」を考える</p>
<p>ビジネスでも同じだ。失敗するか成功するかにこだわらず、何をすべきかをよく考え、決断をすることだ。その際に常に問題になるのが、「立場」である。「立場」というともっともらしく聞こえるが、別の言葉に置き換えると「面子」である。ビジネスで「面子」の源泉になっているのは、「役職」である。さらに、企業レベルの話になってくると、社会的地位というのも問題になる。</p>
<p>役職とは本来、経験により、組織の中である「役割」であって、「立場」ではない。同じように社会的地位も社会の中の役割であって、立場ではない。これを勘違いすると、派遣切りのような行動をするようになる。失敗できないからだ。</p>
<p>もし、役職や社会的地位を立場だと考えているのであれば、「役割」だと認識すれば、明日からでも行動はがらりと変わるだろう。失敗と恥が切り離され、行為と人格がきちんと切り分けられるからだ。</p>
<p>&#0160;</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】組織とは何か</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2008/11/post-54cb.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2008/11/post-54cb.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49470819</id>
        <published>2008-11-10T22:00:00+09:00</published>
        <updated>2013-03-01T18:21:47+09:00</updated>
        <summary>◆個人と組織 社会保険庁の記録改ざんで、「個人」と「組織」の線引きが問題になって...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロジェクトスポンサーの秘密" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロジェクトマネジャーの秘密" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>◆個人と組織</p>

<p>社会保険庁の記録改ざんで、「個人」と「組織」の線引きが問題になっている。社会保険庁に限らず、官民を問わず、この問題は微妙である。改めて組織とは何かと考えさせられる。</p>

<p>「組織で行う」というのは、組織の上位管理者が構成員（以下、社員と書く）に対して、業務命令を行い、社員が実行することを意味している。このロジックで考えると、命令がないのに、社員が「組織のために良かれ」としてやったことは、個人が勝手にやったことになる。</p>

<p>この問題が複雑なのは、その行為を管理者が知っているかどうかで話が変わってくることだ。知っていれば、正規の手続きを踏んでも組織として行ったことになり、知らなければ個人の行為だということになることが多いが、責任体制もそのようななっているかというと極めて怪しい。</p>

<p>◆権限委譲というグレーゾーン</p>

<p>この問題そのものは内部統制の強化で徐々に解決してきたが、依然として残っている問題は、この問題が原因になって起こっている権限委譲の問題である。権限委譲というのを明確な形で行っていないため、ここがグレーゾーンになって、結局、誰の責任か分からなくなっているケースをよく聞く。</p>

<p>プロジェクトマネジメントでもこの問題が出ている。プロジェクトマネジャーの権限を確認すると、「プロジェクトの運営に関するすべて」という答えが返ってくることが少なくない。「関するすべて」という言い方は日本では、「ケースバイケース」と読む。要するに、プロジェクト上位管理者の意向に反しない限り、認めるということで、これは権限委譲とは言わない。意思決定の代行をさせているだけである。言い換えるとサボっているだけである。ゆえに、丸投げといわれる。</p>

<p>◆現場のルールを決める際に、組織全体のルールを決める</p>

<p>統治者は自分自身の統治ルールを決めない。いざというときのために、統治に関するフリーハンドを残しておきたいからだ。これと同じで、組織が現場のルールを決めるときにはルールを課せられた現場に対応する自分たちのルールを決めない。自分たちの問題が発生したら、現場のルールを変えて対応しようとする。</p>

<p>現場のルールを決める前に、ルールの全体のデザインをすべきである。そして、抜け道を作らないことだ。ちなみに、プロジェクトマネジメントのルールを作るときには</p>

<p>・プロジェクトマネジメントポリシー<br />・プロジェクト区分<br />・プロジェクトマネジャーの権限<br />・エグゼクティブの権限<br />・ビジネスコミッティ、技術コミッティの権限<br />・プロジェクトマネジメント関係組織間の業務分担と連携</p>

<p>は最低限決めておく必要がある。</p>

<p></p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】ガラパゴス化するプロジェクトマネジメント</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2008/11/post-3e93.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2008/11/post-3e93.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49470823</id>
        <published>2008-11-04T12:44:36+09:00</published>
        <updated>2014-07-23T16:37:46+09:00</updated>
        <summary>「夢をかなえる象」の勢いがとまらない。テレビドラマ化されただけではなく、ドラマ化...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="「守破離」のプロジェクトマネジメント" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロジェクトスポンサーの秘密" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="プロジェクトマネジャーの秘密" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>「<a href="http://www.amazon.co.jp/exec/obidos/ASIN/4870318059/opc-22/ref=nosim" target="_blank">夢をかなえる象</a>」の勢いがとまらない。テレビドラマ化されただけではなく、ドラマ化されるとまた、売れるという好循環モードに突入の様子。象という動物は頭のよい動物なのだろう。</p>

<p>さて、象でも違った話。サーカスの象の調教方法をご存知だろうか？小象の時分から、杭につないでおく。小象なので、杭を抜いて脱出しようとしても力不足でできない。象は成長し、成人象になる。当然、杭など訳もなく引き抜くことができる。ところが、杭から逃れることはできないという思い込みがあって逃げることはなく、おとなしい象になるという話。</p>

<p>これは、本で読んだ情報なので、真偽は分からない。</p><p>もうひとつ、同じような逸話がある。同じく小象を鎖で杭につないでおく。しばらくつないで置くと、鎖をはずしても、つながれていたときに動ける範囲でしか動かないという話がある。これはある人からずっと前に聞いた話。聞いたときに、犬はずっとつないでおいても、鎖をはずしたら逃げるといったら、知能が高いほど、このような思い込みは激しいというオチがついた（笑）。なるほど、人間がもっとも高いわけだ。</p>

<p>信じていかなったのだが、最近、この話を本でよんだ。この本。</p>

<p>「<a href="http://mat.lekumo.biz/books/2008/10/post-26cb.html" target="_blank">会社を変える 不合理のマネジメント―1.5流から超一流への発想転換</a>」</p>

<p>話の真偽はともかく、サーカスの象の話も、後の話もたとえ話としては鋭いところをついている。</p>

<p>組織における常識というのは厄介である。問題が起こったときに、常識の枠にとらわれていると解決できないことが多い。一方で、問題解決方法に対する承認を得るためには、常識から大きく逸脱することは望ましくない。</p>

<p>多くのマネジャーはこのジレンマに悩み、「中途半端」な解決策を実施し、痛い目にあう。そして、マネジャーになって２～３年すると常識の範囲で考えることの重要性を知る。</p>

<p>こうなると、マネジャーの問題解決行動は変容する。問題が発生したときに、問題を何とか常識の範囲で解決できるようにすることを考えるのだ。スケジュールが遅れると、納期を延ばすなど。つまり、問題解決としては、「ネゴシエーション」が中心になってくる。昨今、ネゴシエーションが注目されているのは、常識の範囲で解決できない問題が増えてきたからである。これも問題を解決する方法のひとつであるので、悪いわけではない。</p>

<p>ただし、常識は組織によって異なるという落とし穴がある。</p>

<p>日本でも先進的なマネジメントをしていると思われている企業の情報システム部門の人がこんなことを言っていた。「日本のベンダーさんとはスピード感が合わず、結果として、入札をしてもらえないことが多いので、結果として海外ベンダーに頼んでいる」という。つまり、この会社とベンダーは常識が違うのだ。最近はリスクマネジメントで、この傾向に拍車がかかっていると思われる。これも企業経営のひとつのあり方である。</p>

<p>この問題は結構深刻な問題である。自分たちの常識が他にも通用するというのは、横並びの社会の話であって、競争をしていると通用しない。この点について認識してやっているのであればよいが、もし、違うとすれば上の事例が例外的なものでなるなる日は遠くない。<br />昨今、情報産業ではガラパゴス化が話題になっている。製造業全般にそうだという話もある。</p>

<p>宮崎 智彦「<a href="http://www.amazon.co.jp/exec/obidos/ASIN/4492761772/opc-22/ref=nosim" target="_blank">ガラパゴス化する日本の製造業</a>」、東洋経済新報社（2008）</p>

<p>日本のプロジェクトマネジメントもガラパゴス化しないように、変革していく時期を迎えていることは間違いない。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】計画されないプロジェクト</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2008/03/post-651a.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2008/03/post-651a.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49470957</id>
        <published>2008-03-09T10:00:00+09:00</published>
        <updated>2013-03-01T18:21:50+09:00</updated>
        <summary>◆計画の位置づけの違い テレビの道路特定財源の議論を見ていたら、なるほどなと思っ...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>◆計画の位置づけの違い</p>

<p>テレビの道路特定財源の議論を見ていたら、なるほどなと思ったことがある。</p>

<p>日本の道路のコストがなぜ高いのかという議論なのだが、欧州では道路は計画に時間をかけて実現性を持つように徹底的にやる。その代わり、計画が終われば、「計画通り」速やかに工事計画を作り、工事をするので、結果として、企画から供用までの時間は欧米の方がはるかに短いという。</p>

<p>ところが日本は、最初の計画は作るが、実現性は工事での調整任せ。着工すると、できるところから予算をつけてやることになる。ゆえに、とびとびに作り掛け道路が点在しているのだそうだ。</p>

<p>なるほどなあと思った。この問題で、以前、テレビで国道８号線の高架化工事のいきさつの特集をやっていた。一応、計画を作って、タウンミーティングをやる。何回かやっているのだが、住民のコンセンサスは得られていないどころか、報道を信じれば圧倒的に反対住民が多い。にも関わらず、今後もタウンミーティングを続けながらも、計画通りに着工手続きに入り、進めていくというのだ。</p>

<p>基本計画の調整ができていないままで、工事にバトンを渡している。</p>

<p>これでは、いくら、工事計画を精緻に作ろうとその通りに実行できるはずはない。実際に工事を始めると、現場では想定していなかった障害が飛び出してくる。</p>

<p>◆なぜ、コストが高くなるのか？</p>

<p>プロジェクトマネジャーのみなさんなら、まあ、これは最後まで計画通りにいかないと思うのではないだろうか？</p>

<p>では、プロジェクトオーナーは何をやろうとしているのか？とりあえず、キックオフする。そして、比較的、反対住民の少ない箇所から着工し、既成事実を作って、反対住民が多いところを切り崩していく。</p>

<p>ただし、この切り崩しが、当初予算どおりにできるはずがないのは、自明の理だ。既成事実化すれば、土地が上がるし、何らかの補償をするにしても、補償金を上げることが「合理性」を持ってくる。当然、当初計画よりはるかに大きなコストがかかる。役人がリスク管理をしていないはずはないので、おそらく、確信犯でやっているのだろう（リスクをとっているわけではない。リスクを識別して無視しているのだ）。</p>

<p>当然、工事コスト自体もよけいにかかるのも明らか。ところが、ここでも既成事実が意味を持つ。「今、止めてしまうと、今までの投資はすべて無駄になる」というロジックで押し切れるからだ。</p>

<p>◆ＳＩプロジェクトのロジック</p>

<p>実は、このロジック、ＳＩプロジェクトで行われていることに瓜二つ。ポイントは以下の３つだ。</p>

<p>・徹底的に基本計画をせず、大雑把な基本計画でとりあえずプロジェクトを始める<br />・問題がでてきたら、予算の積み増しを要求し、継続する<br />・今、やめたら、これまでの投資が無駄になると継続の合理性を主張する</p>

<p>この構図は、ＳＩベンダーを非難しているように聞こえるかもしれないが、違う。３つとも、ユーザ側のプロジェクトマネジャーにとってもそうするメリットがあり、利害が一致するのだ。</p>

<p>計画を詳細化すればするほど、意志決定しにくくなるし、時間がかかる。また、変更がしにくくなる。変更をするのは、担当者にとってみれば一生懸命仕事をしていることのエビデンスだと言えなくもない。そして、中断しないのは一蓮托生である。</p>

<p>このような利害の一致があるがゆえに、止められない。そして、大けがをする。</p>

<p>◆ユーザ側の理性と計画</p>

<p>ただ、ユーザ側に「理性」があると、こんなことにはならない。先日の新聞にこんな記事が載っていた。</p>

<p>=====（抜粋開始）<br />静岡県を地盤とする地方銀行のスルガ銀行（本店・沼津市）は６日、銀行業務に関する基幹コンピューターシステムの開発を契約通りに行わなかったとして、開発委託先の日本ＩＢＭ（本社・東京都港区）に約１１１億円の損害賠償を求める訴訟を東京地裁に起こした<br />　関係者によると、スルガ銀行は２００４年９月、銀行業務全般にかかわる基幹システムを刷新するため日本ＩＢＭとシステムの開発契約を結び、開発費用の一部はすでに日本ＩＢＭに支払っている。ところが、新システムの稼働を予定していた０８年１月を過ぎても稼働のめどは立っておらず、開発費用も当初の予定額より膨らんだため、支払った費用の返還などを裁判で争うことにしたという。<br />　スルガ銀行は日本ＩＢＭとの開発契約は破棄したと主張しているが、システム開発自体は引き続き進めるとしている。<br />　日本ＩＢＭの広報担当者は、「このような訴えを起こされるのは異例だ。訴状が届いていないので詳細は分からないが、スルガ銀行との契約上の義務は果たしたと認識している」と話している。<br />=====（抜粋終了）</p>

<p>たぶん、記事の内容からすれば、契約の方法などにも問題があるように感じるが、ここで区切りをつけようとしたのは、まさに「理」だとも感じる。</p>

<p>ちなみに、スルガ銀行は横並びしないことで有名な地銀だ。何よりも、スルガ銀行を有名にしたのは、バブルの時に踊らなかった数少ない銀行であったこと。同族経営の強みだと言われているが、まあ、経営や、戦略を感じる企業である。</p>

<p>この記事は、ＳＩプロジェクトのプロジェクトマネジメントは日本で活動しているベンダーとしては頭一つ抜けているという評判のＩＢＭであることがもう一つのポイントだろう。これ以上は憶測になるので控えるが、このような事態が発生するのも、道路の問題と同じく、「計画」という作業の「位置づけ」に問題があるのではないかと推測される。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>ＭＢＡフェロー</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2007/03/post_d7e2.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2007/03/post_d7e2.html" thr:count="1" thr:updated="2007-04-22T14:02:49+09:00" />
        <id>tag:bb.lekumo.jp,2003:post-49471265</id>
        <published>2007-03-27T10:02:11+09:00</published>
        <updated>2013-03-01T18:21:58+09:00</updated>
        <summary>先週、土曜日に、母校神戸大学の経営学部の大学院で、「ＭＢＡフェロー」というボラン...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>先週、土曜日に、母校神戸大学の経営学部の大学院で、「ＭＢＡフェロー」というボランティア活動をした。</p>

<p>この活動は、ＯＢの中から２０名ほど選ばれたフェローが現役の学生さん（ほとんど社会人）のゼミに参加して、いろいろとアドバイスをしたり、意見を交わすという活動だ。</p>

<p>神戸大学のＭＢＡコースは発足してもう２０年近くになるが、比較的古い世代のＯＢから選ばれたようで、みんな、卒業後、１０年以上といった感じ。</p>

<p>好川が参加してきたのは、松尾博文教授のゼミで、ＳＣＭとか、製品開発を中心にやっているゼミ。</p>

<p>好川がＭＢＡのコースに行ったのは９５年だが、この当時は学生のほとんど中堅・中小企業だった。大企業は、欧米のＭＢＡコースに留学に出すからだ。</p>

<p>ところが今回、参加してまずびっくりしたのは、大企業ばっかりだったということ。関西を代表する大企業は一通り来ているような様相だ。聞けば、最近では、海外留学はほとんどなく、国内留学が主流になってきたとのことで納得。</p>

<p>これがいいかどうかはともかくとして、まあ、学生の質は高く、議論は刺激があって面白かった。</p>

<p>フリーディスカッションをする機会があって、プロジェクト組織の作り方で激論になった。特に、武田製薬、松下電器、任天堂の方との議論が印象深かったが、なんにしても、ＭＢＡコースに来ている人がこれだけプロジェクトマネジメントに興味をもっていることが分かったのは収穫だった（製品開発のゼミというバイアスがあるが、、、）</p>

<p>日本のＭＢＡコースにもプロジェクトマネジメントの講義を入れるべきですね。</p>

<p>ＭＢＡフェローについては<a href="http://www.kobe-mba.net/admissible/MBA070401.pdf" target="blank">こちら</a>。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>プロフェッショナルのための業界団体　ＰＭＩ</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2006/12/post_2d6e.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2006/12/post_2d6e.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49471357</id>
        <published>2006-12-25T00:37:55+09:00</published>
        <updated>2013-03-01T18:22:00+09:00</updated>
        <summary>ある方から、「プロフェッショナル」という記事に批判コメントを戴いた。掲載を許して...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>ある方から、「プロフェッショナル」という記事に批判コメントを戴いた。掲載を許していただけなかったので、できるだけ、ご本人のコメントに触れない形で反論をしておく。</p>

<p>まず、ＰＭＩという組織が何のためにあるかを考えてほしい。ＰＭＩ（Project Management Institute）ができたのが１９６９年、アポロが月面着陸に成功した年である。この当時はＰＭＩというのはプロジェクトマネジメントの普及団体であった。しかし、１９８４年、ＰＭＰ（Project Management Professional）制度ができて、ＰＭＩにはもう一つの性格が加わる。それは、プロフェッショナルのための業界団体である。</p>

<p>プロフェッショナルのための業界団体をもう少し正確にいうと、プロフェッショナルの倫理を保証する団体である。このために、そのような団体は、プロフェッショナルの倫理規定を設け、その倫理規定が遵守されるように監視を行う。ピンと来なければ、弁護士会だとか、医師会といった業界団体を思い浮かべてもらうと分かると思う。</p>

<p>ここでもう一つ注意すべきことがある。それは、プロフェッショナルの活動を規定する「法律」があるかどうかだ。医師にしろ、弁護士にしろ、そのような法律があってそれによって活動倫理が規定されている。いわゆる「士業」だ。倫理というとこのような法律遵守を想像するかもしれないが、これは「人を殺傷してはならない」というレベルの話であって、倫理として議論すべきことではないだろう。法律を犯すことは犯罪であり、倫理感云々という問題ではないように思う。倫理とはプロフェッショナルの責任ともいうべきものだ。これはどのような業界のものでもだいたい３つある。</p>

<p>（１）業務とプロフェッショナルであることに対する真摯な態度<br />（２）業務責任を果たすために必要な専門性の維持<br />（３）自らが属するプロフェッショナルの地位向上への貢献</p>

<p>の３つだ。</p>

<p>ＰＭＩがプロフェッショナル責任として提示しているものを見るとこの点はよく分かる。以下の５点である。</p>

<p>（ａ）個人の健全性（真摯さ）とプロフェッショナリズムの確立<br />（ｂ）個人の能力（コンピタンス）の増進<br />（ｃ）専門領域の知識集積への貢献<br />（ｄ）利害関係者間の調整<br />（ｅ）チームや利害関係者との協調関係</p>

<p>上の３つの項目との関係は</p>

<p>（１）：（ａ）、（ｄ）、（ｅ）<br />（２）：（ｂ）<br />（３）：（ｃ）</p>

<p>といったところだろう。</p>

<p>ここでよく考えてほしいがいくつかある。（ｄ）とか（ｅ）というのはプロジェクトマネジメントスキルだと考えているＰＭＰが多いが、そんなに甘いものではない。これらはスキルではなく、プロフェッショナルとしての責任である。</p>

<p>次に、（ｂ）個人の能力（コンピタンス）の増進という項目があるが、プロフェッショナルであれば、時間がないといういいわけはすべきではない。プロジェクトマネジャーとして従事することも、研修を受講することも同等な重要性を持つ仕事である。この点がよく分かっていないＰＭＰが増えているのは嘆かわしい。</p>

<p>また、時間をとってレッスンズラーンドを行うことは、組織への貢献がない、あるいは評価されないとしてもプロフェッショナルとして行うべきである。（ｃ）専門領域の知識集積への貢献として、他のプロフェッショナルのために知識集積をすると、めぐりめぐって、また自分に戻ってくる。</p>

<p>では、自分はプロジェクトで忙しいのでそれどころではない。これらのプロフェッショナル責任を果たせないと思ったときに、何をすべきか。選択肢は２つある。</p>

<p>ひとつは、自身のタイムマネジメントをより真剣に行い時間を作るという道だ。これはドラッカーがプロフェッショナルの条件で非常に重視しているポイントである。</p>

<p>もう一つは何か。いうまでもないと思うので、書かないことにする。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】考古学のようなプロジェクトマネジメント</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_7dc9.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_7dc9.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49471377</id>
        <published>2006-11-21T19:59:01+09:00</published>
        <updated>2014-07-23T16:37:47+09:00</updated>
        <summary>原丈人という実業家がいる。原さんは、実業家として、手始めに光ファイバーのベンチャ...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>原丈人という実業家がいる。原さんは、実業家として、手始めに光ファイバーのベンチャー事業で成功し、その後、ベンチャーキャピタルを創設する。技術型のベンチャー育成投資家としては、ボーランド、ゾーラン社などの育成で名をはせている。欧米で活躍している実業家なので、日本ではあまり著名ではないが、世界トップの育成投資家の一人である。</p>

<p>原さんは慶応大学の法学部の卒業で、ファーストキャリアはなんと、考古学の研究者である。一度、原さんの話を聞いたことがあるが、考古学研究とベンチャー発掘育成は似たところがあるという話をされていて、なるほどと妙に感心してしまった。</p>

<p>そのようなものの見方をする原さんが、雑誌ウェッジに非常に面白い記事を書いていたのが目に留まった。</p>

<p>「<span style="color: #ff6633;">ビジネススクールの流儀はもはや人を幸せにできない</span>」</p>

<p>という過激なタイトルだ。原さん自身、スタンフォード大学経営学大学院に学んだ経験がある。この記事の内容もとても面白い。ビジネススクールの流儀の数字絶対主義の経営が米国で主流になったのは、米国がいろいろな人種が住む国であり、その中で、唯一、共通の価値観、言語になりえたのが数字だったからだという指摘をしている。その上で、もはや、そのような価値観に行き詰まりが生じ、新しいパラダイムを探しているというだ。ところが、そのような価値観にも関わらず、日本ではいまだに、数字絶対主義経営がもてはやされているのはどういうわけだという問題提起をしている。</p>

<p>この記事を読んで真っ先に思ったのが、この構図はプロジェクトマネジメントの構図そのものであるということ。プロジェクトマネジメントがダイバーシティを前提にしているというのは、難しい話でも何でもなく、単に現象や価値を数字に置き換え、マネジメントをしているに過ぎない。そして、グローバル企業においては、このような考え方が有効だとしている。</p>

<p>イラク戦争を見ても、過去の歴史をみてもそうだが、ものごとを単純化するというのはアメリカという国の特徴である。しかし、ものごとを単純化すると免疫がなくなり、純粋に体力勝負になる。国でいえば大国、企業で言えばグローバル企業だけが有利な構図だ。</p>

<p>プロジェクトマネジメントで重要だとされていることにリスクマネジメントがある。これは間違いないと思う。しかし、リスクマネジメントの識者の共通の見解として、</p>

<p>　<span style="color: #ff3300;">リスクに強い組織を作るには原理原則を重視し、ものごとを単純化しないことが大切</span></p>

<p>というのがある。米国がよくやるのは</p>

<p>　ものごとを単純化し、単純化された世界で原理原則を大切にする</p>

<p>という、強者が生き延びるためのレトリックである。</p>

<p>米国発のＰＭＢＯＫのリスクマネジメントの原理を思い出してみてほしい。まず計画と称して、現象や価値を数字化する。その上にリスクというのを定義しているのだ。かつ、数字化するから、リスクが明確になるとまで言っているし、そこでさらにリスクを数字化するという点に及んでは驚きである。</p>

<p>まさに、単純化しておいて、リスクを高め、リスクマネジメントは大切だというマッチポンプをやっているわけである。本当にリスクマネジメントが大切であれば、簡単に数字化すべきではない。現象をきちんと扱っていくべきである。</p>

<p>そして、日本には昔から、そのような知恵があった。それが、ビジネススクール流で崩れつつある。</p>

<p>最近、可視化というのは注目されている。これがまた危険な発想だ。可視化をする前に現場を見るべきである。数字化しておいて、現場（現実）を見えなくし、可視化するというなんとも訳の分からない話だ。これもビジネススクールの流儀だ。</p>

<p>奇遇にも同じウェッジにソニーの不調の話が出ていた。「ビジネス書の杜」ブログでも紹介したが、天外伺朗さんの</p>

<p>マネジメント革命</p>

<p><a href="http://mat.lekumo.biz/books/2006/10/post_62e3.html" target="blank">http://mat.lekumo.biz/books/2006/10/post_62e3.html</a></p>

<p>という本がある。</p>

<p>この本に書かれているのは、まさに、ものごとを単純化しない経営である。</p>

<p>天外伺朗さんは、実は、ソニーでNEWSワークステーションや、AIBOを開発された土井利忠さんのペンネームである。NEWSやAIBOそのものが成功したかどうかというのは微妙なところだが、土井利忠さんが実践されてきたようなマネジメントが本当の意味での現場力を生み、ソニーの反映に寄与したことは間違いないだろう。間違っても、電池の発火原因が数ヶ月経過しても分からないといったことはなかったと思う。</p>

<p>PMBOKを導入した。しかし、何かうまく行かない。しっくりこない。腑に落ちない。</p>

<p>ある人はこれをPMBOKへの理解が足らないという。PMBOKを感じていないという人すらいる。</p>

<p>しかし、本質的に、数字的なマネジメントがそぐわないという組織も少なくないと思う。ソフトウエアの企業で、CMMIやPMBOKを導入して、「社相」が悪くなったなと思う会社がいくつかある。クライアントであれば、だんだん、お付き合いがなくなっている。</p>

<p>ビジネススクールの流儀ではないプロジェクトマネジメントを考えるべきときにあるのではないかと思う。単純化して理解しあうのではなく、コミュニケーションにより相互理解を形成するグローバルマネジメントを考えるべきであろう。</p>

<p>まさに、原さんの言う考古学のように現実を直視し、ありのままに受け入れ、大切に扱っていくようなマネジメントである。</p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】誰が土俵を作るか</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_33c2.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_33c2.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49471379</id>
        <published>2006-11-19T19:41:22+09:00</published>
        <updated>2013-03-01T18:22:01+09:00</updated>
        <summary>今年は、ＰＭＡＪのＰ２Ｍの改訂委員会に参加している。先日、委員会の合宿があり、ゆ...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>今年は、ＰＭＡＪのＰ２Ｍの改訂委員会に参加している。先日、委員会の合宿があり、ゆっくりと考えをめぐらせる時間が取れた。</p>

<p>ＰＭＢＯＫはいまや２００万人が使う標準である。プロジェクトマネジャーという限定された人が使う標準として、２００万という数はすごい。そして、プロジェクトマネジメントだけではなく、プログラムマネジメント、さらにはポートフォリオマネジメントとだんだんその範囲を拡大している。仮に、ポートフォリオマネジメントがメジャーになっていけば、その利用者の数は一桁上がってもおかしくないだろう。</p>

<p>そんな動きがある中で、ＥＵのプロジェクトマネジメントの標準であるＩＣＢも今年６月に新しいバージョンであるバージョン３が登場し、ＰＭＢＯＫに遅れはとっているものの、いよいよ、本格的にグローバル展開を開始した（グローバルというか、当面のＰＭＩとの戦場はアジア、特に、インドと中国らしい）。</p>

<p>そんな中で、日本では、Ｐ２Ｍという標準がある。５年前にできた標準で、僕も中小企業経営を中心に、結構、使っている。ただ、５年前というとＰＭＢＯＫ２０００と同じ記事であるが、その間の普及を較べると大苦戦をしている。</p>

<p>ＰＭＩのアプローチは大変、システマティックであり、実践的である。プロジェクトマネジメントという現場のマネジメントから入り、だんだん、その範囲を拡大し、プログラムはともかくとして、ついに、ポートフォリオまで出てきた。</p>

<p>今のところ、ポートフォリオマネジメント標準については、ＰＭＢＯＫ１９８７程度だと思う。指したり実体はない。しかし、この分野に出てきたことは極めて重要な意味がある。</p>

<p>ポートフォリオマネジメント標準の本にそれぞれの位置づけについて極めて適切な表現がある。それは</p>

<p>ポートフォリオマネジメント　：　Doing the right work<br />プログラムマネジメント、プロジェクトマネジメント：Doing work right</p>

<p>という位置づけである。日本語に訳すと</p>

<p>ポートフォリオマネジメント　：　正しい仕事をする<br />プログラムマネジメント、プロジェクトマネジメント：正しく仕事をする</p>

<p>とでも訳すのだろう。「い」と「く」の一字違い。しかし、この一字が現場と経営の違いになっている。いよいよ、この領域に来た。これはエライことだ。</p>

<p>オペレーションのマネジメントはどこの標準でもよいと思う。所詮、如何に合理的にやるかという話であり、よいものはどんどん取り入れていけばよい。しかし、経営レベルで、欧米の標準を使うというのは、文化を受け入れるということ。人の土俵で相撲を取るようなものだ。必ず負けるだろう。</p>

<p>実際のところ、これらの標準に則って仕事をすると、欧米流の考え方により、日本企業が強みの一つにしてきたきた「スカンクワーク」はすべて葬り去られるだろう。ひいては、「人活経営」も崩れ去れる。</p>

<p>ファイナンスの世界で、日本は欧米から、同じ土俵にあがれと非難される。これはそのとおりだと思う。勝手は土俵を作ってビジネスをしていたのでは、迷惑をこうむるのは顧客だ。しかし、問題は、その土俵を誰が作るかという話である。</p>

<p>一方で、Ｐ２Ｍはというと、最初から、正しい仕事をする＆正しく仕事をするという両方を睨んだ仕事だった。その意味で、非常に先進性があったし、欧米でも評価されている。</p>

<p>しかし、結局、現在のところ、普及できないままである。土俵になっていない。</p>

<p>話は変わるが、１５年くらいまでに、UDL/Iというハードウエア設計言語の標準化プログラムのあるプロジェクトのプロジェクトマネジャーをやったことがある。これも日本発の標準だった。ちょうど、米国の押すＶＤＳＬという標準があり、それに対抗する形でＭＩＴＩが標準を作ろうとした（というか、某企業がＭＩＴＩを担いで標準を作ろうとした）。</p>

<p>標準はできた。技術的先進性は国際的に評価された。しかし、結局、普及しなかった。このプロジェクトでは、日本で半導体ビジネスをやっている企業が３０社近く集まり、コミッティをつくり、進めていった。この中には外資系の会社もあった。しかし、結局、活動の半ばで、既に、ＶＨＤＬの採用に踏み切る企業もあった。その企業におけるグローバル展開のためである。</p>

<p>Ｐ２Ｍはグローバルな土俵になるのだろうか？</p>

<p>そんなことを考えさせられた１日だった。どれだけ戦力になれるか分からないが、とにかくがんばりたい。</p>

<p>ちなみに、弊社のプログラムマネジメントの標準はＰ２ＭとＰＭＩを折衷し、独自の考えで纏め上げたものである。</p>

<p>プログラムマネジメント～複数のプロジェクトを同時に成功させる方法とそのポイント</p>

<p>　<a href="http://www.pmstyle.biz/smn/mpm.htm" target="blank">http://www.pmstyle.biz/smn/mpm.htm</a></p></div>
]]>
</content>


    </entry>
    <entry>
        <title>【補助線】仕込みポイントの勘違い</title>
        <link rel="alternate" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_ea53.html" />
        <link rel="replies" type="text/html" href="https://mat.lekumo.biz/ppf/2006/11/post_ea53.html" thr:count="0" />
        <id>tag:bb.lekumo.jp,2003:post-49471383</id>
        <published>2006-11-12T14:23:10+09:00</published>
        <updated>2013-03-01T18:22:01+09:00</updated>
        <summary>タウンミーティングで仕込みが問題になっている。 タウンミーティングとはアメリカが...</summary>
        <author>
            <name>好川哲人</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="★補助線" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="オピニオン" />
        
        
<content type="html" xml:base="https://mat.lekumo.biz/ppf/">
<![CDATA[
<div xmlns="http://www.w3.org/1999/xhtml"><p>タウンミーティングで仕込みが問題になっている。</p>

<p>タウンミーティングとはアメリカが「新大陸」であったころに、最初の入植地であるニューイングランドで行われた市民主導の統治方法である。タウンミーティングとは、市民が地域の問題を議論し投票するために集まるタウン集会をさす。</p>

<p>この統治方法の特徴は、意思決定の対象を市民自身が決めることと、投票者と市民の決断との間に仲介するものがなかったことである。つまり、直接民主制である。当然、このような形態では入植民が多くなると意思決定ができなくなるので、間接民主制に移らざるを得ない。アメリカの場合だと、連邦や連邦憲法による統治に移っていくが、タウンミーティングそのものは根強く残っているという。</p>

<p>この方法に注目したビジネスマンがいた。ＧＥのジャック・ウェルチである。ジャックウェルチはワークアウトプログラムの中にタウンミーティングを位置づけた。ワークアウトにおけるタウンミーティングはニューイングランドのそれとは若干異なる。まず、タウンミーティングメンバーが問題に対する議論をし、結論を出す。その上で、統治者（イシューに対するガバナンスを持つ人）をタウンミーティングに呼び、その場でメンバーの結論に対する意思決定をする。受け入れる場合もあれば、受け入れない場合もある。この仕組みで、通常であれば２～３ヶ月かかる意思決定が１週間程度で終わる。</p>

<p>これはたいへんな慧眼だと思う。タウンミーティングの本質は直接民主制にあり、それは、経営組織でいえば自律組織による統治を意味する。まさに、仕組みを使う人が仕組みを改善していく仕組みとしてはぴったりである。</p>

<p>日本でもこれに似た仕組みはあった。分野は狭いが、ＱＣサークルである。</p>

<p>さて、今回の問題を見ていると、いろいろ批判もあるが、日本では今の時点でタウンミーティングなるものをやろうとするとこういう方法しかなかったように思う。三権分立の理屈の上では、タウンミーティングは行政の仕組みとして行っているわけで、議員とは別の人たちを立てて行う。問題は仕込をどこでやるかだ。質問者に仕込みをやるのは間違いだろう。むしろ、タウンミーティングを仕切る人に仕込みをすべきで、その仕切りを国の行政機関がやっていることそのものが間違いではないかと思う。要するに、ガバナンスの問題である。</p>

<p>これと同じ構図はマネジメントの中にもよくある。コンサルタントとしてある企業でプロジェクトワークアウトを行ったときに、まったく同じことに出会ったことがある。上位マネジャー（統治者）がメンバーに仕込みをして、議論にならなかったことがある。組織のガバナンスとして仕込むのはかまわない。しかし、仕込みは人ではなく、文化である。</p>

<p>要するに民主主義の仕組みなのだ。組織のマネジメントにおいても民主化がされていないところに、プロジェクトマネジメントのような民主化を「前提」にした仕組みを持ち込んでいるところに、ガバナンスの混乱が発生している。</p>

<p>上に述べたように、米国における民主主義は直接民主主義から間接民主主義に変化し、その民主主義をベースにしてマネジメントが行われている。日本人が民主主義を解さないのは、直接民主主義の経験がないからではないかと思う。これが歴史なのだろう。</p>

<p>マネジメントの仕組みを考えるときには、このあたりをよく考えておく必要がある。</p></div>
]]>
</content>


    </entry>
 
</feed>
