私が日頃目にするITプロジェクト管理関連の書物はソフトウェア開発方法論や開発ツールに偏重していると感じています。また、方法論や開発ツールを導入すればプロジェクトの生産性が向上し、成功すると思い込んでいる経営者がいるようにも思います。方法論や開発ツールの重要性に疑義を差し挟む余地は些かもないのですが、プロジェクトの成功にはこうした方法論や開発ツールに加えて戦略が必要です。

また、上記の書物の多くは単独のプロジェクトに的を絞った議論になっています。プロジェクト管理を成功させるには、当該プロジェクトを含む組織がどう行動するかを考える必要があります。複数のプロジェクトが同時並行的に遂行されている組織（企業、システムプロバイダー）にとって、組織全体の利益（短期のみならず、中長期的利益）が得られなければ成功とは言えません。一つのプロジェクトの失敗が組織の生き残りを危うくすることがあり、逆に経営判断のミスがプロジェクトの失敗の原因になることもあります。

戦略というからには相手が存在します。ITプロジェクト戦略では、市場という“場”における競合他社が相手ということになります。相手の出方に応じてこちらの出方を決める必要があります。市場はいろいろな要因で変化しますので、その中で、自組織が最も有利となるよう行動するのです。

本稿ではITプロジェクト管理を、人間を扱う戦略的視点から捉えて見たいと思います。

「戦略の本質」（日本経済新聞社　著者：野中郁次郎、戸部良一、鎌田伸一、寺本義也、杉之尾宜夫、村井友秀）では、第8章において、戦略の構造とメカニズムを論じています（下表は本書の表8-1を引用）。

ITプロジェクト戦略にも、この戦略の構造化の視点を応用することができます。

ITプロジェクト戦略は４つのレベルで捉えられます（下表参照）。一方の極の戦略は経営戦略で、他方の極の戦略は技術です。その間にプロジェクト戦略、戦術のレベルがあります。組織が市場で生き残るために、これら４つのレベルの戦略を重層的に活用するのです。

相手がどう出てくるかによって、自組織の出方を決めなければなりません。経営戦略のリーダは組織にとって最も有利となるよう、他のレベルの戦略にも気を配る必要があります。各レベルの戦略は自組織が市場で最も有利となるように、それぞれの立場で行動します。相手がどう出てくるか常にウォッチし、普段から相手に勝る準備をしておく必要があります。

以下では、主として、今日のITシステム構築サービス市場を中心に、各戦略レベルで想定しておくべき課題について考えます。

（１）　技術のレベル

システム開発における技術として、ソフトウェア工学の技術やそれにもとづくツールがあります。他社が使用している開発ツールよりも圧倒的に生産性・性能・品質が高いツールが使用出来きるならば、優位に立てるチャンスが生まれます。ITシステム構築サービス市場をターゲットにする中小システムプロバイダーにとって、これはなかなか困難な課題です。自社のみが優位に立てるツールを独自に開発するには、莫大な費用がかかります。一般の業種システムの構築では、市場が大きい反面、対戦相手が多く、使用するツールを顧客が指定する場合もあります。中小システムプロバイダーの場合、標準的ツールで勝負する以外に方法がないのが普通です。

以上のことから、ITシステム構築サービス市場では、市販の標準的ツールを使いこなす錬度で勝負する必要があります。これについては次の（２）戦術のレベルで説明します。

ITシステム構築サービス市場に、大企業から提供される機能では満足できない顧客を狙って、（初期段階では規模が小さな）市場に向けてツールを開発し、標準的ツールの隙間をついてサブ市場を開拓する技術戦略があります。例えば携帯電話のWebブラウザやASP（アプリケーション・サービス・プロバイダー）型のグループウェア、高度な電子帳票などで実績を上げた企業があります。今後、 SaaS（Software as a Service）タイプのサービスで、上記と同様の技術戦略で成果を上げる企業が数多く出てくるものと思われます。

国家戦略が必要なケースでは、事情が異なります。監視衛星、スーパーコンピュータ、武器などに搭載するソフトウェアは機密保持された状況で開発し、他国のものよりも優れていればそれだけ経済／軍事的に優位になれます。この戦略では相当の資金を投入する必要があります。

（２）　戦術のレベル

プロジェクト管理と言うと、方法論や開発ツールを駆使し、淡々とこなせば旨く行くと考えている向きがありますが、それだけでは不十分です。プロジェクト活動を実践するのは、プロジェクト状況に合わせて編成する小規模の実行チームです。チームを運営するのはチーム・リーダ、システム技術者、プログラマです。戦術のレベルの主役は彼等です。

チーム・リーダ、システム技術者、プログラマは顧客の要求を満たすべく、関係者の出方を見ながら、チームで立ち向かいます。彼等は上位のプロジェクト・リーダから与えられた役割をこなすために、チームの能力を最大に発揮すべく努力するのです。

チームのメンバ（システム技術者、プログラマ）は、チームの目的を達成するよう行動します。戦術のレベルの課題は次の通りです。

