自己紹介

学習期間2年(RubyからPHPに切り替える)
開発系の企業に就職するが会社都合で退職
実務未経験(共同開発時)
Qiitaで技術記事を発信し、300記事以上投稿(学習を継続)
オンラインコミュニティーで勉強会を主催する
IT企業に勤務し、プログラマーを目指し学習中
共同開発では初学者と経験者がいる中でリーダーを務めた
初の実務案件に参加した時のことを書いていく

Qiitaアカウント

学習記録

概要

初めて参画した案件がIT教育企業の自社開発案件です。

⚫︎開発人数(9名)
・バックエンド6名
・フロントエンド3名
その内リーダー1名、レビュアー2名

要件定義

どういうサービスか

受講生の管理アプリの開発に参画させていただきました。
IT教育の企業様の案件で講師がオンラインの講座を作り、受講生がその教材を閲覧して
その進捗状況を確認できるアプリの開発です。

競合のサービス

●Teachable

●オンクラス

環境

テキストエディタ

インフラ

サーバーサイド

フロントエンド

タスクやスケジュール管理などのツール

1.GitHub
2.Swagger(OpenAPIを使ったスキーマ駆動開発)
3.Jira(タスク管理ツール)
4.Postman

テーブル設計やER図など

細かいER図やテーブル設計は外部には出せないのでざっくりとした内容のみにしておきます

受講生対講座　= 多　対　多

簡単なER図

全部公開はできないので1部公開します。

Instructers(講師) →　coursers(講座)
coursers(講座)　→ attendances
coursers(講座)　→ chapters
chapters　→ lessons
attendances → lesson_attendances
lessons → lesson_attendances
attendances　→ students

任されたタスクと実務で意識したこと

1.任されたタスク
⚫︎チャプター詳細画面表示（講師側）
（前の開発者がリクエスト・レスポンス作成済み）　
前の開発者からの引き継ぎとなりました。

1.編集画面：空の配列 return []; を返すようにコントローラ＋ルーティング作成
2.編集画面：DBからのデータ取得ロジック
3.リクエストファイルのバリデーション設定とリソースファイルのコード整形
4.認可処理の実装
5.coursesテーブルのstatus追加(講師側)

※5のタスクは実装箇所が多かったので複数に分けて実装した。

⚫︎2.実務で意識したこと
他にも開発初参画のメンバーが数人いて、Gitの操作がわからない方がいたので
自分がGitについて書いた記事を共有したり、有益な記事を共有して、未経験ながらも他のメンバーをサポートした。

ブランチのルール

①.topicブランチ作成
　　topic/jka-○○/lesson_edit
　　developからブランチ切った状態でpushしておく

②.topicブランチからfeatureブランチを切る
feature/noriaki/jka-〇〇/controller
作業完了したらtopicブランチに対してプルリクエスト作成→レビュー

ブランチ補足

featureブランチ -> jiraに割り当てられたタスク(子タスク含む)を
実装していくブランチ

topicブランチ -> featureブランチを取り込んで、１機能を完成させていくブランチ

学習と実務の違い

1.お手本が存在しないこと
スクールとかだとこうやったらこう動くよ！など教えてくれたりするかもしれないです。
しかし、実務案件だと自分がやったことないようなことを実装したり調べたりします。
自分の知識を総動員したり、先輩エンジニアに聞いたりして解決していく必要があります。

2.プロジェクトによって環境やツールが違うこと
自分が学習をしていた時はVSCodeを使ったりdockerを使っていましたが、
これだけではなかったりします。
プロジェクトによってはRedHat、CentOS、Ubuntu、Gitlab、Azure、GCPなど
なかなか学習では出会わないようなツールを使うこともあります。

3.実務ならではのツールを使うこと
Jiraやswaggerなど個人学習では普段使わないようなツールを使います。
人によってはdockerなども使わない場合もあるかもしれないです。
前もって調べたり使ったりする必要があります。

4.チーム開発になること
学習みたいに個人開発をすることはほとんどの場合ありえないです。
Git操作や他人や読みやすいコードなど配慮が必要です。

5.ファイルやディレクトリの数が学習よりも多いこと
ファイルやディレクトリの数は個人学習よりも多くなります。
ディレクトリやファイルが60個などあったりします。まだリリースはしていなかったので
もう少し小さいプログラムでしたが、プログラムの量は学習とは比べ物にならないです。

6.すでにあるコードで開発を始めること(学習みたいに0から作らない)
プロジェクトの途中から参画したり、リリースした後の改修作業などすることがあります。
他人のコードを読んでいくし、他人が読みやすいコードで書いていく必要があります。
laravel createやrail newみたいなコマンドは滅多に打たないです。

7.プロジェクトによってルールがあること
自分が入ったプロジェクトではviewはバックエンドの実装者は使わない方針で、postmanだけで挙動を確認する案件でした。現場によってルールが違うことを学びました。

8.世間でよく言われるプログラミングは仕事の一部だったりすること
開発の仕事は僕も実務案件に入る前に、現役のCTOに聞いたりして仕事の手順や流れを調べて書いた記事がありますので良かったら読んでみてください。(あんまり大した実装もやっていないので説得力はないかもしれないですが)

