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
200
クライアントワークと管理画面の話
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
300
次世代ヘッドレス開発室が提供するヘッドレスEC
texdeath
0
630
中期プロジェクトで e2eテストを導入してみて感じたこと
texdeath
2
7.7k
おさらいVue Composition API
texdeath
0
440
React使いがVueと仲良くなるためにやったこと
texdeath
0
280
Optional Chainingについて
texdeath
3
170
副業として個人事業主をやる場合の メリット・デメリット
texdeath
0
110
Container Componentは必要なのか
texdeath
4
620
Kotlin/JSでReactアプリを作ってみた
texdeath
1
910
Other Decks in Technology
See All in Technology
3月のAWSアップデートを5分間でざっくりと!
kubomasataka
0
120
4/16/25 - SFJug - Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
2
120
コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた #jawsug_tokyo
non97
0
420
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
490
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
690
QA/SDETの現在と、これからの挑戦
imtnd
0
140
サーバレス、コンテナ、データベース特化型機能をご紹介。CloudWatch をもっと使いこなそう!
o11yfes2023
0
180
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
120
Amazon CloudWatch Application Signals ではじめるバーンレートアラーム / Burn rate alarm with Amazon CloudWatch Application Signals
ymotongpoo
5
530
30代からでも遅くない! 内製開発の世界に飛び込み、最前線で戦うLLMアプリ開発エンジニアになろう
minorun365
PRO
11
3.2k
白金鉱業Meetup_Vol.18_AIエージェント時代のUI/UX設計
brainpadpr
1
150
Porting PicoRuby to Another Microcontroller: ESP32
yuuu
4
440
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
183
22k
We Have a Design System, Now What?
morganepeng
52
7.5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.4k
Building Flexible Design Systems
yeseniaperezcruz
329
38k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
9
760
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Fireside Chat
paigeccino
37
3.4k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.4k
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