ID:61647さん

ゴール：納期までに開発を達成する 役割: メンバー 担当: 設計・開発・テスト DB: PostgreSQL 使用技術：Python, FastAPI, SQL Alchemy /React, TypeScript , MUI, /Google Cloud(Cloud Run、Cloud Build等)/ OpenAPI アーキ： DDD/Atomic Design プロジェクトの応援として参画することになった。 ベースとなる技術選定やマスタなどの部分の実装は既に行われており、主にフロントエンド側で全般を見つつバックエンド側も担当し技術負債を返却しながらリリースまで品質と速度を出すことが求められた。 課題としては、特にフロントエンド側の設計実装ともに治安が良くない状態だったのと、バックエンドにおいても即席の実装を重ねた結果バグが発生しやすい状態だったこと、N+1問題などが発生していたこと。スキーマ定義をコードとして残していなかったこと また開発体制もかなり属人性の高い状態だったことが課題として挙げられる。 具体的には、componentの抽象化がほとんどされていない状態だったり、Container/Presentationalパターン が意識されていないかつAtomic Designになっていなかったので修正する時のコストがかなり跳ね上がっていたこと、endpointやrouter、schmeを集約、活用できていなかったこと、TypeScriptの恩恵を得られる実装ではなかったこと、デザインの観点からも位置ずれや親要素のデザインが別のコンポーネントにある影響でどの要素がどれにかかっているのかすぐにわからなかったり、UXの部分でも無駄なレンダリングや副作用の理解が足りなく画面にちらつきがあったりなどが挙げられる。 それらの負債を解消して、チームメンバーにもフロント側のルールや知見を還元した。 バックエンドに関しては、 設計・実装の相談・レビューを行い、フロントに関わる部分のAPIの作成・既存の修正などを行なった。 当時参画した時にI/Fが明確になっていなかったこともあり既存の設計・実装を読みときそれらをフロント側に反映させた。またそれだとI/Fが明示されておらず変更に弱いのでFastAPIからOpenAPIのスキーマを生成しフロントエンドとバックエンドの型定義を共通利用するようにした。 認証や検索処理、データの整合性の設計、アプリのcrudなどの実装を行った。 またModel、データ基盤の部分も実装も一部担当した。

ゴール：Vertical SaaS としてスタートを成功させる 役割: メンバー 担当: 設計, 開発 DB: PostgreSQL 言語: Deno, TypeScript, deno-postgres / React, TypeScript, Redux, Danfo.js / GCP , Firebase / OpenAPI アーキ：軽量DDD / Atomic Design, CSS Modules プロトタイプ開発によりある程度仮説を固めた上で、各社から契約が進められることになり本格的な開発がスタートした。 担当領域はフロントエンドは全般、バックエンドは設計・アプリケーションロジック全般の実装を担当し、BIZ含め４名で開発を進めることになった。 課題は、プロダクト開発の進め方に大きな課題があった。 元々はプロダクト開発として進める予定で進められていたが、11月後半になり別の受託プロジェクトの開発費を削減するためにこのプロダクトの資産を利用することになり、その契約に合わせ要件の見直しが入り、一部仕様変更が行われたり、またその契約状況をヒヤリングしながら進むことになった。 製造業・卸業どちらに舵を切るか、というフェーズでの開発でもあったのでプロダクトの方針が社内の事情に揺らぎながらの開発になった。 その上で技術的な課題は、1. 別プロジェクトにforkすることを踏まえて開発する 2. 仕様変更に強くする 2.どこまで譲れるか密にコミュニケーションを取る 4 優先順位を都度整理する などのことが挙げられる。 バックエンド技術選定の背景は、 フロントエンドとの親和性が高いこと、型を利用することで開発速度を向上し変更にも強くできること、フロントエンドとの親和性からTypeScriptを選択。 ランタイム環境についてNode.jsとDenoの選択において議論があったがフィジビリした結果、Node.jsをDenoより採用したい理由が「既存資産に乗っかりたい」以外なかったのと、Denoはnpmをサポートしていたり、標準ライブラリが充実していたことから必要としている機能を十分に満たしていたためDenoを選択した。 開発中もDenoの標準ライブラリを使用することでシンプルかつ安定して開発をすることができた。 実際の開発においては、仕様変更が来たときにすぐ対応することや事業部のジャッジによってプロダクトが右往左往されるのがとても大変だった。 これらに関しては、常に優先順位を意識し実装上は責務やアーキ、抽象化・依存関係を意識することで対応した。 ビジネス上の課題は受託プロジェクトの関係者やリーダー層とコミュニケーションをしっかり取ることで極力後戻りが発生しないよう心がけ、実際効果を得られた。 しかし2022年12月末、バックエンドの全体設計・一部実装が終わった段階で経営の方針上プロダクト開発は一旦停止することになった。 とても悔しい経験だったが、プロダクト開発においてどのように進めれば角度が上げられるのか、何を意識して開発することが大事なのか、どのようなチームがいいのか、どういう顧客に当てていくのか、撤退ラインはどうするかなど様々なことを学べ貴重な体験だった。

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

ゴール：クイックな開発を行い仮説検証を行う 役割: メンバー 担当: 設計, 開発, テスト 言語: React, TypeScript, Danfo.js / CGP, Firebase アーキ：Atomic Design, CSS Modules 仮説がある程度溜まった状態でスタート。 要件はBIZの方が決めていただき設計・実装はエンジニアである私が担当した。 選定背景は、同じ事業部でReactが使用されており親和性が高く第三者の参入コストが低いこと、新しいversion・適切な責務で書き換え新しいデファクトにして組織に残したかったこと、組織単位でコンポーネントの再利用性を高めたかったことが挙げられる。 実装する上での技術課題は、 1. とにかく早く作ること、2. データの永続化の必要はなし、3. 日付関係を意識した複雑な計算(PSI計算)をする必要がある、4 仕様が変動する など挙げられる。 1と2を達成するためにバックエンドを作らずフロントエンドのみのアプリケーションとして作成した。 3に関しては、配列で日付を扱うこともできたがよりシンプルに複雑な表の関係を解消するためにデータフレームを使用して計算シミュレータを作成した。(pandasリスペクトのdanfo.jsを使用) 4 に関してはUIの切り替えをできるような形でcomponentを実装し、抽象に依存する形で対応をした。 csvアップロードしたデータをブラウザで保持し取り回すこと、その値を適切に管理すること、仕様変更に強いアーキにすることが大変だった。 結果、クイックな開発に繋がり潜在顧客からのFBを得ることができ次のプロジェクトにつなげることができた。

[期間] 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を利用すると二重管理にならざる負えない問題などもあるので、メンバーと相談しながらチームにとっての最適解を目指していきたいと思います。