最適化されたプロジェクト・スコープを納品する

はじめまして。株式会社イマジンスパークの深沢です。
　縁あって今回こちらでブログを始めさせていただく事になりました。よろしくお願い致します。

プロジェクトマネジメント、プロジェクト・マネジャーについて

　プロジェクトマネジメントは、可能な限りのあらゆる要素を考慮した上で、成果物やプロセスの「最適化」を考え、定義して、実現する活動だと考えています。

　ＰＭＢＯＫの定義文はまた別ですが、ＰＭＢＯＫの単語も使って表現すれば、プロジェクト・マネジャーは「成果物スコープを実現する最高にスマートな（最適化された）プロジェクト・スコープをデザインして、実現し、成功裡のプロジェクトとして完了する［サービス（無形の成果物）］を納品する」というサービス業と思っています。いずれにしても業界は特定しない考え方です。

　とはいえ、私の場合はコンピュータが好きで、ＩＴ業界の仕事で「最適化」を考えてきましたので、具体的な題材としてはＩＴプロジェクトを対象に表現していくことになります。

　なぜこんなヤヤコシイ表現をしているのかというと、物事をうまくいかせるために必要なこととして、少し乱暴ですが大きく２つ、対象についての詳細な情報（知識、データベース）とそれらを最大限に活かした手順（最適化プロセス）が必要と考えているためです。

　どちらが不十分でもうまく機能しません。

　ですから、いくらプロジェクトマネジメントがＩＴ業界の仕事でうまく行ったとしても、例えばもっとずっとシンプルなはずの自分のカミさんとの旅行プロジェクトが散々だったりするのです。

　これは、日頃からの興味の度合いによる、情報量の少なさや考慮の真剣さの違い、仕事との優先度の違いによってかけられる時間や労力が全く少ないなどといったことが要因になります。

　で、カミさんからは「ホントに普段仕事できてんの？」などと言われるわけです（笑）。

　まぁ、確かに現実目の前で起こっていることからすると、「たぶんそのはずなんだけど...」ぐらいしか言えなかったりしますが...。

　いきなり私個人の言い訳のようですが、まぁ、そんな感じです。
　「交渉人」という映画がありましたが、その冒頭で、まさにプロの交渉人である主人公が奥さんをまったく説得できないシーンなんか見ると、ひとりで過剰にジーンときてしまったりするわけです。

　「これが出来るのにこれが出来ないのは他人から見て全く理解不能、論理不在。でもそれが人間」なんだなと...。
　これはプロジェクト・マネジャーとしては中心的に大事な理解だと思っています。

ＩＴプロジェクトが上手く行かないワケ

　逆に、特に官庁や大企業間のプロジェクトなど、ひとりひとりは高い能力を持ちながら、なんだかどうしようもない様な感じでプロジェクトが失敗へ向かってしまう場合は、まさにこういったことの積み重ねであると考えています。

　善し悪しではなく、大企業の場合は別段コンピュータやプログラミングが好きで会社に入った訳ではない場合もより多くなってきますし、元々客先にも興味がないとか、家族や同僚、上司など、他者との意識の違いなどによって躊躇してしまう等、様々な要因で、皆が目の前のプロジェクトに集中できない、またそこを何とかする人、何とかしようとする人がいないことによって、いわゆるデスマーチが引き起こされているという印象です（コンピュータが好きなわけではないという事実は、そもそも「人がやりたがらない事をするから仕事として成り立つ」という場合もありますので、これが悪いわけではないと思っています）。

　あと、ＩＴプロジェクトがなかなかうまく行かないもう一つの理由として、ＩＴ業界はこれまでずっと、情報収集ばかりしていて、「最適化プロセスを作る」ということを正確に理解してなかったのではないか、と考えています。

　というと「そんなことはない、ウォーターフォールやスパイラル、統一プロセスなどもあるし、会社でまとめた開発プロセスなど、様々な方法をやってきたぞ」と思われるかも知れませんが、これらは全て情報（データベースのレコード）にしか過ぎません。

　私自身、ＩＴ業界に入った当初は、様々な書籍を読みあさり、書かれていることにのっとった形になるように様々な文書フォーマットを、当時最新の、それでも一度に一字しか漢字変換できないワープロソフトで一生懸命作ってみたりしました（素晴らしいことに四文字熟語は一度に変換できました）。

　しかし、そこそこできている感じ、あるいは「揃った」という感じに表面上はなるのですが、実感としては「うまく行った」という感触を持つ事はできずにいました。

