【開発生産性カンファレンス 2025】 AIを前提とした開発プロセスとマネジメントの変革 - 開発生産性+2000%達成に向けた取り組み

グラファーについて

黑﨑：グラファーは、「プロダクトの力で 行動を変え 社会を変える」というミッションを掲げています。

このミッションにあるように、私たちの価値提案は、ソフトウェアプロダクトを提供することによって、お客様の事業や業務に変革をもたらし、その結果として、お客様を変え、さらにその先にいるエンドユーザーや市民の皆さんに変化を起こすことで、社会インパクトの最大化を目指しています。

このミッションを実現するために、私たちは2つの事業を展開しています。



黑﨑：1つ目が、今では社会インフラとして当たり前になってきた行政サービスのデジタル変革を担う「Graffer Platform」です。皆さんも引っ越しやお子さんの誕生といったライフイベントの変化で関わることがあると思います。

簡単に言うと、スマートフォンやウェブから行政サービスを簡単に利用できるプロダクトです。例えば、引っ越しするタイミングでどんな手続きが必要なのか、どこに何を持っていけばいいのかを、自分の状況に照らし合わせて一覧化できるサービスや、そのままオンライン申請をして、実際に市役所や区役所に来庁しなくてもオンラインで手続きを完結できるようなプロダクトを展開しています。



黑﨑：これまで全国約1,700ある自治体のうち273自治体に導入していただき、約6,900万人の市民の方々にサービスをご利用いただける状況になっています。日本人の2人に1人の方が利用可能な状況で、もしかしたら皆さんの中にもお使いいただいた方がいらっしゃるかもしれません。

もう1つが、2023年から展開している民間企業向けの「Graffer AI Solution」です。これは生成AIを活用したビジネス変革を支援するソリューションです。こちらは3本のサービスをまとめて1つのソリューションとして提供しています。



黑﨑：1つ目が生成AIプロダクトで、企業がセキュアな環境でChatGPTやGeminiといった生成AIモデルを活用できる「Graffer AI Studio」というサービスを展開しています。

2つ目が生成AI利活用の伴走支援です。生成AIをどう活用していきたいのか、何を解決していきたいのか、それを使うことによってどんなことを実現したいのか、といった課題から一緒に考えるサクセス・サポートをサービスとして提供しています。

3つ目が生成AI研修・人材育成です。生成AIをどう使っていくかについて、そもそものリテラシー向上が課題になっていると考えているので、それを上げていく支援を行っています。

これら3つの柱を持って、「Graffer AI Solution」を提供しており、皆さんにもなじみのある大手企業様にも多数導入いただいています。

このような事業背景を持つグラファーが、なぜ開発生産性向上を目指し、どのような取り組みを行っているのか。これから詳しくお話ししていきます。

なぜ生産性向上を目指すのか

黑﨑：なぜ生産性向上をそもそも目指すのか、ということについて目線合わせをさせていただきたいと思います。

グラファーのプロダクトに求められることは、おそらく皆さんにとっても共通する話だと考えています。企業がプロダクト事業として取り組んでいく中で、長期的なゴーイングコンサーンの中でプロダクトを提供して対価を得ていく、つまり市場に潜む課題に価値を提供することによって対価を得ていくことが、現在我々が取り組んでいることです。



黑﨑：競合や市場が厳しい中で、いかに最速で課題を解決し続けるか、価値を提供し続けるかが最大の目的です。

従って、生産性向上を突き詰めると、価値を最大化していくこと、価値提供を最速化すること、そして10年といった長いスパンで見た時に価値の創出速度を維持していくこと、これらを担保するために生産性を上げ続ける必要があると考えています。

では、皆さんは生成AIで生産性をどの程度向上させることができているでしょうか。

独立行政法人経済産業研究所が発表しているレポートによると、全産業で見て大体10%から30%、平均すると20%程度の向上となっています。



黑﨑：私が今回の登壇準備として調査したマイクロソフト、GitHub、グーグルが発表しているレポートでも、大体10%から多くて50%程度、トレンドとしては20%から30%程度の改善が見られます。

これらのデータから、AIを導入することで生産性20%から30%の向上は実現できると言えますが、AIのポテンシャルを考えると「この程度なのか」という印象があり、生産性を爆発的に向上させる銀の弾丸ではないことが分かります。

そこで今回は、開発生産性2000%達成を目指してAIを前提とした開発プロセスとマネジメントを実践するグラファー独自のアプローチをご紹介します。

参考までに、Findy Team+ Awardで2023年と2024年の2年連続で生産性評価をいただいており、リリース頻度については弊社の各プロダクトで1日平均6回のアプリケーションレベルでの本番リリースを実施しています。

開発生産性向上のための従来の取り組みとして、2022年から2025年にかけてAIの登場により変化している部分もありますが、主に定型プロセスの自動化、エンジニア採用による開発体制の増員、AIツールの導入と利活用の仕組み整備などが挙げられます。



