ID:61647さん

[期間] 2021年2月 ～ 現在 ・リポジトリパターンの採用 　・理由: FatController・FatModel解消のため・テストを書きやすくするため ・Vue.js(Nuxt.js)の導入 　・理由: 負荷分散・SPA知見蓄積・UX向上・エンジニア採用強化 ・React.js(Next.js)の導入　 　・理由: UX向上・TypeScriptの相性・社内知見蓄積・外販準備 ・HerokuからAWS(ECS Fargate)に移行 　・理由: コスト削減・レスポンス速度改善・社内知見蓄積・エンジニア採用強化 ・Terraformの導入 　・理由: インフラ情報の可視化・社内知見蓄積・環境の再利用・エンジニア採用強化 ## 内容 主な理由としてはエンジニアの採用目的・外販準備となります。 絶対条件として、 - ビジネススピードに遅れないこと。 - 将来極力負債にさせないこと などを意識していますがそればかり優先してしまうと、 中長期的に見たときに技術的な選択肢が狭くなり 採用・競争力・品質などの点で大きく遅れてしまうと考えております。 したがって、個人・組織・ビジネスの３点のバランスを取りながら　　 業務に支障がでない範囲でできる限り新しい技術の導入を行ってエンジニアにとって魅力的な環境を作るように心がけてきました。 結果、開発の効率化、ユーザーの視点で見た場合のUX改善、少人数で仕事を回すために運用コストの削減、また外販に備えた知見蓄積にも繋がり 採用においては中小のユーザー企業という立ち位置の中、会社に興味を持っていただくことができ一名の採用をすることができました。

[期間] 2021年2月 ～ 現在 [メンバー] 4名: ディレクター1名・デザイナー1名・エンジニア2名 [役割] メンバー ・https://www.housebokan.co.jp/ ・上記サイトの表側・管理画面側の改善 ・Nuxt.jsで管理画面機能のSPA化 ・Next.jsで管理画面機能のSPA化 ・APIの作成 ## 内容 主に不動産システムの改修・機能追加を行いました。 不動産特有のバックオフィス業務効率化やサービスの品質向上が主な理由となります。 表側はユーザーが使いやすくするためにスマートフォン版対応地図検索機能、マンション情報詳細機能、物件ページにマップを表示する機能追加等を行い、 管理画面については、マンション情報管理機能や幼稚園・保育園情報管理、SalesForce連携、物件の写真枚数確認機能や現地でも効率的に登録できるよう写真登録SPAサービス等を作りました。 特に物件の写真枚数については物件情報の質を維持する意味ではとても重要な指標になるため、写真が登録されていない物件を洗い出すことができ、サイト全体の品質を上げることができました。 ## 技術面 潜在的な課題としては、DB設計上の問題で基幹データの取得に少し問題があったことやテストが実装されていなかったこと、責務の分離がされておらず拡張性・保守性に弱いアーキテクチャなどが挙げられます。 これらの課題は設計上の問題を緩和しつつ保守性を高めるためにロジックをService・Repository・Interface に移しデータベースアクセス層とロジック層をコントローラー・モデルから引き剥がしました。その上でテストを実装し、各層が明確な役割を持たせることでメンバーに左右されず保守しやすくなったことやビジネススピードに応えられる状態に近づいたと思います。 DDDなどの採用に関してはこの規模では真価を発揮できず負債になる可能性が高いのとフレームワークを移行する可能性が直近数年でほぼ見込めない、保守する人員を確保できないなどといった消極的な理由で採用していません。 また管理画面の一部機能に関しては当時、Herokuにある事が主な原因となりますがレスポンスがあまりよくないという話を受けていたのでUX改善という観点から一部機能を Nuxt.js + TypeScript で追加を行いました。 途中からNext.jsに置き換えている理由はVueとTypeScriptの相性の観点からです。 進行中ではありますが、将来的には管理画面の全機能をSPA化する予定なのでその際にNuxtで作られた機能についてもNext.jsに書き換える予定です。 ## 得られたこと 正規化が適切でないDB設計やアーキテクチャは、中長期的に見たときに負債になる可能性が非常に高いということと、かといって何でも分離することが必ずしも事業のフェーズに合うとは限らないので、そのバランスが事業を進める上で非常に重要だということを学びました。 他にもコメントや仕様書を残し理解を助けることは大きく開発速度に影響することも学び、これらは今後のプロダクトやチーム開発に生かしていきます。 またVueはフレームワーク的に原理をあまり意識しなくても使え、Reactは原理を知らないと使うことは難しいがあまりブラックボックスは少なくTypeScriptとの相性も良いという知見を得られたため、今後はプロダクトの性質によって合った方を選定するつもりです。

