ITプロジェクト管理考の前書きで、日本のソフトウェア企業のITプロジェクト管理力が育たないのは何故かを問い、その後思いつくままに書き綴ってきましたが、前稿：ソフトウェア事業と共同体を書き終えたとき、ソフトウェア産業構造に疑いを持つようになりました。ITプロジェクト管理力をつけ、活かすには下地ができていなければならないのではないか。下地とはITユーザ企業やソフトウェア企業経営者のITプロジェクト管理に対する認識や取組み、産業界の活動、法制度などを指しています。残念ながらこれまでのところ下地ができていないということです。IT（情報技術）は社会や企業、個人の生き方を支援する強力な手段です。これを生かすも殺すも使い方次第です。ITプロジェクト管理はITシステムの構築・維持（保守、更改）を合理的に行う手法であり、これを旨く使いこなすには下地がなければならないということです。

以下では、ITプロジェクト管理力を使いこなす“下地”について述べ、ITプロジェクト管理力がつかない状態から脱却するにはどうすれば良いかを考えます。

（１）　ITユーザ企業経営者の認識

ITシステムを発注するユーザ企業経営者の多くは、ITプロジェクト管理は発注先のソフトウェア企業が行うものと考えているようです。しかし、それは違います。

現在、プロジェクト管理を必要としているのは誰なのか。その人はプロジェクト管理の必要性を自覚し、戦略的に活動しているのか、・・・等々と考えて行くと、日本では、ITプロジェクト管理について正しく理解されていないように思います。銀行や証券取引、自動改札機などのシステム障害は、念入りにチェックして導入したはずではないのか、それにもかかわらず、何故障害が発生してしまうのか。障害を修復した後で責任者もしくは広報関係者から説明される原因は実にあっけらかんとしています。先ず、お騒がせしましたとお詫びの言葉が述べられ、TVカメラの前で頭を下げます。続いて二度とこのような障害を発生させませんと平然と言ってのけます。正直なところ自信はないのだが、その場ではそう言わざるを得ないのでしょう。謝罪した経営者やトップ管理者は社内に戻って、現場責任者や発注先ソフトウェア企業に何とかしろ！とプレッシャーをかけていることでしょう。自分が解決策をもたないのにです。障害が復旧してしばらくすると、「あのときの原因は、不具合の修正時に別の不具合を作りこんでしまった」、「あれは特別な状況で発生する障害でした」などという説明がなされます。世の中の一般の人達を安心させようとするために。彼らの釈明の中に管理レベルの話が全く登場しません。末端の技術者のミスが大事故につながったと言わんばかりです。ITプロジェクト管理を理解していない経営者やトップ管理者にとって、その一時がしのげたら万事OKなのです。末端の技術者がなぜミスを作り込んでしまったのか、組織に問題はないのかということに気が回らないのです。実はそこに真の原因があります。システム開発の殆どはプロジェクトで行いますので、直接には個人のミスであっても最終製品のミスは個人のミスではありません。プロジェクト（責任者）のミスと言うことになります。プロジェクトのミスは組織（責任者、つまり経営者）のミスです。ですから、最終製品にミスがないようにする責任は経営者にあります。異質な、様々な能力の技術者を集めてプロジェクトで仕事をするのですから、プロジェクトの生産性を求め、質の高い仕事を行えるようにする組織作りはユーザ企業の経営者やトップ管理者の役割です。

ITシステムは企業にとって戦略的な手段です。そのITシステムの開発を全面的に発注先のソフトウェア企業に任せて安心できるわけがありません。ユーザ企業はIT（情報技術）そのものについては素人であっても、本業については専門家です。本業のITシステム化に必要な機能はチェックできます。ITシステム開発を行うソフトウェア企業をコントロールするために、背景知識やノウハウが必要ならばコンサルティング企業を使えば良いのです。適切なコンサルティング企業がなければ、その目的を達成する組織を作る必要があります。小規模システムの開発ではソフトウェア企業に任せておいて問題はないでしょうが、大規模システムの開発ではそうは行きません。自社とソフトウェア企業との間に、自社の立場に立ってソフトウェア企業をコントロールする組織が必要です。このようなコンサルティング企業や自社内組織は、ユーザ企業の本来業務と、IT（情報技術）およびITプロジェクト管理に精通していなければなりません。このような慣習が日本では定着していません。ユーザ企業にはこのようなコンサルティング企業もしくは組織を是非育ててもらいたいものです。このような体制はITプロジェクト管理力を根付かせる重要な下地の一つです。

補足：ソフトウェアシステムの開発をビル建築に喩えるのは間違いです。ソフトウェアシステムはユーザ企業の業務そのものに深く関わっており、仕組みも非常に複雑です。このようなシステムの構築を、生活空間を満たすビル建築と同様に考え、業者に発注したら、後は業者任せにすることが許されないのは至極当然のことです。

（２）　ソフトウェア企業経営者の認識

