SaaS.tech#5 （https://saas-tech.connpass.com/event/256288/）で発表したスライドです。 ※記事中に表示されている「視認性を意識したデザインシステムのアップデート」は下記URLで公開しています。 https://note.com/tadaki/n/n14d1f97a3243

1. 業務システム開発でデザインとフロントエンドも妥
協しない話
2022/08/10 SaaS.tech #5
アルプ株式会社 mura- @mura_cx

2. © Alp, Inc.
村濱 一樹（むらはま かずき） mura-
● NTT系列のネットワーク会社に新卒入社
● 地元沖縄にもどりWeb系プログラマとな
り、徐々にフロントエンド開発を中心に
していく。2015年にフリーランスとし
て独立。
● 2019年にアルプ株式会社に入社。主に
フロントエンドの開発を担当し、現在は
エンジニアリングマネージャーとして開
発マネジメントや採用活動にも従事
自己紹介

3. © Alp, Inc.
● 対象者、見ていただきたい方
● デザイナーやフロントエンドエンジニア
● toBのシステムにおけるデザインとフロントエンド開発のアプローチの一例を知りたい方
● POやPdMなどプロダクト戦略に興味がある方 など
● 話す内容
● サービス・会社紹介
● デザインの話
● 業務システムにおけるデザインへの考え方
● 今までのデザインの変遷やアルプにおけるデザインへのアプローチ など
● 開発の話
● どのように実装しているか
● デザイナとのコラボレーション など
● 今後の課題とまとめ
本日話すこと

4. サービス・会社紹介

5. 会社概要
社名
アルプ株式会社
設立
2018年8月21日
資本金
1億円
拠点
東京都港区新橋2-20-15
新橋駅前ビル1号館7階
代表
伊藤 浩樹
従業員数
47名（2022年8月1日現在）
資金調達額
19億円
株主
経営陣, グロービス・キャピタル・
パートナーズ, DNX Ventures, ANRI,
PKSHA SPARX アルゴリズムファン
ド, GMO VenturePartners, 電通ベ
ンチャーズ, 個人投資家

8. デザインの話

9. © Alp, Inc.
デザインの話
AlpではScalebaseのデザインに明確に投資している
1. 操作感が軽快で、テンションが上がるデザイン
● 業務システムは、プライベートで使うWebサービス以上に長い時間使うことになる
ケースが多く、デザインによって生産性に違いがでる
● 逆に使うのが億劫になるようなシステムはたしかに存在し、海外の先行サービスの利
用者にインタビューをしても、出てくる不満は広義のデザインに関する内容が非常に
多かった
2. 複雑なドメインへの認知コストを下げる
● ただでさえ複雑なドメインの業務システムであり、会社によって使う使わないのパ
ターンも千差万別
3. 知覚品質を上げること（狭義のデザイン）が、全体の品質を高めるベースとなる
アルプにおける業務システムへのデザインの考え方

10. © Alp, Inc.

11. © Alp, Inc.
様々な検討を経て
β版のデザインが完成

12. © Alp, Inc.

13. © Alp, Inc.

14. © Alp, Inc.

15. © Alp, Inc.
デザインの話
● 最初のデザインはオレンジ基調だったが、ブランディングの検討などにより色を見直し
● 青(紫寄り)になったのは、サービスカラーを考えようとなったときに、サービスの理
想のイメージを上げていったときに「冷静」や「堅実」のようなワードが挙がってそ
れを体現していった。
● ドメインが成熟していくにつれデモに利用していたβ版から構成などを大きく見直し
正式リリースまでの道のり

16. © Alp, Inc.
2019年10月、本番リリース
（デザイン Version 1）

17. © Alp, Inc.

18. © Alp, Inc.
デザインの話
● V1の主な問題点
1. Component単位での細かい仕様が曖昧だった
● ボタンの大きさの種類があるが、どれを選択するべきか
● フォームの幅をどう設定すればいいか など
2. サービスが成長するにつれ、想定より表示したい情報密度が高くなってきた
● セクショニングのルールやパーツの大きさ・マージンが合わなくなるなどV1の設
計ではうまく情報を表現できなくなってきた
3. 情報密度が高いがゆえの視認性をあげなけれならなかった
● 参考: 視認性を意識したデザインシステムのアップデート
よりサービス・ドメインが進化することで、V1ではデザインとして不足がでてきた

19. © Alp, Inc.
新規機能追加しながらも、
徐々に新しいデザインへ移行
（デザイン Version 2）

20. © Alp, Inc.

21. © Alp, Inc.
さらに理想を求め、
デザイン原則の確立へ

22. © Alp, Inc.
Design Systemとデザイン原則
デザイン原則はDesign Systemの土台です。
Design SystemにあるUIコンポーネントやライティ
ングもデザイン原則のもとに成り立っています。
Design Systemとデザイン原則
22
デザインの話

