
目次
DXやAI活用が進む中で、ビジネスアイディアの実現可能性を検証する「PoC」の重要性が高まっています。しかし現実には、PoCを実施しても本番導入につながらない・成果が出ないケースも珍しくありません。
IT業界の調査会社「ガートナー」のレポートによれば「AIに適したデータ基盤を持たないAIプロジェクトの60%は、2026年末までに破棄される」と予測されています 。実際、2025年末時点で生成AIプロジェクトの50%以上がPoC後に放棄されたという報告もあります。
この数字が示すように、PoCは「やること」自体に意味があるのではなく、正しく設計・評価・支援されて初めて成果につながります。本記事では、PoCの正しい意味と活用方法、よくある失敗とその回避策、PoCを成功に導くITコンサルティングの役割と進め方を解説します。
GeNEEは、新規事業・新サービスの立ち上げにおけるMVP開発・PoC支援の実績を持つITコンサルティング会社です。「検証を始めたいが何から始めればよいかわからない」「アイデアをPoCに落とし込む段階から伴走してほしい」という相談からお受けしています。まずは支援実績をご覧ください。
⇒GeNEEのDX・新規事業支援の実績を見る
PoCとは?その意味と役割
支援_アイキャッチ-800x600.webp)
新規事業の立ち上げやDX推進、AI導入といった文脈でよく耳にする「PoC」。しかし、言葉だけが独り歩きし、その本質や活用意義が正しく理解されていないケースも少なくありません。
PoCは単なる実験や試作とは違い、ビジネス上の意思決定を下すための重要なプロセスです。ここでは、PoCの定義や他との違い、なぜ今PoCが求められるのかについて、順を追って整理していきましょう。
PoCの定義
PoC(ポック)とは「Proof of Concept」の略で、日本語では「概念実証」と訳されます。あるアイディアや技術が実現可能かどうかを、事前に検証する工程として用いられます。
PoCの目的
| 目的 | 内容 |
|---|---|
| 技術的な検証 | 実装予定の技術が想定どおりに動作するか |
| ビジネス的な仮説の検証 | 提供価値やユーザー需要が見込めるか |
| リスクの洗い出しと軽減 | 初期段階でリスク要因を把握・対応するため |
| 経営判断の材料提供 | 事業化に進むべきか否かを判断するための根拠づくり |
PoCは、単に動くモノを作ることが目的ではありません。将来的な本格導入や事業化を見据えた検証活動であり、関係者の意思決定を支える役割を担っています。
実証実験・MVP開発との違い
PoCと混同されやすい言葉に「実証実験」「MVP開発」があります。それぞれ似ているようで、意味と役割は明確に異なります。
| 項目 | PoC | 実証実験 | MVP開発 |
|---|---|---|---|
| 目的 | 概念や仮説の検証 | 現場環境での実運用テスト | 最小機能での市場検証 |
| 成果物 | 結論や評価結果 | 実運用に近い検証レポート | リリース可能なプロダクト |
| 主な対象 | 技術・ビジネス両面 | 実環境での性能・運用性 | 初期ユーザーの反応・事業性 |
| リリースまでのフェーズ | 初期 | 中期 | 後期 |
PoCは「やるべきか・できるか」を判断するための活動で、実証実験やMVP開発はその後の段階に位置します。目的ごとにフェーズを正しく理解して設計することが、PoCの成果を最大化するうえで重要といえるでしょう。
関連記事:PoC・プロトタイプ・MVP開発の違いとは?3つの検証手法の目的・使い分けを徹底解説
プロトタイプとの違い
ちなみに「プロトタイプ」は特定のステップを指すものではなく、PoCや実証実験の過程で必要に応じて作成される試作物です。たとえばPoCの中で「このUIで操作できるか」を確かめたいときに簡易的なプロトタイプを作る、といった使われ方をします。あくまで検証を補助するための手段であり、プロトタイプを作ること自体がゴールではない点に注意が必要です。
PoCが必要とされる背景
PoCという手法が注目されるようになった背景には、企業を取り巻く技術環境とビジネス環境の急激な変化があります。
主要な要因
- DX(デジタルトランスフォーメーション)の加速
レガシーな業務プロセスを刷新するにあたり、段階的な導入と仮説検証が不可欠。いきなり本番開発に踏み切るのは、経営リスクが大きすぎるという判断 - AI・IoTなど新技術の普及
高度な技術ほど導入効果が読みづらく、技術的な妥当性や有用性の検証が必要。AIを使った需要予測、画像認識、レコメンドなどは典型的なPoC対象 - 企業の変化対応力への期待
市場や顧客ニーズの変化が早まるなか、PoCを活用することで「試してから本格化する」柔軟な開発体制を選ぶ企業が増加
上記背景から、PoCは単なる技術テストではなく、経営戦略の一部として活用されるフェーズに入っています。適切な設計と評価ができれば、PoCは新規事業や業務改革の成功確率を高める強力な武器になるでしょう。
なぜPoCは失敗するのか?50%以上がPoC後に破棄される現実

