ID:84954さん

## ＃プロジェクト経験概要 大手通信会社の決済システムにおける、加盟店向けWebポータルの要件定義から設計・実装・テスト・リリース・運用保守までを一貫して担当しました。加盟店が自社の請求データを参照する検索機能を中心に開発し、検索APIのパフォーマンス改善とテスト自動化によるデグレード検証の効率化については、自ら課題を提起して推進しました。 ## ＃チーム情報 - 計8名（エンジニア6名、設計担当1名、顧客折衝を担うリーダー1名）の体制で、ウォーターフォール型の開発を行いました。 - 自身はエンジニア6名のうちの1名として実装を担当しつつ、性能改善とテスト自動化については課題提起から実行までを主導しました。 - 仕様の不明点や顧客要望はRedmineでチケット化し、リーダー経由で顧客に確認する運用を徹底しました。工数配分や新たな施策への着手など、スケジュールに影響する判断は必ず事前にリーダーと合意を取り、独断で進めないことを原則としていました。 --- ## ＃開発・実装内容A：加盟店向け請求データ検索機能の設計・実装とSQLチューニング ### 【概要】 加盟店が自社の請求データを検索・参照するための画面およびAPIの詳細設計と実装を担当しました。大量データに対する検索応答速度が要件を満たさなかったため、SQLの見直しにより実行時間を約30%短縮しました。 ### 【どのような機能の開発・実装か】 - 加盟店向けWebポータルの請求データ連携機能です。検索条件を受け取り、該当する請求データを返却・表示します。 - バックエンドはLaravelで実装しました。フロントエンドはLaravelのテンプレートとjQueryを用いた画面構築を基本とし、一部の動的な挙動をTypeScriptで、レイアウトをBootstrapで実装しました。 - ローカル開発環境はDocker / Docker Composeで構築・運用しました。 ### 【課題・問題点】 - 検索対象のデータ量が多く、初期実装のSQLでは応答速度が要件を満たせませんでした。 - スケジュールが固定されている中で、既存実装を最大限流用しながら要求仕様を満たす必要があり、「どこを作り込み、どこを流用するか」の工数配分の判断が求められました。 - 自身はSQLチューニングの経験が浅く、独学で試行錯誤するとスケジュールを圧迫するリスクがありました。 ### 【打ち手・使用した技術】 **どのように考えたか** まず、遅延の原因がアプリケーション側のロジックにあるのか、SQLの実行計画にあるのかを切り分け、後者が主因であると判断しました。その上で、「自分で調べ切ること」よりも「チーム内にすでにある知見を最短で取り込むこと」を優先すべきだと考えました。期限が固定されたウォーターフォール案件では、学習コストを自分だけで負担するとクリティカルパスを直接圧迫するためです。ただし答えをもらうだけでは自分に何も残らないため、レビューは「指摘の理由まで確認する場」として活用することを意識しました。 **実施したこと** - ボトルネックとなっているクエリを特定した上で、JOINおよびサブクエリの構成を見直し、検索処理を高速化しました。 - SQLチューニングに知見のあるメンバーへ早期にレビューを依頼し、指摘内容を実装へ反映するとともに、なぜその書き方が速いのかを確認して、以降の実装に横展開できるよう判断基準を自分の中で言語化しました。 - 設計面では、既存実装の流用範囲をリーダーと合意した上で切り分け、新規実装は要件充足に必須の箇所に限定することで、スケジュール内に収めました。 - 仕様の不明点はRedmineでチケット化し、リーダー経由で顧客へ都度ヒアリングを行い、口頭確認による認識齟齬と手戻りを防ぎました。 **成果** - 検索時のSQLクエリ実行時間を約30%短縮し、ポータル利用時のユーザビリティを改善しました。 - スケジュール遅延なく、要件定義からリリースまでを完遂しました。 --- ## ＃開発・実装内容B：Playwrightによる単体テスト・デグレード検証の自動化 ### 【概要】 繰り返し発生する単体テストとデグレード検証をPlaywrightで自動化し、テスト工数を約50%削減しました。品質担保と工数圧縮を両立させ、結果としてAのパフォーマンス改善も加速させました。 ### 【どのような機能の開発・実装か】 - Playwrightを用いた、単体テストおよび改修時のデグレード検証（回帰テスト）の自動実行環境の整備です。 - 対象は加盟店向けWebポータルの検索機能を含む主要画面・APIです。 ### 【課題・問題点】 - 改修のたびに手動でのデグレード検証が必要となり、テスト工数が肥大化していました。 - 特にパフォーマンス改善のためのクエリ修正は既存の検索結果に影響を与えるリスクがあり、「性能改善のために手を入れるほど検証コストが増える」というトレードオフが発生していました。 ### 【打ち手・使用した技術】 **どのように考えたか** 性能改善と品質担保はトレードオフに見えますが、その本質的な原因は「検証が手動であること」にあると考えました。検証コストを自動化によって固定費化できれば、改修回数が増えても総工数が増えない構造に変えられます。短期的には自動化に工数を割くことになりますが、残りの開発期間で必要となる改修回数を見積もった結果、中長期では十分にペイすると判断しました。この見通しをリーダーに説明して合意を取った上で着手し、独断で工数を消費することは避けました。 **実施したこと** - Playwrightでテストをコード化し、改修のたびに一括実行できる状態を整備しました。 - デグレード検証の観点を整理し、繰り返し実行される検証項目から優先的に自動化しました。 - Docker / Docker Composeによる環境統一により、テスト実行結果が実行者の環境に依存しない状態を確保しました。 **成果** - 単体試験およびデグレード検証の工数を約50%削減しました。 - 検証サイクルが短縮されたことでクエリチューニングの試行回数を確保でき、Aの性能改善にも寄与しました。 - リリース後の運用保守フェーズにおけるメンテナンス負荷の軽減につながりました。 --- ## ＃開発・実装内容C：AWSへのリリース作業と月次SLA報告 ### 【概要】 AWS環境へのリリース作業およびリリース後の検証を担当し、あわせて月次のSLA報告資料の作成・顧客提出を継続的に実施しました。 ### 【どのような機能の開発・実装か】 - AWS上で稼働する加盟店向けWebポータルのリリース作業と、リリース後の動作検証です。 - 稼働実績データを集計し、SLA遵守状況をまとめた月次報告資料を作成・提出する運用業務です。 ### 【課題・問題点】 - 決済に関わるシステムであり、リリース時の不具合が加盟店の業務に直結するため、確実性の高いリリース手順が求められました。 - SLA報告は毎月発生する定型業務であり、単に数値を提出するだけでは、システムの状態をサービス品質の観点で説明できませんでした。 ### 【打ち手・使用した技術】 **どのように考えたか** リリースとSLA報告は一見別の業務ですが、実際には「リリース内容が翌月のSLA数値として返ってくる」という一本の線で繋がっています。そのため報告資料の作成を単なる事務作業として処理せず、自分たちの改修が稼働品質にどう影響したかを確認する機会として扱いました。この視点は、AやBで取り組んだ性能改善・テスト自動化の優先順位づけを判断する際の根拠にもなりました。 **実施したこと** - AWS環境へのリリース作業と、リリース後の検証テストを担当しました。 - 稼働データを集計し、SLA遵守状況をまとめた月次報告資料を作成して顧客へ提出しました。 - 報告値の推移から品質面の懸念点を把握し、改善施策の優先順位づけに反映しました。 **成果** - リリース起因の重大な障害を発生させることなく、安定した運用を継続しました。 - 顧客に対してサービス品質を定量的に説明する体制を維持し、信頼関係の構築に貢献しました。

