プロジェクト・チームの編成で失敗していませんか：何かがおかしいIT化の進め方（3）

[公江義隆，＠IT]

情報化プロジェクトを進めるに当たって、その要員をどう集めるかは、特に人的余裕に乏しい中堅・中小企業にとって頭の痛い問題だ。プロジェクトを進める際、教科書では「既存組織から独立し機能的に完結したプロジェクト・チーム制、メンバーも専任が望ましい」としている。情報化プロジェクトにおいて、これが本当に望ましい姿であろうか？ 今回はこんな問題を現実論として考えてみる。

世の中にはさまざまな種類のプロジェクトがある

　プロジェクトと呼ばれるものにもいろいろある。企業内の研究開発プロジェクトなどは「プロジェクト＝研究開発テーマ」として、既存組織の中での「人のアサイン」ととらえる方が分かりやすい。

　一方には、新規事業プロジェクトや新規工場の建設というような、既存の組織の「外」に発生する非定常な問題に対するプロジェクトがある。この場合、遂行に新たな組織（プロジェクト・チーム）が必要となる。そしてプロジェクト・チームの中で、白紙の状態から必要なことすべてを考え実行していかなければならない。情報システム分野でいえば、初めてのシステム開発を開発方法論を持たずに行うようなものだ。この種のプロジェクトでは「白紙からの、初めての種類の問題」というところに難しさがあるが、その一方で既存のもろもろのものとの摩擦は比較的少なくて済む。

　この“白紙から”型プロジェクトでは、未来での役割がおおよそ想定されるので、「自分が将来やるべきことの準備をしている」という見方ができる。例えば新規事業プロジェクトの責任者が新会社の社長に、市場開発の担当が営業部長に任命されたり、または新工場建設プロジェクトでは、プロジェクト責任者は工場長に、製造設備の設計の取りまとめ役は製造部長に任命されたり……という具合だ。時間のズレはあるものの、自分のやったことは自分に跳ね返ってくるという自己の中で完結する形になっている。

「アサイン型」プロジェクト 「白紙から」プロジェクト 形態 ある目標に基づき、既存組織の中で人をアサインし、チームを組む形態のプロジェクト。既存の制度や事項との調整が難しい ある目標を遂行するため、人事異動などにより新たに別組織を起こす形態のプロジェクト。過去のノウハウがない分、問題にぶつかることも多いが、既存制度との摩擦は少ない 特徴 完全な自己完結型ではない 自己完結型 例 情報化プロジェクト、研究開発プロジェクト 新規事業プロジェクト、新工場建設プロジェクト

表1　プロジェクトの種類と特徴

　現在の体制や業務のあり方全体を一新するような超大規模情報システムの開発プロジェクトは別として、一般的な情報化プロジェクトではどうであろうか。

　現実の情報化プロジェクトの多くは、「白紙からの、まったく初めての種類の問題」という要素は比較的少ない。その半面、既存の事項との調整項目や制約が多い。

　情報化は、「業務のプロセス／組織体制を変える」という業務改革の問題である。つまり現行の組織内部の問題であって、現在の組織の「外」に何か新しいものを作る問題ではない。情報化プロジェクトの対象部門の責任者はプロジェクト終了後もそのままだろうし、そのほかのキーマンについても恐らく同じだろう。情報化プロジェクトが人事異動の引き金になることは、普通想定外だ。プロジェクト途上でまずい決定があれば、それは後になって対象部門の責任者に降り掛かることになる。

　各部門は情報化の課題以外にも数多くの問題を抱え、それらの多くを平常体制の中で解決している。例えば、既存工場にある老朽化した製造装置をリプレースする場合には、どのような体制、どのような手順で物事が進められているのだろうか。多くの問題は、通常の指示命令・報告系統を通じて物事が運び、既存の決裁手順を踏んで物事が進められているはずだ。

　情報化の課題について特別扱いする理由はない。ほかの問題と同様、体制や手順に沿って扱われるのが自然な姿ではないだろうか。ただし何か問題が起こったとき、プロジェクト・チームを編成して対処することが常態化している会社なら、情報化・IT課題についてもそうするのが良いし、トップが何でも細部まで指示しないとうまくいかない会社なら、情報化も課題もトップダウンでやるのが良い。

一般の情報化プロジェクトには立派なプロジェクト・マネジメント論は合わない

立派なプロジェクト・チームにするほどユーザー部門との溝が広がる