　あるとき気がついたのは、目の前にある書籍がいくら有名な学者によって書かれたモノだとしても、地球の裏側にいる、目の前のプロジェクトとは全く無関係の人が書いているものだという、当たり前のことでした。

プロジェクトが上手く行く考え方

　そこで違う考え方を試すことにしました。以降、一切書籍や雑誌は見ず、目の前のプロジェクトそのものだけを見て自分で「最適」を考えるという進め方です。
　それ以来、プロジェクトはとても上手く行くと感じる様になりました。

　外見上はあまり変わらないかも知れません。
　「他者が行っているやり方に当てはめて進め方を考える」か「自分がやり方を考えるに当たって、他者のやり方を参考にするか」の違いだけであって、中には「それって同じじゃないの？」という人もいるかも知れませんが、これは思考経路としては、決定的に違うと言うことはおわかりいただけると思います。

　前者は例えば、「知識を持っていることを示したい」「このプロセスが言っているのは、こういうことだ、と指摘したい」など（私も本当に陥りがちですが...今後、そんな記事があったらご指摘を...）、様々な理由から作業が増えていくのに対し、後者はどれだけ同じ成果を得るのに作業を減らしたか、がポイントになってくるのが通常です。

　同じような理由で会社での問題指摘は、決まっているやり方を知っていて、何かを「やっていない」と指摘することによって集団の中で優位に立とうとしがちですので、どんどんと実作業者がやらなければならない、「本質的に作る事とは違う作業」が増えていきます。で、ドキュメントはいろいろあるのに、肝心のモノは全くできていない。これは「知識」による弊害というか「知識」の使い方のミスといえばいいでしょうか。

　気がついてしまってから業界誌や周囲の状況を見ていると、私の知る限りは、わりと最近までの２０年近く、一部のうまくやっている人達を除いて、ほとんど前者のイメージで業界全体が動いていた感触があります。

　これは、関わる人が多い大組織ほど、起こりやすくなる事ですし、誰にでも予測がつくことなのに、全く配慮されていなかったり、あるいは皆気がついていても公式の場では言い出さなかったりする場合も多く、なかなか抜け出せないということだと思います。

プロジェクトがうまくいく考えを生み出すもの

　ではなぜ、私自身が業界全体の流れのままで行かずに済んで、トラブルといえるほどの問題に一度もぶつからなかったのかと言うことを考えてみたことがあります。

　まずひとつめは小さな会社の仕事から始めたから、ということは言えると思います。
　これは規模の違いとか関係者数が多い少ないとかそういうことではなくて、うまく行っていないＩＴ大企業の進め方は、間違いなく小さな企業だったら訴訟レベルの大問題になりそうな雑な仕事が普通に起こっていてもそうならずに済んでいる、という印象です（たとえば、メニュー画面に戻れないシステムが納品され、承認済み、なのを見たことがあります）。
　「小さい会社だったら一度だけでも絶対にやっていけなくなる」と思うことが多々あるのですが、いつものことなので、どうでもいいらしい、と感じる事すらありました。つまり、危機感、恐怖感の違いです。

　ふたつめとして、これはあちこちでお伝えしているのですが、とても大きな要因として、ＩＴ業界に入って最初にＰＥＲＴ／ＣＰＭによる計画法を勉強したということが挙げられます。

　そうです。ＰＭＢＯＫに書かれているプロジェクト・ネットワーク図による計画法です。これが書かれていたブルーバックスの「計画の科学」という書籍をたまたまＩＴ業界での初出勤の帰りに恵比寿駅前の古本屋さんで２００円で買ったのがキッカケです。

　当時読み終わって「こんなカッコイイやりかたがあるのか。仕事が面白くなりそう」と思いました。同時に、その書籍が当時で２０年前（１９６５年、私が２才の頃）に書かれた本だったという事にも気がつき、なんでこれを学校で教えてくれなかったんだぁ〜！」と少しイラっとしたことも覚えています。

計画活動から全てが生まれている

　現在も相変わらず、学校で計画法を教えることは通常ありません。せっかく暗記しまくった知識の、最も効果的な活用法であると言えるにもかかわらずです。

　計画に当たっての「現状の理解」、理解のための「議論」、目標と現状を埋める「工夫」と「議論」も、計画と照らし合わせての「評価」も、「全て計画活動が生み出す」と言えるのに、「社会に出る前に、科学的かつ緻密な計画作成とその実行を意識して繰り返せないということは、とても残念なこと」と思っています。個々のプロジェクトでの明確な役割分担や評価基準が作れないために、「倒れるまでやったかどうか」だけという、デスマーチの根幹をなす評価の仕方が生まれていて、これは日本の伝統的な考え方になっていると思っています。全てプロジェクト・マネジャー以上のマネジャーの責任です。

