上流工程SEとは?やりがい?つまらない?30代女現職が暴露!未経験転職は?

上流工程のシステムエンジニアとして都内で働いている30代女性です。上流SEとはどんな仕事なのか、どういう経緯でこの仕事をすることになったのか、紹介します。未経験の方が転職してなることができるかについても論じます。

自分の力は試したい！でもこだわりがなかった就職活動

そこそこ名前が知られている大学を卒業しましたが、情報系を専攻していたわけでもなく、エンジニア志望でもありませんでしたが、その時々の関心事に向き合った結果、今の仕事をすることになっています。

話は就職活動まで遡ります。経済学部ということもあり、先輩や同級生たちは銀行や証券会社など金融系を志望している人が多く、絶対に転勤したくないということで、総合職ではなく一般職志望の人も少なくない状況でした。

そんな中で私は、確かに転勤が多いのは大変だろうけれど、せっかく働くなら自分の力を試してみたいという気持ちがあったため、転勤があったとしても転勤族ほどにはならないだろうと考え、メーカーやSIerを中心にエントリーすることにしました。この条件であれば、メーカーやSler以外も候補に挙がりますが、文系採用人数の多さを考慮したり、営業職採用＝転勤多い可能性あり！？を除いたりしたら、たまたまメーカーやSlerが残りました。
仕事内容にはこだわりはなく、働く環境を重視したらそうなったという感じです。

無事にメーカーから内定をいただき、配属されたのが社内で使うシステムを開発、運用、保守している部門でした。こうして、社会人生活をたまたまエンジニアとしてスタートさせることになりました。

ざっくり説明！ウォーターフォール手法って？

エンジニアの話をする前にシステム開発について少し説明します。様々な手法があるので、ここでは日本でよく使われてきたウォーターフォール手法という手法に基づいて、簡単に説明したいと思います。

まず、「システム」という言葉について。言葉は、みなさん聞いたことがあると思います。ここからの話では、「システム」という言葉を、「ある目的を達成するために、ITを使って構築した仕組み」という意味で使います。Webサイトでクレジットカード決済をできるようにするのもシステムですし、ドリンクバーで好きな飲みもののボタンを押したらそれが出てくる、ミルク残量を確認して、ミルクが少なくなってきたら補充メッセージを出す、それもシステムです。

システムを作りたい！という場合には、大まかに次のような段階を経ることになります。

※この①～⑥は後からも出てきますので、覚えていてください。

上から下へ水が流れるように、逆戻りせずに①～⑥の段階を進めるので、この手法をウォーターフォールと呼びます。どのようなシステムをどのように作るのかを決めるまで②③を上流、実際に作る部分④⑤を下流と表します。

ちなみに、これらを社内で使うシステムのために行うのが社内SE、販売するシステムのために行うのがSIerのSEです。お客様が社内なのか社外なのかという違いがあります。

会社によって、社内で①～⑥すべてを行う場合もあれば、①だけを社内で行い、②以降をSIerに発注する場合などもあり、社内SEと一口に言っても会社によって、プロジェクトによって扱う範囲が異なります。

システム開発って、誰が何をするの？

次に、前述の①～⑥について、それぞれどのような役割の人が携わるのかを説明したいと思います。

①企画	システムオーナー(発注者)
②要件定義	上流エンジニア
③設計	上流エンジニア・下流/開発エンジニア
④実装	下流/開発エンジニア
⑤テスト	下流/開発エンジニア
⑥運用	運用エンジニア

上流エンジニア、下流エンジニアという呼び方は、先ほど説明したウォーターフォール手法でいう水の流れの上流部分を担当するエンジニアか、下流部分を担当するエンジニアかということに由来しています。

単に担当部分を表したもので、能力として上流が優等、下流が劣等という意味ではありませんので、注意してください。

私が現在担当しているのは、②、③の部分になります。

ただし、大規模なプロジェクト、システム開発に十分お金がかけられるプロジェクトでは上記のように役割ごとにエンジニアが存在しますが、中小企業でシステム部門に数人しか在籍しておらず、お金をかけずに社内リソースのみでシステム開発しなくてはならない、という場合には、②～⑥は同じメンバーが手がけることがある、というのはよく聞く話です。

