2025年5月アーカイブ

1. はじめに：なぜ生成AIはPoCで止まりやすいのか
2. セッション概要：本番活用企業に見える共通点とは
3. 本番導入できた企業に共通する3つの特徴
4. 技術導入の前提にあるべき"2つの視点"
5. まとめ：PoCを超えるには、文化と仕組みの設計から

1.はじめに：なぜ生成AIはPoCで止まりやすいのか

先日AWS Patner Summit 2025に参加し、「100以上の生成AI導入事例から学ぶPoCを本番利用に導く秘訣」というセッションを聴講してきました。 生成AIの活用は注目を集めていますが、現場では「PoC（概念実証）までは進めたが、本番運用には至っていない」といった悩みを抱える企業も多く見受けられます。 セッションでは、本番導入に進めた企業の共通点について、100件を超える導入事例をもとに整理・分析された内容が紹介されていました。

本記事では、PoCを超えて生成AIを業務に定着させるための"3つの共通点"と、"それを支える組織的な仕組み"についてご紹介します。

2.セッション概要：本番活用企業に見える共通点とは

「100以上の生成AI事例から学ぶPoCを本番利用に導く秘訣」では、AWSが関与した数多くの生成AI導入プロジェクトの中から、本番活用に至った企業の成功要因が紹介されました。 特に印象的だったのは、「本番化に成功した企業は、技術的優位性よりも、組織の進め方や評価の仕組みに違いがあった」という点です。 私たち自身、日々お客様と向き合う中で、PoCが終わった後の"次のステップ"をどう設計するかが導入の分かれ道であると実感しています。

セッションでは、PoCを超えて成果を出した企業に共通する要素として、次の3つが挙げられました。

3. 本番導入できた企業に共通する3つの特徴

（1）顧客起点文化：効果を定量的に測る仕組みがある

成功企業に共通していたのは、生成AIの導入目的が「業務課題の解決」や「顧客価値の向上」といった明確なテーマに基づいていたことです。 つまり、「生成AIの導入が、具体的な業務課題や顧客価値向上といった目的と結びついておらず、『なんとなく使ってみた』というレベルで止まってしまうケースが多い」ようです。 目的や活用シナリオが曖昧なままだと、PoCの意義が不明瞭になり、結果としてプロジェクトは停滞しがちです。　さらに、成功企業ではその効果を定量的に測定する仕組みが整っており、導入の是非を数字で判断できる文化が社内に定着していました。 例えば、「対応時間の短縮率」「生成コンテンツの品質改善度」といった具体的なKPIを設け、取り組みの価値を検証していました。

（2）小規模なチーム：素早い意思決定と実験を可能にする体制

多くの成功事例では、数名からなる小規模なチームでプロジェクトがスタートしていました。 スピード感を持って動けるこの体制は、部門間の壁を越えて柔軟に意思決定できる点が特徴です。
私たちも、開発現場では少人数での検証フェーズを設けることがありますが、こうした体制の重要性を改めて認識しました。 試行錯誤を前提としながらも、成果が見えた段階でスケールさせる柔軟性が鍵になります。

（3）頻繁な実験：小さく始めて早く学ぶPDCA文化

本番導入に成功した企業は、最初から完璧な成果を求めず、まず動かしてみることを重視していました。
「やってみて、振り返って、すぐ改善する」というサイクルを短期間で何度も回すことで、生成AIの精度や業務適合度を高めていく姿勢が印象的でした。 この"実験と学習の反復"が、PoCから脱却するための強力な推進力になっていました。

4. 技術導入の前提にあるべき"2つの視点"

PoCを突破し、本番運用へとつなげるには、3つの共通点だけでなく、技術を受け入れる側の「組織的な仕組み」と「導入の順序」に対する明確な方針が必要です。

（1）新技術を受け入れる仕組みがあるか

