プロジェクトの目的は単純ではありません。

　成果目標は、企画・計画などのプロジェクト・エンジニアリングを発注する顧客の目的、プロジェクト・マネージメントを行う所属会社の営業目的、それに、プロジェクトメンバーのルーティンワークに携わる現場の目的>等が、互いに入り組みそれぞれ独立した要素目的を持っています。そして、それぞれがプロジェクトの目的を達成する構成要素として存在することで、プロジェクトの目的が構成されます。

　プロジェクト組織の発足は、継続的な事業活動を行う行う組織とは発足の動機が異なります。つまり、継続事業を行う場合は、事業活動を行う組織も継続しますが、プロジェクト組織においては、プロジェクト指向の目的によってプロジェクト・システムが発足します。そして、プロジェクト目的の達成、あるいは、プロジェクト・チームの意義が無くなったとき、システムは解散します。

　ですから、プロジェクトを直截的に説明すると、先例のない企画・計画・開発などの成果指向を対象業務として、専門的な知識的な価値（ノウハウ）、あるいは、専門技術におけるスキル（習熟）の実施を営業項目にする業務ということになります。

　そのため、専門職の優れたメンバーを異業種の所属組織に参加を求めることになります。ですから、プロジェクトメンバーは、プロジェクト活動の行われる期間に限って、所属組織からプロジェクトに出向参加という形式で離れることになります。

　そして、プロジェクト作業を行う現場には、所属組織よりの出張や派遣などの取り扱いによって一時的に、プロジェクト・チームのメンバーとして、労務管理を受けることになります。

　この労働は、通常の常傭作業とは性質に違いがあります。

　つまり、プロジェクトメンバーの作業内容は、個人行動が優先され、専門的なスキルを用いて能率良く作業を消化させる特長があります。ですから、プロジェクトに参加するメンバーの行動は、所属する組織の目的や、作業現場の管理の諸事情や目的によって、影響をうけるうけるおそれがあります。

重要なものは、顧客の目的

　しかし、プロジェクト目的の中でもっとも重要なものは、顧客の目的です。
何の問題を解決したいから、システム開発を計画したのか、この動機を理解しないと目的を把握できないという点です。もし、この目的の達成が不十分であると、顧客は完成とは認めず修正要求を出すことになるでしょう。

　またその反面で、設計技術的にはどんな解決法でシステムの目的を達成するのかという、問題解決の方法論がポイントになるケースもあります。

　次の課題に営業目的が関わります。
もちろんプロジェクトによる収益の黒字はいつでも営業目的ですから、その他にもこの顧客を得意先として固定化を願うことが目的であるかもしれません。けれども、営業段階で値引きをしており、今回は赤字にしないようにしながら顧客の信頼を勝ち取ることが目的、というようなこともあります。

そのような場合、採算をとろうとするあまり、無理をして納品物に顧客のクレームがつき、結局修正を要求され、信頼もプロジェクトの黒字化の二つともに失うということになります。

　ところが、根本的に無理な目標を強要されると、人間は知性的であることをやめてしまう傾向を持っています。そんなことにならないように営業レベルでどんなことをしたのか、その目的は何なのか、具体的に明確にしておくべきです。

現場として要員の養成を目的

また、現場としての要員の養成などという目的も、プロジェクトの目的にあげられます。システム開発では人的要素がきわめて重要なので仕事の中で要員のレベルアップを目指すことは、ある意味で投資行為にもなります。システム開発企業の教育は、オン・ザ・ジョブ・トレーニングとよくいわれますが、目的指向を考慮することを意識しないで、結果的に、教育になるはずという波及効果は多くを期待できません。

　けれども、仕事の技術内容がきわめて先進性の高い分野への挑戦であれば、この仕事での採算を考えるだけでなく、技術の習得という目標を立てることも可能になります。これは将来に対する投資の姿勢にもなります。

　プロジェクトの目的とはこのように、色々な側面からも考えられますが、個々の目的についてはそれぞれに優先度を決めておかなければなりません。もし、どちらかの目的のうち一つを断念しなければならないときに、この優先度を選択するのです。

　いずれにしても、プロジェクト管理とは、達成目的の実現のために状況を制御する行動です。ですから、その目的地もわからずに船の舵を取ることはできないことになります。

