だん

## プロジェクト概要 ### 目的・背景： - 推定ユーザ数500万人の動画配信アプリケーションのフロントエンド開発 - ※既存アプリケーションの移行先となる新規アプリケーションであり、既存アプリケーションのユーザ数が500万人のため、上記の通りに「推定値」として記載 - 0 からの新規アプリケーション開発 - アジャイル開発 ### 担当 - 技術調査チームのメンバ：使用技術や開発・実装方針を決めるチームメンバ - 詳細設計・実装担当 - 動画配信アプリケーションの一部であるSNS機能・共通エラーハンドリングを担当 - フォロー/いいね/プロフィール - レビュワー ### 使用技術： - 言語：Typescript - フレームワーク：Next.js (Pages Router) - テスティングフレームワーク：Jest - API：RESTAPI - CSS : モジュールCSS - データフェッチライブラリ：axios ### 開発環境： - コード管理：Gitlab - 開発エディタ：VSCode ### 規模 - PM：1名 - POA : 5名 - スクラムマスター：5名 - エンジニア：40名 　※上記はフロントエンド開発チームのみの人数 ## 課題 - 【短期間による集中開発】仕様決定やバックエンド開発も並行して進められる中で、開発期間７か月でリリースできる状態へ仕上げる必要があった。 - 【自由奔放な実装方法】自社内にReact.js/Next.jsの経験者がいなく探り探りの実装の中で、実装方法の大きな差が出てきており、保守性が低下していた。 ### 技術的アプローチ・工夫した点： - 【他チームやAPI開発側との事前すり合わせ】短期間による集中開発であったため、積極的に他の開発チームとの連携が必要であった。自身の担当機能を開発やチーム内レビューを行っていく中で、不足しているAPIやより効率化できるフロント機能があれば該当者と連携を取り、よいプロダクトづくりに向けて動いた。結果として、より負荷の少ないAPI設計・実装やフロントエラーハンドリングの共通化に貢献することができた。 - 【コーディング規約の作成】実装方法に差が出てきていたためコーディング規約を作成・運用をしていく必要があった。使用技術の深堀とメンバとの共有・レビュワーとしての参加などを行いコーディング規約のたたき台を作成し、チーム間の会議で調整をしフロントチーム全体で運用を行える体制を整えた。結果として、バグの原因特定速度の向上につながった。

# プロジェクト概要 * スピード感を持った意思決定を支援するデータ分析基盤の構築 * 分析対象のサービスはR&Dの一環として、顧客と共同で実証実験 * アジャイル開発 ## 業務期間 2023年7月~2024年9月 # 担当 * データ分析エンジニア * ビジネスチームとの要件ヒアリング～データ基盤の構築・実装 # 使用技術 * AWS: Lambda, Athena, Glue, DynamoDB, QuickSight * 言語: Python # 規模 * ビジネス・開発全体: 約120名 * 開発全体: 約80名（要件定義10名 / 設計・開発70名） * データ分析チーム: 3名（PM1名、エンジニア2名） # 課題 1. 分析指標の不足 * データ分析チームが関与しないまま企画・開発が進み、機能リリース後に分析基盤構築の依頼が発生。指標提供が遅れた。 2. 品質の低下 * 本体開発と並行して分析基盤を構築する必要があり、設計の連携不足による障害が発生。 * 具体的には、一部の分析指標が正しく集計されず、データの整合性が取れない状況が発生した。 # 取り組みと成果 * 依頼フローの整備 * 要件定義の段階からデータ分析チームが関与し、必要指標を事前にヒアリング * 依頼内容を定型化し、本体開発のフローに統合した結果、リリースと同時に分析結果を提供できるようになった。 * 耐障害性 * 指標ごとに処理を分割し、1つの障害が他の指標に影響しない設計を導入 * エラー検知を実装し、修理時間を1時間程度に改善 * 本体開発チームとの連携強化 * 必要要件を設計・開発チームに共有し、プロダクトオーナーと連携して開発スケジュールを調整 * データ基盤の品質向上に貢献 # 工夫した点 * 体制・フローの改善 * アジャイル開発と体制拡大の過渡期に、PMの兼務負担を軽減するため、体制やフローの整備にも積極的に関与 * クラウド活用の推進 * AWSのデータ分析サービスを適切に活用するため資格を取得し、最新の技術を活かした実装をリード

# プロジェクト概要 * メタバース・Web3サービスの開発 * R&Dであり顧客と共同実証実験プロジェクト * アジャイル開発 ## 業務期間 * 2024年10月~現在 # 担当 * アプリケーションおよびクラウドインフラのセキュリティ要件定義 # 使用技術 * AWS: SecurityHub, Inspector, Lambda * 開発言語: Python # 規模 * ビジネス・開発全体：約120名 * 開発全体：約80名 * 要件定義チーム：約10名 * 設計・開発チーム：約70名 # 発生した課題 * セキュリティの知識不足 * 体系的なセキュリティ知識を持つ頼れるメンバがいなかった。 * セキュリティ要件の欠如 * 参画当初、社内のシステムセキュリティルールの順守が9割未実施の状態だった。 * 前任者が場当たり的な対応をしていたため、正式な要件定義が行われず、統一的なセキュリティ基準が適用されていなかった。 * 各アプリケーションごとのリスク評価を実施する前に、まず基本的なセキュリティルールの適用が必要な状況だった。 * R&Dのスピードに対するセキュリティ対応の遅れ * R&Dのスピード感に対し、セキュリティ施策の実施が追いついていなかった。 * 機能開発やKPI達成が優先され、セキュリティ対策が後回しにされた。 * プロダクト拡大に伴うセキュリティ関連の庶務作業の負担増加 * 要件定義業務に関連した社内調整や文書作成の負担が大きく、本来の要件定義の進捗に影響を与えていた。 # 取り組みと成果 * セキュリティ体制の整備 * 課長・部長らに状況を説明し、全体的なセキュリティ取り組みを開始。 * 対策状況を整理し、8割のセキュリティルールが適用済みになり、全体的なセキュリティ強化の基盤を整えた。 * セキュリティ知識の強化と実践 * 情報処理安全確保支援士の学習を開始し、週10時間の学習を継続。 * 学習を通じて得た知識を活用し、要件定義時にセキュリティルールを満たしているか判断できるようになった。 * 設計・開発チームとの連携強化 * 開発の実態をヒアリングし、現実的なセキュリティレベルと運用方法を検討。 * その結果、開発プロセスにセキュリティレビューを組み込み、早期段階でのリスク対策を実現。 * セキュリティルール順守の体制変更 * 要件定義業務を設計・開発チーム主導へシフトし、文書作成は手順書を作成し業務分担。 * その結果、セキュリティ対応の遅延が解消した。 # 工夫した点 * 自分の意見を持つこと * セキュリティに対する意見を持ち、能動的に発信することを意識した。 * その結果、要件検討の段階でセキュリティ考慮が行われる割合が向上し、要件決定の精度が向上した。 * 課長・部長らと密な連携 * セキュリティルールの遵守が難しい場面では、課長・部長と定期的に状況を共有し、迅速な意思決定を行える体制を構築した。 * その結果、セキュリティ対策の検討スピードが向上し、リスクの早期検知・対応が可能となった。