進め方のネタ帳 個人メモ (→Cacooへ?)

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
進め方のネタ帳 個人メモ (→Cacooへ?) создатель Mind Map: 進め方のネタ帳 個人メモ (→Cacooへ?)

1. 社内で根っこを共有するまで

1.1. (要求定義の初期、に近い?)

1.2. 事業目的

1.2.1. 読むと「ふーん、そんなんやってんのね」くらいでもいいのでは?

1.2.2. この開発が必要な目的

1.2.3. 現状の問題点

1.2.4. などなど…

1.3. 現状把握

1.3.1. 現行メイン業務の把握

1.3.1.1. 概要(ほんとざっくりが良さそう)

1.3.1.1.1. (絡まない業務は不要)

1.3.1.1.2. 現行の業務

1.3.1.1.3. フェーズ2以降の業務シナリオ

1.3.1.1.4. 完成後の業務シナリオ

1.3.1.2. ちょっと掘り下げ

1.3.1.2.1. 予約~来店~退店

1.3.1.2.2. 精算~集計(CP、店舗、経理)

1.3.1.2.3. などなど…

1.3.2. 登場人物の把握

1.3.2.1. メイン業務

1.3.2.1.1. 店舗

1.3.2.1.2. 予約センター

1.3.2.1.3. CP

1.3.2.1.4. 客

1.3.2.2. ほか(サポなど)

1.3.2.2.1. 川崎制作

1.3.2.2.2. 埼玉制作

1.3.2.2.3. 開発

1.3.2.2.4. マーケ

1.3.2.2.5. 管理部

1.3.2.2.6. 事務局

1.3.2.2.7. 意思決定者

1.3.2.2.8. 経理

1.3.3. 現行システムの把握

1.3.3.1. (すぐに掘り下げなくていいものは把握のみ)

1.3.3.2. websystem

1.3.3.2.1. control

1.3.3.2.2. sales

1.3.3.2.3. members

1.3.3.2.4. hl

1.3.3.2.5. 営業ページ

1.3.3.3. 外部

1.3.3.3.1. spreadsheet

1.3.3.3.2. gas

1.3.3.4. ローカル

1.3.3.4.1. excel

1.3.3.4.2. レジ

1.3.3.4.3. 日報送信

1.3.3.5. などなど…

2. よくあるシステム導入の段取り

2.1. ウチがその通りやるべきかは別として

2.2. 仕様に着手する前段階なので、資料の見栄え出来栄えは関係なし

2.3. 社内都合で詰められない部分はおそらくある

2.3.1. 詰められない部分を明確にして共有しておく

2.3.1.1. 共有すればシステムに余白を持っておいてもらえる

2.4. AI時代の基礎教養「システム開発」の超基本を5分でつかむ

3. 【参考】 要件定義とは何?スムーズな進め方や成果物(要件定義書)についても解説 | Backlogブログ

4. 要件定義

4.1. 業務要件

4.1.1. 業務の整理

4.1.2. 全体の業務フロー確認

4.1.2.1. 代表的な業務とその流れを、 登場人物を絡めながらまとめてみては?

4.1.2.2. 【参考】 【具体例で実況中継】ITの「業務要件定義」はどう決めるか?

4.1.3. (ボリューム多くて取っ散らかるなら) 個別の業務フロー確認

4.1.3.1. 各登場人物からの視点で 業務の流れをまとめてみては? (資料化なくてもいいと思う)

4.1.3.1.1. これ掘り下げてる途中に「あ、これ必要かも」が出てくると思うので、 ひとまずメモっといて後で選別

4.1.3.1.2. 客

4.1.3.1.3. CP

4.1.3.1.4. スタッフ

4.1.3.1.5. 予約センター

4.1.3.1.6. 店舗責任者

4.1.3.1.7. 経理

4.1.4. 業務要件の確定

4.1.4.1. 業務の設計

4.1.4.1.1. 業務やタスク自体を変える必要がある?

4.1.4.1.2. 業務やタスクは変えずにシステムに代替させる?

4.1.4.1.3. 業務の最終形を確定

4.1.4.2. ここまでは、社内で言う「仕様」を作るための準備で、 繰り返しになるが発注者マター

4.1.4.3. 決めた要件で100%行けることは無いでしょうが

4.1.4.3.1. ここが曖昧だと、できたシステムに合わせるため 無茶なオペレーションを要求することになってしまうイメージです

4.1.5. Cacooに起こす

4.2. ■最上段からここまでは、 原則としてシステムを考える必要がない、発注者マター

4.3. 機能要件

4.3.1. (要件定義、仕様っぽいこと)

4.3.2. 業務要件のうち、 システム開発で解決する内容を決める

4.3.2.1. 開発しない、人力

4.3.2.2. システムに置き換えると、業務がどうかわるか

4.3.2.3. システム開発・実装する部分を決める

4.3.2.3.1. その機能の役割はなにか 開発・実装して何をもたらすか

4.3.3. システム開発が必要な内容が決まったら、 その内容を丁寧に揉もう (=上流工程を丁寧に)

4.3.4. 実際には機能/非機能要件がある

4.3.4.1. 非機能要件は、バックエンドのかたに 気をつけるべきところを指摘してもらったほうがいい気がする