株式会社グラファーの【Govtech】Product Developerの求人

## ▍グラファーについて 1つの社会課題だけをテーマに事業を行う企業は多くあります。 一方でグラファーは、行政・食品流通・AI駆動開発と異なる領域に挑戦し、現場に深く入り込みながら事業として形にしてきました。 私たちが取り組む領域を広げ続けてきたのは、どの現場でも、本来なくてもいいはずの手続きや工程が人や組織の行動を止め、社会が前に進むことを阻害している現実に何度も直面してきたからです。 そして今、AIの進化によって、これまでSaaSでは業務の個別性に対応しきれず、個別開発ではコストや運用負荷が大きすぎて実現できなかった“手順の問題”にまで踏み込めるようになりました。 **We Remove Steps.** このミッションのもと、私たちは社会に根付いた「価値を生まない手順」に向き合い、事業をさらに進化させていきます。 ### 会社概要 - [会社紹介資料](https://speakerdeck.com/graffer/zhu-shi-hui-she-gurahuahui-she-shao-jie-zi-liao) - [会社紹介資料（プロダクト開発編）](https://speakerdeck.com/graffer/zhu-shi-hui-she-gurahuahui-she-shao-jie-zi-liao-purodakutokai-fa-bian) ### 事業、組織、文化について - [「アウトプットではなくアウトカム」を常に考える組織であり続けたい。VPoP兼VPoEに就任した黑﨑の想いとは？](https://career.graffer.inc/inside-graffer/product-management) - [Govtechスタートアップ におけるSecurity Engineerとは？](https://career.graffer.inc/inside-graffer/security-engineer) - [【エンジニア編】カジュアル面談でよく聞かれることにお答えします](https://career.graffer.inc/inside-graffer/engineer-casual) - [不確実性の高い状況で意思決定力を試されるプロダクトマネージャー。その業務内容と成長の転機とは](https://career.graffer.inc/inside-graffer/aisolution-hirata) - [「バリュー再定義プロジェクトの全容を公開します」Part1（完結編のPart2も公開しています）](https://career.graffer.inc/inside-graffer/value-part1) ## ▍本ポジションのミッション プロダクトマネージャーや事業開発部門と協働し、行政DX SaaS [『Graffer Platform』]( https://graffer.jp/governments ) の開発を主導します。ユーザーヒアリング、現場業務体験等を通じ、顧客の理解を深めながら、フルサイクル/フルスタック開発を用いて、真の課題解決につながるあるべきプロダクト体験を作ります。 ## ▍業務内容 - プロダクトで解くべき課題の深堀り/要件策定 - 機能開発・運用 - 他部門を巻き込んだプロダクト開発の推進 - 開発速度を向上させるための技術的な課題設定及び解決 - 問い合わせ対応含む安定稼働のための保守、運用 ## ▍仕事の魅力 ### ■課題/ソリューションの距離の近さ、フィードバックサイクルの高速化 プロダクト開発は新しい問題や未知の問題に取り組むものであり、機能開発や改善は顧客の問題を理解できない、または問題解決に対する適切なアプローチが分からないところからスタートします。課題に対する知識とソリューションの知識を結合させることで価値候補を生み出しますが、その価値候補が本当の価値（すなわち顧客の課題解決）になるかは提供してみないとわかりません。つまり、課題と思われるものを特定し、適切と思われるソリューションを提供し、フィードバックを受けてそのフィードバックを基に改善を繰り返す、このサイクルを高速で何周も回すことがプロダクト開発にとって必要だと考えています。 ### ■中長期での成長に向けた全体最適 SaaSビジネスは、単一の顧客ではなく、複数の顧客が抱える共通の課題やニーズによって形成される「市場」に向かって「プロダクト」を提供していくビジネスモデルです。常に課題が変化するこの市場に対し、中長期的に「プロダクト」を中心とした事業成長を実現していくためには、「プロダクトを具現化するソースコード」を含めたプロダクトの全体最適を常に意識し、開発を進めています。 ### ■フルサイクルの開発を重視する理由 上記の2つの前提（価値発揮までの高速化と中長期での成長を見据えた全体最適）を踏まえると、ソフトウェア開発ライフサイクル（課題発見から運用まで）の各プロセスにおける意思決定者が異なると「分業的」となり、この分業化により、コミュニケーションによるタイムロス、知識伝達による情報の欠落、組織同士の利害対立が発生します。その結果、Time To Valueの長期化（価値を届けるまでの時間が長期化し、フィードバックサイクルが遅延）、価値開発力の低下（解くべき課題とソリューションが一致しない）、局所最適による失敗（担当範囲内でのゴール設定）が引き起こされます。 これらを未然に防ぐため、ソフトウェア開発ライフサイクルの各プロセスにおける意思決定者を同一にすること（すなわち、プロダクトマネジメントとエンジニアリングの意思決定権を同居させること、フルサイクル開発を採用すること）が必要であり、これにより長期的に市場（ユーザー）に潜む課題を最速で解決することが実現できると考えています。 ### ■当社では、ソフトウェアエンジニアを「Product Developer」と呼称しています プロダクト開発には「Why：なぜ作るのか（解くべき課題）、What：何を作るのか（プロダクト、機能）、How：どう作るのか（ソースコード、技術）」という3つの要素があります。当社では、「Why」と「What」を自分ごととして捉え、正しく理解することで、初めてアーキテクチャや技術、ソースコードといった「How」を正しく実現できると考えています。また、既存の「How」をきちんと把握しておくことで、長期的な価値発揮に向けた「What」を選択できると考えています。そこで、グラファーではソフトウェアエンジニアはフルスタックエンジニアでありながら、プロダクトの「Why、What、How」の全てに責任を持ち、一人ひとりが裁量と責任を持ち、プロダクトの成長そのものに貢献することができる体制を敷いています。このことを職種の名前から表現するために、「プロダクトを成長させる人」、つまり「Product Developer」という呼称を採用しています。 ## ▍開発環境 当社の技術選定のモットーは「適切な問題に、適切な道具を」であり、解決したい問題を見極めながら、問題解決に合う、広く普及した一般的な言語や技術スタックを選定しています。 解決したい技術的課題に応じて、新しい技術の導入に向けたスピーディな検証を行ってから利用しています。 ### フロントエンド - 言語：TypeScript - フレームワーク：React, Next.js - インフラ：AWS, Docker, Terraform - ツール：StoryBook, Chromatic ### バックエンド - 言語：Go, Python - フレームワーク：Gin、Flask - インフラ：AWS, Docker, Kubernetes - DB：PostgreSQL, MySQL, MongoDB - API：GraphQL, REST, gRPC ### 共通 - CI/CD：GitHub Actions, Argo - 運用監視：Sentry, Datadog - デザインツール：Figma - コード管理：GitHub, Renovate - 生成AI：GitHub Copilot, Devin, Cursor, v0 - タスク管理：Jira、GitHub Issues - コミュニケーションツール：Slack, Google Workspace, Esa