PM on Rails・AI駆動開発
Beekleが自社開発した開発基盤「PM on Rails」と、AIを使った開発の品質・期間・仕様変更・引き継ぎについて。
6問
- PM on Railsとは何ですか?
-
PM on Railsは、Beekleが自社開発し、実際の開発案件で使っている開発基盤です。
AIでコードを書く速度は大きく上がりました。しかし、要件が曖昧なままAIへ渡せば、間違ったものを高速に作ってしまいます。
そこでPM on Railsでは、要求→Use Case→Gherkin Scenario→Acceptance Criteria→設計→AI実装→テストまでを一つにつなぎます。単なるプロジェクト管理ツールではなく、「何を作るか」を正確にしてから、AIで速く作るための開発基盤です。
- PM on Railsを使うと、発注側にはどんなメリットがありますか?
-
システム開発で本当に怖いのは、開発会社がコードを書くのが遅いことだけではありません。もっと大きな問題は、要件が正しく伝わっていない、必要なケースが抜けている、設計に矛盾がある、テストされていない条件がある、完成後に「思っていたものと違う」と分かる、修正のために納期と費用が膨らむことです。
PM on Railsは、この「後から分かる」をできるだけ前に持ってくるための仕組みです。要求を具体的なGherkinシナリオと受入基準まで分解し、AIで正常系だけでなく、異常系・境界値・権限不足・エラーケースなども洗い出します。さらに、DB・API・権限・状態遷移・エラー処理などを実装前にレビューし、シナリオとテストをつなげます。
その結果、次の状態を作れます。
- 要件が早く具体化する
- 抜け漏れを実装前に発見しやすい
- 設計ミスを早い段階で見つけられる
- AIが迷わず実装しやすくなる
- テスト漏れを減らせる
- 後工程の作り直しを減らせる
発注側にとってのゴールは、PM on Railsを使うことではありません。「ちゃんと意図が伝わっているだろうか」と不安になりながら完成を待つのではなく、途中から正しい方向へ進んでいることを確認でき、より短い期間で安心して欲しいシステムを受け取れることです。
Beekle社内では、従来開発との比較で開発速度約3倍、要件・シナリオの抜け漏れ約30%削減、品質約30%向上という暫定評価もあります。
※Beekle社内での従来開発との比較に基づく暫定的な体感・評価値です。案件規模・要件・チーム構成・技術条件によって効果は異なります。
- AIを使った高速開発だと、品質が落ちませんか?
-
「AIを使う=品質が上がる」わけではありません。むしろ、曖昧な指示をAIへ渡せば、間違った実装まで高速化されます。
BeekleではPM on Railsで、シナリオ、受入基準、DB、API、権限、エラーケース、非機能要件、テストまで具体化してからAIへ渡します。
つまり「AIだから速い」ではなく、AIが正しく作りやすい状態を先に作るから、速さと品質を両立しやすいという考え方です。
- なぜPM on Railsを使うと開発期間を短縮できるのですか?
-
開発期間は、コーディング時間だけではありません。要件定義+設計+実装+レビュー+テスト+手戻りの合計です。
PM on Railsでは、次の方法でそれぞれの工程を短縮します。
- AIでシナリオを生成し、抜けを洗い出す
- 受入基準を具体化する
- 設計をまとめてレビューする
- 構造化された仕様をAIへ渡す
- シナリオとテストを接続する
- 問題を実装後ではなく前工程で見つける
だから、コードを書く部分だけではなく、開発全体を速くすることができます。PM on Railsを利用した実案件では、要件整理から動くデモまで1日で到達したケースもあります。
※案件規模・条件が限定された実例であり、すべての案件が1日で完成することを意味するものではありません。
- 仕様変更があった場合にもPM on Railsは役立ちますか?
-
はい。仕様変更で怖いのは、変更した箇所以外への影響を見落とすことです。
PM on Railsでは、要求→シナリオ→受入基準→設計→実装→テストの関係を保持します。そのため変更時に、関連する仕様・設計・テストを追いやすくなります。
結果として、変更するたびに別の場所が壊れる、昔の判断理由が分からない、といった不安を減らしながら改善を続けられます。
- 担当者が変わってもプロジェクトを引き継げますか?
-
PM on Railsでは、重要な情報を特定のPMやエンジニアの頭の中だけに残さないことを重視しています。要件、設計、判断履歴、変更理由、テストなどをプロジェクトの資産として残します。
そのため担当変更や長期開発でも、「なぜこうなっているのか分からない」状態を減らせます。将来的な改修や保守まで考えると、コードだけでなく開発時の判断そのものが残っていることが大きな価値になります。