黑﨑：これらを一般的なプロダクト開発の流れ（課題発見→要件定義→設計→実装→テスト→リリース→運用）に当てはめると、AIツールは主に設計、実装、テストの工程で活用され、CI/CDやユニットテストの自動化、採用による体制強化は全プロセスに寄与します。

しかし、本当にこれらの取り組みだけで生産性が2000%アップするのでしょうか。生産性を「成果÷投下コスト」と定義して考えてみると、それぞれの施策は異なる効果をもたらします。

AIツール導入は個人のアウトプット品質向上に寄与するスケールアップ（成果の増加）です。自動化は人手作業の削減によるスケールイン（投下コスト削減）です。そして採用によるメンバー追加はスケールアウト（投下コスト増加）の構造となります。

グラファーでは、スケールアップとスケールインは当然取り組むべき領域である一方で、過度な分業と過剰採用、つまり「過度なスケールアウト」が生産性向上を阻害する要因になっていると考えています。

実質的に投下コストの方が成果より上回ってしまう構造や、生産性が上がっていくまでに長いリードタイムが生じていることが、生産性を上げきれない要因になっているのではないでしょうか。

AI×少数精鋭フルサイクル開発のアプローチ

黑﨑：分業が必要になる根本的理由は、専門性の違いです。フロントエンドエンジニアがバックエンドの知識を持たない、プロダクトマネージャーがエンジニアリングを理解していないといったように、専門性に違いがあり、相互に補う必要があるから分業が発生します。

この分業が発生することで、プロセス間・チーム間での情報伝達が必須となり、コミュニケーションが発生します。しかし、100%の情報伝達は不可能であり、必然的に情報ロスが生じます。その結果、価値を提供するまでのリードタイムが増加し、情報がロスすることによって価値開発力が低下してしまいます。

また、かつてのDevとOpsが分離していた時代において、価値提供の方法を巡る対立が典型例として挙げられます。こうした利害関係や局所最適化の進行は、組織全体の生産性低下に直結する課題になっていました。

ところが、AIを活用することによって、スキルギャップを埋めることが容易になってきました。自分以外の専門家のスキルや知識に頼っていた部分を、AIに問い合わせることで補完可能になり、プロダクトマネージャーがバイブコーディングでものを作れる時代が到来しています。



黑﨑：過剰採用は、取り組みたい業務量に対する人数不足から生じます。人員を増やし続けることで、ピープルマネジメント工数の増加、AIを最大限活用できないメンバーの割合増加、タスク調整のための「仕事をつくる仕事」の発生といった新たな課題が生まれます。

AIの進化により、リソース代替も可能になってきました。プロダクト開発において、従来であればメンバーにアサインしていたタスクを、DevinやCursorを活用して処理することができます。

これらの共通要因として、コミュニケーションの肥大化が生産性を大きく低下させているという認識があります。したがって、開発プロセスにおけるコミュニケーション最小化が、生産性向上の鍵になります。

なお、分業を完全に否定しているわけではありません。また、コミュニケーションが全く不要というわけでもありません。重要なのは適切なバランスを見つけることです。

グラファーでは、「プロダクト志向×多能工」というアプローチを採用しています。プロダクト志向とは、ユーザーの思考を重視し、ユーザー価値の最大化を目指して全体最適で行動する考え方です。

多能工は、トヨタ生産方式からインスパイアを受けた概念で、1つのプロセスを専従で担当するのではなく、複数のプロセスを一人の人間が一気通貫で担当できるようにする仕組みを指します。

私たちは、ユーザーの業務知識と課題を少人数に集約し、分業ではなく一気通貫でプロダクトを作るアプローチを実践しています。



黑﨑：この考え方を開発に適用すると、プロダクトマネジメントとエンジニアリングの意思決定権を同一人物に集約することになります。グラファーでは、課題発見から運用まで、1人のプロダクトマネージャー/プロダクトディベロッパーが全責任を負う体制を構築しています。

「なぜこれが課題なのか」「どのような機能が適切か」「どう作るべきか」「どのようにテスト・リリースするか」といった一連の意思決定を、基本的に1人が担当します。1つのチームには複数のプロダクトディベロッパーが所属し、それぞれが並行して複数の課題を解決し続ける開発体制になっています。

一気通貫のアプローチが重要な理由は、SaaSビジネスの特性にあります。マーケットに対してプロダクトを提示する際、顧客の共通課題やニーズで構成されるマーケットとの向き合いが不可欠です。

「なぜ作るのか」（Why）は、マーケットの顧客との向き合いによってのみ理解可能です。「何を作るのか」（What）は、マーケットが求める機能の特定です。「どう作るのか」（How）は、プロダクトのビジョンに基づく具体的実装になります。



