【Rails】実務未経験の介護士が共同開発に参加して学んだこと

14455 ワード

Rails 共同開発 Ruby 未経験エンジニア Docker Ruby テキストリンク

0. はじめに

はじめまして！

この記事では、「実務未経験の介護士の私が Rails 共同開発に挑戦し、そこで学んだことや躓いたこと、反省した点」などについてまとめています。

チームでの開発現場経験を積むことで、「コミュニケーションの適切な取り方」や「わからない部分の質問の仕方」、「コンフリクトの解消の仕方」など、一人での学習では決して学ぶことのできない貴重な経験を積ませていただくことができました。

今回はそのような共同開発の現場で実際に学んだことをまとめて、今後の自分の成長につなげることができたらなと考えております！

1. 自己紹介

まずは簡単な自己紹介からさせて頂きます！

スペック
- 27歳
- 介護士 → エンジニアを目指している駆け出しエンジニア
- 学習中の言語：Ruby, Ruby on Rails
- 今後学習予定の言語や知識：Javascrict, AWS
趣味
- カラオケ（高音域が出ないことが悩みなので、いつかボイストレーニングを習いたい）
- 野球（球速は遅いが、コントロールには安定感がある）
- 筋トレ・運動全般（毎日頑張っています💪）
性格
- 介護士として忍耐強く働いてきたということもあり、衝動的な性格から理性的に行動するように。
- 比較的、温厚な性格だと思う。

2. 今回の共同開発に参加しようと思った動機

まず、「なぜ今回の共同開発に参加しようと思ったのか？」の根本的な動機の部分を述べさせて頂きます。端的に言うと、以下のものを「得たい！」と思ったので、共同開発に参加させて頂きました。

コミュニケーションスキルの向上
チームでの開発経験
問題にぶち当たった時に自分で原因を特定し、解決を図るための「自走力」
試行錯誤した上でどうしてもわからない場合、素直に質問できる柔軟性

これらのものを「共同開発」に参加することを通して獲得したいなと思いました。

結果的に、特に「コミュニケーション」の部分に関してはスキルの向上ができたのと、以前よりもより自信を持つことができた気がします。

ここについての具体的なやり取りに関しては後述させて頂きます！

3. Rails 共同開発で取り組んだ内容

共同開発で取り組んだ内容を簡単にご説明していきます！

成果物
- 今回の共同開発では「ECサイト」の購入者視点の画面の実装に取り組みました。

概要
- 開発期間：3/1 ~ 4/30（2ヶ月間）
- 週1回のチームミーティングを行い、進捗状況の確認を行う
- 週2~3回の作業会を行い、それぞれわからないところを質問し合う
構成メンバー
- 講師・TA：現役エンジニア2名
- 共同開発メンバー：現役インフラエンジニア1名、未経験2名
使用した言語・技術
- バックエンド
  - Ruby（バージョン：2.7.1）
  - Ruby on Rails（バージョン：6.0.3.5）
- フロントエンド
  - HTML5
  - CSS3
  - Bootstrap（5.0.0.beta2）
- インフラ
  - Docker
  - docker-compose
- データベース
  - MySQL2（0.5.3）
使用したツール・環境
- Slack：レビュー依頼、進捗状況の確認、日報の共有などをしました。
- GitHub：タスク管理・確認、プルリクエストを出す、コードレビューを受ける、受けた指摘に対応し、コミットを出すなどをしました。
- Googleドライブ：モックアップ、基本設計（ER図/画面遷移図）、画面定義書などのファイルを管理・共有のために使用しました。
- Git / Sourcetree：コミットやプッシュなどの git 操作をするために利用しました。
- Sequel Pro：DB を視覚的に管理できるツール
- Boost Note:「1タスク1メモ」といった感じで、学んで点や躓いた点を随時メモしました。
- DeepL：英語対策のための翻訳アプリ
- 使用したエディター：Visual Studio Code
- 使用したPC：Mac
ER図
実装した機能
- 新規ユーザ登録機能
- ログイン / ログアウト処理
- 商品検索
- 商品詳細へ
- カートへ
- カートを開く
- 購入確定
- Top画面に戻る
- 履歴を開く
- 注文検索
- 注文キャンセル
- ユーザ情報を開く
- ユーザ情報修正 / 退会処理
- 修正確定
GitHub
- https://github.com/quest-academia/qa-rails-ec-training-violet

