システムを導入するとは？#2
この本は本当に読やすいので、まとめる意味があるのか？と思いながらも第2章に進めます。
本書内では、各セクションで要点も強調されています。それを抜き出す作業にも近いですが、noteで見てみると後で振り返るのはちょうどよいと思っています。
Appendixで示されているチェックシートやフロー図は関係者と確認できるようにファイルを置きましたので機会があれば利用してみてください。
参考図書
第2章 発注者がこれだけは知っておくべき最低限のこと
～自社の業務を正確に知っているか～
第2章の読み方
この本の素晴らしいところはそのストーリー性だけでなく、最初に要点をまとめてくれているところも素晴らしいです！
・自社のシステム開発を担当する立場になれば、改めて社内の業務を勉強し「自社の業務」をしっかり理解する必要がある
・システム開発に意欲の低い人たちが関与する影響を説明
・システム導入に限らず、プロジェクトを進めるうえでは、「役割、責任、権限、知識」が明確にそろっていなければ円滑に進まない。
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P88～91参照
第2章のまとめ
・システム担当者にはシステム化する対象業務の知識が必要
・発注者側の責任で頓挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるために、経営者の視点で導入の意味や目的を考える
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P140参照
＜2-1＞ベンダに協力せずに失敗したときの損害は発注者が保障する
・発注者側に責任があってプロジェクトが中断した場合は、たとえ仕事が完成しなくてもベンダは作業をした分の請求をすることができる
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P104～109参照
＜2-1 所感＞
当たり前な内容ですが、要件定義であれ発注し、ベンダ側に成果物を保証させるのであれば、発注側も真摯に対応しないといけないです。
＜2-2＞要件定義に必要な発注者とベンダの協力関係とは
・要件定義から設計フェーズで発注者が知っておくべき最低限のことは
「ベンダの作る画面がイメージにあっているか、やり取りするデータに過不足や間違いがないか」を確認するために、実際の業務をしっかり把握すること
＜発注者＞
＋要件定義で業務フロー作成から始めて業務要件に落とす
＜ベンダ＞
＋システム要件定義とは機能および非機能要件定義を合わせたもの
＋機能要件定義とは、各業務を実現するためにはどんなインプットにどのような演算処理をしてどのようなアウトプットを出すかを決める。
このような入力・演算・出力のセットのこと
＋非機能要件とは、システムの処理速度・容量・使い勝手、セキュリティのような機能以外に実現すべきことをまとめてもの
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P111～120参照
＜2-2 所感＞
第1章のまとめの⑤にもありましたが、「システム担当者が業務をどのように改善するのか意思をもつ」というマインドがないと導入前にコケることは明らかです。
ましてや要件定義に多くの時間を割いて、高額なシステムになるほどその意思を長期間持続できないと成功はしないと思います。
人事異動など担当者が変わってしまうことがないように、会社全体でシステム導入を自分ごととして支援する必要があります。
＜Appendixの参考資料＞
この記事が気に入ったらサポートをしてみませんか？