ID:70412さん

# プロダクトの概要 本プロジェクトはLRM株式会社が提供しているSaaSの「セキュリオ」の開発・運用・保守です。セキュリオは情報セキュリティに関するeラーニング機能や、標的型攻撃メール訓練、ISMS取得に関わる機能を提供するサービスです。 # 業務概要 ## 開発業務 開発業務としては、PdMからアサインされた大まかなユーザーストーリーを細かいチケットにタスク分解して、実装、テスト作成、リリース作業を行いました。 ## 運用保守業務 運用・保守業務としては、バグ通知やパフォーマンス低下通知、本番障害通知への対応を行いました。必要に応じて、CSやPdM等に連絡を行い、対応をしました。 # 以下、業務として行った主なことを時系列に記載します。 - 2021年11月 - 内定者バイトとしてLRM株式会社に入社し、研修を開始しました。 - 2022年1月 - セキュリオの開発業務に関わり始めました。内定者バイト期間は主にフロントエンドの改修に携わりました。 - この期間に行った業務は、誤字の修正、確認モーダルの実装、CSSの変更、topページのデザイン変更等です。 - 使用技術: Rails, SCSS, jQuery, HTML(erbファイル) - デザイナーさんから頂いたデザインにできるだけ近くなるようにと考えて業務に取り組みました。 - また、ほぼ未経験の状態だったのですが、技術的にどうしたらいいのか分からないときは最低一日は自分で調べ考え手を動かすようにしました。一方で、仕様面で分からないときはすぐにPdMや先輩エンジニアに確認を取ることが大事だと学びました。 - 質問をする際には、自分が試したこと、仮説、どういうものを実装したいのか、ということを整理して質問をするようにしました。 - 加えて、仕様面で質問するときは、私自身とPdM等で双方の認識が合致していることを確認するようにしました。 - 2022年4月 - LRM株式会社の正社員となる - この時期に、アラートフラッシュにリンクの埋め込みを行いました。 - 使用技術: Rails, HTML(erbファイル) - アラートフラッシュ上にリンクを埋め込む上で、サニタイズをしなければならず、脆弱性が生じないかを調べてつつ実装しました。結果としては、こちらが打ち込んだリンクを表示するだけなので(ユーザーが入力したリンクを表示するわけではなかった)、問題なく実装できました。 - 2022年5月 - ユーザーストーリーの作成に関して学び、同じ会社の情報セキュリティコンサルタントにヒアリングを行って、ISMS関連機能開発のためのユーザーストーリーを作成しました。 - 背景としては、先輩からバックエンドに関するタスクの一つとして頂いたのですが、仕様面を突き詰める上で、ISMS規格を読み込み、不明点は弊社の情報セキュリティコンサルタントに質問をしたところ、大幅な改修を行わなければISMSに対応した機能にならないということが判明し、ユーザーストーリーの作成に取り組むことになりました。 - まず、オライリージャパンのユーザーストーリーマッピングという本で、ユーザーストーリーの作り方を学びました。その後、ISMS規格を読んで、機能として必要になりそうなことの仮説を立てると同時に、不明点のピックアップを行って、弊社情報セキュリティコンサルタントに質問をしました。そして、機能として必要となるものを、実装できそうな単位で細分化して、それぞれに対してユーザーストーリーを作成し、CTOのフィードバックを受けました。 - フィードバックを受けてユーザーストーリーを完成させたのですが、他の優先タスクが差し込みで入り、実装までは至りませんでした。 - 2022年6月 - Power Automateを活用して、社員同士の1on1の自動化を行いました。また、Power Automateを用いて、顧客ヒアリング等や商談へのエンジニアやPdMのアサインを自動化しました。 - 使用ツール: Power Automate - 2022年7月 - ZohoCRMとセキュリオのAPI連携機能の運用を退職した先輩から引き継ぎ、実際に利用するIS/CSからの質問に応対しました。 - また、AWSへのデプロイ作業も行うようになりました。(こちらは現在まで引き続き行っています) - 使用ツール: Github, Github actions, AWS(ECR, CloudFormation, ECS, CloudWatch) - こちら、マニュアルが整備されており、マニュアル通りに進めるような形です。リリースタグの間違いなどが起きないように気をつけながら行いました。 - また、リリース作業完了後、問題ないことを手動テストで確認しています。 - 2022年8月 - CSが誤って顧客データを削除してしまうリスクをなくすため、利用中のユーザーが機能ごとに不要なデータを削除できる機能を実装しました。(詳細はプロジェクト2) - 使用技術: Rails, MySQL, JavaScript, RSpec - こちら、顧客側が誤ってデータを削除しないように、確認モーダル上でデータを削除する機能の機能名を入力しないと削除できないようにしました。 - また、CSからも顧客の利用状況を確認でき、プラン変更で利用不可とする機能へのアクセスはできないようする操作ができるようにしました。それに伴って、CSへのヒアリングを行いながらadmin画面の改修を行い、利用しやすいものにしました。 - この際に、元々あった顧客のデータ状況を管理するテーブルに加えて、顧客が現在利用できる機能を把握するためのテーブル追加を行いました。結果として、機能を追加する際に二つのテーブル上でデータを作成しなければならなくなったことが反省点です。安直にテーブルを追加するのではなく、カラムの追加で対応できないかよく検討するべきでした。 - 一方、良かった点としては、ユーザー側とCS側双方の視点でユーザーストーリーを作成し、どちらにとっても利用する上ではUXが悪くならないように実装できた点です。 - また、BugSnag通知が来るたびに、通知内容を確認し、必要に応じてCloudWatch logsを使ってバグ発生時のログを確認やAWSEC2を使って本番DBの確認を行い、バグの再現および改修を行いました(こちらは現在まで引き続き行っています) - 2022年9月 - N+1問題でサービスダウンが起きたため、原因となったクエリの特定及びコードの改修、デプロイを行いました。 - 使用技術: Rails, NewRelic, CloudWatch logs, Rspec - このときはまだNewRelicの使い方がよくわかっていなかったので、ログを読み、N+1になっているSQLを特定しました。 - 対応としては、erbファイルの改修と、controllerでincludesとなっていた箇所をpreloadに変更しました(N対Nの関係であったため)。この対応で、N+1は解消されました。 - 2022年10月 - 開発チーム、PdMでの雑談を行うオンラインmtgが設定し(自由参加)、開発チーム内でのコミュニケーションの活性化を行いました。(現在まで続いています) - 基本的にリモートでの業務となっているので、コミュニケーションが増え、チームビルディングに役立っていると思います。 - 2022年11月〜12月 - Ruby2.6系から3.1系へのアップデートを行いました。(詳細はプロジェクト3) - JSが動かなくなったため、動くようにする方法を調査するのに苦戦しました。また、gemのバージョンアップがされておらず動かなくなったものもあったため、そちらに関しても調査して動くようにしました。 - また、プロダクト全体としてテストが不十分な状態であったので、可能な限り手動テストをしました。 - 2023年1月 - グループ(部署)をCSVで登録・更新・削除ができる機能を実装しました。 - 使用技術: Rails, RSpec - 登録・更新・削除という処理をまとめて行う上で、削除してはならないデータを削除してしまうことが最も恐ろしい事態だと考えられました。なので、バグ等がないか徹底的にRspecを書きました。 - テックリードのエンジニアさんに細かくコードレビューをいただき、より適切な命名での実装ができました。 - 2023年2月 - 新卒向け教材(パワーポイント)の作成 - こちら、未経験で入社することを想定して、可能な限り簡単な言葉に落とし込むようにしました。また、ハンズオンで行う箇所も入れて、聞くだけのつまらない講義にならないように工夫しました。 - また、この時期にNewRelicの主要機能の使い方を理解し、パフォーマンス低下時にNewRelicから問題となっているクエリを特定して改修する等、パフォーマンス維持業務を行っています(こちは現在まで引き続き行っています) - 2023年3月 - ユーザー登録画面にて、10人までまとめて登録できるよう、jQueryを用いて動的に増減する登録フォームを実装しました。(詳細はプロジェクト4) - 使用技術: Rails, jQuery, RSpec - こちらは、2,3人程度のユーザーを登録する際にCSVファイルで複数名登録するのが面倒だというユーザーからの要望に基づいて実装しました。複数ユーザーを登録する上で、jQueryを用いて必要なだけ入力フォームを増やせるようにしましたが、個人情報を扱う場所を動的にする実装には疑問が残っています(とはいえ顧客要望なので、致し方なく実装しました)。 - 入力されたデータの受け渡しは全てパラメータで行うようにし、入力→プレビュー→登録or入力に戻る、という操作ができるようにしました。 - また、こちらも誤った情報が登録されるなどリスクがあるので、RSpecを丁寧に書くように意識しました。 - 2023年4月〜5月 - CSVエクスポート機能にて、エクスポートする量が多いときにタイムアウトエラーとなる障害が発生したため、ポストモーテムを実施しました。その後、エクスポート機能をバックグラウンド処理化しました。この際、出力されたCSVファイルは一時的にAWSのS3に保存しました。 - 使用技術: Rails, RSpec, MySQL, AWS S3, SendGrid, JavaScript - バックグラウンド処理が終わったことをユーザーに伝える方法としてメールを採用しました。メールで通知を受け取り、メールに記載されたリンクをクリックするとCSVファイルがダウンロードされ、JavaScriptでサービスの画面に遷移するようにしました。 - ダブルレンダーエラーが起きないようにする方法が思いつかなかったので、業務委託のエンジニアさんに質問をしたところ、JavaScriptで画面遷移を行うという方法を教えていただきました。 - また、バックグラウンド処理のステータスとしてはenumを採用しカラムはinteger型にしました。そして、ステータスを1000,2000,3000など飛び番にすることで、今後新しいステータスが必要になっても対応できるようにしました。 - S3の環境変数に関しては、インフラエンジニアさんと相談して決めました。 - また、新卒向けの研修及びOJTを行うようになりました(現在も行っています) - 2023年6月 - グループに部門コードを設定できるようにしました。 - 閲覧権限のないユーザーにeラーニングが配信されるバグを修正しました。 - いずれもRailsを使用しています。 - 2023年7月 - 不要なデータを非表示にするアーカイブ機能の実装 - こちら、該当のデータにaasmが設定されていたので、最初はaasmを使って実装していたのですが、ステータスがとても増えてしまったので、boolean型のカラム追加での対応に変更しました。 - 2023年8月〜現在 - 通知設定画面のUI改修を行い、非同期処理で設定の変更を行えるようにしました。 - 使用技術: Rails, RSpec, jQuery - 非同期処理を実現するために、部分テンプレートを使うようにerbファイルを変更しました。 - また、現時点で設定することのできない通知機能に関して、通知設定が行えるように改修を行っています。 - こちら、オフショアチームが作成している機能に関しても通知機能の追加が必要となったので、オフショアチームに伝わるよう、PdMと相談しながらドキュメント作成を行いました。