9.動いたからOKではないこと
動いたとしてもビジネス側の要求やセキュリティや品質などを考慮できないとマージはされません。
そのくらいいいじゃないかと思うこともありますが、そのくらいいいじゃないかの部分が大事だと教わりました。

10.納期があること
自分が入った案件は自社開発の案件かつ短期間のアサインだったので
納期までは時間があったので特に納期に自分の場合は追われることはなかったですが、
いつまでにこのタスクをやってという期限は決められてました。

苦戦したこと、指摘されたこと、

1.書き方は現場に合わせること
viewは基本バックエンド開発者は実装しないはずがviewを返す記述をしてしまったことや他のリクエストファイルの記法に揃えるべく、配列形式の記述で書き直すように指摘されました。この他にも指摘が入った。

2.GitのデフォルトがmainブランチになってしまっていてPR出せなくなってしまったこと
今回はmainブランチに影響はなかった。Git操作は慎重にやっていきたい。

3.前任者のタスクの引き継ぎでタスクの理解が曖昧になってしまったこと
先輩エンジニアに自分が確認しなかったので、タスクに余計な時間がかかってしまった。
次回からはタスクの内容などを確認していきたい。

4.読みづらいコードを書いてしまい、レビュアーに負担をかけてしまったこと
シンプルなコードで書かなければ、後から参画してメンバーなどがコードが読みづらくなってしまい、
サービスの品質が落ちてしまうのでコードの品質には妥協しないようにしていきたい。

5.不要なファイルは消す
PRを出す前に不要なファイルは残さないことを心がけたい。

6.タスクの理解を徹底する
認可処理の実装をやっている時に、タスクの内容があまり理解できず、
的外れな実装をしていたので、タスクのゴールを把握していきたい。そのために
タスクを振っていただいたエンジニアにゴールを質問していきたい。

7.コードを書いた時のコードの意図を理解する
自分で書いたコードでなんとなくで書くのではなく、必ず意図を説明できるようにしたい。
コードを説明しながら書けなかったのが反省点。ペアプロでなんとか解決できた。

8.PRの時に実装とは関係ない修正は含めない方が良い
実装と関係ない修正がされた状態でPRを出してしまった。
何か意図があるならPR時に説明する必要があった。

9.postmanを使いこなせていなかったこと
講座登録をpostmanで確認していた時エラーがでていることを確認できておらず、PRを1度出してしまった。原因はPOSTで送るとこをGETで送ってしまっていた。SwaggerでURLの確認をし、エラーを解決できた。初歩的なミスでもあったのとpostmanの使い方がわかっていなかったことが原因でした。　

10.報連相はこまめにする
何かタスクをやった後は必ず報告をするように指摘されました。
初歩的なミスだったので反省しました。

11.Githubを環境を合わせること
レビュアーのコメントに対して返信したはずがレビューに返信が送れていませんでした。
原因は自分のGithubのアカウントがChromeでログインしていなくてSafariでログインをしていました。
レビュアーはChromeでプルリクエストを確認していたので
自分がChromeにログインしていなかったのでレビュアーに自分の返信が送信できていませんでした。
PRを出すときの作業はChromeで統一した方がいいと思いました。

これから実務で取り組みたいこと

1.問題意識を持つこと
言われたタスクをやるだけではなくて業務改善提案などもできるようになっていきたい。

2.後から入ってきたメンバーに教える立場になっていきたい
1年以内に仕事に慣れて、後輩などができた時に自分が教える側になっていきたい

3.5年以内にチームリーダーになれるようにしたい
タスクがこなせるようになるのは1年以内で、3年以内には教える立場になり、5年以内に開発リーダーになれるようになりたい。

4.フロントエンドの実装もできるようになりたい
今回はBootstrapなどを使った実装ですが、Reactなどを使って実装できるようになって
フルスタックエンジニアを目指していきたい。

5.AWS(インフラ)の理解も深めていきたい
インフラを学び、アプリがどう動いているのかを深く知りたい。
あと、今回はAWSの環境での開発ではなかったのでAWSを使って実務をこなしていきたい

Postmanの使い方

APIを扱った現場では、よく使われます。

実務に入る上での有益資料

1.学習と実務の違い
学習とプログラムの違いをベテランエンジニアでスクールメンターの方の説明が載っています。
Rubyですがソースコードも見ることができます。

2.実務にアサインされたらどうするのか？
実務にアサインされたらまずどうするのかについて細かい説明が載っています。

3.スプリントとは何か？
先輩エンジニアからスプリントという言葉が出てきた最初は何のこと？って感じでした。
そこで自分で調べてみました。
スプリントはスクラム開発の考え方で、時間を細かく区切り、その中で目標を立てて開発して行きます。

実務未経験から実務案件に参加した方の記事

実務未経験から案件に参加した方の資料をこの記事以外にも紹介します。
参考にしてください。

まとめ

まだ実務をやって1ヶ月です。この案件はもう1ヶ月続きます。
残り1ヶ月で少しでも何か吸収していきたいです。また案件が進み次第更新していきます。