●連載・プロジェクト管理のつぼ●

第一回　キモに銘じておくこと

プロジェクト管理委員会
（promgt@bolero.plala.or.jp）


■はじめに

　2002年４月のみずほ銀行決済システムのトラブルや2003年３月の航空管制用飛行計画システム障害などの公共的な社会基盤を担うシステムに問題が発生したことなど、開発対象となるシステムの巨大化、複雑化等もあり、近年、システム開発やソフトウェア開発のプロジェクト管理に注目が向けられている。また、プロジェクト管理に関する多くの書物や手引書が新たに出版され、さらに20年ほど前に脚光を浴びたソフトウェア工学の教科書が再版されるに至っている。

　これらの開発手引書やプロジェクトマネジメント手法書にも一部触れられていることではあるが、実際の開発現場はマニュアルどおりに動かないことが多々ある。終始順風満帆に進むことはまずないといっても過言ではない。実際の開発業務では対象とするシステムへの要求条件や開発作業に従事するメンバーの特性等を考慮したプロジェクトマネージャーの判断、行動が重要となる。システム開発やソフトウェア開発は、その分プロジェクトマネージャーの考え方が活かせる興味深い仕事とはいえるが、いい加減な気持ちで取り組むと多数の関係者を巻き込むトラブルを引き起こすことも事実である。

　従来の開発手引書やプロジェクトマネジメント手法書は、主に開発者側（例えばシステム開発の受注者側）から、顧客のご期待に沿えるよう、納期までに機能、品質の確かなものを提供するにはどうすれば良いかの観点から書かれていた。しかし、実際には開発作業は多くの関係者で成り立っていて、特に発注者の協力無しに成功することはまずあり得ない。受注し実際に開発する側の観点のみならず、発注者の観点からのプロジェクト管理も非常に重要といえる。システム開発プロジェクトでは予期せぬ出来事が起こるのが当たり前であり、危機や難局を乗り越え、当初目標どおりにシステムを仕上げるためには、発注者、受注者双方がプロジェクト状態のモニタリング、アクション、作業計画の作成・調整、関係者の意識共有など、日々のマネジメント業務（意識的な行動と舵取り）が欠かせない。

　プロジェクト管理研究会では、実際のシステム開発プロジェクトマネジメント業務に従事した経験やこれまでの先輩諸氏から引き継がれてきたノウハウをもとに、発注者側がシステム開発に大きく関与するケースに関し、どちらかというと発注者側の視点にたち、開発業務を進める上で重視すべき考え方や事項についてまとめた。プロジェクトを成功に導くためにマネージャーは何に着目し、どのように行動するか、当たり前のようなことであるが実務経験から学んだことを３回に分けてご紹介したいと考えている。第一回目は「キモに銘じておくこと」、第二回は「開発作業計画の作り方」と「進捗管理」について、第三回は「品質管理」と「コミュニケーション」について述べさせて頂く。開発モデルにはウォーターフォール・モデルや、RUP（Rational Unified Process)、XP（eXtream Programming）等の段階的/反復型開発モデルもあり、どの開発モデルを採用するかによって工程管理や開発の仕方は異なる。今回ご紹介する内容は、どちらかというとウォーターフォール的な観点が強いこと、書かれている内容の性質上、ある種、個人的とも受け取られる見解も多く含まれることにご容赦いただき、プロジェクトマネジメント業務に従事されている皆様の一助になればと考えている。

　なお、具体的なシステム開発のプロジェクトマネジメントの方法については、各種一般の書物（例えば文末、参考文献の[１]〜[８]）や各開発の現場で利用されている開発作業標準に規定されているので、基本事項はそれを読んで頂ければと思う。

■キモに銘じておくこと（五カ条）とは

　システム開発やソフトウェア開発の責任者に命じられた人や、その部分的なコンポーネント開発のマネジメントを委任された人（以下マネージャーと呼ぶ）の行動を観察すると、他のメンバーや委託会社へ熱意をもって働きかけ、多くのエネルギーを費やして業務を遂行していることが観察できる。そのような行動力や責任感のある人がマネージャーに任命されるといったほうがよいかも知れない。マネジメント業務は大変人間臭い仕事の側面をもっている。しかし、その努力が結実せず、不幸にしてプロジェクトの運営がうまくいかなくなることがある。具体的には、プロジェクト運営の問題は下記のような現象となって現れてくる。