# 背景 - CSチームのオペレーションミスで各機能単位で顧客データが物理削除される恐れのある実装になっていた。 - また、実際にCSチームのオペレーションミスが発生しており、顧客データが削除されてもおかしくない状況にあった。 # 実装前の整理 - まず、CS側とユーザー側、双方の視点からユーザーストーリーを作りました。 - 双方のペインを明確化するために、日を改めて何度かユーザーストーリーを練り直しました。 - その結果として、 1. その機能に関して顧客のデータがあり、かつ、顧客にその機能へのアクセス権がある 2. その機能に関して顧客のデータがあり、かつ、顧客にその機能へのアクセス権がない 3. その機能に関して顧客のデータがなく、かつ、顧客にその機能へのアクセス権がある 4. その機能に関して顧客のデータがなく、かつ、顧客にその機能へのアクセス権がない の4種類の状態があるという形に整理されました。 - また、データに関しては顧客が生成・削除すべきであり、アクセス権に関してはCSが制御するべきだ、という結論に至りました。 - そこで、 - 1->2への変更はCSが行う - 1->3の変更は顧客が行う - 1->4の変更は起きえない(※解約時を除く) - 2->1の変更はCSが行う - 2->3の変更は起きえない - 2->4の変更は顧客が行う - 3->1の変更は顧客が行う - 3->2の変更は起きえない - 3->4の変更はCSが行う - 4->1の変更はCSが行う - 4->2の変更は起きえない(アクセス権がない機能に関するデータの生成は認めない) - 4->3の変更はCSが行うが、アクセス権を認める際に初期データが生成されることを顧客は期待するはずなので、4->1の変更に集約する という形に整理しました。 # タスク分解 1. admin画面(CS側が操作する画面)で顧客データを削除できないように(生成はできるように)バックエンドの変更し、フロントエンドも修正する 2. ユーザー画面で顧客データの削除・生成(アクセス権があるときのみ)できるようにバックエンドを変更し、フロントエンドも修正する # 実装 1. 顧客の各機能のデータの有無を管理しているテーブルはすでに存在していたので、それを流用 2. 顧客の各機能のアクセス権を管理するテーブルを追加 3. admin画面に関するcontrollerとviewファイルの変更 4. リリース 5. ユーザー画面に関するcontrollerとviewファイルの変更 6. リリース # 工夫した点 - CSのオペレーションミスで顧客データが失われる事態が最も問題となるので、先にCS側の操作画面の変更を行なった - 検証環境へのリリース後、CSに実際に触ってもらい、本番リリースまでにUI/UXの改善をした - ユーザーが誤ってデータを削除しないように、削除できる権限を有するユーザーを限定的に絞り、かつ、削除確認モーダルにて、該当する機能の名称を入力しないと削除ボタンを押下できないようにした。 # 結果・反省点 - CSのオペレーションミスによるデータ削除のリスクが0になった - 一方で、各機能に関するテーブルが二つになってしまったので、新たに参画したエンジニアにとってはテーブル設計が理解しづらくなってしまった。 - この点に関しては、初めてのテーブル作成だったということもあるが、安直にデータを管理しているテーブルの構造を真似たことも失敗だったと思う。 - どうにかデータを管理しているテーブルでアクセス権の管理もできないか、検討したがうまくできなかった。自身の経験不足も原因の一端であると考えている。

