常駐・派遣ビジネスの功罪を考える
はじめに
みなさん、こんにちは。第1回では「SIerの存在意義と抱える悩み」を解説しました。第2回以降では、「SIerが新しい時代に合ったモデルに変革して輝くために何をすべきか」を一緒に考えていきたいと思います。
孫子の兵法に「知彼知己,百戦不殆(彼を知り己を知れば百戦殆うからず)」という一節があります。この教えにしたがって、SIerの現状を冷静に見つ直すことからはじめます。まずは、日本のSIerが常駐・派遣主体になっている理由とその功罪について考えてみましょう。
採用(配牌)よりも育成(ツモ)
「我が社は、人材ではなく人財と言っている」。そう得意げに話す経営者がいます。実は”人材 意味”でググると「才能のある、役に立つ人」と表示されますし、ウィキペディアでも「才能があり、役に立つ人物」となっている(「人材」をググった結果はこちら)ので、”材=材料”という解釈は誤解なのですが、「人財」という言葉を使いたいという想いはよくわかります(ちなみに英語で人材は「Human resource」です)。
でも、こんなこと言っている割には、さっぱり社員を財産として扱っていない経営者が多いのです。それがどれほどもったいないことかを経済理論で説明します。
いろいろな業界で「当社は人が資産」という言葉を聞きますが、ソフトウェア業界は掛け値なしにその通りなのです。例えば、製紙会社では最新の抄紙機を購入することが設備投資ですが、ソフトウェア会社の場合は人を雇うことが生産設備増強のための投資です。さらに言えば、抄紙機の場合は購入した時が最大の生産性で、時間とともに相対的に価値が下がりますが、人の場合は採用時を起点にぐんぐんと生産性が上がっていく特性があります。
こんな簡単な原理に気づいていないのか、多くのソフトウェア会社は”優秀な人を採用する”のには一生懸命ですが、”採用した人を育てる”ことが疎かになっています。新入社員教育だけは行いますが、その後は放任、放置でほとんど教育を行っていません。
麻雀だって配牌よりツモが重要です(例えが悪いか……)。プロ野球でも広島カープのように人を育てるチームが強い時代です。そもそも、弱小チーム(平凡な企業)には松井やダルビッシュのような元から超優秀な選手(社員)は来ないので、せっかく入社してくれた”虎の子”を大事に育てる姿勢が大切です。
魚心あれば水心
経営者の多くは常駐・派遣ビジネスを減らし、請負開発の割合を増やしたいと思っています。常駐・派遣で社員が散り散りに働いている限り、社員の育成やノウハウの集結、会社の強みの育成が困難だからです。また、帰属意識が薄れてしまい、苦労して採用した大切な”資産”を失うことも深刻な問題として捉えています。
それでも、いっこうに常駐・派遣ビジネスが減らないのはなぜでしょう。ユーザー側とSier側それぞれの「持ちつ持たれつの関係」を理解すると理由が見えてきます。
(1)ユーザー側の事情(ニーズ)
- 一箇所に集まった方が効率が良いから
大規模開発を行うには人を集めなければなりません。1社で必要人数が不足する場合は複数の会社に委託するわけですが、その場合別々の作業場所では情報を共有しにくく、開発効率が低下しがちです。 - 融通のきく開発・保守をやってもらえるから
ユーザー企業が社員として開発者を採用し育成するのは大変です。アメリカと違ってレベルが低くても不要になっても社員を切るわけにはいきません。そんなふうに抱え続ける代わりにSIerが育ててくれた人に常駐してもらって、社員のように都合よく使わしてもらう方がよほど便利です。ときどき5年も10年も同じユーザーに常駐しているという人を見かけますが、長ければ長いほど自社の業務に精通してもらえるので楽ちんです。 - セキュリティの規定がうるさいから
2005年に個人情報保護法が全面施行され、情報セキュリティの意識が高まったにもかかわらず、企業が持つ個人情報の漏洩事件が後を絶ちません。ユーザー企業のセキュリティ対策は事件のたびに厳しくなり、情報の外部持ち出しは全面禁止、社内に開発者を集め隔離した環境で情報を厳重管理するケースが多くなりました。
(2)SIer側の事情(シーズ)
- ユーザーの要求に応えないと仕事がもらえないから
上記のような事情からユーザーが「常駐で」という条件で外注を探すため、「うちは常駐はやりません」と選り好みしているともらえる仕事が激減します。よく「うちの会社は常駐型ばっかり」なんて愚痴を聞きますが、上司も好き好んで常駐させているわけではないのです。 - 安定収入を得られるから
請負開発はうまくいけば利益も大きいですが、失敗して赤字になるリスクもつきまといます。また、1つの開発プロジェクトが終わってから間断なく次の開発プロジェクトに入れる保証はなく、要員の空き時間が発生してしまうこともあります。
一方、常駐・派遣は”人月契約”なので、そこに人を出している限りは安定した収入があります。もらえる金額と支払う金額の逆転もないので赤字リスクはありません。常駐ニーズは高いので仕事は見つけやすく、長期で同じところにいれば空き工数が発生するリスクもありません。営業費用もコンペのある請負案件に比べてぐっと小さく抑えらるので、実際に営業部門がないSIerも多いのです。 - 請負開発を行う力がないから
請負開発を成功させるには、組織として相応の開発力が必要です。実用的な開発手法を持っていて、プロジェクト管理やドキュメント標準などもきちんとしていて、開発者を育成できている企業でなければ、下手に請負開発をすれば必ずやけどします。つまり、組織として請負開発する体制、力がない企業は常駐・派遣で食っていくしかないのです。
ユーザー側のニーズとSier側の思惑は、このように”魚心あれば水心”の関係にあります。決してSIerが一方的に常駐・派遣を望んでやっているわけではないのです。
常駐・派遣ビジネスの問題から目をそらさない
「ユーザーとSIerの利害が一致しているなら良いじゃない」。そう思いたいのですが、ここで問題点から目をそむけて改革を先延ばしにすると”ゆでガエル”になってしまいます。では、いったい常駐・派遣ビジネスの問題点とは、どのようなものでしょうか。
(1)社員のスキル育成がしにくい
あちこちのユーザー企業や元請けSIerに社員が分散するため、社員を教育しにくくなります。採用には力を入れてそれなりに新入社員研修はするのですが、客先に常駐させてからは「自分でスキルアップしてね」という図式になってしまいがちです。
(2)社員のコアコンピタンスを作りにくい
このユーザーが終わったら別のユーザーというように、働く環境や作業内容が都度異なります。いろいろな会社の仕事ができるので幅広い技術・知識を身につけられるメリットはありますが、反面、自己のスキルアップが受け身になりがちで、「自分はこれに強い」という特化した強み(コアコンピタンス)を計画的に尖らせにくくなります。
(3)組織のコアコンピタンスを持ちにくい
社員があちこちに分散して働き、習得した知識・スキルが個人の中に点在するだけなので、会社(組織)としての強みに熟成しにくいです。SIerのホームページを見ると「技術力」「ソリューション力」「高品質」などの漠然とした強みをアピールしている会社が多いですが、裏を返せば「これといった強みを持ててない証」と言えます。
(4)働く環境として居心地が悪い
オズの魔法使いでドロシーが”There’s no place like home.”と言ったように、「やっぱり家が一番!」と口にしてしまうのは世界共通です。客先に他のSIerと一緒に”外注”として隔離され、サボらないか監視されながら黙々と仕事をさせられるのは窮屈でストレスが溜まります。スマホを見たり、自社と電話したりすることに目くじらを立てるユーザーもいますし、有給を取ったり外部セミナーに参加したりするのにも気を遣います。特に最近はセキュリティ管理が厳しく、職場によっては「牢獄にいるみたいだ!」なんて声も聞かれます。
(5)社員が定着しにくい
会社との接点が少ないため社員の帰属意識が低くなり、社員の定着率が低くなります。せっかく採用したのに、スキルを高めて稼げるようになったら転職されてしまう。ソフトウェア会社は”人が財産”なのに、こんなふうに資産が流出し続ける限りいつまでたっても経営は楽になりません。
(6)利益率が低く、会社の価値も低い
常駐・派遣主体の会社は、売上高利益率が非常に低いです。また、社員教育がままならず定着率も低いので、会社の資産価値(スキル×人数)も高まりません。当然ながら、そこで働く社員の給料も低く抑えられるので、自らの努力でスキルを高めた社員は転職したりフリーランスに転じたりしてしまいがちです。
このように問題点をあげつらうと、”魚心あれば水心”なんて悠長なことは言っていられませんね(時代劇で悪い奴が言うセリフですし……)。もちろん、誰しもがこの状況を「このままじゃいけない、改革しなければ……」と思っているのですが、「でも、どうすべきかわからない」のです。
こうした経営課題に「銀の弾丸」はありません。声高に「今までの◯◯はダメだ、これからは◯◯でうまくいく」などと言い切る奴はみんなペテン師です。私もそんなウルトラCは言えません。でも、これまでに私が行った試行錯誤から「立ち上がって、歩き出す」ためのお手伝いはできると思っています。次回からは、その具体的な改革プランを掘り下げていきます。
常駐・派遣主体のSIerも派遣会社も、エンジニアをユーザー企業に常駐させて「時間単価の収益を得る」という点では一緒です。本連載ではエンジニアを雇用している企業=SIer、エンジニアの登録だけで雇用しない企業=派遣会社として区別しています。後者は一般労働者派遣事業と同じビジネスモデルであり、本連載の対象外としています。
前回、「アメリカのSIer技術者の割合は日本に比べて少ない」というデータを紹介しましたが、そのからくりがフリーランスです。実はアメリカでは「エンジニアを雇用して、教育して、ユーザー企業に送り込む」という日本のSIerのスタイルは珍しく、個人が派遣会社(第三者リクルーター)経由もしくは独自にユーザーを探して、自分の専門知識・スキルに応じて契約するフリーランスが多いのです。
日本でもクラウドソーシングサービスの登場などもあって派遣会社を利用する人(フリーランス)は増えており、私の会社でも何人か契約しています。これまで「個人とは契約しない」としていた(古くさい)ユーザー企業も時代の変化とともに個人契約OKに変わりつつあります。常駐・派遣主体のSIerも、そうした変化を意識してユーザーと社員の両方から頼られる存在にならなければ、存在意義が失われかねません。
ITサービス業の実態を把握した上で考える
改革プランを考える前に、日本のIT業界の実態を数値で把握しておきましょう。経産省が売上高の7〜8割をカバーする上位企業を対象に毎年行っている「特定サービス産業動態統計調査」というレポートがあります。この中からSIerに関連する「情報サービス業」と「インターネット付随サービス業」の売上を抽出したグラフをご覧ください(図)。
※出典:経済産業省 大臣官房調査統計グループ 特定サービス産業動態統計月報 P18,26よりピックアップ
受注ソフトウェアが情報サービス業全体の62%を占めており、やはり日本ではSIerが中核を担っていることがわかります。受注ソフトウェアには常駐・派遣と自社持ち帰りの一括請負が含まれています。客先常駐型の比率も知りたかったのですが、派遣契約や準委任契約はもちろん、請負契約でも客先常駐となることも多いので、適当なデータがありませんでした。
ソフトウェアプロダクツは全体の10%しかありません。受注ソフトウェアが多重下請け構造(次回で解説)なので売上が嵩上げされている面はありますが、米国に比べて割合が低くプロダクトベンダの一員として不甲斐なさを感じます。
注目著しいインターネット付随サービスはどうでしょうか。サイト運営やコンテンツ配信などを含む全体の規模では情報サービス業の14%にまで成長してきましたが、「SIerの仕事を奪う」とされているASP業務はソフトウェアプロダクツに比べても0.6%しかなく、まだまだ発展途上だということが数字に出ています。
市場の実態と自社の力量に応じてプラニングする
このような日本のITの実態を見て、「まだ受注ソフトウェアは大丈夫だ」「やっぱりプロダクツやASPも楽じゃない」と考えるのは無理もありません。外野が「ダメだ、ダメだ」と言うのはたやすいですが、経営者は社員の生活と会社を預かっている立場なので、自社の現状と力量に応じた改革案を慎重に考えて行動します。
でも、いつまでも「まだ大丈夫」が続かないことは強く感じています。ならば「稼げているうちに、次の手を打つ」ことにしましょう。日本のIT業界はこのところ景気の良い状態が続いているので、オリンピック前年までの3年スパンで改革の方針を立てるのです。
その具体的な改革の方針としては、以下のようなことです。
(1)常駐・派遣主体のまま問題を解決する
常駐・派遣主体からは変革できませんが、常駐・派遣の課題を次々とクリアして社員にとってもユーザーにとっても満足度の高い優良企業に高めていきます。単なる人出しではない、みんなに愛されるSerの姿はきっとあるはずです。
(2)常駐・派遣主体から請負開発型に転換する
社員が自社内で仕事ができる請負開発主体に転換します。この際、従来ベースの開発だけでなくクラウドベースの開発やBtoC分野への参入、これまでにない仕事内容にも積極的に取り組むことが肝要です。請負開発ノウハウや新分野の知識が不足しているため失敗するリスクもありますが、それを恐れずにチャレンジする勇気が必要です。
(3)常駐・派遣主体からプロダクトやサービスベンダに転換する
請負開発型もレッドオーシャンっぽいので、自社のコアコンピタンスを見つめ直し、時代のニーズに合った製品やサービスを作ります。こうしたプロダクト型の事業は長期戦になるので、3年や5年というスパンで事業を育てていく覚悟が必要となります。
人にはそれぞれ得意不得意があり、力量も違います。これは会社にも言えることなので、一概に理想型を論じずに、それぞれで今の力量に応じた作戦を立てる必要があります。
自社の力量は経営者が一番わかっていますが、時として過小評価していることもあります。今の力量を推し量る洞察と社員の潜在能力を信じる強い心を持って、改革の中期計画とロードマップを書くことからはじめましょう。
次回は、こうした改革ロードマップ作りのための具体的なタスクについて掘り下げていきます。