Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クライアントワークと管理画面の話
Search
texdeath
May 01, 2023
Technology
0
230
クライアントワークと管理画面の話
texdeath
May 01, 2023
Tweet
Share
More Decks by texdeath
See All by texdeath
コードメトリクス計測による課題可視化と品質確保 / Visualize issues and ensure quality by measuring code metrics
texdeath
0
340
次世代ヘッドレス開発室が提供するヘッドレスEC
texdeath
0
640
中期プロジェクトで e2eテストを導入してみて感じたこと
texdeath
2
7.8k
おさらいVue Composition API
texdeath
0
460
React使いがVueと仲良くなるためにやったこと
texdeath
0
290
Optional Chainingについて
texdeath
3
180
副業として個人事業主をやる場合の メリット・デメリット
texdeath
0
110
Container Componentは必要なのか
texdeath
4
640
Kotlin/JSでReactアプリを作ってみた
texdeath
1
920
Other Decks in Technology
See All in Technology
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
1
180
DeNA での思い出 / Memories at DeNA
orgachem
PRO
3
1.6k
Goss: New Production-Ready Go Binding for Faiss #coefl_go_jp
bengo4com
0
1.1k
ソフトウェア エンジニアとしての 姿勢と心構え
recruitengineers
PRO
2
670
R-SCoRe: Revisiting Scene Coordinate Regression for Robust Large-Scale Visual Localization
takmin
0
430
「守る」から「進化させる」セキュリティへ ~AWS re:Inforce 2025参加報告~ / AWS re:Inforce 2025 Participation Report
yuj1osm
1
120
キャリアを支え組織力を高める「多層型ふりかえり」 / 20250821 Kazuki Mori
shift_evolve
PRO
2
300
マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ
grimoh
1
200
浸透しなさいRFC 5322&7208
hinono
0
120
[OCI Skill Mapping] AWSユーザーのためのOCI(2025年8月20日開催)
oracle4engineer
PRO
2
140
EKS Pod Identity における推移的な session tags
z63d
1
200
帳票Vibe Coding
terurou
0
140
Featured
See All Featured
Writing Fast Ruby
sferik
628
62k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building Adaptive Systems
keathley
43
2.7k
The Language of Interfaces
destraynor
160
25k
What's in a price? How to price your products and services
michaelherold
246
12k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Into the Great Unknown - MozCon
thekraken
40
2k
Visualization
eitanlees
147
16k
The Invisible Side of Design
smashingmag
301
51k
Transcript
クライアントワークと管理画面の話
自己紹介 森田 勝駿(@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