## ＃プロジェクト経験概要 電子辞書向けの追加コンテンツ管理ソフトとECサイトの設計・開発を担当しました。Reactによる新規フロントエンドの構築とLaravelでのバックエンド開発に加え、米国の外注先との協業体制の立て直し、およびPHPバージョンアップ対応を担いました。 ## ＃チーム情報 - 調整役のリーダー1名と開発メンバー3名の計4名体制で、アジャイル開発を推進しました。 - 加えて、テキストエディタ部分を米国企業へ外注しており、実質的には時差をまたぐ分散開発の体制でした。 - 自身はフロントエンドとバックエンドを横断して開発を担当し、顧客とのQA対応を主導しました。外注先との連携ルールの整備についても、自ら手を挙げて担当しました。 --- ## ＃開発・実装内容A：米国外注先との協業体制の再設計 ### 【概要】 時差・言語・開発文化の違いにより外注先との連携が停滞していた状況に対し、タスク管理と言語運用のルールを策定しました。結果として、仕様問い合わせの回答リードタイムを3日から1日へ短縮しました。 ### 【どのような機能の開発・実装か】 - 外注先の米国企業が開発するテキストエディタを、自社の追加コンテンツ管理ソフトへ統合する部分の仕様調整と連携実装です。 - あわせて、統合作業を支えるチーム間の情報共有基盤として、Backlog上のタスク管理ルールを整備しました。 ### 【課題・問題点】 - 時差と開発スタイルの違いにより、仕様の問い合わせから回答まで3日かかる状態が常態化していました。 - やり取りが個別の会話に閉じており、誰が何を確認済みなのかがチーム内で見えませんでした。 - 複数国間での仕様調整が必要で、英語を共通言語として運用しなければ意思疎通が成立しない状況でした。 ### 【打ち手・使用した技術】 **どのように考えたか** 当初、遅延の原因は「時差」だと捉えられていました。しかし時差そのものは変えられない以上、そこを問題設定にしても打ち手が出てきません。実際に何が起きているかを整理すると、遅延の多くは往復回数の多さに起因していました。一度の問い合わせで意図が伝わらず、確認のやり取りが複数回発生することで、時差の影響が回数分だけ累積していたのです。したがって打つべき手は「速く返してもらうこと」ではなく「往復回数を減らすこと」であると判断し、非同期のやり取りでも一往復で伝わる形式に寄せる方向で施策を組み立てました。 **実施したこと** - Backlogを中心としたタスク管理ルールを策定し、問い合わせを口頭や個別チャットではなくチケットへ集約しました。これにより確認状況をチーム全員が追える状態にしました。 - 翻訳ツールを併用しつつ、英語を公用語とする運用ルールを明文化しました。「その場にいる人が訳す」という属人的な運用をやめ、記録が常に共有可能な状態を保ちました。 - 仕様や画面の認識合わせにはFigmaのデザインデータを共通の参照点として用い、テキストのみの説明で生じる解釈のブレを構造的に排除しました。 **成果** - 仕様問い合わせの回答期間が3日から1日となり、約66%短縮しました。 - 仕様確認の迅速化により開発スピードが向上し、納期の遵守と品質の両立を実現しました。 - 外注先との連携が改善し、チーム全体の情報流通が透明化しました。 --- ## ＃開発・実装内容B：Reactによる新規フロントエンド開発 ### 【概要】 実務経験のなかったReactでの新規フロントエンド設計・実装を担当しました。学習期間をあらかじめスケジュールに織り込むことで、品質を担保しながら納期を遵守しました。 ### 【どのような機能の開発・実装か】 - 電子辞書の追加コンテンツ管理ソフトおよびECサイトのフロントエンドを、Reactで新規構築しました。 - Figmaのデザインをもとに、細かなUI要望を継続的に反映しました。 - 顧客とのQA対応を主導し、要望のヒアリングから実装への反映までを担当しました。 ### 【課題・問題点】 - Reactの実務経験がない状態でのアサインであり、我流で書き進めると設計が破綻し、後半で作り直しが発生するリスクがありました。 - アジャイル開発で顧客要望を継続的に取り込む前提であったため、変更に弱い作りにすると後工程のコストが跳ね上がる構造になっていました。 ### 【打ち手・使用した技術】 **どのように考えたか** 「間に合わせるために、とりあえず動くものを書く」という進め方は、この案件では逆効果になると判断しました。継続的に要望が追加される前提であれば、初期の設計品質がそのまま後半の変更コストに直結するためです。そこで、着手前に調査・学習の期間を明示的にスケジュールへ組み込むことをリーダーと合意しました。学習を個人の努力、すなわちスケジュール外の見えないコストとして処理せず、計画の一部として可視化することで、品質と納期の両立を成立させる狙いでした。 **実施したこと** - Reactの調査・学習期間を工程として確保し、設計方針を固めてから実装に着手しました。 - Figmaのデザインデータを基準としてUIを実装し、デザインと実装の乖離を最小限に抑えました。 - バックエンドはLaravelで構築し、2年目にはPHPのバージョンアップに伴うコード修正とテストを担当しました。 - Docker / Docker Composeによる開発環境のコンテナ化を推進し、環境差異に起因する不具合を排除しました。 **成果** - 未経験の技術でありながら納期を遵守し、品質を落とすことなくリリースしました。 - 顧客からReactの習得速度と対応力・柔軟性を評価いただき、継続的な信頼関係の構築につながりました。 --- ## ＃開発・実装内容C：電子辞書デバイスとの接続部分の改修（C#） ### 【概要】 管理ソフトと電子辞書デバイスを接続する部分はC#で実装されており、Web側の仕様変更に伴う影響箇所の確認・改修に一部携わりました。 ### 【どのような機能の開発・実装か】 - 管理ソフトから電子辞書デバイスへコンテンツを連携する接続部分の処理です。この領域はC#で実装されていました。 - 主にWeb側の改修に伴う影響範囲の確認と、それに応じた軽微な修正を担当しました。 ### 【課題・問題点】 - 自身の主担当はWeb側（React / Laravel）であり、C#部分は普段触れない領域でした。 - 一方でWeb側の仕様変更がデバイス接続部分に影響するケースがあり、Web側だけを見て判断すると影響を見落とすリスクがありました。 ### 【打ち手・使用した技術】 **どのように考えたか** 担当外の言語であることを理由に接続部分をブラックボックスのまま扱うと、影響範囲の判断を毎回他者に依存することになり、確認のたびに待ちが発生します。全面的に習熟する必要はないものの、少なくとも「どこがWeb側と接続しているのか」を自分で追える程度には把握しておくべきだと考え、必要な範囲に限定してコードを読み解く方針を取りました。 **実施したこと** - C#で実装されたデバイス接続部分のうち、Web側と接点を持つ箇所を中心に読み解き、影響範囲を自分で判断できる状態にしました。 - Web側の改修に伴い必要となった軽微な修正に対応しました。 **成果** - Web側の変更が接続部分へ与える影響を早い段階で把握できるようになり、確認のための待ち時間を削減しました。 - 主担当領域にとどまらず、システム全体の構造を踏まえた判断ができるようになりました。

