PR

 顧客企業のIT化を直接手がける直ビジネスでは,要求定義の能力が不可欠です。下請けと直ビジネスとの最大の差は,この要求定義ができるかどうかです。開発力やプロジェクト管理能力はそんなに大きな差はありませんし,技術的なことは訓練できます。

 要件定義は,ビジネスの話ができなくてはなりません。対象は偶有性(予測不可能)に富み,曖昧な人間です。要件を主導し,うまく効果が出なかったら,ユーザーから何を言われるか分かりません。そんな難度とリスクの高さから,ITベンダーの多くは要求定義を,「要件を言って下さい,作ります」という腰が引けた御用聞きスタイルにしてしまいました。
 
 我々黎明期(1970年ごろ)のSEにとって,システム要件をキッチリ言ってくれるお客などいませんでした。お客の業務を聞いて,SE主導でシステム設計を提案し,「運用性や実現可能性はどうか?」を議論しました。そもそも“要件”なんて言葉が,その当時にあったのかどうか。

 当時のシステム化は,既存業務の自動化や省力化が狙いでした。ですから,現状の業務を理解していればSEでもイニシアティブを取れたのだ,とも言えます。

 ただし,コンピュータの導入によって,慣れ親しんだ業務プロセスは大きく変わることになります。その上,省力化狙いで人数も減らされますから,現場ユーザーからの抵抗は少なくありませんでした。当時,まだまだ若造だった私が,ユーザー部門の担当役員と大議論したこともあります。そして,抵抗しているユーザーに「システム化して楽になった」と言ってもらおうと,必死で頑張った記憶があります。そんなSEが黎明期には多かった。どうして変わってしまったのでしょうか?

 ローリスク・ローリタンな下請けに甘んじることと引き換えにITベンダーが失ったのは,要求定義を始めとする開発上流のスキルです。確かに開発上流はリスクが大きく,人月のうまみもありません。下流のインプリメント工程には大量のSEやプログラマが必要です。結果としてITサービス産業は,人月という量が規定する,労働集約的産業になってしまいました。IT企業の規模の拡大は,要員の採用や調達動員力に依存するようになったのです。量の拡大は質の低下を招きました。

 日本の産業は,大企業を頂点とし多数の下請けが産業の裾野を構成するピラミッド構造です。IT産業もその日本独特な産業構造を踏襲しました。踏襲と言うより,ウォータフォール型開発がピラミッド構造の中にピッタリ収まってしまったのです。ひと握りのプライム・コントラクタの下請け,孫請け,ひ孫請け....という多段階下請構造ができたのです。これはこれで,プライム・コントラクタにとっても,下請け・孫請けとっても,さらにユ−ザーにとっても補完関係のある柔軟な構造だったのです。

 しかしながら,IT産業は,参入のしやすさやオフショア開発で揺らいでいます。人月単価の低落傾向は止まりません。ベストセラーになったビジネス書「ブルー・オーシャン戦略 競争のない世界を創造する」の表現に従えば,IT産業は「既存市場内で血みどろの争いを展開する赤い海」となっているのです。