ウォーターフォールと多重請負の構造問題(3)

2018年8月10日金曜日

システム開発 システム業界問題

t f B! P L

なぜウォーターフォールで作るのか

(アジャイルの普及しない理由)


 ウォーターフォールは最初にシステムの要件を全て明確にして、システムの仕様を決めて、決められた仕様に忠実に従いシステムを開発する開発手法です。
 Sier業界ではほぼどこへ行ってもウォーターフォール開発を行っています。
 海外では近年ウォーターフォール開発はほぼ絶滅しており採用されることは無くなっているそうです。大半のシステム開発はアジャイルかプロトタイプ開発で行われるようです。
 なぜアジャイル開発のような柔軟性の高い開発手法を採用しないのでしょうか?

ウォーターフォールの利点と欠点


 [ウォーターフォール]
  前工程) 要件定義→設計→開発→テスト→納品→導入 (後工程

 ウォーターフォールの利点は以下のものになると思います。
・価格と納期を開発前に知ることができる。
・計画が単純で(IT素人には)わかりやすい(ように見える)。
・進捗が(IT素人には)わかりやすい(ように見える)。
・開発終了後、保守コストだけで運用できる。
・請負契約で発注できるので瑕疵担保責任をITベンダーに要求できる。

 欠点は以下になると思います。
・最初に要件を明確に定義しなければならない。
・最初に定義した要件を途中で変更してはならない。
・途中で要件を追加してはならない。
・計画の変更が非常にやり難い。
・無理に仕様変更や計画変更を行うと非常にコストが高くなる。

 ウォーターフォールというのはその開発手法から考えて仕様変更が出来ません。多くのSIerが多少の仕様変更を認めているので発注元企業の中には「仕様変更できるのが当たり前」と誤解している人も多いですが、本来ウォーターフォールは仕様変更できないものなのです。SIerが仕様変更を受け付けるのはデフレ経済の影響でシステムの買い手に対して弱い立場に立たされていた為しかたなく仕様変更に応じていただけであり本来仕様変更はできないものなのです。
 「仕様変更できるのが当たり前」という認識を持っている発注元企業は考え方を改めないとITベンダーに撤退されてしまう可能性もあります。注意してください。

 ウォーターフォールにおける仕様変更が何を意味するのか簡単に説明します。
 以下の計画が正常な仕様変更の無いウォーターフォール開発です。

 (予定)1月→ 2月→ 4月→ 8月→ 9月→ 10月
 要件定義→ 設計→ 開発→ テスト→ 納品→ 導入

 現在の時期は6月で進捗が開発50%達成しているとしましょう。
 このタイミングで設計に25%の仕様変更が入るとします。この仕様変更は開発済みの50%に全て含まれるとします。
 正常に仕様変更を行い計画を変更すると以下のようになります。()内は工数です。1ヶ月は20日です。

 要件定義→設計→開発→テスト→納品→導入

要件定義1月(20日)
設計2月(40日)
開発4月(80日)
現在6月初頭
テスト8月(20日)
納品9月(20日)
導入10月

 設計工数は40日の25%なので10日。
 開発工数は80日の25%+50%=75%なので60日。(25%が20日)

 要件定義→設計→開発(50%)→設計(25%)→開発(25%+50%=75%)→検収→納品・導入

 
要件定義1月(20日)
設計2月(40日)
開発4月(40日)
現在6月初頭
設計6月(10日)
開発6.5月(60日)
テスト9.5月(20日)
納品10.5月(20日)
導入12.5月

 設計は25%、工数10日分しか変更していませんが設計の影響を受ける開発が設計の2倍手間がかかる為、25%でも20日の工数がかかります。(実際の開発は5倍10倍ぐらいとお考えください)
 追加された工数は設計10日開発20日となります。
 既に後工程ができあがっている部分を前工程に戻って変更すると、その影響を受ける後工程はやり直しになります。つまり工程が重複するわけです。重複はそのままコストに積み増しされます。
 今までSIerが引き受けていた仕様変更の負担というのは二つの手段で吸収していました。一つは初めから余分な工数を確保して仕様変更のコストを確保しておく。この方法だと仕様変更しない場合発注元は損をすることになります。
 二つ目は下請けに無理強いをして仕様変更を無償でやらせる。これなら発注元は損をしないように見えますがそんなワケはありません。前回の説明で「多重請負の元では全ての会社がマージンを取る」ということを説明したと思います。仕様変更に備えて余分な工数を確保するということを多重請負の全ての会社がやるから無償で仕様変更をやらせるということが長期的には出来ないのです。
 もし発注元や元請けが「無理強いをして仕様変更を無償でやらせる」ことを繰り返せば下請けは次回に仕様変更分上乗せした対価を請求してきます。仕様変更を繰り返す我が儘まな発注元や元請けは他より高い開発費を最初から請求されているものなのです。

ウォーターフォールの人員配置


 ウォーターフォール開発では後工程に進むほど多くの人員が必要になります。基本設計で5人必要なら開発は20人は必要になります。テストはもっと必要になる(開発する物によってテストの規模は大きく違うため全てに当てはまるわけでは無いです。汎用品ほどテストが大規模になります。通常はユーザーに参加してもらいます)
 昔、設計と開発を同じ人間がやっていたころは開発工程を長く取ることで設計も開発も同じ人数で同じ人間がやっていましたが、現在は開発に十分な時間を掛けられない為人数を増やすやり方をしています。時間を掛けられないのはおそらく発注元の都合でしょう。
 つまりプログラマーなどの開発者は一つのプロジェクトに長く参加することが出来ません。ウォーターフォールの開発工程は短期間に多くに人員を必要としますが終われば、開発者は無用になるので契約解除(つまりクビ)になります。
 SIer業界ではこのように開発プロジェクトのたびに開発者を招集しては契約解除するということを当たり前のようにやっています。業界が派遣プログラマーやSESや偽装請負を必要とする背景にも開発手法の問題は影響していると思います。
 これは現在のSIer型ウォーターフォールを続ける限り変えることができません。

ウォーターフォールの嘘


 ウォーターフォールについてはいくつか嘘がまかり通っています。

(1)ウォーターフォールは逆流できない。
(2)人は何を作るべきか(要件)を物を作る前に完璧に決めることが出来る。
(3)人は計画を予定通りに遂行することができる。
(4)計画で想定していない事件は起こらない。
(5)後工程は前工程に隷属しなければならない。

(1)ウォーターフォールは逆流できない。


 SIer型ウォーターフォールでは前工程にミスがあったとき、後工程から前工程へ工程を戻ってやり直すことができない、とされています。しかし本物のウォーターフォールでは工程の逆流を認めています。
 冷静によく考えれば、設計ミスが開発工程で発見され、一度設計工程へ戻ってやり直し再び開発を行う、ということは別に奇妙なことではなく普通の物作りで良くある場面です。なぜ「逆流できない」などという嘘がまかり通るのでしょう。

 SIer業界は先に説明したように多重請負体制に基づく役割分担が行われています。要求分析・要件定義を担当する会社と、設計する会社と、開発する会社とそこにITエンジニアを派遣する会社は全て別々の会社です。
 この業界構造はSIer型ウォーターフォール開発手法に大きく依存しています。設計する会社は開発会社に開発を発注します。つまり開発会社にとって設計会社は顧客です。デフレ経済下では買い手が有利なので開発会社は顧客である設計会社に逆らえません。その為設計にミスがあって指摘しても設計会社がミスを認めないことが多いのです。結果、逆流しないで無理矢理開発を強行するのです。
 また、もう一つの理由として「人的レバレッジ」を行っているから、とも説明できます。
 設計を担当している会社も、開発を担当している会社も、それぞれ正社員を多く雇わずに必要な技術者を「人的レバレッジ」で必要に応じて招集します。
 設計会社と開発会社がそれぞれバラバラに「人的レバレッジ」を行う為、設計会社は設計工程が終わったら人員を解放(契約解除)してしまいます。その為開発会社が開発工程に入ったときには設計を担当したITエンジニアはもう解放されていてプロジェクトに居ないのです。従って開発工程で設計ミスが見つかってもそれを直せる設計者は居ない為、設計工程に戻ることが出来ないのです。
 通常この場合、開発者が設計を修正します。その修正が正しいかどうかは厳密には誰にも分かりません。

(2)人は何を作るべきか(要件)を物を作る前に完璧に決めることが出来る。


 SIer型ウォーターフォールではお客様は神様です。私はお客様というのは只の「買い手」と認識しているので神様とは思っていません。
 だいたい私は「仏教徒」です。仏教では神様を信仰しません。ブッダの教えを学び実践するのが仏教徒の考え方でありキリスト教徒のように神様に服従したりしません。(神道における神々は日本人のご先祖様であり又同胞の一種なのでやはり神に服従したりしません)
 SIer型ウォーターフォールでは発注元が一番偉く逆らえない存在です。発注元がシステムの仕様について一番大きな発言権を持ち、実際に仕様設計に干渉します。
 そして、発注元は多くの場合「IT素人」です。
 この「IT素人」がシステムの「要件をシステムを作る前に全て完璧に間違いも曖昧さもなく定義できる」という前提で計画されるのがウォーターフォール開発なのです。
 「IT素人」が作る前に具体的な「システムが稼働し業務で動いている姿」を正確に想像できるでしょうか? それを正確に人に説明できるでしょうか? 要件定義書に書けるでしょうか? そもそも要件定義書の書き方を知っているのでしょうか?

 正直に申し上げると「そんなこと出来るわけ無いだろう!」というのが私の本音です。
 業務に合わせて要件を定義するなどという技術はITエンジニアでもかなりベテランでなければ務まりません。素人がニワカにしかも業務の片手間でできる仕事ではありません。
 ウォーターフォール開発は重要な最前工程を「IT素人」が完璧に遂行することを前提に計画を立て実施するのです。
 最初から失敗が約束されているようなものです。

(3)人は計画を予定通りに遂行することができる。


 ウォーターフォールでは工程ごと個々の作業ごとに期間を定め何を何時やるか予定を立て、ガントチャートに記述します。
 ガントチャートは縦軸に個々の作業をリストアップし、横軸で時間(期間)を表し、直線の長さで「何時から何時まで何をやるか」を記述します。

 このガントチャートの問題はいくつかあります。
(1)個々の作業の依存関係を記述できない。
 例えば設計しなければ開発に入ることが出来ないのですが、ガントチャートでは設計工程と開発工程が重複した計画が書けてしまいます。また、そのようなガントチャートが平気で書かれています。
(2)直線の長さで必要な情報を記述するので記入がかなり面倒で修正が困難なこと。
 かなりの頻度で修正すべきことが修正されません。書き換えにくいという理由で。
 Microsoft Project のような管理ツールを使用すれば書き換えは容易ですがガントチャートのどこが何故変更されたのかすぐには分かりません。
(3)担当者の重複に気づかない。
 人的資源の管理が計画に反映されにくい。
 Microsoft Project を使用すれば資源管理も出来るのですが、これはガントチャートで管理しているのではなくデータベースで管理してその一部のデータをガントチャートで表示しているだけです。

 ガントチャートはウォーターフォール開発を規定しています。SIer業界のマネージャー達はガントチャートに記載されている情報だけでプロジェクトを管理しようとします。ガントチャートで表せない概念は存在せず、ガントチャートに書かれたモノは正しい、と考えます。
 設計工程と開発工程が重なっていてもガントチャートに書ければそれは正しいのです。一人の人間に同じ時期に複数作業が重なってもガントチャートに記載されれば従わなければならないのです。

 以上のようにガントチャートは計画を必ずしも正確に記述できません。言語が思考を規定するように、ガントチャートは計画を規定します。ソフトウェアプロジェクトの記述方法としてガントチャートは相応しい方法とは思えないのです。
 ガントチャートというものは所詮、部外者に計画を大雑把に説明する道具に過ぎず、計画を正確に記述できるツールではないと思います。

 「人は計画を予定通りに遂行することができる」のかの話に戻ります。

 計画は進捗するにつれ変わっていくものです。ソフトウェアの場合は「作ってみたら予想と違っていたので設計を変更した」なんてことは日常茶飯事なわけです。「設計を変更する」ということは「何を作るかを変更する」ということで当然に「どのように作るか」ということも変わってきます。ソフトウェアというものは作っていく内に構造が変わっていくものなのです。計画もそれに合わせて変わっていかなければなりません。
 「計画を予定通りに遂行する」という考え方自体が現実的ではないと思います。製品は開発を進めるにつれて変わってきます。計画は製品に従属します。ならば計画は製品に合わせて変わらなければなりません。

 ウォーターフォールはガントチャートによって記述された「計画に人も製品も全てを合わせよう」とします。
 しかし本来は「製品と人に合わせて計画を記述」しなければなりません。計画と製品や人の主従関係が逆になっています。本末転倒です。
 計画と思考を規定しているガントチャート自体が不正確な道具です。

(4)計画で想定していない事件は起こらない。


 そんな分けないだろう !
 としか言いようがないです。
 開発メンバーが突然死ぬかも知れないし、辞めるかも知れない。
 顧客がちゃぶ台ひっくり返すかも知れないし、「計画では想定していないことは必ず起きる」と考えるべきでしょう。
 これは計画には常に余裕を持たせるべきだ。ということです。
 SIer業界のプロジェクトはギリギリの計画を立てるものが多く、予想外の事態への対処はITエンジニアの残業で対処するのが当然だ! という価値観が跋扈しています。夜間の対応が必要な案件でも夜間要員を用意せず「少しぐらいなら良いだろう」とITエンジニアに徹夜させます。マネジメントに関してはホントにルーズです。
 結局人員に残業させ放題だ! という甘えが非常事態への対処を無視する怠慢へと繋がっているのでしょう。

(5)後工程は前工程に隷属しなければならない


 本来、前工程と後工程は対等です。それよりも高が工程の違いで序列や上下関係が何故生じるのが不明です。意味が分かりません。
 しかし、SIer業界では後工程を下等生物のように軽視する価値観が随分昔から続いています。プログラマーはSIer業界では卑しい仕事となっています。
 今はテストエンジニアやインフラエンジニアを軽視するようになっているようです。それも虐げられてきたプログラマーがです。
 もう「やれやれ」という言葉しか浮かんできません。虐げられている奴らが虐げているバカ共の価値観に従ってどうすんだ ?

 実務の話をします。
 前工程と後工程に上下関係があると開発の障害になります。人間は必ずミスをするので前工程の担当者は必ずミスをします。前工程のミスは通常、後工程で見つかります。
 後工程がミスを指摘したら前工程はミスを修正しなければなりません。上下関係があるとこれができません。ミスを残したまま開発を強行することになります。
 十中八九炎上します。

SIer型ウォーターフォール開発は以上のような非現実的な嘘に基づいて、計画が立てられ、取引が行われています。


アジャイル開発の利点と欠点


 [アジャイル開発]

 反復期間は1週間から1ヶ月程度の固定期間。
 反復期間ごとに動くソフトウェアをリリースする。
 反復期間を繰り返すことにより完成品へ近づけてゆく。
 通常は毎回機能を追加していく形になるが、仕様変更を反映し改造する場合もある。

 反復期間-1) 目標定義→設計→開発→テスト→納品→導入
 反復期間-2) 目標定義→設計→開発→テスト→納品→導入
 反復期間-3) 目標定義→設計→開発→テスト→納品→導入
 反復期間-4) 目標定義→設計→開発→テスト→納品→導入
 反復期間-5) 目標定義→設計→開発→テスト→納品→導入
 反復期間-6) 目標定義→設計→開発→テスト→納品→導入

 目標定義とはウォーターフォールの要件定義に似たものである。
 要件定義は納品時に必ず満たさなければならないものだが、アジャイルでは要件を満たすことより反復期間の期日に稼働するソフトウェアを納品することを優先する。従って予定遅延などにより全ての要件を満たせない場合は、要件を次の反復期間へ先送りして実装しない。
 民法の請負契約では「要件定義に書かれた要件を満たすかどうか」で契約を満たすかどうかを判断する。これはアジャイル開発には適さない。
 アジャイルならば準委任契約で反復期間ごとに目標定義を定めて、
 第一に「反復期間末尾に稼働する製品を納品する」こと、
 第二に「目標定義をできる範囲で満たすこと」の優先順位で開発を進める。
 反復期間中に目標定義を満たせなければ、目標定義の一部を次の反復開発へ先送りにする。
 優先順位は「反復期間にリリースする」ことが「目標定義を満たす」より上になる。
 リリースされた製品をユーザーが検証して次に何を作るべきか決めるからだ。目標が満たせなくても、出来るところまで作りユーザーに見せることが重要なのだ。

 例えば「反復期間-1」で目標定義がA,B,C,Dの4つ定義されたとする。
 実際に作ってみるとA,B,Cの3つしか作れなかったとする。この場合A,B,Cを実装したソフトウェアを「反復期間-1」でリリースし、目標定義「D」は「反復期間-2」の目標定義群に加えられる。
 逆のケースもある。「反復期間-2」の目標定義がD,E,Fだとする。
 予想より簡単でD,E,Fが全て終わりさらに「G」が実装できる。
 この場合D,E,F,Gを実装したソフトウェアがリリースされる。
 目標定義は少し多めに定義しておき、いくつか先送りになるのが当たり前という認識で開発を進める。

 よく誤解されるがアジャイル開発は最初に何も考えずにいきなり開発を始めるわけではない。開発に入る前に業務を分析しシステム構想を練り企画を立ててから、開発に入る。何を作るか構想も持たずに作り始めるわけではない。
 要件定義より前の工程はウォーターフォール開発のそれと同じである。
 アジャイルだからと言って、開発の前のシステム企画・構想の段階では何を作るのかよく考えて製品イメージを作らなければならない。
 開発前に試行錯誤しなければならないのはウォーターフォールと同じで、開発しながら重要な構想を試行錯誤して良いわけではない。
 構想ぐらいは先に決めておけということ。

 アジャイル開発の利点は以下のものになると思います。