要員の選定
　システム開発の体制を整備するさい多分要員の選定という問題は、偶然そのときに空いているメンバーが選ばれるというケースが多いと思います。そして、「実務的にはそれ以外の方法などあり得ない」と主張されるかもしれません。

しかし、実際問題として、この要員の選定及びその投入計画が仕事の成否を決定するような大きい要素だとしたら、それを偶然に任せるという状況で良いのでしょうか。

　また、要員の問題は、単に量の問題として「必要な人数を集める」という派遣ビジネスでのスタンスから、一括請負での成功に導くために、必要な人材という「質の確保」という問題へ変化してきています。

プロジェクトの成功がメンバーにより左右されるという紛れもない事実を認めるとすれば、もはや偶然に任せて良い問題ではありません。企業において人事が最大の問題であるように、システム開発プロジェクトにおいても要員の選定ことが重要なのです。

　まともなプロジェクト管理などない時代でも、成功するプロジェクト管理などない時代でも、プロジェクト活動の評価は、成功するプロジェクトと、失敗するプロジェクトに分かれました。その決定的な理由は、「要員の力量」の有無になります。

　優秀なメンバーが自分の担当する仕事を確実に責任を持って成し遂げれば、それで仕事は成功のうちに終わります。しかし、管理にかなったものであっても、担当者の力量が不足していては、仕事は失敗に終わります。

　これは、管理の不要論を唱えるわけではありません。管理者不在でも、優秀なメンバーが集まれば成功したという昔のエピソードは、システムの規模が比較的小規模で、人数も少なくてできたという場合にだけ有効な話です。そして、本来管理者が行うべき内部調整や各人間の問題点のすりあわせなど、担当者間で行える程度の複雑さだけだったのです。

　つまり、管理者の行うべき機能を、現場担当者がそれぞれ分担していたのでした。現在のシステムの大きさや複雑さは、このような調整機能を専門に行う管理者なしには問題を、克服できない構成になっております。

　しかし、その反面そのシステム開発の成否を決める第一の要素は、「要員と仕事の適用具合」にあることは変わりありません。担当するメンバーが十分な技術力と仕事をやり遂げるという情熱を持ち合わせていることで成果を成功へ導いてくれるのです。どんなに易しく見える仕事でも、担当メンバーに油断や能力の不足があれば、やはり失敗することになります。

　システム開発の難しさややっかいさは発生した問題を解決できるレベルのメンバーがいないと、人材を増員してもその問題は解決できません。システムはだいたいにおいてコンセンサスでつくるものでなく「もっとも優れたノウハウを他の人にも使えるようにする」ためにつくられるものです。

　そのため、基本的なコンセプトに関わる部分は、だいたい一人で考えてはじめて、統一性のあるシステムになり得ます。多くの人々の共同作業にすると、各人のコンセプトの差異がシステムをまとめにくいものにします。つまり、「船頭多くして、船、山に登る」たとえの事態になります。

　このことは、必ずしも優秀なメンバーをたくさん集めればよいのではなく、各人にどのように適合した仕事を割り当てメンバーの力量を最大限に発揮できるようにするか。これが重要なポイントであることを示しております。これは、自然に仕事の成り行きで行う性質のものではありません。管理の観点から、事前予測と管理の自信をもって行う性質のものです。

「優秀なメンバーはコストが高い」という一般原則からしても、優秀なメンバーのみの構成は高いコストにのみのメンバーになって、採算の点から問題になります。

　「仕事の難易度にあったメンバーを選択し、各人にそれぞれ適した担当を割り当てる」という要員選定と仕事の分担割り当てが、管理者にとって最大の決断事項であるのです。

　開発しようとするシステムの規模が大きい場合には、開発プロジェクトの組織を考慮する必要があります。優秀なメンバーを擁しながら開発が失敗に終わったり、納期を大きく遅らせたりする例は少なくありません。

　このようなケースでは、大抵の場合、プロジェクト組織構成がはっきりしておりません。そのため、命令系統が判らずしかも内部的な調整を誰が行うのか不明になってる有様です。システム開発では、必要になるメンバー間のコミュニケーション回数に比例して生産性が低下します。つまり、コミュニケーションの数が多いほど、仕事の能率が下がります。そのため、どのようにしてコミュニケーションの数を削減する組織にするか、が研究されています。