## ＃プロジェクト経験概要 大手通信会社のQR決済システムにおけるBFF（Backend For Frontend）の開発とテスト設計を担当しました。複数のマイクロサービスとフロントエンドの間に立ち、仕様の整合性を担保する調整役を、実装者の立場から担いました。 ## ＃チーム情報 - リーダー1名、設計1名、テスター2名、開発者5名の計9名体制で、アジャイル開発を行いました。 - 自身は開発者5名のうちの1名です。BFFという性質上、フロントエンドチームと各バックエンドマイクロサービスの双方に接点を持ち、設計と実装の橋渡し役を担いました。 --- ## ＃開発・実装内容A：BFFのAPI開発およびスタブ環境の整備 ### 【概要】 複数のマイクロサービスを束ねるBFFのAPIを実装しました。あわせて、スタブの設定ページをLaravelで構築し、他チームが自分の進捗を待たずに開発を進められる状態を整えました。 ### 【どのような機能の開発・実装か】 - QR決済システムにおけるBFFのAPI実装です。フロントエンドからの要求を受け、複数のバックエンドマイクロサービスを呼び出して整形・返却する機能を担います。BFF本体はフレームワークを用いず、素のPHPで構築されていました。 - 上記に加え、スタブの応答内容を設定するための管理ページをLaravelで構築しました。 - ローカル開発環境はDocker Composeで構築しました。 ### 【課題・問題点】 - BFFは複数のフロントエンドとバックエンドマイクロサービスの中間に位置するため、双方のAPI仕様を把握する必要があり、仕様の調整に多大な工数がかかっていました。 - 仕様の不一致による実装遅延や手戻りが頻発し、開発効率の低下が懸念されていました。 - 参画初期は、実装と既存コードの不整合により作業が長期化していました。 - BFF本体がフレームワークを用いない素のPHPで書かれているため、規約に頼れず、既存コードの構造を読み解いた上で書き方を揃える必要がありました。 ### 【打ち手・使用した技術】 **どのように考えたか** BFFの遅延は、自分の実装速度ではなく「前提となる仕様がいつ確定するか」に律速されていました。したがって個人の作業効率を上げても解決しないと判断し、仕様が確定する前でも実装と検証を進められる状態をつくることを優先しました。具体的にはスタブによって依存関係を切り離し、他チームの開発が自分の進捗に依存しない構造にしました。スタブの応答設定については、依頼のたびに自分がコードを書き換える運用にすると自分自身がボトルネックになるため、設定ページを用意して他メンバーが自律的に操作できる形にしました。また、参画初期に手戻りが多かった原因は、設計意図を実装者が正確に受け取れていないことにあると考え、認識の同期を仕組み化する方向で対処しました。 **実施したこと** - 素のPHPで構築されたBFFに対し、既存コードの構造と記述の流儀を読み解いた上でAPIを実装しました。 - フロントエンドの並行開発を可能にするスタブを作成し、その応答内容を設定する管理ページをLaravelで構築しました。実装効率とテストの網羅性を両立させる粒度を意識して設計しました。 - API仕様書のレビューを担当し、実装側から見た技術的制約や仕様上の矛盾点を早期に指摘しました。 - Docker Composeによるローカル環境を整備し、環境依存の不具合を排除しました。 **成果** - 仕様の不整合を実装着手前に検出できるようになり、手戻りを大幅に削減しました。 - スタブ設定を他メンバーが自ら操作できるようになり、自身への依頼待ちが解消されました。 - API仕様の整合性が向上し、チーム全体の生産性向上に寄与しました。 --- ## ＃開発・実装内容B：設計と実装の認識齟齬の解消とテスト設計への関与 ### 【概要】 定例会議の議事録作成と継続的な認識合わせを主導し、参画初期に長期化していた実装・検証サイクルを、最長でも3日以内にテストへ着手できる状態へ改善しました。 ### 【どのような機能の開発・実装か】 - 設計者・テスター・開発者の間で情報を同期させる仕組みづくりです。 - あわせて、テスト設計および一部テストの実施を担当しました。 ### 【課題・問題点】 - 設計と実装の間で認識齟齬が生じ、実装完了後のテスト段階で差し戻される事象が発生していました。 - 仕様変更時の影響範囲がチーム内で共有されず、対応が後手に回っていました。 - テスターが別途2名いる体制のため、実装側の意図がテスト観点に反映されにくい構造になっていました。 ### 【打ち手・使用した技術】 **どのように考えたか** 手戻りが顕在化するのはテスト工程ですが、原因が生まれているのは設計と実装の受け渡し時点です。したがって、テストを厳しくするのではなく、受け渡しの精度を上げるほうが効率が良いと判断しました。また、口頭で合意した内容は時間が経つと双方の記憶が食い違うため、議事録という形で必ず文字に残すことを自分の担当として引き受けました。書く手間よりも、認識のズレが後工程で顕在化したときの損失のほうが大きいという見積もりに基づく判断です。 **実施したこと** - 定例会議の議事録を欠かさず作成し、設計者との合意内容を文字で残す運用を定着させました。 - 実装側から見た課題や技術的制約を能動的に共有し、設計に対して建設的なフィードバックを行いました。 - 仕様変更が発生した際は影響範囲を即座に洗い出し、チームへ共有しました。 - テスト設計にも関与し、実装者の視点から見た確認観点をテスト側へ提供しました。 **成果** - 実装品質が向上し、参画初期は長期化していた実装からテスト着手までのリードタイムが、最長でも3日以内に安定しました。 - 開発の手戻りを大幅に削減し、プロジェクトの安定的な進行に貢献しました。