会社紹介資料（プロダクト開発編） 

本資料は、ぜひ会社紹介資料（全社編）を 見ていただいた後にご確認ください。 

プロダクトの力で 行動を変え 社会を変える ミッション 誰もが等しくテクノロジーの恩恵を受け、自由を享受することができる社会へ。 

創業から継続して提供プロダクトを拡大 現在 4 2017.7 2018.2 2020.4 創業 Graffer 法人証明書 請求リリース Graffer 手続きガイド リリース Graffer スマート申請 リリース Graffer 窓口予約 リリース 複数の新サービスを 実証実験中 2023.4 2022.1 Graffer お悩みハンドブック リリース Graffer AI Studio リリース 2018.11 2021.9 2023.6 Graffer Call リリース 行政・自治体向け 個人向け 事業者向け Graffer AI Solution リリース 2023.10 

組織 

プロダクト体制図 6 ● 各プロダクトチーム：事業戦略に基づいたプロダクト戦略を描き、ユーザー価値最大化に向けた開発・運用を担う。 ● エンジニアリング部：技術・専門性を用いて、事業部横断でのプロダクト共通基盤の進化、プロダクト開発に高度な アジリティをもたらす。 エンジニアリング部 Enterprise事業部（事業者向け） GovTech事業部（行政・自治体向け） プロダクト Product Manager Product Developer Product Developer プロダクト Product Manager Product Developer Product Developer Design Engineer Product Designer Frontend Engineer Platform Product Development Product Manager Product Developer 各事業部のProduct Manager/Product Developerが兼務で所蔵する組織 プロダクト Product Manager Product Developer Product Developer プロダクト Product Manager Product Developer Product Developer SRE Security Engineer Backend Engineer Corporate Software Engineer 

Platform チーム 

8 Platform SRE Site Reliability Engineering Security Security Engineering Backend Backend Developer 信頼性 ● SLO/パフォーマンス管理 ● スケーリング 監視/オブザーバビリティ ● リアルタイムモニタリング ● トレーシング プラットフォームエンジニアリング ● セルフサービスプラットフォーム セキュリティ設計・実装 ● 認証・認可 ● プロダクトセキュリティ ● IaC セキュリティ ● クラウドセキュリティ Kubernetes AWS Datadog 　専門領域を持ち、協働し、事業成長を加速させるチーム 共通アプリケーション ● 認証・認可アプリケーション ● 共通ライブラリ設計・実装 横断テックリード ● アーキテクチャレビュー ● 全社横断的なバックエンド開発の支援 Go AWS Datadog gRPC Sentry Go インフラストラクチャー ● マルチクラウド管理 ● ネットワーク ● DNS 監査・コンプライアンス ● セキュリティ監査 ● 脆弱性対応 ● コーポレートセキュリティ 生産性向上 ● 自動化ツール ● 開発環境 Corporate Software Enginner 

技術への考え方 

技術の重要性：プロダクト成長を支える 10 技術負債の解消/防止 ● 過去には自前で作るしかなかった複雑な領域の外部 サービス利用 ● マーケットに対するプロダクト拡張性と具体の課題 解決のための適切なソースコードを適切な抽象度 ● 「技術への探求」は「プロダクトの成長」と切っても切り離せない関係 有事の際の影響最小化 ● クラウドベンダーが提示する責任分界点を表明する 責任共有モデル ● 自動テストによるインシデント発生の未然防止 ● Datadogを始めとする監視ツールの強化 機能デリバリー時間の短縮 ● Github Copilotなどの生成AIツールよる実装時間の 短縮 ● CI/CDの高度化によるデプロイ時間の短縮 ● 問題発生時の素早いロールバック プロダクトのアイディア ● 技術には課題解決のソリューションという側面が存 在する ● ソリューションを持っていることで課題を特定しや すくなり、プロダクトに対するアイディアに繋がる 