　世にあるプロジェクト・マネジメントに関する教科書の多くの内容は、“白紙から”型プロジェクトを前提に、既存の組織から独立した軍隊型の立派な組織を理想としている。ここでいう軍隊型組織とは、内部に一式の機能を持つ完結性の高い組織のことである。遠隔地で孤立無援になることが想定される軍隊は、独立して行動できるように、内部に医療、司法（軍警・軍事裁判）、建設（工兵）……など、機能一式を内蔵している。同じく治安維持を目的とする組織である警察は、行政の機能の一部として、単体機能しか持ち合わせておらず、ほかの機能と連携してしか活動できない。

　プロジェクト・マネジメント分野の専門家といわれる人たちも、こんな教科書で勉強した一昔前の情報システム開発リーダー、あるいは工場建設や巨大プロジェクトなど、“白紙から”型の経験者の方が多い。

　一昔前の情報化プロジェクトは現行業務のコンピュータ化が中心的課題であり、コンピュータによる情報処理システム作りがその中の主要な作業だった。このケースでは、対象業務の基本的内容は変えるわけではない。そのためそれなりに手間の掛かる作業ではあったが、業務部門とのかかわりも、現状を確認してこれに従ったモノ作りを行い、あとは新しいツールの操作方法の説明程度で事足りた。一方、システム開発という仕事は、企業の平常の運営機能から懸け離れた一時的な存在である。これを一時的な特別の体制で行うことの意味があった。

　しかし現在はどうであろうか。情報化は業務プロセスや組織の改革である。社員の意識改革や動機付け（motivation）、教育が重要になる。改革を求められているのは業務部門であり、お金（効果）を生み出すのは新しい業務プロセスと、これに携わる“人”である。業務部門の既存組織の中で進めるしか本来的に道がない問題である。既存組織の中の1テーマとしてマトリクス・マネジメント（プロジェクトとラインをマトリクス組織的に考える管理）の問題になる。

昔の情報化プロジェクト いまの情報化プロジェクト 情報化の課題 現行業務のIT化 業務プロセス／組織の改革 業務部門とのかかわり 現状の確認とIT教育 ・業務プロセスの改革 ・部門スタッフの意識改革と動機付け プロジェクト体制 通常の運営機能から離れたアド・ホックなプロジェクト 業務部門の既存組織の中で進めるべき

表2　情報化プロジェクトの特性

　情報システムは、これらの改革を支えるツールと位置付けられる。つまり、お金を使う側の役回りだ。問題が高度化する中で、専門性を持つ限られた人材をいかにうまく組み合わせ、コスト・パフォーマンスの高いシステムに仕上げるか。マトリクス・マネジメントの重要性は、別の意味でIT部門についてもいえる。

情報化プロジェクトのため新組織を作る必要があるか？

　例えば、専門分野の異なるAさんとBさんがいるとしよう。Aさんの専門性とBさんの専門性を共に必要とする業務テーマ（プロジェクト）が2つあったとする。AさんとBさんを管理するマネージャには、この2つのテーマを1つの管理対象にまとめ、それぞれの専門性が2つのテーマの中でうまく展開できるようにコントロールすることが求められている。片方のテーマをAさんに、もう一方はBさんにそれぞれ「任せる」という名の下に、問題の丸投げをしてはいないだろうか。もしそうならマトリクス・マネジメントをうまくやったライバル企業にマネジメント力の差で完敗することになる。

　情報化プロジェクトにおける業務部門についても同じことが当てはまる。本来自分の問題であることを他人であるプロジェクト・チームに任せてしまえば、結果的に自分の思惑とは違った結果になるのが当然だ。またIT部門についても、プロジェクト・チームという別組織にすることによって、数少ない手持ち人材の持つ専門性の活用が難しくなる。さらに1プロジェクト内では完結しない、ITインフラやアーキテクチャの標準化や、これを通じた全社システム最適化という問題を遠いものにしてしまう。

　つまり教科書にあるような“独立した”立派なプロジェクトで進める形にするほど、業務部門との間に権限上の対立構造を作ることになり、結果的に内容にギャップを生じさせ、プロジェクトの始めと終わりで2重の苦労をすることになる。また、情報システムのコスト・パフォーマンスや全社最適化を損なう結果にもなりやすい。

　ただし、鳴り物入りのプロジェクト・チーム体制には、社内全体に対し「これをやるぞ！」ということを示す絶大なPRの効果がある。そうたびたび使える手ではないが、会社が大きく方向を変えていく場合などには、社員に対する動機付けの手段にできる。

　このような観点に立てば、できることは可能な限り、既存の平常組織の中でマトリクス・マネジメント的に進めるようにし、そこからはみ出る部分だけを臨時組織であるプロジェクト・チームでやるという考え方が妥当ということになる。特に、「絶え間ない革新の継続が必要、変化の常態化を事業環境が求めている」といわれる昨今の経営の下では、ますます平常組織の中で進めていく考え方が重要になる。

