ITプロジェクト戦略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１） T、T1、T2、・・・はチームの略。　　例：　「品質管理チーム」　→　「品質管理T」

２）詳細設計Tiとコード化Tiは、開発期間中はペアで活動。複数のペア：T1、T2、T3、・・・、Tnを配置。チーム数は、システム規模、ジョブの開発工数（詳細設計＋コード化工数：人日）、確保要員数に依存する。期間内に収まるよう要員確保は確実に。詳細設計Tiとコード化Tiの能力・作業は下記の通り。

　

詳細設計Ti　： ①　業務および機能／構造設計に精通。

②　機能／構造設計を元に該当ジョブ１ロットの詳細設計を行う。

③　詳細設計書をコード化チームに解説。

④　詳細設計完了後、直ちに該当ジョブ１ロットの単体テスト仕様を立案。

⑤　コード化Tiが仕上げた該当ジョブ１ロットのプログラムについてコード化Tiと一緒にレビュー。

⑥　障害について、製造Tiと一緒に解決。

⑦　進捗状況をプロジェクト推進Tに報告。指示を受ける。

　

コード化Ti　： ①　開発技術に精通。

②　機能／構造設計を学習。

③　詳細設計Tiが仕上げた詳細設計を解読。

④　詳細設計を元にプログラムを作成。

⑤　該当ジョブ１ロットのプログラムについて詳細設計Tiと一緒にレビューを行う。

⑥　詳細設計Tiが仕上げた単体テスト仕様を元に単体テストを実施。

⑦　障害について、詳細設計Tiと一緒に解決する。

⑧　進捗状況をプロジェクト推進Tに報告。指示を受ける。

※T1、T2、T3、・・・の順はテスト順に従って決めるのが合理的。例：最初のジョブは異常系、入力系、後のジョブは参照系、出力系、・・・。ビジネスフロー及び処理系から見極める必要がある。

３）システム統合Tは、Tiから仕上がってきたロットを結合テスト環境に、結合テスト対象としてビルドする。ビルド毎にV/R番号を付与。ビルドのスピードがネックにならないようにしておく必要がある。結合テストのサイクルとビルドのサイクルが合うのが望ましい。

４）結合テストTは、システム統合Tが用意したビルド毎にテストを実施。最初からすべてのジョブが揃わなく、当初は最小ジョブロットのテストからはじめ、全ジョブロットが揃ったところで全体の結合テストを行う。
　・　結合テストのテスト仕様のメイン部分は結合テストTが起こすが、プログラム依存部はTiが起こす。
　・　結合テストで検出した障害は直ちに障害処理票を発行し、品質管理Tに渡す。
　・　結合テストは開発機で行えるあらゆるテストを実施する。

５）品質管理Tは、結合テストTおよび総合テストTから発行された障害処理票/問題・課題処理票を記録し、問題傾向分析を行い、出荷に向けての見通しを見極め、全員に報告、対策を指示する。

６）受入テストは、社内の結合テスト中のビルドを本番機に移行し、顧客による仕様、使い勝手、性能、等の確認作業。目的は、①最終製品が顧客要求を満たしているかをなるべく早期に確認すること、②システムの完成度を肌で感じてもらうこと、である。受入テストで検出した障害等は、障害処理票/問題・課題処理票を発行し、品質管理Tに渡す。

７）総合テストは、顧客を巻き込んだテスト。目的は、①結合テストと同等のテストを実環境で行うこと、②本番機でなければ行えないテストを実施すること、である。総合テストで検出した障害は直ちに障害処理票を発行し、品質管理Tに渡す。

８）プロジェクト推進Tは、他のすべてのTの進捗状況を把握し、プロジェクト計画が達成できるか追跡する。手段としてT、T1、T2、T3、・・・のリーダからなる進捗会議を開催する。初めは週１、2回、状況が切迫してくれば朝夕の2回行い、納期達成に向けてプロジェクトをコントロールする。
プロジェクトの予算管理もこのTの役割。追加機能、不良品質、進捗遅れなどのプロジェクト状況をウォッチし、出来るだけ早期に対策を講じることが予算オーバを防止する。

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

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

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

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

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

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

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

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

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