以前の記事で、SIerの一次請けは技術力(特定分野の専門知識やコーディング力)は問われない構造であるという話をしました。
今回の記事ではそれを踏まえて、一次請けの詳しい仕事内容をもう少し詳しく解説しながら、大手SIerに向いている人・いない人を私なりに考えてみたいと思います。
(SIerの構造や、役割分担について解説した前回の記事はこちらになります。
仕事内容についてはこちらにも解説しているので、是非ご覧ください。)
SIerを就職先として検討している就活生(特に理系)、IT系に転職したい方などが、すでにある程度実態をご存知かと思いますが、この記事を読んでよりリアルな現場の実態を知った上で自分に合うかどうかを考えて希望してほしいと思います。
※まだ仕事を始めて1年の若造が書くので、下っ端の目線で見た主観であることをご了承ください。
筆者のプロフィール
- 大手のSIerのSE
- 2019年に新卒で上記の会社に入社し、2年目に突入
また、同じく20代から見たSIerの仕事内容として下記のブログも参考になります。
私の職場も概ね同じような構造です。
大手SIerの仕事内容
向いている人・向いていない人の前に、SIerの一次請けの仕事がどんなものか解説してみたいと思います。
ウォーターフォール型の大型システムの受託型開発について、各工程の仕事内容をより詳しく解説していきます。(参考：ウォーターフォールの具体的な開発方法を知りたい方はこちら)
主な仕事内容は、ステイクホルダーとのコミュニケーション
全体を通して、SIerのSEの一次請けの仕事はステイクホルダーとの調整とマネジメント業務です。
ステイクホルダーとの調整は、具体的に以下の人に対し、提案をしたりお伺いを立てたり責任範囲を決めることを指します。
- 顧客
- 社内上層部(プロジェクトを進めていいかのお伺いを立てます)
- 社内他部署
- 同じプロジェクトの上司・先輩・部下
- 開発・運用保守などを発注している子会社
(大規模なシステム開発だとアプリケーション・インフラ・運用保守などで会社を分けて発注を行うため、複数の会社がいることが多いです)
マネジメント業務は、計画書を作ったり見積もりを作ったり発注をしたり進捗管理をしたりなどです。
上流工程は、技術力なことを聞きながら交渉
一次請けは、受注～設計は頑張って行います。
顧客がシステムの構築やリプレイスを行いたいとなると、RFIやRFPを発行します。
それらに対応してコンペに勝つことで受注ができます。
この段階で、プロジェクト全体の検討をしたり、コンペで受注できるように対策をするのは一次請けの役割です(コンペをやるのは主に営業です)。
受注してプロジェクトが始まると、最初に要件定義で顧客の要求をどうシステムに落とし込むかを検討し、その後に構成や仕様を決めていきます。
受注～要件定義では、責任範囲を明確にしたりプロジェクト全体について顧客と合意を取るため、WordやExcelを使ってドキュメントを作ったり、ガントチャートを作ったり、見積もりをしたりします。
それが終わると設計に入ります。必要に応じて二次請けに発注し、技術的なことを聞いたり細かい技術まわりを手伝ってもらいながらシステムの細かい仕様を決めていきます。仕様書を作ったり、発注して作ってもらったものをレビューしながら、顧客と合意を取っていきます。
まとめると、 (全部の工程そうですが) ExcelとWordとPowerPointを使ってドキュメントを作りながらいろんな人と打ち合わせします。IT土方と言われる所以ですね。
どういった前提条件でプロジェクトを行うかを顧客と中々合意が取れなかったり、どういった前提で誰にどんな仕事をお願いするかで揉めたりで中々苦労することはあるかと思いますが、ここで大きく炎上することは(開発や本番稼働後に比べて)ないと思います。ただし、上流工程でうまく仕様を決められないと開発が炎上したり、障害が起こったりしてとんでもない問題になるので、プロジェクトが上手くいくかどうかはここにかかっています。
下流工程は、二次請けに丸投げ
ドキュメントにまとめた合意済の仕様を、システムにするためにプログラムに起こす開発は二次請けに丸投げです。
一次請けがやるのは進捗管理とか、細かい検討事項が出てきたら確認する等などです。
テストは開発よりは少し頑張ります。方針を作り、テストケースが網羅できているかをチェックします。実施は二次請けにやってもらったり、自分たちでやったりです。
また、残念ながら私の会社は未だにテスト工程の進捗はほぼExcelで管理してます。
上流工程が上手くいっていないとここでプロジェクトが炎上します。
コミュニケーションが上手くいっていなかったり見積もりを見誤ると開発が予定より遅れたりしますし、開発のプログラム品質が悪くてバグがいっぱい出てくると頭を悩ませる会議が発生したりします。
本番稼働後に障害が発生すると詰む
以上のような感じで開発が終わり、システムリリースを経て本番稼働が始まります。
(システムリリースは顧客の業務時間外の深夜や土日に行われたりもします。)
大規模な障害が起こらない限りは、運用保守の問い合わせ受付や、決まった手順を行うオペレーター業務は二次請けに発注してやってもらうことが多いです。
稼働後に障害が起こった時が正直一番大変です。
社内の偉い人に根回しをし、顧客のお偉いさんに一緒に謝りに行き、システムの修正をします。
きちんと設計や品質確認ができているシステムなら障害が起こらず、運用保守の問い合わせ対応を運用保守部隊にお願いすれば大丈夫ですが、できていないシステムは安定して稼働せず、様々な種類の障害が次から次へと起こったり、原因が分かっても作りが悪いので他の部分に問題を出さずに修正するのが難しくなったりします。
大規模な基幹システムというのは、往々にして少しでも問題を起こすとかなりまずいものです。業務に影響がある障害が起こった場合は、昼夜問わず障害対応に追われます。
プロジェクト内の人事異動が激しく、誰にでも出来る内容
これは会社によると思いますが、私の会社では一次請け内での人事異動は多いです。
お金がなくなったから人を減らすことがありますし、逆にどうしても回らないので人員補充を行う例もあります。4月や10月には人事異動が結構あります。私もプロジェクトに途中参入しています。
「そんなこと言っても仕様分からないとマネジメントできないでしょ？」と思われるかもしれませんが、結局開発は二次請けに丸投げしており、行うのはコミュニケーションとパワポ・エクセル作成なので属人性は低いです。
(天才的に交渉が上手く、その人が抜けたら誰もお客さんと交渉を行えなくてプロジェクトが回らないみたいな例ももちろんありますが、それとはまた別の話で、システムの仕様を知っているかどうかや技術力の有無が一次請けの仕事に関係ないと言う話です。)
開発を行っている方たちの方が、プログラムに落とせるレベルでより細かく仕様を把握する必要がありますし、「この部分が分かる人誰もいないじゃん！」ということが起こると詰むので、人の入れ替えを行うのが大変そうだなと思います。
向いている人・向いていない人
コミュニケーション・調整が得意な人は向いている
大体結論は見えているかと思いますが、向いている人は下記のような人だと思います。
SIerに向いている人
- 人とコミュニケーションを取るのが得意で、それを仕事にしたい人
- 組織として成果を出す人が好きな人
- 計画を立てて、その通りに実行をするのが好きな人
- 福利厚生が充実している大企業で働きたい人
SIerは何十人、場合によっては百人以上が集まって一つのシステムを作る広大なプロジェクトなので、皆で大きなものを作ることに価値を見出せる人、組織の中で円滑にコミュニケーションが取れる人が向いています。
悪意のある言い方をすれば、「いかに組織の歯車になれるか」が大切です。
また、SEがホワイトかどうかは置いておいて、大企業に入りたいならSEとして応募するのは良いと思います。比較的沢山採用するので。
個人として武器となるスキルを持ちたい人は向いていない
逆に、向いていない人は以下になります。
SIerに向いていない人
- やりたいこと(画像処理とかAIとか)が具体的に決まっている人
- 特定分野の専門性を持っていて、それを活かした仕事がしたい人
- コミュニケーションが苦手な人
- プログラミングがしたい人
SIerのSEは案件ガチャが激しく、さらにその中でもプロジェクトがどのプロセス(要件定義～テスト)をやっているかで仕事内容が全く異なります。自分個人の価値を高めるべく、スペシャリストとしての専門スキルを身に付けたい人は向いていません。
また、理系でコミュニケーションが苦手な方や開発(プログラミング)が好きな人も向いていないと思います。
まとめ
これからの時代、チームで仕事を円滑に行うことができる能力は職種を問わず大切なものだと思います。一方で、SIerは特定分野への専門性は身に付きづらいのかなと思います。
会社をずっと頼りに出来ない時代になりましたし、よく考えてキャリアを積んでいきましょう。
コメント