## 概要 [期間] 2021年8月 ～ 現在 [メンバー] 開発 4 2名: エンジニア 2 名・デザイナー１名/営業幹部/経営層 [役割] リーダー 不動産取引時に使用する契約・契約書情報を管理・出力するシステムの作成 ・契約情報保存機能 ・各種契約書出力機能(10+14 種類の書式) ### 課題 旧基幹システムに残ったままになっており、セキュリティ的にも運用上的にも大きな問題となっており、いつ停止してもおかしくない状況だったため、それらからの脱却・全面リニューアルを目的とした作業でした。 また当時目指していた外販商品として想定されていたため、それらを意識したUI/UX構造にするために独自ルールや説明書がなくても直感的に理解できるシステムを目指していました。 ### 内容 不動産取引時に使用する契約書の作成・記録・保存・検索ができるシステムです。 旧契約書システムを読み解き、マスト機能とそうでないものを切り分ける作業をディレクターを中心に行い、要件定義、設計からすべての工程を担当しました。 期間中、関係者達が退職されることになったので一旦外販方向をやめ、とにかく自社で使用できるものを最速で作る方向に変更し元々9ヶ月頂いていた納期の中約２ヶ月でコアとなるマスト機能を完成させる必要にななったため、知見の多いLaravel + Vueという選定に変更し常に先回りをして関係者を巻き込み集中的に開発を行いました。 ### 技術面の課題 出力する書類の種類が多いため分岐が発生しやすい環境になっており、それらを防ぐためのテーブル設計やフォーム設計、URI設計、他には専門用語を命名に落とし込む作業や和暦変換、誰もが使いやすくシンプルにすることなどの工夫が課題としてあげられます。 vueにおいては選択した内容に紐付いたデータを非同期的に取得し表示する処理や状態管理などユーザーがより使いやすくする機能を実装しました。 ### 得られたこと 項目精査の結果や運用ルールの見直しなどを通じて、半分以上の項目が不必要になったことやテーブル設計・フォーム設計を大きく変えたことで入力や管理がしやすくなっただけでなく、管理者のリーガルチェックが行いやすくなり品質が大きく向上したとユーザーから意見をいただくことができました。 技術的な面においては、URI設計を学ぶ機会になったことやDB設計を工夫することで不要な分岐などを減らしつつ高いメンテナンス性を実現できる一つのノウハウを習得できたこと。基幹システムで得られた知見を還元したことで、専門用語が飛び交うシステムの中、自分以外の人でもすぐに保守できる状態になったことなどが得られました。 不動産業界の外販戦略において、競争他社に対して自社の武器の一つになったので、今後は外部展開に挑戦できるよう技術的にも品質の高い状態を作り、よりユーザーにとって価値の高いサービスにしていくつもりです。 *不動産システムの構築・運用に該当しますが、システムの規模が他サービスとは違うため別に書かせてもらっています。

