システム発注者(ベンダー側)が要求依頼する前に用意すべきもの。受注者(メーカー側)も意識すべきこと。
システム発注者(ベンダー側)
以下をよく整理してから要求依頼をしてください。
私のメーカーでの開発経験では、以下ができていた開発はすべて発注側、受注側、共にストレスや軋轢の発生がとても少ないまま、PJが成功していたと記憶しています。
開発体制(だれ?)
PM(要求要件の管制)
運用目線の第三者(ユーザ観点レビューワ)
PG(Webシステム開発者)
開発の現状進度(どこ?)
ビジョン・理想・哲学・経緯・熱量・思い・文化・原理・ポリシー
ビジョン/理想/哲学(どこへ行きたいのか)がまだない場合
現状・事実…ブレスト+KJ法でクラスタリングして整理整頓をし
理想…ロジックツリー+集約でMapReduceし、
解決…ギャップ分析せよ。
⇒これを経緯とし、そこからビジョン/理想/哲学を作り出せ。文化・原理・ポリシー
文化…どのような業務をしているか?
Web開発・・・ユーザーの運用のし方、運用設計
データ・・・どのようにデータが生まれるか
原理・・・重視すべき物事の道理
ポリシー(原則)・・・原理から導かれるやっていい事、ベストプラクティス
本番運用まで見据えたドキュメント
線表(いくら/いつまで)
要求定義
予算(ITストラテジストの観点を踏まえて。)
コンセプト
アーキテクト
画面動作イメージ
大まかな状態遷移図
アーキテクチャ図
想定人数/年間
頻度/日
営業日と営業時間
1プロセスの許容時間
受注者(サプライヤー側/メーカー側)
発注者側は、ほとんどの場合は、上記すべてを意識できていないため、
メーカー側も、哲学/経緯/文化/熱量についてまず、力を入れてヒアリングし、以下の課題形成の構造(ストラクチャ)を意識した上で、上記を聞き出す姿勢でいてください。
何かあってからでは遅いのだ。
おわりに
孫子:「勝敗は、戦う前に決まっている。」(※メーカーとしての私の座右の銘)
以下参考です。
はじめての要件定義で読むべきIPAドキュメント #要件定義 - Qiita
要求定義(要求エンジニアリング)とは何か?要求定義書作成の進め方をわかりやすく解説【プロジェクトマネジメントの基礎】 | Promapedia(プロマペディア) (ssaits.jp)
運用設計とは?必要項目や設計の流れ・ポイントをイチから解説! (sint.co.jp)
本記事と合わせて、以下も読むと開発体制の見直しができるのでお勧めです。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon