ID:69026さん

# プロジェクトの詳細 BPO業務の進捗・契約・請求等を統合管理する業務効率化システムの開発を、要件定義からデリバリーまで一貫して実施しました。 ## チーム情報 - 体制：テックリード（バックエンド／フロント／インフラ横断） - 管掌：ジュニアエンジニア2名の育成、オフショアベンダーのマネジメント - 担当：プロジェクト全体の予算・人員・スケジュール管理 ## プロジェクトにおける自身の役割 - 要件定義 - 基本設計 - 詳細設計 - 実装 - テスト - UAT - システムアーキテクチャ設計 - テックリード（バックエンド／フロント／インフラ） - ソースコードレビュー - ジュニアエンジニア2名の育成 - オフショアベンダーマネジメント - 予算・人員・スケジュール管理（プロジェクト全体） # 施策詳細 ### 業務フローの再設計・効率化（ドメイン分解／境界・責務整理） #### 課題 BPO業務は進捗・契約・請求など複数の業務が密接に絡み、属人化や手作業・二重入力により、運用コスト増加やミス発生の温床となっていました。加えて、将来的な機能拡張や他システム連携を見据えると、業務とシステムの境界が曖昧なままではスケールしづらい状況でした。 #### 工夫 業務フローをドメインに分解し、境界（モジュール）と責務を整理した上で、システムの構造を再定義しました。さらに、各業務の状態遷移・入力責務・データ整合性を明確化し、運用で発生していたムダな確認・入力・差戻しを前提から削減しました。 #### 成果 徹底した業務フローの効率化により、人件費を60%削減しました。また、QCD目標をすべて達成しました。 ### システムアーキテクチャ設計（高品質・安全な連携／拡張性の担保） #### 課題 既存システムとの接続において、品質・セキュリティを担保しつつ、将来的な機能追加や連携先増加にも耐えられる拡張性が求められていました。短期的な実装最適に寄せると、後続の改修コストが増大するリスクがありました。 #### 工夫 全体アーキテクチャを設計し、既存システムとの接続方式を「安全性」「保守性」「拡張性」の観点で整理しました。加えて、バックエンド／フロント／インフラを横断してテックリードとして設計品質を統一し、ソースコードレビューを通じて実装のばらつきを抑制しました。 #### 成果 既存システムとの高品質かつ安全な接続を実現し、拡張性を持たせたアプリケーション設計を達成しました。 ### プロジェクト運営（QCD達成／育成／オフショアマネジメント） #### 課題 予算・人員・スケジュールの制約下で、品質を落とさずにデリバリーを完遂する必要がありました。また、オフショア委託範囲の管理や、ジュニアの立ち上げ・戦力化も並行して進める必要がありました。 #### 工夫 プロジェクト全体の計画・実行・モニタリングを行い、QCDの観点でリスクを早期に潰す運営を徹底しました。オフショアベンダーについては成果物レビュー／進捗・課題管理を仕組み化し、品質と納期の両立を図りました。ジュニア2名には設計・実装・レビューのフィードバックサイクルを回し、役割と期待値を段階的に引き上げました。 #### 成果 - プロジェクトのQCD目標をすべて達成 - オフショアベンダーに一部委託していた開発も予定通りに完了 - ジュニアエンジニア2名を育成し、2名ともミドルレベルに昇進