23. © Alp, Inc.
デザイン原則が必要な3つの理由
Scalebaseのあり方を共有する
😣 経営陣の思いがデザインに反映されていない
😣 「Scalebaseらしさ」とはどういうことか定まっていない
チーム全員の「よいデザイン」の認識を揃える
😣 メンバー共通の大事にする軸が定まっていない
世界観を統一する
😣 個人の好み・感覚に頼ってしまっている
デザイン原則が必要な3つの理由
23
デザインの話

24. © Alp, Inc.
デザインシステム「TORCH」の3原則
🔭 FORESIGHT
👫 TOGETHERNESS
🏛 STABILITY
デザインシステム「TORCH」の3原則
24
デザインの話

25. © Alp, Inc.
デザインシステム「TORCH」の3原則
👀 見通しよく /☀明快に / 🙌 ポジティブに
ゴールを喚起させ、入り口からゴールまで不安なく進めるようにしよう。
Points
● 現状を一目で把握できるような俯瞰性
● 情報への簡易なアクセス性
● 補完やサジェストなどを使って入力を支援
FORESIGHT 🔭
デザインの話

26. © Alp, Inc.
デザインシステム「TORCH」の3原則
💖 心を折らない / 🚩共感し導こう / 🤝 親近感
突き放さず、否定せず、温かみを持って振る舞い、心を折らないようにしよう。
Points
● 文字だけに頼らず、アイコンや絵文字、画像などを用い効果的に簡潔に
● 否定しない。エラーでは解決策を提示
● 人間味ある柔らかい言い回しを。時には会話的に
TOGETHERNESS 👫
デザインの話

27. © Alp, Inc.
デザインシステム「TORCH」の3原則
🧘基本に忠実に / 🎮コントローラブルに / 🚄レスポンスは素早
く
基本を忠実にデザインし、かつ操作の実感を損なわないようにしよう。
Points
● デファクトスタンダードなUIを採用、奇抜なデザインを回避
● 安心感を与えるコントロール性の高いUIシステム
● アクションの結果をタイムリーに正しく提示
STABILITY 🏛
デザインの話

28. © Alp, Inc.
3原則を取り入れてHOMEをリデザイン
デザインの話

29. © Alp, Inc.
3原則を取り入れてHOMEをリデザイン
デザインの話

30. © Alp, Inc.
3原則を取り入れてHOMEをリデザイン
デザインの話

31. © Alp, Inc. 31

32. © Alp, Inc.

33. 開発の話（フロントエンド）

34. © Alp, Inc.
● React
● TypeScript
● CSS in JS（Emotion）
● AtomicDesign（ちょっと崩している）
● Storybook
● VRT
開発の話
現時点で採用しているフロントエンド技術スタック

35. © Alp, Inc.
開発の話
1. StorybookやVRTを駆使して、デザイナもある程度なら安心して修正などができるように
2. デザイン原則やデザインシステムによって、今後はそれにをもとに、デザイナーやエンジ
ニアがコミュニケーション取りやすくなるようになる
● 大事なところにフォーカスできる
3. デザイナーが確認しやすい状況を作っている
● PR単位でStorybookを確認できる、
PRに画像やBefore/Afterを貼るなど
4. デザイナー自身もコードに介入する文化がある
デザイナーとのコラボレーション
FE・デザイナでペアプロ中

36. © Alp, Inc.
開発の話
デザインに関わることは、PRにデザイナーがチェック
デザイナからのフィードバック

37. © Alp, Inc.
開発の話
Github ActionsでPR単位でStorybookがDeployされる
CIでStorybookをDeploy

38. © Alp, Inc.
開発の話
PR単位でVRTによる差分チェック
CIでVRTによるチェック

39. © Alp, Inc.

40. © Alp, Inc.
開発の話
● フロントエンドの実装としては、なるべく多くの箇所をDependency Injectionできるよ
うにしている
● 小さいパーツだけでなく、Storybookにある程度の塊を表現できる
● 当初MSW+Storybookを使っていたが、通信をMockする必要もなくなる
● どの部分で通信を行うか、など設計には注意を払っている
テスタビリティや開発体験向上のために依存性注入（Dependency Injection）をする

41. © Alp, Inc.
開発の話
ReactのContext経由でDIを実現している
どうDIをしているか
export const EditStaffDIContext = createContext<Dependencies>({
updateCustomerStaff: buildDummyUpdateCustomerStaff(),
});
export const useEditStaffDIContext = () => useContext(EditStaffDIContext);

42. © Alp, Inc.
開発の話
● 現状の構成
● Atoms(原子)
● Molecules(分子)
● Organisms(生体)
● Templete（テンプレート）（厳密には実体はないが、概念として似たようなものがある）
● Pages(ページ)
● PagesでDIしている＝Pages単位でStorybookへ載せることも可能
● TemplatesもVRT対象
DIとStorybookの関係性

43. © Alp, Inc.
開発の話
model-domainとmodel-ui
● フロントエンドでもドメイン（model-domain / model-ui）を持つようにし、サーバーサ
イドにある情報やドメインとはあえて分けてかんがえている。
● FEはFEで必要なUX上の情報などが必要なため。
● サーバーから取得したデータは、フロントのドメインに加工し、保持する。
● APIスキーマ（Protobuf）で表現できないことを表現する
フロントエンドでもドメイン情報をもつ