## 概要 [期間] 2021年5月 ～ 8月 [メンバー] ディレクター1名・エンジニア2名・デザイナー1名 [役割] メンバー 基幹システムをAPIとしたSPAサービスの作成 ・ハウスメーカー向け土地検索サービス(SPA) ・不動産仲介会社（他社）向け物件検索システム(SPA) #### ハウスメーカー向けシステム 現状ハウスメーカーと営業とのやり取りに課題が多かったことやハウスメーカーの殆どは自社内に不動産検索システムを持っていないので、土地情報を知りたい時は不動産会社に問合せをするしかないなどの問題を解決するために作成しました。 #### 他社向けシステム 他社不動産会社とのやりとりの際に電話やFAX・メールで行われておりインサイドセールスや営業に負担になるということや自社内で物件検索システムを持っている企業が少ないのでそれらの課題を解決するために作成しました。 ## 内容 共に基本的にはAPIから渡されるデータを整形・表示するRead案件がメインでした。 表示できる物件に条件があったり、運用ルールを決めることなどが主な課題でした。 戦略的な理由としては自社が不動産業界の中でもハウスメーカーとの取引において全国トップクラスの実績があり、それらの強みを生かし外販するためにも実装しました。 ## 技術面の課題 技術面の課題としては、社内にReact.js/Next.jsの知見がない状態からの作業でしたので特に認証周りなどの調査や適切なアーキテクチャ設計、知見還元に苦労しました。 調査においては、API 認証を行うには当然認証の仕組みを理解していないと試行錯誤もできないことや当時LaravelをAPIとした情報がほぼ転がっていなかったため苦労しました。 なので、試行錯誤や情報量の多いRailsの記事なども参考にしながら作業を進めました。他にも公式やGithub、界隈の著名人やカンファレンス動画などを通じてこれらの習得を行いました。 ### 得られたこと Next.jsやレンダリング・SPAなどフロントの知見を手に入れたことでそれらを踏まえた技術選定ができるようになったことや、JavaScriptの技術力が向上したこと、 あとは社内知見蓄積による開発速度向上や採用強化などにも繋がりました。 しかしReact.jsはAngularやVue.jsと違って人員の確保や品質が開発者によって左右されやすいことなどもあるので今後は費用対効果と保守性をよく考えたうえで選定していくつもりです。 現状まだまだ運用・展開中ではありますが、様々な知見が得られたので今後の外販戦略に生かしていくつもりです。

## 概要 [期間] 2021年4月 ～ [役割] メンバー 社内用のCMSを作成し、以下サイトを作成しました。 ・https://holidays-design.com/ ・https://recruit.sumarch.co.jp/ ・https://recruit.sumarch.co.jp/ (リニュアールも含む) ・APIとの連携 ・CMS7種類の保守・運用・機能追加 ## 課題 自社サイトの一部がWordpressで作られており、本体やプラグインの更新もほとんど行われておらずセキュリティ的にも危険な状態だったため知見のあるLaravelにすべて作り直しました。 上記サイトのHOLIDAYSに関しては初めてエンジニアとして作成したサービスであり、技術だけではなくエンジニアとしての能力を磨き成長するきっかけにもなりました。 ## 内容・得られたこと リニューアルをすることで以前は開発環境もなくDeployもすべてFTPでしたが、全てにおいて開発環境・CI/CD環境を準備し、迅速な回収作業を行えるようにしました。 リニューアルを行ったことでCVR率も向上し、集客にも大きな影響を与えました。 他にも機能を追加することでSNSを使用した広告の効果を上げることや事業間の繋がりも強化でき、集客やブランディングに影響を与えました。 また、CMS依頼が多かったので前もってテンプレートリポジトリを用意することで、チーム全体の開発速度向上に繋がり、品質も保たれました。

