最終更新: cloudhands 2018年09月01日(土) 18:52:01履歴
ITシステムを開発ベンダーに発注するに当たって一番重要なものは要件定義書です。発注者と受注者でのトラブルの多くは要件定義に起因しています。
要件定義書の具体的な書き方については、それだけで一冊の本になるぐらいのボリュームなのでここでは割愛します。
ここでは、要件定義を作成するための体制(要員)について書いてみます。
例えば、企業などでITシステム構築の話があがってきて、自組織の業務にも関係あるシステムであり、自組織からもプロジェクトに参加するメンバーの要請があったとします。
よくある話として、「あいつパソコンとか詳しいから、あいつでいいんじゃないか」というような流れで担当が決められるということです。
要件定義は、業務要件とシステム要件に分けられると書きましたが、まず作成しないといけないのは業務要件で、これが十分に検討されていないと、いざシステムが出来上がったときに「これでは業務にならないじゃないか」ということになりかねません。
というわけで、要件定義を作成する要員は、業務に精通した人でないといけません。先の例のようにパソコンやシステムに詳しいという観点で選ぶべきではありません。
また、できれば業務的な権限を持つリーダークラスの人を選ぶべきでしょう。システム化にあたって、業務の見直しが必要な可能性もあるためです。
業務を要件定義書に落とし込む人は、プロジェクト体制の中に別途配置すればよいのです。それぞれの業務担当組織から配置するメンバーはシステムに関する知識は必須でありません。
プロジェクト管理者の立場になる人は、必要な業務知識を持つ人がメンバーに含まれているかを十分に検討して欲しいです。
要件定義書の具体的な書き方については、それだけで一冊の本になるぐらいのボリュームなのでここでは割愛します。
ここでは、要件定義を作成するための体制(要員)について書いてみます。
例えば、企業などでITシステム構築の話があがってきて、自組織の業務にも関係あるシステムであり、自組織からもプロジェクトに参加するメンバーの要請があったとします。
よくある話として、「あいつパソコンとか詳しいから、あいつでいいんじゃないか」というような流れで担当が決められるということです。
要件定義は、業務要件とシステム要件に分けられると書きましたが、まず作成しないといけないのは業務要件で、これが十分に検討されていないと、いざシステムが出来上がったときに「これでは業務にならないじゃないか」ということになりかねません。
というわけで、要件定義を作成する要員は、業務に精通した人でないといけません。先の例のようにパソコンやシステムに詳しいという観点で選ぶべきではありません。
また、できれば業務的な権限を持つリーダークラスの人を選ぶべきでしょう。システム化にあたって、業務の見直しが必要な可能性もあるためです。
業務を要件定義書に落とし込む人は、プロジェクト体制の中に別途配置すればよいのです。それぞれの業務担当組織から配置するメンバーはシステムに関する知識は必須でありません。
プロジェクト管理者の立場になる人は、必要な業務知識を持つ人がメンバーに含まれているかを十分に検討して欲しいです。
タグ
コメントをかく