SIerの時代のおはなし(メイン)と社内SEのおはなし(サブ)

どうも、バーチー熊野です。

 

時々、ふと前職のSIerでのことを思い出します。

私の社会人生活の原点なので、

良くも悪くもSIer基準での考え方が元になっています。

 

そんなSIer時代のエピソードを紹介します。

 

私の所属していたSIerは、

SIer業界で売り上げランキング一桁の会社でしたので、

良くも悪くも大きい会社でした。

 

ですので、規則がしっかりとしていて、

色々な制約で雁字搦めにされていました。

良い部分も悪い部分もありましたね。

 

と、少し横道に逸れましたね。

 

要件定義から入る案件が多くあったので、

ITコンサルに近いSEという働き方でした。

新卒で配属されたチームで任された仕事は、

大規模の要件定義案件でした。

 

お客さんの会社のビジネスモデルを知らないのに、

要件定義から入っていくのは、

なかなか難しかったです。

 

その分、お客さんのシステムについては

とても詳しくなりました。

お客さんの会社で、

異動してきたばかりの人に

こちらが指導する、みたいな。

指導料は含まれていないんですけど、

と思いながら教えていましたね。

 

社内SEなんですけど、

自分の会社のシステムを把握していなかったり、

IT知識が足りなかったりすると、

ベンダーの言いなりになるしかありませんので、

そこは注意してくださいね。

ひどいベンダーはお客さんを舐め腐っていて、

ぼったくりに近い額をふっかけたりしますからね。

 

そうならないためには、

日々勉強あるのみです。

 

私の場合は、

長く会社にいる人に

よく話を聞きに行っています。

会社のビジネスモデルに詳しい人や、

会社の営業に詳しい人や、

会社のシステムのことに詳しい人。

それぞれ得意な分野が分かれているので、

分野ごとの詳しい人を把握して、

仲良くなっておくと、

会社内のことは詳しくなれます。

 

とはいえ、

社内SEはITに詳しい人なので、

ITの知識は負けちゃダメですよ！

 

また話がそれちゃいましたね。

 

私は要件定義が初の仕事でしたよ、とお話ししていましたね。

次に、1度だけ基本設計からリリースまでを通しで経験し、

その後は要件定義や基本設計、結合テストを担当していました。

一番やっていた仕事は案件の管理ですね。

プロジェクトリーダーという役割でしたが、

プロジェクトマネージャーは名前だけだったので、

実質プロジェクトマネージャーでした。

 

案件に入る前に、

開発の概要を定義して、

スケジュールを引きます。

 

次に開発の内容やスケジュールを元に、

基本設計の見積もりを出します。

 

開発の概要と見積もりでお客さんと合意をとり、

基本設計を進めていきます。

 

基本設計を進めるうえで、

詳細設計以降の見積もりを作ります。

その見積もりが、

作業内容を細かく設定していたので、

見積もりを作る段階で、

WBSが完成している感じでした。

 

で、その後はWBSを元に、

下請けのSEさんを管理していく感じです。

管理しつつ、品質を担保しつつですね。

 

お客さんと下請けのSEさんと上司に挟まれながら

案件を炎上しないように進めていく仕事でした。

 

そのおかげで、

しっかりとした開発の進め方と、

品質を担保するレビューの仕方などを

学べましたね。

 

社内SEは、

要件定義をしてあとは投げっぱなしではなく、

レビューやテストで品質を担保する責任があるので、

今の糧になっています。

 

ではでは、今日はこの辺で！