ID:79069さん

## プロジェクト概要 外注していた求人制作Webサービスの開発を内製化し、アジャイル開発により開発スピード向上を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、PHP（Laravel, CodeIgniter）およびjQueryを用いたWebサービスの設計・コーディングを担当し、SQL Serverを利用したデータベース設計・運用にも従事しました。 - フロントエンドの実装にも携わり、スクラムチームの一員として設計から運用・保守まで一貫して担当しました。 - 当初はメンバーとしてプロジェクトに参画し、途中からはチームリーダーとしてメンバーの支援・タスク管理等を行いました。 - ベンダー側の開発チームと密に連携しながら、知識共有やレビューを推進し、内製化を支援しました。 ### チーム規模と構成 - PdM1名、エンジニア4名の内製化チームで構成され、ベンダー側の開発チームと連携しながら二つのチーム体制で開発を進めました。 ## 背景・課題 - 外注で開発していた求人制作サービスの開発を内製化し、高速かつ柔軟な対応を目指してプロジェクトが立ち上がりました。 - 内製化初期段階では、社内にドメイン知識や既存コードベースの理解が十分に浸透しておらず、開発効率の低下や品質維持が課題でした。 - 内製化に伴う知識ギャップが社内に存在し、ベンダー依存から脱却するための技術的・業務的ノウハウの蓄積が急務とされました。 ## 実際の取り組み ### 開発環境 - PHPのLaravelを中心にバックエンドを構築し、jQueryを用いたフロントエンド実装を行いました。 - SQL Serverをデータベースとして利用し、AWS EC2上でサービスをホスティングしました。 ### 改善内容 - 社内のドメイン知識不足を補うため、ベンダー側の有識者に積極的に質問やコードレビューを依頼し、知見を吸収しました。 - 得た知識は自らレビュワーとしてチーム内に展開し、特に重要な内容についてはドキュメント化して共有基盤を整備しました。 - アジャイル開発（スクラム）を推進し、開発案件ごとに画面表示、ビジネスロジック、DB定義変更などを一貫して対応する体制を構築しました。 ## 成果・価値 - 社内に開発ノウハウが蓄積され、最終的にベンダーに依存せずにビジネス要求を遂行可能な内製チームを確立しました。 - 内製化完遂に伴い、コミュニケーションが社内で完結する体制となり、開発の迅速化と柔軟性が大幅に向上しました。 - アジャイル開発の導入が定着し、開発スピードの継続的な向上に貢献しました。 - 後に内製開発チームが拡大していく際にも、ここで吸収した知識を新メンバーに展開することでスムースなオンボーディングに貢献しました。