エンジニアは最新技術の勉強などをし続ける必要性があるということもあって、自主勉強会などがよく開催されています。connpassなどIT系勉強会告知に特化したサイトなどもあり、私も興味に合わせて参加することが時々あります。大体、誰かの会社の会議室をお借りすることが多いのですが、勉強会後に宅配ピザや缶ビールなどを囲んで、ざっくばらんに色々話します。

そうすると、「予算が限られていて、外注できないので、全部自分たちで行わないといけない」、「他の業務もやりながら、システム開発をしないといけなくて、時間も人も足らず、外注ベンダーの比較検討、説明する時間すら確保が難しく、納期が迫り自分たちでやることになってしまう」と言ったリアルな声を聞いたりします。

システム開発の流れ、各段階でどのような役割の人が携わるのか分かったところで、上流エンジニアの仕事内容についての説明に入ります。
※番号は前述の①～⑥に対応しています

上流エンジニアの仕事その１～どんなシステムを作りたいのか？情報を引き出す～

②要件定義についての説明です。システムオーナー(発注者)から、どのようなシステムを作りたいのかヒアリングをすることです。

システムオーナーとは、例えば社内向け会計システムを作ってほしいと言っている部署の人など、システム開発を依頼した人のことです。

このシステムオーナーは、企画書やそれに準ずるものを作成しますが、システム目線だと突っ込みどころが満載なことがほとんどです。例えば、「マイページがあって、ログインすると○○ができる！」とは言うものの、そもそも会員登録を行う機能について忘れ去られていたり等です。

そこで、システムオーナーにヒアリングを行い、実現したいことを体系立てて考えつつ、システム化する際に必要な情報を集めます。

ヒアリングの方法は様々です。システムオーナーが同じビル内で働いている場合は会議室で対面で行いますが、別の場所で働いている場合は、移動時間がもったいないので、テレビ会議でヒアリングすることもあります。

参加者は、経理部などシステムオーナー側2～3人、システム部門(私たち)側2～3人といったところです。システムオーナー側の出席者は、その業務を担当している人、システムオーナーで、システムオーナーは業務を担当している人の上司である場合が多いです。

ヒアリング回数は、システムの規模にもよりますが、1週間に1回くらい、1～2時間くらい行います。大規模なシステムだと、機能ごとにヒアリングし、全機能のヒアリングを聞き終わるまでに2ヶ月くらいかかることもあります。小規模なものであれば、1、２回でヒアリング終了です。

ヒアリング内容をシステム部門でまとめ、それをシステムオーナー側に確認してもらい、イメージと違うところなどを指摘してもらいます。確認後、システム部門で修正し、再度確認、、を数回繰り返し、要件定義をまとめた「要件定義書」というドキュメントを作成します。私の場合、Wordで作成しています。

例えば、

・利用ユーザーは何人くらいを想定していますか？同時に何人くらいが使うと予想していますか？

→データベースの大きさや処理速度に関わってきます。

どういうことかと言うと、ユーザー数が100人くらいだと見込んでデータベースの構築した場合、実はユーザー数が100,000人だった！となると、処理能力を越えてしまって、遅くなってしまい利便性が低下したり、最悪、サーバーがダウンしてしまうということが考えらます。(通販サイトで人気商品の販売時にアクセスが集中してサーバーダウンしてしまうのをイメージしてもらえれば良いと思います)

・ユーザーの権限は、どのようなものを考えていますか？

→簡単に言うと、システムを使う人の役割の種類と、各役割の担当は何か？を明確にする、ということです。

少なくとも管理ユーザーと一般ユーザーの2タイプはあると考えられます。管理ユーザーというのは、そのシステム全体の設定を変えたり、再起動する権限があったりなど、システム全体に関わる機能も含めて全ての機能が使える人で、そのシステムの運用に責任が持てるごく少数のユーザーのことです。一般ユーザーはシステム全体に関わる機能「以外」の機能のみが使えるユーザーのことです。

一般ユーザーでも使える機能や見える機能を人によって制限するのか、何か重要な処理はシステム上で上司の承認が必要なのか等を把握する必要があります。
画面や機能を制御する機能の有無、承認フローの設計有無等に関わってきます。

・サービスが使えるのはパソコン？タブレット？スマホ？全て？