冒頭でも触れたとおり、ガートナーの調査では2025年末時点で生成AIプロジェクトの50%以上がPoC後に放棄されたことが報告されています。
参考: Why 50% of GenAI Projects Fail — And How to Beat the Odds
なぜこれほど多くのPoCが成果につながらないのか。その背景には、単なる技術的な問題ではなく、進め方や設計における構造的な問題があります。
PoCが失敗する3つのパターン
PoCは、導入前にリスクを抑えつつ新しい技術やサービスの有効性を確かめる重要な手段です。しかし実際には、PoCが成果につながらないケースが後を絶ちません。「アイディアは良かったのに形にならない」「社内では好評だったが顧客の反応が鈍い」そういった声が現場から多く聞かれます。
ここでは、PoCが失敗する典型的な3つのパターンを取り上げ、それぞれの構造的な問題と回避のヒントを見ていきましょう。
PoCが目的化してしまう
本来は「仮説を検証する」ために実施するPoCですが、プロジェクトが進むにつれ、PoCを実施すること自体が目的になってしまうことがあります。こうなると、以下のような問題が発生します。
- PoCを完了することがゴールとなり、評価や学びが残らない
- 「PoC実施済み」の実績だけが社内報告の目的となる
- 成果を次フェーズへつなげる設計が欠落している
特に、大企業や官公庁などでよく見られるのが、PoCを通じて部門内の予算を消化するという構図です。こうした状態は「PoC疲れ」「PoC貧乏」とも呼ばれ、いくら検証を重ねても事業が前に進まない悪循環に陥りやすくなります。
評価基準やKPIが曖昧なまま始めてしまう
PoCの実施で多い失敗パターンは、事前に評価軸が定まっていない状態でスタートしてしまうことです。
以下は、PoCの評価においてよくありがちな課題と、その結果生じる問題です。
| 課題 | 起きやすい問題 |
|---|---|
| KPIが設定されていない | 成果が見えず、社内報告が困難になる |
| 定量データが不足している | 感覚ベースの評価となり、判断が属人的になる |
| 評価者が決まっていない | 成果を誰が判断するかが不明瞭になり、次に進めない |
たとえば、ある企業でAIによる需要予測モデルのPoCを実施したものの「予測がどれだけ当たれば成功か」という基準を明確にしていなかったため、開発チームとビジネス部門で評価が大きく乖離してしまいました。
PoCに入る前の段階で、KPIや判断基準、評価者を明確に決めることが、次のアクションにつなげるためのカギとなります。
関連記事:需要予測システム及び予測モデルの構築とポイントについて解説
技術検証に偏り、ビジネス成果に結びつかない
PoCが失敗する原因のなかでも深刻なのが、技術検証にばかり焦点が当たり、ビジネス側の視点が抜け落ちてしまうパターンです。
- 新技術(AI・IoT・XRなど)をPoCの主眼においてしまい「何の課題を解決するための技術か」が曖昧になる
- 開発担当者と現場ユーザーのコミュニケーションが乏しく、利用シーンが具体化されない
- 結果として、社内デモでは高評価でも、顧客には使われないというミスマッチが起きる
「使えるかどうか」だけを検証して「使いたいかどうか」「使って何が変わるか」を置き去りにしてしまっている状態です。PoCは、技術・業務・顧客価値の3点をバランスよく検証する視点がなければ、成果には結びつきません。
ITコンサルによるPoC支援が成功を左右する理由

