システム構築丸投げにしない 事業を成功に導くカギは
『システムを作らせる技術』
若手リーダーに贈る教科書次に、顧客が改善すべきと考える業務フローでは、業務内容とその優先度、システム導入の効果とコストとの見合い、新システムの受け入れや実現の可否などをマトリクスにして解説し、経験に基づく著者ならの知見が紹介されています。
そして、最後に導入を考えるプロジェクトを、経営幹部や現場の従業員に説明する時のノウハウとして、「透明性」を挙げます。つまり、プロジェクト関係者以外の人間にもシステム導入の意義がわかりやすく伝えること。一見すると、当たり前のようにも思えますが、そのノウハウは平易に、かつ詳細に記述されています。
その視点は、徹底してシステムを発注する側に向けられ、注意点や心得などを助言しています。
皆さんは自分の現在の業務を「ちゃんと」語れるだろうか？
どういう目的で、なにをインプットして、どういうノウハウで作業して、なにをアウトプットしているのか？ ビジネス全体の中で、自分が担当する業務がどういう役割を果たしているのか？ やらなかったらなにが起こるのか？
同様に、皆さんは将来の業務がどうなってほしいか「ちゃんと」語れるだろうか？ 何を変えたいのか？ なぜ変えたいのか？ 変えた結果、前後の業務とどうつながるのか？
これらをちゃんと語れる人はかなり少ない。これができないと、システムをちゃんと作ってもらえないのに。
組織が部門ごとに縦割りになっているので、自分の部署の作業しか知らないことがほとんど。まるでベルトコンベアの自分の持ち場しか見ていないように。
だが、悲観し過ぎなくても良い。変革プロジェクトで改めて業務フローで業務全体を描いてみると、自然に全体の流れを理解できるようになる。隣の部署（もしくは他の会社）が思ったより大変な仕事をしてくれていること。良かれと思ってやっている作業が、実はやらなくても良かったこと。
プロジェクトも半ばを過ぎると、ビジネスのありようを理路整然と語れるようになっているだろう。
（E章 将来像（HOW）を明らかにする 93ページ）
どういう目的で、なにをインプットして、どういうノウハウで作業して、なにをアウトプットしているのか？ ビジネス全体の中で、自分が担当する業務がどういう役割を果たしているのか？ やらなかったらなにが起こるのか？
同様に、皆さんは将来の業務がどうなってほしいか「ちゃんと」語れるだろうか？ 何を変えたいのか？ なぜ変えたいのか？ 変えた結果、前後の業務とどうつながるのか？
これらをちゃんと語れる人はかなり少ない。これができないと、システムをちゃんと作ってもらえないのに。
組織が部門ごとに縦割りになっているので、自分の部署の作業しか知らないことがほとんど。まるでベルトコンベアの自分の持ち場しか見ていないように。
だが、悲観し過ぎなくても良い。変革プロジェクトで改めて業務フローで業務全体を描いてみると、自然に全体の流れを理解できるようになる。隣の部署（もしくは他の会社）が思ったより大変な仕事をしてくれていること。良かれと思ってやっている作業が、実はやらなくても良かったこと。
プロジェクトも半ばを過ぎると、ビジネスのありようを理路整然と語れるようになっているだろう。
（E章 将来像（HOW）を明らかにする 93ページ）
システムを稼働に移す時に求められること
プロジェクトを進めるなかで必要なパートナー、つまり実際にシステム構築を請け負うITベンダーをどう選んだらよいか。その手法についても、著者は詳細かつ目配りのきいた内容で紹介しています。基本は意思疎通の重要性。発注者が期待している業務改革の内容をベンダーに伝え、いかにコストを抑えて求めうる最善の効果を達成するうえでも、どのように正確にプロジェクトの内容を伝えるかという点です。ベンダーとの間の地道な根回しも欠かせないことを説いています。
近年IT人材が不足している。ベンダーに提案を依頼した際に「人がいない」「メンバーが揃えられない」という声をよく聞く。
選定したベンダーといざプロジェクトの具体的なスケジュールを詰める段になって「人がいないので半年くらいプロジェクト開始を待ってもらえないか」と依頼されることもある。
これまではどちらかと言うと、業務担当者などの社内関係者に参画してもらうことに苦労していたが、潮流が変わってきている。本当に重要なプロジェクトであれば、社内のメンバーは異動などでなんとかなる。だがベンダーは別会社なので、こちらから働きかけても調整できることはわずかだ。
望むタイミングでメンバーを揃えてもらうよう、できるだけ前からベンダーへ体制確保の声がけをするか、ベンダーの人員確保の期間を、あらかじめ計画に組み込んでおくしかない。
プロジェクトの期限が変えられない。ベンダーの人員確保の期間を待てない場合、最悪プロジェクトが立ち上がらない。こういう場合は他の条件で最適なベンダーではなく、今すぐプロジェクト始められるベンダーと組むしかない。エンジニア個人も、会社としてのベンダーも、優秀で売れっ子だからこそ、忙しい。だからスケジュールを優先してベンダーを選定するのは極力避けたい事態なのだが。
（Q章 稼働までの計画を立てる 257～258ページ）
選定したベンダーといざプロジェクトの具体的なスケジュールを詰める段になって「人がいないので半年くらいプロジェクト開始を待ってもらえないか」と依頼されることもある。
これまではどちらかと言うと、業務担当者などの社内関係者に参画してもらうことに苦労していたが、潮流が変わってきている。本当に重要なプロジェクトであれば、社内のメンバーは異動などでなんとかなる。だがベンダーは別会社なので、こちらから働きかけても調整できることはわずかだ。
望むタイミングでメンバーを揃えてもらうよう、できるだけ前からベンダーへ体制確保の声がけをするか、ベンダーの人員確保の期間を、あらかじめ計画に組み込んでおくしかない。
プロジェクトの期限が変えられない。ベンダーの人員確保の期間を待てない場合、最悪プロジェクトが立ち上がらない。こういう場合は他の条件で最適なベンダーではなく、今すぐプロジェクト始められるベンダーと組むしかない。エンジニア個人も、会社としてのベンダーも、優秀で売れっ子だからこそ、忙しい。だからスケジュールを優先してベンダーを選定するのは極力避けたい事態なのだが。
（Q章 稼働までの計画を立てる 257～258ページ）