１）　規律

チームには規律が求められます。個人が別個に行動することは許されません。たとえば、規律の一つである会議の開始時間を守らないメンバは排除されなければなりません。規律を守ることはチームワークの基本です。

２）　結束

チームのメンバにはチームの役割に沿った、それぞれの役割が与えられます。時々刻々変化する環境の中で、メンバは互いに状況を報告し、他のメンバと協調して自己の役割を達成します。チームが結束するためには、共通の仕事を通して、メンバ同士が信頼関係を築いていることが必要です。

３）　リーダに求められる資質

信念、先見性、持続力、情熱、迫力、集中力、体力、判断力、理解力、決断力、勇気、積極性、実行力、説得力、信頼感、強い責任感、冷静さ、着実性、緻密さ

４）　リーダシップ

リーダは組織、プロジェクト、およびチームの目的をメンバに納得させることが要求されます。
リーダはチームの規律・結束を強化維持し、メンバの士気を高揚させます。
リーダは刻々変化する環境を確認しながら、各メンバの役割を見直し、指示し、チームの目的を達成するよう調整します。

５） 錬度

機能設計・構造設計・アーキテクチャ設計・詳細設計・品質・性能については勿論のこと、システム開発に使用する方法論やツールについても、メンバおよびチームの錬度が要求されます。システム開発を開始する前にこれらの錬度を上げておく必要があります。市場で競合する他社も同じ方法論やツールを使用している場合、上記の１）～４）や錬度で勝負します。

（３）　プロジェクト戦略のレベル

プロジェクト戦略レベルでは、プロジェクト計画立案とプロジェクト推進が課題となります。プロジェクト・リーダは、プロジェクト推進チームを立上げ、このチームに支援させてプロジェクトを統括し、開始から終了に到るプロジェクト運営に関わる全ての責任を負います。

本稿ではプロジェクト戦略のレベルを説明するために、Waterfall型の開発モデル（下図参照）を使用しますが、このモデルでは、調査＆機能設計＆構造設計＆アーキテクチャ設計→詳細仕様設計→コード化→単体テスト→結合テスト→総合テスト＆評価というプロセスに展開します。

 プロジェクト推進チームはWaterfall型開発モデルの前工程に対して次の作業を行います。

・ プロジェクト計画立案
・ 前工程計画立案
・ 機能設計チーム→構造設計チーム（含：アーキテクチャ設計）の立上
・ 前工程の進捗状況把握
・ 後工程のチーム編成
・ 後工程チームの訓練

　プロジェクト推進チームは、顧客要求機能を実現するプロジェクト計画を立案しなければなりません。通常、プロジェクト計画は、要求機能や実現手段が確定しないまま立案することが多く、リスクの大きい仕事です。要求機能が曖昧ならば、プロジェクト計画は立てようがありません。しかし、顧客は大まかな機能要求で納期と見積費用を知りたがります。不確定要素が多い場合、プロジェクトとしては、大上段に構えて納期と費用を決定することは避けねばなりません。調査→その他の前工程→後工程などに区切りって分割契約することがリスク回避に役立ちます。前工程が終了し、機能設計と構造設計に曖昧さがなく、後工程の要員調達の見通しがあるならば、確度が高い納期と費用を提示できますが、それができなければ、幅を持たせた契約にしておくべきです。情報不足のまま走り出さないことが肝要です。

実績のある同様のプロジェクトがあるならば、そのプロジェクトの要員や生産物を活用することにより、信頼性が高いプロジェクト計画を立案することが可能となります。これは２つ目のアプローチ法です。

３つ目のアプローチ法は、カスタマイズして使える既存のシステム（含：パッケージ・ソフトウェア）があるならば、そのシステムを使用するよう顧客を説得し、プロジェクト計画を立てるやり方です。この方法により、更に信頼性の高い計画を立案することができます。

プロジェクト計画立案に先立つ調査で、上記のようなアプローチ法について顧客と合意しておく必要があります。この合意にもとづいて、プロジェクトを大づかみに捉えるスケジュールを立てます。このスケジュールはWaterfall型モデルの各プロセスの作業規模と要員＆設備調達見込みに従うプロセスの開始・終了期日を記します。更に細かいプロセス毎のスケジュールは、各プロセスの開始に先立ち別途立案します。

プロジェクト推進チームは初めにプロジェクト計画に沿って前工程の機能設計に関わる作業項目、設計担当、日程をスケジュールします。構造設計のスケジュールは機能設計が終わる前に立てますが、この時点ではプロジェクト計画のスケジュールのままにしておきます。

プロジェクト推進チームは配下に機能設計チームを編成します。このチームは戦術のレベルで述べたチームとして行動します。機能設計チームの作業が終盤にかかると、プロジェクト推進チームは構造設計に関わる作業項目、設計担当、日程をスケジュールし、構造設計チームを編成します。このチームは機能設計の終了と同時、あるいは機能設計と並行して、戦術のレベルで述べたチームとして行動を開始します。