→ブラウザから使用するシステムの場合は、設計やテストのために予めサービスが使われる環境を定めておく必要があります。また、画面デザインなどをPC向けにするのか、スマホ向けにするのか、ブラウザサイズに合わせて流動的に対応できるよう複数準備するのかに関わってきます。

ブラウザとは、パソコンだとInternet ExplorerやEdge、Chrome、タブレットだとSafariなどのことです。これらは、どれでも同じように見える/使えると感じるかもしれませんが、実は細かい仕様は異なっているため、同じように見える/使えるために個別の対応をしたりしています。そのため、どの環境で使えるのかを予め明確にすることが重要です。

・どのくらいの可用性(システムが継続できる割合)を求めますか？

→システムの構成や運用体制に関わってきます。

システムには、最悪決まった時間だけ動いていればよいもの、24時間365日絶対に不具合が発生してはいけないものなど、止まらずに動き続けることにどれだけの必要性があるかが異なります。

例えば、社内でのみ使っているシステムなら、使っている時間帯のみ動いていれば良いですが、時間に関わらず利用できることが望まれるもの、通販サイトやガス、電気提供システム、24時間営業コンビニの会計システムなどは24時間365日動いている必要がありますよね。

24時間365日必要なシステムは、万一不具合発生した場合でもシステム継続できるように、常にデータバックアップ(複製)を取っておいたり、すぐに切り替え可能な環境を作っておく必要がありますし、夜中でも必ず誰かに連絡がついて対応してもらえるような運用体制をつくる必要があるためです。(この対応をするのが⑥運用エンジニアです)

話が運用エンジニアのことに少し逸れますが、私は夜中に対応したりといった対応をしたことはなく、運用エンジニアに依頼したことがある程度ですが、契約内容としては、「夜中でも常に電話出られる状態にしておくこと」「要請があったら○時間以内に出社して対応すること」等となっています。

実際、夜中に出社しなければいけない不具合が発生することは滅多にありませんが、運用エンジニアの方に話を聞くと、チーム内で対応当番を決め、当番日は電話に必ず気付く必要があるので仮眠程度になってしまうということで、なかなか過酷だなと感じた記憶があります。

要件定義のイメージが沸いたでしょうか？

システム開発というと、どんなことができて...と機能面を思い浮かべる人が多いかもしれませんし、確かにそれもシステム開発の一部なのですが、このように見えない部分でも考えなくてはならないことが沢山あります。ITに通じていないと、なかなか出てこない内容もあるため、上流エンジニアがそれを引き出します。

上流エンジニアの仕事その2～システムをどのように実現するかざっくり考える～

③設計部分の説明に入ります。

必要な情報を収集できたら、②運用設計で作成した要件定義書を元に設計書を作成します。こちらも私はWordで作成しています。

この部分は、要件定義書を元に下流エンジニアがたたき台を作って、それを上流エンジニアがレビューしながら決めていくこともありますし、現在の私の仕事では、最初のたたき台を私(上流エンジニア)が作成し、それを元に下流エンジニアが具体化し、更にそれをレビューするという方法をとっています。

下流エンジニアのたたき台は、Wordだったり、メモ帳(txt)だったり様々ですが、内容が把握できれば良いので、私はそこはこだわっていません。私の場合、下流エンジニアはグループ会社のエンジニアが担っています。表に出てやりとりしているのは2,3人ですが、チームとしては20人くらいいるようです。オフィスは別ですが、Web会議も含めてよく打ち合わせで顔を合わせているので、人柄も良く知っておりコミュニケーションは問題なく取れています。

設計とは主に以下の3つに分類できます。

画面設計

必要な機能をスムーズに満たすためには、何の用途の画面がいくつ必要なのか、画面間のつながり、画面の大まかなレイアウトなどについてまとめます。

例えば、「上司への処理実行承認依頼ボタンを押すと、上司が承認できる状態になり、上司が承認すると処理が開始される」という機能があったとします。

その時必要な画面と画面間のつながりは、

A承認者は誰か登録する画面→B処理の承認依頼をする画面→C上司が承認する画面→D上司が承認したかを確認する画面→E処理の実行状況を確認する画面

となります。

