freee + Product Design FY25Q4

各種ページのリンクについては以下ご参照ください。

P.3 freeeブランドムービーについては【freee】ブランドムービー2021「スモールビジネスを、世界の主役に。」

P.4 有価証券取引報告書（IR）についてはIRライブラリー有価証券報告書

P. 23 武和の社外発表については多様な環境で作り方をデザインする,
P.24 森川の社外発表についてはデザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと

Transcript

1. freee Application Designer 弊社プロダクトデザイナー職のご紹介
2. フリー株式会社について
6. 製品・サービス
9. デザイナーの立ち位置 Application Designer 概要
10. デザイナー職種は原則、全日出社です。 週5出社により、小さいお子さまや近親者のケアな どで日常生活との両立が困難な方は、重要なMTG 等に出社することを前提とし、週1~2日の在宅勤務 が可能です。ほかの事情も、人事の判断で在宅を認 めるケースがあります。 ご自身やご家族の体調不良、お子さまの学校行事 など、突発的な事情でも在宅勤務が可能です。 働き方 デザイナーの出社方針
11. 定義: freee Application Designer PMに多角的な視点を示す問題定義コンサルタントとして伴走し、 高速かつ手戻り不要の のアウトプットで プロダクト開発全域のビジブルなスピード感向上を起こす。 「何を解決するか」 freee Application
 Designer とは
12. Application Designer のビジョン 「業務のデザイン」でチームが同じ夕日を見る
13. チームが同じ夕日を見る Application Designerは質的調査やUI設計など基礎スキルに加 え、職能横断チームが同じ目線でコトに向かえるよう、PMや エンジニアと顧客の 明らかにする が期待されます。 「何を解決するか」 業務のデ ザイン 「業務のデザイン」で 職能横断チームでマジ価値を届けきるために ─
14. 顧客のために解くべき問題のデザイン = 業務のデザインを、PM やエンジニアと実施し、業務の要求に落とし込みます。
 Application Designerは、職能横断チームでの業務の要求を定 め、目線が を期待されます。 「同じ夕日」に揃った状態で各職能の専門性が発揮さ れたプロダクト開発の場作り 同じ夕日を見る QA PM PMM Engineer Engineer 問 題 領 域 何 を 解 決 す る か ← ここで目線合わせ 職能横断チームでマジ価値を届けきるために ─ 解 決 領 域 問 題 の 解 き 方 Designer 業務のデザイン PJの目的 スコープの定義
15. チームで顧客の業務をデザイン PMやドメインエキスパート示す方向性に対し、プロダクト開 発の視点で肉付けや議論をし、 をエンジニアやPMと明らかにします。 どの業務の「何を解決するか」 チームで「何を解決するか」を定義 PMが初期のアイデアを記述したあと、様々な手法で し、顧客の業務のうち「何を解決するか」を職能横断 チームみなが同じ水準で理解することを促進します。 業務の要求 を具体化 リサーチによる要求の精緻化 業務のデザインをする際に挙がる不明点を、端的で します。そ の後、質的調査で得た結果を要求に反映します。 検証可能な 仮説に変換し、職能横断チームで調べる箇所を合意 Designer QA PM PMM Engineer Engineer 解 決 領 域 問 題 の 解 き 方 職能横断チ ーム でマ ジ価値 を届 けき るため に ─ 同じ夕日 を見 る 業務のデザイン PJ の目 的 スコ ープの定義 問 題 領 域 何 を 解 決 す る か
16. UI設計 UT アプリ設計 API設計 インフラ構築 デリバリ管理 ステークホルダ折衝 チームの主要メンバーで「顧客の抱える〇〇を良くしよう！」を合意します。 PM中心に、何を取って何を捨てるかを定義します。 　 「〇〇申請と管理を提供。〇〇は次バージョンで対応」などを定義 職種ごとに発揮できる専門性で分かれ、設計・実装を進めます。 デザイナーは主に、UI設計やそのUTを担います。 エンジニアやPMと、技術要素に関係なく提供すべき顧客の業務の要求を定義。 デザイナーは、要求に不明点があれば質的調査を行います。 　 「ユーザは〇〇申請する」「請求書の総合計の求め方」などを定義 同 じ 夕 日 を 見 て ・ ・ ・ 職 能 ご と の 専 門 性 を 発 揮 職能横断チームの活動イメージ 例 例 DB設計 職能横断チームでマジ価値を届けきるために ─ 同じ夕日を見る 業務のデザイン PJの目的 スコープの定義
17. デザイナーの体制 事業部デザイナーと基盤デザイナー Application Designerは、PMやエンジニアと で働きます。 事業部には、具体のプロダクト開発を担うデザイナーが配置さ れています。基盤開発部のデザイナーは、事業部横断で利用す る機能やデザインシステムを開発します。 プロダクト特性から、デザイナー無しの事業部もあります。 職能横断のプロダ クトチーム 事業部デザイナーと基盤デザイナーの比較 事 業 部 A PM Eng ApD 事 業 部 D PM Eng ApD 事 業 部
 C PM Eng ApD 事 業 部 B PM Eng ApD 事 業 部
 E PM Eng 事 業 部
 F PM Eng ApD 事 業 部
 G PM Eng ApD 基盤開発部 ApD