[期間] 2021年9月 ～ 現在 [メンバー] エンジニア 2名 [役割] リーダー ・基幹サービスのherokuからAWS移行(ECS Fargate) ・基幹システムに関連したサービスのherokuからAWS移行(ECS Fargate) ## 内容・課題 各種運用サービスをHerokuからAWSに移行しました。 元々Herokuで運用していましたが、年間運用コストが400万円以上かかっていることや海外リージョンにある関係から発生する問題などが潜在的にあり品質として安定していなかったこと、また代表の意向もありHerokuからAWS移行しました。 選定の理由としては、メンバーの数が少なくインフラを専門に作業できないことなどの課題もあったのでECS(Fargate)を採用しています。 またフロントエンドのデプロイにおいてはVercelなどの選択肢がありましたが、費用対効果の関係上Fargateで運用しています ## 技術的な課題 社内に最低限のリソースを使用しECSをpublicにおいて構成する知見はありましたが、 privateにECSを置く構成や、ALBの知見、Worker,バッチ処理,フロントエンドのコンテナ運用、定時処理、DB移行, KVS(Redis) の冗長化, DNS移行などの知見がなかったのでそれらを調査するところから始まりました。 ECSの基本構成についてはさほど手間がかからず実装できましたが、workerなどに関してはHerokuの環境を参考にしながら何度も仮説・検証を繰り返し、各種設定を行うことでそれらの構成を実現することができました。 それだけでなく、CloudFrontやAuroraの利用、SQS, Lambda, AWS Grafana などの検討なども行い、費用対効果が高いものに関しては実際に採用しました。 セキュリティやタスク数、チューニングに関しては 実際のセッション数やサービスの性質を踏まえた上でabコマンドなどを使用しで何度も検証することで最適化を図ることができました。 セキュリティに関してはWAF(v2)を導入することでDOS, DDOS などの攻撃から　サービスを守れるようにしました。 Terraform管理していたとのこともあり、ディレクトリ構成を見直しテスト環境にも対応できるようCI/CD ,Makefileやshellを利用しコマンドに応じて簡単にリソースを切り替えられるようにしました。 様々なディレクトリ構成がありますが、私達はmoduleごとに切り分け変数を受けとる・リソースを実行・変数を渡すの３つの責務を分離し構成しています。 結果、AWSの基本を理解していれば検索次第で対応できる状態に近づきました。 実際の移行作業に関しては、何度もデモを行い当日問題なく移行できるよう万全の準備をするだけでなく、あらゆる可能性を考慮することで当日スムーズに行うことができました。 ## 得られたこと 結果年間運用コストを200万円以上抑えることに成功しただけでなく、リージョン問題も解決でき、各種サイトのレスポンス等の品質が向上しサービス全体の品質が高まりました。 しかし、現状task-definitionにおいて環境変数の管理がGithub actionsを利用すると二重管理にならざる負えない問題などもあるので、メンバーと相談しながらチームにとっての最適解を目指していきたいと思います。

[期間] 2021年2月 ～ 現在 [メンバー] エンジニア 2名 [役割] メンバー ・テスト環境の作成 ・CI/CD環境の作成 ・開発基盤にテストsample実装とそれの転用 ## 概要 各種運用サービスにテストとCI/CD環境を導入しました。 Laravelのバージョンが5.8と少し古くなってしまっていたのですが、テストが一部レスポンスチェックのみされている状態でバージョンアップ作業で非常に困ったため各ページのレスポンステストから開始し、必要なところについてはUnitTestをEMと協力して書きました。またメインサービス以外の各種ブランドサイトについてもテストを導入しました。 他にも開発基盤を整えることで個人に左右されず安定した品質を作ることに繋がり、メンバー間で早く開発したいなら最低限のテストを書いて当たり前で動かないものはmergeしてはいけないという文化浸透にもつながったと思います。 ## 得られたこと 全てのサービスにおいてフレームワークのアップデートが完了し、現在はLaravel8.xで運用ができています。 サービスの規模が小さいがゆえにカバレッジ率60%程度でもアップデートできてしまったところがあるので、サービス規模が大きくなる前にさらにカバレッジ率を上げて品質を向上させる予定でいます。また最低限テストを書いたほうが結果的に開発速度と品質が向上するということも知見として得られたので今後の開発に生かしていくつもりです。 他にもE2Eテストなども実装も外販をする上では必要になってくると考えているので実装していきたいです。