こんにちは。
この記事を読んでいるあなたは、このような悩みを持っているのではないでしょうか。
「エンジニアになった後、仕事がどのようなスケジュールになるか気になる」
「エンジニアになったあと、どのくらい忙しいのか知りたい」
「エンジニアの具体的な、 一週間のスケジュールを知りたい」
特に、「これからエンジニアを目指していきたい！」と思っている場合、エンジニアになった後の姿は具体的に知っておきたいですよね。
僕もエンジニアになる前、「エンジニアとして働く」ということが全然分からず不安だったので、よく分かります。
そこで、この記事では、以下のような内容をまとめました！
この記事を読んでわかること・エンジニアとして働くときの特徴を知ることができる
・エンジニアの具体的な一週間の仕事の流れを知ることができる
・エンジニアとして働く上で必要なスキルを知ることができる
この記事を読むことで、エンジニアになった後の姿を具体的に想像できるようになります。
その結果、あなたはプログラミングやエンジニアとして必要なスキルの向上に集中したり、安心してエンジニアへの転職活動を進められるようになりますよ。
あなたが今やるべきことに集中するためにも、しっかりと読んで理解してくださいね！
この記事の信頼性
僕は新卒からエンジニアになり、エンジニアやプロジェクトマネージャーとして長い間働いています。
また、エンジニア以外にもUIデザインや商品企画のチームなど、色々なチームに所属していたため、 客観的な目線でも、エンジニアの一週間がどのようなものかを知っています。
そういった中で、いろいろな問題に直面したり、大変なプロジェクトで苦労もしてきました。
この記事は、そんな僕の実体験を元に書いてあるので、「エンジニアのリアル」を知るためには最適な内容になっています。
エンジニアの仕事の特徴
[結論]エンジニアの仕事の特徴: プログラミング以外の業務もたくさんある
まずは、エンジニアとして働く際の特徴をまとめました。
エンジニアの仕事の特徴・割とミーティングが多い
・場合によってはプレゼンをしたりもする
・突発的な仕事も多い
・会社によるものの、自由な働き方ができる場合が多い
・複数のプロジェクトを掛け持ちすることも多い
割とミーティングが多い
「エンジニアは一人で黙々と作業する」というイメージが強いかもしれませんが、実はそんなことはありません。
毎日、他の関係者と認識を合わせるミーティングを実施したり、開発方針や不具合に関するミーティングを実施したりします。
多いときには一日の半分以上がミーティングで潰れる、なんてこともあります。
エンジニアとしてはミーティングはあまり楽しい作業ではないと思いますが、間違った方針で開発を進めないためにも、開発を始める前に認識のすり合わせを行うのは非常に重要です。
そうしないと、「せっかく開発したのに方向性が違っていたので菜魚からやり直し・・・」なんてことにもなりかねないからです。
エンジニアには、もちろん優れた開発スキルが必要です。
それに加え、あなたの考えていることを他の人に伝えたり、他の人の考えていることを理解できるコミュニケーション能力も重要になります。
場合によってはプレゼンテーションで説明をしたりもする
1つ前の項目と似ていますが、エンジニアの仕事は開発するだけではありません。
「現在の状況をわかりやすく人に説明する」ことも重要となります。
例えば、事業に大きい影響を与える内容の場合、チーム外のマネジメント層に現状や今後の予定などを説明する場があったりします。
「エンジニアであれば他の人と話さなくていいだろう」
という考えでエンジニアになると、いざプレゼンをする場が発生したときなどで、大変な思いをすることになります。
会社やプロジェクトにもよりますが、場合によってはこういった作業が発生する可能性があることは理解しておきましょう。
問題が起きたり、突発的な仕事も多い
特にサービスを提供している会社では多いですが、かなり突発的な作業が多いのも特徴でしょう。
・サービスのユーザーからクレームが入ったから
・その他、使っている環境で予期しないアップデートが入ったから
などなどの理由で、問題が起きる前に対処したり、起きた問題をすばやく対処する必要があります。
「プログラミングに集中していたのに突発的な仕事が入ってきてしまったため、集中力が途切れてしまった・・・」
というのも、「エンジニアあるある」の話だったりします。
会社によるものの、自由な働き方ができる場合が多い
もちろん会社にもよりますが、「絶対に9時から仕事を始めなさい」なんていう決まりがない会社も多くあります。
むしろ、エンジニアが働いている会社や環境であれば、仕事を開始する時間が厳密に規定されている会社の方が珍しいでしょう。
「今日はちょっと疲れてるから朝10時からにしよう」
「今日は友達と飲み会があるから早めに仕事を切り上げよう」
なんてことができるのも、エンジニアのスケジュールのメリットでしょう。
特に、あなたが「自由に働きたい！」と思っている場合、このポイントはかなり嬉しいポイントなのではないでしょうか？
複数のプロジェクトを掛け持ちすることも多い
競合他社との競争が激しくなってきている現在、どの会社でも基本的にエンジニア不足です。
エンジニアはなかなか採用できないけど、やらないといけないプロジェクトの数が増えていく・・・なんてことも多々あります。
そのため、いずれか1つだけのプロジェクトを専任でやるエンジニアは少なく、多くの人が複数のプロジェクトをかけもちすることになります。
特にエンジニアとしての経験年数が長くなり、年次が長い人であればチームをまとめたりリーダーとして多くのプロジェクトに関わることが多くなります。
エンジニアの仕事の一週間のスケジュール
ここまでで、エンジニアの仕事のざっくりとした特徴をお伝えしてきました。
ただ、これだけだと伝わりづらいと思うので、僕が作った仮想的なスケジュールをベースに、具体的な内容を説明したいと思います。
詳細な説明の、前提
以下が仮想的なスケジュール (でも、僕の経験をベースにしているので、結構リアル)です。
このエンジニアは、三つのプロジェクトを掛け持ちしています。
多くのエンジニアがそうであるように、この会社は完全裁量労働制で、出社や退社時間は特に定められてない前提です。
この人は大体毎日10時に来て20時に帰る生活をしています。
かつ完全なプログラマーというより、若干システムエンジニアよりの仕事をしている方です。
この週の想定は、
・ そしてその緊急対策で木曜の夕方から金曜まで、その対策に時間を使った、
という設定です。
もちろんこのスケジュールは空想の物ですが、エンジニアの一週間の一つの例として見ていただければと思います。
それでは月曜から順に見ていきたいと思います。
月曜日: エンジニアは週に1回のチーム定例を持っている場合が多い
10:00 | チーム定例
エンジニアに限らず他の職業の人でもそうであるように月曜の朝にチーム定例をするところは多くあります。
このチーム定例では別のプロジェクトに関わっている同じチームメンバーに対して、
・そこで起きている問題
・今週やる予定のこと
などのステータス共有を行います。
10:30 | デイリースクラム
そして毎日朝の10時半から入っているデイリースクラムでは、プロジェクトCに関わっているプロジェクトマネージャーや、デザイナー、企画担当者と一緒に30分弱の情報共有会を行います。
このデイリースクラムは一般的に、ホワイトボードの前で立って行い、 時間をかけずにお互いの状況や今日やることをシェアすることが目的です。(一般的にアジャイル開発でよく取り入れられている手法です)
11:00 | プロジェクト定例
その後、30分間の自席での作業時間を挟んだ後、11時から12時まで、プロジェクト A の定例会を行います。
この定例は基本的にプロジェクトにより大きく運営方針が異なるのですが、 基本的には、プロジェクトに関係しているメンバー間での情報共有や、スケジュールに関して議論することが多いです。
もちろん場合によっては、現在起きている問題に対して議論を行うこともあります。
12:00 | ランチ
そして12時からはランチの時間となります。
エンジニアによってはあまり他の人と喋りたくないという人もいるので、自分の席でランチを取る人も多くいます。
13:00 | 作業時間
そしてランチが終わった13時から16時までは奇跡での作業時間です。
この作業時間では、 メールや Slack に来ているメッセージを返したり、プログラミングをしたり、ソフトウェアの設計をしたりします。
ですので、ミーティングがないからと言って、 決して暇ではありません。
基本的にこの3時間も全力で働いています。
16:00 | 企画定例
そして16時から17時が、プロジェクトBの企画定例を行います。
エンジニアと企画チームのとの定例では、
・エンジニアチームの進捗報告や
・実装が難しいポイントの仕様を変更できないかの相談
などを行うのが一般的です。
また、企画とエンジニアは組織が違うことも多く、利害関係が一致しないこともあるので、 割とミーティングは殺伐とした雰囲気になることも多いです。
17:00 | デザイン定例
続いて17時から18時はプロジェクトCのデザイン定例です。
ここではデザイナーのチームとエンジニアとの間で定例会を行います。
内容はもちろんデザインに関するものの議論になります。
デザイナーは、よりソフトウェアを作る側に近いので、企画チームとのミーティングほど殺伐することも少ないように思います(笑)
18:00 | 自席で作業
それが終わった後は18時から20時まで自席で作業をし20時に退社します。
ちなみにエンジニアの組織によっては20時以降も、 Slackやメール、そして LINE などで通知が来るため、 休まる暇がないという組織もあります。
火曜日
この日は、 比較的ミーティングは少ない日です。
月曜日と比較して分かる通り、日によってミーティングの多い少ないが大きく異なることがあります。
15:00 | ちょっとご相談
この日は朝の10時半からデイリースクラムを行い、その後ランチを挟んでしばらく自席で作業をした後、15時から突発的に入れられたミーティング「 ちょっとご相談」に参加します。
この「 ちょっとご相談」 といったようなミーティングは、1対1で行われることが多く、 人事的な話や、プロジェクトの今後の方向性など、 比較的シビアな話をされることが多いです。
少なくとも僕は「ちょっとご相談」とか「雑談」とかいうミーティングを入れられたときが、一番緊張します (笑)
水曜日
この日は夕方の18時から Projectg の、トップマネジメント向け状況報告のミーティングに向けて準備をする日になります。
12:00 | トップマネジメント向け状況報告準備
お昼の12時から13時に、その「状況報告」に向けた準備のミーティングを行います。 いわゆる、 事前会議、というものです。
特に大企業では、このような事前会議をやることがあり、 場合によっては事前会議の事前会議、 なんてミーティングもあったりします。
18:00 | トップマネジメント向け状況報告 (本番)
そして18時からがその報告の本番になります。
プロジェクトに投資を続けてもらえるか？などがかかっていることもあるため、非常に緊張するミーティングになります。
エンジニアも、リーダクラスになると、こういったミーティングに呼ばれてプロジェクト状況や今後のプランを説明する必要が出てくる場合があります (全員ではありません)
木曜日
10:30 | 出社
この日は本来10時に出社すべきところを、 寝坊してしまった為、一時間ほど 遅刻して会社に到着しました。
ただ、完全裁量労働制であれば、このように一時間遅れたとしても、特に何も言われません。
メールや LINE で、「1時間ほど遅れます」とメッセージを入れれば特に問題ない会社も多くあります。
少なくとも僕がこれまで勤めてきた会社はそのような文化でした。
16:00 | クレームについて
この日は夕方までは、特に何もなく業務が進んでいたのですが、16時から入っている
「クレームについて」
というミーティングをトリガーに大きく状況が変わるケースを説明しています。
ここでは例として、エンドユーザーから すでにプロジェクトBでリリース済みの製品に対するクレームが入ってきた例をご説明しています。
エンジニアも、緊急度の高いクレームが入ってくると、その対応に追われることがしばしばあります。
このケースではそのクレームを16:00からの緊急ミーティングで受けたと仮定しています。ミーティングではCSやビジネス、商品企画のチームから招集がかかり、起こっている事象を把握するところから始めます。
このようなミーティングが入れられたら、エンジニアとしてはアドレナリンが大量に出ます。
19:00 | 市場不具合対策会議
緊急でその問題を解析し、19時から緊急で市場不具合に対する対策会議を行います。
このような状況に陥ると、(エンジニア以外でも同じだと思いますが)基本的に定時で帰れる可能性が低くなります。
エンジニアは、その問題が解決するまでは終電での帰宅となることも、しばしばあります。
金曜日
この例では木曜日中にこの問題が片づかなかったものとして、仮想スケジュールをひいています。
9:00 ~ | 対策方針検討会
この対応が最優先になってくるので、本来は出席すべきだったデイリースクラムなどのミーティングは全て欠席をし、対策の検討を行います。
そして、このように援助をしてしまったプロジェクトは、プロジェクトマネージャーや、会社の経営層に対して、 こまめに reporting をすることが必要となります。
12:00 / 17:00 | 対策方針検討会 & 状況共有
ですので、このケースでも、12〜13時や17〜18時の時間で、そういった関係者に現状の報告や、 修正が終わる見込みの時間を伝えることになります。
またそういう状況下では、ランチが取れないこともしばしばあります。
ですので、 このケースでも、金曜日はランチが取れずに仕事をすることになりました。
以上が、 「エンジニアあるある」 を含んだ、 エンジニアの一般的な一週間のスケジュールになります。
もしあなたがプログラマーになるのであれば、 これよりもミーティングは少なくなることが予想されます。
一方で、もしあなたが、顧客と直接話す機会のあるシステムエンジニアであれば、これよりももっとミーティングの数や時間は増える傾向にあります。
エンジニアの仕事をする上で必要なスキル
ここまでで、エンジニアの具体的な一週間の内容を見てきました。
おおよその流れや、エンジニアになった後にどのような状態になるか？がお分かりいただけたのではないでしょうか？
続いて、あなたがエンジニアになった後、成果を出すためにどのようなスキルが必要なのか？をまとめていきます。
もちろん人によって得意・不得意が出てくるとは思いますが、これらには対応できる必要があります。
他の人とのやり取りができるコミュニケーションスキル
エンジニアの一週間のスケジュールの中でも多くのミーティングが出てきたかと思います。
エンジニアは、ミーティングなどであなたの考えていることを伝え、相手の言っていることを理解するためのコミュニケーション能力が必要です。
特に問題が起きたときは、問題を冷静に分析し、「今起きている問題が何で、解決できそうか？解決するために必要なことは何か？」などを関係者に伝える必要があります。
プログラミングだけでなく、他の人とのコミュニケーションができるようになると、エンジニアとしての評価が一気に高まります。
わかりやすい説明ができるプレゼンテーション力
特にシステムエンジニアに必要となるスキルですが、以下のようなものを会社の上層部やお客さんなどに説明する場合があります。
・どのくらいの予算がかかるか？
・どのような問題が起きているか？リスクはあるか？
この説明が上手か下手かによって、それ以降の開発の大変さが大きく変わってきます。
プログラマーの場合はそれほどプレゼンテーションで説明することはないかもしれません。
一方、システムエンジニアやプロジェクトマネージャーなど、他の人と多く関わる仕事に就きたいと思っている場合は、今のうちからわかりやすく論理的に説明するスキルをつけておくことをオススメします。
スケジュールとタスクの管理能力
すでに説明した通り、エンジニアは割と多くのミーティングを行います。
特にミーティングの数が多い場合は、
「今日、プログラミングをしていたのは実質2時間だけだった・・・」
なんてこともあります。
とはいえ、プロジェクトの締め切りは変わらないため、あなたがはエンジニアとして限られた時間の中でアウトプットを出す必要があります。
「締切の日が来たけど、全然開発が間に合いませんでした・・・」
とならないように、
・何か遅れている部分はないか？
などのスケジュールやタスクをきっちりと管理する能力が必要となります。
もしあなたがスケジュールやタスクの管理に自信がない場合は、今のうちから訓練しておきましょう。
スケジュールやタスク管理は、エンジニア以外の仕事や学生の勉強の中でも訓練することができます。
臨機応変な対応力
これもすでに説明した通りですが、エンジニアの仕事には飛び入りや割り込みの仕事も数多く発生します。
しかもそういった仕事は緊急性が高かったりするため、エンジニアには「臨機応変にタスクに対応するスキル」も求められます。
「このプロジェクトにかかりっきりで頭がいっぱいなので、他のタスクは担当できません・・・」
という状態だと、「使いづらいエンジニアだなぁ」と思われたりします。
この臨機応変な対応は、エンジニア以外の仕事でも比較的多く発生すると思います。
もしあなたが、
と思う場合、今の仕事をこなす中で、「いかに飛び入りのタスクを素早く処理できるか？」などの意識を持つことで、少しずつ臨機応変な対応力を上げることができます。
プログラミングスキルやソフトウェア開発スキル
そして、エンジニアとして、最も基本的で重要な要素が「プログラミングスキル」、そして「ソフトウェア開発スキル」です。
プログラミングスキルに関しては、ほぼ全ての方が理解されていると思うので特段説明をすることはしません。
もしあなたが
と思っている場合、この後にまとめている「エンジニアとして必要なスキルを身につけるための方法」の章を読んでみてください。
この章を読むことで、
「エンジニアになりたけど、どのような勉強をしたらいいかわからない」
なんてことにならずに済みますよ。
あなたが、エンジニアになるのに遠回りしたくないない場合は要・チェックの内容です。
エンジニアとして活躍するために必要なスキルを最速でつけるには
もしあなたが「できる限り最速で、無駄なくエンジニアになりたい！」と思っているのであれば、プログラミングスクールに通ってみることをオススメします。
何故なら、プログラミングを独学しても、ここまでで説明してきたような実践力を身にづけづらいためです。
独学でプログラミングを学習する場合、プログラミング自体のスキルは身につけられるでしょう。
一方で、他の人と協力して開発をしたり、実際の開発現場で遣われている開発手法を学んだり経験するのは難しいですよね。
もちろん、独学でのプログラミングの学習が不要というわけではありません。むしろ、きちんとプログラミングを習得するには必須です。
特にエンジニアとしての即戦力をつけられるプログラミングスクールは、プログラミングのスキル以外にも、
・ソフトウェアの設計や要件の検討
など、エンジニアとして必要なスキルを一通り身につけることができます。
こういったプログラミング以外の知識もプログラミングスクールで学習することにより、より早く活躍できるエンジニアになることができます。
とはいえ、「どんなプログラミングスクールに通ったらいいかわからない！」という声が聞こえてきそうです。
そこで、僕のエンジニアの経験を生かして、「即戦力としてエンジニアとして働くためのプログラミングスクール」を選びました。
ここで選ばれているプログラミングスクールに通うことで、プログラミングのスキルを身につけつつ、この記事で説明したような、「エンジニアとして必要なスキル」を一通り身につけることができます。
この「目的別・オススメのプログラミングスクール10選」ページでは、目的別でオススメのプログラミングスクールをピックアップしていいます。
最後に
いかがだったでしょうか。 エンジニアなってからの一週間のスケジュールを、少しリアルに想像できたのではないでしょうか。
この記事を読んで、あなたがエンジニアになった後の姿を少しでも具体的に想像できて、目の前のプログラミングなどの作業に集中できるようになることを願っています。
以上で、今回の記事を終わります。
最後まで読んでいただき、ありがとうございました！
コメント