PoCの成功を左右するのは、検証の質の高さです。そのために、ビジネス・技術・現場の3つの視点を客観的に理解し、適切に設計・調整・評価できるパートナーがいると成功確率は高まります。
PoCを単発の「実験」で終わらせるのではなく、戦略的なステップとして機能させるため、ITコンサルが果たす役割は非常に大きいといえるでしょう。ここでは PoCにおけるITコンサルの具体的な貢献ポイントを3つ解説します。
検証設計・仮説構築・ROI評価の支援
PoCを意義あるものにするには、PoC設計がもっとも重要です。ITコンサルは、PoCに入る前に以下の支援を行います。
| 項目 | ITコンサルが担う支援内容 |
|---|---|
| 仮説構築 | どんな価値を、誰に、どのように提供するかを明確化 |
| 検証設計 | 成功・失敗の基準となるKPIや前提条件の整理 |
| ROI試算 | PoC実施によって得られる成果とコストのバランスを評価 |
たとえば、AIを用いた業務自動化のPoCであれば、「処理時間がどれだけ短縮されるか」「削減できる人件費はどの程度か」など、具体的な数字に基づく仮説とKPIの設定が必要です。この初期設計が曖昧だと、PoCが何を証明したのかが不明瞭になり、次の判断に進めなくなってしまいます。ITコンサルは「仮説を数字で語れる状態」にしてPoCの価値を明確化します。
社内調整・経営層説得など意思決定プロセスの支援
PoCの内容がいくら優れていても、組織が前に進めなければ実行には至りません。ここでITコンサルが果たすのは、以下のような、いわば「組織内の通訳(トランスレーター)」としての役割です。
- 技術チームと業務部門のギャップを埋める
- ステークホルダー間の合意形成を促進する
- 経営層向けにPoCの意義やリターンを言語化する
たとえば、現場から上がってきたPoC案に対し、経営層は「それで売上がどれだけ伸びるのか」「投資対効果はあるのか」といった視点で判断します。この「現場」と「経営層」の橋渡しができるかどうかが、PoCの実現可否を分ける分岐点になるでしょう。
ITコンサルは技術の可能性を理解しつつ、経営層を説得するロジック構築や社内プレゼン資料の設計支援まで担うことができます。
PoCから本番導入へつなげる戦略設計
PoCだけで終わるプロジェクトが多いのは、その先の道筋が描けていないからです。重要なのは、その成果をどう本番導入、業務変革に落とし込むかです。
| フェーズ | ITコンサルが担う支援内容 |
|---|---|
| PoC | 仮説・KPI設計、Go/No-Go判断基準の設定 |
| MVP構築 | 本番移行の要件定義、開発パートナーの選定支援 |
| 機能拡張 | 現場フィードバックの収集・分析、改善優先度の整理 |
| 全社展開 | スケール戦略の設計、ROI検証と経営報告 |
PoCと本番導入は別プロジェクトとして分断されがちですが、本来は連続した戦略であるべきです。ITコンサルはロードマップ作成を担い、PoCの成果をビジネスインパクトに変えるための戦略設計を支援します。
成功するPoCの進め方|4つのステップと実践例

