ID:62445さん

# プロジェクト概要 ## 目的・背景 --- - 既存システムのリプレイス - レガシーコードからの脱却 - Perlを用いたシステムで、既存コードの保守・メンテナンス性が低い状態になっている - セキュリティレベルの向上 - 要配慮個人情報などのアクセス権などが適切に管理されておらず、情報セキュリティレベルの向上が急務となっている - プロダクトの内製化 - 既存システムは外注されており、コードも外注先の資産という契約になっている - 自社資産とするためにもリプレイスに伴う内製化が急務となっている ## 開発規模 --- - 予算 - 2億5000万円〜3億円 - チーム構成 - PdM：2名（内1名途中で退職） - デザイナー：1名 - インフラエンジニア：1名（CTO） - フロントエンドエンジニア：最大6名（内業務委託2名） - サーバーサイドエンジニア：最大9名（内業務委託7名） ## 使用技術・開発環境（サーバーサイド、インフラ） --- - Docker - Java SpringBoot3.4.4 - Swagger（OpenAPI Specification3.0.3） - AWS（環境構築はCTOが実施） ## 自身の担当業務 --- - 要件定義・設計 - 要件定義設計（261機能） - 機能仕様設計（261機能） - API設計（436API） - DB設計（68テーブル） - Docker環境構築 - Dockerfile、docker-compose.ymlを用いて、開発環境構築コストを80％程度削減 - API実装 - 4API - 要配慮個人情報を取り扱うファイルアップロード（4権限分） - 20API - 本プロダクトの開発に付随して、各種のプロダクトの基底となる「サービス基盤」側のAPIの改修・新設 - API実装review - 1次reviewは技術観点、2次reviewは要件・仕様の観点で実施 - 1次review：6.7％担当（30/436API） - 2次review：51.8％担当（226/436API） - develop環境検証・staging環境検証 - develop環境検証（フロントエンドからの指摘事項） - 38.4%（103/268件）の原因・改修方法調査（実際の改修は業務委託の方に依頼） - staging環境検証（QAチームからの指摘事項） - 53.6%（30/56件）の原因・改修方法調査（実際の改修は業務委託の方に依頼） - サーバーサイドエンジニアのまとめ役（役職は一般職） - サーバーサイドメンバーのタスク・スケジュール管理、仕様理解・実装フォロー - 基幹システムとなるSalesforceとのデータ連携方法を、Salesforceチームと協議・決定 - AWS AppFlowによる同期処理に必要なカラム検討 ## 課題 --- - 納期 - リリース期限が決まっているが、ビジネスサイドの要求・業務フローが定まっていない状態からのスタート - 要件の決定 - ビジネスサイドが要求から要件をまとめられず、要件定義から参画し要求→要件→仕様にまで落とし込む作業から対応 - 質問管理表を用意して仕様を明確化した（最終質問数：987） - 搭載機能の量と制限事項 - 436APIの開発（開発期間6ヶ月） - 膨大な機能群と機能に対する制限事項（状態管理のステータス）の網羅的整理 - リソースの所属、公開・非公開、契約前・契約中・契約終了、契約の有効・無効、ユーザーの利用中・利用停止など # 技術的アプローチ・工夫した点 --- - GoogleのAPI設計を参考にリソース指向のAPI設計を導入 - 親子関係のあるリソースの階層表現 - HTTPメソッドのみで表現しきれないカスタム動詞（URIの末尾に:動詞をつける）を導入 - 膨大なAPI群の詳細制御を実現 - アーキテクチャの選定 - 最終的にはレイヤードアーキテクチャを採用（納期・実装メンバーのスキル差の兼ね合いから、レイヤードに着地） - パッケージ構成にdomain・Injectorなどの概念を採用 - モデリング・Golangの使用などをチームに提案 - develop環境・staging環境での検証 - develop環境での検証をフロントエンドメンバーに実施していただき、そこで発見したバグを解消してからstaging環境の検証（社外のQAチームに依頼）を実施 - 上記工程にすることで、staging環境でのバグ報告を大幅に削減できた # 自身が発揮したバリューおよび成果 --- - 参画メンバー全員のコミュニケーションのHub役となった - PdM・デザイナー・フロントエンドエンジニアなど立場の異なるメンバーとのコミュニケーションの窓口となり、サーバーサイドの主要メンバーとして設計・開発に従事 - チームにおいては業務委託7名（5名、1名、1名の3社）、プロパーメンバー2名と設計・実装上で発生した疑問・トラブルシューティングの対応窓口となり、解決方法の模索・施策を実行した - 暗黙知を形式知にすべく、プロダクトの要件・基本設計にオーナーシップを持って取り組んだ - 質問管理表の41.2%（410/995）を私個人で起票し、解決した内容を機能仕様書・API設計・DB設計・実装に反映した - 機能仕様書への反映は質問管理表へのリンクを必ず作成し、仕様決定の背景の証跡を追えるようにした - スキーマ駆動開発（WebAPIベースのコミュニケーション）をフロントエンドにも展開 - フロントエンドのWebAPIに起因する開発工数の70%を削除 - 社内評価（グループ会社全社を含む、筆者の属するITの機能会社は26名） - 2024年度4〜6月度MVPノミネート（グループ全社253人中3位） - 2024年度年間MVPノミネート（グループ全社253人中4位）