・個人や個々の委託会社が「自分のパートはしっかりやっている」と、ことさら強調しはじめる
・マネージャーが全体像（進捗や品質）について第三者に判るように説明できない
・問題が解決可能な具体的な課題に変換されない
・課題解決の期限が何度も修正される 等

　このような状態に陥らないようにする、または症状を早く発見するために、開発責任者やマネージャーが頭に叩き込んでおくべき原則があるように思う。

　仕事を他のメンバー（例：同僚）や委託会社（以下委託先と呼ぶ）に依頼しているにもかかわらず、出来不出来の責任の50％は自分にある（つまり発注者側にある）、という一見逆説的な話である。


キモに銘じておくこと（五カ条）

第一条：出来の悪い仕事の責任の半分は発注者側にある

　仕事を委託された側（受注者や開発者）は発注者のオーダーに基づいて作業を行い、経過や結果を報告し承認を経て仕事を完成させる。発注者は仕事の成果と引き換えに報酬を支払うことになる。この過程で発注者にはマネジメント責任が発生する。発注者は、委託先の選定/仕事の内容提示/仕様の規定/進捗の把握/修正のオーダー/結果の評価など、仕事を完成させるためのキーとなる重要な行為（舵取り）を担当することになる。よって、それらの行為（舵取り）が適切に実行されないと、システム開発の方向やスピード感が狂い、結果が悪くなるのは当然といえる。

　大きなプロジェクトなどで仕事の委託関係が階層化されている場合でも、各階層で発注者としてのマネジメント責任が生じる。さらに開発のオーダーが発注者側の［部課長］→発注者側の［担当］→［委託会社］→［再委託会社］という流れを辿る場合、発注者側の担当や委託先も次の委託先への発注者としての責任を持つ重要な役割を果たしている。つまり、発注会社と委託先会社の二者間のみならず、上記の部分的な関係においても二者関係が存在し、プロジェクト管理業務が発生する。

　委託関係が階層化された場合、各階層の担当者にとって重要な原則があるように思う。その原則とは、「�@開発プロジェクト責任者以外の課長や発注者側の担当者は、職務上の権限は限られている、�A一般には仕事を任された形になっていても、開発の基本条件（発注会社と委託先の基本条件）に抵触する事項については判断情報を上位マネージャーに報告し、その都度、判断を仰ぐ義務がある」ということである。当たり前のことであるが、コスト、納期、影響範囲の大きい仕様変更の可能性等が予想される場合は速やかに報告し、判断を仰がねばならない。

　一方、発注者側の開発責任者は各階層において前述の原則を自組織内のメンバーや委託会社に浸透させることが重要となる。しかし表面的には理解を示してもなかなか行動の伴わない人が必ず存在するものである。実際には、このような人がいることを前提にプロジェクトの運営を行なうことになる。以下の例は、必ずしも一般的な例ではないが、筆者らがこれまでの開発プロジェクトで得た一つの傾向である。

例1：企業グループなどの仲間内だけで仕事をしてきた組織や人は、以心伝心で仕事ができると勘違いし、あいまいなオーダーと報告で仕事を進める傾向がある。この場合、結果が出た時点でオーダーの意識違いに気付き大きな手戻りを生じさせる危険がある。

例2：他組織や他社との業務取引の経験の少ない人は、契約という概念や指示（業務命令）という概念がなかなか理解できず、上位マネージャーの指示を軽視したり、感情面の人間関係を重視するあまり委託会社へ契約上必要な指示が出せない場合がある。

　この例に示すような組織や人に限って自分の責任範囲を矮小化し、仕事がうまく進まない原因を再委託先のせいにすることがあるように思う。ただし、一般的には悪意でなくビジネスやマネジメントの基本を知らないことから生ずることなので、発注者側の開発責任者は委託先から報告を受けた際などに説明を注意深く聞き分けて、委託先の力量、責任感などを掌握した上で、必要に応じて是正措置を講じなければならない。

　一人ひとりが自分の職務をわきまえ責任を自覚しているプロジェクトは、問題が発生しても機動的な動きができるようになるので、意識的にそのような状態にプロジェクトを近づけてゆくことが、開発責任者のツボの一つかと思う。

NEXT >>