18. デザイナーの体制 事業部デザイナー 事業部のデザイナーは、次の期待値を担います： R 事業のロードマップの実現を果た R プロダクトのOKR達成を追求す“ R 顧客の業務理解と「業務のデザインˆ R 基盤製品を活用し、高速かつ効果的に開発を担う 事業部デザイナーと基盤デザイナーの比較 事 業 部 A PM Eng ApD 事 業 部 D PM Eng ApD 事 業 部
 C PM Eng ApD 事 業 部 B PM Eng ApD 事 業 部
 E PM Eng 事 業 部
 F PM Eng ApD 事 業 部
 G PM Eng ApD 基盤開発部 ApD
19. デザイナーの体制 基盤デザイナー 基盤開発部のデザイナーは、次の期待値を担います： 事業部デザイナーと基盤デザイナーの比較 事 業 部 A PM Eng ApD 事 業 部 D PM Eng ApD 事 業 部
 C PM Eng ApD 事 業 部 B PM Eng ApD 事 業 部
 E PM Eng 事 業 部
 F PM Eng ApD 事 業 部
 G PM Eng ApD 基盤開発部 ApD ~ 画面テンプレである“標準UI”含むデザインシステムの開発と普j ~ 事業部横断で利用する基盤モジュールの開z ~ UI設計のガイドライン普及
20. スキルと育成 デザイナーの成長とインパクト創出のため
21. チームで要求分析 何らかのモデルやフロー図 チームで要求定義 要求仕様 チームで開発スコープ検討 マイルストーンやバージョン定義 エンジニアと分析 状態マシン図やユースケース記述 質的調査 検証可能な仮説、検証結果、気付き 競合調査 必要な機能要求やユースケース一覧 要求の部分修正・加筆 部分的に具体化された要求仕様 ユーザビリティテスト 検証可能な仮説、検証結果、気付き 情報設計 画面遷移図 テンプレを活用したUI設計 挙動を考慮したfigmaファイル モックの実装 業務ロジックがないモック UIの案出し 数案のfigmaファイル 〇 ◎ 〇 ◎ ◎ ◎ ─ ◎ ◎ ◎ △ ─ 〇 〇 〇 ─ ◎ ─ ─ ─ ─ △ 〇 〇 問 題 領 域 解 く べ き 問 題 解 決 領 域 問 題 の 解 き 方 ミドル 活動の例 シニア アウトプットイメージ 研修 育成 研修 育成 freee ApDのミドルとシニアのスキルセット比較 スキルと育成 業務のデザイン 業務のデザイン 業務のデザイン
22. スキルと育成 育成の方針 次のような全社的な取り組みにより、
 Application Designerはキャリア形成の支援を受けます。 スキルの伸ばし方 ‡ 全社教育研’ ‡ 事業部単位にアサイン予定の、シニアデザイナーによるコーチンm ‡ シニアデザイナー専用の横串トレーニングf ‡ マネージャー陣による育成支援
23. 武和の社外発表 デザインコンサルの企業から弊社にJOINした武和が、職種横断 チームのなかで、 に取り組み、ぶつかった壁やその解決に奮闘した奇跡を紹 介しています。 「業務のデザイン」や「生産工程のデザイ ン」 スライドのリンク 中途入社したシニアの例 スキルと育成
24. 森川の社外発表 エンジニア経験やスクラムプロダクトオーナー経験など、非連 続なキャリアをもつ森川が、 させる取り組みを紹介してい ます。 UI設計にとどまらず質的調査の勘 所や経験を職能横断チームに適応 スキルと育成 スライドのリンク 中途入社したシニアの例
25. マインドセット Application Designerは、人間中心設計（HCD）を 下敷きに、職能横断チームの具体の開発プロセスに HCDのマインドセットを適用します。 弊社でシニアのキャリアを目指す場合、HCDで求め られるコンピタンスの自然な体現が目指せます。 開発プロセスにHCDのマインドセットを適応
26. PJ立ち上げ チームがPJを立ち上げ、 スコープや目的を定義 要求の分析＆調査 業務の要求を洗い出し、不明点 はリサーチ等で明らかにする 業務の要求の定義 解決すべき業務と、
 そこで使われる情報を記述 システム要求の定義 職能横断で業務をfreeeで実現す る場合のWHATを定義 ユーザビリティ評価 定義したユーザビリティ要求を UI案が満たすか仮説を用い検証 実装 エンジニアが設計に基づ きソフトウェアを実装 動作確認 開発単位ごとに エンジニアが要求や設計を 満たすか確認 UIとソフトウェアの設計 エンジニアとデザイナーがそれぞれ、 要求を満たす設計を実施 QA ユースケース等を参考に、 シナリオテスト等を実施 マインドセット 1. 利用状況の理解 及び明示 3. ユーザ要求事項 に対する設計の評価 実際のプロダクト開発の流れ 人間中心設計が定義するコンピタンス 2. ユーザ要求事項の 明示 3. ユーザ要求事項に
 対応した設計解の作成 開発プロセスに人間中心設計のマインドを適応
27. 選考フローの例 選考に進まれる場合...
28. 選考フローの例 二次面接 書類選考 最終面接 オファー面談 一次面接 要求定義＆設計テスト 四段階の選考とオファー面談 一次選考で面接と並ぶ「要求定義＆設計テスト」は、弊社が用 意する仮の開発テーマについて、要求を引き出すためのヒアリ ングをし、成果物としてワイヤーフレームを作成頂きます。 最終面接を通過した場合、配属先の紹介や候補者様が入社後の 期待値を説明いたします。 ※ 候補者様の適性や状況により、選考の回数は増減します 弊社の基本的な選考の流れ