生成AIのような新技術を取り入れるには、業務や人材、評価制度といった社内インフラの準備が不可欠です。 また、新しい技術を前向きに試そうとする姿勢や、それを歓迎する社内文化、変化を楽しむ人材がいることも、導入を前に進める大きな推進力となります。
制度や体制だけでなく、そうした「人と文化」の土壌があるかも、技術定着の成否を分ける要素の一つです。

例えば：

• 小さく試す場（PoC環境）と、成果を検証する制度
• ナレッジ共有やガバナンス整備

私たちもこれまで、PoCを一度きりの取り組みに終わらせないためには、こうした仕組みをプロジェクト設計段階から組み込むことが重要だと考えています。

（2）ユースケース起点で技術を当てはめる発想

導入がうまくいった企業の多くは、「何を実現したいか」が明確で、そのうえで技術を当てはめていました。 この発想は、自社の顧客業務を深く理解する必要がある私たちのような開発会社にとっても、非常に重要です。 ユースケース起点の設計が、結果としてデータ活用や継続的価値創出の連鎖を生み出します。

また、生成AIプロジェクトを実行に移すうえでは、「スコープ設計」、「関係者の巻き込み」、「失敗前提でのスピード感ある進行」など、具体的な進め方にも工夫が求められます。 この点については、私たちも以前から重視しており、生成AI導入を現場でどのように進めていくかという観点からまとめたブログを公開しています。
今回のセッション内容とも重なる点が多くありますので、ぜひあわせてご一読いただければと思います。

▶︎ 生成AI導入案件の30％が中止見込み、従来システム導入と大きく異なるアプローチ

導入戦略と具体的な進め方の両輪を意識することが、生成AI活用の成功確率を高める重要なポイントだと感じました。

5. まとめ：PoCを超えるには、文化と仕組みの設計から

今回のセッションを通じて改めて感じたのは、PoCで止まらない企業には「特別な技術力」ではなく、「業務にフォーカスした明確な目的」と 「小さく早く動く文化」、そして「評価と継続を支える仕組み」 があったということです。 PoCを繰り返すこと自体が目的化してしまうのではなく、「成果が出る仕組み」をどう作るかを設計することが、生成AIを本番活用へとつなげる鍵になります。

<今すぐ社内で検討できる3つのアクション>

• 導入目的を業務課題ベースで再定義する
  「誰の、どんな業務を、どう改善したいのか」を明確にする

• 小規模な横断チームで短期間の実験サイクルを始める
  少人数・短期間でまずは試す体制をつくる

• 定量的な効果測定の枠組みを導入し、継続判断を支える
  KPIや評価軸を事前に設定し、PoCから学びを次へ活かす

私たちアクセルユニバースでは、生成AIを活用した業務改善のPoC支援から本番導入・運用までを、ユースケース設計と組織課題の両面からサポートしています。
今後もこうした学びを活かし、お客様のビジネスに根ざした生成AI活用を支援してまいります。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

はじめに

小さな仕様変更のつもりが、大きな追加費用の話に発展してしまった。思い描いていたイメージと違う画面ができあがってきた。そんなすれ違いに、もどかしさを感じたことはありませんか？ 私たちも、「もっと柔軟に、一緒に考えられる開発のかたち」を模索してきました。
本記事では、変化に寄り添う開発パートナーでありたいという私たちの想いと、準委任契約に込めた想いをご紹介します。

一緒に考えるパートナーであるためには？

請負契約の現場でよく交わされる言葉

例1）機能追加の要望が出たとき
発注側（お客様）：「そういえば、検索結果にフィルターを追加できますよね？あれ、たしか最初の打ち合わせで話してたと思うんですが...」
開発側：「申し訳ありません。それはスコープ外ですね。要件定義書には含まれておりません。」
発注側：「えっ？最初から話してたと思うんですけど...。なんで反映されてないんですか？」
開発側：「正式な仕様としては合意されておらず、実装対象になっていないため、対応には追加費用が発生します。」

