プロジェクトごとに軽い管理の仕組みを作る 仕様書とボードの実例

数か月から年単位で続くプロジェクトでは、決めたこと・決めていないこと・だれの番かを残す仕組みが欠かせません。この記事では、既存のサービスの決まりに仕事を合わせるのではなく、プロジェクトに合わせて軽い管理の仕組みを作る方法を、編集部の実例と公式の料金で説明します。

管理の決まりが合わないと、何が起きるか

プロジェクトが長くなると、次の 3 つが分かりにくくなります。何が決まったか。何がまだ決まっていないか。次に動くのはだれか。

編集部の運営会社では、AI(Claude Code)に頼んで、Web のサービスや社内の道具を作っています。その中で、実際に次の 3 つが起きました。

• 指示が会話に散らばった: 画面の見本を何度も直すうちに、細かい指示が AI との会話の中に散らばりました。
• AI の案が「決定」に混ざった: 資料を整理すると、AI が補った細部を「決定」として書いていた項目が 17 件ありました。
• 置き場所が分からなくなった: ある案件の、提出する書類を管理するページの場所を思い出せず、4 か所を探しました。

3 つとも、記録する場所と区分が、仕事の進め方に合っていませんでした。次の節で、既存のサービスの区分と比べます。

既存のサービスの決まりに合わせるとき

プロジェクト管理のサービスは、課題(やること)を分ける型を持っています。たとえば Backlog では、プロジェクトを作った直後に、種別の基本セット(バグ・タスク・要望・その他)と、標準の 4 つの状態(未対応・処理中・処理済み・完了)が用意されています(公式のヘルプ)。

型があると、申し込んだ日から始められます。チームの全員が、同じ言葉で進み具合を話せます。一方で、プロジェクトで要る区分が型と違うときは、次のようになります。

• 区分を足す: 足せる範囲は、サービスとプランで決まります。Backlog では、状態の追加は有料プランで 1 プロジェクト 8 個まで、独自の項目(カスタム属性)はプレミアムプラン以上です。Trello の独自の項目(カスタムフィールド)は Standard から、Asana は Starter からです。Jira は、ワークフロー(状態の流れ)の変更と独自の項目が、無料のプランにもあります。
• 標準の区分は残る: Backlog の標準の 4 つの状態は、名前の変更・並び替え・削除ができません。「未対応」の前と「完了」の後にも、状態を足せません。
• 型に入らない記録は、別の欄に書く: 「ユーザーが送った文そのまま」や「確かめた結果」のような記録は、課題の説明・コメント・ドキュメントの欄に分けて書くことになります。

どちらが良い・悪いという話ではありません。編集部の運営会社の代表は、中長期のプロジェクトでは管理が欠かせないが、既存のサービスの決まりに合わせるより、プロジェクトに合わせた軽い仕組みを作るほうが合うことがある、と考えています。次の節から、その実例を説明します。

編集部の軽い仕組み: 仕様書とボード

編集部の運営会社では、2026年10月1日から、AI と進めるプロジェクトごとに「仕様書」と「ボード」の 2 つの資料を作っています。どちらも、ブラウザで開く 1 枚の Web ページです。

仕様書には、決定した「やること」だけを書く

• 表は「ID・やること・出どころ」の 3 列です(赤枠 2)。出どころの I-04 は、もとになった指示の番号です。押すと、ボードのその行が開きます。
• 状態の欄はありません。進み具合は、ボードで見ます。
• 作り方(使う部品や関数の名前)は書きません。書くのは「何を作るか」です(赤枠 1)。

ボードには、それ以外のすべてを置く

ボードの欄は、次の 6 つです。

確認待ちの案の札には、「仕様へ OK」と「直したい」のボタンがあります。押すと、すぐに保存されます(赤枠 2・3)。OK の札は、AI が仕様書へ移して、ボードから外します。「直したい」の札は、メモを読んで AI が直し、もう一度見てもらいます。

ID の頭の文字は、プロジェクトごとに決めます。見本の仕様書は B-、このメディアの仕様書は H- です。章ごとに頭の文字を変えているプロジェクトもあります。

発言に ID を付けて残す