PoCを「実施して終わり」にしないためには、各ステップで正しい設計と判断が求められます。以下の4つのステップが、現場で成果を上げているPoCプロジェクトに共通する進め方です。
STEP1:目的・仮説の明確化とKPI設定
PoCで最初に行うべきは、「このPoCで何を明らかにするか」を言語化することです。目的と仮説が曖昧なまま進めると、PoCの評価が属人的になり、次のアクションに進めなくなります。
以下のケースは、受注業務に関するPoCです。
| 設定項目 | 内容の例 |
|---|---|
| 解決したい課題 | 受注業務の対応漏れを削減したい |
| 検証する仮説 | AIチャットボット導入で問い合わせ対応の60%を自動化できる |
| 成功基準(KPI) | 1日あたりの対応件数が1,000件増加 |
| Go/No-Go判断 | KPIを達成した場合はMVP構築へ、未達の場合は仮説を修正して再検証 |
とくに重要なのが「Go/No-Go判断」の事前設定です。KPIに届かなかった場合に「失敗」として終わらせるのか、「仮説を修正して再検証する」のか、「別の手段を検討する」のかを、関係者全員で合意しておくことが重要です。なぜなら、この合意がないと結果が出た後に「誰が・何をもって判断するか」が曖昧になったまま終わってしまうからです。
STEP2:実施計画・PoC開発のスモールスタート
PoCは「最小範囲で最速で仮説を検証する」が基本です。最初から完璧なものを作ろうとすると、時間もコストもかかりすぎPoC本来のメリットが失われます。以下のポイントを意識してPoC計画を立てます。
- 対象範囲を絞り込む(例:一部業務のみ、特定部署のみ)
- 必要最小限の機能に限定する(MVP的アプローチ)
- 短期間で実行できる計画にする(1〜2ヶ月など)
PoCの価値は「完璧さ」ではなく、「仮説の早期検証」にあります。たとえば、製造業において不良品検知のAIを導入するPoCであれば、全ラインに適用するのではなく、まず1つの製造工程だけに限定して始めるのが賢明でしょう。
STEP3:結果の定量評価と判断基準の明確化
PoCを終えたあとは、必ず「成果をどう評価するか」「次に進むべきかどうか」を明確に判断するプロセスが必要です。
そのために必要なのが、定量評価と、あらかじめ合意された判断基準です。
| 評価軸 | 確認内容 |
|---|---|
| KPI達成状況 | 成功基準をクリアしたか |
| ROI(費用対効果) | 想定コストに対してどれほどの効果が得られたか |
| 残存リスク | 本番導入時に想定される課題・障壁は何か |
| 次のアクション | Go(MVP構築へ)/ No-Go(中止)/ Pivot(仮説修正して再検証) |
たとえば、PoCで月間業務時間の20%削減を目指していた場合に、実際には10%しか削減できなかったとします。これを「失敗」と見るのではなく、「本番導入前に想定とのギャップが見えたこと」を価値と捉えるべきです。
重要なのは、定量的な評価が可能な仕組みを用意しておくことと、それを使って冷静に判断できる体制が整っていることです。
STEP4:本開発・導入への移行設計
PoCで得られた知見や検証結果をもとに、次のフェーズである本開発・本番導入にどうつなげるかを設計するのが、最後のステップです。
PoCと本番開発は別物ですが、連続性を持った計画でないと、検証結果が無駄になるリスクがあります。全体ロードマップを引かずにPoCを終えてしまうと、結果は報告書を提出して終わってしまいます。実際、PoCと本番導入の間に意思決定の空白が生まれ、プロジェクトが宙に浮くケースは珍しくありません。
そのためにも以下のポイントを押さえて計画を立てておきましょう。
- PoCの成果をどのように事業・業務に反映するか
- システム要件やユーザー導線を再設計できるか
- 定着・展開のための教育・運用体制を準備できるか
PoC終了後すぐに開発フェーズに移行できるよう、導入の障壁・コスト・体制をあらかじめ見積もっておくことが、PoCを「成果」へと変えるカギといえます。
PoC支援サービスを選ぶ際のポイント

PoCの成否は、アイディアや技術そのものよりも、パートナー選びにかかっていると言っても過言ではありません。支援会社の視点やスコープによって、プロジェクトの出口は大きく変わってくるからです。
PoC支援を依頼するときには、単に開発力のある会社を選ぶのではなく、事業と検証をつなぐ「橋渡し役」として機能するかどうかを見極める必要があります。ここでは、ITコンサルティングの立場から、支援パートナーを選定する際に注視すべき3つの視点を整理しましょう。
支援範囲は「設計・検証・導入」まで含まれているか
PoCを成功させるには、前後のフェーズも含めて支援できるパートナーであることが重要です。検証だけを任せてしまうと、次のステップでつまずくリスクが高くなります。
支援範囲を見極める際の観点
| フェーズ | 必要な支援内容 | チェックポイント |
|---|---|---|
| 設計前 | 仮説構築・KPI設定 | ビジネス背景を踏まえた提案があるか |
| 検証中 | 実施・評価・改善 | 技術面だけでなく業務面も評価しているか |
| 導入後 | 展開設計・実装支援 | 本番移行の戦略や体制構築が含まれているか |
たとえば、PoCの成果を活かした本開発が別プロジェクト扱いになる場合、連携が途切れやすくなります。そうならないよう、一連の流れを見据えて伴走できる体制かどうかを確認することが大切です。
ITコンサルティング会社に求められる支援領域や選定ポイントについてもっと知りたい方はこちらもご覧ください。
関連記事:ITコンサルティング企業とは?仕事内容・依頼できる支援内容を徹底解説
技術力だけでなく、ビジネス視点を持っているか
PoCの成功には、技術の検証だけでなく、「なぜこの技術を使うのか」「どんな事業成果に結びつくのか」を語れる力が欠かせません。以下のような視点を持っているかをチェックしましょう。
- 課題や仮説が、顧客価値や業務改善とどう関係しているかを理解しているか
- 検証結果が、売上やコスト削減といった経営指標にどう影響するかを説明できるか
- 技術導入の先に、どのようなビジネス展開があり得るかを描けているか
たとえば「AIモデルの精度が90%に達した」という報告だけでは不十分です。どのくらいの業務が効率化され、どの部署のどんな業務負荷が減るのかまで落とし込めて初めて、PoCは事業にとって意味のある成果になります。
テクノロジーとビジネスの両面に通じていることが、支援会社の選定基準として極めて重要です。
スケール戦略や運用支援まで設計できるか
PoCの成果を一部で終わらせず、全社的に展開し、継続的に活用していく設計力があるかどうかも、ITコンサルティング会社を見極めるうえで大きなポイントです。確認したい観点は、以下に記載しています。
- 成果をどのように横展開できるか、スケール戦略を描いているか
- 本番稼働後の運用や保守体制について、継続的な関与が可能か
- 組織内での定着を促す、トレーニングやチェンジマネジメントの設計が含まれているか
たとえば、最初のPoCで業務改善の効果が見られたとしても、他部署に横展開するプロセスが設計されていなければ、プロジェクトはスケールせずに止まってしまいます。結果として、投資に対する成果が限定的になってしまうのです。
PoCはスタートラインにすぎません。「その後の活用フェーズ」まで見据えた支援ができるかどうかが、真に価値あるパートナー選びのカギになります。
PoC支援にかかる費用感は?

