クライアントワークと管理画面の話

自己紹介
 森田　勝駿（@texdeath） AI事業本部 DX本部 アプリ運用センター フロントエンドエンジニア ● 2021/08 ~ 中途入社 ● 業務はクライアントワーク中心 ● 技術選定・設計・実装 ● 要件定義・チームマネジメントなども担当

今やっていること ● アプリ運用センターでフロントエンドのテックリード ○ 案件を横断したフロントエンドの品質管理 ● いろんなプロジェクトの管理画面開発 ● いくつかのプロジェクトのフロントチームマネジメント ● ほか、採用や新卒育成など

Agenda ● クライアントワークと管理画面 ● 使用した技術の話 ● 開発で工夫したところ ● プロジェクトでつらいところ ○ どんな対策をとっているか

クライアントワークで管理画面？ ● 管理画面と聞くと自社開発におけるシステムの運用などに使用する イメージが強い ● あとはFirebaseとかGCPのコンソールのイメージ

クライアントワークで管理画面？ ● クライアントワークにおいても、アプリやWebサイトだけでなく管 理画面を同時開発する案件はよくある ○ たとえば顧客管理システムも一緒にリニューアルしたいとか ○ リニューアルに伴って取り扱っている機能の仕様も変わるから 合わせて一新したいとか

選定した技術 ● React ● Recoil ● TypeScript ● grpc-web / connect-web ● Nx ○ リリースするものが多かったので、monorepo構成にしたかった

Nxとは ● モノレポ管理ツールの一種 ● Webフロントエンドのサービスを 一つのリポジトリに集約 ● ビルドやテスト環境なんかもいい 感じにセットアップしてくれる

Recoilを採用した理由 ● 状態管理はしたかった ● 管理画面でグローバルな状態管理をすると往々にして複雑化した 経験があった ● 参画するプロジェクトメンバーが多く、スキルもまちまちだった ので、ある程度とっつきやすいライブラリを選びたかった ● 複雑になりがちな管理画面の概念をなるべく平易化したい ● Familyの概念を上手く使えばエンティティの共通化も容易かと 思った

connect ● gRPC 互換の HTTP API を構築するためのライブラリ ● バックエンドが grpc を採用していた ● 当初はgrpc-web＋envoy を使用する予定だった ● 2022年の8月にES版も本格利用できそうだったので、使用してみた ● コンパクトで取り回ししやすく、TSの型保管も効いて便利

Recoilと通信層のつなぎこみ ● 結構設計に苦労した ● メンバーの提案もあり、Custom Hooksをドメイン単位で呼び出し、grpc 通信とRecoilのstate更新をひとまとめにした ● 実装メンバーが通信プロトコルの違いを意識しなくていいように配慮

Recoilと通信層のつなぎこみ

Protoファイルからの型ファイル生成 ● grpcの型定義元になるProtoファイ ルはバックエンド側のリポジトリに 置いてあった ● 二重管理はしたくなかった ○ バックエンド側のリポジトリを 見にいき、自動で型定義ファイ ルをgenerateする仕組みを作 成 ● バックエンドのリポジトリに更新が あればPull Requestを出す

ディレクトリ・コンポーネント設計方針 ● フィーチャー駆動パターンもどきを採用 ○ 機能単位でディレクトリ設計 ○ 基本設計を理解していれば、構築の際に迷うことがないのがいい ○ 運用時も改修しやすい ● Atomic Designなど、いろいろコンポーネント設計のデザインパターンは あるが、現実的に運用が難しいと判断した ○ 管理画面は基本的にエンジニアのみで作ることが多い ○ エンジニアだけでは「このコンポーネントはどの分類に属するの か？」などを判断するのは難しい ○ エンジニアと連携して動いてくれるデザイナーがいれば話は別

工夫したところ（開発） ● 開発人数が多かったので、先に方針を決めておいた ○ ドキュメントやCI/CDの整備、リリースフローの簡略化、チケットの 切り方、など ○ ドメインに紐づくビジネスロジックをほぼすべてドキュメント化し、 オンボーディング時に展開 ○ チームの中で役割を分け、それぞれにサブリーダーをつけた ■ ビジネスロジックを実装するチーム ■ リファクタリングを行うチーム ■ 動作確認をメインで行うチーム（単体テスト実装含） ● それでも全体的にテスト不足が目立ったので、現在E2Eテストの導入中

そのほか（開発） ● なるべく自動化/簡略化して、ヒューマンエラーや取りこぼしを防ぐ ● RELEASE NOTEを残すようにした

つらいところ（全体） ● 変わりゆく要件定義（要件定義とは・・・） ● 大半は考慮不足だったりする ● クライアントワークだと担当者が変わると方針も変わったりする ● これまでOKだったものが急にNGになったり、急に仕様追加されたり

どうしているか ● 工数と工期を同時に出さない ○ 工数は見積もりできても、工期はプロジェクトの色々な都合がからん でくる ○ 工数バッファ＋工期バッファを加味したスケジュールにする ○ どんなにブロックしても、差し込みタスクはある

どうしているか ● メンバーにお願いするタスクは概要から細部まで丁寧に記載 ○ 「このファイルのここを変更するといいと思います」くらいまで ○ メンバーとの意思疎通の齟齬を限りなくなくしつつ、無駄なミーティング を減らす

まとめ ● クライアントワークでも管理画面は作ることが多い ● 花形にはなれないが、管理画面は大事なもの。 ● それだけに、要件定義や基本設計はしっかり行ったほうがいいです ● 大規模なメンバーの開発になってきた場合は、自分自身が実装することも 減ってきます。適切なドメイン知識をメンバーにつけてもらうことが大事 ● 「できると思います」は自分の首を絞めます（n敗）

EOF