44. © Alp, Inc.
開発の話
model-domainのコード例。ここでは、フロントエンドが持つべき銀行口座オブジェクトの型を定義している。
サーバーサイドから降りてくるデータの形を考慮せず、フロントの都合で作る。サーバーサイドの型が変わっても影響が少ない。
フロントエンドでもドメイン情報をもつ
export type BankAccount = {
bankName: string;
branchName: string;
branchNumber: string;
accountType: AccountType;
accountNumber: string;
accountName: string;
recipientName: string;
};
export type AccountType = 'NONE' | 'SAVING' | 'CHECKING';
export type BankAccount = {
bankName: string;
branchName: string;
branchNumber: string;
accountType: AccountType;
accountNumber: string;
accountName: string;
recipientName: string;
}
export enum AccountType {
BANK_ACCOUNT_TYPE_NONE = 0,
BANK_ACCOUNT_TYPE_SAVING = 1,
BANK_ACCOUNT_TYPE_CHECKING = 2
}
バックエンドの型 フロントエンドの型
「バックエンドはenumだが、フロントではUnion型にした方が扱いやす
い」と、ここでは判断している（コード赤枠部分）

45. © Alp, Inc.
開発の話
model-uiのコード例。ここでは、データの日付による検索のOptionにつかわれるラベルなどを定義している。
フロントエンドでもドメイン情報をもつ
export const dateFilterConditionOperators = [
'である', 'ではない', 'より前', 'より後', 'の範囲内'
] as const;
export type DateFilterConditionOperator =
typeof dateFilterConditionOperators[number];
export type DateRangeFilter = {
beginDate: Date | null;
endDate: Date | null;
operator: 'の範囲内';
};
export type DateMatchFilter = {
targetDate: Date | null;
operator: Exclude<DateFilterConditionOperator, 'の範囲内'>;
};
// 日付での絞り込み状態を表す型
export type DateFilter = DateRangeFilter | DateMatchFilter;

46. © Alp, Inc.
開発の話
model-domainとmodel-uiに変換する仕組み
サーバーサイドでAPIの型は定義されているが、それをフロントのモデルに合わせて変換する
Protobuf（Protocol Buffer、スキーマ言語）を使ってサーバーサイドでAPIの型を定義しており
フロントエンドではそれをTypeScriptに変換して利用している。
● Mapper
● model-domain（フロントの型）とProtobuf（サーバーの型）のマッピングを定義。
● Assembler
● Mapperを使って、model-domainをProtobufに変換、もしくはその逆を行う。
● Adapter
● 実際にサーバーと通信し、Assemblerを使って変換を行う。
※変換のテストももちろん書く。
フロントエンドでもドメイン情報をもつ

47. © Alp, Inc.
開発の話
model-domainとmodel-uiに変換する仕組み（イメージ図）
フロントエンドでもドメイン情報をもつ
画面 API
Assembler
Mapper
(toProtobuf)
Adapter
Mapper
(fromProtobuf)
フロント用データ
( model-domain
/ model-ui )
バックエンド用データ
( protobuf )
※場合によっては複数
のAPIから組み立てられ
るデータもある
UI組み立て

48. 今後の課題とまとめ

49. © Alp, Inc.
まとめ
1. デザインシステムや「TORCH」はまだまだこれから。やるべきことがたくさんある。
2. フロントエンドでモデルを作れてない、DIできてない箇所などがある。
3. エンジニアがコンポーネントの組み立てなど、デザインをできる範囲を増やし、開発のイ
テレーションを素早く回せるようにする
● デザイナー：デザイン原則やデザインシステムなどデザインの根幹を担当。
● エンジニア：それを使ってどうユーザーに価値を届けれるかを考え、実装。
4. デザイン原則・デザインシステムはComponent単位では定義をすすめているが、操作体
験をパターン化できていない。
今後の課題

50. © Alp, Inc.
● デザイン
1. 業務システムであっても、意志をもってデザインに投資している
2. デザインはドメインやサービスの進化に合わせてバージョンアップしている
3. デザイン原則・デザインシステムを策定しUI/UXをよりよくするための言語化を行っている
● 開発
1. デザイナーとコラボレーションをしやすい体制を作っている
2. VRT/Storybook等のツールを使いCIを回し、Componentの変化などを視認できるように
3. フロントにもモデルを定義し、バックエンドの都合によらないUXを実現しようとしている
4. DIでテスタビリティや開発体験を上げることで上記の下支えをしている
業務システム開発でデザインとフロントエンドも妥協しない話（まとめ）
一緒に、理想に向かってデザイン・フロントエンド開発を進めてくれるデザイナー・エンジニア大募集です！
単純に情報交換だけでもいいので、Twitterなどで別途連絡ください。よろしくおねがいします！