こんにちはカレイドです。
今回はプログラマーの1日について話そうと思います。
駆け出しエンジニアの皆さんがわりと気になることって、社員さんがどのような1日を過ごしてどのように業務をこなしているかってとこじゃないでしょうか。
実際にコンサルを何人かさせていただいて、仕事はどんな感じなのか聞かれることが多かったので、
話せる範囲で1日の大体の流れをご紹介しようと思います。
私はあくまで正社員ではないので、それを踏まえた上で読んでいただけると幸いです。
とは言ってもほぼ一緒に行動しているので安心してください。
簡単な自己紹介です。
現在の出社状況
まず、私が働かせてもらっている会社は１１−５時までコアタイム（この間は仕事をする）
として設けられています。それ以外は、
早くきて早く帰るもよし。
遅くきて遅く帰るもよし。
わりと自由に通勤させてもらっています。
ちなみに夏休みに入ってからついに大学の都合がなかったので１週間のうち５日間出社することができました。
きっちり8時間✖︎５＝40時間です。
もちろんリモート稼働も可能です。私の場合は大学の都合もあるので、比較的出社するように言われていますが最近は業務もこなせるようになってきたので、リモートでも出社でもどちらでも大丈夫といった感じですl
社員さんも基本週１リモート活用しているので、こういう日は私も大体リモートにしてしまっています。
大学で午後からしか行けない日にもリモートさせてもらったり本当に融通が効くなぁと思っています。
一番うまい使い方ができた日の一例としては、最近早起きが多いので６時に起床してのんびり朝活。
タイミングよく切り替えて８時からリモートで業務をこなす12-1でお昼兼移動休憩
１時から５時まで働いておしまい。
という状態。これ自分が実際に入ってからもこういう働き方できるって考えたらわりと自分の時間有意義に使えるかもしれないとも思っています。普通のバイトと違って1人の社会人の経験ができるので色々見定めながら業務以外のこういうところも結構考えて仕事をさせてもらっています。
他にも午前中に荷物がきたりとかでリモートにしている社員さんとか、基本ルールを守れる前提の中で全体で効率をあげようという形です。
先ほど話したように将来的な目でみてもやはり魅力的ですよね。
別に午前リモートで午後出社という形もできる。こういう自分のタイミングをうまく活用できる方が私は好みですかね。
皆さんはこういうタイプと時間きっちりの方がしっかり動けるからというタイプどちらでしょう。
実際の1日
ここからは実際の1日の流れを説明していこうと思います。
火曜のお昼だけは１２時から全体のミーティングがあって私も全プロジェクトの進捗状況などを聞かせてもらっています。
ギリギリを埋めながらうまくプロジェクト内で協力したり、手伝ったりしてもらったりと、みんなが全体の状況を把握できているからこそこういうことができますね。
大企業はプロジェクト単位で孤立しているでしょうから、そのまま過ごしていたら味わえないようなベンチャーならではの臨場感も経験させてもらっています。
また、金曜の６時からは勉強会があってエンジニアが一部屋（結構狭いw）面白い話、コーディングに限らず、トレンドなどについても共有しています。
正直レベルが高すぎてついていけない部分もありますが、聞くだけでも知らない世界を知ることができるのでとてもいい刺激になっています。
先日Gitの新しいVerなんかがきましたが、私もTwitterで情報集め一応しているので発表された週には全体で共有されています。
さて、特殊例を話し終えたので一般的な1日について行きましょう。
1日の流れとしては大雑把にいうなら午前中コーディングお昼1時間休憩夜コーディング
いやー面白く無いですねwそんなんが聞きたいんじゃねーよ！って罵倒が飛んできそうです。
わかっています。これでは曖昧すぎて何も伝わらないので、1日という区切りを変えて一つのissue対応という観点で説明します。
1日ではなくissue単位のサイクルで考える
issueっていうのはバグだったり機能開発だったりリファクタリングだったりと後でやるべきこととして上がっているものです。
これに割り当てられたものをどんどんこなしていきます。最初のうちは仕様的な面でわからないこと多かったので社員さんと話して実装という流れでしたが、最近はissueに置いといたからよろしくって感じです。
さてissueをこなすサイクルとして基本的に4ステップに分かれていると個人的には思っています。
step.1 issueの理解
ここが一番重要です。自分なりに理解できれば自分の世界観で実装できますので。ここと次のステップで外部のやり取りが必要になってきます。
先ほど行ったようにわりと大雑把にタスクをもらうので、仕様面でわからないことが結構出てきます。
多分バイトということもあって最初から配属されているわけでは無いので、どのような動きになるかわからない部分があるということですね。
なので、まずは割り当てられたissueを理解して、全体的な実装の流れをイメージして把握する作業から入ります。
なのでここでは本格的なコーディングはあまりせず、他の実装と比べてあれと似ていそうとか考えたり、こういう感じでのコーディングで思っている通りの実装ができるかを考えます。
そして実装方法が複数ある場合には過去の実装例をみながらどっちがいいかなーなんて考えたりします。
おそらくJavaとかだと明確なコーディング規約があったりとかわりと制限きついと思いますが
Reactに関して言えばまだまだ実装に正解が無い世界です。
なので、疑いなく実装する力よりもどちらがいいかを考えられる方が全体的な発展に繋がります。
そして大体の実装が自分の中で完結したら、疑問点を先輩と共有に入ります。
step.2 実装の流れの確認と仕様確認（共有がメイン）
このステップでは社員さんに自分の考えと共に実装の指針が社員さんのイメージ通りか確認すると同時に仕様的に怪しい部分をすり合わせます。
今で自分が違和感を感じた部分っていうのは大体社員さんも納得してくれるし、すでに意図がある場合はキチンと説明もしてくれます。
なので、ここでしっかり自分の意見をいうことが大事です。
自分が考えている実装方の中で、どちらがいいか、前の実装がこういう感じだったのでこうしたいのですがーとか、こう実装していますが、これ割と大変だと思ってこっちの方がいいかなと思っていてとか、素直に全部話してしまいます。
そうすると大体、悩んでいることや、実装法について考えている部分は同じなので少し話し合いが入ります。
そして方針を決めるまでがステップ２ですね。
step.3 実装段階
ここから本格的に実装の処理に入ります。ここは多少なりわからないことが出てきても自分でグーグル先輩を使って調べたりすることで乗り切ります。
場合によってはいつでもできる部分なので複数のタスクが用意されているときには後回しにすることもあります。
リモートでも特に問題なく実装できるのはこのステップになります。
基本的には、過去の実装例などを見ながらコピペしたりして書いていきます。
ここ最近の感覚では７〜８割はすでに知っている内容。残り２割が知らなかったりする内容で調べたり、過去のコードを見ながら苦労しながら実装する部分になってきます。
step.3 PRを出してレビューをもらう
完成したらGithubにPR（プルリク）をお願いをします。
基本的にはやった内容を書いて実装中に出会った疑問点、確認しておきたい部分を記入しておしまいです。
先輩もすぐにレビューを見てくれるほど暇ではないので、私も以前出したプルリクのレビューを見直してそちら側の修正に入ります。
または、全て終了してしまう場合には先輩にタスクをもらってまたステップ1から始まるという感じです。
最後に 日頃から１機能実装の流れは真似できる
いかがでしたでしょうか。
意外とそこまでずば抜けてすごいことやっている部分はなかったのでは無いでしょうか。
特に駆け出しエンジニアの方で、自分でアプリ開発等を進めていくにあたって同じように一つの機能を順番に実装をしていくという形になると思います。
なので、実務で使うような意識を持ちながら、特に自分でGithubを作ってmaster branchを切って実装プルリクを出して承認とやれば１連の流れは真似できると思います。
日頃から意識するだけでも変わると思いますのでぜひ試してみてください！