# プロジェクト概要 内製開発チームが発足し、社内での開発がスタートしました。 ビジネス価値を届けるための開発を行う傍ら、運用面の課題や技術的負債ごとベンダーから引き継いでいたため、それらの改善を行いました。 # プロジェクト体制 当時の私はメイン機能を開発するチームのエンジニアリーダーを務めておりました。 時期によって入れ替わりはありつつ、大体の期間でPdMが1 - 2名、エンジニアが5 - 7名、デザイナーが1名のチームでした。 チーム内で完結する内容については、私の主導で行いました。 また、負債解消に取り組む専任チームも存在し、時には彼らと協力しつつ課題の解消に取り組みました。 # 開発の実施内容 エンジニアのリーダーとして、新規機能・機能改修の設計を主導しました。 既存プロダクトの構成をドラスティックに変更するようなことは出来ない制約（これは主に割けるリソースの問題と、モノリスの一部だけ異なる設計思想を導入すると却って新規参入者を戸惑わせてしまう、との判断によるものです）の中で、既存の問題点を踏襲しないような作りを心掛けました。 特に単一責任の原則について考える機会が多かったです。私は既存コードがDRYを強く適用しすぎていたと考えており、単に見かけの処理内容が同一かどうかではなく知識の同一性を意識した設計になるように注意を払いました。 # 運用改善の実施内容 ## エンジニアによる手動データ書き換えの撲滅 外注開発時代は、PdMの依頼の元エンジニアが本番DBに入ってUpdateを行う運用が常態化していました。目の前は楽かもしれないですが、定期的に工数を奪う上、オペレーションミスによる誤った更新も時折発生していたため、このような作業を1つ1つ潰していきました。PdMに上記のようなデメリットを説明したうえで、作業内容の機能化・バッチ化等を行ったり、バグの根本対応を行ったりすることで、本番DBに入って作業する機会のほとんどを削減することが出来ました。 ## 不要コードの削除 引き継いだコードベースには、すでに使っていない機能に関するコードが残っていました（残り方は様々で、関数1つ消し忘れているものから、ルーティングだけ削除してあとは丸々残っているものまでありました）。元々モノリスなので改修影響範囲の調査に気を遣うのですが、不要コードが残っていると調査対象に入ってきてしまいさらに工数がかかるので、これらを削除する取り組みを始めました。明らかにコード上到達できないものは、エンジニアがチケット化し余裕のある時に削除作業を行いました。また、実装したが実は現場でもう使われていない機能についても、PdMにそういった情報の提供をお願いし、削除までを行うことが出来るように仕組みを整えていきました。 ## ユニットテストの整備 引き継いだコードベースにはテストコードが一切存在せず、改修の影響の検知が手動QAに頼りきりになっていました。その状態を改善するため、ユニットテストを整備していくことが決まりました。基盤の構築は負債解消チームが行い、私の役目は自チームのメンバーが開発とセットでユニットテストを書く状態を作ることでした。 - ユニットテストポリシードキュメントの展開 - ユニットテスト部分のコードレビュー - PdMとの調整（目先の工数が増えることになりますが、意義を説明し理解を得られるよう努めました） といった活動を行い、ユニットテストの拡充に尽力しました。 ## 監視の導入 運用を引き取るにあたり、監視ツールとして新たにNew Relicを導入しました。導入されたNew Relicを活用し、以下のような活動に取り組みました。 ### アラートの導入・調整 障害によるユーザーに影響が広がる前に検知できるよう、アラートの導入を行いました。アラートは導入して終わりではなく、そのアラートが来た際の影響や対応内容を検証し、サービス影響が小さいアラートについては閾値を緩めたり、アラートのレベルを下げたりといった調整を継続して行いました。 ### 障害の対応 New Relicを活用した障害対応についても、オンコール当番であるか否かに関わらず積極的に参加しました。 ・Redisへの大容量SETの是正と、再発防止のためのロギング、アラートの追加 ・リードレプリカを適切に使用できていない個所の特定・修正対応 ・大量アクセス等システムの安定性を阻害するIPの特定と、AWS WAFでのブロック対応 ### 定点観測 アラートを待たずにサービス改善の手を打てるように、定点観測会を開催しました。その際、メモリ使用率やエラーレートといった観測に必要なパラメータを集めたダッシュボードを用意して観測しやすくしました。発見された課題は各チーム持ち帰って調査・改善を行いました。