# プロジェクトの詳細 在庫移動・発送業務を支援するSaaSを新規開発。外部API提供会社との仕様調整・交渉も含め、立ち上げを推進しました。 ## チーム情報 バックエンドエンジニア（自分含め複数名）＋外部API提供会社（別組織）と協業 ## プロジェクトにおける自身の役割 - バックエンドエンジニアとして参画 - 要件定義（外部APIの仕様調整・交渉含む） - アーキテクチャ／IF設計（外部API依存の不確実性を吸収する設計） - 実装、テスト、運用保守 - MVPの優先順位付け／バックログ管理 - 既存基盤の流用によるコスト最適化 - 外部API開発会社へのAPI設計レクチャー（設計観点・例外系・運用観点の共有） # 施策詳細 ### 外部API不確実性の吸収（疎結合IF設計・例外系整備） #### 課題 外部API提供会社の開発状況や仕様の揺れにより、要件の確定・結合テスト・運用時の安定性に不確実性が残る状態でした。API障害やタイムアウト等が起きた際に、業務（在庫移動・発送）を止めない設計が必要でした。 #### 工夫 外部APIとの境界を明確にし、疎結合なIF設計を徹底しました。リトライ／タイムアウト／例外系（外部API異常、部分失敗、想定外レスポンス）を標準化し、運用時に切り分け可能なログ・エラーハンドリングを整備しました。あわせて定例・技術支援を通じて、外部API提供会社側にもAPI設計の考え方（互換性、例外設計、リリース手順）をレクチャーし、協業前提で品質を底上げしました。 #### 成果 要件定義開始から3か月でファーストリリースまで到達し、700店舗での導入に成功しました。外部API提供会社と協力してシームレスなシステム連携を実現し、類似APIの拡張時にも迅速に横展開できるアーキテクチャ基盤を構築しました。 ### MVP推進（バックログ管理・コスト最適化） #### 課題 新規SaaS立ち上げでスピードが求められる一方、外部APIに依存するため手戻りリスクが高く、コスト増につながりやすい状況でした。 #### 工夫 MVPとしての機能を明確化し、優先順位付けとバックログ管理でスコープをコントロールしました。また既存基盤を流用して初期コストを抑えつつ、外部APIの不確実性を吸収できる設計・運用を先回りで整備しました。 #### 成果 短期間（3か月）での初回リリースを実現し、導入規模（700店舗）までスムーズに展開できる形でサービスを立ち上げました。以降の類似API拡張にも耐えられる構成として、継続的な機能追加に繋がる土台を作りました。

