ID:67939さん

# プロジェクト概要 ## 目的、背景 - 駐車場シェアリングサービスakippaの開発、運用保守 ## 期間 - 2016年10月〜現在 ## チーム構成 - 時期によるがバックエンドエンジニアは5名程度、アプリエンジニア1〜5名、デザイナー1〜3名、プロダクトマネージャ1〜3名、チームマネージャー1名程度で、現在は15名程度のチーム構成。 ## 担当した役割 - バックエンドのテックリードとして、PHP(Laravel、ZendFramework)を用いたバックエンド開発 - AWSで構成されるインフラ構築運用保守全般 - 他エンジニアへのオンボーディング、コードレビュー等 - 社内他部門からのプロダクトや技術に関する問い合わせ窓口等 - 社内エンジニアのMTGや勉強会等のファシリテータ # 実績 ## PHPのZendFrameworkからLaravelへのリニューアル - akippaでは、サービスローンチ当初より、ZendFrameworkでフロントサイトや管理サイトなどが構築されてきた。入社後、それらのサービスを全てフルスクラッチでLaravelで作り直すプロジェクトが開始されたが、想定より開発に長期間を要し、まだ黒字化していない状況でこれに社内開発全リソースを注ぎ込む状態を継続する事が難しいとなり、半年後に頓挫した。 - その後半年程経過した2017年後半より、1画面ずつ1機能ずつとリニューアルしていこうという動きを始めた。フロントサイトは同一サブドメイン下で新旧のフレームワークを混在させる事となるが、ALBのパスルーティングにより、開発が完了した画面から一つずつLaravelへ向けるような設定を施して、部分的なリニューアルを実現。管理サイトは、社内でしか使わない事もあり、サブドメインレベルで分けることとし、開発が完了した画面から旧の方を削除していくという方針で進行。 - 部分的に実施しており、現在も進行中。 ## AWS RDS MySQLからAurora MySQLへの移行の推進と実行 - テレビ放送が控えている等、一時的なスケールアウトなどの対応が必要な際に、通常のMySQLを使用している状況だと、リードレプリカの増台に併せて、Webアプリケーション側の設定ファイルの修正も必要であった。Auroraには、1つのリードエンドポイントで複数のリードレプリカに対して分散アクセスをしてくれるので、Webアプリケーションの修正の手間が削減される事や、カスタムエンドポイントという機能もあるので、複数あるリードレプリカの内、特定のインスタンスにはアクセスを向けないような事も可能で、分析用途に重たいSQLを叩く用のインスタンスと、プロダクトで参照させるインスタンスと異ならせる事が可能など、当時のマネージャにAuroraにするメリットの説明を行い、導入の許可を取り付けた。 - 当時はテストコード等がなかったため、実施すると決まってからは、外部のテスト会社に協力を依頼し、全機能テストのケース作成と実施をして頂いた。 - 本番の移行作業では、当時の社内では初めてのメンテナンスモード的な形でサービスを止めて移行を行ったが、このときの作業手順なども開発環境での事前検証など含め、全て自身にて作業を行った。バッチなどは全停止し、Webアプリケーションは、ALBのパスルーティングにて、全リクエストを静的なメンテナンスページのレスポンスを返すような設定を施すなど。結果、大きなトラブルがなく本番移行も完了し、その後もAuroraに変えたことに直接起因するトラブルもなく、無事成功した。 ## Laravelへクリーンアーキテクチャーの導入 - Laravel導入直後は、基本的にはLaravelのMVCに則りながら、細部に関しては各エンジニアが思いのままコーディングをしていた。 - それではよくないので、一部のエンジニアが用いていたRepositoryパターンを全員で使おうとか、FATコントローラ、FATモデルを少なくするためにServiceレイヤーを用意しよう、そして、テストコードはそこに書こうというルールを定めた。 - だが、Serviceレイヤーに関するルールが曖昧で、作り手により実装に違いが出たり、ビジネスロジックと技術詳細が密結合になりテスト書きにくくなり、結果、テストコードが後回しか用意せず放置状態となるケースが出始めた。 - また、コードレビューでも、何を以て正しいかが曖昧となり、レビューが荒れる場合も出てきてしまった。 - そこで、PHP業界では著名な方の[Laravelのコアレイヤーパターンに関する記事](https://blog.shin1x1.com/entry/independent-core-layer-pattern)をほぼそのまま参考にして、Laravelにクリーンアーキテクチャー、軽量DDDのようなアーキテクチャーを導入した。 - これにより、多少のバラツキはあるものの、各エンジニアが同じようなコードを書けるようになったり、コードレビューもしやすくなり、ビジネスロジックと技術詳細が疎結合になりテストコードも書きやすくなるなど、非常に恩恵を得られていると感じている。詳細は以下記事参照。 - https://note.com/akippa_murakami/n/n8996c751db84 ## ローカル開発環境のDocker化 - 入社当初、akippaでの各個人の開発環境は、EC2に用意した個人用環境とそれに個人用サブドメインを割り当ててWebの開発を行なっていた。Laravelへのリニューアルの際は、自身にてVagrantとVirtual Boxを用いたローカル環境を用意した。ただ時が経つにつれて、Macのバージョン等の違いからか、新しくエンジニアが参画された際のローカル開発環境の構築に失敗するという事態が頻出するようになった。 - akippaでは、複数サブドメインで複数サービスを動かしていて、フロントサイトについては同一サブドメインで新旧フレームワークが共存している状態なのだが、これをほぼそのまま再現する状態のdocker-composeを作成した。詳細は以下記事に記載。 - https://note.com/akippa_murakami/n/nf0bf182c7345 ## ステージング環境用のDB構築 - ステージング環境のテスト用DBを、本番環境のDBを定期的にコピーして、個人情報などはマスクしてほぼ本番同等でテストできるような環境を、JenkinsとAWS CLI等を用いて構築した。これにより、リリース前のパフォーマンスの確認や、実際のユーザー様から問い合わせがあった不具合の再現などが容易となった。 ## その他様々な機能の開発 - これまでに記載した内容とは別に、日々、新機能の開発や既存機能の保守に多く携わった。 - Pdmや他部門が企画するものを開発する場合でも、その時点では曖昧な要件である事が多いので、要件定義的な段階から携わる事が多い。 - ユーザーに近いフロント側はPdmなど企画の方が企画する事が多いが、例えば消費増税があった際や、DBのEOLが到達するなどで、システムの裏側の改修を行う際には、開発業務だけでなく、方針の叩き作成や各部署への説明なども担当した。 ## リリース作業担当 - 本番リリース作業の半自動化(Jenkins等を用いてビルドスクリプトを実行)の構築など。 - 大幅なデータのマイグレーションが必要な場合、1〜3時間程度の深夜メンテナンス計画と実施を担当。(過去5回程度) ## コードレビュー担当 - 他エンジニアやデザイナーのコードレビューも担当。例えばインデントやPSR-2に則っているかなどの細かい事は指摘せず、ツールによる自動コメントやコードフォーマッタによる修正がなされた方がよいと考えているので、自身のレビュー観点は、後で何かあったときに、自分でも修正できそうか？という点でレビューをする事が多い。 ## エンジニア採用担当 - この会社で初めてエンジニア採用に携わる経験をした。書類選考、カジュアル面談、一次面接までを担当。 - 自分自身が採用担当となった当初、自身含めチームが採用に不慣れで、当初は、明確に不可な理由がなければ合格…というスタンスで臨んでいた。その後、スキル面だけでなく仕事や相手に対する姿勢などで衝突する事もあり、チームビルディングに悪影響を及ぼすという時期を生じさせてしまった。 - 現在は、スキルチェックも重視するが、それよりも会社で定めているミッション、ビジョン、バリューに共感していただけそうな方かどうか、という点も重視するようになっている。 ## その他エピソード - 自身が入社して1年後ぐらいに、当時のマネージャーと、唯一インフラを担当していた先輩社員等が一気に辞める事となり、社員エンジニアとしては自分しか残らないという状況となった。それを退職3週間ぐらい前に聞かされ、自身の進退も考えたものの、これをある意味、当時ほぼ0だったAWS含めたインフラスキルを身につけるチャンスを捉え、社に残る事を決意し、それから5年以上、社のインフラをほぼ一人で死守してきた。このような貴重な経験をさせていただき、とても運が良いと思っている。