## プロジェクト概要 求人作成サービスの持続的成長を目指したモジュラモノリス構成へのリプレイスに伴うバックエンド設計と実装を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、PHP/Laravelを用いたAPI群の設計と実装を担当しました。 - イベントストーミングを主導し、ドメイン駆動設計（DDD）を活用したアーキテクチャ設計に深く関与しました。 - リプレイスに伴うモジュラモノリス構成の設計改善に貢献し、サービス理解の最も深いエンジニアとしてチームを牽引しました。 ### チーム規模と構成 - バックエンドエンジニア6名、フロントエンドエンジニア3名､プロダクトマネージャ1名の計10名体制でスクラム開発を採用したチームでした。 ## 背景・課題 - 求人作成サービスの内製化にはいったん成功したものの、レガシーな作りの改善が大きな課題となっていました。また、企業が使う部分のシステムは完全内製化出来たものの、ユーザーが使う部分のシステムは未だ外注に頼っており、コードベースこそ分かれているもののドメインの結合度が高く、会社をまたいだ連携が度々必要な状況になっていました。 - 中期経営計画に基づき、既存求人作成サービスの持続的な成長と保守性向上のため、コンテキスト境界を策定したモジュラモノリス構成へのリプレイスが企画されました。 ## 実際の取り組み ### 開発環境 - PHP/Laravelを用いたバックエンド開発をメインとし、DDDとオニオンアーキテクチャを組み合わせた設計を取り入れました。 - イベントストーミングを用いてドメインの理解を深め、モジュラモノリス構成の設計に反映しました。 ### 設計・改善内容 - まず初めに、イベントストーミングを実施し、求人作成サービスのイベントを洗い出し、仮のコンテキスト境界を策定しました。その際、エンジニア内で最もサービス理解の深い立場から、イベントストーミングのファシリテーションを行い、チーム全体のドメイン理解度向上に寄与しました。 - コンテキスト境界の策定後、ビジネス側とのすり合わせを行い、ビジネス要件の優先度に合わせて少しずつ新モジュールへの移行を行うことになりました。 - API設計においてはRESTfulな設計方針を徹底し、開発者間での共通認識を図るためにドキュメント整備を推進しました。 - 内部の設計については、オニオンアーキテクチャを採用しました。DDDの戦術的設計を取り入れるにあたって、導入しやすさとレイヤー分けによる整理効果のバランスが良いと考えたからです。組織内でのDDDによる実装事例はあまり無かった中で、チームで議論を行いながらその後の模範となるAPI実装を行うことが出来ました。 - 元のプロダクトにはテストコードの実装が一部分しか出来ておらず、そもそもテスタブルではない関数が多々あり導入を妨げていたのですが、この機会にユニットテストの整備を徹底しました。 ### その他アピールポイント - リプレイスプロジェクトは一時凍結となったものの、採用したDDDやモジュラモノリス構成の技術的な手法は他プロジェクトへの横展開が進んでおり、組織全体の技術力向上に貢献しています。 ## 成果・価値 - 社長交代による中期経営計画の見直しによりプロジェクトは一部凍結されたものの、モジュラモノリス構成やDDDの導入の経験・ノウハウを活かすべく、他プロジェクトでの活用が進んでいます。 - 設計段階での深いドメイン理解とイベントストーミングの実施により、今後の開発効率改善に向けた基盤が構築されました。

## プロジェクト概要 採用ページ作成サービスに企業アカウント審査機能を追加し、悪用防止と業務効率化を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - エンジニアチームリーダーとして、開発実務に加えメンバーのタスク管理とスプリント調整を担当しました。 - PdMと仕様の細部にわたるすり合わせを行い、複雑な審査要件の設計と意思決定経緯のドキュメント化を推進しました。 - フロントエンド・バックエンド双方の実装に携わり、PHP/LaravelとjQueryを用いた機能開発を担当しました。 ### チーム規模と構成 - PdM1名、デザイナー1名、エンジニア3名の合計5名体制で、スクラム開発手法を用いて機能開発を進めました。 - エンジニアチーム内では技術的な知見共有とレビューを重視し、品質担保に努めました。 ## 背景・課題 - 採用ページ作成サービスにおける悪用防止のため、企業アカウントの妥当性検証機能が必要となりました。 - 既存の認証プロセスとの整合性確保と、審査は厳密にしたい/離脱は最小化したいという相反する要求が仕様の複雑化を招きました。 ## 実際の取り組み ### 開発環境 - PHP/Laravelを用いたバックエンド開発とjQueryによるフロントエンド機能実装を行い、単体テストにはPHPUnitを活用しました。 - スクラム開発手法に基づき、短期間のスプリントを繰り返しながら継続的に機能を改善しました。 ### 設計・改善内容 - PdMと繰り返し要件のすり合わせを行い、審査基準における「条件分岐」「判定結果」の認識を統一し、意思決定経緯を詳細にドキュメント化しました。 - 数種類の審査フローに対してクラス分け、メソッド分けを適切に行い、凝集度が高いコードとなるように努めました。 - 単体テストを充実させ、仕様変更時のリグレッション防止に努めました。 - プロジェクトマネージャーとして、チームメンバーの技術的課題の解決をサポートし、スムーズな開発推進に寄与しました。 ## 成果・価値 - それまで人力で行っていた企業アカウント審査業務をシステム化し、審査工数の大幅削減を実現しました。 - 審査機能の導入により、悪用リスクの低減とサービスの信頼性向上に貢献しました。

