ヒアリング
価値を発見する
その仕事を最も深く理解している人に、直接話を聞きます。具体的な判断や例外への対応をたどり、本人にとって当たり前になっている専門知識、判断基準、強みを引き出します。誰にとって、どのような価値になり得るかを整理します。
その理由をたどると、仕事を支える知性が見えてくる。
デジタル化されていないから、遅れている。
紙をなくせば、仕事は効率的になる。
私たちも、かつてはそう考えていました。
しかし、現場の仕事を知るほどに、話はそれほど単純ではないことに気づきました。
なぜ、そのやり方が残っているのか。
何を守るために、そのひと手間が必要なのか。
私たちのものづくりの原点には、その理由を知ろうとした経験があります。
ここでは、私たちが大切にしている考え方と、それを実際の仕事としてどのように進めているかをご紹介します。
「紙を入力フォームに置き換え、業務を効率化しました。」
そう説明されるシステムの横で、現場の人たちが紙のメモを申し送り、仕事をつないでいる。私たちは、そんな場面を何度も見てきました。
入力欄には収まらない事情。
決められた手順では扱えない例外。
次の担当者に、どうしても伝えておかなければならないこと。
システムが拾いきれなかったものを、現場の人たちが理解し、補っていたのです。
紙をなくすなら、まず、紙が担っていた仕事を理解する必要がある。
そう考えて話を聞くうちに、私たちの関心は、紙に書かれた情報から、「なぜ、それを書き残す必要があると判断したのか」へと向かうようになりました。
なぜ、この情報だけは伝えておくのか。
なぜ、今回はいつもの手順を変えるのか。
なぜ、この段階で確認しておくのか。
一つひとつの理由を聞いていくと、その人が何を見て、何を予測し、何を大切にしているのかが見えてきます。
一枚のメモの背景には、仕事の流れへの深い理解がある。
さりげない申し送りの中には、問題が起きる前に気づく判断がある。
私たちが紙を通じて見つけたのは、仕事を成立させている人の知性でした。
このことに気づいてから、自然と問いが変わりました。
本当に価値ある知性は、どこにあるのか。
この仕事を、最も深く理解しているのは誰なのか。
事業の全体像を捉えている経営者。
複雑な条件から答えを導く専門家。
わずかな違いから、次に起きることを見抜く現場の担当者。
その仕事を深く理解する人に出会い、話を聞くことで、つくるべきものの輪郭が見えてくるようになりました。
プロダクトづくりで、私たちが大切にしているのは、誰に話を聞くかです。
何を実現するべきか。
どの条件を見落としてはいけないか。
何をもって、よい結果だと判断するか。
その解像度が高い人ほど、つくるべきものを具体的に教えてくれます。
ただし、優れた判断のすべてが、最初から言葉になっているわけではありません。本人にとって当たり前すぎて、説明されていないこともあります。
だから私たちは、具体的な場面を聞きます。
「そのとき、何を見ていたのですか」
「なぜ、そちらを選んだのですか」
「条件が変わったら、判断も変わりますか」
答えを聞き、背景を確かめ、理解したことを形にして、もう一度見てもらう。
その対話を通して、経験の中にある判断の根拠や、仕事を支える考え方を捉えていきます。
ある人が、何年もの経験を通じて身につけた見方。
複雑な状況の中から、重要な条件を選び取る力。
まだ表面化していない問題に気づく判断。
その価値を、より多くの人が仕事の中で使えるようにする。
私たちは、そこにITプロダクトの本質的な価値があると考えています。
たとえば、経験豊富な人が最初に確かめることを、必要な場面で尋ねてくれる。
条件に応じて選択肢を整理し、判断の理由まで伝えてくれる。
見落としやすい例外に気づき、次に確認すべきことを示してくれる。
そうした体験として、知性をプロダクトに実装していきます。
実際に使ってもらい、元の判断が持っていた意味を捉えられているか、利用する人の仕事に役立っているかを確かめる。そこで見つかった違いを、次の改善につなげます。
誰の、どんな知性を届けるか。
そして、その価値を、使う人が受け取れる形にできるか。
それが、プロダクトの価値を左右すると考えています。
人の判断には、状況に応じた問いかけや、言葉でしか表せない事情が含まれています。
AIを活用することで、そうした背景を対話の中で受け取り、必要な情報や仕組みと組み合わせながら、一人ひとりの状況に応じた支援を設計できます。
その可能性を生かすためにも、最初に必要なのは、価値ある知性を見つけ、深く理解することです。
何を尋ねるべきか。
何を根拠に考えるべきか。
どこで人の判断を必要とするか。
私たちは、それらをプロダクトの振る舞いとして設計し、使われる場面で確かめていきます。
紙に残されていた理由を知ろうとしたことが、仕事を支える知性を見つける出発点になりました。
その知性を持つ人に話を聞き、理解を深め、繰り返し使える形にする。
そして、必要とする人へ届ける。
これが、AI Orchestrationの仕事です。
だから私たちは、「コンサルティング」を独立した仕事として切り分けません。
現場や専門家に深く話を聞き、言葉になっていない判断基準を引き出すこと。
誰が、なぜ、いくらで買うのかという事業と販売の仮説を組み立てること。
何をつくるべきで、何をつくるべきでないかを一緒に見極めること。
世の中では、それらを「コンサルティング」と呼び、開発とは別のカテゴリーや別料金のサービスとして切り分けることがあります。
しかし私たちにとっては、案件を引き受ける限り、やるのが当然のことです。
知性のありかも、届ける相手も、対価を払う理由も掘り下げないまま、言われた通りの機能だけをつくっても、現場や市場で本当に使われるプロダクトにはならないからです。
新しいAIプロダクトの事業化でも、既存システムのMCP/API接続でも、認証や公開申請の支援でも。
事業の前提から問い直し、価値が届くところまで設計・実装するプロセスは、私たちのすべての仕事に含まれています。
構想と実装を切り離さず、すべての仕事で4つの工程をつなぐ。
自社製品でも、パートナーとの共同開発でも、個別の技術支援でも、私たちはこの4つの工程を土台に仕事を進めます。発見した価値を、購入する理由と実際に使える製品につなげていきます。
価値を発見する
その仕事を最も深く理解している人に、直接話を聞きます。具体的な判断や例外への対応をたどり、本人にとって当たり前になっている専門知識、判断基準、強みを引き出します。誰にとって、どのような価値になり得るかを整理します。
価値を市場につなぐ
誰が、なぜ、いくらで買うのか。発見した強みを顧客の購買理由に翻訳し、価格、販売経路、提案方法の仮説をつくります。顧客との対話や提案、必要に応じた試作を通じて、その仮説を確かめます。
価値を再現可能にする
販売戦略から逆算し、専門家の知性を効果的に届けるプロダクトを設計します。利用者への問いかけ、判断に必要な情報、AIと人の役割、例外時の対応を具体化し、必要な機能と品質の合格基準を定めます。
約束した価値を、使える品質に仕上げる
AIを最大限活用して実装と改善を進めます。人が要求の充足、不具合、例外条件、実用性を検証し、合意した要件と受け入れ基準に対する完成責任を担います。顧客に約束した価値が、実際の利用場面で届くかまで確かめます。
販売・利用実績を、次のヒアリングと販売戦略へ。
購入を決めた理由、見送った理由、使って初めて分かった課題を共有し、価値の理解、販売方法、設計・実装を更新していきます。
専門家の優れた知性も、顧客が必要とする形で届いて初めて、製品としての価値になります。
どの場面で使われるのか。何が改善されれば、対価を払う理由になるのか。誰が購入を決め、どのような提案なら価値を理解できるのか。
私たちは、これらの問いをAI設計の前に置きます。その答えによって、必要な機能、利用体験、提供方式、求める品質が変わるからです。
販売仮説は、対話や試作、提案を通じて確かめます。新しい事実が分かれば、前提に戻って見直します。
AIは、実装と改善の可能性を広げます。その力を活用しながら、何をもって完成とするかは、人が判断します。
ヒアリングで発見した価値が、販売戦略で定めた顧客に、設計した製品を通じて届いているか。このつながりを、品質の判断基準にします。
そのために、想定する利用場面と合格基準を設計時に共有し、実装した製品で検証します。期待した結果にならなければ、原因を確かめ、設計や実装を見直します。
合意した機能と判断の条件を満たしているか。
情報不足、想定外の入力、外部サービスの不調にも適切に対応できるか。
利用者が理解し、仕事の中で継続して使えるか。
顧客が購入する理由となった価値を、実際の利用場面で受け取れるか。
担当範囲、検証方法、完成の判断者を明確にし、確認できたことと残る課題を共有します。
4つの工程をつなぐために、誰に話を聞き、誰と判断し、誰が販売を担うかを、着手時に整理します。
パートナーが事業を主導する場合も、専門知識、製品設計、販売、顧客の反応がつながる体制を一緒につくります。
判断の根拠や例外まで理解するため、その仕事を深く理解している方に直接ヒアリングできる機会を設けます。
事業責任者とAIOの役割、仕様変更を決める手順、品質の合格基準、完成の判断者を明確にします。
AIOとパートナーのうち誰が営業、提案、販売後の対応を担うかを定め、販売戦略を実行する体制を整えます。
商談、失注、利用状況、問い合わせから得た情報を、共有する範囲と方法を決めて製品改善へつなぎます。
販売戦略の策定と販売の実行は、それぞれ担当と責任を定めます。事業・開発・営業・運用の分担に合わせて、成果物、意思決定の方法、情報共有の進め方を確認します。
新しいプロダクトの事業化を一貫してご一緒するほか、ストア公開、MCP/API接続、セキュリティ要件への対応設計、技術評価など、必要な範囲からご相談いただけます。
どのテーマから始まった場合でも、言われた作業だけを切り出して請け負うことはしません。誰にどんな価値を届けるための仕事かを最初に共有し、前提の整理から成果物・確認基準の設定まで一貫して向き合います。
専門知識や技術を製品にしたいが、誰に何を提供し、どのように販売するかが定まっていない。発見した価値を購買理由へ翻訳し、設計・実装・品質保証までつなぎます。
専門知識や業務ノウハウの製品化、AIを使った新規サービス、既存製品の事業化を検討する経営者・事業責任者・プロダクト担当者。
その仕事を深く理解する方へのヒアリングを通じて、強み、想定顧客、購買理由、価格、販売経路、必要な情報と協業体制を整理し、検証計画をまとめます。
販売仮説の検証、利用体験・AI機能の設計、試作、実装、受け入れ基準に基づく品質検証、販売・利用情報を踏まえた改善を支援します。既存製品の活用も含め、価値を届ける方法を検討します。
専門知識・判断基準の整理、販売仮説・検証計画、製品仕様、品質の合格基準、試作品・実装、検証結果。契約する工程に応じて成果物を定めます。
事業・開発・営業・運用の担当と責任を、案件ごとに定めます。販売戦略の策定に加え、営業実行をどこまで含むかを明確にします。売上や利益の達成を保証するものではありません。
自社サービスをChatGPTから利用できるようにしたいが、どの機能を提供し、どのように設計・申請すればよいか分からない。利用者の目的と公開要件に合う設計から申請準備までを支援します。
自社サービス、データ、業務機能をChatGPTの利用者に提供したい企業の事業責任者・開発担当者。
利用者が行うこと、公開する機能、必要なデータ、ログインの要否を整理し、既存システムの活用範囲を含めた公開方針と要件一覧をまとめます。
MCP/API連携、認証・権限、エラー処理、必要に応じた画面の設計・開発、接続検証、公開説明文・テスト手順・申請資料の整備、審査指摘への対応を支援します。公開後の運用や変更管理は別途定めます。
公開方針・要件一覧、機能・ツール仕様、認証・権限設計、検証結果、申請用パッケージ・説明資料、審査指摘対応表。
公開可否はOpenAIの審査によって決まります。承認・掲載・審査期間を保証するものではありません。支援範囲は、既存システムの状態と申請時点の要件を確認して定めます。
社内データや既存システムをAIから使いたいが、データをそのまま公開するわけにはいかない。誰に何を許可するかを整理し、業務に必要な機能だけを接続します。
既存の業務システム、データベース、WebサービスをAIと連携させたい企業の情報システム・開発・業務部門。
接続したいデータ・機能と利用者を確認し、読み取りと更新の区別、既存APIの利用可否、認証方法、必要な実行制限をまとめます。接続方針とMCP/API仕様のたたき台を作成します。
MCPサーバーやAPIの設計・開発、既存認証との連携、テナント・権限の分離、更新操作の確認、エラー・タイムアウト処理、接続試験、運用引き継ぎを支援します。
接続構成図、ツール・API仕様、権限設計、実装コード、接続・権限テスト結果、運用引き継ぎ資料。
接続先の利用条件、データの取り扱い、既存システムの制約を確認して設計します。すべてのAIサービスで同一の動作を保証するものではありません。ChatGPTへの一般公開・申請は必要に応じて別途支援します。
JC-STARの取得を求められているが、製品のどこを確認し、何を改修すべきか分からない。チェックリストを埋める前に、製品仕様と運用の両面から対応方針を整理します。
IoT製品・エッジ機器を企画、開発、提供する企業の製品責任者・開発担当者。
対象製品、目指すレベル、現行仕様を確認し、要件との対応状況と不足項目を整理します。要件差分表と対応優先順位をまとめ、設計変更や追加確認が必要な箇所を明確にします。
認証・アクセス管理、更新機構、ログ、脆弱性対応などの設計検討、確認試験の計画、証跡の整理、申請準備を支援します。外部評価が必要な場合は、役割分担と評価機関へ確認すべき事項を整理します。
対象・前提条件の整理、要件差分表、対応優先順位、対応設計書、試験・証跡一覧、申請準備資料。
本サービスは、JC-STARの要件適合と適合ラベル取得に向けた設計・準備を支援するものです。適合ラベルの付与を行うサービスではなく、取得を保証するものではありません。対象製品・レベルに応じて必要な評価・申請手続きを確認します。
提案書やデモは魅力的だが、費用や設計の根拠を判断しきれない。すでに進行中の開発について、継続・修正・再検討の判断材料がほしい。発注者側の立場で、確認できる根拠と未確認事項を整理します。
AIシステムの発注前、契約更新前、PoC後、本番移行前などに判断が必要な経営者・事業責任者・情報システム担当者。
提案書、見積、構成図、要件、試作品など、共有可能な資料と判断したい論点を確認します。前提条件、技術的な妥当性、未確認リスク、ベンダーに確認すべき質問をまとめます。
構成・技術選定の比較、費用項目と見積前提の確認、検証計画・受け入れ基準の整理、改善提案、必要に応じたベンダーとの技術打ち合わせを支援します。コードや実環境の検証は別途範囲を定めます。
評価レポート、未確認事項一覧、ベンダーへの質問案、改善提案、次の判断に必要な確認計画。
共有された資料と合意した範囲に基づく技術評価です。法的判断、監査証明、完全な脆弱性診断を行うものではありません。評価のみのご依頼も可能です。
私たちが設計・開発に関わった取り組みをご紹介します。各事例では、課題、設計の考え方、担当範囲、検証状況をご確認いただけます。
産業用電力の予測・制御に関する設計・開発事例。SPAQ株式会社の電力削減ノウハウを顧客に届けるため、商品コンセプト・営業訴求の整理から、要件定義、予測充放電制御の設計・実装、実設備での動作確認までを担当しました。
公的支援情報とAIをつなぐ設計・開発事例。株式会社CoCreateとの協業により、対話による制度検索から公式情報の照合、専門家への相談準備までをつなぐプラグイン/MCP基盤の構想・要件定義・開発を担当しました。
「あの人なら、何を見て判断するだろう」
「この専門性を、もっと多くの人に届けたい」
「経験の中で培ってきた考え方を、サービスにしたい」
「試作品や技術はあるが、誰にどう届けるかが定まっていない」
まだ仕様が決まっていない段階から、ご相談ください。
誰が、何を理解しているのか。その知性が届くことで、誰の仕事がよくなるのか。知性の所在、想定する顧客、販売の体制、今回取り組む範囲を整理し、進め方をご提案します。
事業仮説、設計、見積、試作品など、いま判断したい対象を確認し、次に進むための論点を整理します。
事業化の工程と担当範囲を定め、成果物、受け入れ基準、期間を共有して進めます。
事業・技術の判断、開発レビュー、販売・利用情報を踏まえた改善を継続的に支援します。
依頼範囲、成果物、役割分担、検証方法を確認したうえで、期間と費用をご提案します。