例2）軽微な修正のつもりで依頼したとき
発注側：「あと、ここの文言を少し変更して、ボタンの色も変えてもらえますか？デザインにちょっとこだわりたくて。」
開発側：「それは大幅な仕様変更です。デザインガイドラインからの逸脱になりますので、影響範囲を精査し、別途お見積りとなります。」
発注側：「えっ？ボタンの色を変えるだけですよ？そんなに大ごとですか？」
開発側：「スタイルガイドや他画面との整合性にも関わるため、慎重な対応が必要になります。」

例3）思っていたものと違う画面が出てきたとき
発注側：「あれ？この画面、ここのフローはもっと簡単になるはずじゃなかったでしたっけ？」
開発側：「そんな話、聞いてません、、、いただいた仕様に基づいて、その通りに作っています。」
発注側：「えぇ...たしかに言葉にはしてなかったかもしれないけど、流れ的に当然そうなると思ってました。」
開発側：「明文化されていない内容は基本的に対象外となります。」

システム開発の現場で、こんなやりとりに疲れた経験はありませんか？
こうした"すれ違い"とも言える冷たいコミュニケーションをせずに、開発することはできないのか？
そんな想いが私たちにはありました。

請負契約がもたらす"壁"

システム開発は、進めるうちに新たな課題や気づきが次々に生まれるものです。
しかし請負契約のもとでは、要件・納期・金額を最初に確定させるため、途中で仕様を変えるたびに、調整や費用の再検討が必要になります。

「最初に決めた通りに作る」ことと、「本当に必要なものを届ける」こと。
この間に生まれるズレに、私たちは違和感を抱くようになりました。
もっと自然な変化に柔軟に応え、最適なシステムをお客様と一緒に育てていきたい。
そんな想いが、大きくなっていきました。

お客様とチームでいたいから、準委任契約という選択を

システム開発を進める上で、「まずは請負契約で進めたい」というご要望をいただくことは少なくありません。ゴールや成果物を明確に決めてからスタートするスタイルは、安心感があり、プロジェクトの管理もしやすいと感じられるからだと思います。私たちも、請負契約ならではの安心感やメリットを十分に理解しています。

ただ、近年のシステム開発は、市場環境の変化が速くなり、ビジネスニーズやユーザー要求も常に変化しているため、プロジェクト開始後に要件やニーズが変わるケースがますます増えてきました。
最初に決めた仕様を守ること自体が目的になってしまい、「本当に今、必要なもの」とずれてしまう──そんなジレンマが起きる場面も、現場で見てきました。

そうした背景から、私たちが選んだのが 「準委任契約」 でした。

この契約形態では、あらかじめ決まった成果物に縛られることなく、必要な作業・工程そのものに対して対価が発生します。 つまり、変化に柔軟に対応できます。 請負契約のように、最初にすべてを決めてから始めるのではなく、都度、話し合いながら進めていくスタイルが特徴です。

とはいえ、ゴールへの責任感が揺らぐわけではありません。 私たちは、仕様変更や要件追加があった場合でも、プロジェクトの目的やお客様の本来のゴールを常に意識しながら対応を進めます。 単に作業をこなすのではなく、お客様と同じ目線で課題を解決することを目指して伴走します。

また、準委任契約では柔軟な対応が可能な一方で、プロジェクトの方向性がぶれないよう、定期的なチェックポイントや中間ゴールの設定を必ず行っています。
これにより、お客様と認識を合わせながら一歩ずつ進めることができ、進行中でも「今、正しい方向に向かっているか」を常に確認しながら開発を進められます。

準委任契約を導入することで、現場は大きく変わりました。 例えば、あるプロジェクトでは、当初要件が曖昧だったにもかかわらず、「まずは一緒に考えていきましょう」とスタートできました。
結果として、お客様自身も気づいていなかった課題やニーズを掘り起こすことができ、本当に必要とされるシステムにたどり着くことができました。 「仕様に含まれていないから...」ではなく、「まず相談する」ことができるようになり、 信頼を積み重ねながら、「共にゴールを創っていく」感覚が生まれました。

