オリエンタルインフォーメイションサービス、代表の大内と申します。弊社は神奈川のみなとみらいでシステム開発業を営む会社です。
とはいえ、受託開発のシステム会社が何を広報するのか、不思議に思う方もいるでしょう。
ご指摘は全くそのとおりです。我々のビジネスは完全にBtoBであり、記事が読まれたからお客さんが増える、という性格の事業ではありません。
ですから、私が今回広報活動をやりたい、と思った理由は他にあります。それは「システムエンジニアの地位を向上させたい」と思ったからです。
驚くほど多くの会社がコンピュータを用いて仕事を行い、世の中の主要な仕組みはコンピューターソフトウェアなしには運営すら難しい状況の現在ですが、「それを作る人々」の苦労はあまり見えません。
もちろん多くのエンジニアは「それでも良い」と黒子に徹している方々です。謙虚な方が多いと言えるでしょう。
ですが、私は彼らのやっていることをもっと世の中に発信していくべきと考えています。
そうすることで、
・エンジニアとの付き合い方
・エンジニアがなぜこのようなことを言うのか
など多くの点で「システムを利用する人たち」との相互理解が深まり、ひいては「システムエンジニアの地位向上」につながるのではないかと考えています。
さて、そういうわけで少し話をしたいのですが、一回目はエンジニアを取り巻く究極の課題の1つである「なぜエンジニアの労働環境が悪くなりがちなのか」について考察したいと思います。
ここで言う労働環境は、労働時間であったり、賃金であったりという衛生要因的な側面、もっと言えば「エンジニアを取り巻く構造的な問題」です。
その前段としてまず皆さんにお知らせをしなければならないのは
「ソフトウェアを作ることは、大変に手間がかかる」
という事実でしょう。
一昔前は「ソフトに金をかけるなんてバカバカしい」という風潮もありました。また、業界の内部をあまりご存じない方は
「設備も要らず、コンピュータの前に座ってキーを打つだけの仕事の、一体何に手間がかかるのか」
と不思議に思う方もいるでしょう。
もちろん、キーを打つだけの仕事であれば手間はかかりません。ですが、システム開発はもちろん、そんな仕事ではありません。
我々の仕事の本質は「思考の具現化」です。
例えば、弊社の仕事の1つに「電子書籍システム」があります。
（写真は、電子書籍システムチームのリーダー、内野です）
この仕事、お客さんからの要求は「システムが遅いので、動作を早くしてくれ」という注文でした。
と言っても「早くする」のはそう簡単ではありません。
彼はお客さんと話し、まず「何が遅い原因か」「どう直せば早くなるか」について、丹念にやるべきことを定義しなければなりません。
その上で、実際にコンピュータへの一連の命令を、コンピューター言語を用いてソフトウェアという形で丁寧に一つ一つ組み上げています。
システム会社にソフトウェアを発注したことのある方ならわかると思いますが、お客さんは、作りたいソフトウェアを非常に曖昧な形で我々に伝えます。
その要求を一つ一つを、コンピュータが扱える形にして計算させ、お客さんの望む形にアウトプットする。それが我々の仕事です。
それはもしかしたら「文章を書くこと」に似ているかもしれません。
例えば「報告書を書こう」とする時、いきなり文章を書くことはできません。頭のなかでもやもやしている何かを言葉として定義し、それを分の中に配置し、読める形にして文をアウトプットする。
これは大変、手間のかかる仕事です。
しかしながら、このように手間のかかる、丹精込めた仕事をしていても、エンジニアたちが置かれている状況は全体としてあまり良いとはいえないかもしれません。
例えばこの業界の中小企業では残業が月に数十時間はあたりまえで、百時間ある会社も珍しくありません。
また大変遺憾に思うのですが、「残業代をきちんと出さない」会社も多いのです。
それはなぜでしょうか。端的に言えば、それは「業界のピラミッド構造」に起因します。
具体的に言えば、大手のSIerの下には、10人から20人の小規模な開発会社が1000社以上もぶら下がっており、彼らはほとんどの場合「以前から付き合いのあった特定の顧客、例えば大手のSIer（システムインテグレータ）からの仕事で食べている」のです。
ご存じの方も多いと思いますが、これは建設業にもよく見られる構造です。
まずは最終的なシステムのユーザーである「エンドユーザー企業」がいて、それを「大手のSIerが受託」します。
大手のSIerは、その仕事を一次請けの開発会社に流し、一次請けは孫請けの開発会社に流す……。それが業界のピラミッド構造です。
下請けビジネスは確かに、開発会社に安定的な収入をもたらします。
例えば、社員を一人雇い、その方をSIerに月に数十万円で派遣すれば、管理費を除いた差額が、安定的に利益になるのですから、このビジネスを最初に考えた人は素晴らしく優れたビジネスモデルを生み出したと言っても良いと思います。
ですが、その代償はそれなりに大きなものになります。
「発注者の指揮命令によりやらざるを得ない」場合が多いのです。
例えばピラミッド構造の最上部にいる大手のSIerとの契約の形態は、単純化すれば以下のようなものです。
◯一人のエンジニアを一ヶ月、大手SIerに常駐させると、稼働が140時間〜180時間の間であれば、×万円をSIerは下請けに支払う
◯×万円から、時間単価✕時間数の金額を、稼働が180時間を超えた場合はプラスして、140時間に達しない場合はマイナスして支払う
こう言った契約を、下請けの開発会社とSIerは取り交わします。
見て分かる通り、大手のSIerは、派遣されてきたエンジニアを180時間までは固定の費用で稼働させることができます。
多くの企業で、残業なしの労働時間は約155時間ですから、25時間は残業させてもSIerが下請けに支払う金額は変わりません。
問題はこの25時間の残業代はだれが持つのか？という話です。
本来、割増の残業代を払うのは派遣元の開発会社です。しかし小さな開発会社は残業代を支払ってしまうと、ほとんど手元に利益が残りません。
そこでエンジニアに言います。
「いま、あなたがもらっている給料には、最初から25時間分の残業代が含まれていますよ」
これが「固定残業代」の仕組みです。
ですが、これはあまり良い仕組みとはいえません。
なぜなら、SIer側にも開発会社側にも「残業を抑制しよう」というインセンティブが働きにくくなるからです。本来会社が取らなくてはならないリスクを、個人が引き受けることになってしまう。
だれが悪いわけでもないのですが、このような「構造的な問題」が、この業界の中小の開発会社の課題です。
では、この構造的な問題を打破することはできるのでしょうか。
結論から言うと、私はできると考えていますし、それが中小のシステム開発会社の責任だと考えます。
しかし、それは多くの中小の開発会社にとってあまり心地よい道とはいえません。
つまり「安定した下請けビジネス」を捨て、ピラミッドの上部、すなわち「エンドユーザー企業」と直接取引をすることを目指さなければならないからです。
そして、そのために必要なのは
・マーケティング力
・営業力
・プロジェクトマネジメント力
の3つです。
中小の開発会社に、エンドユーザ企業から興味を持ってもらうべく、きちんとマーケティング活動を行うこと。
お声がけいただいたユーザ企業へきちんとした営業活動、提案活動を行い、仕事をもらうこと。
そして、頂いた仕事を品質高く遂行すること。この３つを中小の開発会社は強化していく必要があります。
弊社は10年前から「エンジニアの地位向上」を目指してこの取組を始め、現在では6割以上の会社が「エンドユーザ企業」との取引とすることに成功しました。
こちらについては次回以降の記事にて書いていきたいと思います。
【お知らせ】Books&Appsでは、企業の広報活動を支援するサービスを行っています。ご興味のある方はこちらからご連絡ください。
