01 / 04
議事録を入れる
議事録を1件入れると、要望、まだ決まっていないこと、今回やらないことに分かれます。登録されるのは、内容を確認して承認したあとです。
来月、プロジェクトを始めようとしている方へ
開発はなぜ、失敗しがちか。
失敗の大半は、プロジェクトの前に決まっている。
議事録を1件入れると、要望、まだ決まっていないこと、今回やらないことが分かれて表示されます。始める前に自分の目で確かめられ、決めたあとの管理は自動で進みます。
(01)
使い方の流れ
議事録を入れてから、アプリができるまで。
人が決めるのは、今回の範囲と優先順位です。整理、質問、進捗の反映は自動で進みます。
02 / 04
今回の範囲を決める
要求カードを、必須・重要・できれば・今回は見送りの4列に置きます。確定ボタンを押すまで、今回の約束にはなりません。
03 / 04
完成の条件を先に書く
ストーリーごとに、前提・もし・ならばの形で受入シナリオができます。まだ決まっていないことは質問にして、Slackで聞けます。
04 / 04
MCPでつないで開発AIに渡す
MCPでつなぐと、Claude Code / Codexが要求の背景、完成の条件、今回やらないことを読んで実装します。PRの動きは、タスクと進捗に反映されます。
使い方を選ぶ
Web版
ブラウザですぐ使う
インストールなしで始めるならこちら。ログインして、そのままワークスペースへ進めます。
- すぐ開ける
- 配布物の更新を気にしなくていい
- 外出先や共有端末でも使いやすい
Desktop版
ベータMacに入れて常用する
Dockから起動して、Web版と同じアカウントでログインします。今はMacのみのベータ版です。
- デスクトップ起動でそのまま作業
- Web版と同じアカウント
- ベータ版のため、動作や画面が予告なく変わることがあります
ベータ期間中は、お申し込みいただいたメールアドレスへダウンロード用のURLをお送りします。
(02)
こんな方へ
機能リストはあるのに、完成の条件が決まっていない方へ。
来月始めるのに誰が使うのかを書けない方、要望は集まったのにやらないことを決められない方、AIで作るのは速いのに決めることと管理が追いつかない方。立場は違っても、つまずく場所は同じです。
01 — PM
議事録を読み直す時間を、決める時間に使える
いま困っていること
文書を整えることが仕事になり、範囲が膨らんでいる。
こう変わる
議事録から、要望、未決事項、今回やらないこと、完成の条件までが書き出されます。人が決めるのは、範囲と優先順位です。
02 — エンジニア
推測ではなく、完成の条件を読んで実装する
いま困っていること
機能リストとタスク名だけを渡され、どこをどう直すかを推測している。
こう変わる
Claude Code / Codexにも、背景、完成の条件、依存関係、着手後の変更をそのまま渡せます。
03 — 事業側
任せきりにしても、リリースで「違う」にならない
いま困っていること
業務を知っているのに、要件と受け入れを開発側に任せている。
こう変わる
専門知識は要りません。上司にそのまま見せて報告できる画面です。進捗率の説明を待つ必要がなくなります。
04 — 内製化したい経営者
あれもこれも入れた結果、現場が元の手順に戻るのを防ぐ
いま困っていること
あれもこれも入れて始めた結果、現場が元の手順に戻ってしまう。
こう変わる
内製化しても、判断の材料が会社に残ります。使われないものを量産していないか、自分で確認できます。
05 — 自分でアプリを作りたい方
AIに作らせる前に、渡す情報が揃う
いま困っていること
AIで画面はすぐ動くのに、何を作るか、どこまで作るかが決まらないまま作り続けている。
こう変わる
決められた手順で進めるだけで、AIに渡すべき情報が揃います。Claude Code / Codexがそのまま読むので、指示書を別に書く必要はありません。
(03)
なぜ失敗しがちか
機能リストを直しても、始まってからのズレは止まらない。
多くのプロジェクトは、機能の一覧と金額だけを先に固めます。現場の人は、完成間近まで画面を見ません。「順調です」と聞いていたのに、リリースしてみると業務で使えません。これは技術の問題ではありません。
機能リストだけを渡す
誰が何のために使うかを決めずに、何ができるかだけを渡すと、現場で使われないものができあがります。
要望を全部入れる
各部門の「今のうちに」を全部載せると、要件は際限なく膨らみます。今やる／後でやる／やらないを先に決めます。
進捗率を信じる
「順調です」は、技術タスクを積み上げた数字です。つないで動くものがなければ、事業としての進捗はまだゼロです。
炎上の流れ
始める前に決めておかないと、後半の手戻りが大きくなる。
機能リストで始め、現場の人を完成間際まで巻き込まず、進捗率だけを追うと、リリース直前に「思っていたのと違う」が出ます。
01
機能リストで始める
02
現場が見ていない
03
進捗は順調
04
リリースで使えない
(04)
何が変わるか
リリースで「思っていたのと違う」が起きにくくなる。
Beekleの開発現場で毎日使い、途中で止まった案件の立て直しにも使っています。社外での継続利用は、まだ検証中です。
聞くべきことが一覧になる
聞くべきことが一覧になる
未決事項、質問文、回答待ちが並ぶ確認事項の画面です。機能を積み上げる前に、まだ決まっていないことだけをここで確認できます。
PM
議事録を読み直す時間を、決める時間に使える
- いま
- 希望と決定が混ざった文書を渡してしまい、機能が膨らんでいく。
- これから
- 誰のための開発かと、今回やらないことがはっきりする。リリース直前の「違う」が減る。
実装中も完成条件を読める
実装中も完成条件を読める
Claude Code連携の画面です。要求・タスク・完成条件を開発AIが直接読みます。機能リストだけを渡して当てさせるのではなく、同じ情報を読ませます。
エンジニア
推測ではなく、完成の条件を読んで実装する
- いま
- 背景を何度も聞き直し、完成の条件が無いまま書いている。
- これから
- 誰の何のための開発か、どうなれば完成かを読んでから書ける。作り直しが減る。
使う人の目的がカードになる
使う人の目的がカードになる
「誰として何をしたいか」、背景、受け入れ条件が並ぶ要求カードです。機能リストの前に、誰のどんな困りごとなのかが書き出されます。
事業側
任せきりにしても、リリースで「違う」にならない
- いま
- 機能リストで始めてしまい、できたかどうかの判断がリリース直前になる。
- これから
- 要望、作る範囲、完成の条件を自分で確認でき、受け入れにも参加できる。使われないものができにくくなる。
遅れと進み具合を経営側が見る
遅れと進み具合を経営側が見る
要求、タスク、遅れ、準備状況が並ぶダッシュボードです。担当者に聞かなくても、何を後回しにしたかを追えます。
内製化したい経営者
あれもこれも入れた結果、現場が元の手順に戻るのを防ぐ
- いま
- 経営のやりたいことで仕様が決まり、現場で使えるかどうかを誰も見ていない。
- これから
- 優先度、現場で使えるか、遅れ、変更の理由を経営側が追える。使われない投資が減る。
AIが読む完成の条件が先にできる
AIが読む完成の条件が先にできる
開発単位ごとに、受入シナリオを開けます。AIに作らせる前に、どうなれば完成かをここで先に書いておけます。
自分でアプリを作りたい方
AIに作らせる前に、渡す情報が揃う
- いま
- 思いついた順にAIへ指示し、動いたものを見てから直し続ける。
- これから
- 誰のために、何を、どこまで作るかと完成の条件が先に揃う。AIへの指示が短くなり、作り直しが減る。
(05)
なぜ今か
実装は速くなった。決めることと管理は、人の手のまま。
AIでコードは速く書けるようになりました。速くなった分、何を作るかを決めること、確認すること、進捗を追うことが人に溜まります。案件が2つ、3つと並ぶと、手作業の管理では追いつきません。来月始めるなら、いま決まっていないことが、そのままプロジェクトの前提になります。
01
速い実装はズレも速くする
以前は、設計や実装の途中で上流のズレに気づけました。いまは機能単位で一気に書き上がるので、間違ったものが先に完成します。
02
管理が実装の速さに追いつかない
コードは1日で書き上がるのに、要件の確認や進捗の更新は手作業のままです。PM on Railsは整理、質問、進捗の反映を自動で進めるので、案件がいくつ並んでも同じ画面で追えます。
03
型に沿うから、AIに渡す情報が自然に揃う
誰のための開発か、今回やらないこと、完成の条件といった、AIに作らせるときに必要な情報が、決められた手順で進めるだけで揃います。発注する人も、自分でアプリを作る人も、同じ型で進められます。
04
始まってからでは遅い
画面が動くことと、現場で毎日使えることは別です。完成の条件と、現場の人が触った結果のない進捗は、あてになりません。
速い実装でも、遅れは画面に出る
速い実装でも、遅れは画面に出る
準備状況と遅れが並ぶダッシュボードです。実装が速くても、何を作るかが口頭のままだと、ズレはリリースまで見えません。ここでは数字で出ます。
遅れはその週のうちにグラフに出る
遅れはその週のうちにグラフに出る
バーンダウンの画面です。残作業が予定から外れると、折れ線が予定の線から離れます。機能を盛り込んだ週のズレが、納期直前まで隠れずに見えます。
(06)
何ができるか
誰のための開発かと今回やらないことが、先に決まる。
議事録を入れると、要望と未決事項が分かれて出てきます。範囲を決めるのは人です。決めたあとの質問、回答の反映、進捗の更新は自動で進むので、「できた／違う」の判断をリリース直前まで先送りしなくてよくなります。
01
誰が使うのかが資料から見えてくる
議事録から、決まったこと、まだ決まっていないこと、今回やらないことを分けます。
02
未決事項を関係者にそのまま聞ける
まだ決まっていないことを質問文にして、Slackで確認できます。
03
返ってきた回答が完成の条件になる
回答を要件、完成の条件、タスクの更新案に反映できます。
04
進捗率ではなく、動いているかが見える
タスクとPR（開発者の変更依頼）がつながり、完了や状態の変化がそのまま進捗に反映されます。
要望がカードになる
要望がカードになる
「誰として何をしたいか」、背景、受け入れ条件が並びます。機能リストの前に、利用者の目的を書き出します。
今回やらないことまで決める
今回やらないことまで決める
必須・重要・できれば・今回は見送りの4列に、カードをドラッグして置きます。確定ボタンを押すまで、今回の約束にはなりません。
未決事項が質問文になる
未決事項が質問文になる
宛先と回答状態が一覧になります。ヒアリングで固めてしまう前に、まだ決まっていないことを聞けます。
完成の条件が先に読める
完成の条件が先に読める
開発単位ごとに、受入シナリオを開けます。リリース直前の「できた／違う」の判断を、ここで先に書いておきます。
いつリリースされるかを予定表で見る
いつリリースされるかを予定表で見る
四半期やサイクルごとのまとまりと、今作っている場所が見えます。報告を待たずに、関係者も確認できます。
日々の作業がボードの上で動く
日々の作業がボードの上で動く
未着手から完了までタスクが並ぶカンバンです。実装は進んでいるのにボードは古いまま、とならないようにPRとつなぎます。
遅れも準備も一覧になる
遅れも準備も一覧になる
要求の準備、自分の作業、遅れが並びます。進捗を手作業で集めなくても、判断の材料が先に揃います。
開発AIが同じ情報を読む
開発AIが同じ情報を読む
Claude Code / Codex連携です。タスク名だけを渡して当てさせるのではなく、要求と完成条件を開発中に読ませます。
(07)
なぜPM on Railsか
要件定義書を仕上げるためのツールではありません。
Beekleの開発現場で毎日使い、途中で止まった案件の立て直しにも使っています。決めた範囲が、開発の作業と完成の条件までつながって残ります。
01
開発現場で毎日使っている
Beekle自身のプロジェクトで毎日使い、途中で止まった案件の立て直しにも使っています。
02
機能リストのまま始めようとしているなら
誰が使うのか、今回やらないこと、どうなれば完成かを、始める前に決めておく場所です。
03
型に沿えば、AIに渡す情報が揃う
書き換わるのは、人が確認してからです。決められた手順で進めるだけで、Claude Code / Codexが読む背景、完成の条件、やらないことが揃います。指示書を別に書く必要はありません。
04
議事録1件から試せる
料金の話の前に、手元の資料がどう整理されるかを確認できます。
決めた範囲が開発単位になる
決めた範囲が開発単位になる
スコープを確定すると、ストーリーと完成条件が残ります。要件定義書だけで止まると、決めた範囲が開発に渡りません。
変更の理由もここに残る
変更の理由もここに残る
提案の差分の横に、承認・却下・適用のボタンが並びます。要望を足すときは、何を後回しにするかを隣で決めます。
(08)
自動化
決めたあとの管理は自動で進む。
機能の多さより、途切れないことが大事です。要望、今回やらないこと、完成の条件、実装、動作確認が、別々の書類に分かれません。人が決めるところ以外は自動で進むので、複数のプロジェクトを同時に追えます。
01
要件定義
AI・連携が支えること
議事録から、誰のための要望か、決定、未決、今回やらないことを分ける
人が確認・判断すること
内容が合っているか確認する
02
確認
AI・連携が支えること
曖昧な点をSlackで聞ける質問にする
人が確認・判断すること
質問内容と送信先を確認して共有する
03
反映
AI・連携が支えること
回答を要件・完成条件・タスクの更新案に戻す
人が確認・判断すること
承認する
04
開発投入
AI・連携が支えること
完成条件、見積もり、依存関係から、着手前の不足を確認する
人が確認・判断すること
今回の範囲、担当、期間を決める
05
実装
AI・連携が支えること
Claude Code / Codexに要求・完成条件・タスクの文脈を渡す
人が確認・判断すること
実装を進める
06
進捗
AI・連携が支えること
連携・紐付け済みのPRの動きをタスクと進捗に反映する
人が確認・判断すること
進捗とテスト結果を確認する
開発に入れる前に確認すること
誰が使うのかが分かる
完成の条件がある
今回やらないことが決まっている
関係者が合意している
(09)
できること
誰のための開発か、今回やらないこと、完成の条件が残る。
資料から作業までがつながり、決めたあとの管理は自動で進みます。案件がいくつあっても、準備状況と進み具合を事業側が確認できます。連携した開発AIが読むのも、同じ情報です。
誰が使うのかが資料から見えてくる
議事録から、要望、未決事項、今回やらないことを分けます。
未決事項を関係者に聞ける
連携したSlackに確認を送り、回答を仕様の更新案につなげます。
リリースの前に「できた」の基準が揃う
どうなれば完成かを、開発者にも開発AIにも伝わる形にします。
決めた範囲が開発の作業になる
要望を開発単位、完成の条件、タスクへ展開します。
実装の動きが進捗に反映される
GitHub連携とタスクへの紐付けを設定すると、PRの動きで状態が更新されます。
進捗率ではなく、遅れが見える
「自分の作業」で担当と予定を、「進捗・管理」で進み具合を確認できます。
議事録1件から相談できる
ログインして最初に開く画面です。資料を添付して相談し、登録していいか確認してから作成されます。
(10)
人がやること
人が決めるのは、範囲と優先順位です。
AIは整理と質問づくりを手伝います。内容を確認し、今回作る範囲、優先順位、担当、期間を決めるのは人です。実装後のテスト結果も、人が確認します。
誰のための開発かを確認する
今回やらないことを決める
完成の条件と進め方を決める
(11)
比較
整えた機能リストを入力し直す場所ではありません。
一般的なツールでは、整理済みの情報を人が登録します。PM on Railsは、議事録から誰のための要望かを分け、今回やらないことと完成の条件まで残します。
| 観点 | 一般的なツール | PM on Rails |
|---|---|---|
| 位置づけ | 要件定義ツール / タスク管理ツール | 誰のための開発か・今回やらないこと・完成の条件を決める場所 |
| 入力 | 人が整理済みの機能リストを登録 | 議事録から要求を分け、作る／作らないを人が決める |
| 要件定義 | ヒアリングで固めて文書を渡す | 未決事項を聞き、作らないことを先に決める |
| 進捗管理 | 書類の進捗率で判断する | 完成条件とPRの動きで、動いているかを見る |
| AI coding | 機能リストとタスク名を渡す | 要求・完成条件・タスクのつながりをClaude Code / Codexへ渡す |
| 事業側 | 開発を任せて終わりにする | 事業側が完成の条件を読み、受け入れに参加できる |
まずは試す
手元の議事録1件で試せます。
ログインすると会話画面が開きます。資料を1件添付して相談し、登録していいか確認してから、今回やらないことを決める流れです。次に何をするかは、ホームの「開発の準備」が案内します。
相談
いまの進め方を聞かせてください。
機能リストだけを整えている、要望を全部入れようとしている、AIで作るのは速いのに管理が追いつかないなど、いまの進め方をお聞きして、最初に決めるべき範囲を一緒に整理します。
01
最初に決めること
議事録から、誰が使うのか、今回やらないこと、まだ決まっていないことを書き出す。
02
次につなぐこと
完成の条件、タスク、PR、進捗までつなぎ、受け入れまで途切れない状態にする。
無料相談