　ＩＢＭ社のチーフプログラマ・チームという組織論が有名ですが、同じように、皆さんにお勧めする方法も、一人のリーダーに五人までのメンバーからなる開発チームの方法です。それにあうように仕事の分担を割り当てます。そして、管理者はそのリーダー達とのみ指示・報告を受けます。この方法であれば、意志疎通に必要な人間の数がグループ・メンバーではリーダーのみになります。

　システムの仕事は問題を理解するのにそれなりの時間がかかるので、理解しなければならないものを、減らすのも生産性を上げるのに役立ちます。リーダーが適当に問題を分割して、ここのメンバーが全体の理解がなくても、仕事を進められるようにする、いわゆるモジュール分割を行います。このような能力をもったリーダーを持てば、経験不足のメンバーであっても、仕事を進めることが可能になります。このように仕事の規模、メンバーの顔ぶれなどにより、開発を実際に行う組織の構成を決めることが必要になります。

　あるべき開発組織の構成が決まっても、それぞれの役割にはまる人材がいない場合が多いのではないかと思います。とくに、システムエンジニア技術を所有して、グループ・リーダーをこなせる人材が不足しているのが現状だと思います。

システム開発という仕事を、昔は一人で何でも行っていましたが、現在ではテクニカル・エンジニア、プロダクション・エンジニア、アプリケーション・エンジニア、デベロップメント・エンジニア、システムコーディネータ、システムエンジニアなど、いろいろ多岐な職種に細分化されるのがふつうの状態になりました。

　ですから、プログラマを何年か経験していくと、システムの専門技術者や、統合技術者であるシステムエンジニアに、成れるわけではありません。これらのシステム技術に関係する仕事には多くの高度な技術的な差異があると考えるべきです。

　同じように経験が長いから、リーダーを勤められるとは限りません。
とくに、コンピュータ関係の仕事はプログラムが典型のように、自分一人の世界にこもりがちになります。他人の動向に関心のないいわゆる技術者タイプの人が多くいます。このような周囲の人間関係に無関心タイプ型の人達は、リーダー適正に乏しく、もしリーダーにすると、担当者に作業をやらせようとするより、自分でやってしまう方法を選ぶ傾向を強く持っています。

　そのために、リーダーは自然に育つのを待つのではなく、意識的にその養成に勤める必要があります。その場合、該当者の現状を分析し、何を強化すべきかなどを把握して、実際の仕事を通して本人が自覚しながらオン・ぞ・ジョブ・トレーニングを行うべきだと思います。目的に対して無意識のオン・ザ・ジョブ・トレーニングからは、結局何も生まれないことになります。

　プログラマとデザイナーの仕事の間に、その知識や技術に大きなギャップがあります。経験だけでは管理などの力量をはかれません。そこで単に経験を尊重するだけでなく、一人一人の能力を把握し、足りない部分を、どのように養成するかを、考えておかねばなりません。

　人材が足りない場合。要員の能力が足りないと泣き言を言っても解決になりません。泣き言を言わずに、メンバーを養成するということも管理者としての能力の発揮するところです。個々のメンバーの特長をよくとらえ、適切な指導と仕事の割り振りを行うことで、そのメンバーの能力を向上させます。

仕事をしながらの人材養成こそが真の養成である真剣勝負です。そして、担当者に生きた教育をほどこすことができます。実際においても、豊富な人材を使えることはほとんどありません。「育てながら仕事をする」以外に成功することができないのが現実の姿です。

　また、担当者のサイドから見ても、自分をきちんと見てくれてレベルアップを図ってくれる管理者に対して、忠誠心が生じます。逆に要員を機械の部品のように固定的で進歩のない単なるコスト要素であると考えている管理者が、信頼を集められるとはとうてい考えられません。システム開発は結局、人間が行います。成功と失敗を決めるものも単なる合理だけでなく、人間的なものも大きな要素を占めています。

ですから、プロジェクトに参画しているメンバーこそが最大の関心事でなければならないでしょう。メンバーの心を一つにして頑張ることができれば、たとえ難易度の高い開発であっても、成功に導く道を発見できることは容易なことだと思います。