• ユーザーが送った文を、そのまま残します(赤枠 1)。
• 1 つの発言に指示がいくつもあれば、指示ごとに分けて I-01・I-02 のように番号を付けます。
• 各指示から決めたこと(仕様・案・未決)を、リンクで結びます(赤枠 2)。緑の ID は仕様書、黄色の ID はボードにあります。

こうしておくと、「なぜこう作ったのか」を、仕様の行から指示へ、指示から送った文へとたどれます。

AI が記録を書く流れ

Claude Code の公式のドキュメントには、Claude Code は「reads your codebase, edits files, runs commands」(コードを読み、ファイルを編集し、コマンドを実行する)道具だと書かれています。編集部では、この力を記録にも使っています。仕様書とボードのもとになるデータと、そこから 2 枚のページを作る台本(プログラム)を、AI に書いてもらいました。AI は、指示を受けるたびにデータを書き換え、台本を動かしてページを作り直します。Claude Code のあらましは、Claude Code とは？で説明しています。

このメディア自身のボードにも、同じ流れの記録があります。2026年10月12日の、9 つの題を調べて書いて載せること、ビジュアルをできる限り多く用意することを頼んだ発言は、I-15 と I-16 に分かれました。そこから仕様の H-17・H-18 ができ、載せたあとに V-12(記事の検査で NG が 0 だったことなど)が書かれています。

AI が守る決まりは、次の 4 つです。

• 指示は、作る前に書く。
• AI が補った細部や AI の案を、AI が自分で「決定」にしない。
• ID は振り直さない。取り消したものは、消さずに「取り消したこと」の欄へ移す。
• 書き換える直前に読み直し、変わる所だけを書く。

12 のプロジェクトで、記録は何件になったか

編集部の運営会社では、10月1日から 12日までに、12 のプロジェクトでこの形を使いました。どれも自社のサービス・メディア・社内の道具で、取引先との案件は入っていません。

• 合計は、決定が 904 件、AI の案(確認待ち)が 781 件、決めていないことが 137 件、確かめたことが 205 件、指示の記録が 720 件でした。
• AI の案は、決定に近い数があります。分けて書いていなければ、この 781 件は決定と見分けがつきません。
• 欄は、プロジェクトごとに違います。「取り消したこと」「見本の見る場所」「カテゴリの分け方」「作り方のメモ(AI の判断で、仕様ではないもの)」を足したボードがあります。「確かめたこと」の欄が無いボードもあります。
• 資料の数も違います。方針を書いた「企画」を足して 3 つにしたプロジェクトと、決まったことと案を 1 枚にまとめたプロジェクトがあります。

プロジェクトの種類で、合う形は変わる

公的な資料の考え方

進め方ごとの向き不向きは、公的な資料に書かれています。内閣官房 IT 総合戦略室の「アジャイル開発実践ガイドブック」は、デジタル庁の標準ガイドライン群の 1 つです。政府の情報システムを対象にした参考の文書で、アジャイル開発(短い区切りで、作って確かめることを繰り返す進め方)に向いている領域・不向きな領域・慎重な判断が必要な領域を分けています。

• 計画を先に固める形: 対象の範囲と詳細が先に決まっているプロジェクトに合います。作業を分解した表と日程で、計画と実績の差を見ます。
• 少しずつ反復する形: 作りながら詳細を決めるプロジェクトに合います。スクラム(アジャイル開発の進め方の 1 つ)の公式のガイド「スクラムガイド」は、区切り(スプリント)を「1 か月以内の決まった長さ」としています。ガイドブックは、途中の報告書より、動くシステムを関係者で確かめることを中心に置いています。
• 流れを見る形: カンバンガイドは、カンバンを「あるプロセスを通じて、価値の流れ(フロー)を最適化するための戦略」としています。仕事の流れは、使う人たちが定義します。

ガイドブックには、2 つの進め方の文化を、気づかないまま混ぜないように、という注意もあります。反復して作っているのに、進み具合が心配で報告書を増やすと、流れを止めてしまうことがある、という内容です。

編集部の運営会社で作った 6 つの形

編集部の運営会社でも、プロジェクトの種類ごとに形が違いました。

