Saas管理機能付きIdaas
メタップスクラウドの開発
サービス説明
企業が導入しているSaasの利用コスト、利用頻度などを可視化し管理する事が可能なIdaas
概要
サービスローンチ前の0->1フェーズに参画しアーキテクチャや技術選定など技術的な意思決定全般を行いました。 </br> 最終的には以下の規模まで成長しましたが初期開発スピードを損ねることなく継続的な価値提供を維持する事ができました。
- 連携外部サービス数500
- APIが400程度
- DBのテーブル数120程度
- LineofCodeが165,000程度
- TestCoverageが全ファイル対象で80%以上
詳細
プロトタイプからローンチ、グロースを行い、事業計画に合わせ将来を見据えた技術的負債と機能開発、運用コストなど技術戦略のコントロールに努めました。 </br>
</br> プロダクトの中長期的な成長、開発生産性を重要視し、技術選定は現場のチームのスキルセットに合わせて技術選定するのではなく、解決する課題や将来を見据えた技術選定を行う方針にしていました。 </br> そのため、チームのスキルが未熟な技術の選定をする際には勉強会開催の実施、デザインドキュメントの運用、メンバー個別の理解度に合わせて丁寧にレビューや共有の時間を取るなどカバーを行い、選定した技術がチーム全体の生産性を得るような仕組み作りまで行うことで短期的な成果と長期的な成果両方を担保することができたと感じています。 </br> </br> インフラ、バックエンド、フロントエンド、ネイティブアプリ、Chrome拡張機能どプロダクトに関わるサービス全体を管掌し、システムアーキテクチャ、技術選定、品質担保やオペレーションをフルスタックエンジニアとして自ら手を動かしながら行いました。 </br> 合わせて、Figmaを使いUIデザインの作成やコンポーネントの整理などデザイナーと協業しながらUI/UX設計も行いました。
具体例
- formatter、linter、testツール、dockerなど開発環境の構築と運用
- 秘匿情報の管理やDB、アプリケーションの設定
- 2FA/token認証など認証機能の設計・開発
- 階層構造やロールベースのアクセス制御など複雑な機能を含むテーブル設計
- Railsアプリケーションのレイヤー分け方針決め
- OpenAPIを使ったスキーマ駆動開発の導入
- フロントエンドのReact移行の戦略決めと推進
- 監視、運用設計
- 開発フロー、CI/CDの設計
- サーバーレスアーキテクチャーとPythonを採用したwebスクレイピング基盤開発
- サーバーレスアーキテクチャーとgoを採用した非同期基盤開発
- chrome extensionの開発
- Flutterでのネイティブアプリ開発
- GraphQLサーバーの検証と基盤構築
- rails/React/MUIなど各種ライブラリバージョンアップ
- サービス開発および運用に関わる設計、ソースコードレビュー
アーキテクチャ
モノリスrailsを中心にwebスクレイピング基盤など特殊な機能はマイクロサービスとして切り離したCitadel Architecture構成です。
</br>
具体的なサービスアーキテクチャは以下のように分離していました。
- railsアプリケーション
- 管理者向け設定画面
- IdaaSポータル画面
- webAPI
- フロントエンドアプリケーション
- webスクレイピング基盤
- ID連携基盤
- 通知基盤
- chrome extension
- ネイティブアプリケーション
システムの複雑性やUX向上のために、railsアプリケーションにはレイヤードアーキテクチャを採用しています。
技術スタックの詳細はこちら
期間毎の実績
~ サービスローンチ
役割: フルスタックエンジニア・システム面全般でのリード
プロトタイプでのrailsアプリケーションが存在している状態だったのでインフラからフロントエンドまで全てのレイヤーで商用運用するために必要なタスクを洗い出しおよび対応を行いました。 </br> また、ローンチまでに必要な機能開発の推進と同時に、バグの多さや開発スピードの遅さを解消するために今後の開発方針や戦略策定も行いました。
技術戦略
- フロントエンドの実装ガイドラインと方針定義
- SPAへのリプレイスの判断と計画
- リリースフロー/開発フロー定義
- アプリケーションアーキテクチャのTobe定義
- テストコードでのQA方針定義
- 参画時にテストコードカバレッジが20%程度かつ、テストコードの内容もテストできているとは言えないものが多く、ほとんどテストがない状態だったため、テストコードの方針と戦略を策定
アーキテクチャ
- ユーザ情報テーブルの再設計
- OTPを使った2FA機能の実装
- RDBでの階層構造のテーブル設計
- 外部API利用する機能のアーキテクチャ
- サーバーレスアーキテクチャーを採用したwebスクレイピング基盤
- フロントエンド技術スタックの選定と開発環境基盤構築
セキュリティ
- 秘匿情報の整理と管理方法の選定
- DBカラム暗号化
- DBのインスタンスタイプや各種設定の最適化
運用、監視
- ログ収集、検索基盤
- 監査ログ
- アプリケーションログ
- 監視
QA
- rspec動作環境の整備
- Simplecov導入
- saml連携部分など重要機能のテストコード追加
- coverage 0 -> 100
その他
サービスローンチ -
役割: フルスタックエンジニア・システム面全般でのリード
サービスロンチ後は、継続的な機能開発の生産性を維持するための技術導入やチーム全体のケイパビリティ向上、難易度が高い機能開発、マイクロサービスの切り出しなどの全体アーキテクチャへの最適化を行いました。
開発方針
- 切り出したマイクロサービス間でAPI通信が発生するためOpenApi3.0の採用
- railsアプリでは’committee’, ‘committee-rails’でAPI定義と実装の整合性を担保
アプリケーション開発
- formbase認証を実現するchrome extensionの設計/構築
- フロントエンドをReactへリプレイス
- 技術選定/開発基盤の構築/コンポーネント設計/知見共有
- UIデザイナーがデザインモックを描き、各エンジニアがそれを実装する開発方法でしたが、フロントエンドリプレイスのタイミングでデザインのコンポーネント/システム化、部分的にはリデザインをUIデザイナーと協業して行いました。
- モーダルダイアログは重要な変更を行うときに使用する。
- ボタンの色はOOのケースはOOを使うなどのガイドライン策定
- inputは選択肢の数によってスイッチ/トグル/プルダウンを使い分けるガイドライン
- Railsエンジニアで構成されたチームだったので勉強会を行いCSS/React/TS/コンポーネント設計/ステート管理とデータフロー/アーキテクチャ/デザインシステムなどフロントエンド全般の共有を行いました。
- バックエンドのAPI接続部分はopenapi generateでの自動生成を活用しました。
- schema駆動開発
- OpenAPI 3.0を使いschema駆動開発行いました。バックエンドのAPIはcommitteeを使用してIFの担保とフロントエンドはAPI呼び出しとDTOをopenapi generateで自動生成することで開発生産性を向上しました。
- goを採用したID連携基盤の構築
- goを採用した通知基盤の構築
- ネイティブアプリ開発