SI業界の今後と技術者のキャリアを真剣に考える①デスマーチな業界が変わるには?

Home » コラム » SI業界の今後と技術者のキャリアを真剣に考える①デスマーチな業界が変わるには?
最近、IT業界で注目のニュースと言えば、スマートデバイス、ビッグデータ、クラウド、HTML5などに関することが多いですね。少しマイナーなテーマですが、DevOpsも注目されています。

ひと昔前は、ホットな話題と言えば仮想化やオフショア化でしたが、短い間に大きく様変わりしたものです。

IT業界ではバズワードや新しい流行が目まぐるしく生まれては消えてを繰り返していますが、最近の大きな潮流としては、ITがコスト削減の手段からビジネスで活用する武器に変わってきていると言われています。特にWEB界隈では、ICTがビジネスの中核そのものになって久しいです。

 

IT業界の華々しい話題とは裏腹に…
ICTのビジネス活用という潮流は、エンタープライズアプリケーションの領域にも流れ込んできており、Hadoop等のOSS活用や、AWS等のクラウド活用の成功事例の話を見聞きすることが増えてきました。

ただ、そのような華々しい話題とは反対に、SIの現場ではデスマーチの話も、華々しい話と同じくらいによく耳にします。

 

SIの現場では、未だにこんな声が聞こえてきます(≒イメージです)。
「はあ、この仕事辞めたい。企業の社内システムの開発はもう嫌だ。ここじゃ枯れ切った技術しか触れないし、プロジェクトマネージャはコーディングできない上に、あいつが連れて来る新メンバーは全然使えない。仕方ないから今日も終電過ぎまで自分でやるけど、、、、こんな仕事いつまで。。。」

・・・残念なことですが、珍しい話ではないですね。
と、達観していても何も良くなりません。国民が政治に無関心のままでは政治が変わらないのと同じように(?)、開発者が変わろうとしなければ開発の世界は変わらない、ということで、ここはひとつ、みんなの力で変えていきましょう。(まずは変わることを信じることから)

ではなぜ、SI業界ではこのような悲しい現実(≒デスマーチ)があふれているのでしょうか。
その克服方法とは何か。
さらには、SI業界で働く技術者に、今後何が求められるのか。
これらを真剣に考えたいと思います。

 

デスマーチが始まる原因とは… 
まず、なぜデスマーチが起こるのか、ですが、
これは色々な人がWEBで解説していますが、改めて考察します。
 ①伝統的な開発手法と一括請負契約の問題
 ②多重下請け構造の問題
 ③「プログラマーは地位の低い職種」とみなしたキャリアパスの問題

これらが主な原因だと考えられます。ひとつずつ見ていきましょう。

 

①伝統的な開発手法と一括請負契約の問題
日本のシステム開発は、開発フィーを作業工数と単価の掛け合わせで決めることが多いですが、ユーザ企業と開発べンダの間で、一括で請負い契約を結ぼうとするリスクオンなマインドが、時に大きな問題を引き起こします。
一括請負契約は、開発ベンダーがリスクを取ってくれるので、ユーザ企業にとってはありがたい契約形式に見えますが、実はそうとも限りません。開発ベンダーはリスクを受け持っていますが、それは開発コストに関するリスクで、システム品質に関するリスクはユーザ企業が負っています。このことを、架空のケースで見ていきましょう。

 

ある開発ベンダーAが、要件定義が完了した時点で作業工数を見積もり、ユーザ企業Bとシステム開発契約を締結しました。開発ベンダーAは、基本設計からシステムリリースまでの全工数を見積もり、ユーザ企業と請負契約を締結しました。(請負契約の詳細はWEBで検索して調べてください)

その後、実装工程を経て、テスト工程になってから、設計の考慮漏れが大量にあったことが判明しました。
開発ベンダーAは、「この仕様変更の対応を実施するのであれば、追加で費用を請求させて頂きたい」とユーザ企業Bに伝えますが、要件定義書や基本設計書には、それらの仕様についてどちらとも取れる曖昧な記載しかありませんでした。開発ベンダーAは「要件定義書や基本設計書はユーザ企業Bの担当者にもレビューしてもらってOKをもらった」と主張しましたが、ユーザ企業Bは「設計書の記載では曖昧で判断できず、常識的に考えれば、今の仕様が間違っていることは明らかだ」と主張し、開発ベンダーAはユーザ企業Bとの関係悪化を懸念して、追加費用を請求せずに対応することにしました。(このような習慣が根付いていると、開発ベンダーがユーザ企業にそもそも追加費用を請求しようとしないこともあります)