ここ数年の主要な取り組み（参考） 11 ● デザインシステムの導入 ○ プロダクト横断的に利用できるデザインシステムを導入しています。 ○ その結果、プロダクト間での共通のUI/UXを提供することでユーザー体験を向上させるとともに、各プロダ クト開発者にとって「作る」ではなく「利用する」になることで開発生産性を向上させます。 ● 新技術採用（LLM、ベクトル検索、Next.jsへの移行） ○ プロダクト成長のために技術への投資は必要だと考えています。全員が新技術へのアンテナを張り、開発者 体験向上/開発生産性向上など、プロダクトの価値向上に寄与するものであれば積極的に採用をしていま す。 ○ 業務内外に問わず、技術について語り合うSlackチャンネルがあるとともに、各領域に特化したSlackチャン ネルがあり、その領域に対する相談が頻繁に行われています。 ○ Github Copilotを開発メンバー全員に付与しています。 ● インシデント対応フローの制定 ○ インシデント時の対応プロセスが属人化しており、対応するメンバーによってインシデントに対する温度感 /プロセス/対応内容が異なっており、障害復旧時間や顧客対応に影響を及ぼしていました。 ○ サービスの影響度によるインシデントレベルの制定、Slackワークフローを用いたインシデント用Slackチャ ンネル作成および障害対応ドキュメント作成の自動化など、インシデントのオープンからクローズまでを統 一プロセスによって遂行できるようになったことで、インシデント対応への負荷軽減と顧客への影響度を最 小化を実現しました。 

利用技術 12 ● 技術選定のモットーは「適切な問題に、適切な道具を」 ● 解決したい問題を見極めながら、問題解決に合う、広く普及した一般的な言語や技術スタックを選定 Frontend Backend インフラ・ミドルウェア その他ツール ※各社コーポレートサイトより引用 ※掲載しているロゴは各社の商標又は登録商標です Github 

プロダクト開発の アプローチ 

プロダクト開発へのアプローチ 14 プロダクト志向を持つ多能工 

プロダクト開発へのアプローチ 15 プロダクト志向を持つ多能工 

なぜ「プロダクト志向」が必要？ 16 プロダクトによる課題解決 多くの顧客が抱えるニーズ/課題を効率良く解決 することで対価を得る プロダクトは「市場（≒ユーザー）に潜む課題を解 決すること」で対価を得ている SIerなどの労働集約型によって作られたプロダクト ではなく、SaaS型というスケーラビリティを伴っ たプロダクトで解決することで、少ない人数でも高 い付加価値を創出することができる 課題を解決し続けることで理論的には半永久的に価 値創出が可能 長期での価値を創出できる 長期・不可逆なトレンド 社会が抱える長期的に続く、不可逆なトレンド に沿って発展している事業 大きな社会インパクトを残せる 法令が整備され社会的合意が取れているため、行政 のデジタル化は長い期間をかけて進む一方通行のプ ロセスであり、今後、行政のアナログ化が進むこと はない 生成AIは「一過性の話題ではなく、大きな変革期の 始まり」（研究開発戦略センター）であると言われ ており、長期的に活用が進むことはあっても、AIを 使わない方向に人類社会が進むことはない 【グラファー3つの特性】 長期的に市場（≒ユーザー）に潜む課題を最速で解決すること グラファーのプロダクトに求められること スタートアップ 外部から資本を調達し、様々な支援を受けつつ 事業を発展させていく 短期間での急成長を求められる 資本主義の中で企業経営には常に売上や利益といっ た資本面での結果が求められる さらにスタートアップは様々な投資家から資本を調 達しており、短期間での急成長が必要 新しい技術やアイデアを活用し、既存の市場に変革 を起こし、イノベーションを通じて社会や人々の生 活に大きな変化をもたらすことで成長する 

なぜ「プロダクト志向」が必要？ 17 プロダクト軸にした事業展開 多くの顧客が抱えるニーズ/課題を効率良く解決 することで対価を得る プロダクトは「市場（≒ユーザー）に潜む課題を解 決すること」で対価を得ている SIerなどの労働集約型によって作られたプロダクト ではなく、SaaS型というスケーラビリティを伴っ たプロダクトで解決することで、少ない人数でも高 い付加価値を創出することができる 課題を解決し続けることで理論的には半永久的に価 値創出が可能 価値がわかりやすく高利益になりやすい 長期・不可逆なトレンド 社会が抱える長期的に続く、不可逆なトレンド に沿って発展している事業 長期成長が見込める大きな市場機会 法令が整備され社会的合意が取れているため、行政 のデジタル化は長い期間をかけて進む一方通行のプ ロセスであり、今後、行政のアナログ化が進むこと はない 生成AIは「一過性の話題ではなく、大きな変革期の 始まり」（研究開発戦略センター）であると言われ ており、長期的に活用が進むことはあっても、AIを 使わない方向に人類社会が進むことはない 【グラファー3つの特性】 長期的に市場（≒ユーザー）に潜む課題を最速で解決すること グラファーのプロダクトに求められること スタートアップ 外部から資本を調達し、様々な支援を受けつつ 事業を発展させていく 短期間での急成長を求められる 資本主義の中で企業経営には常に売上や利益といっ た資本面での結果が求められる さらにスタートアップは様々な投資家から資本を調 達しており、短期間での急成長が必要 新しい技術やアイデアを活用し、既存の市場に変革 を起こし、イノベーションを通じて社会や人々の生 活に大きな変化をもたらすことで成長する プロダクト志向が必須 ユーザー価値 全体最適 組織横断 事業 