# プロジェクトの詳細 ## チーム情報 ネイティブエンジニア（3人） バックエンドエンジニア（自分含め2人） # プロジェクトの詳細 スタートアップのバックエンドエンジニアとしてライブ配信アプリの立ち上げと新機能開発を担当しました。ネイティブアプリの上流設計も担当しました。 ## プロジェクトにおける自身の役割 - 要件定義 - 全体アーキテクチャの設計 - API開発 - バックエンド、ネイティブ開発のリードエンジニア - エンジニアリングマネージャー # マネジメント、リーダー経験について❶ ## プレイングマネージャーとしての業務 #### 課題 プロダクトの年数に比べて技術的負債がかなり多いことが課題として上がっていました。 原因としては - 明確な設計指針が決まっていない - コーディング規約がない - とりあえずリリースすることが目的になっている（それを保守していくという意識がない） の三つが挙げられました。 #### 工夫 まず短期的にできる施策としてコーディング規約の明確化や設計指針の明確化を行いました。メンバー全体のmtgで自分の設計を発表しメンバーからも賛否の意見をもらうことで自分がこの決定に携わったという意識を各々に持ってもらいました。保守意識の向上については、中期的な施策にはなりますが、機能を作るときに負債が原因で工数が増える例を毎日の定例で取り上げることで後々困るのは自分たちという意識づけも行いました。 #### 成果 その結果、レビューでも規約に沿っていないなどの指摘が飛び交うようになるなどポジティブな変化が見られました。また、見積もりの際にも既存の負債の解消や新たに余計な負債を生まない工数も含まれるようになり、保守性の向上の意識がチーム全体に浸透していきました。ネガティブな側面としてはとりあえず設計とか気にしずに作りたいというモチベーションのメンバーが離れていくきっかけにもなってしまいましたが、プロダクトの成長という観点で言えばポジティブな面が多かったと思います。 ## プレイングマネージャーとしての業務❷ ### 開発フロー全体を見直し、デグレを８割減 #### 課題 リリースの度に大きめの不具合が出てしまっていました。前述のユニットテストの不足もありますが、１番の問題はQAが十分になされていないことが問題でした。技術的負債がかなり溜まっていたので、デグレがかなり起きやすい状況になっていましたが、それをカバーしうるだけのQAができていませんでした。また通しテスト中に数多くの不具合が出てきて、特定機能のRevertやリリースの延期などを余儀なくされる状況でした。 #### 工夫 マージ前の機能ごとのQAとリリース前の通しQAを積極的に行うことにより、開発時にデグレが起こらないようにするフローを組みました。また通しQAの項目も不足していたので全機能を洗い出し、それぞれの項目に強弱をつけ全体への影響があまり出ないようにもしました。 #### 成果 リリースの度に起こっていた不具合を約８割減少させることに成功しました。また、マージ前のQAを実施したことにより、リリース時の通しテストで報告される不具合もかなり減らせたおかげで安定したリリースフローの実現ができました。 ## バックエンドとiOSチームのテックリードとしての業務 #### 課題 上記の技術負債の他に技術的な知見が少ないこともチームの課題として挙げられました。CTOが技術的にそこまで深ぼった経験がない方ではあったので致し方のないことでもありました（それを悪とは思っていないです）が、プロダクトの成長には技術的な専門性の向上を各チームで行う必要があると感じました。 #### 工夫 バックエンドとiOSのそれぞれでお手本となるようなものを作るため、ある機能のリファクタリングを企画しました。これに準えて実装すればある程度の質は担保されるというものを目指しました。iOSについては実装は他の方に任せることで属人化を防ぐ取り組みもしてみました。 #### 成果 その結果、他の機能もお手本の機能に倣ってリファクタしていきたいという声がチーム内から出るようになりました。実際のリファクタについても、自分の指摘を元に他の方が似たような指摘をまた他の方にしていくという流れが作れ、チーム全体としての技術力の底上げを図ることができました。 # 代表的な施策 ### 長期の運用を見越した堅牢な設計技術の導入 #### 課題 Laravelを使用しており、特定の範囲への責務の肥大化やコードの継ぎ足しによる複雑化が進んでおり、ある機能を修正すれば別の機能の不具合が高い確率で発生する状況でした（当然ユニットテストもほぼありませんでした） #### 工夫 ドメイン駆動開発の一部とCleanArchitectureを導入し、一つ一つのクラスの責務を整理し配置し直すことで修正による影響範囲を限りなく小さく納めることにしました。その結果、機能改修時に別の機能がバグを起こすということはほぼ起こらなくなり、ユニットテストも十分に実装することができました。またバックエンドだけではなく、ネイティブチームへも助言を行い、バックエンドと同じような設計の見直しやユニットテストの導入も進めていました。 #### 成果 変更箇所が局地的になったことによる他の箇所でのバグの発生を少なくすることに成功しました。また、CleanArchitectureを採用したことにより、ビジネスロジック、アプリケーションロジック、プレゼンテーションロジックを実装前に考える必要性が出てきたことにより、実装の抜けもれや仕様の抜け漏れの指摘などが各エンジニアが自分でできるようになりました。 ### 大規模施策の推進 #### 課題 リソースが少ない中で事業計画に沿った機能開発をするために、スピード感を持って機能の開発にあたる必要があった。技術的負債が多い中で複雑な機能をその上に作っていく必要があった。 #### 工夫 自分がPMを兼任することでPdMからの仕様の吸い上げから実装までのリードタイムをなるべく少なくするようにしました。またネイティブ開発も一部兼任したことでAPIの仕様などをスピード感を持って決めることができました。既存の箇所に新機能を実装していく部分については、納期と相談しながら適時技術的負債の解消にあたった。技術負債の解消には自分がバックエンドとクライアントサイドの一部を両方兼任することで余計なコミュニケーションロスを減らし、数時間から数日で解決するようにしました。リリース遅延をなくすためにQAの方と協力して境界値テストや既存のデグレチェックなどをかなり手厚くしてもらいました。 #### 成果 ファンランキング機能や課金システムと連携したいいね機能の拡張などの複雑な機能を事故なく遅延なくリリースすることができました。ユーザーからの評判の声もかなり良く、文字通りやって良かったと言えるプロジェクトになりました。 ### DBパフォーマンスの向上 #### 課題 リアルタイムの通信が多く行われる状況下でDBのパフォーマンスの問題が顕著になっていました。特にランキングの集計に負荷がかかっており、その度にサーバーリソースが枯渇するという問題があった。 #### 工夫 スロークエリの発見と実行計画をもとにしたインデックスの付与などを行いました。またランキングの集計については、そもそもの設計から見直しました。具体的にはランキングを取得する際に毎回集計処理をしていた部分を、redisのzindexの機能を使い集計を都度行うようにすることで、サーバーに負荷を与えすぎずに要件を満たせるようにしました。 #### 成果 スロークエリの解消により、全体のDBのパフォーマンスが目に見えてわかるくらいに改善しました。またランキングの集計も毎回サーバーが落ちていたところから、大規模イベントのランキング集計にも耐えれるようになりました。

