エンジニアの具体的な仕事内容【一週間のスケジュール公開】

エンジニアのスケジュール エンジニアの紹介
engineer's schedule

こんにちは。

この記事を読んでいる方は、このような悩みを持っているのではないでしょうか。

・エンジニアになった後、仕事がどのようなスケジュールになるか気になる。
・エンジニアになったあと、どのくらい忙しいのか知りたい。
・エンジニアの具体的な、 一週間のスケジュールを知りたい。

新しい職種や職場に行く前は、その内容が分からないから非常に不安になる気持ち、非常によくわかります。

プログラミングの勉強をしながら、頭の片隅にこういった不安があるのは精神衛生上よくないですよね。場合によっては目の前でやるべき勉強に集中できない、なんてことも起こったりします。

この記事を読んでわかること

エンジニアになった後の、具体的な一週間のスケジュールを知ることができます。

このスケジュールを知ることで、知らないことによる不安を払拭でき、 エンジニア転職に向けた勉強などを頑張ることができます。

なぜ私がこの記事を書けるか

私は新卒からエンジニアになり、エンジニアやプロジェクトマネージャーとして長い間働いています。

また、エンジニア以外にもUIデザインや商品企画のチームなど、色々なチームに所属していたため、 客観的な目線でも、エンジニアの一週間がどのようなものかを知っています。

エンジニアの一週間

ざっくりと、どんな感じになるか?

いきなり詳細なスケジュールを見せられても・・・だと思いますので、まずは一週間のサマリーをご説明したいと思います。

・裁量労働制であれば、出社と退社の時間は自由
・朝の早い時間に「立ったままミーティング (デイリースクラム)」をやることが多い
・システムエンジニアであれば、結構ミーティングが多いことがある
・ミーティングがない間も、ひたすらプログラミングやメール、Slackでメッセージを返す作業で忙しい
・プロジェクトが炎上すると、一気に仕事の時間が長くなる。かつ、昼休みがとれないこともある。

とはいえ、これだけだと伝わりづらいと思うので、僕が作った仮想的なスケジュールをベースに、具体的な内容を説明したいと思います。

詳細な説明の、前提

以下が仮想的なスケジュール (でも、僕の経験をベースにしているので、結構リアル)です。

このエンジニアは、三つのプロジェクトを掛け持ちしています。

多くのエンジニアがそうであるように、この会社は完全裁量労働制で、出社や退社時間は特に定められてない前提です。
この人は大体毎日10時に来て20時に帰る生活をしています。

かつ完全なプログラマーというより、若干システムエンジニアよりの仕事をしている方です。

この週の想定は、

・前半は特に何も問題が起きませんでしたが、木曜日の夕方に顧客からクレームが入ってきました。
・ そしてその緊急対策で木曜の夕方から金曜まで、その対策に時間を使った、

という設定です。

もちろんこのスケジュールは空想の物ですが、エンジニアの一週間の一つの例として見ていただければと思います。

それでは月曜から順に見ていきたいと思います。

月曜日

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時の時間で、そういった関係者に現状の報告や、 修正が終わる見込みの時間を伝えることになります。

またそういう状況下では、ランチが取れないこともしばしばあります。
ですので、 このケースでも、金曜日はランチが取れずに仕事をすることになりました。

以上が、 「エンジニアあるある」 を含んだ、 エンジニアの一般的な一週間のスケジュールになります。

もしあなたがプログラマーになるのであれば、 これよりもミーティングは少なくなることが予想されます。
一方で、もしあなたが、顧客と直接話す機会のあるシステムエンジニアであれば、これよりももっとミーティングの数や時間は増える傾向にあります。

このようなスケジュールをこなすために必要なスキル

続いてこのようなスケジュールを問題なくこなすために必要なスキルに関して、ご説明したいと思います。

見てわかるとおり、エンジニアは、基本的に忙しい一週間を過ごしています。

またこういうミーティングをしながらも、 メールや Slack などで大量のメッセージが、送られてきます。ですのでエンジニアとして必要なのは、

・業務に求められるレベルのプログラミングのスキル

だけではなく、

・違う役割の人や、違うチームの人と話せるレベルのコミュニケーションスキル
・ミーティングをしている間に、自分の関係ない話であれば、自分宛に飛んで来ているメッセージをさばける、マルチタスク能力

なども必要になってきます。

逆に言うと、 あなたが前職までで培った能力があれば、多少プログラミングができなくてもエンジニアとしての仕事ができるということも言えます。

ですので、僕の他の記事でも書いている通り、エンジニア=プログラミングではない、と考えています。プログラミング以外の、様々な業務をこなせるスキルがあれば、未経験からでも十分エンジニアになることができます。

最後に

いかがだったでしょうか。 エンジニアなってからの一週間のスケジュールを、少しリアルに想像できたのではないでしょうか。

この記事を読んで、あなたがエンジニアになった後の姿を少しでも具体的に想像できて、目の前のプログラミングなどの作業に集中できるようになることを願っています。

以上で、今回の記事を終わります。

最後まで読んでいただき、ありがとうございました!

コメント

タイトルとURLをコピーしました