4. Rails 共同開発で私が担当した箇所

①ユーザー登録ページ

「お客様情報登録」にお客様（ユーザー）が登録に必要な情報を入力するためのページを作成しました。

②商品詳細画面

■ 商品が存在する場合

■ 商品が存在しない場合

「商品詳細画面」を商品が存在する場合と存在しない場合の二つに分けて、それぞれの画面が表示されるようなページを作成しました。

③商品検索画面

■ 検索結果にヒットする商品が存在する場合

■ 検索結果にヒットする商品が存在しない場合

「商品検索画面」に検索フォームや商品の一覧、ページネーション機能などを入れて、お客様（ユーザー）が商品を検索できるようなページを作成しました。

5. 【必ず身に付けておきたい】講師に学んだプルリクエストの出し方

共同開発では、開発業務以外にも Git や GitHub の操作方法がとても学びになりましたが、その中でも特に「 Pull Request（プルリクエスト）の出し方」が個人的には参考になりました！

今後の開発を進めていく上での基礎として、必ず身に付けておきたいと思いました。

▼ プルリクエストを出す際の雛形となるテンプレート

以下は講師が提供してくださったテンプレートを元に僕が作成したプルリクエストの一例です。

プルリクエスト出す際は、以下のようなフォーマットをもとに作成しました。

プルリクエストの最終的な確認項目
- このプルリクエストで実行したこと（概要）
- 対象 issue
- 重点的に見て欲しいところ（不安なところ）
- 実装できなくて後回しにしたところ
- チェックリスト（動作確認・ rubocop の実行など）
- その他の参考情報（参考にした記事のリンクなど）

このようなフォーマットを元に書くことによって、レビュアーの方にとってわかりやすいプルリクエストの作成に繋がると感じました。

特に「重点的に見て欲しいところ（不安なところ）」の項目では、「問題に躓いた時にうまく人に頼れるスキル」も大事になって来ると思うので、不安だったことについては小さなことであっても、必ず書くようにしました。

また、予想完了時間や実質完了時間、作業内容、納期などもタスクに取り組む前に予測・設定しました。実務では「担当するタスクを細かい作業項目に分解して、一つずつ取り組んでいくスキル」が必要になってくると思うので、思いつく限りのことはなるべく言語化して書くようにしました。

作業内容は、最初は全ての作業項目を洗い出すことはできず、取り組みながら後から修正を加えたりしました。

ただ、プルリクエストを出してマージされるまでにかかった時間が、予想完了時間を大幅に超えてしまっていたり、納期が遅れてしまったりしたことは反省点です💦 はじめから無理な目標を設定しすぎない方が良いと思いました。

▼ 1指摘1コミット

また、コードレビューを受ける際は「1指摘1コミット」でやり取りをするようにしました。つまり、複数の指摘を同時に受けたとしても、対応する際は一つずつコミットを出して個別に対応していくということです。

これは講師の方から「意外と知らない人が多いけど、大事なこと」として教わりました。

以下のような感じです↓

基本的なことかもしれませんが、こう言った基礎的なことが個人的にはとても大事になってくると思うので、今後も実践を通して身に付けていきたいです。

6. Rails 共同開発で躓いた点・大変だったこと

共同開発において躓いたことや大変だったこと、またそれに対する僕の対応です！

主に、以下の2点でつまずきました。

① コンフリクトの発生
② if文を用いた View ファイルの条件分岐

① コンフリクトの発生

コンフリクト発生に関しては、共同開発が始まった初っ端から躓いてしまい、かなり焦りました💦

まだ始まったばかりなのにいきなり難しい問題に出くわして「自分にはやっぱり向いてないんじゃないかな・・・」と勘違いしてしまった記憶があります😅

その時はなんとか解決したいと思い、検索を繰り返し問題への対処に当たりました。

とりあえず問題の理解と解決策がなんとなく理解できたので、それを実行しようと思う意思とそれが今後の開発にあたり問題のない対処法かどうかを確認をしたかったので、講師の方に質問してみました。

以下が僕が講師の方に質問させていただいた際のやり取りの記録になります。

僕からの講師への質問（Slack より引用）文字が小さくてすいません💦

この質問への講師からの回答は１往復で済み、なんとか「コンフリクトの解消」にまで至りました！