• AI と進める自社の開発: ここまでに説明した、仕様書とボードです。
• お客さまと進めるアプリの開発: はじめは、この案件のためだけの進み具合の表(ガントチャート)を作りました。その後、自作の課題管理に移しました。種別に「当社作業」「並行作業」「貴社ご対応事項」を足し、状態に「滞留」を足しています。お客さまにお願いすることが、いつからいつまでかを、同じ表で見られます。
• 新しい拠点の立ち上げ: IT 以外の作業が中心でした。計画書のページに、数十のチェック項目と名前つきのコメント、工程の日程表を付けました。日程表の棒を動かすと、本文の日付も変わります。
• 決まった時期に書類を出す継続の案件: 時期ごとに、数種類の書類を出します。出した・まだを一覧にしました。
• 事業の構想の相談: 答えを先に書かず、十数個の問いを「未・仮・持ち帰り・確定」で管理しました。話し合いの場で、メモをその場で書き込みます。
• 増えた資料の置き場: 資料と小さな仕組みが増えて、置き場所が散らばりました。そこで、プロジェクトごとのカードから、目次・概要・リンク集を開けるダッシュボードを作りました。資料は写さず、リンクだけを置きます。

この課題管理は、Backlog に似せて作ったものです。凡例の右側の「タスク・バグ・要望・その他」は、はじめから入っている種別です。左の 3 つ(赤枠 2)が、このプロジェクトのために足した種別です。

向き不向きの表

既存のサービスの料金とできること

総務省の通信利用動向調査では、クラウドサービスを使っている企業のうち、プロジェクト管理に使っている企業は、2014年の 4.8% から 2024年の 19.5% に増えました(令和7年版 情報通信白書の図表。調査の対象は、常用雇用者が 100 人以上の企業です)。代表的なサービスの料金と、区分を自分で決められる範囲をまとめます。

• Jira の料金は、人数で単価が変わります: 料金ページの初めの表示は、300 ユーザーのときの平均(Standard は 1 ユーザー月 1,085 円)です。人数の欄を 10〜100 にすると、1,240 円と表示されます。
• Backlog は、2027年1月1日からプランが変わります: 公式のブログ(2026年6月17日)によると、今の 4 つのプランは、エコノミー(月 21,000 円・15 ユーザーまで)・ビジネス(月 36,300 円)・プロフェッショナル(月 100,000 円)の 3 つになります(月払い・税抜)。今のプランの新しい契約は、2026年12月31日までです。無料のプランのユーザーの上限は、10 名から 5 名になります。
• 数え方が 2 つあります: 人数で数えるサービス(Jira・Notion・Asana・Trello・GitHub)と、契約ごとに数えるサービス(Backlog)です。

10 人で 1 年使う場合、公式の単価から計算すると、Backlog のスターターが 30,780 円(年払い・税抜)、Asana の Starter が 144,000 円(年払い・税別)、Jira の Standard が 148,800 円(月払い・税の表示なし)です。Backlog のスターターは、30 ユーザー・5 プロジェクトまでです。

自分で作るか、既存のサービスを使うか

編集部の仕組みは、小さく作っています。1 つのプロジェクトの仕様書とボードを作る台本は、見た目の決まりを入れて 246 行です。「仕様へ OK」「直したい」を保存する仕組みは 228 行です。できあがるのは HTML のファイルで、専用の DB(データベース)は使っていません。

次のように考えると、選びやすくなります。

• 記録を書くのは、AI か人か: AI が書くなら、AI が直接読み書きできるファイルの形が扱いやすくなります。既存のサービスにも、AI から使う窓口があります。Jira の料金ページには、Standard から上のプランに「Rovo MCP サーバー」の行があります(MCP は、AI の道具とほかのサービスをつなぐ共通の決まりです)。
• 見る人は何人か。社外の人も書き込むか: 人数が多いとき、社外の人が書き込むときは、役割ごとの権限と通知が要ります。既存のサービスが向いています。
• 決まりは、プロジェクトごとに違うか: 違うなら、足せる範囲をプランごとに確かめます。足りなければ、自分で作ることを考えます。
• 直す人はいるか: 自分で作った仕組みは、不具合も自分で直します。直す人と時間が取れないなら、既存のサービスを使います。

自作と SaaS(インターネットを通して、月額などで使うサービス)の費用の比べ方(作る・動かす・直す)は、自作で脱 SaaS はできる？でくわしく説明しています。商談や見積もりの場で、既存のサービスと比べられるときの話は、開発会社から見た SaaS の過去・今・未来に書いています。

まとめ