2004年2月，日経システム構築（現 日経SYSTEMS）誌上で「深層ルポ なぜ繰り返すのか 失敗プロジェクト」という連載を始めた。当時は石を投げれば失敗プロジェクトに当たるといった状況で，幸か不幸か取材先に事欠かなかった。この連載は1年続き，書籍「さらば！失敗プロジェクト」として出版された。

　今，同じ雑誌の2008年1月号で「うまくいくプロジェクト基盤（仮）」という特集記事を掲載すべく，その取材を進めている。4年前と比べると，プロジェクト推進を巡る環境は様変わりしたという印象を受ける。

・ユーザー企業の担当者と合意して開発したシステムなのに，その企業の検収の段階で役員から話が違うとひっくり返される。
・メーリング・リストに埋もれた議事録を探したが見つからず，知っていそうな人に電話で聞いて開発したが，議事録に書かれていたものとは違っていた。
・ユーザーとベンダーとで基本設計の定義がまるで違うものだったことに基本設計フェーズの成果物を見て気づく。

　4年前は当たり前だったこんな話が，今は当たり前ではない。多くの失敗を教訓に「意思決定の手順」「情報管理の方法」「プロセス/成果物」といったプロジェクトの基盤の整備が進んでいるからである。現場に浸透するにはまだタイムラグがあるだろうが，浸透させるべき基盤は用意されつつあるようだ。

　3K職場，デスマーチと言われ，いつ自分がその当事者になってもおかしくないのがIT業界だった。多くの場合，その根本原因は「決めてくれる人がいない」「何を決めたのか分からなくなる」「標準的なやり方がないため自己流でやっている」といった極めてプリミティブなものである。

　そういう状況はそう遠くない将来に変わっていくだろうと，私は見ている。もちろん，失敗プロジェクトや悲惨な現場は残るだろうが，極論すればそれは運の悪い一部の現場の話となっていくに違いない。

　メインフレームの時代に一度成熟し，クライアント・サーバー（C/S），Webシステムと変わる中で混乱を極めたITの現場は，再び成熟しつつある。その兆候がプロジェクト推進に見て取れるのである。逆に，現時点でそのような兆候を全く感じ取れない現場は，淘汰されていくのではないだろうか。

　では，プロジェクト推進が楽になるのかと言えば，事はそう簡単ではないようだ。現場のプロジェクト・マネージャ（PM）やプロジェクト・マネジメント・オフィス（PMO）への取材を重ねると，現場の悩みの質が変容していることが分かる。「情報漏洩」と「偽装請負」にその一端を垣間見ることができる。

情報漏洩：キックオフするのも一苦労

　システム開発プロジェクトには複数の会社がかかわるのが普通だ。SIベンダーや製品メーカー，協力会社などである。EDI（電子データ交換）のようなシステムであれば，ユーザー企業の取引先も加わる。それぞれの立場によって，プロジェクトの間，アクセスできるデータは同じではない。

　「情報漏洩を防ぐという観点から，誰もが本番データにアクセスできる状況は望ましくない。限られた一部のメンバーしかデータに触らせないなどアクセス権のルールを決めておく必要がある」（大手SIベンダーのPMO）。

　開発ルームを用意するのも面倒になった。

　「昔は，スペースに電源と端末があればプロジェクトをキックオフできた。90年代後半からはインターネットや社内システムへの接続などネットワークを敷設する必要が出てきた。今はそこにアクセス権をルール通りに設定した上でないと，キックオフできない」（大手SIベンダーのPMO）。

　アクセス権の設定は，開発するシステムのデータだけではない。メールやグループウエア，ファイル・サーバーもその対象だ。

　「客先に常駐する場合は，客先のセキュリティ・ポリシーに従う必要がある。開発ルームから自社のメールやグループウエアにアクセスできないこともある」（情報システム子会社のPMO）。そうなると，社内の情報共有・流通に別の仕組みを考えなければならない。

　開発用の端末にも準備が必要だ。Winnyがインストールされたパソコン，パッチやアンチウイルス・ソフトがアップデートされていないパソコンは開発ルームのLANに接続させられない。しかし，協力会社を含め，それを確実に守らせるためには，プロジェクト用にセットアップしたパソコンを支給するなり，検疫ネットワークを構築するなり，手間とコストがかかる。

　金融機関の情報システムなどセキュリティ要件が厳しい案件であれば，入退室の管理も必要だ。ICカードによる制限などを考えることになる。「このような段取りは，総務部などバックオフィスが手配するが，その手配や要件をまとめるのはPMを初めとするプロジェクトのメンバー」（大手SIベンダーのPMO）である。

　ラインの活動であれば，このようなことは1回準備しておけば，次からは準備する必要はない。しかし，プロジェクトは，始まりと終わりがある一過性の活動である。1回ごとに要件を洗い出し，準備しなければならない。これではキックオフするのも一苦労である。

偽装請負：お願いもできない

　偽装請負とは，契約上は「請負」なのに，実態として「派遣」になっていることを言う。発注者側の現場担当者が，受注者側の現場担当者に直接指示を出す，といった行為がそれに当たる。昨年，厚生労働省が「偽装請負に対する当面の取組について」というドキュメントを公表し，監督指導の強化を打ち出した。システム開発の現場は，その対策に追われるようになった。

　「今まで意識していなかったので，何が善くて何が悪いのかを洗い出すのが，まず大変だ」。あるSIベンダーの企画担当者はこう吐露した。実態を洗い出すのが大変な上，その対策を講じようとすれば，それは現場のコミュニケーションを難しくすることにつながる。

　「現場では，メンバー同士でちょっとしたことを聞いたり，作業をお願いしたりすることは普通にある。請負契約だと，そのちょっとしたことも偽装請負だと疑われる恐れがある」（大手SIベンダーのベテランPM）。

　それに対して「請負先とのやり取りは部門長を通し，会社として行う」といったルールを作って対処することは簡単だ。ただ，そのルールを厳密に守ろうとすれば，開発の現場は非効率になる。その非効率を埋める仕組みを別に考えなければならない。

　開発ルームの配置にも工夫がいる。あるベンダーでは「請負契約で協力会社に発注する場合は，こちらのオフィスに常駐してもらうのではなく協力会社のオフィスで開発してもらうことを基本としている。常駐してもらわざるを得ない場合も，机をパーティションで区切ったり，別の島に席を分けたりする」という。偽装請負を疑われないように，コミュニケーションの壁をわざわざ作るのである。コミュニケーションの風通しをいかによくするかという方向で頑張ってきた開発現場とすれば，まるで正反対の対処を迫られるわけである。

　もっとも，順法の観点からも社会的責任においても，これらはやって当たり前のことばかりだ。ただ，成長と変化の中で何となく見過ごされてきた。これまでは「QCD（品質，コスト，納期）を守る」ことをプロジェクト推進の至上命題として掲げていればよかった。今は「法律と社会的責任を守った上で，QCDを守る」ことが至上命題となる。この当たり前のことを当たり前のようにこなせるかどうかが，本当の意味でのIT業界の成熟を問うことになるだろう。