最近では、当初は「絶対に請負契約でないと進められない」というお声をいただいた企業様からも、最終的には「準委任契約でお願いします」と言われることが増えてきました。

準委任契約が生む、柔軟な開発と信頼の関係

準委任契約には、私たちが大切にする価値観と相性の良いポイントがたくさんあります。

柔軟に変化に対応できる

準委任契約の最大の強みは、「途中での変更」に柔軟に対応できることです。 要件の追加や修正も、都度話し合いながら、スピード感を持って反映できます。 「まず作ってみて、使ってみて、調整していく」という現代的な開発スタイルと相性が良く、お客様の"ひらめき"を最大限活かすことができます。

一緒にプロジェクトを育てる

請負契約だと、どうしても「発注者 vs 受注者」という関係になりがちです。 でも準委任契約では、同じチームの一員として、共通のゴールに向かって並走している感覚が生まれます。
実際に、あるお客様からは「仕様にないけど、相談したらすぐ一緒に考えてくれて先回りした提案ももらえた」という声もいただきました。

進捗が「見える化」されることで、同じ目線で前に進める

請負契約でも、進捗管理表や中間報告などを通じて、プロジェクトの状況を把握することは可能です。ただ、その多くは「成果物の完成に向けた節目ごとの報告」であり、日々の作業の流れや現場で起きている細かな変化までは伝わりづらいこともあります。

一方、準委任契約では、稼働状況や進捗を日報や定例ミーティングなどを通じてリアルタイムで共有する文化が根付きやすく、「どこに時間がかかっているか」「何に悩んでいるか」といった細かな情報まで、お互いが同じ目線で把握できる関係性が築かれます。

また、契約構造の違いも、プロジェクトへの関わり方に影響します。 請負契約では「成果物に対する対価」という性質上、ある程度お任せするスタンスになりやすい傾向があります。

準委任契約では「稼働時間に対する対価」であるため、お客様も「何に時間が使われているのか」「この進め方でよいか」など、日々の状況に対して自然と目を向けるようになります。 その結果、もしスケジュールが遅れそうな場合でも、「なぜそうなっているのか」「何を優先すべきか」といったことを事実に基づいてフラットに議論できるようになり、対立ではなく建設的な対話につながります。 進捗の"見える化"は、単なる報告のための手段ではなく、お互いの理解を深め、信頼関係を育てるプロセスそのものだと考えています。

信頼関係が深まる

何かを"お願い"するたびに費用の話になってしまうと、どうしても心理的な距離ができます。
でも準委任契約なら、「まず相談してみよう」と思っていただける関係を築くことができます。
お互いがフラットに意見を出し合えることで、自然と信頼関係が深まる。
それは、プロジェクト成功の大きな鍵になります。

エンジニアにとっても、作ることだけがゴールではなく、"お客様の課題を解決する"という本質的な価値に集中できるようになりました。

本当に寄り添える開発パートナーでありたい

私たちが準委任契約に込めているのは、「契約形態を変えること」そのものではありません。 大切なのは、"お客様の力になりたい"という想いを、どうやって実現するか。 そのためのひとつの手段として、私たちは準委任契約を選んでいます。

お客様のビジネスや現場に深く入り込み、ともに課題を見つけ、解決し、改善を重ねていく──。 そんな関係性こそが、私たちの理想です。 変化の多い時代だからこそ、契約にも柔軟性と信頼が求められると、私たちは感じています。

とはいえ、準委任契約がすべての案件に適しているわけではありません。

• 短期間・低コストで成果物を納品することが明確な案件
• スコープが完全に決まっていて、変更が発生しないことが前提の案件

