はじめに
こんにちは株式会社SCOUTERでエンジニアをしているhirokinishizawaです。 業務では、SARDINEという人材紹介会社向けの業務管理システムを開発しています。
2019年2月1日でプログラミングというものに出会ってから1年が経ち楽しい時期やつらい時期もありましたが、1年間実務だけやってきた自分が得た教訓をプログラミングを始めたばかりの方やこれから始めてみたいと思っている方に共有をし、少しでもお役に立てればいいなぁと思います。
自分の経歴
入社する前
自分は日大付属の高校に通っていて特にやりたいこともなく大学受験をせずに卒業しました。(決して、決して行けなかったわけではないです!!多分。。。)
卒業をした後も特にやりたいことはなく主に軌道工事、塗装工事、屋上防水工事などいわゆる建築現場職人の仕事をしたり、土日などは父親の仕事の手伝いで3D図面を書いていたりしました。
そんな何の目標もないまま月日が流れ2018年1月に兄の繋がりで弊社CEO中嶋に出会いエンジニアという職業を知りその場で2月から入社をさせていただくことになりました。
入社してから
入社してからの流れは下記のようになります
ProgateでHTML&CSS、JavaScript、PHPを勉強 ↓ オウンドメディア作成(jsはほぼやってもらった) ↓ サービスLP作成 ↓ NuxtMeetUpのLT登壇 ↓ サービス開発
このような流れでサービス開発に合流しました。
ありきたりかも知れませんが自分の得た教訓をこれから話していこうかと思います。
1.遠慮するのは時間の無駄
これはエンジニアに限った話ではないですが経験者、未経験者問わず入社してからわからないことは多々あるかと思います。
- みんな他の仕事があるし質問するのは悪いのではないか。
- 質問の回答が自分の求めていた回答ではなく、その時に別の聞き方ができずもう一度同じ質問するのが気まずい。
- そもそも何で詰まってるのかがわからないから質問が出来ない。
質問したけど質問した内容の意味が分からない時に苦い顔するので再び質問しに行きにくいだったり、皆忙しいから質問しずらいだったり。いろいろな思いがあり質問しに行きずらいことがあるかと思いますが全て時間の無駄使いです、気にせず質問しましょう。
もちろん時間を割いて教えてくれるのですから最低限考えて質問しなければいけないとは思いますが、わからないものは一人で考えても分からないので、とにかく一つ一つ確認しましょう。
実際に自分は結構周りの目を気にしてしまうタイプで半年近くもの期間を無駄にしたなぁと今でも後悔しています。ですが困ったことがあったら質問する。再び分からなくなったら質問するを繰り返した結果自分の成長を実感できたのも事実です。
- 自分が質問する時に気をつけていたこと
- コードベースで話が出来ないぐらいわからない時はタスクベースでなにをしたいのかを伝えてまずは調べ方を教えてもらう
- 調べてもわからない時はどのように検索したのかを先に伝えてその上で相手だったらどういうような対応をするのかを聞く
- 言っている(回答の)意味が分からない時はちょっと止めてもらい出てきた単語だったりのメモを取り後ほど検索する
など意識していました。ただ自分は開発の質問をテキストでするのが苦手で口頭で聞きたいタイプなのですが、そうではない方もいるのでそこは臨機応変な対応ができる人になりましょう。
2.アサインされたら見積もりや設計を先にしよう
アサインされたのですぐにコードを書き始めるのは一見早いように思えますが、レビューしてもらう人に自分の設計の意図が伝わらず(そもそも設計が出来てないなど)手戻りが発生し結果遅くなることがあります。
現在弊社ではスクラムを導入しておりプランニングの時間をとってチームで見積もりや設計を行っております。フロントエンドが得意な人やサーバーサイドが得意な人、どちらも卒なくこなせる人などいろいろな人がいる中で見積もりを行うわけですから、導入してすぐの頃は見積もりがずれ当初決めていたリリース予定には間に合わなかったり、アサインされた人が設計をやったりしていたので分からない時もありコミュニケーションコストだったり手戻りが起きてしまったりした時にすごく時間がかかってしまうことがありました。
最近では認識のズレは改善されてきて見積もりも大幅にずれることはなくなり、プランニングで時間をかけて見積もりや設計を行うことによってコミュニケーションコストや手戻りが起こることがほぼ無くなってきました。
仮に個人で開発をするときでも自分だけが分かればいいのではありません。もし設計が苦手だとしても癖を付けるために他の人も触るという前提でコンポーネント設計など心がけるのがいいと思います。
3.一つ一つ順番に終わらせていく
タスクAのレビューをお願いしてその間にタスクBに着手しました。タスクBをやっている最中にタスクAのレビューが終わり修正が必要。そんな時にあなたはどちらを先にやりますか?「タスクAのレビュー対応がそこまで大変ではないので後回し」、「タスクBはまだまだ掛かりそうだから先にタスクAのレビュー対応しておこう」2つだけだったらなんとかなるかと思います。
ですがレビューをお願いしている人にも他の仕事がありレビューが遅れることもあります。タスクA、タスクBまで終わりレビューのお願いをしていてレビューが遅れてしまいタスクCを着手している時にレビューが返ってきてタスクA、タスクBともに膨大な手戻りが必要になった時。そこからさらに緊急度の高いバグ報告が来たら。他にも緊急度高い修正依頼が入ってきたら。焦ってしまいがキャパシティが小さい自分にとってはパンク寸前です。
エンジニアだけの話ではないと思いますがそれぞれタスク毎に何をやるべきなのか、その中で優先度が高いのはどれか。パンク寸前でも時間は待ってくれませんし、その時間に追われてどんどん焦ってくることがあります。ですが一度立ち止まって整理し一つ一つ終わらせていくしかありません。
実際に自分は一度にタスクが増えて焦ってしまい全部に手を出そうとして結果何も進まなかったということを何度かやってしまっています。今でもマルチタスクは苦手ですがメモを使い、やることを全て書き出してから優先度をつけてやっています。
まとめ
- 成長をするためなら自分より出来る人に質問するしかない(ある程度限度はあります)
- 見積もりや設計に時間を取られたとしてもしっかり行えばリターンはある
- 焦らずにやるべきことリストを作って優先度をつけてパンクしないようにする
もちろん自分の性格など関係するとは思いますが、この3つのことで悩んでいる方も少なくはないのではと思います。そんな方に少しでもお役に立ててたら幸いです!
最後に
弊社では事業・サービスが成長していくにあたってメンバーを増やしていきたいと思っています。
興味のある方は下記からご応募いただくか、@hirokiにご連絡ください!!