・最初に全ての要件を明確に定義しなくても良い。
・途中で仕様変更が可能である。(仕様変更するとコストが余分に掛かるのは同じです。仕様変更にも限度というものがあります)
・開発初期の段階から必要最小限の機能を実装したソフトウェアを使用することが出来る。
・重要な機能から実装するので、
 重要な間違いは早い段階で発見できる。
 重要な機能ほど早く使い始めることができる。
 重要な機能ほど長期間に渡ってテスト検証することが出来る。
・開発終盤には重要ではない機能を作っている。
 途中で予算が無くなって開発を中断しても損害は少ない。

 欠点は以下になると思います。
・開発前に納期と価格(総経費)がわからない。(最初に何を作るか決めていない為)
・要件を定義しないので民法の請負契約が成立しない為、瑕疵担保責任を受託者に要求できない。(契約は準委任契約になります)
・発注者は反復期間ごとに納品される製品を検証し次の目標定義を作らなければならない。
 発注者はとても忙しくなります。
 業務の片手間で適当に済ますことは出来なくなり本格的に開発メンバーとしてシステム開発プロジェクトに参画しなければならなくなります。
 丸投げ体質のやる気の無い発注者には務まらないでしょう。

SIer業界がウォーターフォールを選ぶ理由


 先に説明しましたが、SIer業界の多重請負体制はウォーターフォール開発手法に大きく依存しています。
 提案→企画→要件定義→設計→開発→テスト→納品→導入
 という工程を別々の会社が行うことでSIer業界が成立しているわけです。
 提案と企画はコンサルタントの仕事なので別でも良いのですが、さすがに設計と開発を分けるのは生産性が悪すぎるのです。(開発とテストは同じ会社がやります)
 設計も基本設計と詳細設計に分かれておりそれぞれを別の会社が行うことも日常茶飯事です。
 前工程を元請けが、後工程を下請けが受注し、さらに後ろの後工程を孫請けが受注するという具合に多重請負化していきます。