PoC支援の費用相場
PoC支援にかかる費用は、自社で実施するか外注するかによって大きく異なります。
| 実施形態 | 費用相場 |
|---|---|
| 自社で実施 | 150万〜400万円程度 |
| 外注(PoCのみ) | 300万〜500万円程度 |
| 外注(本開発・サポート含む) | 400万〜900万円程度 |
もちろん、費用はプロジェクト期間が延びれば延びるほど増大するので注意が必要です。
PoCのフェーズ別のコスト内訳
PoCは大きく「計画フェーズ」と「実証フェーズ」の2段階で構成され、それぞれに費用が発生します。
| フェーズ | 自社実施 | 外注 | 主なコスト項目 |
|---|---|---|---|
| 計画フェーズ | 50〜200万円 | 150〜250万円 | 人件費・外注費・打ち合わせ費・研修費 |
| 実証フェーズ | 50〜200万円 | 150〜250万円 | 上記+機器購入・環境構築費・施設費 |
費用を左右する4つの要因
PoCの費用は一律ではなく、以下の4つの要因によって大きく変動します。
- 検証範囲の広さ:対象業務・拠点・ユーザー数が多いほど費用は増加する
- 技術の複雑さ:AI・IoTなど専門性の高い技術を扱う場合はコストが上がる
- 支援範囲:仮説設計のみか、実装・評価・本番移行まで含むかで大きく異なる
- 期間:本開発や運用サポートまで依頼する場合、期間が長くなるほどコストが膨らむ
補助金・助成金を活用すれば費用負担を抑えられる
PoCの実施には一定のコストがかかりますが、要件を満たせば公的な補助金・助成金を活用することで費用負担を軽減できます。
| 補助金・助成金 | 概要 | 補助率・上限額 |
|---|---|---|
| IT導入補助金 | ITツール導入による業務効率化・DX推進が対象 | 補助率1/2以内、上限450万円 |
| ものづくり補助金 | 革新的な生産性向上のための設備投資等が対象 | 補助率1/2〜2/3、上限750万〜1億円(規模による) |
| 小規模事業者持続化補助金 | 小規模事業者の販路開拓・事業継続が対象 | 補助率2/3、上限50万円(通常枠) |
各補助金は申請要件・対象範囲・募集時期が異なります。最新の募集要項をかならず確認のうえ、対象となるか事前に確認することをおすすめします。
FAQ(よくある質問)
Q PoCの費用はどのくらいかかりますか?
自社実施で150万〜400万円、外注では300万〜500万円程度が目安ですが、検証範囲や支援範囲によって大きく異なるため、まずは要件を共有したうえで見積もりを取ることをおすすめします。
Q PoCはどのくらいの期間かかりますか?
スモールスタートであれば1〜3ヶ月、複数業務にまたがる場合は3〜6ヶ月が目安です。
Q PoCと実証実験の違いは何ですか?
PoCは「できるか・やるべきか」を判断する初期検証であり、実証実験はその結果を踏まえて本番導入直前に実環境での動作を確認するプロセスです。
Q PoCが成功したら次は何をすればよいですか?
MVP構築→機能拡張→全社展開という3段階で本番移行を進めるのが成功率を高めます。
Q PoCは外注と内製、どちらがよいですか?
KPI設計・経営層への説得・本番移行設計まで含めると、専門パートナーへの外注が成功率を大きく高めます。
GeNEEのMVP開発支援が選ばれる理由

