社内アプリ開発部門システム
部門からの依頼から従業員の定着・効果測定まで、社内向けツール・アプリを開発するチーム。
社内ツール構築の全サイクル：依頼・分析・開発・テスト・リリース、そして定着と実際の効果測定。
クレジットカード不要 — システム一式が1分でプロジェクトにセットアップされます
これがお手元に届くシステムのボードです。ワークフローの列と、最初のステップを示すスターターカードが並んでいます
このシステムで仕事はどう回る？
部門のニーズは「依頼」のカードとして届き、でき上がった解決策ではなく問題を説明します — 滞っている業務プロセス・困っている人・かかっている時間。カードは「分析」へ移り、アナリストが依頼部門と膝を突き合わせて実際のプロセスを理解し、要件と受入基準をカードに書きます。承認後「開発」へ移り、開発者が段階的な納品で進めます。「テスト」では依頼部門のユーザー自身が試し、気付きを記録します。全従業員への準備が整えば「リリース」へ。旅はリリースで終わりません — カードは「定着」へ移り、従業員の利用と研修をフォローし、「効果測定」でツールが作られた目的のプロセスへの実際の効果を記録します。
チャットは開発者の日次連携と、依頼部門との緊急の要件確認用です。フォーラムは技術判断・大きな要件の議論・リリース後レビューを記録し、後からチームに加わった人が設計判断とその根拠を理解でき、同じ議論を繰り返さないようにします。
アプリマネージャーは依頼を受け取って優先順位を付け、「開発」への進入を承認します。アナリストは「分析」から依頼部門との「テスト」受入までカードに付き添います。開発者は実装し、気付きを処理します。「効果測定」の結果はアプリマネージャーに戻り、決めます — 第2フェーズの開発・現状維持・使われないなら正式に停止。
誰が何を担当する？
このシステムの運用ロールと、日々の仕事における各ロールの責任。そのままチームに割り当てても、自社に合わせて調整しても構いません。
社内アプリマネージャー
部門依頼を受け取って優先順位を付け、「分析」から「開発」へ、「テスト」から「リリース」への移行を承認します。
ビジネスアナリスト
依頼部門のニーズを分析して要件と受入基準をカードに書き、ユーザー受入までテストに付き添います。
開発者
「開発」のカードでアプリを作り「テスト」の気付きを処理し、技術判断を判断時にフォーラムへ記録します。
定着・研修コーディネーター
リリース後の従業員へのツール紹介と研修を主導し、「定着」「効果測定」で利用指標を集めます。
初日から用意されるものは？
システムのユニット
- タスク — ワークフローの列と実行カードを備えたかんばんボード
- チャット — チームの素早い日常調整チャンネル
- フォーラム — 整理されたセクションで記録される議論 — 決定も知識も失われません
フォーラムのセクション (4)
- 技術判断社内アプリ構築で採用したアーキテクチャとツールの選択とその根拠の記録 — 後からコードに触れる人への参照。
- 要件と部門との議論正式分析へ移す前の、依頼部門との大きな要件を巡る詳細な対話。
- リリース後レビュー各リリースでうまくいったこと・つまずいたこと — 今後のプロジェクトのための記録された教訓。
- アイデアと改善新しい社内ツールの提案や既存ツールの改善。チームとユーザーの気付きから。
«このシステムの運用ルール» — フォーラムにピン留め
1. 承認済み分析なしの開発は禁止：書面の要件と受入基準なしにカードは「開発」に入りません。 2. 依頼部門の依頼者がテストに参加します — その受入なしにリリースしません。 3. 技術判断は事後ではなく判断時にフォーラムへ記録します。 4. リリースは、記録された定着フェーズと効果測定を経るまで完了とみなしません。 5. 使われないツールは枯れさせず、記録された決定で正式に停止します。