こんにちは。
今回はSIerのプライムベンダーに求められている役割や生み出している価値についてもう一度整理してみようと思います。
どのような人が企業から必要とされているかや、どのようなキャリアパスとなるかの前提になると思います。
筆者のプロフィールは以下です。
(若者が書いている意見ということを承知の上でお読みください)
筆者のプロフィール
- 日系の大手SIerの新卒2年目
- プライムベンダー(＝一次請け)として仕事をしている
この記事で分かること
- SIerのプライムベンダーの価値を生み出す重要な仕事内容は何か
- SIerの社内でどのような仕事をしている人が偉いか
(→社内での生存戦略、出世するキャリアパス)
SIerのプライムベンダーが生み出す価値と求められること
SIerのプライムベンダー(顧客から発注をする立場)が価値を生み出すために必要なことは以下の3つであると考えてます。
- 顧客のニーズに合った提案をし、仕事を作り出すこと
- 顧客の要求を要件(≒自社がやること)に落とし込むこと
- プロジェクトの期間や費用を正確に見積もること
どれも上流工程です。
顧客のニーズに合った提案をし、自社の仕事を作り出すこと
一次請けとして一番やらなければいけないことは、「受注する」ということです。受注しないことには仕事が生まれません。
システムの受注には、顧客と信頼関係を築いたり、顧客のニーズをくみ取ったり、大規模案件の場合はコンペを行う前に念入りに検討して準備を行ったりすることが必要となります。
コンペの場合は値段勝負になったりしますし、システム更改の場合はベンダーロックインになることもある(ここらへんはまたの機会に詳しく書きます)ので、顧客が「何をしたいか」「どのようなものが必要か」をくみ取るだけでうまくいかないことも多く、色々な戦略が必要となります。
また、仕事を生み出すのはコンペだけの受注とは限りません。
私の今のプロジェクトだと、(システムの更改とは別で)、システム本稼働後にお客さんが業務を行いやすくなるためのツールを提供していますし、もちろん保守のお金もかなりの額をもらっています。
受注からシステム納入までのシステム開発以外でも、それに伴って生まれる仕事をたくさん作ることができます。それを顧客に提案して受け入れてもらうスキルを持つ人が一人でもいると、入ってくるお金が増えますね。
顧客の要求を提供するシステムの要件・設計に落とし込むこと
当たり前ですが、顧客満足度というのは自分たちが求めているものとできたものにどれだけ差があるかによって決まります。
システムの機能に関しては業務の流れに沿っていて使いやすいかどうかが重要ですし、非機能要件だと、それだけシステムが稼働しているか(障害が起こらないか)やレスポンスタイム、問い合わせ対応の受付時間や対応の質などによって評価されます。
顧客が求めている機能やレベルを理解するためのコミュニケーションや、求めていることを実現するシステムを作るべく設計書に落としていくという行為が必要になります。設計については技術面は詳しい方に発注してお願いすることも多いですが、取りまとめて設計書に責任を持ち、顧客と調整するのはプライムベンダーの役割です。
プロジェクトの期間や費用を正確に見積もること
私の会社では「SEは見積もりができて一人前」とはよく言われています。
算出した規模(何キロステップとか)の開発を、決められた期間内に終わるように必要な人数を計算して二次請けにお願いします。この算出した費用に何％かを載せて顧客に提出します。会社としてどれだけ利益を得ることができるかはこの見積もりのスキルにかかっています。
システムの要件に対して必要なプロジェクトの工数を見誤れば、大炎上や赤字を招きます(赤字覚悟で追加人員を投入する必要が生じたり、デスマーチが始まったりするわけです)。
かといって、顧客のお財布事情(予算)を考えないで吹っ掛けても受注ができませんので、機微な加減が重要です。
自分の担当する規模の費用や規模の見積もりができないと顧客への回答も二次請けへの発注もできないため、PMになるには見積もりは必須スキルです。
会社内のエンジニアの力関係【仕事を作る側が偉い】
上記のようなことが求められているSIerの社内の中で、ではどのような仕事をしている人が一番主導権を握っているか(ざっくり言えば社内の力関係)について解説します。
「仕事を作り出せる」人が一番偉い
そこそこ大手のSIerだったら、色々な仕事をしている人がいます。
システムエンジニアの中でも、
- 上記に書いたようなSI案件のPM
- アプリケーションやインフラの技術支援部隊
- 自社/他社パッケージの導入サポート
- プリセールス、PoCの拡販SE/ブリッジSE
- (社内SE)
が存在しますし、システムエンジニア以外にもハードウェアやオフショア会社などの調達部門などがいます。
社内のステークホルダーは数え上げればキリがありません。
(箇条書きで書いたシステムエンジニアの仕事内容については下記で詳しく解説しています。それぞれについて詳しく知りたい方や、やりたい業務があって希望を叶える方法が知りたい方はぜひご覧ください。)
これらの職種の中で、上に述べた通り、顧客のニーズを理解して案件を受注し、開発するシステムの規模や見積もりを行うことが価値が高いです。
もちろん同じ会社内なので協力して仕事をしているのは確かですが、残念ながら現実問題として下記のような力関係が生じているのは確かです。
「社外からお金を持ってこれる部門」＞そうでない部門(一部を援助する専門部隊が多い)
その理由は3つあるので、それぞれ解説していきます。
- ビジネスオーナーとなって指示を出すのは仕事を作る側のため
- 顧客のニーズを理解していない側は見下されるため
- 技術に特化しているだけならより安い単価で二次請けを雇える
①ビジネスオーナーとなって指示を出すのは仕事を作る側のため
これはビジネス全般に言えることだと思いますが、「意思決定できる側」が強いです。
SIer案件で言うと、より上流を押さえている側(＝顧客への提案内容、何を提供するかを決める人)が強いです。
社内の技術支援部隊が必要かどうか、ハードウェアがどれくらい必要か、構築を自分たちでできるかどうかを判断するのは案件のPMです。いくら専門部隊が自分たちの専門性が活かせると訴えても、最終決定権は彼らにはありません。
専門部隊は言われたことをやるだけになってしまいがちです。
②にも通じますが、お客さんと交渉して日々調整力やコミュニケーション力を磨いているSE(顧客に対して提案などを行っているPM)は、めちゃめちゃ交渉が上手く意思決定のプロみたいな人がたまにいます。
私は(ジョブローテーションの都合で)技術部隊側と受注案件のPM側の両方で調整を見たことがありますが、専門部隊側は大体勝てないです。
②顧客のニーズを理解していない側は見下される
顧客と直接やりとりするSEは限られているため、顧客の生の声を日々聞いて交渉している受注案件のPMと、彼らから要件を聞いて、伝聞で必要な技術を考える専門部隊という構図になったり、そうでなくても顧客と対話する能力に差があるのは明らかです。
この場合、残念ながら技術力があって専門部隊だけでは顧客が満足いくものは作れません。
評価の基準は、「アーキテクチャがいけてる」とか「最新技術が導入されてる」とかが本質ではなく、これらはあくまで目的を達成する手段にすぎません。
「顧客の業務に合う作りになっているか」が重要で、この目指すべきゴールを知るには顧客とのコミュニケーションが不可欠です。
結果として、残念ながら顧客と接している側には「我々がお金を持ってこないと専門部隊は仕事がないじゃん」「俺たちがニーズをくみ取ってやらないと良いものが作れないくせに」みたいな意識が多少はびこっています。
ここまで読んで大体お分かりかと思いますが、出世する人は専門部隊よりも受注案件のPM出身の方が多いです。上流を知っていることが重要なのは明らかです。
途中でジョブローテーションで調達部門に数年間行ったりする例があります。
③技術に特化しているだけならより安い単価で二次請けを雇える
ここまでお読みになって、「いや、そうは言っても顧客が求めているものを作るための技術力がなかったら作れないよね！？」と思われている方は多いと思います。
しかし、技術力のある専門部隊は必ずしも社内から調達しなければいけないわけではないです。
技術力だけを求めるのであればより安い単価で二次請けを雇った方がコスパが良いです。SIerのプライムベンダーは高給ですので、人件費が嵩みます。
なんで技術部隊がいるんでしょうね。書いていて私も良く分からなくなってきました。
ハードウェアの調達などの技術以外の専門部隊に関しても、他の会社に外注することは可能ですし、私の会社は外注してもしなくても受注案件のプロジェクトをやっている部署の利益は変わりません。(調達する費用を乗せてお客さんに請求したらその費用は調達している部署に入り、会社としての売り上げは上がります。)
まとめ
このような実態が「技術の空洞化」という問題に繋がるわけですが、SIerの多重下請け構造を考えると最適解なので難しいです。
極論ですが、一丁前にIT企業を名乗るのをやめて、業務支援を提案する人材派遣会社とかって名乗った方がコスト部門を抱えずにスリムな経営になりそうですよね。交渉や調整ができる人材が増えてハッピーな気がしてしまいます。
(技術部隊に配属された私が言うことでもないですが。)
SIer全体の多重下請け構造の話(二次請けとの役割分担)や、プロジェクトの上流～下流の細かい仕事内容は以下の記事に記載しています。
今回の話とはあまり関連性はないですが、技術部隊とPM側の両方を見ている経緯は下記の記事に詳しく書いています。
コメント