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

[公江義隆，＠IT]

マネジメント能力とは何か―マネジメントの問題を抽出してみる

　日本の多くの企業で、情報システム開発プロジェクトのプロジェクトマネージャは、マネジメント以外の多くの作業を課されている場合が多い。よくいえばプレイングマネージャだが、現実は組織全体で考えるべき問題（注1）までもが、1プロジェクトマネージャに丸投げされているようなケースもかなりあるような気がする。

　少し極端ないい方をすれば、マネージャの役割は「見て・聞いて」「判断・決定」し、それを部下や関係者に「伝える（報告・連絡・指示・命令）」ことと、「仕事に必要な環境・条件を整えること」に尽きる（注2）。PDCAサイクル上でいえば、P（計画）とC（チェック）、それとA（アクション）の指示がマネジメント機能である。

　「プロジェクトがうまくいかない」＝「プロジェクトマネジメントの問題」といったことに安易にしてしまってはいないだろうか。うまくいかないのは、マネジメントが問題なのか、プレイヤーが（として）行う個別の作業の問題なのか。または、特定のプロジェクトの問題であったのか、常に発生する問題なのか、それらを峻別してそれぞれに別の対策を考える必要がある（注3）。

　常に発生しているマネジメントの問題とそれ以外の問題を切り離してみて、まず「マネジメントとは何か？」を考えてみることが、この能力育成を考えるうえでの出発点である。

---

（注1）

例えば、システム構成法や開発方法などについては、システムタイプ別の標準を、組織として（一定期間を対象に）設定しておくべき性格のものであるし、新技術や商品の評価、オフショア開発などの課題は、将来を踏まえて組織全体として考え・決定すべき問題だ。

システム開発プロジェクトに検討を委ねる理由として、日進月歩の技術の適用、目まぐるしく変わる環境への適応を挙げる方がおられる。

しかし、作られた多くの情報システムは数年〜十数年使われるのである。バラバラな考え方やシステム構成方法、バラバラな技術や商品で作られた相互に整合性が取れていないいくつものシステムの集合体は、企業全体から見てシステムといえるだろうか。10年にわたる管理ができるだろうか。

---

（注2）

プロジェクトの代表者・責任者として、同レベルや上位の関係者との間のコミュニケーション（連絡・依頼・協力の獲得、報告・承認を得る……）は、プロジェクトに限らず、組織を代表する人の一般的な責務であり、これは自分の管理する組織（部下）が行う仕事の環境・条件を整える大切な仕事の1つだ。

しかし、これに対する一般的なルールや方法が決まっているわけではない。どのようなケースなら「自分の一存で処理しても大丈夫か、あるいはどのような形で相手に伝えるのが良いか」は、問題と相手と自分の3者の関係で適切な形が決まる。

組織や人間関係の問題としての判断力や人間関係形成力と、問題解決の方法をいかに数多く持っているかということが問われることになる。

---

（注3）

システム開発上よく問題となる、「システム仕様・条件の検討・設定」の不備によるプロジェクト結果の不首尾という問題について考えてみる。

仕様・条件の内容に問題があるのは、この作業を行ったSEの問題である。この作業をうまく進めるために必要なユーザーとのコミュニケーションに問題があったとすれば、それもSEのその業務分野に対する理解力や知識、コミュニケーション能力の問題である。SEの業務に対する理解力やコミュニケーション能力を高める施策を考えることは必要であっても、マネージャ自身にそれらの実務能力が求められるわけではない。

この場合、マネージャに最も問われるのは、不備な仕様・条件を“是”とした判断、GOサインを出した決定に対する責任である（不備と判断していれば、別途ユーザー組織の責任者と確認の場を設ける、後々懸念される問題について事前に何らかの取り決めをしておくなど、マネジメントとしては打つ手はいろいろある）。ささいなことにとらわれず、問題の本質を把握する力が判断力の源になる。このためには日常の業務の中で、「何は枝葉で、幹はどれだ」ということを自分自身の中で常に問い続け、問題をシンプルにすることを習慣化しておくことだと思う。

また、コミュニケーションについては、「ユーザーとの適切なコミュニケーションの場や手続きの設定がされていたか」、「必要なコミュニケーションがなされているかを確認したか」など、さらにもう一段突き詰めれば、「SEのアサインは適当であったか」がマネジメントの問題である。

ただし、結果がどうであれ、マネージャとして結果に対する責任を負う覚悟をしておくことが肝心だ。覚悟をすれば答えが見えてくることも多い。

余談になるが、それにしても10年?15年間使う基幹システムの仕様／条件が、システム開発途上で大幅に変更／修正が必要になるのというのは、最初の決め方に問題がある場合がほとんどのはずである。

---