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
180
クライアントワークと管理画面の話
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
290
次世代ヘッドレス開発室が提供するヘッドレスEC
texdeath
0
620
中期プロジェクトで e2eテストを導入してみて感じたこと
texdeath
2
7.7k
おさらいVue Composition API
texdeath
0
420
React使いがVueと仲良くなるためにやったこと
texdeath
0
280
Optional Chainingについて
texdeath
3
170
副業として個人事業主をやる場合の メリット・デメリット
texdeath
0
100
Container Componentは必要なのか
texdeath
4
610
Kotlin/JSでReactアプリを作ってみた
texdeath
1
890
Other Decks in Technology
See All in Technology
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
190
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
600
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
160
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
180
Ruby on Railsで持続可能な開発を行うために取り組んでいること
am1157154
3
150
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
11
3.8k
短縮URLをお手軽に導入しよう
nakasho
0
150
日経のデータベース事業とElasticsearch
hinatades
PRO
0
230
OPENLOGI Company Profile for engineer
hr01
1
20k
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
170
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
700
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
280
Featured
See All Featured
Speed Design
sergeychernyshev
27
810
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A designer walks into a library…
pauljervisheath
205
24k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Adopting Sorbet at Scale
ufuk
74
9.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Rails Girls Zürich Keynote
gr2m
94
13k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
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