The Problem
発注の前に、決まっていないことが多すぎる
- 01要件が固まらないまま、見積を取っている。
- 02出てきた見積が、妥当かどうか判断できない。
- 03ベンダーの選定基準が、価格しかない。
- 04何をもって完成とするかが、契約に書かれていない。
- 05追加開発のたびに、金額の根拠が分からなくなる。
Where it breaks
要件定義で、失敗の兆候が出る
プロジェクトが崩れる兆候は、要件定義に出ます。徹底的に詰めきれるかどうかで結果が変わります。
要件は、技術だけ分かっていても詰められません。ビジネスの仕組みとオペレーションに精通していなければ、成し得ないと考えています。何がどう回っていて、どこで人が判断していて、例外が事業のどこに効いているのか。それが分かって初めて、作る範囲と作らない範囲を切れます。
また、相見積もりを取っても、料金の差だけでは質と信頼性まで確認しきれません。ベンダー選定の工程だけを切り出して引き受ける形もあります。
How we work
発注できる状態にするまでの進め方
01 ／ REQUIREMENT
要件を言語化する
業務要件をヒアリングし、作る範囲と作らない範囲を切り分けます。
OUTPUT
- 業務要件の言語化
- 作る範囲と作らない範囲
02 ／ ESTIMATE
見積を集め、評価する
複数ベンダーから見積を取り、内容と金額の妥当性を評価します。
OUTPUT
- ベンダーの選定基準
- 見積の妥当性評価
03 ／ CONTRACT
契約条件を整える
スケジュール、リスク分担、受入れ基準を契約に落とし込みます。
OUTPUT
- スケジュールとマイルストーン
- 受入れ基準
04 ／ HANDOFF
発注・引き渡し
発注先が決まれば、要件書一式を引き渡します。そのまま開発を依頼いただくことも可能です。
OUTPUT
- 発注できる状態の要件書一式
Deliverables
発注できる状態にして、渡す
当社が開発を受注しない場合でも、この設計だけを切り出して依頼できます。
Requirement
Vendor
Estimate
Scope
Architecture
Schedule
Risk
Contract
Acceptance
要件
- 業務要件の言語化
- 作る範囲と作らない範囲
- 優先順位
発注
- ベンダーの選定基準
- 相見積の比較
- 見積の妥当性評価
契約
- スケジュールとマイルストーン
- リスクと対応
- 受入れ基準
Position
受注する側ではなく、発注を設計する側に立つ
工数を売ることを目的にしていないので、「作らないほうが良い」と言えます。開発会社は構造的にそれが言えません。
一般的な開発会社
- 受注する側
- もらった要件で作る
- 「作らない」は言いにくい
- 見積は自社分のみ
INTEPRAL
- 発注を設計する側
- 要件を決めるところから
- 作らない判断も提案
- 相見積を並べて評価
受付中
経営課題の棚卸しから、
運用まで。
システム開発とAI導入支援。何を作るかを決める工程から入ります。
ASK AI
INTEPRALをもっと知る
普段使っているAIに、INTEPRALがあなたに合うか聞いてみましょう。
ボタンを押すだけで簡単に質問できます。