(多重請負の例)

 発注元 提案書を丸投げ
 1次受け 営業。丸投げ
 2次受け 要件定義代筆
 3次受け 基本設計
 4次受け 詳細設計
 5次受け 開発管理
 6次受け 1次技術者派遣
 7次受け 2次技術者派遣(偽装請負)
 8次受け 3次技術者派遣(偽装請負)

 この多重請負体制はウォーターフォール開発以外の開発手法を受け入れることが出来ません。
 仮にアジャイル開発を受け入れたらどうなるか想像してみましょう。

 アジャイル開発は反復開発で
 目標定義→設計→開発→テスト→納品→導入
 →目標定義→設計→開発→テスト→納品→導入
 →目標定義→設計→開発→テスト→納品→導入
 →目標定義→設計→開発→テスト→納品→導入
 →目標定義→設計→開発→テスト→納品→導入
 というように前工程から後工程まで一連の工程を短期間(1週間から1ヶ月)で繰り返します。
 多重請負体制でこれを採用すると、以下のようになります。

 反復期間-1 発注元 提案書を丸投げ
 反復期間-1 1次請け 営業。丸投げ
 反復期間-1 2次請け 目標定義
 反復期間-1 3次請け 設計
 反復期間-1 4次請け 開発
 反復期間-1 5次請け 1次技術者派遣
 反復期間-1 6次請け 2次技術者派遣(偽装請負)
 反復期間-1 4次請け 納品
 反復期間-1 5次請け 1次技術者回収
 反復期間-1 6次請け 2次技術者回収
 反復期間-1 3次請け 納品
 反復期間-1 2次請け 納品
 反復期間-1 1次請け 納品
 反復期間-1 発注元 導入・検証

 反復期間-2 発注元 目標定義を依頼
 反復期間-2 1次請け 営業。丸投げ
 反復期間-2 2次請け 目標定義
 反復期間-2 3次請け 設計
 反復期間-2 4次請け 開発
 反復期間-2 5次請け 1次技術者派遣
 反復期間-2 6次請け 2次技術者派遣(偽装請負)
 反復期間-2 4次請け 納品
 反復期間-2 5次請け 1次技術者回収
 反復期間-2 6次請け 2次技術者回収
 反復期間-2 3次請け 納品
 反復期間-2 2次請け 納品
 反復期間-2 1次請け 納品
 反復期間-2 発注元 導入・検証

 反復期間-3 発注元 目標定義を依頼
 反復期間-3 1次請け 営業。丸投げ
 反復期間-3 2次請け 目標定義
 反復期間-3 3次請け 設計
 反復期間-3 4次請け 開発
 反復期間-3 5次請け 1次技術者派遣
 反復期間-3 6次請け 2次技術者派遣(偽装請負)
 反復期間-3 4次請け 納品
 反復期間-3 5次請け 1次技術者回収
 反復期間-3 6次請け 2次技術者回収
 反復期間-3 3次請け 納品
 反復期間-3 2次請け 納品
 反復期間-3 1次請け 納品
 反復期間-3 発注元 導入・検証

 反復期間-4 発注元 目標定義を依頼
 反復期間-4 1次請け 営業。丸投げ
 反復期間-4 2次請け 目標定義
 反復期間-4 ........
 反復期間-4 ....

 反復期間が仮に2週間(14日)だとすると4次請けまでの多重階層を14日間の間に往復しなければなりません。しかも反復期間の末尾には動くソフトウェアをリリースしなければなりません。途中一度でもミスをして手戻りしたらリリースは不可能です。
 アジャイルでは、優先順位は「反復期間にリリースする」ことが「目標定義を満たす」より上になる。という話をしました。
 多重請負体制はこのルールを守ることに向いていません。ステークホルダーが多すぎて会社間の仕様のすり合わせに時間がかかりすぎるからです。
 だいたい目標定義、設計、開発、納品1,2,3と14日の間に別々の会社がやっていては、3次請けが設計をしているとき、他の会社は待機していなければなりません。4次請けが開発しているとき3次請け含め他は待機していなければなりません。全ての工程にこのような待機が発生します。
 さらにアジャイルは人的レバレッジにも適しません。
 ウオーターフォールなら開発の時に多くの人手を必要とし終われば解放(クビに)しますが、アジャイルはプロジェクトの開始から終了まであまり必要な人員が変わりません。というか今居る人員の生産性に合わせて目標定義を決めるので、必要な人員が急に増えたり減ったりするわけが無いのです。
 これなら有期雇用でもいいので雇用契約を結んだ方が人員を安定確保できるので有利なわけです。派遣契約もアジャイル開発には適さないと思います。
 通常、アジャイル開発はシステムの内製に向いています。アジャイルだと業務部門の仕事が多くなりますからシステム開発者とのコミュニケーションの頻度も非常に増えます。お互い同僚で近しい関係が望ましいのです。
 外注でやるならリモート会議や非同期通信の積極活用が必要になるでしょう。

 以上のような理由で、多重請負体制ではアジャイル開発を導入できません。

