特集2018.07

IT業界の実態をもっと知ろうSE職場の真実
派遣プログラマー・SEの抱える思いとは?

2018/07/13
ITエンジニアの働き方を改善するには、まずは実態を知り、認識を共有することが大切だ。派遣プログラマー・SEや、ユーザー企業のシステム部門、業務部門のシステム担当など、幅広い仕事を経験し、昨年『SE職場の真実 どんづまりから見上げた空』を出版した赤俊哉さんに話を聞いた。
赤 俊哉 せき としや 1964年生まれ。ソフトハウスでプログラマー、SEとして従事した後、ユーザー企業の情報システム部門に転職。現在は株式会社明治座のIT戦略室室長。著書に『SE職場の真実 どんづまりから見上げた空』(日経BP社)、『システム設計のセオリー』『だまし絵を描かないための─要件定義のセオリー』(リックテレコム)など。

─派遣プログラマー・SE時代に抱えていた思いは?

会社に入って嫌だったのは自分の机が会社になかったことです。派遣先の現場には机が用意されていましたが、派遣先のプロパー社員より環境は当然よくありません。だだっぴろい部屋に机が並べられていて、派遣されたエンジニアたちが押し込まれる感じで作業していました。入社時に思い描いていた働き方とは大きなギャップがありました。

派遣プログラマー・SEの時代は、自分の所属する会社を意識することはほとんどありませんでした。金融機関に派遣された時は、メーカーのSEという肩書きで送り込まれました。当時の営業担当は、私の偽の職歴をつくりました。私の職歴欄には「原発の制御システムを開発した経験がある」と記載されていました。金融とまったく違った分野ならスキルをアピールできると考えたのでしょう。なるべく高い値段で契約するためのうそでした。

私は何もわからないまま現場に派遣されました。でも、ユーザー企業は私にメーカーのSEと同じ役割を期待します。スキルがないのに、わかったふりをするのはものすごいプレッシャーでした。

多重下請けなので私の給料はメーカーSEの給料と当たり前のように違います。同じ役割を求められるのに、「仕事に見合っていない」という思いを常に抱えていました。金銭的な部分と、自分がどの会社の人間かわからないということの不満はとても大きかったですね。

─多重下請けや人月単価のビジネスモデルの問題が指摘されています。

人月単価の高い現場に何人派遣するかで会社の業績は大きく左右されます。当時の営業担当はそうした現場に社員を送り込むことが最優先でした。派遣されるSEはきちんとした教育を受けないまま現場に送り込まれて、「ばれないようにがんばれ」。OJTという都合のいい言葉で、「現場で覚えろ」という実態がありました。

そうすると、派遣された社員は、自分がかかわっている作業がどのように役立っているのか、まったくわからなくなってしまいます。仕事も「やれ」と言われているからやるだけで、受け身になってきます。向上心がなくなり悪い意味でずるくなって、「テストだけ通ればいい」という人もいました。会社に人材を育てる意識があればいいのですが、利益優先で現場をたらい回しにしてしまう。利益は上がるかも知れませんが、本人はスキルを身に付けられません。

私がユーザー企業に転職してからも、そういう事例に接してきました。数次の下請け企業から派遣されたエンジニアです。UIを最初からつくることができず、メンテナンスしかできないと言うのです。メンテナンスの現場をたらい回しにされてきたのでしょう。スキルを身に付ける余裕がないようでした。今もそうした実態はあります。

─人を育てる姿勢がないと厳しいですね。

派遣された現場の運・不運はあります。技術を身に付けることができ、人間関係の良い現場もあります。でも、運が悪いとスキルを身に付けられないまま、現場をたらい回しにされてしまいます。

そうした会社で今働いているのであれば、早く辞めた方がいいと私は思います。今の時代、インターネットなどで情報を得やすくなっていますし、チャンスはたくさんあります。

下請けの企業にとっても「御用聞き」だけでは、これからの時代、厳しくなってきます。何らかの得意分野をつくれないときついでしょう。ただ、技術者派遣で成功体験があると方向転換をするのは難しいのかもしれません。人月契約での派遣は安定した利益を得ることができますから。

─こうした問題点に対してどう対処していくべきでしょうか。

下請け企業から業界を変えるのは難しいです。仕事があって、利益が出ればどうしても受けてしまうので。その意味で、業界を変えるとすれば、上流工程から開発の体制自体を効率化する必要があると思います。

今の開発体制はやはり非効率です。日本のIT企業の利益率は他国に比べてとても低いです。非効率にした方が利益の出る現実もあるからです。

業務要件とシステム要件がしっかりしていれば、シンプルでつくりやすい仕組みができます。でも、現実には要件定義があいまいなままつくり出してしまうケースが多いです。開発工程でも、そういう上流工程の成果物を元に作業するので仕組みがどんどん複雑になって、結果として労力がかかります。

こうした流れを断ち切るためには、上流工程をしっかり押さえることが大切だと思います。そのために要件定義に関する本も書きました。

要件定義で一番大切なのはコミュニケーションです。システムにかかわる、さまざまなステークホルダーの人たちが「わかる表現」で合意を得られる要件を固めることが重要です。専門用語などを使ってわかったつもりになってシステムをつくると失敗します。一生懸命システムをつくって、テスト段階で「こんなものは使えない」と言われるのが、現場の人間にとって一番こたえます。業務用語やシステム用語だけではなく、共通のわかりやすい表現で要件を固めるべきです。私の場合、それはデータモデルとプロセスモデルです。プロジェクト全体で何をしようとしているのかという意思を、プロジェクトに参加するメンバー全員に伝えることも大切です。自分の作業が何の役に立っているのかがわかれば、モチベーションも上がります。

─産業の魅力を向上させるには?

派遣プログラマー・SE時代に一番つらかったのは、一人の人間として見られていないと感じたことでした。仕入れ商品のように売り出され、貸し出される。その対象でしかないのかなと感じたことがありました。また、どんなにがんばっても、企業規模間の階層を抜け出せないと感じたこともショックでした。

小さい会社でも請負の仕事を受注して、スペシャリストの体制をつくっていくことが必要です。そうしなければ今後、人は集まらないと思います。

情報サービス産業は、なくなることはないし、これから確実に面白い産業です。私が今20代だったらもう1回ITの仕事を選びます。今、下請けの企業にいて、レガシーのシステムにかかわっていても数年間なら損にはなりませんが、10年間も同じ仕事をさせられるのであれば、転職を考えた方がいいと思います。今はそのチャンスがあります。

産業別の労働組合が働く人のスキルアップを支援できるのなら、とてもいいと思います。もっと幅広い人材がIT業界に入ってくるための職業訓練もあったらいいと思います。

特集 2018.07IT業界の実態をもっと知ろう
トピックス
巻頭言
常見陽平のはたらく道
ビストロパパレシピ
渋谷龍一のドラゴンノート
バックナンバー