# プロジェクト概要 ## チーム情報 ネイティブエンジニア（自分含め、5人） フロントエンドエンジニア（自分含め、6人） バックエンドエンジニア（自分含め4人） # プロジェクトの詳細 サイバーエージェントのDX事業部で外資系小売企業のアプリ開発とバックエンドの認証基盤を実装しました。内定者インターンという立場でしたが、リーダー業務を任せてもらえるなど正社員と遜色ない働き方をしていました。 ## プロジェクトにおける自身の役割 - 要件定義 - シーケンスの設計 - API開発 - Flutterのリードエンジニア - 会員統合プロジェクトのプロジェクトリーダー - DevOpsの推進 # マネジメント、リーダー経験について ### 会員統合プロジェクトのプロジェクトリーダー #### 課題 開発期間が少ない中で複雑な要件である認証周りの機能を事故なく完遂しなければいけなかったことが大きな課題です。認証には既存の会員情報を統合する要件も含まれており、外部の認証サーバーを考慮する必要がありました。また、LINEアプリについてもOAuthを用いたLINEの認証を通す必要がありました。 #### 工夫 認証自体を難しくしているのが外部の認証基盤との連携であり連携方法にも色々なパターンがあるため、まずはパターンの全洗い出しを行い視覚的にみやすくまとめることにしました。また自分自身がOIDCや認証周りの知識を得るために休日をフルに使って関連書籍を読み漁りプロトタイプを作るなどして認識漏れによる遅延が出ないようにしました。まとめたことをドキュメントにし、チームメンバーが迷子にならないような工夫もしました。 #### 成果 上記の工夫のおかげか遅延をすることなく要件を満たす機能を作れました。また、認証機能自体の理解が深まったおかげでコード自体も綺麗に記述することができました。LINE認証についても不具合を一つも起こさずにリリースをすることができました。 ### Flutter開発のテックリード #### 課題 世の中の情報が少ない中で複雑なアプリの保守に耐えうるようなアーキテクチャを選定する必要がありました。 #### 工夫 新技術のFlutterといえども、中身は宣言的UIを基盤としたクライアントサイド開発なので、すでに濃い情報が出回っていたReactのアーキテクチャに関する記事や、iOSのSwiftUI、AndroidのJetpack Composeのアーキテクチャの記事を色々見て知見を集めたり、プロトタイプを作ってみて実際に肌感でメリットデメリットを体験するようにしました。 #### 成果 宣言的UIのメリットを多く受けれるMVVMの構成と複雑なビジネスロジックを吸収できるCleanArchitectureの構成に強いメリットを感じMVVM+CleanArchitectureの構成を採用しました。実際の開発でも途中で要件が変わることが数多くありましたが、レイヤードアーキテクチャを使用していたことにより、変更箇所を限定的にすることができたりなどかなり多くの恩恵を受けることができました。 # 代表的な施策 ### DevOpsの推進 #### 課題 protobufの成果物の手動更新に課題がありました。 サーバーとの通信プロトコルにgrpc+protobufを使用しており、当時はバックエンド側で生成したprotobufの成果物をコピペで クライアント側に移す運用をしていましたが、非効率的でミスが多発していたり、バックエンド側の変更にクライアント側が追随できずに開発生産性の低下が見られました。 #### 工夫 上記のことからproto定義とprotobufの更新の自動化が必要であると判断しました。複数リポジトリを跨いだ運用になるので、github actionのworkflow_dispatchを導入し、protoファイルに更新があったら自動で各リポジトリにprotobufの自動生成を含めたPRを作成するようにしました。DevOps系の知識があまりなかったのですが、持ち前のキャッチアップ力を活かしサンプルを自作するなどして実際の運用をシュミレーションするなどしました。 #### 成果 github actionの活用により、自動生成にうまく成功し、更新があるたびにPRを自動で作るようにしたことでprotobufの成果物の更新漏れがなくなりました。その結果、クライアント側でのAPIの繋ぎ込み作業もかなりスムーズになり全体の開発生産性の向上に努めることができました。 ### フロントエンド開発 納期がかなりギリギリだったということもありフロントエンド開発にも携わる必要が出てきました。フロントエンド開発は初めてでしたが、ネイティブ開発でサーバー間の通信や受け取ったデータの加工、保持などについては共通の考えがあるので最初からかなり高いレベルで貢献できていました。2ページ分の機能をまるまる実装し、フロントエンドの勘所を得ることができました。 ※新卒入社後はメディア事業部に配属となり、AbemaTVのiOSエンジニアとして就業していました。

