見出し画像

システム開発フロー:棚卸

画像1

目的

自分がやっている業務の棚卸。
社内のITコンサルタント、SEとして働いていると上流から下流まで一括で担当し、開発エンジニアも同じ方に依頼することが多い。
業務フローや作成資料など属人的なものが多くなってしまうので共通のフレームワークを勉強しなおして業務をブラッシュアップしたい。



要件定義

・問題のヒアリング(リスクの大きさ、頻度)
・課題の定義(必須要件、希望要件に分ける)
・ステークホルダーの洗い出し

・非機能要件の洗い出し
セキュリティ、保守・運用、エラーなどリスク洗い出し
※ある程度基本設計、詳細設計が決まって運用イメージつかめるようになってからヒアリング(プロトタイプあるといい)


工程の最終Output:要件定義書にまとめる



基本設計(外部設計)

お客様に見えるところを決める(ユーザーとの合意形成レベル)
お客様に見えるところ=システム概要(機能一覧、動作環境、スケジュール)

※ざっくり何したら、どんな結果が出るというInput、Outputを明確にするイメージ。UI、UXはリリース後に改善していくイメージ。

工程の最終Output:ユーザーへのシステム説明書、最終Outputに対するユーザーとの合意形成




詳細設計(内部設計)

プログラム構造、データの流れ(エンジニア依頼レベル)

※何を作るかだけでなく、最終的なOutputをどのように評価(仕様書どおりか、エラーがないか)するかテスト項目なども明確にしておくこと。
先にテスト項目を作成しOutputを抑えたうえでシステム仕様を考えると余計な機能などの判断がしやすい。

工程の最終Output:システム仕様書(依頼書)、単体・結合・総合テスト項目一覧




テスト環境実装(ステージング環境実装)

ごりごりとプログラムを書く

工程の最終Output:ステージング環境での実装




単体・結合・総合テスト

詳細設計で作成した「単体・結合・総合テスト項目一覧」をもとにテスト。

工程の最終Output:チェック済みの単体・結合・総合テスト項目一覧


本番環境実装

ユーザーへの広報、リリース後のエラー対応や保守運用対応について再度確認、旧環境からの移行作業が必要な場合は移行スケジューリング

工程の最終Output:プロダクトリリース




保守・運用

エラーやユーザーからのお問い合わせ対応

ただエラーや問い合わせに対応するのではなく、普及率、お問い合わせ件数、使用回数などモニタリング指標を設定し、改善するように改修・改善を行う。

いいなと思ったら応援しよう!