とても嬉しかったですし、次回以降同じような問題に出くわしたとしても、以前のように無駄に焦ったりはしなくなりました。

② if文を用いた View ファイルの条件分岐

「if文を用いた商品に関しての条件分岐」については、 html.erb 内で if 文を使って「商品が存在するページ」と「商品が存在しないページ」に分岐することができるようにするタスクだったのですが、メソッドの書き方が間違っており、苦戦しました。

苦戦したコードの内容：商品テーブルから指定されたIDの商品の詳細を取得する

本来はコントローラー内で以下のように記載しなければなりませんでした。

def show
  @product = Product.find_by(id: params[:id])
end

しかし僕は、以下の二つの間違いをずっと繰り返していました。

def show
  @product = Product.find(params[:id]) # ← find_by を使ってない
end

def show
  @product = Product.find_by(params[:id]) # ← find_by の引数にカラム指定をしていない
end

最終的には講師の方に記述ミスを指摘してもらい、解決に至りましたが、「find_by メソッドを使う時はカラムを指定する」というところがすっかり抜けていました。

このようにコードの記述ミス然り、アルファベットの記述ミスやファイル名の命名違い、全角スペースでのインデントなど、細かいミスがまだまだ目立つなと思いました。

今後はこのようなミスをできるだけ少なくできるよう、必ず独自の「メモ」を取るようにして、同じ間違いを繰り返さない工夫をしたいと思います。

7. Rails 共同開発に参加して良かったこと

2021年3月頃までは僕は主に一人でプログラミング学習に取り組んでいました。

しかし、将来的にもしエンジニアになることができたら、一人での開発ではなくチーム単位での開発となり、お互いの進捗状況を確認しあったり、わからないことを相談しあったりするなどと言った「協調性」が必ず必要になってくると思いました。

そのため、早めにそのスキルを身につけておくことによって、「技術面でのサポート」はどうしても頂かなければならない時が多々あるかと思いますが、そのような技術的なサポートをして頂く際の「質問力」であったり、互いにスムーズで円滑なやりとりを行うための「コミュニケーション能力」の面においては、なるべく一緒に仕事をさせていただく方々の負担にならないようにしたいなと思いました。

また、個人的に「チーム単位での活動」や「誰かと協力すること」、「コミュニケーション能力」にいささかの不安があったため、実際の現場に近い環境で現役のエンジニアさんやチーム開発参加者たちと共に「テキストベース」や「 ZOOM などでお互いに顔を合わせた状態でのコミュニケーション」に積極的に参加して場数を踏むことによって、苦手分野を克服したいなと思いました。

たとえここで失敗したとしても、苦手分野の克服に挑戦したことによって自分なりの改善策や解決策などのデータが得られると思ったので、積極的に挑戦して行くべきだと判断しました。

ありがたいことに今回の共同開発では、みなさん向上心があり親切な方々ばかりだったので支えて頂いたことの方が多かった印象があるのですが💦 、それでも僕なりに役に立ちそうな情報は共有するようにしたり、読み手に負担をかけないわかりやすい文章を作成することにとても神経を使いました。

この経験によって、コミュニケーションのスキルが今までよりも段違いに向上したのではないかと思います。

8. さいごに【まとめ】

今回この「共同開発」というものに参加させてもらうことによって、

コンフリクトの解消
GitHub の見方・操作・やりとりの仕方
Git の操作やプルリクエストの出し方
開発するものに対する意思の疎通や進捗状況の確認
タスクへの取り組み方や管理の仕方

などの個人での開発・学習では決して学ぶことのできない多くのことを学び、経験させていただきました。

また、現役のRailsエンジニアの方からは「技術力は正直まだまだ足りてないですが、コミュニケーションの取り方はハイレベルですね」といった評価をして頂けたのはとても嬉しかったです！

今後はこれらのことをよりスムーズにできるようにブラッシュアップさせて、実務に入った時に周りの方々に「この人との仕事は余計なストレスがないし、スムーズでやりやすいな」と思ってもらえるように、備えて行きたいと思います。

拙い文章でしたが、最後までご覧頂き、ありがとうございました！

Author And Source

この問題について(【Rails】実務未経験の介護士が共同開発に参加して学んだこと), 我々は、より多くの情報をここで見つけました https://qiita.com/ino_kuni/items/e8e485df621ab2ca02db

著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。

Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .