シューザー

◆プロジェクト概要
◇目的、背景
金融業界向けの証券情報の連携システムの作成。
法改正も絡んだことによる、現行システム＋新規機能を組合わせたシステムの開発を実施。

◇規模感、チーム構成、担当した役割
プロジェクト全体で30名以下。所属チームはオンライン側の開発。
オンライン、認証、環境、バッチと４チーム構成。
オンラインチームとして、全体8名の中でリーダを担当。
役割としては以下担当
設計：基本・詳細設計、レビュア
開発：API処理機能（Java、SQL）、レビュア
試験：単体、連結、総合、性能、プレ本番
管理：上記スケジュール管理、工数見積もり、課題・故障管理
環境：試験環境構築、リリース管理

◇使用技術や開発環境等
フロントエンド：JavaScript、TypeScript、HTML、CSS
サーバエンド：Java、SQL
データベース：Oracle
開発環境：eclipce、Spring Tool Suite（STS）、VSCode、Angular
インフラ：Docker、kubernates、Oracle Cloud Infrastructure（OCI）
使用技術：gitLab、Gradle、A5M2、MyBatis、ZOOM

◆具体的にどんな事をしたか
◇設計
リバースエンジニアリングからの設計や影響調査を含め、大規模システムに対しても精度の高い調査経験がありますので、その能力を活かして、約120処理ある現行システムのサーバ処理数を最終的に約80処理まで減らす実績を作りました。方針として、保守性の向上や後工程の作業工数削減を目指して取り組みました。具体的にはサーバ処理の共通箇所を統一するため、同じDBサーバへのSQLクエリやファイルアクセス処理のディレクトリ名の違いなどを考慮し、同一処理に統一しました。結果的に開発やテスト工数が半分となり工数削減にも大きく貢献できました。また、現行設計書は画面とサーバ処理が同じドキュメントで管理されていたため、どこまでがどの処理か切り分けが難しい特性がありました。そこで、画面とサーバ処理を分けて設計書を作成し、処理が判別できるようにし、設計書の記載ルールも明文化しました。設計書の読み方なども定期的にプロジェクトメンバに対して開催し、チーム全体の能力均一化も心掛けました。

◇API開発～単体テスト
SpringでのAPI開発とレビューを主に担当しました。オンライン業務（エンドユーザが画面操作する箇所）のAPIに対して、開発期間中は1日に3～5つのAPIのコーディングレビューを実施しました。プロジェクトルールとしてコーディング規約を厳守し、単体テストでJUnitのC1カバレッジを100%にすることが決められていました。これをチーム全体で遵守しているかや業務ロジックとして適正かを確認し、レビュー表で指摘内容を管理し、確認完了までステータスが変更されているかまで管理しました。さらに、設計書に沿ったコーディング、効率化、無駄な実装の排除をレビューで確認しました。

◇プロジェクトマネジメント業務
当初はサブリーダーとして参画しましたが、主体的に作業を行い、チームメンバーを巻き込んでの業務推進が評価され、オンライン業務のリーダーを担当しました。開発から試験までの進捗を管理し、オンスケジュールを目指しました。過去案件で培ったインシデント対応の経験を活かし、作業割り振りを効率よく行い、リーダーとしての業務を遂行しました。仕様変更や課題対応が発生した際には作業調整を行い、適材適所を意識したマネジメントを実施していました。オンライン以外のメンバも含む最大15人のメンバーを率い、全体で作業を依頼し、適材適所で業務を行うよう調整し、振り返りを実施してチームがより良い方向へ進むように努めました。

◇試験環境構築
　開発だけでなく、試験環境構築にも初挑戦しました。Linuxでの作業経験はありませんでしたが、様々なトラブルを解決する中で知識を習得しました。思い出深いエピソードとして、性能故障時に試験環境のファイルサイズ上限値の変更やDockerのPODとCatalinaのメモリ変更を行い、基盤チームに必要なメモリやサイズの数値を提出し、承認を得て実装を進めました。本プロジェクトは現行踏襲で、文字コード変更によるバイト数変更やDBスペック変更などの仕様変更もありましたが、これらを解決し非機能要件を満たす性能を達成しました。

◆取り組んだ課題
①独自FWのマニュアルがない状態
独自FW→Angular＋Springへの仕様変更がメインのリプレイス開発です。独自FWの影響調査から入りましたが、独自FWに対するマニュアルが一切連携されずに開始したので、かなり進捗が滞ってしまった、課題がありました。

②単純ミスを簡単に片づける傾向がある
メンバの中で単純ミスなので、ミス自体を軽視している傾向がありました。
そのため、結果的に同じミスを誘発し、進捗の遅延を招いていました。

③自動化テストの処理が大幅に遅れている
本プロジェクトではGitLabでCI/CDパイプラインを使用し、テストを自動化していました。ですが、API処理の検索結果が100パターンあるAPIに対し、テストメソッドが増加することでCI/CDパイプラインの実行速度が平均90分かかり、試験効率に影響しました。

◆取り組みの成果
①選考で調査している別チームがいたので、そこからの調査内容を連携してもらうようにすると、かなり調査の進捗効率が上がりました。今回のようにチーム間の連携を円滑にすることで作業効率が上がるので、そこの部分を円滑にするように作業報告を朝夕会での口頭報告だけでなく、チャットで清書したものを報告してもらうように対策し、何で困っているかを明確にして、情報連携しやすい体制にさせました。

②再発防止策の徹底
なぜそうなったかの原因分析を自他合わせて、徹底的に行いました。なぜなぜ分析を実施し、根本原因を明確化しそれを起こさせないための改善をさせ、再発防止を徹底させました。

③自動化テストの環境設定変更
私たちはgitLabでの自動化テストで使用しているGradleの設定を変更し、オンライン側の10,000件くらいあるテストメソッドのパイプライン実行を並行実行にすることで、実行速度を平均90→40分に短縮しました。これにより、単体テスト自動化の効率化に貢献し故障や課題対応の効率を上げることができました。
開発フェーズ時には開発メンバ/人×約50分も残業などを減らすことができPJ全体の生産性アップに貢献できました。

◆プロジェクト概要
◇目的、背景
日本最大の通信サイトのオンラインサイト開発。
業務機能は別にあり、そこの業務チームから依頼を受けての開発やサイト自体のリプレイス開発などをメインに実施。

◇規模感、チーム構成、担当した役割
全体で400人規模。チーム構成は15チームほどあり、その中の一つのオンラインサイトに所属。
それぞれの会社ごとでチームを作成し、合計でオンラインサイトチームは8～10チームがあり、
その中で、以下を担当。
上記の作業以外にもチーム内の商用故障対応も実施。
設計：基本・詳細設計、レビュア
開発：画面（JSP）サーバ、API処理機能（Java、SQL）、レビュア
試験：単体、連結、総合、性能
管理：上記スケジュール管理、工数見積もり、課題・故障管理
他作業：インシデント管理、夜間待機、受け入れ作業

◇使用技術や開発環境等
フロントエンド：Java（JSP）、JavaScript、HTML、CSS
サーバエンド：Java、
データベース：Oracle
開発環境：eclipce、VSCode、独自開発ツール
インフラ：Docker

◆具体的にどんな事をしたか
◇開発
エンドユーザが商品購入やサービス手続きを行えるシステムを開発するWEBチームに所属し、画面開発やサーバ処理機能の開発を担当していました。フロントエンドやサーバサイドいずれも独自開発ツールを踏まえての開発となっており、プロジェクト独自のツール、業界用語、過去20年にわたるロジックの知識に加え、WEBチームには独自仕様（排他制御やアカウント取得）があり、習得に苦労しました。
　私は主にサービス手続きの会員周りの操作を担当し、アカウントIDやクレジットカードとの紐づけ処理を任されることが多かったです。少しのミスが大きなトラブルになる処理部分であったため、トラブルを避けるためのコミュニケーションロスや知識不足に焦点を当て、対策を講じました。また、WEBチーム全体に対して業務仕様や処理内容に関する勉強会を実施し、情報共有を行ってきました。成果として、コーディングルールやツール使用手順の整理および運用方法の確立により、参画前に頻発していた商用故障を30％減少させ、チームの品質向上に貢献しました。これにより、商用故障や開発遅延を少なくすることができ、リーダ層にもご評価いただきました。

