エンジニアになってから半年でやってきたこと

2021年9月11日 18:14

未経験からエンジニアになってどんな仕事をしたのかについて書いてみようと思います。

まず僕がこの題材で書こうと思った理由は主に2つありまして、まず1つ目が自分自身が実務未経験の時に実際にエンジニアになれた人の仕事内容を知りたかったからです。

なので、過去の自分に教えてあげるつもりで書いてみようと思いました。それが結果的にこれからエンジニアを目指す方の参考になったらいいなと思っています。

2つ目が自分の成長を記録として残しておきたいからです。日々仕事をしていると分からないことだらけであまり成長を感じる機会がないのですが、この半年間を振り返ることで少なからず成長できているところを実感できそうかなと思いました。

読みやすいように今回は短めにまとめようと思いますので、もし個人的に知りたい事がありましたらツイッターのDM（@amop_alor）で気軽に質問いただければと思います。

僕が入社半年で経験したことはこちらです。

- プログラミング課題
- 既存のWebサービスの改修
- 新規開発案件のドキュメント、ワイヤーフレーム、画面遷移図作成
- スマホアプリの開発

3分弱ほどで読めるようにしていますので、ぜひ最後まで読んでいただければと思います！

- プログラミング課題

主に入社1ヶ月目に取り組んだものになりまして、課題の内容は

・Docker、Laravel、MySQLでCRUDができる簡単な掲示板サイトを作成する
・ORMをつかうこと
・毎日進捗をgitにあげて、プロフィールのコントリビュートからみれるようになっていること
・開発したソースに対して、unitテストを作成して、パスしている状態にすること
・フロント画面をVue.jsかReactを使って構築し、スマホ対応していること

こちらの項目をクリアすることでした。1週間〜2週間ほど実務中の時間を使って取り組みました。

フロントにはVue.jsを使ったのですが元々ある程度JavaScriptを触っていたのと、独学でVue.jsを触っていたのでそこまで困ることなく実装できました。

プログラミングスクールではRuby/Ruby on Railsを使用していたためPHPの書き方に若干の違和感を抱えながらコードを書いていましたね。

-既存のWebサービスの改修

PHP/Laravelが使われていてView周りの改修やテストの追加などの業務をやっていました。

このWebアプリはDDDで開発されていたため最初の頃ディレクトリ構造を理解できずDDDの入門書を読みながらテストを書いてレビューもらって書き直してみたいな事をしてました。

実際に僕が読んでいた本が「ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本」というものです。

- 新規開発案件のドキュメント、ワイヤーフレーム、画面遷移図作成

ドキュメントは要件定義書、基本設計書、テスト仕様書、開発工数見積もり、質問シート、運用フローなどを作成しました。

また、要件定義書に従ってワイヤーフレームを作成してデザイナーさんにデザイン作成を依頼したり質問シートでデザインの質問をしてました。

ドキュメントの作成は正直ものすごく苦労して、何度も書き直したり、仕様漏れが合って社長に怒られたり色々ありました。。笑

- スマホアプリの開発

新規で開発しているアプリはアプリ側にReact NativeとTypeScript、バックエンドにPHP/Laravelを使用していて、僕は主にアプリ側の開発をしています。

今までReactの開発経験も無かったので、UdemyでReactやReact Nativeの講座を購入して勉強したり、外部エンジニアの方で大手金融系のスマホアプリ開発を担当された方にReact Native製のニュースアプリを書いて頂いてそれをひたすら読み解いて同じように自分でもアプリを作成したりしていました。

- 一日の流れ

弊社は基本的にリモートになっているので、朝8:00頃に起床して朝食を食べ、始業時間の10:30まで自主学習やスケジュールの確認、タスクの整理などをして、大体定時の20:00（休憩が1時間30分あるため実働8時間）まで仕事をして、その後は夕食からの1時間ほど自主学習&Twitterという流れです。

- 報告など

進捗の報告は主にBacklogというタスク管理サービスを利用して、スクラム体制で開発をしています。

一つのタスクを約2時間くらいの単位で切り出したものをチケットとして管理し、レビューを求めたり予定時間や実績時間を入力して開発時間に遅れがないか都度確認をしながら進めています。

また、業務開始時に、

- 今日やること
- 懸念事項

業務後には、

- 今日終わったこと
- 終わらなかったこと
- 振り返り＆対策検討

をSlackで毎日報告しています。報告ってものすごく面倒くさいしやりたくない仕事の1つですが、これをするかしないかで上司からの信頼度がかなり変わってきます。

終わってないものは隠さずに終わっていない事を伝えますが、ただ終わっていませんと伝えるのではなく、いついつまでにデザイナーさんからデザインの修正を頂けるのでそれを確認し次第こちらのタスクに取り掛かかる予定でして完了までおそらく〜日ほどかかる見込みですなど、どうやって終わらせる見込みなのかを示してあげると安心してタスクを任せてもらえるようになります。

ここらへんは以前の営業経験で養ったものですが、相手の期待値をコントロールするのが結構大事だと思っています。

- 最後に

ここまで読んで頂きありがとうございました！
今回あまり深く掘って書いてませんが、自分が当時知りたかった情報の粒度で書いてみました。

もし「もっとこの情報について知りたい」とかありましたらお気軽に@amop_alorのDMにメッセージ下さい！

今後も定期的に発信して行く予定ですので、もしよろしければフォローと♡を押して頂けると嬉しいです。ありがとうございました！

この記事が気に入ったらサポートをしてみませんか？