ウォーターフォールの利権


 多重請負体制には利権を握っている人々もいます。
 一言で言えば「仲介業者」です。彼らは多重請負体制だからこそ稼ぐことが出来、体制が無くなれば食い扶持を失います。
 仲介業者は大きく二つに分かれます。

 一つは「人売り」いわゆる派遣会社ですが、合法的な派遣会社ならまだ良いのですが、SIer業界には違法な偽装請負で社員を派遣する悪徳業者がゴロゴロしています。
 準委任契約で業務を受託するのですが、客先常駐という名目で実質派遣労働というのが一般的です。
 準委任契約は顧客に指揮命令権はありません。どこで働くか何時間働くか何日の何時から何時まで働くかは全て自社で決めるものです。これらを指揮命令した時点で民法違反であり下請法違反であり、実質は派遣労働なので派遣労働法違反になります。実に三重の違法行為です。労働者が公正取引委員会と労働基準監督署に相談すれば高確率で指導が入るでしょう。指導が入れば裁判で勝つ確率が高くなりますから裁判にも訴えられるでしょう。現在、多くの会社が訴えられないのはITエンジニアが法律に無知か諦めているからです。諦めているのはデフレマインドだと思います。インフレになると変わってくると私は思っています。
 私は「人売り」は長期的には続かないと考えています。

 もう一つの仲介業者は「仲介設計者」と私は呼んでいます。
 多重請負の深化の過程でかつて設計以下の工程を請け負ってきた受託開発業者が開発工程を外注するようになり、そのまま十年経ち世代交代して開発経験の無いSEが設計するようになります。ここで「プログラムの組めないSE」というものが生まれます。
 彼らは開発経験が無いのでマトモな設計書は書けません。曖昧で間違いだらけの設計書、あるいは画面レイアウトだけで説明も無い設計書を書いて、下請けに仕事を投げています。当然、下請けはそんな設計書では開発できないので設計者に質問しながら設計書を正しい設計書に書き直します。そして開発を行うのです。
 この場合、実質設計しているのは下請けの開発社です。設計社は落書きみたいな設計書もどきを書いているだけなので実質仕事をしていないのです。
 多重請負の深化の過程でこういう会社が増えてきました。こうなると設計担当者でもなく只のピンハネ業者です。彼らも上の世代はキチンとプログラムを組めてマトモな設計書を書けるのですが下の世代は開発経験が無く技術が空洞化しています。ピンハネでしか商売が成り立たなくなります。
 このケースは今のところ上の世代がまだ残っているので会社ごと全て「仲介設計者」というのはまだ無いと思いますが、実業がそうなっているケースはあります。長期継続するとホントに空洞化するでしょう。

 SIer業界には一部(少数ではない)にこのようなピンハネ業者がいて、彼らはウォーターフォール多重請負体制の利権者となっています。当然にアジャイル開発のような手法は敬遠するでしょう。
 SIer業界では前工程の業者の方が力を持っていますから、前工程ほど多重請負体制を維持しようとします。だからウォーターフォールも辞めることが出来ないのでしょう。


