システムを導入するとは？#1

システムを導入するとは？#0でも記載しましたが、今回の参考著書は細川義洋氏の「システムを外注するときに読む本」です。
この本は本当に読やすいので、まとめる意味があるのか？と自問自答していますが、本を読んで（インプット）してまとめる（アウトプット）するトレーニングとしてやってみます。

導入を検討している側（顧客）と提案する側（ベンダー）の視点が分かるように進めていきます。

参考図書

システムを「外注」するときに読む本

第1章　システム作りは業務フロー図から
～「本当に役立つシステム」を作るために、まずやるべきこと～

第1章の読み方

この本の素晴らしいところはそのストーリー性だけでなく、最初に要点をまとめてくれているところも素晴らしいです！

・システム作りは要件定義から
・要件定義とはシステムとそれを使う人の動作（業務）を決める作業
・要件定義は「業務要件定義」と「システム要件定義」に大別され、業務要件定義は発注者自身が全面的にリードしなければいけない
①業務要件定義
新しくシステムを導入し、どんな業務を実現するかを決める。システムの技術を意識せずに書き出す
②システム要件定義
業務要件定義の内容を実現するために、システムに必要な機能を書き出す。各業務で必要な入出力、論理演算、速度、容量、操作性、セキュリティなどを決めていく
・業務要件定義書の作成前に絶対不可欠なことは”社内全体の業務を俯瞰して全体最適の視点から業務の問題点や新しいシステムが実現することで改善される点、全社的な効果が分かるようにすること”
・第1章では、発注者企業のシステム担当者が持つべき心構えについて説明

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P26～29参照

第1章のまとめ

さらにまとめまでしてくれています。ただ転記しているだけにならないように理解しながら作ってます。
本書には各章にはAppendixがついており、一般的なチャート図など詳細な説明もあります。この辺りは自作の絵の作成が必要になると思うので、時間を見つけて作成し、最後にまとめて公開するようにします。

①システム導入の目的を忘れないように書き留めておく
②業務フロー図には懸念事項や課題も漏れなく書き込む
③システムを導入することで誰が喜び、誰が困るのかも書き込む
④システム化の範囲は効果が明確に説明できる部分に限る
⑤システム担当者自身が、業務をどのように改善するのかという「意思」を持つ
⑥システム担当者になれば、自分の想いは隅に置いて、改善の推進者になりきる

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P82参照

＜1-1＞どんなシステムを作るかを決めるのは誰か？

・システム開発を専門のITベンダに外注する場合でも、「どんな機能や性能を持つシステムを作るか」を決めるのは発注者側の役割

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P31～39参照

＜1-1　所感＞

丸投げITシステム。という言葉はよく耳にします。どうしても業務は分かるがシステムのことになると良く分からない。というスタンスで打ち合わせを重ねるごとに熱意が下がっていく人は多くいます。
業務を洗い出して、一緒に課題を見つけていきましょう。それが終われば次は・・・とステップを示してあげて、システムの話も理解してもらえるような提案がベンダ側も必要です。

＜1-2＞要件定義は2つの業務フロー図を作るところから

・要件定義は「現状の業務フロー図（As-Is）」と「実現される業務フロー図（To-Be）」の二つを書き出すことから始める。As-Isのフロー図から、今の業務の問題点を明らかにし、なにを改善するかを決める

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P39、40参照

＜1-2　所感＞

システムを提案する業種によっては、As-Is、To-Beという言葉が出てきただけでイヤな顔をする方もいるかもしれません。英語表現は便利ですが、相手に合わせて日本後で表現するなど工夫は必要です。

＜1-3＞業務フロー図を書く人がついやってしまいがちな「ワナ」

・業務フロー図を書く人がやってしまいがちな「ワナ」は、「システム化する範囲を決めてしまい、システムすべきでない業務を含めたり、本来システム化する業務を見落としてしまう」こと

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P41～44参照

＜1-3　所感＞

変にシステムに詳しくなってしまうと、この目線は見失ってしまいそうです。最終的に見積りが出てくれば、機能を落として発注額を落とすこともあると思うので、ベンダー側もしっかり要求に沿って機能の優先度は示してあげるべきです。

＜1-4＞システム化する範囲を間違えないたった1つの判断基準

・システム化する範囲を間違えないたった1つの判断基準は「効果が明確に説明できる部分だけ」
・システム化する範囲を決めた後は、業務の内容と入力・出力を箇条書きにすることで要件定義を作っていく。また業務間のやり取りする情報を決め、項目名や内容を誰が見ても分かるように記載する

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P45～49参照

＜1-4　所感＞

効果を明確に説明できる部分だけ。というのは重要ですが、恣意的にならないように全体最適の結果を合意（コンセンサス形成）しておかないといけないです。これが実は一番難しいと思うので、システム要件定義に入る前に、責任者を含めた会議でスコープを決めることが重要です。

＜1-5＞業務フロー図を書く人に必要なメンタリティがある

・システム導入の責任者ないし、トップはシステム導入の目的を関係者に繰り返し説明し、共有する必要がある
・システムを使う人全員の導入による効果、導入しないときの苛立ちや感情を含めてすべて共有しなければ、システム導入は成功しない

引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 　P62～73参照

＜1-5　所感＞

このセクションが最も重要な出発点のように感じました。恣意的に単に楽したいからシステムを導入する。というのは成功しないですよね。
しかも導入して楽になると思いきや、マスタデータの整備や保守費用など結構工数や出費があることを理解していない人も多いので、関係者にしっかり熱意を共有することが重要です。