ある経済誌の大手ソフトウェア企業トップへのインタビュー記事で「業界にはATMなど大型システムの不具合や不正取引事件の頻発、多重下請けの慣習など多方面の問題が目につく。業界は健全なのか、懐疑的な声が少なくありません」という質問に答えて、「ａ）問題の背景にある仕事のやり方が前近代的で、モジュール化や技術の標準化が進んでいない。ｂ）日本のシステム自体は信頼性も品質も高い、ある国では『このATMは壊れていることがあります』と表示される、システムに対する寛容度が海外と違う。ｃ）お客様の要求が高かったから、技術的に１ケタ上のシステムができた、これからは職人的な品質の高さを損なわずに開発工程を近代化することが大事です」と述べています。認識に甘さとずれがあります。解決の意思が語られていません。また、問題解決の手段があくまでも技術にあると考えている節があります。前稿：ITプロジェクト戦略を読んで頂くと分かるように、ソフトウェア開発はそれ程単純なものではないのです。また、多重下請けの慣習はメリットもデメリットもある問題ですが、答えていません。この経営トップの認識は日本の他の大手ソフトウェア企業のトップの認識と大差はないと思います。このレベルではやはりダメです。

ソフトウェア企業によっては、顧客の業務に精通した人材を用意し、IT（情報技術）やITプロジェクト管理力よりも重視する経営者もいるようです。ソフトウェア企業の人材はIT（情報技術）とITプロジェクト管理についてしっかりとした能力を磨いておくことが重要であり、その上で顧客の業務に精通する必要があります。顧客業務にだけ精通し、それ以外は下請けのソフトウェア企業に任せておけば良いというような考えは厳に戒めなければなりません。

また、ソフトウェア企業の経営者の中には、IT（情報技術）とITプロジェクト管理の重要性についてあまり理解していない人もいます。ソフトウェア企業の市場価値はIT（情報技術）とITプロジェクト管理にあるのです。

ISO9000やCMMIレベル何がしかの認証を得て、会社の看板にしているソフトウェア企業は大分増えているようです。こうした認証を受けていると商売がやり易いのでしょうが、そうした認証を取得している企業がITプロジェクト管理を問題なくこなしているかというとそうでもありません。認証を取得している企業はそれなりのレベルにあることを示していることは確かです。しかし、個々のITプロジェクトが問題なく実施できるかどうかは別の問題です。認証取得は静的なものであり、ITプロジェクト管理は動的なものだからです。動的なものを静的なもので保証することはできません。このことについて誤解している経営者が多いように思います。

ソフトウェア企業にとって必要なのはどのようなITプロジェクトであっても、常に問題なくこなす力量です。個別のITプロジェクトについて、プロジェクト進捗の段階に応じて適切な状況にあるか計測し、改善点があれば改善し、どんなITプロジェクトでも目標を満足させる組織体制になっていることが必要です。このことについては前稿：ITプロジェクト戦略やITプロジェクトにおける知識継承を参照してください。企業内のITプロジェクト管理に関する知識やノウハウを蓄積し、関係者と共有し、維持発展させる考え方について述べています。ソフトウェア企業の経営者はこうした下地作りに務めることが必要です。

（３）　多重下請け慣習

上記（２）の記者のインタビューにあるIT業界の多重下請けの慣習がどのようにして始まったかという議論はいろいろあるようですが、汎用コンピュータが普及し始めた頃に根ざしていると思います。汎用コンピュータの開発には多大な資金を必要とし、そこそこの規模の企業では全く手が出せない領域でした。大手総合電機メーカや通信機メーカが将来性に期待して投資を続けたのです。一旦手を出したが、利益度外視の投資に競争から降りた大企業が３社あります（早くから見切りをつけた家電メーカを入れると４社）。IBM対日本という戦いにも見えました。汎用コンピュータのユーザは大手企業ばかりで、数100億円の商談さえありました。このようなシステム開発には数百人の開発要員が必要で、顧客側にも数十人から100人以上のシステム部門があり、メーカと顧客は一緒になってシステムの開発に邁進したのです。これだけ大きな案件がゴロゴロしていましたから、人集めは大変でした。コンピュータの知識が全くない新卒の社員を自社のみならず、下請け企業から派遣してもらい、基礎から教え育て上げ、開発に投入する状況でした。メーカの配下に入り、人さえ集めれば商売になるので、このタイプのソフトウェア企業が沢山生まれました。メーカは苦労して構築した下請け構造を簡単に壊す訳にはいきません。下請け企業を集めて共栄会なるものを作り、共存共栄を図ろうとしました。メーカに取引口座を持たないソフトウェア企業は下請けの下請けになり、長期安定の仕組みができたのです。このようにして多重下請けの慣習が完成したという訳です。