プロダクト開発へのアプローチ 18 プロダクト志向を持つ多能工 

多能工とは 19 ● 1人の従業員が複数のスキルを持ち、複数業務を遂行すること ● 短期的な生産性は単能工が高いが、長期的な生産性は多能工が高い 多能工 ● 複数のプロセスを担当できるため、不測の事態に柔 軟な対応が可能 ● プロセス全体を把握できるため、全体最適な問題解 決に繋がる ● プロセス間遷移のコストが失くなるので、スムーズ に次プロセスに遷移できる ● 同じ知識・経験を複数人が有するため、属人化・ブ ラックボックス化を防ぐ 単能工 ● 特定のプロセスの経験が増すため、高度な専門スキ ルの習得 ● 特定プロセスの熟練度、効率化が進めた、短期的な 生産性が向上する ● 各プロセスにおける需供の不一致が発生するため、 業務負担に偏りが発生する 

ソフトウェア開発における多能工とは 20 課題発見 要件定義 設計 実装 テスト リリース 運用 ソフトウェア開発ライフサイクル UI/UX フロントエンド バックエンド インフラ CI/CD ソフトウェア構成領域 運用 ● ソフトウェア開発ライフサイクルにおける複数プロセスへの染み出し ○ =>DevOps、プレイングマネージャーなど ● ソフトウェア開発/運用の領域のカバー範囲 ○ =>フルスタックエンジニア など セキュリティ 

SaaSビジネスにおける重要な４つの構成要素 21 マーケット プロダクト 顧客 コード コンセプト、ビジョン、方向性に アラインした形での具現化 課題、トレンドに アラインした課題解決 ● 顧客：具体的な購入者（潜在的顧客も含む） ● マーケット：共通のニーズを持つ顧客の集合（抽象的概念） ● プロダクト：マーケット向けの製品（コンセプト、ビジョン、仕様を含む） ● コード：プロダクトの具体的な実装 自社外 自社内 抽象 具体 Why What How 共通の課題やニーズ ※全ての課題/ニーズが共通ではない 

グラファーにおける多能工 22 課題発見 要件定義 設計 実装 テスト リリース 運用 よくあるプロダクト開発 What How プロダクト開発メンバー グラファー Why PdM フロントエンドエンジニア バックエンドエンジニア QA 運用エンジニア ● プロセス毎の分業をしていません。 ● 全メンバーが課題発見から運用までをフルサイクル的に担当します。 

多能工であるメリット 23 Time to Valueの最小化 価値開発力の向上 全体最適 プロダクトのアイデアが顧客に価値を 届けるまでの時間を最小化できる 多能工を採用しない場合、工程によって担当 する人が異なるため、必ずプロセス間に知識 転移（コミュニケーション）が発生してしま う。 その結果、課題発見から顧客のフィードバッ クまでのサイクルが長くなり、次の改善のた めの知識獲得が遅れてしまう。 また、各機能に割り当てられているリソース と仕事の量は等しくないので、多能工ではな い場合、組織内の特定部分にボトルネックが 生じやすい。 課題とソリューションが近くなり創出 できる価値が向上する 機能開発や改善は、顧客の問題が不明瞭/適 切な問題解決のアプローチが分からない状 態からスタートする。課題を解き明かし、 知識（課題）と知識（ソリューション）を 組み合わせることで、価値を創出すること ができる。 知識伝達は必ず知識のロスが伴うため、す べての情報を伝えることはできない。適切 なソリューション構築のための情報がロス する可能性が高まる。 個々人が、自身の担当範囲だけでなく 全体のゴールを達成を目指す 業務を分けて業務と部門を紐づけると、それ ぞれの部門での目標が発生する。結果的に部 門間の利害対立が発生してしまい、個々人が 全体の目標達成ではなく自身の担当範囲内の 目標達成にのみフォーカスする可能性が高ま る。 

