システム発注者(ベンダー側)が要求依頼する前に用意すべきもの。受注者(メーカー側)も意識すべきこと。

システム発注者(ベンダー側)

以下をよく整理してから要求依頼をしてください。
私のメーカーでの開発経験では、以下ができていた開発はすべて発注側、受注側、共にストレスや軋轢の発生がとても少ないまま、PJが成功していたと記憶しています。

  • 開発体制(だれ?)

    • PM(要求要件の管制)

    • 運用目線の第三者(ユーザ観点レビューワ)

    • PG(Webシステム開発者)

  • 開発の現状進度(どこ?)

    • ビジョン・理想・哲学・経緯・熱量・思い・文化・原理・ポリシー

      • ビジョン/理想/哲学(どこへ行きたいのか)がまだない場合

      • 現状・事実…ブレスト+KJ法でクラスタリングして整理整頓をし

      • 理想…ロジックツリー+集約でMapReduceし、

      • 解決…ギャップ分析せよ。
        ⇒これを経緯とし、そこからビジョン/理想/哲学を作り出せ。

      • 文化・原理・ポリシー

        • 文化…どのような業務をしているか?

          • Web開発・・・ユーザーの運用のし方、運用設計

          • データ・・・どのようにデータが生まれるか

        • 原理・・・重視すべき物事の道理

        • ポリシー(原則)・・・原理から導かれるやっていい事、ベストプラクティス

    • 本番運用まで見据えたドキュメント

      • 線表(いくら/いつまで)

        • 要求定義

        • 予算(ITストラテジストの観点を踏まえて。)

        • コンセプト

        • アーキテクト

        • 画面動作イメージ

        • 大まかな状態遷移図

        • アーキテクチャ図

        • 想定人数/年間

        • 頻度/日

        • 営業日と営業時間

        • 1プロセスの許容時間

受注者(サプライヤー側/メーカー側)

発注者側は、ほとんどの場合は、上記すべてを意識できていないため、
メーカー側も、哲学/経緯/文化/熱量についてまず、力を入れてヒアリングし、以下の課題形成の構造(ストラクチャ)を意識した上で、上記を聞き出す姿勢でいてください。


課題形成ストラクチャ

何かあってからでは遅いのだ。

おわりに

孫子:「勝敗は、戦う前に決まっている。」(※メーカーとしての私の座右の銘)

以下参考です。

はじめての要件定義で読むべきIPAドキュメント #要件定義 - Qiita

要求定義(要求エンジニアリング)とは何か?要求定義書作成の進め方をわかりやすく解説【プロジェクトマネジメントの基礎】 | Promapedia(プロマペディア) (ssaits.jp)

運用設計とは?必要項目や設計の流れ・ポイントをイチから解説! (sint.co.jp)

本記事と合わせて、以下も読むと開発体制の見直しができるのでお勧めです。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

この記事が気に入ったらサポートをしてみませんか?