　“情報システムのモノ作り”プロジェクト・チーム中心の情報化の時代は終わり、関係者との密なコミュニケーションこそが鍵の時代になった。「情報化課題（IT化）課題＝プロジェクト」「プロジェクト＝プロジェクト・チーム体制」という発想から脱皮が必要と思う。ユーザー企業にとって情報化は、モノ作り・技術の問題ではなく、業務プロセス・組織・人作りの問題である。

　初めて情報化・IT化に着手するといった企業は、まずはプロジェクト・チームでスタートするのが妥当であろう。こうした経験を通じ、組織の中に情報化・IT化に対する理解が進んでくるに従い、将来に向けてどのような体制で進めるのが自社にとってベストなのか――世の通説はさておき――を考えてみることをお勧めしたい。

プロジェクト・メンバーは専任が良いのか？

　具体例として、プロジェクト・チームのメンバー編成問題を考えてみる。どうしてもプロジェクト・チームでやらなければならない作業もあり、このためのメンバー確保はいずれにせよ必要である。

　教科書には「プロジェクトのメンバーは専任にすべし」と書いてある。専任であれば、“実家部門”の仕事の都合で“一時帰省”してプロジェクトの方がおろそかになる心配もない。部門の利害にとらわれず、理想の追求ができるなどといわれている。

　プロジェクトを管理する立場から見れば、自分の裁量の幅が広がる点でもこの形は一見魅力的である。しかし現実にはどうだろうか。

　例えば、あなたがプロジェクト・チーム編成（人集め）に奔走する中で、業務部門の管理者からは次のような話が出てくるとしよう。

　こうした話し合いの中では無意識のうちに、「自分側の問題を説明するより、相手から情報を引き出して自分の方で判断したい」という態度になっていることが多い。相手はプロジェクト・チームに出す自分の部下に求められている仕事の内容は分かっていない。あなたはA、B、Cさんそれぞれの人物や能力に対して情報は持っていないし、少し話を聞いたぐらいで分かるはずはない。人事のミスマッチは誰にとっても不幸な結果になる。特に情報化プロジェクトのような短期決戦の仕事では、このミスマッチが致命的になる。

別部門のスタッフをプロジェクト・チームにスカウトするには

　人事異動における人選は、人を出す側の判断が原則である（もちろん企業によっては、公募制など受ける側で徹底的に審査して決めるケースもあるだろう）。そのために、人を求める側からの十二分の説明が必須条件になる。「システムの外部仕様の検討うんぬん……」程度の説明では、相手には到底理解できない。担当してほしい業務範囲の説明は欠かせない。相手からITはひとくくりの問題と見られているように、販売はひとくくりの分野と思っていても、受注は顧客問題としてDさんが専門、在庫は流通の問題として現在別途Eさんに担当させているといったこともある（同じ会社にいれば本当はこんな動きは把握しておかなければならないが……）。

　もう1つは、具体的な問題の2〜3のケースを挙げて、「在庫管理の発注点や規準発注量をまとめてもらう仕事」など、仕事の内容と要求する質の具体的なイメージを分かってもらうことである。この理解が人選の判断条件となる。人選次第で業務部門の将来の仕事が左右してしまうことを、相手に理解してもらう機会でもある。

　また、システム開発プロセスを通じたITリテラシー教育の絶好のチャンスでもある。忙しいキーポジションの管理者には、こんなときぐらいしかITの話は聞いてもらえない。

　相手がやることの全容を理解すれば、人選だけでなく、業務部門でやる問題や範囲について意見が出てくる可能性もある。例えば、「この部分はプロジェクト・チームでやってもらわなくても、自分のところで検討した結論があるからそれでやってほしい」などだ。そうなればしめたものである。関係者、特にキーポジションの人の参画意欲が、プロジェクト成功の大切な要件となる。

　それでも現実には、目を付けた優秀なキーマンAさんは出してはもらえないだろう。Aさんにはいまのポジションのまま、プロジェクトの途上で、進み具合の評価や重要事項の判断・決定を行うレビューメンバーとして参加してもらい、業務部門内部への影響力を行使してもらうことが現実的であり得策である。

　優秀な人でも、その権限が行使できるのはポジションがあってのことである。もし現職を離れプロジェクトの専任スタッフとなれば、元の部門内部に対する影響力は激減する。後任はAさんのライバルといったこともある。工数を要する“量”の作業と、判断・決定といった“質”の仕事をうまく分離して、人のアサインを考えることが、最小の人的負担で目的を達するための重要なポイントである。