開発ベンダーAのプロジェクトマネージャは、追加のフィーをもらわずに現場で何とかするようにメンバーに指示を出しましたが、現場では何ともなりません。
かくして、デスマーチが始まりました。デスマーチが始まると、開発チームのメンバーがいかに頑張っても解決できない事態に陥ることもあります。こうして、ユーザ企業Bがシステム品質の問題を抱えることになるのです。最悪の事態としては、システムをリリースできなくなり、訴訟沙汰になることもあります。「システム 訴訟」でWEB検索すると、そのような事例は沢山出てきます。
こうして見ていくと、一括請負契約といえど、ユーザ企業がシステム品質リスクを受け持っていることがわかります。

現在では、これらのリスクを軽減するための開発手法が普及してきています。
・PoC(Proof of Concept)で初期検証を行い、企画段階で開発リスクを減らす。
・要件定義~UATはスクラム的な方法(反復的かつ漸進的な開発手法)を用いてリスクを減らす。
 大規模開発の場合は、アジャイルの考え方をそのまま導入することは難しいですが、
 フェーズを分けてリリースする等の方式でリスクを軽減します。
・契約を短期間(1~3か月程度)にすることでリスクを減らす。(素早い計画の見直しを可能にする)

これらを適用し、開発手法や契約形式に起因するリスクを減らすことができます。
(そう簡単に適用できないよ、という話もありますが…)
これに加えて、人のスキル不足に起因するQCDのリスクを軽減することも重要ですが、これについては後述します。


②多重下請け構造の問題
ITゼネコンという言葉がありますが、まず一次受けの開発ベンダーがシステム開発案件を受注し、二次受けの会社がその一部を1次受けよりも安い単価で受注し、さらにその下請けの会社がその一部をもっと安い単価で受注するというのが当たり前なのが、日本のSI業界です。
この構造の問題を簡単に言うと、技術者の役割が細分化されすぎて、それぞれの技術者が交代可能なパーツになり下がってしまうことです。本来、クリエイティブな技術者のはずだったのに…
ユーザから見ると、ほとんどの技術者は存在を感じられないロボットか単純作業者のように見えるのではないでしょうか。ユーザーからは見えてすらいないという方が正しいのかもしれません。
このことは、次なる問題を生みます。

 

③「プログラマーは地位の低い職種」とみなしたキャリアパスの問題
私が20代の頃にはこのようなキャリアパスの絵をよく見ました。
キャリアパス若き日の中途半端なコーディング力の私は、このような絵を見る度にプロジェクトマネージャかITコンサルタントになりたいと思っていました。
それから10数年が経ち、相変わらずコーディング力は中途半端なままですが、ありがたいことにプロジェクトマネジメントとITコンサルティングを生業にして飯を食べていけるようになりました。
そんな私の話はさておいて、もとに戻ります。

かなり強引な例えですが、技術者のキャリアパスを日本のプロ野球に例えると、このように表現できます。
 ・プログラマー = プロ野球選手
 ・SE = コーチ (選手の次のキャリア)
 ・プロジェクトマネージャ = 監督
 ・ITコンサルタント = プロリーグ以外の野球指導者
 ・スペシャリスト = 助っ人外国人選手

 

この例えでは、プロ野球選手(=プログラマー)は、引退してコーチ(=SE)になるか、助っ人外国人選手(=スペシャリスト)になることができます。

プロ野球の選手がコーチより稼げないという賃金の序列はないですが、
日本のプログラマーはSEより賃金が低いような・・・

 プログラマーの地位が低いのは、
プログラミングを単純な作業に近いものと位置づけてしまっているからでしょう・・・


設計とプログラミングの間に境界線を引き、設計はSEのタスク、プログラミングはプログラマーのタスクという切り分けをしてしまっているのです。不自然な切り分け方なのは明らかですが、歴史的な多重下請け構造に合わせて出来たキャリアパスなので、ひっくり返すことは容易ではないです。
しかし、細分化されて単純労働者に近い扱いを受けるプログラマーは、ユーザが魅力的に感じる技術者に育つことができないまま、それでも月日は流れ続けていくのです。こうして、IT部門はユーザーが必要とするタレントを十分に備えることができないまま、ダメな組織としての烙印を押されて・・・ ただただ、変えなければと思います。

ではプログラマーの地位向上は、どのようにして実現するのでしょうか。
次回に続きます。