# プロジェクト概要 ## 目的、背景 - 自社サービスと受託開発を並行していた会社にて、受託開発として様々なWebサイト開発 - 自社サービスが売上を出していない状況だったので、運転資金の確保のために受託開発を行なっていた - 所属会社がWeb開発の際に採用しているフレームワークであるCakePHPを用いて開発を行なっていた ## 期間 - 2014年1月〜2016年10月の2年10ヶ月程 - 上記の間ずっと携わっていたではなく、自社サービス開発や受託案件の状況によりアサイン ## チーム構成、担当した役割 - バックエンドエンジニア3名(自分含めて) - チームリーダー - お客様との打ち合わせ担当 # 実績 ## 在庫管理用Webサイト開発 - ブランド品等の中古品の買取、販売を行うユーザ様向けの在庫管理用Webサイトの開発 - サイトの概要としては、会員、商品の登録、ブランド等のマスタ情報の登録、編集、商品のバーコード出力などの機能を有する - 設計、実装、テストを担当し、CakePHPにて開発を行った ## スマホ向けソーシャルゲーム開発 - クエスト、ユーザバトル、ガチャ、カードボックス、課金アイテム購入など、一般的なソーシャルゲームの機能を備えたカードゲーム風のソーシャルゲーム開発 - フロントはUnityにて、バックエンドのAPIはCakePHPにて開発を行った - 要件分析、技術調査、設計、実装、テスト、アプリケーション公開の手続きまでを担当 ## 介護系コンテンツサイト、求人サイト開発 - サイトの概要としては、介護の現場で用いられるレクリエーション素材(塗り絵等)やネタの登録やダウンロードが行えたり、介護系の求人の管理(企業側からの求人情報登録、求職者からの求人応募、サイト運営側からのそれらの管理)が行える機能を有する - 設計、実装、テストを担当し、CakePHPにて開発を行った ## 墓地霊園検索サイト開発 - 不動産検索サイトの墓地霊園版 - サイトの概要としては、現在地、都道府県や永代使用料等から墓地霊園を検索し、資料請求が行える機能であったり、システム管理者による墓地霊園情報の登録、更新等のデータメンテナンス機能を有する - 設計、実装、テストを担当し、本案件では、BaserCMSというCMSをベースにして開発を行った(BaserCMSは、CakePHPフレームワークを用いて開発されたCMS) ## 某自治体向け保育士求人サイト開発 - 某県向けの保育士求人サイト開発。 - サイトの概要としては、一般の求職者側から保育園等の施設を検索、求人応募する機能、施設側が自身の施設の住所や求人情報を掲載する機能、システム管理者による求人応募の状況確認やデータメンテナンス機能を有する - 設計、実装、テストを担当し、CakePHPにて開発を行った