概要

某自社開発の案件。サービスはホワイトニングサロンの予約サイト(すでにリリース済み)。

使用技術

⚫︎言語、フレームワーク

• Ruby
• Ruby on Rails(バージョン7)
• RSpec
• RuboCop
• haml(view)
• TypeScript
• React.js

⚫︎周辺ツール

• GitHub
• GitHubProjects(タスク管理)
• MySQLWorkBench
• CodeRabbit

⚫︎インフラ

• AWS
• Terraform
• Docker
• GitHubActions(CI/CD)

設計手法

• ドメイン駆動設計(DDD)

• DHH

コメントの形式

YARD形式でした。

変数命名

複数形名詞や不可算名詞に、『s』をつけるときがある。
例えば、mediaをmedias、informationをinformationsなど

リファクタ

この記事を参照

Railsのデザインパターン

共通化

yamlファイルで共通化

Gitのブランチ運用

developmentブランチがなく、mainブランチにそのままプッシュする。

参画時の現状

Activeユーザー数千人。
マーケティングにお金を使いすぎて開発にお金を使えなかったので
これから開発にお金を使い、サービス拡大していく。これから一部上場を目指す❗️

自ら進んで行った業務改善提案、タスクなど

提案

• 環境構築のためのオンボーディング資料作成
  自ら提案。
  ・オンボーディング資料がわかりづらくなっていて、
  新しく参画する方が環境構築などが詰まってしまう問題があったので、現場に状況を伝え、自らISSUEを作成しドキュメントを作成。
  環境構築とオンボーディングがやりやすくなったと現場から評価をいただきました。

ex)dump_data流し込み。SlackとGitHubの連携、ドキュメント編集権限付与、業務委託向けの請求書の作成方法、定例会のZoomのURLを貼っておくなど。

• 新規参入者のための仕様理解のドキュメント作成(情報共有をするため)
  現場のリーダーですら、仕様を把握できていないという問題があったので、
  仕様書の作成をし、新規参入者やビジネスサイドと連携するためにドキュメントとしてまとめた。

• Releasenote作成
  顧客と連携を取るためのドキュメント

【具体的事例】
・オンボーディング資料がわかりづらくなっていて、
新しく参画する方が環境構築などが詰まってしまう問題があったので、現場に状況を伝え、自らISSUEを作成しドキュメントを作成。
環境構築とオンボーディングがやりやすくなったと
現場から評価をいただきました。

ex)dump_data流し込み。SlackとGitHubの連携、ドキュメント編集権限付与、業務委託向けの請求書の作成方法。
定例会告知。

・フルタイムで働けていないエンジニア方が複数人アサインされて
いて現場で情報共有ができていない問題があったので、
自ら情報共有のためのドキュメントを作成し、情報を可視化できる
ようにしたので、開発効率が上がったと現場から評価されました。

・仕様理解のためのドキュメント作成を提案。
仕様がわかりづらく新規参入者の仕様理解が遅い課題があった。

仕様書の作成により、
ビジネスサイドと開発チームの潤滑油のような存在。

・git pull –rebase のコマンドを提案、採用
自分のQiitaの記事が現場のドキュメントに採用

顧客に向けたリリースノートの作成。(書き方の注意点をまとめたドキュメント作成。お手本のサンプルなどを貼って対応)

Wantedlyなどの採用で日程調整機能を提案する(採用のコミュニケーションコスト削減)。
Spir、TimeRex、easyなど
採用ツールもGrennやindeedなども提案する。

タスク

バグの修正や改修のチケットが多かったです。
1.環境構築
特に苦戦したのがdump_dataの流し込み。(本物のデータの流しこみ)

2.環境構築時にコンソールに出てる無駄なエラーをなくす。(バグ修正)
他の方と想定通りのエラーが出なかったので報告。

3.停止ストアにカレンダーが表示されないようにする(viewのバグ修正)
haml独特のインデントエラーに苦戦。

4.storeページで未ログイン状態にて日時選択をすると会員登録ページに飛んでしまう(バグ修正)

5.電話番号のバリデーション作成

6.Adminのusersの画面で未使用回数券の枚数確認ができるように表示
(CTOの工数削減と顧客からの要望)

7.Adminのusers画面の予約履歴の表示
(顧客からの要望)

8.Adminのusersのshow_serviceのテスト(RSpecのテスト実装)

自身のよかったところ(Keep)

1.絵文字などテキストコミュニケーションで気を使うことができた
2.オンボーディングの資料を自ら作成。ISSUEも作成した。

自身の反省点、苦戦したこと(Problem)1月

1.環境構築時に、OSやDockerのバージョンが古くて整合性が取れなくなってしまった
2.仕様書を書いている時に、〇〇さんと✖︎✖︎さんは開発がわかりませんという記載。これだけだと失礼
3.正規表現では、コメントを書いた方がいい
4.予期せぬエラーが発生した時に原因が特定できなかった
5.リリースノートの書き方が悪かった
6.スクショでエラーを見せることができず、わかりづらい質問になってしまった。
7.envにDB情報があることを知らなかった。
8.ISSUEを作った時にAsginerの設定を忘れた。
9.動画でdevtoolsの画面を見せる時に相手に知りたい情報が伝わらなかった。
10.仕様書を書いている時に、〇〇さんと〇〇さんは開発がわかりませんという記載。これだけだと失礼。
11.優先度を考える。
12.質問を明確化する。
13.シェルスクリプトの理解ができていなかった
14.devtoolsの理解が足りていなかった