黑﨑：プロセス全体でWhy・What・Howを理解して意思決定することで、「なぜ作るのか」「何を作るか」「どう作るのか」の関係性において情報が欠落することなく一貫性を保てます。結果として、開発プロセスにおけるコミュニケーションを最小化し、長期的に市場の課題を最速で解決し続けることが可能になります。

このプロダクト志向×多能工のアプローチは、昨今注目されているフルサイクルエンジニアやプロダクトエンジニアの概念と方向性を同じくしています。ただし、グラファーは2017年の創業当初からこのアプローチでプロダクト開発を実践しており、複数のプロダクトを継続的に成長させてきた実績を有しています。

このフルサイクル開発とAIの親和性が、「AI×少数精鋭フルサイクル開発」のアプローチの核心になります。AIツールの活用においては、新卒・ジュニアメンバーのマネジメントと同様の手法が適用可能です。AIの能力と限界を把握し、適切な段取りとアウトプットの明確化を通じて、人間とAIの協働による効果的な開発体制を構築することが重要です。

事例：データ整備ボトルネック解消による事業拡大

平田：直近で私が関わっているプロダクトの事例として、ある会社において商品の海外輸出拡大が経営上の重要テーマとなっており、AIを使った課題解決のご依頼をいただき、現在PoCを回している状況です。

今回の特徴は、私が通常のプロダクト開発だけでなく、その前段階の事業開発の部分も含めて担当したことです。まさに事業開発からプロダクト開発まで、フルサイクル開発をさらに飛び越えて、一気通貫でやったということです。



平田：事業開発の段階では、そもそも解くべき課題は何なのかというところのヒアリングから私が担当しました。実際に課題解決の背景にある業務フローを、全て私が書き出しました。

私が現場に行って、現場の方が今どういうふうにオペレーションやっているのかを実際に見た上でフロー化して、「ここがボトルネックですよね。ここをこういうふうに解消していきましょうね」という提案から私がやったものです。エンジニアでありながら、通常ですとBizDevやCSが担う仕事も含めて、プロダクトマネージャーが担当したということが特徴です。

その結果、事業開発の段階から、このコンテキストが私に集約されている状態で、すべての物事を進められることによって、非常にMVPを正確に見極めて、かつ短期間で開発をすることができました。事業とプロダクト双方のコンテキストが常に同期された状態となり、改善のサイクルを高速で回してクオリティを高められました。

それぞれの工程で私は非常にAIを活用し、基本的に全てを約1ヶ月でPDCAを回しながら、1名プラスAIという体制で大きな成果を生むことができました。

開発の面に関しては、Claude Codeを非常に活用しました。6月11日から7月2日までの期間で開発を行いました。

総コストは930ドル（約13万円）分のトークンを使用し、トークン数は約10億トークン、コードの行数は大体15万行になります。これだけの開発を私1人プラスAIでやりきったということです。

スキルギャップの解消とリソースの代替という、AIの使いどころに照らして言うと、私の場合、以下のような形でAIを使えました。



平田：私はエンジニア出身なので、プロトタイピングもあまりしたことないし、顧客提案もやったことがないという感じでした。

例えばスライド作成に関しては、GenSparkを使って叩き台を作り、Claudeのインフォグラフィック機能を使ってビジュアル化し、できたものを私は最後に確認してチェックして、それをもとに提案するだけという感じでやりました。

リソースの代替では、プロダクトマネジメント、企画をまとめるところでo1 Pro等を使って企画書を作ったり、エンジニアリングの部分ではClaude Codeを使ったり、一部Devin AIも使いました。軽微なものであればDevin AIに任せて、私が食事をしている間に処理してもらうといった感じで、リソースを並列で走らせられるように工夫しました。

まとめ

黒崎： 平田さん、ありがとうございました。時間の関係上、一点だけ質問させていただければと思います。このAIという話は昨今のエンジニアの中でよく話題に上がりますが、AIでは対応できなかった部分、AIではどうしてもうまくいかなかった部分について、最後にお話しいただけますでしょうか。

平田： はい、まさに「Why」の部分、つまり何が課題なのかを特定する部分は、AIでは対応できなかった領域だと考えています。課題の背景も含めてきちんと把握し、課題の解像度を上げていく作業。この部分については、現場に出て行って、顧客を含めて深掘りをして、深い考察が必要だと思うんですね。

また、実装の際も、私はClaude Codeを活用しましたが、完全にAI任せにはしていません。ソフトウェアは中長期的にメンテナンスしていくものなので、完全にAI任せにして人間が全くメンテナンスできない状況になると、全くサステナブルではないと考えています。

黒崎： ありがとうございます。本日お話しした内容の本質は、「AIを使い倒しつつ、顧客業務と課題の解像度を上げて、圧倒的価値を生む課題解決に向けた少人数フルサイクル開発が、AI時代における開発生産性につながっていく」ということです。

本日は貴重なお時間をいただき、ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です