ID:75303さん

＃プロジェクト概要 マンションでピンポンを押した際の居住者との通話やメッセージをアプリで管理。 以下の2チームがあり、私は管理画面開発チームでした。 ・Flutterを使ったネイティブアプリ開発チーム ・Laravelで管理画面の開発チーム # 設計 要件定義はPLが作成済。 私は、要件定義を確認しながら設計書を作成するのを担当しました。 ＃開発・実装内容 【概要】 マンションマスタやユーザーマスタなどの管理画面の実装。 ・画面 ・バッジ処理 ・API のうち、画面を担当しました。 【どのような機能の開発・実装か】 6画面／12画面を担当しました。 1画面の担当範囲は、フロントもバックエンドもどちらも実装となります。 基本はマスタのCRUD処理の実装で、PDFとQRコードの作成・出力機能も実装しました。 Laravelフルスタックでしたが、画面のUXのため、JavaScriptも多く使いました。 【使用した技術】 開発環境：Docker FW：Laravel DB：MySQL 【課題・問題点】 私が感じて改善・挑戦した部分を上げさせていただくと、 ・開発環境の提案：Virtual Boxを使われていて起動までの速度が遅かったのですが、WSLでの開発を提案し開発体験の向上を図りました。 ・Swaggerの導入：以前に使ったSwaggerがそのままテストやドキュメントとして便利でしたので導入してもらいました。 ・UI/UXの改善提案：設計書外の項目で、ユーザー体験が悪くなりそうな部分があれば、提案・検討を行いました。 納期は厳しかったですが、 開発者も多かったので、共有事項やソースレビューでの指摘事項を共有などを行い、品質を落とさないことを意識しました。

＃プロジェクト概要 いくつかのロールがある、請求書の発行・管理画面の作成。 ロールによって、機能や表示内容が変わる。 請求書のステータスも、「起票　→　見積もり　→　請求書　→　入金確認」 などに分かれており、一定期間を過ぎてもステータスが変わらない場合は、バッジでメールを送信する。 # チームについて チームの規模は ・開発者6名 ・PM,PL 私は、SESで参加させていただき、開発を担当しました。 社内に未経験のエンジニアがおりましたので、サポート＋進捗管理を担当しながらの開発でした。 ＃開発・実装内容 【仕様した技術】 ・FW：Laravel（API作成） ・ライブラリ：Vue.js（フロント作成） ・DB：MySQL 【どのような機能の開発・実装か】 フロント部分は、テーブル表示でデータ表示や検索機能をつけました。 バックエンドはAPI開発で、CRUD処理を実装しています。 【課題・問題点】 ロールが多かったので、ロジックが複雑でした。 さらに、命名がリーダブルでないことがあったので、より複雑になり、 変更提案を行った。 # テスト テストの実施とバグ改修を担当しました。

＃プロジェクト概要 LMSのように、動画のアップロードやユーザーを管理できるシステム。 スマホユーザーも多いので、動画はHLS形式での配信。 メール送信にはSendGridを使用。 ＃チーム情報 受託開発で、 ・PM、PL ・開発　4名 がおり、私はPLと開発を担当しました。 # 開発・実装内容 ・管理画面 ・ユーザー画面 ・インフラの構築 ・動画の変換処理 で、全て担当範囲でした。 【使用した技術】 ・FW：Ruby on Rails（フルスタック） ・インフラ：AWS（EC2、S3、RDS、Lightsail） ・その他：AWS（SNS、ETC、Lambda）、SendGrid、Loocker Studio、Node.js 【課題・問題点】 「顧客より、別のシステムを作ってもらった際に動画が見れないとことがあった」 との声をいただいていたので、動画配信のベストプラクティスについて考えました。 私だけでは知見が足りませんでしたので、技術顧問などに相談しながら進めました。 HLS形式での配信を選択しました。 アプリのインフラ構築は何度かやったことあるので問題なかったのですが、 HLS形式に変換して配信のため、 「S3に動画をアップロード　→　Lambda（Node.js）→Elastic Trans Corderで動画をエンコード　→　SNSでRailsに通知」 のように実装するのに苦労しました。 構築後も保守で、顧客と戦略MTGを行い、サービスを拡大していくためのアイディア出しや改修を継続しております。 サービス改修の指標として「データの見える化」でLoocker Studioを導入しました。