# 背景 - Ruby2.6系はセキュリティサポートが終わった状態に終了した状態にあったが、依然としてアップデートできていない状態にあった。 - 原因としては、人的リソース不足や機能開発を優先していたこと。また、誰もやりたがらなかったことにある。 - しかし、情報セキュリティに関するプロダクトであるにも関わらず、セキュリティサポートが切れたバージョンを利用していること(しかもそのことをユーザーに隠していること)は大きな問題だと思い、アップデートに取り組んだ。 - このときの最新バージョンが3.1系だったので、3.1系へのアップデートに踏み切った。 # プロセス - 最初に、Ruby2.6系から3.1系へのアップデートに関する文献がないか調べたが、見つからなかった。 - そこで、まずはメジャーバージョンのアップデートを行うことにした。具体的には、3.0系へのアップデートを実行した。 1. アップデート前にローカル環境でRSpecを実行し、すべてが通ることを確認。 2. アップデートの実行後、ローカル環境でRSpecを実行し、テストが通らなかった箇所をローカル環境で確認。 - 主にJS系で問題が起きており、system specが落ちていることを確認しました。 3. Ruby3系でJSが正しく機能させる方法を調査 - ``app/assets/config/manifest.js``を追加することで、動作することを確認できました。 4. gemのバージョンアップがされていないものがあり、そのことが原因で動作しない箇所があったので、gemのアップデートも必要に応じて実行 5. Ruby3系でリリース 6. Ruby3.1系へのアップデートを実行 - マイナーバージョンの変更なので、大きな問題も生じず完了しました。 # 大変だったところ - テストをちゃんと書いていない箇所が多々あり、手動でのテストが必要だったところ。 - 思っていた以上に、Rubyのアップデートに関するドキュメントが少なく、調査に時間を要したところ。 # 感想 - 新卒1年目で取り組むには難しいタスクであるようにも思ったが、上司や先輩の助けを借りながらも完遂したことで、自信に繋がりました。 - また、テストを丁寧に書くことの重要性をよく理解できました。

# 背景 - 複数ユーザーを登録する際にはCSVファイルを利用する必要があるが、2〜5人程度の少人数のユーザーを追加するためにCSVファイルを利用するのは面倒だという要望が複数上がっていた。 - そこでユーザーを一人だけ追加するページで入力フォームを動的に増やせるようにして欲しいとPdMから要請を受け、私が実装等を担当することになりました。 - ただ、私個人としては、メールアドレス等の個人情報を扱う箇所でJSを使うことには賛同しかねており、あまり気乗りはしなかった。 # 受け入れ要件の整理 - +, − ボタンで登録フォームを最大で10件まで増やせること - 登録が実行される前に、登録される内容の確認ページが表示されること - 確認ページで誤りに気づいた際には、入力した内容を保持したまま、登録フォーム画面に戻れること - (当然だが)正しく複数人の登録が行われること # タスク分解 - ユーザー一人だけを登録するページで、複数人の登録ができるように、バックエンドの処理の変更 - modelの追加、ストロングパラメータの変更等 - 複数のフォームを表示できるようにフロントエンドの処理/UIの変更 - 確認ページの実装 - 登録完了ページのUI変更 - リリース - アジャイル開発なので、本来であれば細かくリリースしたかったが、「顧客から不十分だと突っ込まれる」とPdMに言われ、全てを実装した状態でリリースすることになりました。 # 実装で苦労した点 - フォームを動的に増やすこと - Railsはこのような実装をサポートしておらず、``form_with``と``fields_for``を組み合わせることで実装しました。 - また、フォームを増やす動作にはjQueryの``clone``を活用しました。 - select2というjQueryのプラグインを問題なく動作させること - 動的に増やしたフォームで正しく動作させることに苦戦しました。 - select2が機能しないということに関して、英語の文献が複数あったのでそれらを読み、複数の仮説を立てて試しながら実装をしました。 - 動的に増やしたフォームに重複しないidを与えることで解決しました。 # うまくいった箇所 - すでに登録されているユーザーの登録を試みているなどのエラーがある場合、確認画面でエラー内容を表示できるようにしたこと。 - modelにエラーとなるケースの処理を記述し、controller側でそれら全てを確認するように実装しました。 - modelではエラーの場合に早期returnをするようにしました。 - 結果として、ユーザーが登録ボタンを押下してからエラーと表示されることを防ぐことができました。 - 登録内容の受け渡しにはRailsのパラメータを活用したことで、session等に入力内容が一時的に保存されることを回避したこと。 # 反省点 - 上述の通り、私としては気乗りのしないタスクだったので、PdMともっと議論をするべきだったと思います。PdMには技術的なことはわからないので、エンジニアとしてもっと自身の意見を述べるべきでした。 - 多くのユーザーが望んでいる機能は実装したいが、技術的に可能であっても、自身のポリシー・考え(いつか技術的負債になりそう、ユーザーの個人情報が漏洩するリスクがある)に反するようなものは作るべきではないのではないか、という疑問が残っています。