最大で5つ画面が必要になりますが、この場合、BDEは使う人が同じ、ある1つの処理の状況を確認するという意味では目的は同じなので、1つの画面で行えるようにすることが多いです。そうなると、必要な画面は3つということになります。

機能設計

画面上で行ったことの裏側の処理について考えます。

みなさんがシステムやアプリを使う際は、画面上で見えるところに注目していると思いますが、裏では様々な処理が動いています。例えば、何か行った時にエラーメッセージが出るのは、裏側で予め定めたチェック処理を行い、このまま次に進んではいなけいという判断を行っているからできることで、このようにいわゆる"プログラミング"された色んな仕組みが裏では動います。

前述の承認機能の例でいうと、
B処理の承認依頼をする画面：「承認依頼する」という言葉の裏には、依頼する時点で承認者が既に登録されていていることを確認する、依頼すると承認者が承認するにあって必要な情報を見られるようになる、といった内容が含まれています。

各機能において、処理内で実現しなければならないことを洗い出していきます。

データ設計

処理をする際には、どんなデータが必要なのか、どのようにデータ同士を連携させるのかについて考えます。システムには色々な情報が保存されています。何かのサービスに会員登録する際、名前や生年月日、メールアドレスなどを入力しますよね。そういった情報のことをデータと言います。

前述の承認機能の例でいうと、

ユーザー情報	社員ID、名前
承認情報	承認依頼者の社員ID、承認者の社員ID
処理情報	処理番号、承認依頼者の社員ID、承認状況、処理状況

などです。

例えば、承認者として登録されている人が退社し、ユーザー情報から削除したのに、承認情報の方にはまだデータが残っていて、承認依頼が出されてしまったら、誰も承認できない依頼が発生してしまいますよね。そういうことにならないように、この段階で、「承認情報の中に社員IDがない場合のみユーザー情報から削除できる」等のルールを決めておきます。

このあたりは、システム開発の経験がない方には少し難しかったかもしれません。

必須資格はなし！ただし、ヒアリング能力は必要

仕事内容を読んで、どのようなことをしているのか、大体イメージがついたと思います。

上流エンジニアとして働くためには、②要件定義段階では、システムオーナーからいかに情報を集められるかが重要になります。そのためには、じっくり相手の話を聞けること、相手が分かる言葉に置き換えて説明できることが大切です。システムオーナーは、その業務においてはプロですが、ITに疎いこともしばしばありますので、相手に合わせて話せる必要があります。

私はもともと、自分が話したいというより相手の話を聞きたいタイプで、自分が目立ちたい！話したい！というよりも人の話をじっくり聞く方が好きなので、この辺りは性に合っていると思っています。小さいころから、自分から人前に出て話すことは少なく、いるのかいないのか分からない子だと言われていました。

そのため、最新技術を追いかけてアレコレやってみたい！というタイプの人には、仕事内容でも書いたような質問内容に相手がすぐ答えられず、それ以前になぜその質問をする必要があるのかといったところから説明しなくてはならない状況は、じれったく感じるかもしれません。

同僚がまさにそのタイプで、試してみたい新しい技術の提案をしても、相手は「それ何ですか？よく分かりません。とにかく××だけできればいいんです。」と言った感じだったため、自分の興味と仕事内容がずれていて、フラストレーションが溜まっていたようでした。

大切なのは「相手が何を必要としているのか引き出す」なので、相手が必要としていないけれど自分がやりたいことを押し売りするのは、相手にとっても「話を聞いてくれない人」という印象を与えてしまいます。

③設計段階では、システムの目的をきちんと理解した上で、④実装段階で必要な情報を整理しなければならず、システム構築全般の経験や知識が必要になります。

上流エンジニアをしている人で、最初から上流エンジニアをしているという人には私は出会ったことがありません。みなさん、最初は開発エンジニアや保守エンジニアをして、開発や運用を通して下流では何が必要なのかを学んでから、上流エンジニアになられています。私もそうです。

上流エンジニアの仕事をするにあたって必要な資格はありませんが、ほとんどの方が学生時代や社会人になって最初のうちに、IPAの基本情報技術者試験や応用情報技術者試験を受けています。私も両方とも受け、取得済です。