自身の改善策(Try)1月

1.バージョンアップは必ずする。そのためにストレージは余裕を持っておく
2.この2人はビジネスサイドの方と修正。できないことより、できることを記載すべし
3.正規表現ではコメントを書く
4.***binding.pryをbase〇〇.rb(継承元)で使う
5.先輩からフィードバックをもらう(ダブルチェック)
6.スクショでは必ずエラーの箇所を貼る
7.覚える
8.メモしておいて確認する
9.画面全体を録画する。ログを大きく表示するようにする
10.この2人はビジネスサイドの方と修正。できないことよりできることを記載。
11.優先が高いissueかを必ず質問する
12.この質問はわかりやすいかを一度自分でフィードバックする
13.実務でやったことを復習
14.devtoolsの使って練習、調べる

自身の課題(Keep)2月、3月

1.予期せぬエラーが発生の原因を特定できなかった
2.each文の中でインスタンス変数と間違う
3.購入日はcreated_atカラムなのに、purchase_dateカラムを追加してしまう
4.エラーを追う時はbinding.pryを使う
5.show_service.rbで実装後に予期せぬエラーが発生した時に、原因特定できなかった
6.タスクのゴールや状況がわからなくなってしまった
7.チケット枚数をviewの画面に表示させる時、動作確認をしているユーザーがそもそもチケットを持っていなかったので、なかなか動作確認が取れず、工数がかかった。
8.RuboCopフォーマットの指摘で、issueと関係ない修正があった。
9.複数のidを取得しているので、@store_idsのような変数名に変更
10.使っていないインスタンス変数は使わない
11.変数名が適切でないことがあった
12.動作確認時に、localhostで確認できれば、onlockでの確認は不要
13.使わない変数(each文で使った時)
14.タスクの背景の理解不足(CTOの工数削減が目的だった)
15.レビューの時のコミュニケーションミス
16.unused_tickets、ticketsなどのチケット枚数の変数だが変数を変えなかった。
17.NameError in Franchises::UsersController#show
uninitialized constant Franchises::Usersのエラーを解決できず
18.質問で何がわからないのかをうまく伝わらなかった
19.def plan_type(plan_type)みたいに、メソッド名が、カラム名と同じで誤解を招く命名になってしまっている。
20.Viewでしか使わないロジック＆＆特定のModel（Reservation）に依存するメソッドはhelpersに書くべきではなかった
21.質問の意図がうまく伝わらなかった
22.スキル不足
23.不明点に対してはっきり言わないことが多い
24.レビューの漏れ
25.CSSもっと学んだ方がいい
26.CSSより開発の方が好きみたいな発言(Web制作を馬鹿にするように聞こえてしまう)
27.ChatGPT依存しすぎ
28.仕様書のフォントとか揃える。不要な記載はしない
29.変数などの単数形、複数形に注意
30.原因特定の切り分けをやる
31.コードを書くときにデータの処理が追えていない
32.基礎理解が不足していて、処理が理解できていないことがあった
33.subjectの提案をした時に、代替え案を出せなかった

自身の改善策(Try)2月、3月

1.base_serviceなどの継承元が原因だったので、binding.pryを入れる
2.覚える
3.一度確認する
4.binding.pryを使いながら処理を理解していく
5.継承元のbase_service.rbでbinding.pryを使う。今回はeの内容をbinding.pryを使うべきだった
6.紙に書いて状況を整理する
7.タスクの背景まで考える。リリースしてるかしていないか確認する。 チケットを持っている人で動作確認。ここではビジネスサイドの方、または自分でテストデータを作って、チケットを作成する。
8.RuboCopフォーマットで修正された内容(実装とは関係ない修正など)は、GitHubでコメントする
9.複数のidを取得している場合は変数名を複数系にする
10.これは必要な変数か必ず確認する
11.何をやっている処理か確認してから変数名をつける
12.この2つの仕組みを理解する
13.使わない変数はアンスコ(_)を使う
14.背景がわからない場合は確認する
15.レビューで不明点があったら、事前に質問する
16.number_of_〇〇みたいに変数をつけるべきだった
17.原因はmoduleの理解不足。ディレクトリを作成した時に、複数形になっていなかった。franchises。
ディレクトリ名やファイル名にも気を配る
18.何がわからないかを細分化する
19.絶対避ける。よりわかりやすいメソッド名にする
20.Decoratorは特定のモデルに関連したビューロジックを書く。
21.何がわからないのか細分化する
22.2〜3年はこの状態が続く覚悟
23.わからないことはきっぱりわからないと言う
24.レビュー前のダブルチェック
25.本や簡単なサイト作り、フロントの簡単なアプリ作りで勉強する
26.誤解を招く発言をしない
27.ChatGPTの情報は半分間違いと思うこと
28.レビューをもらう
29.他のディレクトリやファイルを見る
30.問題の切り分けの記事を読んで実践する
31.binding.pryなどのデバックをしながら実装していく
32.Rubyの基礎から見直していく(実践やってからだと発見があるので)
33.提案する時は、代替え案を必ず提案する

リリースノート書き方