PoCを成功に導き、事業成果へとつなげるには、仮説設計から本番移行まで一貫して伴走できるパートナーの存在が不可欠です。IT部門を抱えていてPoCの知見がある企業ならよいですが、多くの企業が自力でPoCを成功させるにはリソースやスピードの点で不利でしょう。GeNEEの「MVP開発支援」は、まさにその役割を担えるサービスです。
GeNEEが選ばれる理由
- PoCを「事業成長につながるプロセス」として設計:GeNEEの強みは、PoCを「検証だけの箱」に閉じ込めず、仮説構築・検証の反復作業を高速で回しながら、本開発・スケール戦略へと自然につなげていく流れを構築している点にあります
- 検証設計から本番移行まで一貫支援:課題抽出・企画からMVP開発・価値検証、本開発、スケールまでを一貫してサポート。UI/UX設計、データ活用、AI開発、アプリ構築、セキュリティ対策といった領域までワンストップでカバーします
- 300件以上のMVP・新サービス開発実績:スタートアップから大手事業会社のDX推進まで、多種多様なプロジェクトに対応した豊富な実績があります
PoCを「実験」で終わらせず、事業成長につなげたいと考える企業にとって、GeNEEは実務的かつ信頼できる選択肢です。
まとめ:PoCは「検証」ではなく「成果に導く設計」こそが成功のカギ

PoCは、本来「成功するかどうかを確かめる場」ではなく、事業としての実現性を見極め、成果につなげるための設計プロセスです。ただ技術を試すだけでは不十分で、明確な目的、評価基準、戦略的な意図がなければ、PoCの結果はビジネスに還元されません。
その中で、ITコンサルティングの役割は極めて重要です。仮説の設計からROI評価、社内の意思決定支援、本番導入までの移行戦略に至るまで、ビジネスとテクノロジーの橋渡しを担う存在がいることで、PoCは初めて意味を持つでしょう。
検証を成果につなげる視点を持つことが、PoCを「やって終わり」から「未来を切り拓く投資」へと変えるカギになります。

-
GeNEEの開発実績製造業、小売業、流通業、印刷・出版業など、業界別のベストプラクティスを保持しています。
弊社の開発実績にご関心のある方はこちら一部公開可能な事例を掲載中
-
GeNEEの事業内容
現在、6事業を展開しております。お客様の状況や目標に合わせて、FITするソリューションを提供いたします
6事業の詳細はこちら
-
弊社主催セミナー
最大月に1回のセミナーを開催しております。毎回30名以上の方にご出席いただいております。
テック系のセミナーにご興味ある方はこちら月に1回テック系セミナー開催中
-
オウンドメディア
GeNEE は技術に関する情報発信を積極的に行っています。 弊社のお客様だけでなく、業界全体に貢献のできる品質の高い情報提供を心掛けています。
最先端テクノロジーの情報配信中
-
GeNEEの会社概要
ビジネスxテクノロジーxデザインの三位一体で、お客様の課題を解決する独自のアプローチをご紹介
創業から15年の実績
-
GeNEEの5つの特徴
なぜGeNEEはコンサルティングやシステム開発のプロジェクト成功率が高いのか。
競合他社との違いや優位性についてまとめております。GeNEEの5つの特徴
-
GeNEEへのお問い合わせ
DX/ITコンサルティングのご依頼やシステム開発・スマホアプリ開発のご相談はこちらのフォームからお願いいたします
お問い合わせフォームはこちら
-
GeNEEの資料をダウンロード
ご希望の会社様にGeNEEのパンフレットをお送りしております。
ITベンダーとの繋がりをお探しの方は是非お気軽にリクエストください。資料ダウンロードはこちら
代表取締役
<略歴>
東京工業大学環境社会理工学院、慶応義塾大学大学院・慶応義塾大学ビジネススクールMBA(経営学修士取得)卒業。
京都大学経営管理教育部博士課程単位取得退学。国内最大手IT企業の株式会社NTTデータなどでエンタープライズ(大手法人)領域の事業開発・事業企画等に従事。
スタンフォード大学への海外研修を経て、株式会社GeNEEの代表取締役に就任。
<資格>
基本情報技術者試験、応用情報技術者試験、MBA(経営学修士)、MOT(技術経営修士)等
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>