フロントエンドプロジェクト編

仕事内容

業務内容としてはお客様への業務支援の形でプロジェクトに参画しています。
システム開発というよりマネージメントの業務です。

お客様が実現したいサービスに対して技術的な支援や要求仕様の取りまとめ、開発を依頼する外部ベンダーさんとの仕様詰め、設計書のレビュー、開発スケジュール管理、開発完了後の受入テストを主に行っています。

お客様はシステム開発のプロジェクト運営に関しては知見が薄いこともあり、自分の思ったようにプロジェクトを動かせることができるのが面白いです。

SEとしてのポリシー

役割としてプロジェクト管理をする場面が多いので、技術的なことよりも人を動かすことがあります。
ITとは言え開発するエンジニアは人間なので、間違いやミスはありますし、エンジニアにも個性があります。
やるべき仕事をやらせるのはありますが、それよりも大事にしていることはその人の個性を活かすことを重視しています。
端的に言えばその人のプライドをくすぐるように接しています。
人はやらされ感を感じながら行うことは決して身につかないという言葉を常に思いながら管理をしています。

どんな仕事でも苦しい場面は出ます。
そんな時こそ笑いがあり和やかな雰囲気にすることを心がけています。
（周りからは大変な時に笑っていると訝しげに思われてしまいますが）

SEの１日

某エンジニアがSEになるまで

現在でも同じですが、新人～3年目くらいまでプログラマーとして通信会社のホストコンピューターで開発者として従事していました。
私は何回か転職を経験していますが、SEになる志向が強くプログラマーとして参画していたプロジェクトでは設計者は上流会社が受け持っており、自社はコーディングをする役割分担でした。
そのためSEになるためには転職しかないと思い始め、タイミングよく知り合いから声がかかったこともあり転職をしました。

転職先は設計コンサルタント会社の情報システム部門です。
取引先は地方自治体で当時は公共事業は不景気知らずの流れもあり仕事内容も待遇もよかったです。
その会社では独自のパッケージソフトがあり、自治体ごとの仕様に合わせたカスタマイズ開発やコンサルとして新しい業務システムの開発と提案をしてきました。
相手がお役人なので民間との考え方のギャップを感じるシーンが多々あり、民間は如何に業務効率化を行い費用を減らして利益を上げるかを考えますが、お役人は如何に予算を消化し、かつ自分たちの業務を楽にできるかを考えますが、効率化を目指し過ぎると自分のポジションが無くなるのでやり過ぎは良くないと落としどころを目定めるのは大変でした。
そこで培ったのはお客様のニーズだけでなく、そのニーズの背景や導入後の影響も見据えて提案することが大事であると学び今でもその考えを実践しています。
意外と大事なのは相手の人間性を見極めることも重要だと感じました。
その会社も辞めてしまい転職をしたのですが、それは世の中が不景気になり公共事業の予算も削減をしたため売上が減りました。
その状態でも株主に対して配当金を捻出し、社員の給与、賞与を減らし、リストラまで行い、挙句にはコンサルとして一番大事な新しいソリューションへの投資を止めてしあったことです。
今でも思い出しますが退職願を上司に出し、上司から退職理由を聞かれたときに「会社は経営が傾くとリストラをするけど、社員も会社をリストラしてもいいですよね」と言いましたが、今思うと若かったなぁと感じます。

その後は携帯キャリアでの大規模なシステム更改プロジェクト（年間70億円の予算）にてインタフェイス周りの要件定義担当をし、次に金融プロジェクトにて11年間プロジェクトマネジメント（PMO）をしてきました。
業種としてはお堅いところなので開発スタイルも早さよりも品質と信頼性を重視するところでしたので、現在のフロント寄りのプロジェクトでは早さ重視に馴染めないところはありましたが、利用者目を大事にし他の競合サービスに負けないサービス提供を目指してきました。

SEと言っても今回紹介したマネジメント部分もあれば、システム開発寄りのSE、インフラに特化したSEと様々なスタイルがあります。
SEになるための資格はありませんが、どの種類のSEも共通して言えるのはより物事を俯瞰して見れる、相手のニーズだけでなくそれ以上のニーズや問題点を見つけ出せる資質と素養が必要になります。
その資質と素養を兼ね備えるためには、最初の登竜門としてプログラマーとして様々な開発を手掛ける経験が必要となります。