その後は、仕事内容や興味に応じて、IPAの上位資格を受ける人もいれば、オラクルなどベンダーが提供している資格を受ける人もいます。私の場合は、会計システムを担当していたことがあったので、システム系の資格ではありませんが、簿記を受けました。

必要な資質のところにも書きましたが、上流エンジニアに興味がある場合は、まずは開発、運用など下流の仕事から始めることになります。

新卒で上流エンジニアになるには、SIerが現実的

企業内のIT部門の場合、会社によっては上流エンジニアの部分は外注するということもあります。入社前にそこまで把握するのはなかなか難しいと思いますし、希望してもそもそもIT部門に配属されないこともあると思いますので(私は本当に偶然配属されたという状況です)、上流エンジニアに興味があるなら、SIerに就職するのが良いと思います。

SIerという言い方は聞き慣れないかもしれませんが、富士通やNEC、NTTデータなどの会社を思い浮かべてもらえれば分かりやすいと思います。

転職するなら関連職種から、全くの未経験だと難しい...

元々上流エンジニアの仕事をしていた人はもちろん、応募要綱にもよりますが、ポテンシャルがあれば下流の仕事をしていた人も、仕事内容のところに書いたような上流エンジニアが考慮すべきことを理解しているという点で十分チャンスがあるのではないかと思います。

実際、同僚には、元々設計業務を行っていた下流エンジニアの人もいます。専門性が高い仕事なので、下流の仕事の経験がなく、②要件定義に近いような仕事、例えば業務コンサルのような仕事の経験もない場合は、実感として上流エンジニアに転職するのは難しいのではと感じています。少なくとも、私の周りにはいません。

関連職種から上流エンジニアに転職

私は、現在の上流エンジニアの仕事をするまでに転職しています。元々は下流エンジニアでした。

大きなSIerの場合、新卒入社して下流エンジニアなどからスタートし、何年かすると徐々に上流分野に関われることが多いようですが、私が新卒で入った会社は、IT部門の人数が少ない上に人員が固定化していて、仕事も人に固定化してしまっている状態でした。

私が配属された後、新入社員は入ってこなかったため、業務移管も難しく、将来のことを考え、もっと色々な仕事を経験し、社会人としてステップアップしていきたいと考えた時、組織内ではそれが叶えられなかったため、転職を考え始めました。

上流エンジニアを狙っていたわけではありませんが、私の職歴で応募できそう、かつ新しい経験ができそうな求人が上流エンジニア職で出ていたため、挑戦してみた、という経緯です。

センスの光る提案ができた時に感じる達成感が魅力

一番の魅力は、システムの方向性を決められるということです。開発エンジニアをしていた時、「なんでこんな設計にしているんだろう？もっとこうした方が効率よいのにな」と思いながら開発していたこともあったし、「この設計センスいい！」と思いながら開発していたこともありました。センス良い設計をすると、その後の段階がスムーズに進むので、そこに携われるということに喜びがあります。

過去に体験したプロジェクトで一番達成感があったのは、システムオーナーから出てきた複雑な希望について、よく話話を聞いて整理し、「シンプルに必要なことってこういうことですよね？」と提案できたことです。

例えば、実現したいことはお客様との迅速なやりとりなのに、以前の名残で内部承認フローが複雑になっている状態の継続を希望しており、お客様とコンタクトを取るまでに時間がかかっているようなシステム案になってしまっているケースがありました。システム上での処理フローを図に起こして提示し、「これだけの段階を経ないとお客様とコンタクトが取れない仕組みになっていますが、○○の部分は、昔の名残であるだけで、現在の仕事において必要ないのでは？」と提案したりしました。システム目線からみた業務コンサルとも言えるかもしれません。

女性でも男性と対等に働きやすい

理系職場なので、男女比で言うと男性が圧倒的に多いですが、実力主義なので、性別がハンデになることはありません。ただし、どんどん新しく出てくる技術情報のキャッチアップなど、勉強し続けることが必要な仕事でもあります。一度何かを習得すれば安泰という仕事ではないので、学ぶことが好きな人にとっては好奇心を満たしてくれる仕事だと思います。

