本文へ移動
フィリット・コンサルティング

記事・資料・用語・事例をまとめて検索します(Ctrl / ⌘ + K でも開けます)

2文字以上入力すると検索します。

    Philit

    よくあるご質問

    ご相談前によくいただく質問を、61問にまとめました。詳しい解説がある質問は、記事や資料へのご案内を添えています。ここに無い疑問は、そのままお問い合わせください。

    ご相談・お見積り

    はじめてのご相談の前に、費用・進め方・準備するものについて。

    ご相談やお見積りに費用はかかりますか?

    かかりません。ご相談とお見積りは無料です。課題整理から提案書・見積書の作成までは費用をいただかず、ご契約後に作業を開始します。事業のアイデア段階のご相談でも構いません。作るべき範囲、進め方、費用の考え方まで、開発を担当するエンジニアが直接お答えします。

    問い合わせてから、どのくらいで返事がもらえますか?

    お問い合わせフォームからのご連絡には、通常1営業日以内にご返信しています。営業時間は平日12時〜21時(土日祝を除く)です。稼働状況によりお時間をいただくこともありますが、その場合もまずは受付の旨をお知らせします。

    創業前や事業計画の段階でも相談できますか?

    はい。創業前の段階からご相談いただけます。事業の仮説を整理し、最初に検証すべきことと、そのために必要な最小限のプロダクトの範囲を一緒に考えます。市場リサーチから始めることもできます。プレシードの段階で何を作るべきかはプレシードで作るべきものは何かにまとめています。

    何を準備してから相談すればよいですか?

    準備がなくてもご相談いただけます。事業のアイデアと、いまお困りのことを口頭でお話しいただければ、検証すべき仮説と最小限の範囲を一緒に整理します。社内で先に整理しておきたい場合は、要件を1枚にまとめるシートやMVPの範囲を決めるチェックシートをご利用ください。埋まらない項目があっても構いません。

    開発だけ、リサーチだけ、といった一部の依頼もできますか?

    できます。Webシステム開発のみ、市場リサーチのみ、UXデザインのみ、インフラの診断のみなど、必要な範囲を選んでご依頼いただけます。複数を組み合わせる場合も、一つの窓口で対応します。ご依頼できる範囲は事業案内をご覧ください。

    打ち合わせはどのように行いますか?

    お打ち合わせはオンライン(ビデオ会議)で行います。ご相談からリリース後の改善まで、すべてオンラインで進められる体制です。

    東京以外の地域からでも依頼できますか?

    はい。お打ち合わせと納品はオンラインで完結するため、全国のベンチャー・スタートアップに対応しています。

    30分の無料相談では何ができますか?

    開発を担当するエンジニアが直接お話を伺い、作るべき範囲、技術選定、進め方、費用の考え方など、その場で答えられる疑問にお答えします。他社の提案や見積があれば、その読み方もお伝えします。オンラインで行い、事前の資料は不要です。

    他社にも相見積りを取っています。それでも相談できますか?

    はい。相見積りを前提としたご相談も歓迎します。比較の際に見るべき点は相見積もりの比較シートとMVP開発の費用相場にまとめています。金額だけでなく、前提条件・作業範囲・保守の扱いが各社で揃っているかをご確認ください。

    どんな会社に向いていて、どんな会社には向きませんか?

    CTOがいない、または技術者が少ない状態で、事業の仮説をプロダクトで検証したいベンチャー・スタートアップに向いています。一方、モデルそのものの学習・開発や、大規模なRAG基盤の構築は専門外です。その領域が中心のご依頼は、正直にその旨をお伝えします。判断材料としてAI開発会社の種類と頼めることをご覧ください。

    契約・費用

    契約形態、見積りの決まり方、支払いのご相談について。

    契約形態はどのようになりますか?

    準委任契約(月額のチーム契約)と請負契約(機能単位)のどちらにも対応しています。要件が変わりやすいMVP段階は準委任、範囲と検収条件が明確な開発は請負が向いています。選び方は契約形態の選び方シート、費用の考え方は料金の考え方をご覧ください。

    費用はどのように決まりますか?

    作業に必要な工数と単価、それにクラウド費用などの実費を積み上げて見積ります。作る範囲によって案件により大きく異なるため、一律の料金表はありません。ご予算の上限があれば、その範囲で実現できる構成をご提案します。

    小さな予算でも依頼できますか?

    はい。予算に合わせて作る範囲を絞り、段階的に広げる進め方をご提案します。生成AIを開発工程に活用することで、同じ予算でより多くを実現できるよう努めています。範囲を削る順番の決め方は範囲・期日・費用の優先順位シートにまとめています。まずはご予算感をお知らせください。

    残りの資金(ランウェイ)から開発費をどう決めればよいですか?

    次の調達までに何を証明する必要があるかを先に決め、そこから逆算して範囲と期間を決めます。残り月数のすべてを開発に充てると、検証結果を次に生かす時間が残りません。考え方はランウェイから開発範囲を逆算する、試算はランウェイから逆算する開発予算をご覧ください。

    秘密保持契約(NDA)を結んでから相談できますか?

    はい。事業計画や社内資料をお預かりする前に、ご要望に応じて秘密保持契約を締結します。貴社の書式でも弊社の書式でも対応可能です。お問い合わせの際にその旨をお知らせください。

    株式やレベニューシェアでの支払いは可能ですか?

    原則として現金でのお支払いをお願いしています。準委任契約では稼働月ごとの精算、請負契約では検収後の一括または分割が基本です。個別のご事情はご相談ください。

    開発したソースコードの権利は誰のものになりますか?

    契約時に取り決めます。納品物の著作権をお客様に譲渡する形が基本ですが、汎用的な部品や社内の開発基盤など、譲渡の対象外とする部分がある場合は事前に明記します。確認すべき項目はソースコードの権利の確認事項にまとめています。

    保守はどこまで含まれますか?

    契約で範囲を定めます。障害対応、軽微な修正、ライブラリの更新、機能追加は、それぞれ対応時間と費用の扱いが異なるため、「何を、いつまでに、いくらで」を先に決めておくことをおすすめします。整理には保守範囲の確認シートをご利用ください。

    開発の進め方

    着手から検収、リリース後まで、実際の進み方について。

    開発はどのような流れで進みますか?

    ご相談、課題整理、提案・お見積り、ご契約、設計・UX、開発(イテレーション)、リリース、計測・改善、内製化支援の順に進みます。各段階でお客様にご確認いただく内容と、弊社が作成する成果物を決めて進めます。詳しくは開発プロセスのページをご覧ください。

    どのような技術で開発しますか?

    技術は用途と将来の運用体制に合わせて選定し、その理由をご説明します。先進性を重視しつつ、社内チームに引き継げることと、運用コストを抑えられることを判断の軸にしています。使用している技術は技術スタック、選定の基準はフェーズで変わる技術選定の基準をご覧ください。

    開発の途中で要望が変わった場合はどうなりますか?

    まずご相談ください。準委任契約の場合は、稼働時間の範囲内で優先順位を入れ替えて対応します。請負契約の場合は、変更の内容に応じて作業範囲と見積りを見直します。変更内容は文書に残し、認識のずれを防ぎます。進め方の合意事項はアジャイル開発と契約にまとめています。

    すべての機能を最初から作る必要がありますか?

    いいえ。弊社は投資対効果の得られない開発はご提案しません。検証に必要な最小限の範囲から始め、ユーザーの反応を見ながら機能を広げる進め方を基本にしています。作らないほうがよい機能は、正直にお伝えします。範囲の決め方はMVP開発とはをご覧ください。

    開発中、進捗はどのように分かりますか?

    動くものを定期的にご確認いただく形を基本にしています。資料上の進捗率ではなく、実際に触れる画面で判断していただくためです。確認の場で見るべき点は週次デモの確認シートにまとめています。

    納品されたものが要件どおりか、どう確認すればよいですか?

    検収の基準を着手前に決め、その項目で確認します。画面の見た目だけでなく、想定外の入力や権限の扱いまで含めて確認項目に入れておくと、リリース後の手戻りを減らせます。検収テストの項目シートをそのままご利用いただけます。

    他社が開発した既存システムの改修も依頼できますか?

    はい。現状の調査から入り、全面的に作り直すか、段階的に置き換えるかを判断材料とともにご提案します。判断の考え方はレガシーコードのモダナイズをご覧ください。

    セキュリティや個人情報の扱いはどこまで対応しますか?

    認証・権限・通信の暗号化・ログの保全など、事業の段階に応じて必要な範囲をご提案します。最低限そろえるべき項目は小さな会社の最低限セキュリティとスタートアップのセキュリティと個人情報保護にまとめています。なお、一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

    AI活用

    AIを使うべきか、既製のAPIでどこまでできるか、費用と責任の所在について。

    AI開発はどこまで対応できますか?できないことは何ですか?

    既製のAI APIをWebシステムに組み込む開発に対応しています。要約、分類、検索、入力補助、チャットなどが対象です。一方、モデルそのものの学習・追加学習や、大規模なRAG基盤の構築は専門外です。できること・できないことの線引きはAI活用開発とAI開発会社の種類と頼めることをご覧ください。

    生成AIはどのように活用していますか?

    開発工程では、設計の下書き、コードの生成とレビュー、テストの作成、ドキュメントの整備に活用し、高品質と低コストの両立を図っています。プロダクトの機能としても、チャットや要約などのAI機能の開発を行います。AIの出力は必ず人がレビューし、品質の責任は人が負います。詳しくは生成AIを開発工程に組み込むをご覧ください。

    うちの業務にAIを使うべきかどうか分かりません。

    まず、その業務の正解が一意に決まるかどうかをご確認ください。決まるのであれば、従来の仕組みのほうが速く安く確実です。件数が少ない業務や、監査・説明責任の対象になる判断も、AIには向きません。判断はAIを使わない方がいい業務とAIとルールベースの使い分けにまとめています。用途の洗い出しにはAI活用の用途整理シートをご利用ください。

    既製のAIツールを導入するのと、自社で作るのはどちらがよいですか?

    既製ツールで足りるなら、まずそちらをお試しください。自社の業務フローに深く結び付ける必要が出てきた段階が、作る検討を始める目安です。分かれ目はAIツール導入と自社開発の分かれ目に整理しています。弊社も、既製品で足りる場合はその旨をお伝えします。

    AIの利用料が青天井にならないか心配です。

    課金は処理する文字量と回数で決まるため、設計で抑えられます。入力に渡す範囲を絞る、結果を再利用する、上限を設ける、といった手当てを最初から入れます。考え方はAI利用料が膨らまない設計、試算はAI機能のコスト試算シートをご覧ください。

    自社のデータをAIに渡しても大丈夫ですか?

    渡してよいデータの線引きを先に決め、それを設計と運用ルールの両方に反映します。利用するAIサービスの規約で、入力データが学習に使われるかどうかも確認します。詳しくはAIに渡してよいデータの線引きとAIサービスの利用規約で見る点をご覧ください。なお、一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

    AIが間違った答えを出したとき、責任はどうなりますか?

    AIの出力をそのまま最終的な判断として使わない設計にします。人が確認する工程を残し、どの入力に対して何を出したかを後から追えるようにしておくことが前提です。考え方はAIの答えの責任は誰が負うかとAIの判断を後から追えるようにするにまとめています。

    他社から受けたAIの提案が妥当かどうか、見てもらえますか?

    はい。提案書と見積りを拝見し、確認すべき点を整理してお返しします。ご自身で確認される場合はAI提案を受けたときの確認事項をご利用ください。何を検証済みで、何が未検証なのかが書かれているかが、最初の見どころです。

    AIの機能を載せると「ただのAPIラッパー」と言われないか不安です。

    APIを呼ぶこと自体ではなく、その前後の業務設計とデータの扱いに価値が出ます。どこで差が付くかは「ただのAPIラッパー」と言われないためにとAI時代に守れるものは何かに整理しています。

    PoC・検証

    作る前に確かめる工程について。合格ラインの決め方から、打ち切りの判断まで。

    PoC(概念実証)とは何をする工程ですか?

    作り込む前に、事業として成立するかを小さく確かめる工程です。技術的に動くかだけでなく、現場の業務に乗るか、費用が見合うかまでを対象にします。詳しくはAIのPoCとは何を確かめる工程かと用語集のPoCをご覧ください。

    PoCの期間と費用はどのくらい見ておけばよいですか?

    案件により大きく異なるため一律の目安はお示ししていませんが、期間は「結果を報告して次を決める会議」から逆算して決めるのが基本です。費用は開発費・AIの利用料・自社側の作業時間の3つに分けて見積もります。考え方はPoCの期間と費用の考え方をご覧ください。

    PoCの合格ラインはどう決めればよいですか?

    着手前に、数値と判断者をセットで決めます。「精度が高ければ本番化」といった曖昧な基準にすると、結果が出てから議論が始まり、判断できなくなります。決め方はPoCの合格ラインを先に決める、記入にはPoCの打ち切り基準シートをご利用ください。

    PoCだけを依頼することはできますか?

    できます。本番開発を前提とせずにご依頼いただけます。PoCを社内でやるか外に出すかの判断はPoCを誰に頼むか、自社でやるか、契約時に決めておく点はPoC契約で決めておくことにまとめています。

    PoCがうまくいったのに、本番化で止まってしまうのはなぜですか?

    PoCでは扱わなかった条件が本番で出てくるためです。例外的なデータ、権限、監査、運用体制、費用の掛け算などが代表例です。構造はPoCと本番の間にある壁とPoC止まりになる7つのパターンに整理しています。

    PoCを中止すべきかどうか、どう判断すればよいですか?

    着手前に決めた合格ラインに届かず、届かせる道筋も見えない場合は、期間を延ばさずに止める判断が妥当です。中止は失敗ではなく、投資を止められた成果として扱います。判断の手順はPoCを中止する判断の下し方をご覧ください。

    予算をかけずに検証を始める方法はありますか?

    あります。既製のサービスに手元のデータを貼り付けて試す、対象を数十件に絞る、手作業で代替して需要を確かめる、といった方法で発注前に分かることは少なくありません。進め方は予算をかけずに始めるPoCをご覧ください。

    自社で使って確かめる(ドッグフーディング)は有効ですか?

    有効ですが、万能ではありません。社内でだけ通用する仕様になる危険があるため、社外のユーザーによる検証と併用します。始め方はドッグフーディングの始め方、限界はドッグフーディングの限界と誤判断をご覧ください。

    投資フェーズ別

    プレシードからシリーズB以降まで、調達の段階ごとに変わる論点について。

    調達のフェーズによって、作るべきものは変わりますか?

    変わります。プレシードでは仮説を確かめる最小限、シードでは繰り返し使われる状態、シリーズA以降では伸ばすための基盤と負債の返済が中心になります。全体像はフェーズ別、作るべきものの全体像と資金調達フェーズ別に見る、開発パートナーとの関わり方をご覧ください。

    シード期のMVPはどこまで作ればよいですか?

    次の調達で示す必要がある事実から逆算します。すべての機能ではなく、その事実を出せる最小限にとどめるのが原則です。詳しくはシード期のMVPはどこまで作るか、社内での整理にはシード期のプロダクト確認シートをご利用ください。

    シード期からAI機能を載せるべきですか?

    その機能がなくても仮説を検証できるなら、後回しで構いません。AIが事業の核である場合だけ、最初から扱います。判断はシード期にAI機能を載せるべきかとフェーズ別、AIにいくら賭けるかをご覧ください。

    シリーズAの調達後、開発の何が変わりますか?

    検証中心から、伸ばすための開発に移ります。同時に、それまで先送りした技術的負債の返済と、運用に耐える構成への作り替えが必要になります。詳しくはシリーズAで開発の何が変わるかと調達後に返す技術的負債の順番、準備にはシリーズA前の技術準備シートをご覧ください。

    技術デューデリジェンスでは何を見られますか?

    コードの状態だけでなく、開発体制、権利関係、セキュリティ、外部依存が対象になります。準備は直前では間に合わないため、調達を考え始めた時点から整えておくことをおすすめします。技術デューデリで見られることと技術デューデリジェンスの備えをご覧ください。

    ブリッジ期で資金が厳しいとき、開発をどう絞ればよいですか?

    次の調達に必要な一点に絞り、それ以外は止めます。止める判断を先送りすると、どれも中途半端なまま資金が尽きます。考え方はブリッジ期に何を作り、何を止めるかをご覧ください。

    開発の意思決定は誰がすべきですか?

    フェーズによって変わります。範囲の決定、技術の選択、リリースの可否では、決める人も判断材料も異なります。整理は各フェーズで誰が何を決めるかとフェーズごとの意思決定リストをご覧ください。

    体制・内製化

    社内に技術者がいない状態からの進め方と、内製化への移行について。

    CTOがいなくても依頼できますか?

    はい。社内に技術責任者がいない状態からのご依頼が多くあります。技術判断の相談、設計・実装、CTOやエンジニアの採用と引き継ぎまで、一つのチームで伴走します。判断の理由は文書に残し、経営陣が技術方針を説明できる状態を目指します。詳しくはCTO がいない方へをご覧ください。

    他社が開発した既存のコードをレビューしてもらえますか?

    はい。ソースコードと環境へのアクセスをいただければ、開発元にかかわらず現状を調査し、技術的負債やリスクを整理したレポートをお出しします。レビューのみのご依頼にも対応しています。

    将来的に自社で開発できるようにしたいのですが、支援してもらえますか?

    はい。内製化支援として、採用要件の整理、面接での技術的な見極めへの同席、開発プロセスと環境の整備、コードレビューや設計相談による伴走を行います。弊社が開発したシステムの引き継ぎも段階的に進めます。手順は開発の内製化ロードマップをご覧ください。

    引き継ぎのとき、何を受け取れば自社で運用できますか?

    ソースコードと環境に加えて、構成の説明、運用手順、外部サービスの権限、既知の課題の一覧が必要です。どれか一つ欠けると運用が止まります。受け取る項目は引き継ぎ資料の確認リストと運用手順書のひな形にまとめています。

    納品後の保守や改善も依頼できますか?

    はい。リリース後の計測・改善、不具合対応、機能追加を継続してご依頼いただけます。月ごとの稼働時間を決める準委任契約が基本です。社内チームへの移行を見据えた関わり方もご相談ください。

    技術顧問・外部CTOのような関わり方もお願いできますか?

    はい。実装を伴わない技術判断の相談や、採用の見極めへの同席といった関わり方にも対応しています。何を任せ、何を社内に残すかの考え方は技術顧問・外部CTOという選択肢をご覧ください。

    エンジニアを採用すべきか、外部に頼むべきか迷っています。

    事業の段階と、その技術が自社の核になるかどうかで判断します。核になる部分は社内に、変動が大きい部分は外部に置くのが基本です。人数と外部比率の考え方はフェーズ別、開発の人数と外部比率と少人数開発チームの体制設計をご覧ください。

    会社について

    会社の概要と、ご連絡の方法について。

    どのような会社ですか?

    フィリット・コンサルティング株式会社は、Webシステム開発、UXデザイン、市場リサーチ、マネタイズモデル構築、サーバーインフラ整備、広告運用を通じて、ベンチャー・スタートアップの事業立ち上げと成長を支援する会社です。先進性・UX・コストパフォーマンスを重視しています。詳しくは会社案内をご覧ください。

    これまでの開発事例を見せてもらえますか?

    守秘義務の範囲で、匿名の概要として開発事例に掲載しています。お客様が特定できる情報は掲載していないため、より具体的な内容は、ご相談の場で差し支えのない範囲でお伝えします。

    営業時間を教えてください。

    平日12時〜21時(土日祝を除く)です。お問い合わせフォームは常時受け付けており、通常1営業日以内にご返信します。

    連絡先を教えてください。

    ご連絡はお問い合わせフォームからお願いします。通常1営業日以内にご返信します。お打ち合わせはオンラインで行い、全国のベンチャー・スタートアップに対応しています。

    まずは、いま考えていることをお聞かせください

    アイデア段階でも、要件が固まっていなくても構いません。先進性・UX・コストパフォーマンスの観点で、次の一手を一緒に整理します。ご相談・お見積りは無料、通常1営業日以内にご返信いたします。

    無料で相談する

    資料の添付は、送信後に届く受付メールへの返信でお送りいただけます。

    ご相談は無料(30分・オンライン)
    企画書がなくても相談できます

    無料で相談する