　そして緻密な計画活動は、上記の「書籍に書かれていたり会社でまとめた開発プロセスなどの情報」を「最適化されたプロセス」の形で実際に活用する具体的な手段であるとも言えます。

　実現性や精度の高い計画がしっかりとできあがるならば、当然の成り行きとして、その通りにやってみて、うまく行くかを試したくなります。

　自然と、人（チーム・メンバー）がどうしたら計画通りに動いてくれるのか、実現したいことを首尾良く行えるのか、を考える事になるでしょう。

　それは計画内容を、いかに正確に速く伝えられるかと言う意味でコミュニケーションを考えることになり、いかに最初から正確に速く動いてもらうかと言う意味でファシリテーション、あるいはコーチングに当たる分野を、ほっといても真剣に考えることになります。
　少なくとも、頭ごなしにものを言って、計画通りに動いてもらうことはできないということには、一度本気でプログラマをやれば、すぐに気がつくはずです。そんな簡単な作業の業界ではないので。

　精度の高い計画をしっかりと作る方法を知っているなら「どうせ細かいところは曖昧で、変わってしまうし、とにかく始めれば分かる」と、いきなり始めてバタバタと試行錯誤を繰り返すような効率の悪い方法で進めるのではなく、計画のデザインの前に可能な限り多くの情報を集める事に意義を感じることができるでしょう。

　徹底的に情報収集（業務分析、最近ではＢＡ）を行うことについての承認を確実に取り付けることに大きな意味を感じることができ、高いモチベーションを持つ事ができます。

　私の経験では、上場企業や官庁の仕事で、最初からすんなりユーザーの現場を見に行けることは皆無でした。

　このあたりは日本が歴史的に弱かったマネジメントの分野の話となります。今後、本ブログで皆さんと一緒に考えて行く事になると思います。

　結果としては、精度の高い計画法を知っていることによって、書籍等に書かれている、「役には立つし知っている、やっているとカッコイイが、目の前のプロジェクトには関係のない事」への技術者的な誘惑に惑わされずに済んだのでしょう。そもそものプロジェクトの目的に合致した「使えるシステムを作る事」から外れずに進めることができました。

　そして「現場主義、現実主義」で、自分主体に思った通りのプロジェクトに持って行くという発想になったということだと考えています。

ＰＭＢＯＫに書かれている計画作成

　現在、ＰＭＰ資格取得者は日本のＩＴ企業に沢山います。

　ＰＭＢＯＫでは、計画作成の段階でバーチャート（ガントチャート）は出てきません。あくまでプロジェクト・ネットワーク図です。

　バーチャートは、あくまで計画作成を行った結果を見やすくするためのモノです。

　もちろん結果としてのバーチャートを見てさらに修正を行うということはするでしょうが、あくまで結果を見ているだけで、アクティビティの実行順序を考えるということをツールとして実現しているのは、プロジェクト・ネットワーク図です。

　私自身、超大手ＩＴ企業でＰＭＰ試験対策講座の研修をさせていただき、その中の質疑応答コーナーでは、無記名のカードに書いていただいた、実務に関する様々なご質問にも全て回答させていただいたりしましたが、相変わらず、国内のＩＴ企業でプロジェクトネットワーク図を基本として計画作成を行う事になっているという言葉を明確に聞いたことがありません。

　そもそもＰＭＰが普及したキッカケとなったと聞いている米国の某超大手企業が随分と昔からプロジェクト・ネットワーク図による計画を行っているということは知られているにもかかわらずです。

　研修をやらせていただくようになって、ＩＴプロジェクトにおける工夫そのものの他に、「なぜこういう工夫をしたか」という説明をさせていただく様になりました。

　その中でプロジェクトにおける様々な工夫が、自分がプログラマとしてデスマーチに随分とハマった経験から、「自分がプロジェクト・マネジャーをやる時は何としてもデスマーチにはしない」というモチベーションと、上記の通りプロジェクト・ネットワーク図を中心とした計画法から生まれていることに気がつきました（気がつくまでに２２年かかりました）。

　ということで、これからＩＴプロジェクトのデスマーチ根絶を目指すという、不可能かつ壮大なテーマで、プロジェクトマネジメントを中心に、このブログを書かせていただきます。

　初回は随分と長くなりましたが、今後は、ゆるーく不定期に、短かったり、長かったりと、趣味の話なども好き勝手に入れさせていただきながら、本ブログを続けさせていただければと考えております。

　改めまして、何卒よろしくお願い致します。