ID:79069さん

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

# プロジェクト概要 内製開発チームが発足したものの、運用面の課題や技術的負債ごと引き継いでいたため、それらの改善を行いました。 # プロジェクト体制 当時の私はメイン機能を開発するチームのリーダーを務めておりました。チーム内で完結する内容については、私の手動で行いました。 また、負債解消に取り組む専任チームも存在し、時には彼らと協力しつつ課題の解消に取り組みました。 # 実施内容 ## エンジニアによる手動データ書き換えの撲滅 外注開発時代は、PdMの依頼の元エンジニアが本番DBに入ってUpdateを行う運用が常態化していました。目の前は楽かもしれないですが、定期的に工数を奪う上、オペレーションミスによる誤った更新も時折発生していたため、このような作業を1つ1つ潰していきました。PdMに上記のようなデメリットを説明したうえで、作業内容の機能化・バッチ化等を行ったり、バグの根本対応を行ったりすることで、本番DBに入って作業する機会のほとんどを削減することが出来ました。 ## 不要コードの削除 引き継いだコードベースには、すでに使っていない機能に関するコードが残っていました（残り方は様々で、関数1つ消し忘れているものから、ルーティングだけ削除してあとは丸々残っているものまでありました）。元々モノリスなので改修影響範囲の調査に気を遣うのですが、不要コードが残っていると調査対象に入ってきてしまいさらに工数がかかるので、これらを削除する取り組みを始めました。明らかにコード上到達できないものは、エンジニアがチケット化し余裕のある時に削除作業を行いました。また、実装したが実は現場でもう使われていない機能についても、これまでは放置されていたようですが、PdMにそういった情報の提供をお願いし、削除までを行うことが出来るように仕組みを整えていきました。 ## ユニットテストの整備 引き継いだコードベースにはテストコードが一切存在せず、改修の影響の検知が手動QAに頼りきりになっていました。その状態を改善するため、ユニットテストを整備していくことが決まりました。基盤の構築は負債解消チームが行い、私の役目は自チームのメンバーが開発とセットでユニットテストを書く状態を作ることでした。 - ユニットテストポリシードキュメントの展開 - ユニットテスト部分のコードレビュー - PdMとの調整（目先の工数が増えることになりますが、意義を説明し理解を得られるよう努めました） といった活動を行い、ユニットテストの拡充に尽力しました。 ## 監視の導入 運用を引き取るにあたり、監視ツールとして新たにNew Relicを導入しました。導入されたNew Relicを活用し、以下のような活動に取り組みました。 ### アラートの導入・調整 障害によるユーザーに影響が広がる前に検知できるよう、アラートの導入を行いました。アラートは導入して終わりではなく、そのアラートが来た際の影響や対応内容を検証し、サービス影響が小さいアラートについては閾値を緩めたり、アラートのレベルを下げたりといった調整を継続して行いました。 ### 定点観測 アラートを待たずにサービス改善の手を打てるように、定点観測会を開催しました。その際、メモリ使用率やエラーレートといった観測に必要なパラメータを集めたダッシュボードを用意して観測しやすくしました。発見された課題は各チーム持ち帰って調査・改善を行いました。

## プロジェクト概要 求人作成サービスの持続的成長を目指したモジュラモノリス構成へのリプレイスに伴うバックエンド設計と実装を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、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と繰り返し要件のすり合わせを行い、審査基準における「条件分岐」「判定結果」の認識を統一し、意思決定経緯を詳細にドキュメント化しました。 - 数種類の審査フローに対してクラス分け、メソッド分けを適切に行い、凝集度が高いコードとなるように努めました。 - 単体テストを充実させ、仕様変更時のリグレッション防止に努めました。 - プロジェクトマネージャーとして、チームメンバーの技術的課題の解決をサポートし、スムーズな開発推進に寄与しました。 ## 成果・価値 - それまで人力で行っていた企業アカウント審査業務をシステム化し、審査工数の大幅削減を実現しました。 - 審査機能の導入により、悪用リスクの低減とサービスの信頼性向上に貢献しました。