正確には
- 請負契約を減らして内製を増やすべきだ
- 内製を増やすための「一つの手段として」解雇規制の緩和が必要だ
と言う事です。内製化が解雇規制を緩和だけで実現できるとは思っていません。
本稿は主に私の実体験の上に成り立っています。異論・反論あるでしょう。しかし、行き詰まって見えるSI業界界隈の問題認識・解決に向けられた、一人のアーキテクトの思いを伝えてみたくなり、本稿を綴って見ることにしました。
============== 2018.09.15追記 ==============
大変大きな反響をいただき、たくさん「はてなブックマーク」もたくさんして頂きました。説明不足で正しく伝えられなかったと思うものが多かったため、こちらにブックマークへの書き込み全てへ回答を付けさせていただいています。
「SIerは減らす為に解雇規制の緩和が必要」の「はてブ」への回答 - nuits.jp blog
=============== 追記終わり ================
良かったらしばらくお付き合いください。
なぜ「SIerは減らすべきだと思うが、その為には解雇規制の緩和が必要」なのか
端的に言うと次のとおりです。
- SIerの利益構造は請負契約を前提に成り立っている
- 請負契約は、それを端に発するデメリットが大きい
- 内製へシフトするに辺り、雇用リスクが一つの障壁となる
SIerの利益構造は請負契約を前提に成り立っている
「まだ取引が浅いので派遣・準委任（SES）で入り込んで、信頼を獲得して請負で持ち帰りたい」
なんて話を耳にした事ありませんか？受託開発界隈では、そこかしこでそんな会話が繰り広げられています。なぜか？もちろんその方が利益を上げやすいからです。これは二つの理由に集約できます。
- 社外のリソースを活用することで、事業規模の拡大と原価の抑制を実現しやすい
- エース級の人材を、1案件に縛り付けずに済む
派遣や準委任で単価の向上を図ることは困難です。「社員数×単価」を超える業績を上げようと考えると、請負契約で持ち帰らないと難しいという事です。*1*2
しかし請負契約には、大きな落とし穴があります。
請負契約は、それを端に発するデメリットが大きい
請負契約における開発は、内製と比較してQuality・Cost・Delivery全ての面において不利です。*3
掘り下げていくと次の二つの理由にたどり着きます。
- ソフトウェア開発において正確な見積もりは困難を極める
- 開発前にシステムのあるべき姿を定義することは不可能
この二つを裏付ける論拠として、つぎの図の「不確実性コーン」*4というものがあります。
初期コンセプトの見積は、実際にかかるコストにたいして0.25～4倍の範囲で誤差が発生する。誤差はプロジェクトの進捗とともに小さくなっていく、というものです。
こんな中で（概ね）黒字運転する為に、私の身近なところではプロジェクト全体をいくつかのフェーズに分割して契約・管理しています。
- 営業フェーズ
- 要件定義フェーズ
- 開発フェーズ（ここがさらに分割されることも）
営業フェーズでは業務の大まかなAsIs-ToBe分析を行い、システムに求められるユースケースを抽出します。このフェーズは基本無料で対応しています。営業なので。
そして、つぎの二つの見積を含む提案書を作成します。
- 要件定義フェーズの正式な見積
- 開発フェーズの概算見積
これらの見積には、以下の内容をがっつり盛り込みます。
- 想定するシステムに含まれるもの
- 想定するシステムに含まれないもの
- 想定するシステムを実現するための種々の前提条件
これらのいずれかが、少しでも変化したら再見積もりです。ただし見積書のグレーゾーンはすべてSIerが黒なので見積変更は要求しません*5。規模によりますが場合によってはこの「営業」に百万を超えるコストが掛かります。*6
この提案書が受け入れられたら要件定義フェーズに入ります。
要件定義フェーズは準委任で契約します。フェーズ開始時に要件が未確定で成果物を決定できないため、請負契約にはしません。必死で取り組みますが、完了は約束しません。また客先常駐はしませんが、フィールドワークは頻繁に行います。
このフェーズで、おもに次の三つのドキュメント*7を作成します。
- 業務定義書
- 機能定義書
- 非機能定義書
これらのドキュメントの精度が以後の全てを決定します。ドキュメントはSIerの命綱なので*8、時間もコストも掛けて、大量のドキュメントを一字一句に気を配り、決死の思いで作成します。完成したドキュメントは顧客が目を皿のようにしてレビューします。
実際のところSIerも「巻き戻らないウォーターフォール」なんて夢は見ません。ここで膨大なコストを掛けても抜け漏れは絶対に発生します。その場合、つぎのいずれかで対応します。
- ドキュメントに明確に書かれている内容の変更
→ 顧客が追加コストを支払いリスケするか、他機能を削る - ドキュメントが曖昧で顧客とSIerの見解が異なる
→ SIerの過失として頑張る*9
ここまでするのは、システムを欲する側と開発する側が異なる企業であるからです。でなければ完全に無駄なコストです。
これらの定義書を前提として、開発フェーズの正式な見積書を作成します。
見積もりが受け容れられれば、開発フェーズから先は請負契約になります。ただし、契約期間は3ヶ月〜6ヶ月程で一度区切りリリースします。それ以降の契約はフィードバックを加えて再見積・再契約します。
おおまかに言えばこんな流れです。アジャイルではありませんが、反復型の開発プロセスに近いと思います。
さて内製と比較して、請負契約による開発がなぜQuality・Cost・Delivery全ての面で劣るのか、整理すると次のようになります。
| 項目 | 説明 |
|---|---|
| Quality | 開発フェーズに入ってからの要件変更は、顧客かSIerの何れかの「過失」扱いになるため、変更要求をあげにくい体制・慣習にあり、俊敏に改善しにくい*10 |
| Cost | 顧客もSIerも防御的にならざるを得ず、大量のドキュメントという名の契約書を作成するため |
| Delivery | Cost面の問題に加えて、多数の利害関係者の合意をとるため、何事も決定まで時間がかかる |
請負契約でアウトソースするリスクの回避に、顧客は多大な犠牲を払っているわけです*11。ではこれを解決するには、どうすればいいのか？
SIerを減らして、内製率を上げれば解決します。
やっと「SIerは減らすべき」理由が説明できました。しかし、内製化には多くの課題があります。
内製へシフトするに辺り、雇用リスクが一つの障壁となる
課題は多数ありますが、ここでは雇用リスクに絞ってお話しします。
トラディショナルな日本企業では、必要なIT人材の「人数」も「スキルセット」も変動幅が大きく、ピーク時に必要な人数を社員として雇用するのが難しいという問題があります。
企業におけるシステム開発の要求とは、つぎの二つに分けられるでしょう。
- 企業内部からの要求
- 企業外部からの要求
問題は後者で、これは法令改正（消費税増税など）によるシステム対応などが該当します。外部からの要求は企業でコントロールできませんし、その影響は場合によって多数のシステムに一気に波及します。*12
こういった理由からIT部門は必要に応じた柔軟性を求められますが、ここで厳しい解雇規制が問題になるわけです。
直接雇用が難しいなら一次的な契約で・・・となりますが、SIerは請負契約に依存しているため、全面的な派遣事業への転換は好まないでしょう。そして一般派遣の事業許可取得は中々難しいようです。ユーザー企業の需要を満たすことは難しいでしょう。
またエンジニアの特にプログラミングに近い領域の人材の選択肢が、一般派遣に大きく偏ることが良いことなのか私には判断しかねます。*13
ではどうすれば良いのか？
- 解雇規制を緩和して人材の流動性を高め、企業側は必要な人材を必要なだけ雇用しやすい状況にし、内製化を進めることで生産性と品質の向上を図る
- エンジニア側は解雇のリスクは高まるが、求人も増えることを前提に、自分のキャリアパスにあった企業を渡り歩く
こんなスタイルが最も好ましいのではないかと考えています。勿論、解雇リスクが高まる分、給与単価が向上することが前提となりますし、優秀な人材は実際に収入も増えるはずです。
もっとも
- 雇用の流動性が確保できる
- エンジニアの待遇が改善する
のであれば、手段は別に解雇規制の緩和である必要はありません。そして当然ながら、解雇規制の緩和すると言うことは、プロジェクトの度に全員解散すると言うことでもありません。スキルが高いコアメンバーを中心に、恒常的に必要となる規模＋αの人材は継続的に雇用されるでしょう。
こうなると当然SIerの需要は下がり減らざるを得ないでしょう。でもそれで良いのだと思います。
エンジニア組織を「ちゃんと」管理できる人材や、上流工程を適切にこなせる人材は、いくらでも需要があるでしょう。またSIerも自身が蓄積した（はずの）IT技術を活用して、ITサービスの提供者に転換する努力も必要だとは思います。*14
まとめ
改めて整理してみましょう。
- SIerの利益構造は請負契約を前提に成り立っている
- しかし請負契約は、それを端に発するデメリットが大きい
- そのため内製化を進めるべきだが、雇用リスクが一つの障壁となる
- そこで雇用の流動性を高め、内製化を促進しIT後進国を脱却をはかる
実際には難しい問題はいくらでもあると思いますし、変革する苦痛も伴うでしょう。しかし、この方向性こそ正しい方向に私は思います。
ただ実はその為に、もう一つ大切な、いや一番重要なファクターがあると私は思っていて。。。
「変革はリスクが高く、苦痛を伴う。俺が定年するまではこのままでも生き延びられるな」なんて経営者は、俺らが茹でガエルになる前に唐揚げにしてくれる！
以上。皆さんはどう思われますか？
p.s. ここまで書いて私が何故SIerにいるかと言うと、ただの惰性と僅かな自社への期待かもしれません。
*1:これらの理由からSIerが準委任等で顧客に入り込んでアジャイルするのは限定的にならざるを得ないと考えています
*2:社員数以上の規模の受託開発を行う前提にある為、SIerのエンジニアは上流よりのスキルが求められがちです
*3:もちろん人員その他を同条件で揃えられれば、という前提に成り立ちますが
*4:引用元：プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか
*5:という覚悟を持って（もしくは持たずに適当に）私の周辺は仕事をしています。
*6:もちろん営業なので提案が蹴られて営業コストが回収できないということも良くあります。これらのコストは獲得できたプロジェクトの原価に転嫁されます。
*7:弊社用語ですけど
*8:受託開発の世界で、最後に自分を守ってくれるのも、自分を殺すのもドキュメントです。
*9:こう言う事が起こる事を想定したリスク対策費を積んでおきます
*10:ただし最初からプロトタイピングを繰り返す前提のケースも稀にあります
*11:そして誰もが果てしなく疲弊します。
*12:外部からの要求があるからといって、内部からの要求を後へ回せるとは限りませんし、とくに日本企業においては、あまりに多くのシステムを必要性が低いにもかかわらず、スクラッチで開発し過ぎてきたことで、欧米よりもこの問題は深刻なのではないかと私は考えています。
*13:ちなみにフリーランスはこの場合どうなるんでしょうか？私にはさっぱりです。
*14:そして本当の大手はとっくにそういう活動もしています
