プロダクトエンジニアへのご招待

Transcript

1. プロダクトエンジニアへのご招待 -良くある誤解と価値ある未来- 2025年10月2日 Enterprise事業部Enterprise Product Team Manager / Product Manager 河治　寿都
2. 2 エンタープライズプロダクト部 Manager/Product Manager 河治 寿都 2011年　東京大学大学院卒業後、新卒でグリーに入社 以降は越境EC、IoTベンチャー、ヘルスケア領域でTechLead, VPoE, EMを経験後、2025年04月よりグラファーに参画。Graffer AI Studio の開発に従事。 小学校の頃にWindows95とインターネットに出会い、HTMLと JavaScriptを触ってゲーム作りからプログラミングにのめり込む。 技術分野においてはバックエンドエンジニアからインフラ領域、フロン トエンド領域まで幅広く携わり、開発に関わるところで、ユーザー動向 の分析業務や機能企画、顧客対応、システム運用、営業活動から採用、 組織開発、上場に向けての監査対応まで幅広い業務を経験。 自社インタビュー記事 https://career.graffer.inc/inside-graffer/dev-team-management_1 https://career.graffer.inc/inside-graffer/dev-team-management_2 お前誰やねん
3. グラファーのミッション 「プロダクトの力で 行動を変え 社会を変える」 プロダクト 顧客変革 • 「顧客とその先の顧客」の課題解決に資する高 付加価値な解決策を提供する。 • プロダクトとは、多くの顧客に適用可能な形に 仕立てられたスケーラブルな解決策である。 • 高いスケールメリットが、顧客にとってのコス トパフォーマンスと当社の収益を両立する。 • プロダクトが創出する価値を最大化するための 顧客側の業務・事業の変革を支援する。 • 業務や事業の変革を突き詰めることは、必ず 「経営の変革」に直結・帰結する。 • 創出する価値を最大化し、それを顧客と当社で 分け合うことができるwin-winを達成する。 社会変革 • プロダクトを通じて、顧客とその先にいる顧客 に対し価値を提供しきることで、結果的に社会 がより良い姿に変革することができる。 • プロダクトと顧客の経営変革を突き詰めていく ことで、当社が社会にもたらすインパクトを最 大化できる。 キャッシュフロー（＝利益）の最大化 社会インパクトの最大化 顧客の変化 私たちの価値提案 顧客の先にいる顧客＝社会の変化 3
4. 行政サービスのデジタル変革 Graffer Platform 生成AIを企業の業務で活用していくために必要な、伴走支 援、研修、活用プロダクトを包括的に提供。 生成AI活用によるビジネス変革 Graffer AI Solution 4 行政・自治体向け 事業者向け 事業内容 住民接点から行政の内部事務まで切れ目のない行政サービス を実現する、数千万人の市民が使うことのできるデジタル行 政インフラを提供。
5. Graffer Platformとは 5 行政サービスのデジタル変革 オンライン手続き Graffer スマート申請 手続きの案内 Graffer 手続き イド 窓口のネット予約 Graffer 窓口予約 スマートフォンやウェブから 行政サービスが利用できます 手続きや制度の案内、窓口の予約からオンライン手 続きまで、様々な行政サービスをインターネットか ら行えるようにする、行政機関向けのクラウド型の サービススイートを提供しています。 数百万人の市民が使う デジタル行政インフラです これまでに顧客である地方自治体を通じ、数百万人 の市民の方がGraffer Platformを通じてオンライン手 続きなどの行政サービスを利用しています。 電話自動応答／電話発信 Graffer コール
6. Graffer Platformのサービス提供実績 6 6団体 102団体 50団体 273団体 2020年3月 2022年3月 2021年3月 2023年3月 160団体 2024年3月 行政サービスのデジタル変革 194団体 2024年9月 ✔ 自治体中心に273団体にサービスを導入 ✔ 4,100万人超の市民を対象にサービスを提供 ✔ 政令指定都市の70%で導入実績がある 導入団体の例（一部）
7. データ分析・処理 一括処理 アプリケーション エンタープライズ向け生成AISaaS「Graffer AI Studio」 • 汎用的に活用できるチャットサービスを起点としながら、より簡易的に生成AIを活用できるアプリケーションや、 高度な活用や定常業務の効率化につながるような機能を幅広く提供 7 チャットサービス • GPT/Geminiなどモデル切り替え機能 • プロンプトのテンプレート共有機能 • 法人利用に即したアカウント管理 など多数搭載。 タスクライブラリ 営業や経営企画など業務タスクごとにアイテムを用意。 フォーム入力をするだけでプロンプトなしに生成AI活用が可能。 ExcelやCSVなどのファイルを読み込んで、 集計処理や詳細なデータ分析を行うことが可能。 定性的なアンケートのカテゴリ分類や、大量の求人原稿の作成な ど、同種のプロンプトの実行を繰り返し行う場面で、その処理を 一括で行うことが可能。 ワークスペース 社内のドキュメントを継続的に管理し、チャット機能を通じて検 索・参照をしながら新しい成果物を生み出すことが可能。 音声文字起こし 音声や動画データをアップロードすることで、簡単に文字起こし ができ、議事録の作成やWord / PDFファイルの生成が可能。 ファイル検索 その場でPDFなどのファイルを読み込んで、単発的に、 チャットの指示で文言の検索や示唆出しなどの処理が可能。 事業者向け
8. Graffer AI Solutionの導入企業（一部） 8 枚方市 その他、IT・広告企業、食品卸売業、人材派遣会社、鉄道、銀行などさまざまな業界で導入 2.8万人超のビジネスパーソンの生成AI活用を支援 生成AI活用によるビジネス変革
9. 9 Findy Team+ Awardを2年連続で受賞🎉🎉
10. 1. 弊社の組織体制
11. プロダクトエンジニアに対して思われること
12. いろいろ関わることになるので忙しそう なんなら仕事が丸投げされる感じになりそう
13. ビジネスが良くわからないし タスクが抽象的になりそう なんか難しそう エンジニアの自分にはできなさそう
14. コミュ力とかソフトスキルも必要そう
15. 作り手のエゴが出やすくなりがちで 本当にユーザーにとっていいものになっているの？
16. やることが多すぎて 中途半端なソフトウェアになりませんかね？ 事業・プロダクトに向かいすぎて技術負債多そう 技術的成長ができないんじゃない？
18. 全て、弊社に対して誤解されやすいところなので 説明させていただきます。
19. 19 グラファーのアプローチ ユーザーの業務知識と課題を少人数に集約し 分業的ではなく一気通貫でプロダクトを作る point!! 機能組織が分業して プロダクトを作る 企画から開発/運用まで一貫し てプロダクトを作る 多数のメンバーで プロダクトを立ち上げる 1人〜 + AIで プロダクトを立ち上げる プロダクト志向×多能工 AI×少数精鋭フルサイクル開発
20. グラファーのプロダクト開発体制 20 課題発見 要件定義 設計 実装 テスト リリース 運用 What How グラファー Why • プロセス毎の分業をしていません。 • 全メンバーが課題発見から運用までをフルサイクル的に担当します。 プロダクトマネジメントとエンジニアリングの意思決定権を同居させる プロダクト開発の考え方 AI×少数精鋭フルサイクル開発 プロダクト開発各メンバー（Product Manager/ Product Developer） 開発プロセスにおけるコミュニケーションの最小化 長期的に市場（≒ユーザー）に潜む課題を最速で解決し続けること
21. 21 • アプローチの仕方は「フルサイクルエンジニア」と呼ばれるもの • フルサイクルエンジニア ◦ 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年）からこのアプローチでプロダクト開発をスタート • 結果的に多数の複数のプロダクトをリリースし、現在でも日々成長中 プロダクト志向×多能工 AI×少数精鋭フルサイクル開発
22. 22 What How Why 市場分析 ユーザーヒアリ ング 機能仕様 非機能仕様 API設計 DB設計 ソースコード テスト結果 課題発見 要件定義 設計 実装 テスト リリース 運用 アウトプット インプット フルサイクル開発とAIの相性 AI×少数精鋭フルサイクル開発 • AIを活用し目的を達成させる手腕が必要 ◦ ①AI/AI利用ツールの特性を理解し、ゴールに導くための制御を行う ◦ ②案件の背景や制約を理解し、価値に繋がるゴールを生み出す • フルサイクル開発（プロダクト志向×多能工）との親和性 ◦ インプットから期待通りのアウトプットへ導く/アウトプットを正しく評価できる ◦ そのためにはWhy,What,Howの理解が必要 ◦ すなわち、フルサイクル開発（プロダクト志向×多能工）との相性が良い
23. プロダクトエンジニアを配置するなら組織全体の巻き込みが必要不可欠 23 マーケット プロダクト 顧客 コード 販売した顧客が実際は、対象としているマーケッ トの「顧客」ではなかったり、特定の顧客の声 が強すぎる声に引っ張られてしまうこと。 ※後者はエンタープライズ系で起きやすく、ま た、戦略的に意思をもってその要望に答えるこ ともともあり、一概に問題とは言えないもので もある。 これらに引きづられると、マーケットとプロダク トのズレ、プロダクトとコードのズレを引き起 こし、それらが、負債になりやすい。 「プロダクト」のコンセプトが「マーケット」の 不一致や、「マーケット」に合わせた「プロダ クト」を定義する際に、実際の制約（「コー ド」）を考えられていないために不必要に複雑 化したり、特定のケースに合わせすぎたりする ことで起きる負債。 前者側の負債はマーケットへ浸透させようと思っ てもできなくなってしまう状態を生み、後者側 の負債は（よりよいやり方に比べると）、他の 機能開発の制約を生んでしまったり、変更に時 間がかかったりと、「技術負債」と同種の負の 影響を生む。 プロダクトとコードの間に起きる不一致は、いわ ゆる「技術負債」といえます。プロダクトのコ ンセプトや方向性を、具体的なコードの設計で 実現できていないために、新たな機能の追加 や、変更の影響範囲が大きくなってしまってお り、必要以上に開発に時間がかかってしまった りする状態を指します。 仕様負債 顧客負債 技術負債 全ての負債を最小化するには価値提供に関わる人々が 全プロセスの最低限の認知・理解が重要 そのためにはプロダクトエンジニアの配置だけでなく全社的な取り組みとして行う What Why How
24. 2. 実例
25. いろいろ関わることになるので忙しそう なんなら仕事が丸投げされる感じになりそう
26. Why/What/Howと職責を理解することはめちゃくちゃ大事 26 マーケット プロダクト 顧客 コード コンセプト、ビジョン、方向性に アラインした形での具現化 課題、トレンドに アラインした課題解決 共通の課題やニーズ ※全ての課題/ニーズが共通ではない 自社外 自社内 抽象 具体 Why What How Bizメンバー・プロダクトエンジニアが果たすべき「主たる」責務を互いに理解する お互いの業務を理解することで、「双方の染み出し」を実現できる • 顧客：具体的な購入者（潜在的顧客も含む） • マーケット：共通のニーズを持つ顧客の集合（抽象的概念） • プロダクト：マーケット向けの製品（コンセプト、ビジョン、仕様を含む） • コード：プロダクトの具体的な実装
27. Bizメンバーがプロダクトだけでなく 「プロダクト作り」も理解している 双方の染み出しのカルチャーの実例 27 顧客要望のコンテキスト・ヒアリング内 容の共有と要望吸い上げをフロー化して 毎日顧客の理解度を高めている Bizメンバーのプロトタイプ例 顧客起点 VoC PFR Backlog/Issues Sales/Success/PMM 開発起点 PdM/PdD 開発起点 開発・リリース ロードマップ 反映 PdM/PdD 要望の起票 顧客の声の登録 アイデアの登録 開発着手 クローズ／ リリース 案件／顧客
28. ビジネスが良くわからないし タスクが抽象的になりそう なんか難しそう エンジニアの自分にはできなさそう
29. • AIの存在を前提とすることでワークフローが完全に変貌し、従来なら数名～数十名で実施していた業 務のほとんどを1名で自己完結的に実施可能な時代になった。 AI革命で変わるソフトウェア開発プロセス 29 企画・設計 実装 リリース・運用 Open AI GPT-5 Gemini Pro 2.5 設計書 プログラムコード テスト・動作確認 Claude Code Cursor Codex-CLI Devin 修正提案 (pull-request) • やりたいことを言語化した上 で、AIを活用して設計書に落と し込む。 プロセス AIツール 成果物 • 設計書を参考情報として与えて AIに実装作業を行わせ、人間が 修正・調整の指示を出す。 • テストケースの作成や失敗した テストに対する修正はAIツール に作業を依頼し非同期で処理。 高度な推論を用いたタス クに最適なモデル。 AIを用いた開発ツールの 国際標準。 非同期の自立型タスク実 行マシン。 markdown形式等で書面化 させる。 AIが直接コードを作成・ 更新・削除可能。 人間が修正提案をレ ビューし必要に応じマー ジ。 • 開発したプログラムの実際のリ リースや監視については、従来 からDevOpsツールが充実して おり大半のプロセスが既に自動 化済み。 • 監視ツール等には既にAIによる モニタリング機能が付属してお り、トラブル発生時には人間に 通知や必要な情報提供がなされ る。 ほとんどのAIツールは幅広いソ フトウェア開発の知識を持って おり、不足する知識をいつでも 遠慮なくAIに質問しながら作業 できるのもメリット。
30. 実際にプロダクト発信で顧客提案・機能企画を行い、これまでに複数のプロダクト・機能が リリース プロダクトエンジニアが課題抽出からデリバリを行った実例 30 詳細は以下にて発表 AI Engineering Summit https://findy-tools.io/events/ee3c2a3e9ea26296d2e6 開発生産性Conference 2025 https://findy-tools.io/articles/graffer-dev-productivity-con-2025/146
31. コミュ力とかソフトスキルも必要そう
32. 安心して発言できる実例 32
33. 作り手のエゴが出やすくなりがちで 本当にユーザーにとっていいものになっているの？
34. 直接的なコメント・商談参加ユーザーヒアリング・ユーザー会の開催 フィードバック文化とユーザーとの接点・接触機会がある実例 34
35. やることが多すぎて 中途半端なソフトウェアになりませんかね？ 事業・プロダクトに向かいすぎて技術負債多そう 技術的成長ができないんじゃない？
36. 高速なデリバリ環境・業務設計と新しい技術的な取り組み・ケイパビリティの獲得 デプロイ頻度 36 リリース頻度 6.18回/日 ※2025/4 - 2025/6までの集計
37. 3. これからについて
38. プロダクトエンジニアは間違いなく需要が増える職種になる 38 生成AIの登場により、時間をかけて磨き込んだスキルを一瞬で補えることができるように なった。そのおかげで他職種への染み出しや踏み込みも容易になってきており、プロダクト エンジニアに関する技術発信は増えてきている
39. 「課題」に対して時間を十分にかけるべく、他職種の染み出し以上に顧客目線のインサイト を獲得し、従来よりクリエイティブにかつ、本質的な課題解決に繋げるためのプロダクト・ 仕組みを提供することがより現実的に求められてきている。 今後のエンジニア組織がコミットすべき範囲 39 ・課題の本質的理解 ・素早い実装 ・お客様要望の可視化 ・お客様要望の的中 前線に立つ お客様への価値提供 ・お客様満足度の向上 ・市場での期待値向上 満足度をあげる ・拡張性の担保 ・安全性の担保 ・生産性の担保 資産化する ・技術資産の品質向上 ・利活用の徹底 ・管理/メンテナンス 最適化する これまでのコミットする範囲 これからコミットすべき範囲
40. 生成AIを活用して、お客様への提供体験を最適化する モックレベルのコードからMVPを自動生成し、改善項目を加えてプロダクションコードに 変換する部分までを徹底的に自動化する ソフトウェア品質を管理・許容できる範囲でデリバリと品質のバランスを最適化する 開発プロセスと顧客提供体験の最適化 40 顧客要望 MVP実装 プロダクト プロダクション コード 課題抽出 POC 製品化 プロトタイプ コード モックレベル コード コード品質 テストカバレッジ
41. • 世にある便利なAIツールを使えば、誰でも生産性を20%程度高めることは簡単である。 • 実際には、AIをフル活用することで、生産性は2,000%向上させることができる。 生産性 +2,000% の世界へ 生産性 +2,000% +20% +2,000% 生産性の向上ペースは100倍にできる 41 現状 将来
42. グラファーの採用情報を見る グラファーの日常を見る 社員に話を聞いてみる グラファーが大事にしていることは、最先端のテクノロジーを追い求めることではなく、 「人の課題」に向き合い続けることです。 そこに夢中になって取り組むメンバーがいます。 グラファーは、これからも社員一人ひとりが「人の課題」に向き合い、 誰もが等しくテクノロジーの恩恵を受けられるような 新たな価値提供の機会を探索し続けます。 プロダクトエンジニアにチャレンジしてみたい方は ↓↓↓ぜひアクセスしてみてください↓↓↓
43. 43 graffer.jp hr@graffer.jp 東京都渋谷区千駄ヶ谷一丁目5番8号 URL Contact Address