何を作るべきかが決まっていない
「業務を効率化したい」という課題感はあるが、どんなシステムを作ればよいか、どこから手をつければよいかが社内で固まっていない。
PM on Railsとは、打ち合わせで話した内容を、AIがそのまま実装できる形に整理し続ける自社の仕組みです。決まっていないことを洗い出して確認し、「何ができたら完成か」まで書くので、要件定義の途中でも開発が止まりません。
ヒアリングの内容が、実装とテストまで同じ流れで残る。だから要件定義を急がなくても、開発は止まらない。
始める条件
要件未確定でも可
残すもの
要求と受入条件
開発
つながった仕様から
この状況で相談をいただくことが多い順に挙げています
「業務を効率化したい」という課題感はあるが、どんなシステムを作ればよいか、どこから手をつければよいかが社内で固まっていない。
要件を自分たちで整理できず、開発会社に何をどう伝えればよいか分からない。専門用語が多くて会話がかみ合わない不安がある。
仕様書を作っても、完成したものが想定と違う。文章だけでは発注側と開発側のイメージが揃わず、手戻りが発生しやすい。
会議を重ねても決まらず、要件定義のフェーズが長引いてプロジェクトが前に進まない。
なぜ、要件定義が長引くのか
会議を増やしても、文書を厚くしても、実装と確認につながる形で残していなければ、同じ話を何度もやり直します。
議事録と要件定義書は読めますが、実装タスクや確認観点とは別の文書です。渡した瞬間に前提が切れ、開発側が読み替えたところでズレます。
未決を残したまま実装すると壊れる、という恐れから、先に全部書こうとします。決まっていない部分まで待っているあいだ、決まった部分も動きません。
仕様変更の影響範囲を追えないと、変更そのものが怖くなります。怖さのぶん要件定義を長引かせ、結局あとから大きく直す、という循環になります。
BEFORE / AFTER
会議を重ねて文書を厚くしても、実装に届かなければ要件定義は終わりません。会話を役割ごとに分けてつなぐと、決まったところから開発に入れます。
よくある進め方
要望を議事録と要件定義書に書き写し、全部固まってから開発会社へ渡します。途中で変わると、最初から説明し直します。
Beekleの設計
「こうしたい」は要求、「システムが満たす条件」は要件、「完了の確認」は受入条件として残します。同じ文章をコピーして回しません。
その先
優先する要求だけをタスクとテストにつなぎ、AIエージェントがコードを書きます。画面を見て違う箇所は、同じ流れへ書き戻します。
要件定義を全部終わらせてから開発する必要がなくなります。決まった要求から、速く動かせます。
SERVICE PACKAGE
「支援します」だけでは、何を買うのか分かりません。このサービスでどこまで進め、何が手元に残るかを先に共有します。
PROMISE / 約束
「何を作るべきか」が曖昧な段階から入り、会話をPM on Railsで要求・受入条件・実装タスクへつなぎ、動く確認材料まで残します。
PROCESS / 工程
DELIVERABLES / 成果物
SCOPE / 前提・境界
要件は一度書けば固定されるものではありません。動くものや新しい事実で変わったら、理由と影響範囲を追える形で同じ流れへ戻します。
PM ON RAILS
会話を議事録や要件定義書で止めません。要求、ユーザーストーリー、受入条件、開発タスクへ構造化し、その仕様をAIエージェントへ渡して実装します。確認結果も同じ流れに戻します。
INPUT
CONNECT
CONNECT
CONNECT
DELIVERABLES
約束 × 工程 × 成果物
PROMISE / 約束
要件が固まっていない段階から入り、会話を実装と確認につながる仕様へ変え、動くものを見ながら更新します。
PROCESS / 工程
業務ヒアリング → 要求・ストーリー化 → 受入条件 → プロトタイプ → AI実装・テスト → 要件へ書き戻し
DELIVERABLES / 成果物
全部書いてから開発する必要はありません。優先する要求から動かし、残りは後から足します。
聞く
現場の流れ・例外・判断・困りごとを整理する
分ける
要求、ストーリー、受入条件を役割ごとに残す
つなぐ
決まった要求だけを開発タスクとテストにつなぐ
作る
仕様をAIエージェントへ渡し、動く形にする
確かめる
文章ではなく実物で、満たしたかを見る
戻す
違った箇所だけを更新し、影響するタスクをやり直す
会話が実装とテストまで届く形で残るので、要件定義を全部終わらせる前から開発に入れます。AIエージェントは受入条件を読める状態でコードを書き、確認結果は同じ流れに戻ります。要件定義と開発が、同じ速さで進みます。
会話が実装と確認まで届く流れを、順に見ていきます。名前より先に、何が残るかを見てもらうための説明です。
ヒアリングで出た「こうしたい」は要求のまま残します。システムが満たすべき条件は要件に、利用者の目的はユーザーストーリーに、完了の確認は受入条件に分けます。同じ文章を何通もの資料へコピーしません。あとから「どれが正か」を探さなくて済みます。
優先する要求だけを受入条件と開発タスクまで落とします。残りの要求は、後から足せます。要件定義を先に完成させなくてよいので、要件定義そのものが速くなります。待たされている開発も始まります。
要求・受入条件・タスクの関係ごと接続します。Claude CodeやCodexなどのAIエージェントは、何を満たせば完了かを読める状態でコードを書きます。的外れな実装が減るぶん、開発も速くなります。
画面を見て「違う」が出ても、口頭やチャットで終わらせません。受入条件と要求を更新し、影響するタスクだけをやり直します。確認と修正の往復が短いのは、書き戻し先が最初から決まっているからです。
なぜその仕様になったか、どの確認観点とタスクに効くかを追えます。変更が怖いから要件定義を長引かせる、という悪循環が起きにくくなります。速く決めたあとも、速く直せます。
PM on Railsとは、もともとBeekle社内で回していた開発の進め方を、AIエージェントで動くようにした仕組みです。新しく持ち込んだ手法ではなく、これまでの案件で使ってきたやり方をそのまま形にしています。打ち合わせで出た要望、決まった条件、作業、確認結果を1か所でつなぐため、仕様が変わってもどこに影響するかを追えます。いまもBeekleの開発現場で使っています。相談のあと、会話がどの形で残るかを一緒に見られます。
PM on Railsの公開サイトを見る(外部提供は準備中)要件が固まる前に入り、画面で確かめてから本開発へ進めた案件
課題
介護サービスの情報が散らばっており、何をどう作れば高齢のご本人やご家族が使えるのか、要件が固まっていませんでした。
解決策
ヒアリングから文字入力をなくすという要件にたどり着き、LINE上でタップするだけのプロトタイプで操作感を確かめてから本開発に進みました。
成果
Beekleだからできたこと
要件を紙の上で詰め切らず、迷ったら実物を作って確かめます。使う人が高齢者の場合、机上の議論では使えるかどうかを判断できないからです。
課題
構想段階で要件が言語化されておらず、発注側と開発側でイメージがずれやすい状態でした。動くものを早く見て方向性を確かめたい、という相談でした。
解決策
ヒアリング議事録からRFP(提案依頼書)を作り、その仕様をもとに実装しました。1日で動作するデモまで進め、画面を見ながら認識を合わせました。
成果
Beekleだからできたこと
議事録をそのままAIへ渡さず、RFPから仕様へ構造化してから実装します。速いだけでなく、発注側の認識を保ったまま速く作れます。
課題
採用と配置の判断が面接担当者の経験や紙の診断票に依存し、候補者と職種、チーム相性、入社後のリスクを一貫して見る手段がありませんでした。
解決策
HEXACO-100の心理尺度をシステム化し、LLMを構造化分析のエンジンとして使って、個人レポートから職種適合、チーム相性までを返す形にしました。
成果
Beekleだからできたこと
心理学の理論をそのまま実装するのではなく、採用の現場で読める形に翻訳します。学術的に正しくても、現場で判断に使えなければ意味がないからです。
会話を仕様にし、動くものへつなぎ、確認結果を書き戻します
SOLUTION 01
「どんな機能がほしいか」を聞く前に、「どんな業務課題を解決したいか」から整理します。発注者が要件を言語化できていなくても、対話を通じて本当に必要な機能を一緒に定義します。
SOLUTION 02
最短数日で動く確認材料を作成します。要件を文章ではなく実際の画面で確認できるため、認識のズレを本開発の着手前に解消できます。完成イメージを見てから発注の可否を判断できます。
SOLUTION 03
ヒアリング内容を人が読む資料で止めません。要求、要件、ユーザーストーリー、受入条件、実装タスクを複製せず関係でつなぎます。その仕様をAIエージェントへ渡すので、要件定義も開発も同じ速さで進みます。
ヒアリングから、実装につながる仕様と確認材料まで
言葉になっていない要望も、事業課題の背景から聞き取って要件にします。何を作るべきかが決まっていない段階から相談できます。
最短数日で動くものが出ます。仕様書の文章ではなく画面を見て、本開発に進むかどうかを決められます。
会話を議事録で終わらせず、実装とテストまでつながった仕様として残します。だから要件定義を急がなくても、開発は止まらない。
小さなチームが要件定義から運用まで担当します。フェーズが変わるたびに前提を説明し直す手間がありません。
発注前に確認されやすい論点をまとめています
はい。「何を作るべきか」が決まっていない段階からのご相談を歓迎しています。事業課題のヒアリングから入り、本当に必要な機能を一緒に整理します。
可能です。要件定義のみのご依頼にも対応します。整理した要件をもとに他社へ発注される場合も、発注者目線で要件をまとめます。
初回相談・簡易デモは費用をいただきません。実データ連携や個別業務に合わせたPoCが必要な場合は、目的・範囲・判断基準を整理したうえで別途ご提案します。
はい。発注経験や専門知識がなくても進められるよう、専門用語をかみ砕いて説明し、要件の整理から伴走します。会話の内容はPM on Railsで要求と受入条件に落とすので、発注側が仕様書の書き方を覚える必要はありません。
ヒアリングを通じて発注内容の整理までお手伝いします。複数社へ相見積もりを取る前提でも、要求と受入条件を伝わる形にまとめます。
PM on Railsとは、打ち合わせで話した内容を、開発がそのまま使える形に整理し続ける仕組みです。議事録から「まだ決まっていないこと」を洗い出して確認し、返ってきた答えを反映します。「何ができたら完成か」という条件まで書くため、AIエージェントが迷わず実装できます。もともとBeekle社内で回していた進め方をAIエージェントで動くようにしたもので、外部提供は準備中、社内では現在も使っています(pmonrails.com)。
一般的なタスク管理ツールが管理するのは、作業の進み具合です。PM on Railsが管理するのは、「なぜその作業をするのか」から「何ができたら完成か」までのつながりです。要望、決まった条件、作業、確認結果を別々の文書にコピーせず、関係でつないで持ちます。そのため仕様が変わったとき、どの作業とどの確認に影響するかをたどれます。
できます。PM on Railsは進め方を支える裏側の仕組みで、発注側に操作や学習をお願いするものではありません。お客様にお渡しするのは、整理された要件と、画面で確認できる動くものです。ツールの使い方を覚える必要はありません。
会話が実装につながる仕様として残るからです。要件定義書を急いで書くのではなく、決まった要求から受入条件とタスクを切り出し、AIエージェントが迷わずコードを書ける状態にします。動いた結果も同じ流れに戻すので、確認と修正の往復が短くなります。
問い合わせの前に
営業資料だけでは、自社に合うか判断しにくいことがあります。社内の制約や今の状況を知っているAIに聞くと、合う理由と合わない理由が先に見えます。