多重請負体制を維持する限りウォーターフォールを辞められない


 以上のように元々は発注元のコストダウンを目的に始まったシステム開発の外注を下請けのSIerまで行うようになり、外注を下へ下へとエスカレートさせてきたわけです。
 結果として、人材の流通を制御できない状態を作り出します。
 人材の流通に問題があるにも関わらず、ピラミッドの上層はひたすらコストダウン圧力を繰り返すだけなので、人材流通の問題は野放しになりコストを無駄に垂れ流すバケツの穴となります。
 「人売り」と「仲介設計者」はここに集り無駄金を収穫する商売と化しており、ウォーターフォール多重請負が無ければ成り立たない商売となっています。

 エンジニア派遣すべてを否定しているわけではありません。また、設計とコンサルを生業にしている業者を批判するわけでも無いです。

 しかし明らかに何の付加価値も生み出さずマージンのピンハネだけで稼ぐ業者が非常に増えてきたのは事実です。彼らが増えれば増えるほど多重請負体制を維持しようとするでしょうし、その結果としてウォーターフォールも維持されるでしょう。
 これは発注元も利益を考えてそうしているわけでは無いです。

ラスボスは居ない


 これまでSIer業界の問題をdisりまくって来ましたが、SIerそれ自体の悪口は言っていないはずです。
 問題の始まりは発注元企業であること、多重請負体制は最終的にはピラミッドの全てに及んでいること。を説明しました。
 つまり、今は業界の上から下まで全部悪いわけです。
 別の表現をすれば「全ての悪の元凶であるラスボスは居ない」と言えます。
 悪者を叩いて解決する問題ではありません。

 「ではどうすれば良いのか ?」
 その点を今後考えて記事を書いていきたいと思います。

 今日はここまで、とします。
 (文章が短くまとまらない)

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