24 ● アプローチの仕方は「フルサイクルエンジニア」「プロダクトエンジニア」と呼ばれるもの ● フルサイクルエンジニア ○ Full Cycle Developers at Netflix — Operate What You Build（Netflix Technology Blog, 2018） ● プロダクトエンジニア ● Product engineers (Sherif Mansour: Atlassian, Product Manager, 2018) ● Product and Platform Engineers（Lee Robinson: Vercel, VP of Product, 2023） ● グラファーは創業当初（2017年）からこのアプローチでプロダクト開発をスタート ● 結果的に多数の複数のプロダクトをリリースし、現在でも日々成長中 プロダクト志向を持つ多能工 

よくある質問集 

プロダクト開発には「Why：なぜ作るのか（解くべき課題）、What：何を作るのか（プ ロダクト、機能）、How：どう作るのか（ソースコード、技術）」という3つの要素があ ります。当社では、「Why」と「What」を自分ごととして捉え、正しく理解すること で、初めてアーキテクチャや技術、ソースコードといった「How」を正しく実現できると 考えています。また、既存の「How」をきちんと把握しておくことで、長期的な価値発揮 に向けた「What」を選択できると考えています。 そこで、グラファーではソフトウェアエンジニアはフルスタックエンジニアでありなが ら、プロダクトの「Why、What、How」の全てに責任を持ち、一人ひとりが裁量と責任 を持ち、プロダクトの成長そのものに貢献することができる体制を敷いています。このこ とを職種の名前から表現するために、「プロダクトを成長させる人」、つまり「Product Developer」という呼称を採用しています。 よくある質問 26 Product Developerはソフトウェアエンジニアとは違いますか？ 

よくある質問 27 Product ManagerとProduct Developerの違いはなんですか？ Product Managerは各プロダクトに関する一切の意思決定を委譲され、プロダクトのユー ザー価値創出および事業目標達成のためのプロダクトマネジメント担っていただきます。 Product DeveloperはProduct Managerによって意思決定された開発優先度に基づい て、プロダクト志向を持ちソフトウェア開発ライフサイクルに対する責任を伴って課題解 決を行います。 Product Managerとの違いは、「開発優先度含むプロダクト全体の意思決定権（その説明 責任）」の有無になります。 課題に対して主体性を持って、課題発見〜運用のプロセスを遂行するという業務は Product Manager/Product Developer共に行います。 

よくある質問 28 プロダクト開発メンバーに遠方で勤務している人はいますか？ 関東近郊以外の場所からフルリモートで勤務しているメンバーが複数います。過去には国 外勤務しているメンバーもいました（ただし、海外勤務には一部業務上の制限あり）。 遠方勤務のメンバーの中にマネジメント業務を担っているメンバーがおり、フルリモート 如何に関わらず、「任せられる」と判断したら徹底的に権限委譲を行う文化があります。 

よくある質問 29 作ったものが使われるにはどうしたら良いと思いますか？ グラファーでは「作ったものが使われる」ではなく、「使われるものを作る」という思想 でプロダクト開発に臨んでいます。「使われるものを作る」ために、課題解決に向けてプ ロダクト志向を持ちソフトウェア開発ライフサイクルに対する責任を持つProduct Developerが存在します。 ビジネス部門の要望を応える社内受託になっていませんか？ エンジニアがお客様との定例に参加するなど、様々な１次情報をもとにプロダクトチーム とビジネスチームがプロダクトのあるべき姿を議論し、開発につなげています。 エンジニアサイド／ビジネスサイドといった対立構造はなく、全員が足元の利益、過去の 成功や失敗にとらわれず、常に最善の解決策を追求し、スピーディーに未来を創り出すこ とを重視する開発体制は強みになっています。また、開発優先度の意思決定権はProduct Managerにあります。 

よくある質問 30 Product Manager/Product Developerはフルスタック経験必須ですか？ Product Developerに関しては入社時必須でありません。利用技術未経験だったメンバー が活躍している実績があります。入社時は「技術は手段」と捉えながらも、技術に対して 好奇心を持ち学習できることを重視します。 経験豊富なシニアメンバーしか採用通らないですか？ 現在在籍しているProduct Manager/Product Developerのうち、入社時にエンジニア歴 2~4年目の比較的ジュニア層として入社したメンバーが複数存在しており、入社後1年以 内に主要機能開発を任されています。 過去にはインターンとして入社した後に、Product Managerに担うまでに成長したメン バーもいます。