# プロジェクト概要 # 目的・背景 --- - オンラインシェアリングサービスのSanpo保健室の新規開発 - 産業保険業務におけるオンラインサービスが提供できていなかったため、新事業として市場に早急に投入する必要性があった - 小規模事業場に対する労働安全衛生環境の廉価提供 - 50名以上の事業場に関しては産業医の選任が義務付けられているが、50名未満の事業場に対しては義務付けられていない現状がある - 結果、小規模事業場においては労働安全衛生環境の体制が構築されにくく、対応が後手に回っている現状がある - 産業医・保健師とオンラインで廉価にコミュニケーションを取れるチャネルを構築し、多くの従業員の方の労働環境やメンタル面のケアを行うことで労働環境の改善と継続的なサポートの実現を目指す # 開発規模 --- - 予算 - 1億8000万円 - チーム構成 - PdM：1名 - デザイナー：3名 - インフラエンジニア：1名（CTO） - フロントエンドエンジニア：7名（内業務委託3名） - サーバーサイドエンジニア：6名（内業務委託2名） # 使用技術 --- - Docker - Java SpringBoot3.3 - Swagger（OpenApi Specifications3.0.3） - Git , GitHub - AWS（環境構築はCTOが対応） # 担当業務 --- - サーバサイドの設計・実装メンバー - 設計 - API設計（30API担当） - DB設計（自担当の30APIと関係のある箇所分） - 実装 - API実装（30API担当） - API実装review - QA対応 - QASチームから上がってきたバグ報告の確認、原因調査、改修方針の検討、実装者への改修依頼

# 概要 - 自社サイトの保守・運用 - 定期的（季節によって）に更新される内容の変更 # プロジェクトの目的 - 自社サービスへの新規クライアントの獲得 # チーム情報 - アプリケーション側：2名（内業務委託1名） # 担当業務 - バックエンドエンジニアとして、サイト運用・保守を担当 # 使用技術 - Laravel5.8.35、PHP7.1.3、MySQL5.7、SCSS # 開発・実装機能① 【プログラミング教室の夏期講習の編集】 - 参加する夏期講習のプランに応じた持ち物の動的表示 - 参加日とクーポンコードに応じた割引金額の動的設定 - サイトアクセス日の翌日以降のみ、参加希望日を指定できるプルダウンの動的生成 # 開発・実装機能② 【サイト表示改善施策】 - ローディング画面の実装 - .htaccessによるgzip圧縮、expireの設定