こうしたケースでは、請負契約のほうが適していることもあります。 大事なのは、プロジェクトの性質に応じて、最適な契約形態を選ぶこと。 私たちは準委任契約を"万能の正解"とは捉えていません。 お客様にとっての最善策をご提案しております。

同じ方向を向き、変化を楽しみながら一緒にものづくりをしていく──
そんな出会いが生まれることを、心から願っています。

もし今、

• もっと柔軟に動いてくれる開発パートナーがほしい
• 仕様が固まっていなくても相談に乗ってほしい

そんな思いをお持ちでしたら、ぜひ一度お話ししてみませんか？契約形態は、あくまで関係づくりの"土台"です。 お客様とともに、信頼でつながるチームをつくっていけることを、私たちは何より大切にしています。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

はじめに：受託開発はつらい？

「いつかは自社サービスで自由に開発がしたい」
「受託開発って納期に追われてしんどそう」
「裁量もやりがいもなさそう...」

そんなふうに思っていませんか？
最近は、SNSやイベントでも"自社サービス開発の魅力"が語られる場面が多く、「エンジニアとしてカッコいいキャリア＝自社サービスに関わること」といったイメージが強まっているように感じます。

でも、実は受託開発にもさまざまなスタイルがあり、その中には"やりたいこと"を実現できる環境もあります。
今回は、私たちが行っている受託開発のスタイルを通じて、「受託開発ってこういう形もあるんだ」という視点をお届けしたいと思います。

自社サービスの魅力とその現実

自社サービスの魅力は多くの方が語っているとおりだと思います。

• 自分のアイデアで新しい機能を提案できる
• 社会の課題解決に直結したサービスを提供できる
• 長期的に同じプロダクトを育てることができる
• 開発だけでなく、ユーザー視点やマーケティングにも関わることができる

確かに、こうした環境はエンジニアにとってやりがいがあり、非常に魅力的です。 ですが、実際にそうした仕事を担えるのは一部のメンバーだけということも、忘れてはならない現実です。 大規模なサービスになるほど組織が細分化され、担当できるのはほんの一部の機能や領域。 企画や技術選定に関わるポジションに就くには、長い時間とチャンスを待つ必要があります。
つまり、自社サービスであっても「やりたいこと」にすぐに関わることができるとは限らないのです。

受託開発の一般的なイメージ

一方で、「受託開発」と聞くと、どんなイメージを持たれるでしょうか？
おそらく、多くの方が次のようなイメージを思い浮かべるかもしれません。

• 下請けのような立場で、決められた仕様をただ作るだけ
• 常に納期に追われて、気持ちの余裕がない
• 技術選定の余地がなく、最新技術も取り入れにくい

確かに、そういった開発現場も存在します。
しかし、それは受託開発の「一部」でしかありません。
実は、受託開発にも多様な形があり、企業ごとにスタイルが全く違うのです。

AUCの受託開発のスタイル

私たちアクセルユニバース（以下、AUC）は、一般的な分類では"受託開発会社"に入りますが、実態は少し違います。
お客様一社一社の課題に合わせたオーダーメイドのシステム開発を行っており、仕様書通りに作るだけの受託開発ではありません。 それぞれのプロジェクトごとに「何をどう作るべきか」を共に考え、ゼロから設計し、育てていくスタイルを大切にしています。

私たちが手がけているのは「受託開発」ではなく、お客様とともに創り上げる「プロジェクト」だと考えています。

(1)一次請け90％以上の体制

お客様と直接契約しており、「何をどう作るか？」という段階から相談されることがほとんどです。
要件がすでに固まったものを受け取って作るのではなく、企画段階からエンジニアが関わる。これが私たちのスタイルです。

また、要件定義から設計・開発・テスト・運用までを一貫して担当する体制の中では、技術力に加えて、業務理解やお客様とのコミュニケーション力も求められます。 お客様と直接やり取りしながら課題を解決していくため、開発だけでなくビジネス視点も問われる環境です。「部分的に関わるだけ」ではなく、プロジェクトの最初から最後まで、自分の手で価値をつくりあげていけるのが特長です。