## 課題 請求データの処理を行うバッチ処理が、件数の増加とともに数時間という処理時間になってしまい、後続の請求作業に影響が出ていました。レガシーなコードかつ請求というミスの許されない領域ということでリスクはありましたが、短縮を行うという意思決定をしました。 ## 役割 現状の調査や対応方針の策定を私が主導し、実際の改修についてはメンバーエンジニア1人と協力して行いました。 ## 対応 技術的な対応と、要件の見直しによる処理の削減の両面から対応を行いました。 ### 技術的な対応 複数の処理から成り立つバッチについて、処理時間の計測によってボトルネック部分を特定し、その部分を重点的に調査しました。APIコール回数の削減や、計算量への考慮が不足した処理（ループ内で配列のmap処理をしている、等）を発見し、それらの解消を行いました。 ### 要件見直し 数年間手つかずの処理だったため、そもそも現在は役に立たない処理を行っているのでは？という疑いを持ちました。そのため、まずは処理内容とそれによって作られるデータをつぶさに洗い出し、PdMに対して説明を行いました。その情報をもとに、請求データを業務に使用する担当者と話し合い、本当に必要な処理がどれなのかを特定し、それ以外の処理を削除しました。 ## 結果 最も長いときで10時間以上かかっていた処理、3分程度に短縮され、業務の円滑化に貢献しました。

## プロジェクト概要 求職者と企業が連絡を取り合うメッセージ機能に、ファイルを添付する機能を追加したい、というビジネス要望がありました。その機会に、メッセージの機能を対象として、リアーキテクチャを実施したのが本プロジェクトです。 ## 役割 バックエンドエンジニア4名のチームで、リーダーを務めました。 技術的な意思決定に責任を持ちつつ、API呼び出し先となる各チームとの連携を行いました。 ## リアーキテクチャについて 対象プロダクトは、過去の経緯によって「求職者側」と「企業側」に分割されており、別のリポジトリ・別の会社で開発を行っていました。しかし、メッセージのような機能は双方に同様の機能が求められるにもかかわらず、それぞれの会社で別々に開発を行わなければならない状態となっていました。今回のファイル添付についても、画面の導線やファイル管理の仕組み等を別々に作成するのは不適切であると考え、メッセージ機能を双方から呼び出されるAPIとして切り出したうえで、ファイル添付機能を追加する、という決定をしました。 ## ファイル管理の機能について ユーザーがある程度自由にファイルをアップロードできる機能の実現のため、セキュリティには注意して実装を行いました。 - アップロード/ダウンロードはS3の署名付きURL機能を用いて、フロントエンドから直接S3にファイルを配置することで、危険なファイルがバックエンドサーバーに混入しない仕組みにしました。 - AWS GuradDutyの機能を用いて、S3にアップロードされたファイルのウィルスチェックを行いました。 ## その他苦労したこと - 求職者側（別会社で開発）システムのフロントエンドとのAPI連携の事例は初であり、認証の仕組みの構築に苦労しました。 - API呼び出し側のシステムは比較的レガシーなコードで開発に時間がかかっていたため、知識面・リソース面でのサポートを行いリリースの早期化に貢献しました。 ## 成果 顧客企業の要望が高く、また競合プロダクトの多くが備えていた機能であり、いわゆる「当たり前品質」の実現が出来ました。 月に約1万ファイルほどがこの機能を使用してやり取りされているとのことで、使い勝手の向上に大きく貢献できたと考えています。