エンジニアとして一年間働いたので、振り返る。
はじめまして。こーへいです。いつもは大学決算について書いていますが、今回は自分のことについて書きます。大学決算は一ヶ月ぐらい更新が止まっていますが、10月はいくつか書いてみようと思っています。なので、もうしばらくお待ち下さい。
今日は「エンジニアとして一年間働いたので、振り返る。」というテーマで以下のようなことを書こうと思います。
・これまでにやったこと/それに対する反省/現状はどうなったか
・エンジニア研修(2017年4月上旬~2017年9月中旬)
・仕事ナビリリースまで(2017年9月下旬~2018年3月下旬)
・リリース後半年(2018年4月上旬~2018年9月下旬)
・これからやりたいこと(2018年9月下旬~2019年3月下旬)
・終わりに
ちなみに、どうしてこんなことを書こうと思ったか？というと、大変お世話になっている&ご迷惑もおかけしている上長に「半年の振り返りやるで〜」みたいに言われて、「どうせなら、ソーシャルに公開するつもりで書いてみよう！暇だし。」と思ったのがきっかけです。
エンジニア研修(2017年4月上旬~2017年9月中旬)
僕は株式会社LITALICOというところに2017年4月1日にエンジニアとして入社しました。ただ、プログラムというものをまともに書いたことがなかったため、新卒の人が受けるエンジニア研修を受けることになりました。
内容については書きませんが、終了するまでに4月~9月中旬の5ヶ月ほど掛かりました。大学の授業があるなかで、なかなかハードな研修を終えるのは大変でしたが、あの研修がなければ、今の自分は存在していないので、良かったと思います。
研修では「物事を正しく説明する姿勢」「物事を正しく学ぶ姿勢」「タスクの終了時期を明確にする大切さ」などを学んだ気がします。ただ、できていたか？と言われると、「No」でした。今でも「Yes」と言えないですが、当時に比べれば遥かに良くなったと思います。
仕事ナビリリースまで(2017年9月下旬~2018年3月下旬)
この辺りからが本題です。研修を終了したあと、すぐに当時の新規事業開発室に配属されました(現LITALICO仕事ナビ事業部)。
配属当初はペアプロという手法で開発をしていました。ペアプロについてはこの記事がわかりやすいと思います。
簡単に言うと、「一人がPCを使ってコードを書き、もうひとりがそのコードを書いている人に指示やアドバイスを行う開発スタイル」です。
基本的には社員とインターンというペアで開発が進みました。このときの僕は「社員がコードを書いているときは、わからないことが多くて」「僕がコードを書くときは、社員の言いなり。」みたいな感じでした(ちょっと盛ってるかも)。
このときにどうしてこうなったのか？というと、適切なタイミングで適切な質問ができなかったからです。
例えば、コードを書く人がスラスラとコードを書いていて、僕がそのコードがどうして書かれたのか分からないとき、質問ができません。
質問ができないのは今思えば、「質問する機会がなかったから」が大きいと思います。今思えば、小学校~大学と人に何かを質問するという経験をしたことがあまり記憶にありません。強いて言うならば、大学受験の時にお世話になった塾の先生に対してはめちゃくちゃ質問しました。
当時、どうして質問できたのか？というと、僕は早稲田大学に行きたかったのですが、本格的に受験勉強を初めた高校3年生の夏、僕の学力はとてもじゃないけど、早稲田大学に合格できそうになかったです(実際受からなかったしw)。
0から一人で難しい問題を解けるようになるのは時間的に厳しいと感じました。なので、一人で悩んでいても分からないところはチェックだけしといて、解き方や答えを知っている塾の先生に聞くのが手っ取り早いと思っていたので、そのようにしました。
これは仕事でもそのような思考になるべきです。
ただ、上長にすぐに聞けない理由は
・ここで聞いてしまうことで、僕は勉強の力が付かないのではないだろうか？
・上長、忙しそうだしなぁ
・最近、何か話しかけづらいんだよなぁ
と思っていたからです。
他には
・一人で色々な技術ブログやドキュメントを読んでいて、人に聞くという選択肢が頭の中から消え去っている。
からです。たぶん、他にもあります。
最近はこのような悩みはそれなりに解消されました。解消された理由は
・分からない状況が続くと、上長の忙しさを加速させてしまうことに気づいた。
・分からない箇所を勉強するにも何を勉強すれば良いのか分からないので、聞くしかないということに気づいた。
・飲み会とかやっているうちに、上長と仲良くなった。
という要因があると思います。
特に3つ目は大きかったと思います。僕は人との距離感を詰めるのが苦手なので、職場という比較的フォーマルな場でどうやって距離を詰めればいいのかイマイチ分かりません。しかし、飲み会というカジュアルな場であれば、上長もアニメや漫画、彼女がどうだ、みたいな話が多くなります。そうすると、だいたいの人とは仲良くなれるので、職場でも話しかけやすくなります。現に、開発チームでの飲み会が4月~7月の間行われなくなった時期がありました。その時期と僕が質問がしづらくなった時期が重なっていました。それに気づいて、上長との心の距離感が遠くなったことで質問ができなくなったのでは？と思いました。
それと、僕はSNSはめちゃくちゃうるさいです。そんな僕を見た同期が「SlackをSNSだと思って困っていることをつぶやけば？」と言われました。
その作戦がうまくいき、かなり上長に質問や困りごとの共有ができるようになりました。
今でも「質問しづらいなぁ。」と思ったら、Slackなどのオンラインツールで質問や困りごとの共有を行うようにしています。
ただし、比較的適切なタイミングで質問はできるようになりましたが、適切な質問ができているか？というと、ケースバイケースです。この辺はもっと工夫したいところです。
そして、質問は段々できるようになって、リリース間近になってきました。
リリース前は機能としてはかなりの部分が出来上がっており、後はサイトにデザインを当てていくという段階でした。僕はあるページのデザインをHTMLとCSSを用いて、モックの通りに実装するというタスクを割り振られました。このときにはチーム内の事情でペアプロは行われておらず、僕一人に大きいタスクが割り振られました。
当時の僕にとってはそれまでにやったことのある最も大変だったタスクの軽く3倍以上、大変な仕事だったので、完了させるのにとても苦労しました。
どういうところに苦労したか？というと、
・タスクを間延びさせずにしっかりと着地させる。
というところです。
具体的に言うと、
・このタスクのゴール状態は何なのか？を定義する。
・期限を自ら決めて、どのようなスケジュール感で完了させていくのか？を決める。
・実装する
ということだと解釈しています。
今の僕にとってのタスクのゴール状態とは「モック通りの実装されていること」「要求を満たしている機能を作ること」です。
最近はこのまま行くと、ちょっと微妙だと思いました。その先にどのようなロジックがあるのか？どのような数字を追うためにやっているのか？その数字を追うと、ユーザーはどうなるのか？チームはどう助かるのか？とかもっと大きく言うと、会社はどうなるのか？社会はどうなるのか？というのを見ていないから微妙だと思いました。
ただし、それはこれから意識することにすればいいので、気にしません。
今の僕にとってのゴール状態はそれなりに満たすことができるようになってきました。どうしてできるようになったのでしょうか。理由は
・Ruby/Railsでの実装力が上がった。
・モックや要求を見れば、ある程度どのような実装にすればいいか検討が付くようになった(設計力が上がった？)。
が挙げられると思います。
配属当初は研修が終わったいえ、僕自身は簡単なECサイトを研修で作ったことがあるぐらいで実装力・設計力は乏しかったです。当時に比べれば、web applicationを作る実装力はかなり付きました。今なら、一般的なweb applicationなら、それなりに作れると思います。まぁ良くないコードもたくさん書くと思いますが、形にはできると思います。
ちなみに、設計力が付いたなぁと思ったのは「コードを書く手が、思考が完全に停止することが少なくなった。」「完全に停止しても相談することが昔よりも明確になっている。」という実感があるからです。
この実装力と設計力は配属当初から僕のなかで一番伸びたところだし、すごい自信になったところでもあります。
期限を自ら決めて、どのようなスケジュール感で完了させていくのか？という点ではタスクのゴール状態を実現するには何をすれば良いのか？というのを考えるようにしています。それでゴール状態を完了させるのは二週間後だから、一週間後までにはこれとこれを終わらせて、十日後にはこれとこれを終わらせて、二週間後にリリースする。みたいに作ります。
ここでその通りにできればいいですが、物事はそこまでうまくいきません。そういうときは
・期限をずらす
・誰か他の人にタスクを依頼する
・ゴール状態を変更する
という3つを考えるようにします。
例えば、本来の要求からさらに要求が増えた時に、見積もっていたゴール状態を実現するためにやることが増えます。
その時に
・本当は二週間後がリリースだが、三週間後にリリースする→期限をずらす
・二週間後にリリースするために、一人でやるべきことだったタスクの一部を同期や上長にやってもらう→誰か他の人にタスクを依頼する
・二週間後に、〇〇というゴール状態を達成する予定だったが、ゴール状態を✗✗という風に変更して、二週間後にリリースする→ゴール状態を変更する
みたいな選択肢が考えられると思います。
と、「タスクを間延びさせずにしっかりと着地させる。」というのもそれなりにできるようになりました。
これからはタスクを完了させる量を増やすことで更に改善点を見つけて、もっと早く多くのタスクを完了させたいです。
リリース後半年(2018年4月上旬~2018年9月下旬)
リリースしてから半年はざっくりいうと、管理画面の認可の仕組みや新規機能の開発をやりました(というかやっています)。
これらはそれまでにやったことのある最も重たいタスクの5倍~10倍は重たかったです。
なので、最初は「俺ってまじで仕事できないやつやん、、、。」という絶望感に打ちのめされていました。まぁ今でもそうなるときはありますが、これまでで一番そのように感じました。
こうなってくると、仕事が本当につまらないし、働くのが辛くなってくるし、個人的に閉塞感が出てくるので、さらに仕事するのに悪影響が出てきます。
どうしてこうなってしまったのか？というと、
・いつ終わるのか自分で全く見積もりが建てれていなかった
・エンジニア以外とのコミュニケーションが取りづらかった
とかがあったと思います。他にもあると思います。
1つ目がかなり大きかったです。見積もりが曖昧だった時期が長くて、曖昧なまま仕事をしていました。曖昧だったことは
・このタスクのゴール状態は何なのか？
・期限を自ら決めて、どのようなスケジュール感で完了させていくのか？
の2点です。
この2点を明確にした後は苦労はしましたが、なんとか形にできました。
今(8月初旬~9月末)は上で述べてきたことをフル活用して新規機能の開発に当たっている時期になっていると思います。
これからやりたいこと(2018年9月下旬~2019年3月下旬)
上でこのようなことを述べました。
最近はこのまま行くと、ちょっと微妙だと思いました。その先にどのようなロジックがあるのか？どのような数字を追うためにやっているのか？その数字を追うと、ユーザーはどうなるのか？チームはどう助かるのか？とかもっと大きく言うと、会社はどうなるのか？社会はどうなるのか？というのを見ていないから微妙だと思いました。
ただし、それはこれから意識することにすればいいので、気にしません。
これらは「やりたいこと」というよりは「やらなければならない」ことですね。ただ、やらなければならないことこそ、しっかりとやらないといけないと思うので、しっかりきっちりやっていこうと思います。
・タスクの先にある改善したいことを把握する
・それを改善することでユーザーにどのような影響があるのか考えを持つ
・LITALICO仕事ナビ事業にどのような影響があるのか考えを持つ
これら3つを意識しようと思います。
やりたいことは
自分で自分がやるべきことを提案し、それを完了させること
です。
提案するべきことは
・チームの中で緊急度・重要度高めなこと
です。
緊急度と重要度は上で挙げた3つの意識しなければならないことを意識しないと、判断できないと思います。
終わりに
一年間事業会社でエンジニアとしてバイトをしていましたが、モックがあれば、それなりにweb applicationを作れるようになったと思います。
ただ、良いものを大規模に早く作っていくというのはまだまだできそうにありません。上に挙げたものが完璧にできてもまだまだ足りないと感じるでしょう。
でも、まだ見ぬ理想に必要なことに違いはありません。理想に届かない現状から少しだけ、ちょっとずつでも良い、でも確実に、できるようになろうと思います。それを死ぬまで続ければ、人生楽しそうだと思います。
P.S.
このnoteを書くのにめっちゃ時間かかった。辛い。
この記事が気に入ったらサポートをしてみませんか？