# プロジェクトの詳細１ ## プロジェクト概要 新規事業サービスの立ち上げ ## チーム情報 ネイティブエンジニア(2人) バックエンドエンジニア(自分のみの1人) ## 使用技術 Ruby on Rails ## プロジェクトにおける自身の役割 - 要件定義 - DB設計 - API開発 - テスト - プロジェクトマネジメント 新規プロダクトに充てられる会社のリソースが限られており、バックエンドのエンジニアが自分のみであったため、バックエンドの全機能の設計や実装、他にはクライアントアプリを含めたプロジェクトマネジメントを行いました。 ### 課題 要件が不明確というのが大きな課題でした。このプロダクトによって、何をどこまで解決したいのかという目的が曖昧で要件もブレブレでした。テーブル設計やAP開発といったバックエンド開発も初めてであったので技術スキルの課題も自身にありました。 ### 工夫したこと 上記の課題の解決のために、まず自分が要件定義に参加することを決めました。そのために、東京の営業所に向かい、実際の従業員の方がやっている作業を体験させてもらうことでどこに課題があり解決できそうかということを肌で感じ、要件に落とし込むように工夫しました。 バックエンド開発についてはRailsのサンプルアプリを自身で作ってみたり、本番プロダクトのアーキテクチャに近づけてみることで勘所をなるべく早く掴むことにしました。まだDB設計については、書籍を読み漁ったり、CTOとの壁打ちをなるべく多くすることで完成度の高い設計を目指しました。また、一般論と並行して要件定義も自分が行ったことでドメイン知識を誰よりも深め、実際の設計に落とし込むようにもしました。 ### 成果 綺麗に正規化したテーブルを実装することができました。（null許容をなるべく無くし、アプリケーション側で余分なハンドリングを行わなくても済むような工夫もしました）またAPIの実装についても本体のプロダクトとの繋ぎ込みも工夫し実装し切ることができました。プロダクト自体については、実際の現場作業を体験した要件定義を行なったことで、現場との認識乖離を防ぐことに成功し、大変良かったという声をいただくことができました。 # プロジェクトの詳細２ ## プロジェクト概要 ジモティーiOSアプリの保守運用 ## 使用技術 Swift、RxSwift、Moya ## 自分の担当領域 iOSアプリ全体のアーキテクチャ設計 ## 課題 APIとの通信部分のコードが全て別々に書かれていてDRY原則から離れていた。そのせいでAPIの改修があった時にアプリ側の修正範囲も多くなっていた。 ## 工夫したこと 通信部分のコードをまとめるAPIClientを作成することで通信そのものの処理を共通化した。また大規模な改修になるためチームのリソースをヒアリングし、施策が中途半端にならないような工夫をした。他の人が置き換え作業をできるようにInterfaceは全く変えずに内部のみを変換するようにした。（元々がCleanArchitectureを採用していたので、Repositoryの中身を置き換えるだけで済みました。） ## 成果 [Moya](https://github.com/Moya/Moya)というライブラリを取り入れることでAPIの仕様をクライアント側で宣言的に記述できるようにし、見通しをよくすることに成功した。また、全APIの置き換えも他の方に引き継ぎ、２ヶ月程度で事故なくリプレイスすることに成功した。