ID:61001さん

# の開発 ## 主な機能 - 標的型攻撃メール訓練 * - 不審メール報告 * - セキュリティアウェアネス * - eラーニング - 社内アンケート *...私がメインでマネジメントしていた機能 ## PdMとして取り組んだこと - 担当機能のユーザーストーリー作成、開発のマネジメント - 不審メール報告機能の有償化（マーケット調査、価格設定、営業調整など）

# プロジェクト概要 営業支援システムの新規バッチ開発と既存バッチへ機能追加。バックエンド開発のチームでチームリーダー相当の役割を担い、タスク管理、要件整理、設計、バッチ機能実装など、バックエンドの開発業務をすべて担当。 本案件では1つの既存バッチ処理の機能追加、付随する3つの新規バッチ処理開発を行う。 # 言語/環境 - バックエンド - Java11 - Spring Boot 2.7.2 - Spring Batch - MyBatis - MySQL 8.0.30 - SQL Server - その他 - Git - Amazon S3（予定） - Amazon RDS（予定） # 開発手法 ウォーターフォール開発 # 規模 10人月程度 # 組織 チーム：4人 # 役割 チームリーダー相当 # 担当工程 基本設計、詳細設計、実装、単体テスト、結合テスト # 実績 開発に際して以下の課題があった。 - 運用されているバッチ処理に関する設計書や資料がなく、ブラックボックス化している - バッチ内のJavaの処理には使われていないコードが混ざっており、ソース管理が行き届いていない 参画後、上記の課題に気づき、まず設計書のリバース作業に取り組んだ。起こした設計書や資料を基に、既存のコードを机上で整理し、既存機能に影響が出ない実装方法を検討し設計に落とし込んだ。 また別ベンダーが担当する画面側（CMS）の仕様について、エンド企業の担当者と会議に参加し、バックエンド担当の目線から必要な要件や仕様を提示し調整を行った。 # 工夫した点 ## ドキュメント整備 「実績」欄の通り、資料が整備されておらず情報やスキルが属人化しているため、工数との兼ね合いも考慮しながら、解消に向けてできる限りドキュメント化を進めている。 ## 後輩育成、勉強会の実施 この現場で初めて、自社の後輩と参画し指導も行う立場となった。後輩指導の上で、まず自分で調べる習慣付けと質問しやすい関係性の構築を特に意識して取り組んでいる。 また、チーム内のスキル向上を目的に、勉強会を自主的に開催し、成長を促すチーム作りを行っている。 ## 設計段階での十分な考慮 排他制御、トランザクション管理、例外処理について、設計段階のうちに十分に考慮し、設計に落とし込んだ。経験上これらの項目は実装しながら具体的な検討をする場合もあったが、本案件の場合は社内ネットワークの内外にそれぞれDBが存在し、1つのバッチ機能で双方のDBとデータのやり取りを行うため、この部分の考慮を疎かにせず適切に設計すべきと考え、そのように行動した。

# プロジェクト概要 データセンターで使用される業務システムの新規開発で、バックエンドはJavaでRest API、フロントはVue.jsでSPAの実装を行った。フロントエンドの設計・実装・テストをメインで担当し、システム内で最も要件の多い、契約情報・顧客情報を扱う画面を実装した。 また、バックエンドはメインでは担当しなかったが、これまでのバックエンドの経験を活かし、API設計・DB設計について意見を出し、要件の整理やレビューも担当した。 # 言語/環境 - フロントエンド - Vue.js - Vuetify - axios - Mockoon - バックエンド - Spring Boot - Swagger - MariaDB - MyBatis - JUnit - その他 - Git # 開発手法 ウォーターフォール開発 # 規模 19人月程度 # 組織 チーム6人 + 管理者1名 # 役割 フロントエンド担当、一部バックエンドの補助 # 担当工程 基本設計、詳細設計、実装、単体テスト、結合テスト # 実績 新規開発に際して以下の課題があった。 - 基本設計からの参画にもかかわらず、要件が固まっていない箇所が多々ある - PL含め、メンバー6人全員がジュニアクラスのエンジニアで、技術力に不安がある - 事前の工数見積もりが甘く（少ない）、要件を固めると更に工数が膨れ上がること 参画後数日で上記の課題に気付いたため、まずは顧客に要求事項をヒアリングし、画面イメージを作ってそれを基に提案を行い、要件を固めるための行動をしました。その業務の中では、要求・要件に対して都度、DB設計・API設計の担当と話し合い、実現に向けて基本設計を進めた。 要件が決まったものの、工数が膨れ上がった点については、PLに可能な限り要件から外せないか調整することを依頼し、不足していると感じた技術面に対しては、業務外の時間でVue.jsのキャッチアップをすることでカバーし、実装・テストをやり遂げた。 # 工夫した点 ## 要件調整 主体的に提案した要件として、登録したデータの承認機能を具体例に挙げる。ヒアリングの後、提案する段階では必ず画面イメージを作って相手に画面操作がイメージしやすいよう心掛けた。 また承認機能を実現するために、承認用のステータスとロール制御が存在し複雑化していたため、マトリクス資料やデータライフサイクルをフロー図で表現し、提案・要件定義を進めた。

