見積もりの前提から、作り変える。

人月で見積もる受託の仕事に、群れで作る型を入れるための使い方です。題材は、自社のサービスか、お客の許しを得た案件です。

BeesBuild の設計図の画面。ページの一覧と、決めることのカードが並ぶ
設計図 › 設計書画面設計(開発中)・数字は見本

いま、ここで止まっていませんか

  • 人が足りず、案件を断っている

    1人に1つの持ち場では、受けられる大きさが人の数で決まります。

  • 仕様が後から変わり、赤字になる

    画面を見ずに決めた要件は、画面を見た時に変わります。変わるのが作った後だと、高くつきます。

  • AI を入れても、1人ずつが少し速くなるだけ

    1人に1本の AI では、案件の大きさも、受けられる数も変わりません。

  • 若手が育つ前に、案件が終わる

    設計の考え方を、案件の中で伝える時間がありません。

10日の後に、変わること

受託開発と制作会社の、いまと10日の後
いま10日の後
要件の決め方文書で決め、後で画面を見る画面のキャンバスを見ながら、問いに答えて決める
お客との確認作った後先に作る4つと画面の見本で、作る前に
分担人ごとに機能を割るブロックと約束の型で、人と AI の持ち場を割る
品質終わりにまとめて試験監査と AI の試験が、作る間ずっと別に動く
見積もり人月設計の日数、群れの日数、ブロック単位のレビューの日数

分担を、データの持ち主で決める

画面を全部並べてから、どのデータの持ち主かでブロックに割ります。人と AI の持ち場が、ここで決まります。

会員予約決済通知店舗管理 全部の画面 データの持ち主ごとのブロック

10日間の使い方

  1. Day 1〜2 要件を決める型を持ち帰る

    エコシステム、問い、画面のキャンバス、設計書の8本。この順番は、お客との要件定義にそのまま使えます。

  2. Day 3〜7 役を分けて回す

    PM は決める人、エンジニアは回す人、デザイナーは UI と UX の見張りと組みます。だれが何をしないかも決めます。

  3. Day 8 お客の役を立てて触る

    社内の人にお客の役で触ってもらい、気づきを修正のカードにして、ブロックへ返します。

  4. Day 10 最初のリリースか、納める前の版

    自社のサービスなら最初のリリース、お客の案件なら納める前の版まで出します。その後のブロック単位のレビューは、作った時と同じ単位なので、引き継ぎにもそのまま使えます。

向いているプラン

全部のプランの中身は料金にあります。

よくある題材

  • 自社の SaaS や自社のサービス
  • 社内の業務の仕組み
  • お客の許しを得た案件の作り直し

気をつけること

お客の案件を題材にする時は、契約と秘密保持を先に確かめ、AI に渡してよいデータの線を引きます。本番のデータは使わず、テスト用のデータで作ります。

本番に出るリポの merge は、いつも人が押します。

BeesBuildCamp

日程・料金・定員は予定(案)です。決まり次第、このサイトを更新します。