業務システム · デモプロジェクト
プロジェクトを相談Fieldnote
ソフトウェア開発の納品管理
マイルストーン、担当、レビュー結果を共有。
架空のブランドとサンプルデータによるコンセプトです。実際の顧客への納品事例ではありません。
業務の課題
タスクや修正意見が散らばると、次の行動が分かりにくくなります。
解決の考え方
工程をタスクと確認記録に結びつけ、担当と判断待ちを明確にします。
03 /
機能計画と業務ルール
画面の利用場面をもとにした要件案です。具体的なルールと連携範囲は開発前に合意します。
利用者の役割
プロジェクト管理者、開発者、テスター、顧客レビュアー
業務フロー
- 1タスクと反復を計画
- 2開発し阻害要因を解消
- 3顧客レビュー
- 4版を受入確認
タスクと計画
ID、目的、受入条件、担当、優先度、期限を記録します。追加要望は出所を残し、今回の範囲に入れるか判断します。
ボードと状態遷移
未着手、開発、レビュー、完了を区別します。レビューには証拠資料が必要で、状態変更の担当者と日時を残します。
阻害要因と依存
API認証情報の不足などに担当と確認日を設定します。期限超過だけでタスクが自動完了することはありません。
顧客レビュー
権限のある顧客が承認または具体的修正を依頼します。差し戻しは以前の記録を残して再開し、内部費用は公開しません。
ファイルと版
デザイン、デモ、テスト報告を版付きで関連付けます。差し替えでも履歴を残し、非公開資料は取得時に権限確認します。
節目と引き継ぎ
タスク、未解決事項、版、判断をまとめます。成果物、設定説明、操作文書と受領記録を権限のある人が確認します。
具体的な利用例
FLD-121は顧客環境の認証情報待ちです。担当付きの阻害要因として追跡し、準備後にテスト報告を提出します。修正依頼では最初のレビューを保持してタスクを再開します。
受入確認の例
- 必須資料不足や未解決の阻害要因があれば無条件に引き渡し済みにしません。
- 差し戻し後も以前のレビューを保持します。
- 除外したメンバーは古いURLから非公開資料を取得できません。
連携と対象範囲
役割、顧客への公開範囲、受入権限を合意します。リポジトリ、CI、SSOは任意で、時間課金、給与、自動的な従業員評価は標準範囲外です。