ところが、メインフレームから標準化（オープンソースや共通MPU）への移行が始まると、この多重下請けのあり様に変化が現れました。大きな変化はハードウェア、ソフトウェア共に価格が大幅に下がり、かつてなら数億円もした案件が数千万円になり、標準化技術は中国やインドなど労賃の安い国でも利用でき、末端の下請け企業はその煽りを受けて価格競争に巻き込まれ、単金が安く設定されるようになりました。ソフトウェア開発においては上流工程でなければ高い付加価値が見込めなくなったのです（だからと言って詳細設計やコード化、テストという仕事の価値が下がったわけではありません）。長い間メーカの下請けとして仕事をしてきた企業がこの変化に対応できる力をつけてこなかったことに問題があります。メーカ側も新領域の開拓で下請け企業を育てなかった責任は重いと言えます。しかし、経済の変化とはそうしたものです。それまでの価値はメーカ主導の独占（市場、技術、情報など）による価値だったのですが、標準化により独占が崩れ、価値が下がったのですから、付加価値の高い領域へ仕事をシフトしなければならなかったのです。

今では多重下請けの慣習を生み出した要因は存在しません。しかし、資金力と信用力がある大手ソフトウェア企業が受注し、その配下に中小のソフトウェア企業が群がる形で、メインフレーマ以外のプレイヤーも加わり、この慣習は続いています。

先に、ITプロジェクト管理力がつくには下地がなければならないと述べましたが、特にソフトウェア企業の経営者の認識が重要で、多重下請けの慣習はその認識を弱める働きをしています。

大手ソフトウェア企業側から見ると、長年に亘り実質的な開発業務は下請け企業に依存してきたため、管理職レベルにプロジェクトを引っ張るだけの人材が育たなかった。その結果、複数の下請け企業から構成される少し大きめのITプロジェクトは失敗しやすくなっています。

下請けソフトウェア企業側から見ると、ITプロジェクト管理の責任はあくまでも発注側にありますので、限られた範囲の開発業務については責任を負うが、ITプロジェクト全体について考える習慣がありません。

本来なら、一まとまりで成長して行かなければならないソフトウェア企業群が多重下請け慣習の下で、ブツブツに分断され、共存共栄の道を選択できなかったのです。

概ねこのレベルで、はらはらどきどきのITプロジェクト管理が日々進行しているというのが今日の状況ではないでしょうか。多重下請け慣習がもたらした負の部分です。

この状況から抜け出す一つの手段は、せっかく築き上げた信頼関係を一歩進めて、共存共栄の体制を再構築することです。ITプロジェクト管理ノウハウの共有・発展・維持、共同の人材育成、発展を図る各種研究会の実施、などいろいろなやり方があります。経営者に意思があるかどうかの問題です。

大手ソフトウェア企業にその意思がないならば、多重下請け配下の企業が団結して同業者事業組合（法人）を作り、大手と対等な力をつけることです（前稿：ソフトウェア事業と共同体　参照）。

（４）　法制度および企業内監査体制

前稿：日経新聞記事「システム開発の手順統一」を読んで　において少し触れておきましたが、ITシステムの構築に関して法による規制が全くありません。「重要インフラ等システムに相当するもの或いは広く経済的、社会的影響を与えるシステム」の開発に関しては、必要な組織の設置、作業プロセスや基準書の作成および所轄官庁の監査を義務付けても良いと考えられます。この内、監査は大変重要です。重要インフラ等システムと判断する基準はもちろん必要ですが、この基準に該当するITシステムの開発には所定のプロセスと、各プロセスの開始前と後で、ITプロジェクトが所定の基準を満たしているかどうかを監査するのです。所轄官庁が直接監査するのでなく、ITシステム監査法人に委託するだけでも効果はあります。ITプロジェクトが監査対象になるということだけで、ITプロジェクト管理に緊張が生じ、ITユーザ企業、ソフトウェア企業の経営者やプロジェクト管理者の意識は今までとは全く異なったものになるはずです。「情報システムの信頼性向上に関するガイドライン」に準拠したシステム監査を法の下で施行するだけで日本のITプロジェクト管理のレベルは大きく上がると考えられます。

国家的な制度に移行する過程として、大手ソフトウェア企業内に監査部を設置し、ITプロジェクトが社内の基準に従って実施されているかをチェックする体制を作ることにもある程度の効果が期待できます。しかし、法に裏付けられた体制でなければ、プロジェクト実行部隊の力に負けて形骸化してしまう恐れがあります。

（５）　ITプロジェクト管理の暗黙知と形式知の活用組織

前稿：ITプロジェクト管理の暗黙知と形式知（１）、（２）、（３）、およびITプロジェクトにおける知識継承で既に述べましたが、企業内にITプロジェクト管理知識を蓄積・伝承し、発展させる組織が必要です。いつまでも、優秀な技術者個人に全てを委ねるやり方では日本のソフトウェア企業のITプロジェクト管理力は向上しません。

企業内だけでなく、国内の企業・団体が協力して、全体のレベルを向上させるには、IPAなどの団体や学会との連携も必要です。国を挙げた取組みが必要になっています。　■