＃プロジェクト概要 自社の勤怠管理システムのリニューアルを行いました。 【課題】 ・いつ作ったものなのか、バグが多く動作もすごく遅かった。 ・インフラのコストが上がっており、改善の必要があった。 改修にも時間がかかりそうでしたのでリニューアルすることにした。 【遅い原因】 ・更新時に一ヶ月のデータを毎回送信している ・データベースのデータが多い。 【打ち手】 リニューアル＋外販もしない自社プロダクトなので、 ・これまでの勤怠システムからどのように改善・リニューアルするか ・残す機能、増やす機能、やらない事を明確に。 ・システムの要件洗い出しの際に、社内ルールを人事しか把握していなかったので洗い出しと整理（ドキュメント作成）も行いました。 ・管理者がもっと使いやすいように、36協定や労働環境の法改正もバリデーションに盛り込みました。 ・保守しやすいように「Atomic Designパターン」を採用しました ・工数削減のため、Swaggerを導入しました。 ・フロントとバックエンドを別の技術に分け、動作を改善。 ・データベースのリクエストも編集したものだけを送るようにした。 ・データベースを自動でバックアップするようにし、不要なデータはバッジで削除するようにした。 ・インフラをAWSで見直し。 ＃チーム情報 ・PM、PL ・開発者：3名 私はPLと開発者として参加しました # 開発・実装内容 【機能】 ・日々の勤怠管理のデータを入力、編集、削除できる ・ロールにシステム管理者、企業管理者、スタッフがある ・社内ルールや法令遵守のための多数のバリデーションを実装 【使用技術】 ・FW：Next.js（フロント） ・FW：Ruby on Rails（API） ・インフラ：AWS（EC2、RDS、Lighsail） ・DB：PostgreSQL ・CI/CD：GitHub Actions ・ローカル開発環境：Docker 全て担当範囲でした。 ・Lightsailはステージング環境で、WebサーバーもDBも全部のせです。 ・Next.jsとRailsの構築のベストプラクティスが分からなかったので、EC2に両方のせ、Nginxをリバースプロキシとして設定しました。それぞれのアプリケーションが異なるポートで動作するように構成しました。 ・deployはCapistranoを導入していたので、GitHub Actionsで自動化しました。 ・祝日判定はGoogleカレンダーのAPIを使っています。 【特に苦労した点】 グループ会社も使っていたので、聞き取りやスケジュール調整などが離れていることもあり、時間がかかりました。 それぞれのポジションで意見も違うので、何を優先し、何を実装するのか決めました。 開発メンバーを2人アサインしてもらい、開発を進めました。 外国人メンバーだったので、コミュニケーションや指示出しには気を付けました。 # テスト バックエンドのモデルだけはRsepecでテストコードを書くようにしています。 様々な理由により当初のWBSより1ヶ月も遅れたのが反省点ではありますが、楽しい開発でした。

＃プロジェクト概要 美容室やクリニック向けのシステム（BtoB） 美容室などはグループでも横のつながりが薄く、技術が属人化しており、美容室ごとに閉じている。 これは新人教育や別の店舗との技術格差に繋がるので、新人でも良い提案ができるようAIを使ったシステムを提供。 1stはオフショアで開発したとのことで、2ndの機能拡張を担当。 # チーム ・PM、PL ・開発　3名 私はSESでPLとしての開発参加でしたが、先方にいるはずのPMがいらっしゃらなかったので、 要件定義、設計とスケジュール管理、顧客とのMTG、開発、テストも担当しました。 # 開発・実装内 【どのような機能を実装、担当したか】 ・管理者画面 ・ユーザー画面 ・ユーザー用にLINEログインを導入 ・インフラ構築 【使った技術】 ・ライブラリ：React ・FW：Ruby on Rails ・インフラ：AWS（EC2、RDS、Lightsail） ・その他：MUIやTailwindCSSなど 【苦労した点】 ・PMがいなくなったので業務量が増えたのと納期もきつかったので調整が大変でした。 ・1stを開発した会社のドキュメントが英語でも日本語でもなかった。 ・顧客から多くの機能追加の提案があり、スケジュールや品質の観点で、顧客との折衝が多かった。 ・LINE連携などが初めてだった。ユーザー情報の取得にどのような制限があるか調査。モックなどの検証などで実装可能な範囲で設計・実装ができました。