(2)準委任契約が中心＝納期に追われない

受託開発というと「納期地獄」のイメージがあるかもしれませんが、弊社の案件の多くは準委任契約です。
「月○時間稼働」という形でお客様と伴走するスタイルのため、無理なスケジュールで開発を詰め込むようなことは、基本的にありません。

(3)常駐なし、フルリモートも可能

すべて自社内で開発を行っており、お客様先で常駐して業務をすることはありません。プロジェクトはリモートで進行できる体制を整えており、働き方の自由度も高いのが特徴です。

さらに、フルリモート・フルフレックス制度を導入しており、ライフスタイルに合わせた柔軟な働き方が可能です。 2024年の実績では、一人あたりの平均残業時間はわずか月3.6時間です。
また、社内では約50％のメンバーが首都圏外に在住しフルリモートで勤務しています。全国どこからでも活躍できる環境を実現しています。

首都圏に在住するメンバーは、出社・在宅の働き方を自身のスタイルに合わせて選択できる体制を整えています。 働きやすさを保ちつつも、プロジェクトを通じて成長していけるような環境づくりを心がけています。

(4)多種多様な業種・技術に関わることができる

お客様の業界は、小売業、総合商社、製造など多岐にわたります。
その分、要件も開発環境も異なるため、常に新しい技術やアーキテクチャに触れられるチャンスがあります。

• Next.js / Nuxt3
• AWS / Azure / GCP
• Python / TypeScript / Go / Kotlin など

「いろんな言語・フレームワークに挑戦したい」「インフラも設計してみたい」そんな方には、むしろ最適な環境です。

"やりたいこと"ができる理由

弊社の受託開発では、「仕様通りに作る」だけでは終わりません。
「そもそもどんなシステムが必要なのか」から一緒に考えるフェーズに関わることができるため、技術的な提案や意思決定の余地がたくさんあります。

一次請けかつ要件定義から一気通貫で関わるスタイルだからこそ、お客様と対話しながら本質的な課題を見極め、技術の選定やアプローチの設計に関わることができます。

• お客様の業務を理解し、課題を言語化する
• システム構成や技術選定を提案する
• 開発・運用フローそのものを再設計する

こうした工程に関わることで、単なる"つくる人"ではなく、"共に考えるパートナー"として仕事を進めることができます。

幅広い業種や技術領域のプロジェクトに関わる中で、自ら学び、吸収する姿勢を大切にすることで、スキルの幅を広げるチャンスが豊富にあります。

• 「将来はテックリードを目指したい」
• 「幅広い技術を習得して、選ばれるエンジニアになりたい」
• 「現場を理解し、技術を武器に、お客様とチームをリードできるプロジェクトマネージャーになりたい」

そう思っている方には、まさに"やりたいこと"に出会えるフィールドです。

まとめ：選択肢を広げてみませんか？

自社サービスが魅力的なのは間違いありません。
ですが、自社サービスだけがやりがいのある開発ではないということも、少し感じていただけたでしょうか？

受託開発の中にも、「企画から関わる」「提案できる」「技術に挑戦できる」環境は確かに存在します。
私たちAUCは、そんな開発スタイルを実現している会社のひとつです。

転職やキャリアの選択肢を考えるとき、「受託開発＝つらい」という思い込みを、ほんの少し疑ってみてください。
そうすることで、自分にとって本当にフィットする働き方が見えてくるかもしれません。

▶ 気になる方はぜひこちらもチェックしてみてください！

• 社員インタビュー
  「自分らしく成長する」を叶えてくれる場所　大迫 拓馬 / ソフトウェアエンジニア

  未知への一歩から始まったAUCで描く 成長ストーリー　長森 礼音 / SREエンジニア

• 採用ページ
  新卒採用/ 中途採用/ 長期有給インターンシップ

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse