利用者目線に立ったプロダクトを作り続けていきたい。
エンジニア転職後、以前勤めていたコンビニエンスストアにシフト管理アプリを納品したところ「非常に使いやすい」と評価して頂いた経験があります。
非エンジニア職の経験があり利用者が本当に求めているものを理解していたことで、
上記のようなフィードバックを頂けるプロダクトを開発できたのだと考えております。
このような利用者目線を忘れずに、誰でも使いやすいプロダクトを継続して開発していきたいです。
upwork(海外のクラウドソーシングサービス)からRailsで認証機能(SMSを利用した2段階認証など)の実装を行いました。
無事求められていた認証機能を納品しました。
コミュニケーションはすべて英語(チャットのみ)だったので普段よりコミュニケーションに苦戦しました。
また、英語でのビジネス文章を作成した経験はなかったので勉強になりました。
Ruby on Rails, Nuxt.jsを使用したオンライン音楽レッスンWebアプリの開発に従事しました。
バックエンド、フロントエンドを中心に新規・既存機能開発を担当しました。
背景
WebRTCを使用した音楽レッスン用のオンライン通話ページのスタイルが未実装だったものをGoogle Meet風にスタイリングしました。
実装
Nuxt.jsでの開発は初めてだったのと、既存のコンポーネント(1コンポーネント2000行オーバー)が巨大だったため仕様理解に時間を要しました。
レッスン入室者が増えるごとに動的にスタイルを変更する必要があったため、
SCSSのmixin, extendなど機能をフルに活用するなどキャッチアップに務めました。
また、PC対応のみでなくタブレット対応、スマホ対応、Safari対応、Google Chrome対応の必要もあったため、UIテストに苦慮しました。
背景
音楽レッスンのライブ配信、アーカイブ録画用にRaspberry Pi、AWS Kinesis Video Streams(以下KVS)を使用して実装を行いました。
実装
KVSにライブ配信をするためにGStreamerをRaspberry Piにセットアップしました。
バックエンドからKVSにAPIを叩き、動画を取得してフロントエンドに送信して動画を視聴 or ダウンロードできるよう実装しました。
苦労したこと 1
バックエンド側で動画をダウンロードする実装をする際に、60分のMP4をKVSから取得する必要があったのですが、
一回のAPIでは9分前後しか動画を取得できない仕様だったため、
バックエンド側で60分の動画にするようFFmpegを使用しMP4を結合する必要があったため苦慮しました。
苦労したこと 2
バックエンドからフロントエンドに動画を送信する際にRailsのsend_fileメソッドを使用し、
その後動画を削除しようとするとsend_fileメソッドが非同期で動作しているため
動画の送信中にデータが削除されてしまう不具合が発生してしまいました。
結果的にsend_fileメソッドをラップして同期的に動作するようにして対処しました。
Go, Next.js, AWS(サーバレス構成)を主に使用した不動産物件内覧オンラインプラットフォームの開発に従事しました。
バックエンド、インフラを中心にフロントエンドまでフルスタックに新規・既存機能開発から品質保証まで幅広く担当しました。
また、0 => 1フェーズで開発されたプロダクトの初期開発からリリースまで担当しました。
また、ペアプログラミングを行い開発チーム内でのコミュニケーション、
スキルアップの促進し、開発の見通しを良くし、開発チーム全体のスケールアップに務めました。
背景
Goで不動産物件内覧オンラインプラットフォームの社内管理画面を0 => 1で作成する際に
Cognitoを軸とした認証基盤を作成しました。
実装
Cognito HostedUIを使用してGoogleのSAML認証を利用してSSOできるよう実装しました。
また、バックエンド側でセッション管理用のミドルウェアを作成し、
SAML認証後にCognitoから認証トークンを取得してログインできるよう実装しました。
苦労したこと
SAML認証後に認証用のクエリパラメータを取得できずログインできない不具合に悩まされました。
CloudFrontのビヘイビアの設定でクエリパラメータの許可設定が抜けていることが原因でしたが、
原因を探るのに苦戦しました。
背景
プロダクトのリリース前、リリース後にQA(品質保証)を行いました。
やったこと・苦労したこと
QAの観点の作成に苦労しました。
単体テストの項目作成からシナリオテストの作成まで行いました。
ユースケース・観点に抜け漏れがないかQAに詳しいエンジニアと折衝しました。
背景
サーバレスのプロダクトの構成がRoute53 => CloudFront => API Gataway => Lambdaという構成となっていて、
ユーザにアクセスさせる際には必ずCloudFrontを経由してほしいが、
API GatawayのURLに直アクセスすることが可能となっていたのでセキュリティ対策を行いました。
実装
CloudFrontのHeaderにカスタムヘッダーx-api-keyを付与し、Lambda関数を呼び出す際にx-api-keyがなければアクセスさせないようにしました。
(API GatawayでREST APIを使用していればよりシンプルに実装できましたが、運用費用が2、3倍になるためHTTP APIを使用しました。)
また、CloudFrontにWAF(WebACL)を適用し、セキュリティの向上に務めました。
背景
社内でテストのカバレッジを高める目標があり、
その一環でCIからSonarCloudにテストのカバレッジレポートを連携しました。
実装
Github ActionsのWorkflow内でgo testを行う際にテスト用のDBに接続するのですが、
テスト用のDBはAWSのパブリックサブネット内にあり、踏み台サーバを経由して接続する必要がありました。
そのためWorkflow内でポートフォワーディングする必要がありましたが、踏み台サーバ接続時にAWS SSM Session Managerも使用する必要があり、
接続用のコマンドを作成するのに苦慮しました。
前職で関わりのあった清掃事業者の方の要望で本アプリを作成しました。
現状では顧客とのやり取りをLINEやメールで行っているが、専用のアプリを介して顧客とコミュニケーションを取りたいとの要望で本アプリの開発に至りました。
清掃の定期メンテナンスの日程調整機能、現地調査結果報告機能、作業報告機能などを作成中です。
OAuth(Firebase Auth)を使用したJWT認証での実装を行いました。
実装する上でReactとGo(Echo)を介したJWT認証を行うリファレンスマニュアルや参考記事があまり見つからず苦労しましたが、
EchoやFirebase Authの公式ドキュメントを参考にサンプルアプリを作成しJWT認証の流れをデバッグしながら学習することでキャッチアップに成功しました。
Ruby on Railsを基本としたバックエンド領域を中心に、
フロントエンド、インフラ(Docker、AWS)まで指導しました。
初学者の方が行き詰まった場合は、ただ解決方法を教えるだけでなく、
なるべく自分の力で問題を解決できるように問題解決のヒントを小出しにするなど工夫しました。
Rails初学者の方のポートフォリオ作成をビデオメンタリングで指導していた際、
Docker上で動かしていたRailsのログが出なくなる出来事がありました。
当初は原因がわからず指導に苦戦しましたが、海外のフォーラムを探したところ、
RubyのバージョンによってはRailsログが出ない場合があるという記載の記事を見つけられました。
記事の通り設定を変更することでログ出力できるよう無事修正でき、
他人の開発環境で不具合があっても修正できるという自信をつけることができました。
Ruby on Railsで構築された大規模システムにバックエンド領域、
フロントエンド領域からインフラ領域までフルスタックに担当し、
新規機能の追加、既存機能の改修を行いました。
既存機能の改修ではクラス、メソッドの設計から見直し、密結合のクラスを疎結合に分割するなどアンチパターンの解消に務めました。
また上流工程から携わり、社内の非IT部門の方と折衝して要件定義、設計までも担当しました。
非エンジニアの方にも要件、実装について理解して頂くよう抽象化した説明を心掛けました。
セキュリティ対策の実装にも関わり、OS層からミドルウェア層、
アプリケーション層までのセキュリティ対策を担当しました。
具体的な例ではログイン認証機能用の2段階認証機能、外部攻撃のモニター機能をフルスクラッチで開発したり、
パッケージやgemの脆弱性の解消に務めました。
Railsアプリ、Webサーバ、OSの脆弱性対応を行いました。
背景
toC向けのRailsアプリで利用者様のメールアドレスが乗っ取られて不正利用されてしまう出来事があり、アプリ側の不具合はありませんでしたが不正利用防止のためセキュリティ対策を行うこととなりました。
Railsアプリ側
2要素認証機能、ログインユーザの動向を記録するモニター機能を作成しました
OS、Webサーバ側
CentOS側ではパッケージに脆弱性があれば対応しSSHポート番号の変更やFirewallの設定を見直しました。
Apache側ではSSLの脆弱性の改良のための設定変更を行いました
Railsアプリが稼働しているCentOS7サーバのサポート期限が近づいたためRocky Linuxに環境を移行しました。
背景
CentOS ProjectがCentOSの開発・サポートを取りやめると発表したことに伴い、他のOSに環境を移行することとなりました。
どのOSに移行するか検討したところ、RHELと100%の互換性をもつRocky Linuxに移行することとなりました。
実装
Rocky Linuxでは初期状態で入っているOpenSSLなどのパッケージのバージョンがCentOS7より高く、その影響でRailsアプリの環境構築ができないトラブルがありましたが、古いパッケージのソースをmake installしてバージョンダウンすることで対応できました。
そのほかcronの設定やシェルスクリプトなど必要なものの移行まで無事に対応できました。
業務自動化用のPythonアプリを作成しました。
背景
自社でネットワーク工事があり、工事後に通信速度に問題がないか手動でネットワーク速度を計測する作業を複数社員で行っていました。
業務の合間に手動で作業するのは非効率なので、作業を自動化するソフトを作成させて頂けるか提案したところタスクを任せていただけました。
実装
Python、Selenium、BeautifulSoupで実装を行うことになり、自動でネットワーク速度を記録し自社ファイルサーバにCSVを保存するアプリを作成できました。
本案件に携わる前にRailsの案件を2つ経験しましたが、どちらもアプリの規模としては小規模のものでした。
本案件のRailsアプリはControllerの数だけで100以上あり、これまで関わった中でもっとも大規模なRails案件に携わることとなりました。
Railsのバージョンはやや古いものの、実運用されている規模の大きいRailsアプリの案件に携われたことにより、
Railsを始めとしたバックエンドのコードの書き方、セキュアな実装方法についてスキルアップできたものと思います。
前職で関わりのあったコンビニ経営者の方からのご要望でシフトアプリを作成しました。
アプリ導入前のシフト表作成では店長がアルバイトの方からLINE、メールで希望シフトを聞きExcelに手作業で落とし込むという非効率なものとなっており、
シフト希望の収集から勤怠の調整まですべてサポートするアプリを作成することでシフト作成業務に割く時間を軽減しました。
シフトの収集・一覧・作成・調整を行う画面のUI/UXを工夫し、
店長ユーザ、アルバイトユーザ両者から使いやすいとご評価いただけるアプリを作成できました。
1年ほど運用し約100名のユーザ様に使用して頂いたところご好評を頂けており、
現在利用者拡大に対応できるよう引き続き開発を続けております。
これまでエンジニアとして経験していた、「大規模プロジェクトに途中から参画して開発に携わる」というものとは違い、
1からアプリケーションを企画、要件定義、設計、実装を行うプロジェクトとなりましたので、プロジェクト始動時にはなにから行うべきか苦慮しました。
特に、モックアップの作成、設計の段階がスムーズに行かず苦労しました。
当初はなかなかUI/UXの良いデザインが出来上がらず、依頼者のコンビニオーナー様や店長、アルバイトの方と折衝を繰り返しながらモックアップ、プロトタイプを作成しました。
納得いただける形になるまで作成を繰り返した結果、現在ご好評を頂いているUI/UXを実現できました。
本案権ではWeb開発、オブジェクト指向言語、Docker、AWS、CI/CDなど多くの技術を扱いましたが、
いずれも前職のSIer時代に経験がない技術ばかりで、1からのキャッチアップとなり習得に苦労しました。
わからないことがあれば技術記事やリファレンスマニュアルを参考にしておりましたが、
エラー解決の際に日本語の記事が見つからないことも多く、StackOverflowなどの英語記事を漁ることになるなどエラー解決に工数を割くことも多く苦労しました。
SIerの業務で英語のリファレンスマニュアルに慣れていたこともあり、英語記事に抵抗がなかったことは幸を奏しました。
また、バックエンドの開発経験があったこともあり、Ruby、Railsの実装に慣れるまであまり時間はかかりませんでした。
アプリの設計部分から大掛かりなリファクタリングを行いました。
アジャイル開発のようなスタイルでプロトタイプを作っては依頼者に見せるという形で開発を進めていましたが、
あるとき要望の機能を実装しようとした際に既存の設計では実装がしづらいことに気が付きました。
そのときにはアプリの8割ほどは完成していたのですが、データベースの設計のし直しは必須だと思い、1からリファクタリングすることになりました。
工数はかかってしまいましたがコードが読みやすく、機能追加しやすい設計のアプリを作成することができました。
使用していたライブラリで細かい挙動を実装できなかったためラッパーを作成しました。
本アプリでは認証機能にdeviseというRuby gemを使用していましたが、
ユーザの新規登録時に他ユーザの情報を紐付ける実装が困難でした。既存のライブラリでは思うように実装ができないためライブラリをラップしたコードを作成して対応しました。
他にもカレンダーの日付複数選択ができるMultiDatesPicker for jQuery UIというライブラリが日本の祝日に対応していなかったので祝日対応用のラッパーを作成しました。
祝日の情報が格納されているJSONをラッパーに読み込ませることで対応できました。
ラッパー作成時にはライブラリのソースコードを理解する必要があり、コードを読むのに多少苦慮しましたが前職のSIerで他者の書いたソースコードを理解してデバッグした経験が活かせました。
提案からデザイン、ロゴデザイン、文章作成、コーディング、
実装まで1人で担当しました。
モックアップを作成したらクライアント様にお見せし、実装を行うという手順で開発を進め、
ご満足いただける品質のアプリケーションを納品することができました。
クライアント様の要望通りのプロダクトを作成するため、
まずはクライアント様の要望をヒヤリングし完成イメージのモックアップをSTUDIOで作成しました。
必要な機能要件を実現するためモックアップをお見せしつつ要望をヒヤリングするなど工夫しました。
納期が2ヶ月ほどでしたので、納期通りにプロジェクトを進められるよう工夫しました。
はじめの1週間はモックアップの作成に割き、そこから3週間でプロトタイプを作成することで、
1ヶ月でアプリの大枠を作成しました。
残りの納期で追加のご要望やテストに着手し、無事納期までにプロダクトを納品することができました。
基幹システム担当のエンジニアとして、システム障害発生時には障害の状況についていち早く把握、対応するよう努めました。
障害発生時には他チームと障害内容の共有し、運用監視オペレータへどの障害対応手順書を使用するべきか指示し、
手順書が存在しない場合は私自身で障害対応しました。
対応の際に手間取らないよう、日頃から基幹システム内の構造を理解し、基幹システム外のAPIとどのように関連しているか理解するよう務めました。
また、新規に障害が発生したときは対応後に手順書の作成も行いました。
基幹システムの監査作業を自動化しました。
基幹システムのログを1日、1週間ごとにエクセルに手作業で貼り付ける業務がありましたが、
手作業では時間がかかり、ケアレスミスが発生する課題がありました。
上長に業務の自動化を提案したところ自動化の実装を任せて頂け、
VBAとシェルスクリプトで作業を自動化することで週あたり6時間ほどの工数の削減を実現しました。
また、チーム内ではエクセルを使用した作業が多かったためVBAの使用方法を普及させ、チーム全体の工数削減に務めました。
大規模プロジェクトの一環として基幹機能の1つをアップデートすることとなり、30年ほど運用しているAPIの改修に着手しました。
APIはTALというC言語に似た言語で書かれており、マイナーな言語のため英語のリファレンスマニュアルしかなく扱いに苦慮しました。
改修作業では2万行ほどに及ぶソースコードを解析して新規機能の追加、不要機能の削除に着手しました。
英単語が省略されすぎているため意図不明の変数が存在したり、ソースコードにコメントがほぼ書かれていないことで解析に苦慮しましたが、
入念にデバッグし処理を理解することで無事改修に至りました。
改修は困難でしたがデバッグやソースコード解析スキルの向上と英語マニュアルが理解できるようになるなど良い勉強になりました。