有能なプロジェクトマネージャを育てるには（2）：何かがおかしいIT化の進め方（29）（2/3 ページ）

[公江義隆，＠IT]

根気の要る作業をどうやってすればよいか？

　PMBOKに書かれている内容の1つ1つは当たり前のことがほとんどで、そう難しいものではない。また、どこを探してもプロジェクトを成功させるためのうまい話や、びっくりするようなことが出てくるわけでもない。

　しかし、内容をキチッと読み、上記のように情報システム開発プロジェクトの問題にマッピングし直すには大変な根気が必要だ。1人でやろうとしても挫折する可能性が高い。

　何人かの同士が集まって、各自の経験や自社の開発方法論を交えて、PMBOKのマネジメントプロセスの1項目1項目について、できるだけ“具体的”に関係する事例や経験、問題点、疑問を語り合い、「討論で済ますもよし」、あるいは「情報システム開発プロジェクトマネジメント（PMBOK版）にまとめ上げるところまでやるもよし」といった問題だと思う。つまり、この共同作業のプロセスこそが重要というわけである。

　単に記憶しただけの知識では、なかなか実戦力にはつながらない。本当の力は、実践を通じて培われるものではあるが、具体的な事例を用いた他人との共同作業における相互の刺激、五感を駆使する討論が、実戦の模擬経験として大変有効である。

　なお、これらの共同作業の過程では、フェイズごとにPMBOKにある44のマネジメントプロセスそれぞれの重要度が、対象とするシステムの種類や規模によってどのように異なるかを、併せて議論しておくとよいと思う。大規模プロジェクトなら必須でも、小規模なら捨象でできるものもある。実務現場では“必要最小限”が最良である。

　こんな方法を取れば、勉強の努力の度合いに応じた成果が得られると思う。PMBOKは参考書、自分たちの実務内容と経験が教科書である。参考書を使って教科書を理解し直そう！

　大切なのは、協同作業や共同して行う勉強の過程で得る、気付きや知識・知恵である。成果物は、結果をこぎれいにまとめた資料ではなく、協働作業プロセスそのものである。このことにぜひとも気付いてほしいと思う。

PMBOKではなく、自分たちの実務内容や仲間の経験こそ、教科書とすべき問題なのだ！

専門用語や考え方をユーザーに押し付けるな!!

　なお、PMBOKには“標準用語集”という位置付け・狙いがあるといわれる。大切なことだとは思うが、これは（ITの）プロ仲間の間だけにとどめ、ユーザーにまで強要するのはやめておこう。ユーザーの多くは、こんなことを苦労して知ったところで、後々で役に立つことのまずない人たちである。相手に合わせるのがプロの作法だ。

　各企業にはそれぞれの言葉がある。旧財閥系の資本が入った横文字企業では、長らく“旅費”を“車馬賃”と呼んでいたとか聞く。システム上もその会社では“車馬賃”でよいのだ。業界用語や異国の言葉はコミュニケーションの障害になる。一般人に一番理解しやすい言葉が、最良のコミュニケーションを保証する。

　例えば、PMBOKにある「アーンドバリュー」といった新語や、「何を表しているのか」に長々と説明の要るような洗練されたグラフも使わない方がよい。1枚のグラフでたくさんのことを表そうとするから、ややこしくなっているだけだ。コスト対時間、スケジュール（進ちょく度）対時間、コスト対スケジュール（進ちょく度）の3枚のグラフにすれば説明はほとんど要らなくなる。

　プロジェクト運営管理のポイントは、現状を把握し、いまの状況が続けば最終的にどうなるかを予測し、それなら「その最終結果を当初の目標に合わせるために、いま何をすべきか？」を考えて実行することだ。3枚のグラフで状況をみんなに分かってもらい、今後を「どうすればよいか」をみんなで考えてもらうことに時間を使う方が、良い結果が得られると思うが……。

　このような考え方をすれば、少なくとも、関係者に新しい言葉や洗練された（複雑な）グラフの意味や見方を説明するといった“不毛な手間”が省ける。こんなことの説明で、自分の責務を果たしたように思う錯覚から自らを解放することもできる。プロなら「技巧や見栄えに走って本質を見失う」ことのないようにすることが肝要だ。

PMBOKの内容はプロジェクト特有のものではない

WBS（Work Breakdown Structure）は普通の考え方だ

　課題をブレークダウンして、最終的には1人1人の作業単位まで落とし込み、この単位の達成目標（成果）、担当者とスケジュールや予算を決め、これが予定どおりに進むようにすることは、プロジェクトに限らず、多くの仕事の計画や管理における一般的な要件だ。

　例えば、1つの機械を分解していけば、いくつかの部品になり、さらに分解すると多くの素子や機能的な回路などになる。機械を造る会社の組織や仕事のやり方は、この機械の構造の写像になっている（異なった機械の間で共通部品を使うような場合では、問題によっては、ある段階で“機能”を基準にして分類・ブレークダウンされて、機能別、あるいは共通部品別の組織や仕事の内容になっている）。

　こんな考え方以外に、大きな問題の実行を、複数の組織や個人に割り当てる具体的な方法はあるだろうか。PMBOKでいうWBS（Work Breakdown Structure）はプロジェクトだけの特別なことではない。

　しかし、実際の問題は、必ずしも、樹状のきれいな階層構造になっているわけではない。

　WBSでブレークダウンした詳細レベルの作業やその結果（アウトプット）が、別の大枝の先の小枝や葉と干渉を起こす場合がよくある。業務プロセスという仕事の具体的な部分が対象であるためか、情報システム分野ではほかの分野に比べ、こんな場合が多少多いような気がする。具体的にどのような問題が考えられるか、それをどのレベルで調整・修正するかを、方法論として、また仕事の手順・ルールとして考えておく必要がある。