私はバリバリ働きたいタイプなので、性別に関わらず努力次第で活躍できることはありがたいと思っています。未婚/既婚に関わらず、バリバリ働いている女性が周囲にもいます。
出産後、子育てしながら時短勤務で働いている人も少数ながらいますが、仕事外での勉強量も仕事に影響するので、勉強する時間確保が難しい状況だとどうしてもサブ的な仕事になってしまうこともあるようです。実際、お子さんがいて時短勤務している女性で、プロジェクトのリーダーをしている人は私の周りにはいません。

ただ、それまでに積み上げてきたものもあるので、時短勤務のうちはサブ的な仕事でも良いので現状をキープしておくことで、子どもが大きくなってから取り戻すことができるのではないかと思っています。私は未婚で子どももいませんので、そのあたりは現実問題として直面している訳ではなく、自分がその状況になったら、そうするかなというイメージです。

大変だと感じることは正直あまり無い

「これくらい簡単にできるだろう」とシステムオーナーが勝手に判断し、利用開始希望時期間近になってからシステムオーナーから「相談にのってほしい！」と言われたりすることは時々あり、「もっと早く言ってよ～」と思いながら、時期にできるだけ間に合うように残業する羽目になること等はありますが、どの仕事も大変なことはあるし、我慢できないほど嫌だと思うことはありません。

時々、周囲の人で辞める人はいますが、上流エンジニアとしての仕事がキツイという理由ではなく、自分自身でプログラミングなどをしながら技術力をアップさせていきたい、もっと自分自身で開発(プログラミング)するような仕事がしたいといった理由の人が多いです。

上流エンジニアは技術に関しての知識は必要ですが、自分でプログラミングは行わないので、その部分で仕事内容と志向にギャップが生まれてしまったようです。

会社の規模、業態によって年収はまちまち

私の現在の年収は、ざっと560万円です。

エンジニアとしてというより、メーカー総合職としての金額としてお考えください。社内SEの場合は、IT部門も他部門(総務や営業、品質管理部門など)も一律の給与体系に基づいて年収が決まることが多いと思います。

同じような仕事でも、大手SIer勤務だともっと高額になることが多いかと思います。就職活動をする際は四季報や業界地図などを見ることがあると思います。そのような媒体には、会社ごとの年収についても書かれているので、興味があれば見てみてください。

ぜひ、残業時間がどれくらいか？ということについても調べてみてください。基本給はそれほど高額でなくても、残業時間が多いために年収が高くなっている場合もありますので、注意が必要です。

お堅めで残業も多くない！？メーカーのIT部門

私はメーカーに勤務し、社内部門がお客様という状態です。ほぼ社内の人にしか会わないので、服装もカジュアルです。男性もスーツを着ている人はほぼおらず、ユニクロのシャツにチノパンのような服装の人が多いです。女性は、カジュアルなブラウスにスキニージーンズみたいな服装の人もいれば、個人の趣味でゆるふわOL風の服装をしている人もいます。

オフィスは、課ごとにまとまって机が固まっていて、座席も個人ごとに決まっており、毎日同じ席で仕事をしています。IT系というと、カフェで仕事したり、オフィス内がフリーアドレス(座席自由)になっているような自由な雰囲気をイメージする人もいるかもしれませんが、私のオフィスはお堅い感じです。

年功序列の会社で、IT部門とはいえ世代的には20～50代までまんべんなくいるので、新しいことにどんどんチャレンジしていこうというより、しっかり確実にやろうという雰囲気があります。

また、IT系というと、とてつもなく忙しいというイメージが強いかもしれませんが、ややカッチリめのメーカーなので、勤務時間管理などはしっかりしています。もちろん、トラブル発生時に急に残業になったりはありますが、残業時間はそれほど多くはありません。私は「食」が生活の基本だと思っていて、残業時間が多くないので、ほぼ毎日自炊することができています。最近は天ぷらなどの揚げ物にハマっています。

コロナ禍では、緊急事態宣言が出た際には、「在宅勤務で仕事できる人は極力在宅勤務を」という方針になり、一時期は完全在宅勤務していましたが、緊急事態宣言解除とともに「最低2日は出社」という方針になりました。完全在宅勤務に際して何か新しいツールが導入されるといったことはなく、以前から使っていたSkypeでコミュニケーションを取っていました。

