はじめに
ITエンジニアとして働き始めて、気づけば7年が経ちました。
本記事では、「あのとき知っておけばよかった」と感じていることをまとめています。
なお、この記事について、あらかじめ次の点をご理解ください。
- 技術的なノウハウではなく、ビジネスや業務構造に関する話が中心です
- 筆者は事業会社所属ではないため、認識に偏りがある可能性があります
- 本記事では、技術トレンドについては扱いません
本記事は、IT業界に入って数年が経ち、「なんとなく違和感」を感じ始めたエンジニアに向けて書いています。
※本記事は、特定の契約形態や働き方を否定するものではありません。
あくまで筆者自身の経験をもとにした一つの見方として読んでいただければ幸いです。
技術以前に、業界のビジネスモデルを知れ
IT業界では、次のような言葉をよく耳にします。
- SIer
- SES
- 派遣ビジネス
これらの違いを、きちんと説明できるでしょうか。
私自身、業界に入ったばかりの頃は、
SIerは一次受け・二次受けがあって、
SESは派遣みたいなもので……
といった、かなり曖昧な理解でした。
実際には、
- SIer・SES・派遣を兼業している企業もあれば
- 特定の形態に特化している企業もあります
そのため、「この会社は〇〇だ」と一言で判断するのは危険です。
会社ごとにビジネスモデルが異なる、という認識が重要だと感じています。
一般的な契約構造上の傾向として、
業務リスクは
SIer ＞ SES ＞ 派遣
と整理されることが多いと感じています
（※あくまで筆者の経験に基づく整理です）。
ビジネスである以上、法的・金銭的なリスクは避けられません。
経験の浅いエンジニアを、いきなり高リスクな業務に投入するよりも、
- 比較的リスクの低い業務から経験を積ませ
- 段階的に責任の重い業務を任せる
こうした判断は、経営上は合理的な選択だと感じています。
契約を理解しろ（請負・派遣・SES）
ITエンジニアは、主に次の3つの契約形態と関わることになります。
請負契約
請負契約は、開発やテストなど成果物が明確な工程で用いられます。
- 要件定義や仕様が明確であること
- 決められた成果を、納期内・予算内で納めること
が求められます。
要件を満たさない場合、
契約上のトラブルに発展する可能性もあります。
そのため、納期遵守が強く求められ、
必要に応じて人員追加などの調整が行われるケースもあります。
派遣契約
派遣契約は、雇用側にとって比較的リスクが低く、
小規模でも始めやすいビジネスモデルです。
原則、成果物に対する責任を負いません。
業務範囲が比較的限定されるケースも多く、
結果として経験の浅いエンジニアがアサインされる場面を見かけることもあります。
私自身は、契約関係への理解が十分でない相手から、
戸惑うような要求を受けた経験がありました。
SES（準委任契約）
SES（準委任契約）は、
- 要件定義
- 設計
- コンサルティング業務
など、成果物がまだ明確でない段階で用いられることが多い契約形態です。
成果物そのものではなく、
業務遂行に対して一定の責任を負う点が特徴です。
契約内容の認識違いがあると、
トラブルに発展する可能性もゼロではありません。
そのため、業務内容や責任範囲を意識しながら働く姿勢が重要だと感じています。
人間関係には気をつけろ（情報は意外と近い）
一般に、転職すれば人間関係はリセットされると言われます。
しかし、業界や地域によっては、
思っている以上に人のつながりが近いと感じる場面があります。
私自身、
「前の会社のこと、だいたい知ってるよ」
と、やんわり言われた経験がありました。
良くも悪くも、業界は狭い。
日頃の立ち振る舞いや発言は、
思っている以上に見られている可能性があると感じています。
EDINETを見てみること
ビジネスについて理解を深めたい方には、EDINETをおすすめします。
EDINETには、金融商品取引法が適用される
上場企業の決算情報が掲載されています。
転職サイトや企業HPには、
- 強み
- ポジティブな情報
が中心に載っています。
一方、EDINETでは、
- ビジネス上のリスク
- 経営上の課題
- 直近の経営状態
- 従業員数の増減
といった情報も確認できます。
何から見ればよいかわからない場合は、
自分の関心分野でトップシェアの企業から見るのがおすすめです。
私たちエンジニアも、
「労働者」という視点だけでなく、
雇用する側は何を見ているのかを知ることは重要だと感じています。
IR情報は「企業の考え方」が見えやすい
「自分の会社は上場していないから関係ない」という方も、
自社HPのIR 投資家向け情報を一度確認してみてください。
企業が、
- どんなリスクを認識しているのか
- 何を課題として捉えているのか
といった点が、比較的率直に書かれていることが多いです。
まとめ
私たちエンジニアは、ビジネスの中で仕事をしているという意識を持つことが大切だと思います。
技術力の高いエンジニアは、確かに尊敬されます。
しかし、その人が必ずしも一番稼いでいるとは限りません。
私は、
良く言えば「経験」、
悪く言えば「遠回り」を通して、これらを学びました。
皆さんが、同じ轍を踏む必要はありません。
- 自分はどんな契約で
- どんなビジネスモデルの上で
- どんな立場で仕事をしているのか
一度立ち止まって考えるきっかけになれば幸いです。
参考書籍
財務会計講義（桜井 久勝）
会計の基礎が、450ページほど（第26版時点）でまとめられた良書です。
EDINETと併せて、気になる章から拾い読みするのもおすすめです。
ITエンジニアのやさしい法律（河瀬 季）
エンジニアに関わる契約や法律が、平易な言葉で解説されています。
特に、業務系エンジニアや経験の浅い方には、一読をおすすめします。
EDINET
金融庁が管理しているサイト。
上場企業の有価証券報告書が閲覧できるサイトです。
Googleで「EDINET」と検索してみてください。