# プロジェクト概要 ISP事業者の社内で使用される請求情報・明細情報管理システムのリプレイス案件。 楽々フレームワークというFWから、Java・SpringBootを用いてMVCモデルでリプレイスした。 基本設計の工程からPGとして参画し、フロント・バックエンド両方を担当。 主にCSVファイルでのダウンロードやアップロード機能について設計・実装・テストを行った。 # 言語/環境 - フロントエンド - JavaScript - バックエンド - Spring Boot - MyBatis - MySQL - PostgreSQL - JUnit - その他 - Git # 開発手法 ウォーターフォール開発 # 規模 75人月程度 # 組織 チーム：8人（要件定義時：2人 → 基本設計時：4人 → 詳細設計 ～ 結合テスト：8人 # 役割 PG・SE # 担当工程 基本設計、詳細設計、実装、単体テスト、結合テスト、総合テスト # 実績 リプレイスを進めるにあたって以下の課題があった。 - 現行システムに関する設計書や資料がなく、内部処理がブラックボックス化している - 詳細設計以降人数が倍になり、システム理解の習熟度を引き上げる等のフォローが必要だった - 製造の見積り工数に対して、実際に必要な工数が足りないことが製造前に発覚した そのような状況下で、設計については現行システムをリバースして設計書を起こし、新仕様を踏まえたリプレイス後の設計書を作ることで内部の透明化を図った。また詳細設計・製造工程での課題については、詳細設計を行いながらメンバー全員を巻き込んで検討会を行うことで習熟度の向上を図り、実装に向けてどうすれば少ない工数で進めれられるかを考えて、実装の無駄削減に向けた行動をした。（工夫点：共通化資料や手順書の作成・共有） # 工夫した点 ## メンバーのフォロー あるメンバーが進捗が良くなく、黙って深夜まで作業していることを自分だけが気付いたことがあった。状況を聞き、PLに相談の上、躓いていたフロント実装を自分が巻取り、メンバーのフォローをすることでチーム全体の進捗回復に貢献した。 ## 共通化資料や手順書の作成、共有 製造工程のスケジュールがタイトだと把握したため、チーム内の無駄な作業を極力減らしたいと考えた。 目を付け行動したのが、フロント実装の無駄の削減だった。当時、フロントエンドFWの知識はなく、案件でもその技術は選定されていなかったが、HTMLやCSSの画面のソースは、再利用性が高い部分だと自分なりに考え、共通化可能な部分は資料とソースを作成後、他のメンバーに共有し使ってもらうことで、実装コストの無駄の削減に繋げた。

# プロジェクト概要 大手金融系のシステム更改案件の設計業務。実装はニアショア拠点にて行う方針だったため、基本設計を担当するチームで帳票設計を担当。金融案件の設計作法や勘定系APIを学びつつ、基本設計や機能設計を行った。 また設計内で、JavaScript, HTML, CSSを使って画面モックを作成。 # 言語/環境 - フロントエンド - JavaScript - HTML, CSS - その他 - SVN - Excel # 開発手法 ウォーターフォール開発 # 規模 チームとしては10人月程度（プロジェクトは大規模） # 組織 全体：100～200人、チーム：4人 # 役割 PG # 担当工程 現行仕様調査、基本設計 # 実績 本案件では、私自身に以下のような課題があった。 - 利用する勘定系APIは項目数が膨大かつ複雑で仕様理解のハードルが高い - 金融系の設計業務ということもあり設計の粒度が細かく、高水準のレベルが求められる 幸い、基本設計前のインプットとして、現行仕様を理解・調査する期間が1ヶ月程度設けられていたため、その期間で勘定系APIについて理解を深め、不明点はQAを通して勘定系APIの設計者に積極的に確認した。その後の基本設計では、下記を実践し設計書のレベルを向上させた。 - 設計マニュアルを読み込んで1つずつ丁寧に反映し、セルフレビューで細かい記載を修正 - 勘定系APIの取得値の具体的な型や値をQAで確認し、帳票出力時に必要な文字列操作などを詳細に定義 - 一度指摘されたことは一覧化しておき、それを基に設計書レビュー前にセルフレビューを挟む # 工夫した点 ## QAを通して確認したいことの言語化、正しい日本語を使う習慣化 技術的な専門用語を使って文章だけでやり取りを行う必要があり、5W2Hが足りないことによる認識齟齬を生まずにQAのやり取りを行い、設計に反映する必要があった。苦手と感じたことだったので、何度も上司に添削をお願いしながら、言語化と正しい日本語を使うという点を意識して文章を作成し、QA作業を行った。