製造業なので、製造現場に関わる人はもちろん、お堅い性質のため、書類にハンコで承認印を押さないと先に進めない等の社内ルールがあり、仕事内容はITとはいえ、完全在宅勤務はなかなか難しいなと感じています。ハンコ問題がなければ、私個人としては完全在宅でも仕事はできたと思いますが、上層部にはまだまだ「出勤することが善」という考えが根強いので、私が働いている会社の場合、完全在宅は厳しそうです。

SIerやベンチャー企業だと、おそらく事情は異なると思います。

ある日の一日の過ごし方

平均的な一日の流れは、以下のような感じです。

8:30	出社　メールチェックからスタート
9:00	チーム定例　各自が関わっている案件の進捗状況を共有
11:00	相談にのってほしいと言われていた案件のヒアリングをビデオ会議で実施 軽く話すだけなので、まずは相手側は実際に業務を担当しているAさん1名
12:00	昼食　オフィス近くの屋外フリースペースで持参したお弁当を1人でサッと食べた後、オフィスに戻って自席で仮眠
13:00	以前から関わっていた案件の要件定義書を作成
17:30	午前中にヒアリングをしたAさんから、こちらから確認してほしいとお願いした事項について問い合わせの電話があり、対応
18:30	勤務終了

これからの時代、上流エンジニアという仕事自体が無くなるかもしれない

ITはこれからますます重要になっていくので、システム構築の需要は高まると思いますが、上流エンジニアの需要については何とも言えません。

というのは、「上流」エンジニアというのは、ウォーターフォール開発という昔ながらの開発手法での職種であり、日本の会社はまだまだ採用しているところが多いのですが、近年スクラム開発という手法が注目されていて、大手SIerも社内にスクラム開発チームを作っていることが多いからです。大手SIerの名前+スクラム開発で検索すると、各社がスクラム開発の取り組みに力を入れていることが分かります。

スクラム開発はウォーターフォール開発の②～⑥の段階を、1回ではなく、小さなサイクルを何回も回すという考え方で、そもそも上流と言えるものがありません。今後もし、スクラム開発が主流となっていけば、上流エンジニアという仕事はなくなってしまいます。
世の中の流れとして仕方ないと思うので、淡々と受け止め、上流エンジニアという仕事がなくなっても働けるようにしようというのが私の考えです。

そのため、将来性を考えると、「上流エンジニア」として働き続けたいのであれば、SIerのエンジニアであれば、今後少なくなるかもしれないウォーターフォール案件に確実に関われるように、今のうちに上流エンジニアとしての経験を積んできた先輩のノウハウを徹底的に学び、「ウォーターフォール開発なら任せて」と言える立場になっておくか、＋アルファの知識、例えば、簿記やネットワークなど構築するシステムに関係ありそうな勉強をしておく必要があるのではと思います。

社内SEの場合は、どんなシステム開発の手法を採用するのかについては、上層部の判断などもあると思いますので、上流エンジニアとして働き続けられるかどうかは本人の意思だけではどうにもならないケースが多いのではないでしょうか？

なぜ上流エンジニアとして働き続けたいのかを考えてみて、それがどうしても上流エンジニアでしか実現できないのであれば、転職なども視野に入れると良いと思いますが、上流エンジニアでなくても実現できる場合は、自分の興味やその時々で会社から求められているスキルを身に付けていくのが賢明ではないかと個人的に思います。

私自身は効率よくシステム開発を進めたいというのが実現したいことなので、ウォーターフォール開発での上流エンジニアではなく、スクラム開発の中でもそれは実現できると思っています。

そのため、今後会社としてスクラム開発を採用する可能性を見越して、スクラム開発の勉強をしています。実際に仕事として体験したことはありませんが、有志による勉強会などが開催されていますので、そういったところに参加し、スクラム開発の現場の情報を得るように行動しています。

勉強会は同僚と声を掛け合って社内で開催することもありますが、「システム開発における役割」のところにも書きましたが、IT系勉強会告知に特化したサイトなどがあり、興味に合わせて誰でも参加することができます。

「上流エンジニア」としての将来性はなかなか厳しいかもしれませんが、「上流エンジニアとして働きたい」と思ったら、なぜそう思うのか？自分が実現したいことは何なのか？掘り下げて考えてみると、進むべき道が見えると思います。