構造設計チームが活動している間に、機能上の修正が必要になることがあります。構造設計を行ってみなければ気がつかないことがあるからです。機能設計チームと構造設計チームはプロジェクト推進チームの配下で連携して作業することが要求されます。

機能設計と構造設計の進捗状況は担当チームからプロジェクト推進チームに報告され、プロジェクト計画を満足しているならば作業を続行します。何らかの問題があるなら、プロジェクト・リーダは原因究明を指示し、対策を講じます。

前工程の終盤に、プロジェクト推進チームは後工程の体制を編成します。前工程と後工程の大きな違いは、後工程では実行チームの数が多く、プロジェクトの要員数が一挙に増えることです。そのため、機能設計書と構造設計書に誤りや曖昧さがあってはならず、十分練られたものでなければなりません。小さなミスや曖昧さが後工程で増幅されて大きなコスト要因となるからです。前工程で決定された技術や管理手法に不慣れな要員が後工程に配置される場合には、事前に後工程担当チームの錬度向上訓練を行っておく必要があります。

次図は後工程を推進する体制の例を示しています。後工程は複数チームが一体となって効率的に行動しなければならないため、この例に示すような体制が必要となります。

上図の体制運営で最も大切なことは、

・　資源の配分が適切なこと
・　プロジェクト状況が的確・迅速に把握されること

です。そのため、プロジェクトのチームおよびメンバの規律、結束、リーダの資質、リーダシップ、錬度はプロジェクト戦略のレベルでも非常に重要です。「戦術のレベルの課題」はプロジェクト戦略のレベルにも当てはまります。戦術のレベルよりも規模が大きくかつ複雑になりますので、プロジェクト・リーダのリーダシップが特に問われます。プロジェクト・リーダには、技術、チームおよびメンバの活動状況に目を配り、判断・決断・実行指示の適切さ・迅速さが求められます。そうした意味から、プロジェクト・リーダの人選は大変重要です。良くプロジェクトの成功はプロジェクト・リーダの能力に依存すると言われますが、具体的には上記のことを指しています。

プロジェクトのレベルで注意すべきことは、攻勢に出て、守勢に回らないことです。一旦負け戦になると、プロジェクトやチームの士気は一気に下がります。下降加速度がついたプロジェクトやチームを上昇加速度に変えるには、２倍以上の加速度をつける必要があります。それだけエネルギーが必要になります。従って、下降加速度になることは絶対に避けなければなりません。プロジェクト・リーダの役割は決して負け戦にならない手を打つことにあります。

失敗するITプロジェクトの多くは自滅型です。つまり、上記の体制運営がうまく機能していないために失敗するのです。これでは競争相手と“戦う”というレベルに到っていないことになります。組織が市場で競う以上、これまで述べてきた、技術のレベル、戦術のレベル、プロジェクト戦略のレベルは問われるまでもなく達成していなければならない事柄です。

（４）　経営戦略のレベル

市場で競合他社との対戦を指揮しているのは複数のプロジェクトを同時並行的に遂行させている“組織（企業、システムプロバイダー）”の指揮官、即ち経営者です。

経営戦略のレベルで最も重要な課題は経営合理性です。経営者は、市場という“場”の変化・動向、他社の動きをウォッチ（自ら現場を見て理解）し、自社の経営資源を背景に出方を決定する必要があります。市場はいろいろな要因で変化しますので、その中で、自社が最も有利となるよう行動するのです。経営者は、自社のプロジェクト戦略のレベル、戦術のレベル、技術のレベルに目配りし、自社の力（強み、弱み）を理解しておかなければなりません。新規のプロジェクト案件が現われたとき、手を出すべきか否かの判断は所与の経営資源で可能か否かを見極めることが前提となります。

自社の利益追求のために、プロジェクトに対する経営資源の配分に優先順位をつけることも経営者の課題です。大きな利益を生み出すプロジェクトに必要十分な経営資源を配分し、赤字案件からは手を引くことが必要です。また、ある特定のプロジェクトが他のプロジェクトに配分されるべき資源を横取りし、組織全体に悪影響を与えることがあります。経営者は経営資源の配分に十分配慮しなければなりません。

プロジェクトによっては、経営資源不足のため、他社と提携することもあります。昨日の敵は今日の友になるかもしれませんが、生きのびるためにはそのような選択も必要です。

資金力がある組織では、経営者はプロジェクト戦略のレベル、戦術のレベル、技術のレベルをコントロールできます。不足する資源を外部から調達することが可能だからです。しかし、資金力があっても、技術や戦術のレベル、プロジェクト戦略のレベルでの能力の限界が制約になることがあります。戦術のレベルの限界がプロジェクト戦略のレベルの制約になり、それが経営戦略のレベルの制約になります。経営者はこうした能力の限界と資金力を見極めながら、経営戦略を考える必要があります。

経営者は各戦略のレベルの能力の限界を上げるために、各戦略のレベルを背後から支援する必要があります。経営者の理解なくして、各戦略のレベルの能力向上は期待できないからです。■