01
要件定義・業務整理
利用者、業務フロー、制約、権限、例外処理を分け、何を作るかを社内で説明できる状態にします。
困りごとを整理し、作る範囲、画面と操作、完成を確認する条件へ具体化します。依頼する側と作る側が、同じ条件を使って確認できる状態にします。
01 SYMPTOMS
こういう状態なら、ここから入る
01
社内では必要性がありそうだが、何を作るかを一文で説明できない
02
複数社の見積もりが、範囲も前提も違って比較できない
03
画面、業務フロー、データ、権限の話が会議ごとに入れ替わる
02 CAPABILITIES
具体的にできること
要件定義だけを納品して終わるのではなく、社内合意、見積もり比較、動くデモ、実装まで必要なところをつなげます。
02
動くデモ・MVP・PoC
文章だけでは決めにくい部分を、画面や操作で確認できるプロトタイプへ落とします。
03
RFP・見積もり比較の前提整理
各社の見積もり範囲が揃うよう、対象、前提、含まないもの、概算レンジを整理します。
04
受入条件・テスト観点
完成後に「思っていたものと違う」を減らすため、何ができれば合格かを先に決めます。
開発実績
似た相談の実例
課題、実装、成果、Beekleだからできたことまで確認できます
iroAI介護、文字入力をなくして公開
課題
介護サービスの情報が散らばっており、何をどう作れば高齢のご本人やご家族が使えるのか、要件が固まっていませんでした。
解決策
ヒアリングから文字入力をなくすという要件にたどり着き、LINE上でタップするだけのプロトタイプで操作感を確かめてから本開発に進みました。
成果
- 本開発 約2ヶ月でリリース
- 文字入力のいらないUIに着地
- iro-ai.comで実サービスとして公開
Beekleだからできたこと
要件を紙の上で詰め切らず、迷ったら実物を作って確かめます。使う人が高齢者の場合、机上の議論では使えるかどうかを判断できないからです。
AIに任せられない推薦を1週間でPoCに
課題
推薦文をAIに自由に書かせられない前提があり、候補をまとめてLLMに渡して並べさせる一般的な作り方は、最初から選択肢の外でした。
解決策
LLMの担当を、自然文を条件に構造化する入口と、理由を文章にする出口だけに限定し、検索と並べ替えはBM25とベクトル検索のRRF統合＋自前のスコア関数で決定論的に実装しました。
成果
- 相談から1週間で動くPoC
- 検索・並べ替えは10ms未満
- 推薦理由をスコアの内訳で説明
Beekleだからできたこと
AIに何をさせないかを先に決めてから設計するので、「AIにお任せ」で済ませられない事情があっても、動くものと説明できる根拠が同時に手に入ります。並べ替えの根拠はスコアの内訳として数値で残り、精度は評価ハーネスで測れる状態にしてあります。
倉庫AI DXを、要件定義から進めた
課題
紙とベテランの記憶で回っていた倉庫業務を、例外対応や現場の判断ポイントまで含めて要件として整理し直す必要がありました。
解決策
As-Is/To-Beの整理から受け入れ基準の定義、設計、実装までを一気通貫で進め、スキャンや実機端末に対応する倉庫システムを構築しました。
成果
- 紙の作業から抜けられる
- スキャンで誤出荷を防げる
- 進捗と欠品がその場で見える
Beekleだからできたこと
要件定義から入っているので、現場の例外処理まで仕様に残ります。実装だけを請けたときに必ず出る「動くけれど現場では使えない」を、上流で潰しています。
04 WHY BEEKLE
この場面でBeekleが強い理由
曖昧な相談をきれいな資料へ整えるだけでなく、判断できる形と、実際に動く形まで持っていけることが強みです。
01
会話を実装できる単位まで分ける
目的、利用者、具体的な利用場面、受入条件へ分け、開発者が迷いにくい要求へ変換します。
02
最短1日で動く確認材料を作る
長い会議を重ねる前に、見て触れるデモを作り、足りない情報と優先順位を早く確かめます。
03
決めた内容を実装・テストまでつなぐ
要件定義会社と開発会社を分けず、確認した内容を同じ文脈のまま実装とテストへ渡します。
実案件ログ
議事録から、1日で確認用デモへ
発注前のヒアリング内容を、画面で確認できる検証用プロトタイプへ落とし込みました。
- 会話の断片を業務フローと画面単位に整理
- 確認すべき問いをデモで見られる状態へ変換
- 次回打ち合わせで不足情報を確認できる資料として使用
成果物サンプル
発注判断メモ
目的、業務、利用者、制約、受入条件を同じ紙面に置きます。
判断材料
受入条件
何ができたら十分かを、見積もり前に確認できる粒度へ落とします。
次に確認すること
不足情報リスト
発注者側で確認すべき社内事情、データ、承認条件を残します。
05 MATERIALS
初回相談で返すもの
提案資料だけで終わらせず、社内説明や見積もり比較に使える形へ戻します。
01
発注判断メモ
目的、対象者、対象業務、制約、確認すべき問いを1枚に整理します。
02
受入条件のたたき台
画面や機能の話を、検収時に確認できる条件へ落とします。
03
概算レンジの前提
金額だけでなく、何を含み何を含まないかまで比較できる形にします。
06 CONDITIONS
見送り条件も先に置く
相談者側が社内で判断しやすいように、今すぐ着手しない条件も言語化します。
01
利用者や決裁者がまだ特定できていない
02
業務量や発生頻度が分からず、投資判断の前提が置けない
03
既存システムやデータの制約が確認できていない
07 SERVICES