◇商用故障対応
サブリーダーとして、メイン案件対応に加え商用故障の対応も担当しました。具体的には、夜間対応、一次切り分け、お客様への障害報告など、インシデントの受付からリリースまでを一貫して対応しました。早朝から夜間までの長時間対応が求められることもあり、チームでローテーションを組むことで作業引継ぎを効率化し、属人化を防ぎました。WEBチームだけでなく他のチームにも影響を及ぼす故障が多発する中で、該当メンバーやリーダーと協力しながら暫定対応や本格対応の策を練り、円滑な商用故障の解決を目指しました。
　これにより、早急な報告やタスクの切り分けなど、チームリーダーに求められるスキルを磨くことができました。また、自身が故障担当として対応する際には、状況理解を深めるために事象の概要図を作成し、認識齟齬がないように有識者から情報を集めるなど、即時解決に必要な努力を惜しまずに行いました。また、１か月もかかるインシデント対応に追われた時期もあり、心身ともに疲弊しましたが、インシデント収束までやり遂げましたので、責任感を強く持って取り組めた件に関して自信になりました。

◆取り組んだ課題
①チーム間連携が上手くいかない。
業務チームとは件を跨いだりと拠点も違うし、商流も違う別会社ということもあり、コミュニケーションリスクがかなりありました。業務チームから追加機能実装の依頼自体が行われなかったたり、課題が大量にありすぎで埋もれてしまったなどが多発しました。

②独自ツールによる調査難航
プロジェクト自体10年以上の歴史があり、独自ツールに依存した開発体制となっていました。セキュリティの厳重さもありインターネットで調べることも制限があり、解らない点は早期に確認しないとそのままズルズルと遅延してしまう要因によく陥っていました。

◆取り組みの成果
①情報共有会や意識合わせの場を都度開催
独自仕様や要件定義に落としてないなどあり、設計書から読み込むのには限界があるため、観点として有識者に漏れがないかを確認したり、間に入っているPMOに全体の案件自体の手綱を握ってもらったりなどの対策を実施しました。
テレワークなどで中々会えない状況ではありましたが、直接会って会話するなど自分自身を覚えてもらえるようにコミュニケーションをとり認識ずれやミスマッチのリスクを取り除くように努めました。
WEBチーム全体に対して業務仕様や処理内容に関する勉強会を実施し、情報共有を行ってきました。成果として、コーディングルールやツール使用手順の整理および運用方法の確立により、参画前に頻発していた商用故障を30％減少させ、チームの品質向上に貢献しました。これにより、商用故障や開発遅延を少なくすることができ、リーダ層にもご評価いただきました。

②独自ツール仕様の確認会を定期的に開催
自信が有識者より確認した事項に関しては私より、定期的に確認会を実施しました。
逆に知らない場合は、有識者にアサインして説明かを実施し、チームメンバの作業の滞りにならないように
あらかじめ案件当初よりリスク管理をし、円滑に進められるように手配などを行いました。
リスク管理やメンバへの聞き込みを定期的に行うことで、知らないままという事態を減らし、故障の削減に貢献できました。

◆プロジェクト概要
◇目的、背景
物流システムのリプレイス案件になります。数ある画面の中で全体20%分の新規検索画面を担当し、
画面側とサーバサイドの製造をメインにしていました。

◇規模感、チーム構成、担当した役割
全体で20人規模の開発規模です。
チームとしては、画面開発をメインとしたチームに所属しました。
担当としては、共通詳細設計が3割、開発を7割で行い、
リーダからの指示を受けてから作業することもありましたが、
リーダの所属から離れて、他チーム(別会社)に所属しての開発も実施しました。

◇使用技術や開発環境等
フロントエンド：Javascript、HTML、CSS
サーバエンド：Java、SQL(ストアドプロシージャ)
データベース：Oracle
開発環境：eclipce、VSCode、
使用技術：A5M2

◆取り組んだ課題
①設計と並行しての開発作業
ストアドプロシージャの開発時点で設計ができておらず、開発と並行しての作業でした。設計者より指示頂いた内容を元に単体試験を実施し、その結果データを確認して、想定より相違あるのであれば、設計者に連携し都度修正を行うといった取組を行いました。

◆取り組みの成果
①コミュニケーション連携を密にとる
設計書ができていないというイレギュラーな事態でしたが、設計者と密にコミュニケーションを取ることで、連携漏れの内容に行いました。