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
170
クライアントワークと管理画面の話
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
270
次世代ヘッドレス開発室が提供するヘッドレスEC
texdeath
0
610
中期プロジェクトで e2eテストを導入してみて感じたこと
texdeath
2
7.6k
おさらいVue Composition API
texdeath
0
420
React使いがVueと仲良くなるためにやったこと
texdeath
0
270
Optional Chainingについて
texdeath
3
160
副業として個人事業主をやる場合の メリット・デメリット
texdeath
0
100
Container Componentは必要なのか
texdeath
4
610
Kotlin/JSでReactアプリを作ってみた
texdeath
1
890
Other Decks in Technology
See All in Technology
2024年活動報告会(人材育成推進WG・ビジネスサブWG) / 20250114-OIDF-J-EduWG-BizSWG
oidfj
0
230
2024AWSで個人的にアツかったアップデート
nagisa53
1
110
Amazon Q Developerで.NET Frameworkプロジェクトをモダナイズしてみた
kenichirokimura
1
200
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
3
2.1k
Reactフレームワークプロダクトを モバイルアプリにして、もっと便利に。 ユーザに価値を届けよう。/React Framework with Capacitor
rdlabo
0
130
三菱電機で社内コミュニティを立ち上げた話
kurebayashi
1
360
re:Invent2024 KeynoteのAmazon Q Developer考察
yusukeshimizu
1
150
embedパッケージを深掘りする / Deep Dive into embed Package in Go
task4233
1
210
AIアプリケーション開発でAzure AI Searchを使いこなすためには
isidaitc
0
110
dbtを中心にして組織のアジリティとガバナンスのトレードオンを考えてみた
gappy50
0
270
生成AI × 旅行 LLMを活用した旅行プラン生成・チャットボット
kominet_ava
0
160
なぜfreeeはハブ・アンド・スポーク型の データメッシュアーキテクチャにチャレンジするのか?
shinichiro_joya
2
480
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
44
13k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Being A Developer After 40
akosma
89
590k
Mobile First: as difficult as doing things right
swwweet
222
9k
RailsConf 2023
tenderlove
29
970
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
4 Signs Your Business is Dying
shpigford
182
22k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
The Cult of Friendly URLs
andyhume
78
6.1k
Speed Design
sergeychernyshev
25
740
Visualization
eitanlees
146
15k
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