ソルクシーズグループのITコンサルタントが執筆した【ユーザー企業側からみたITプロジェクトのノウハウ本】。
この本は、目次※を見るだけで
・今、取り組んでいる / これから取り組むシステム開発のフェーズ
・システム開発で自分が悩んでいる問題
に役立ちそうなRULEを見つけることができます。
※目次は、インフィニットコンサルティングの書籍紹介ページでご覧いただけます。
過去に、編集部Bossが気になる箇所について紹介しました。
・【RULE02】ITプロジェクトは人選が運命を決める
・【RULE05】企画がダメだとすべてダメになる
・【RULE30】社内合意していないRFPは無意味
・【RULE57】管理者も仕様から逃げない
・【RULE73】その遅延は本当にベンダーのせいか
今回は、現場SEに気になるRULEを選んでもらい、編集長である私：れいが読んで紹介します。経営層であるBossが選んだRULEと比べてみるのも面白いかも。
まずひとつめに選ばれたRULEはコレ。
● RULE27 業務フローで自社の説明責任を果たす
「業務フロー」というのは、自社の業務の流れ（フロー）を、時系列に表現したものです。一般的に部署別に枠を分けて、部署間の情報の受け渡しを明確にするためにも利用されます。
システム開発を依頼するとき、ベンダーに自社の業務を理解してもらうためには「業務フロー」を見せるのが一番、と筆者は言います。
しかし、この「業務フロー」を作成していない会社も多いのです。理由は簡単、「作成するのに手間がかかるから」。初回作成時はもちろん、業務手順や情報に変更があったら更新しなくてはいけません。
大変だから作りたくない、その気持ちはわかります。
では、「業務フロー」がないまま、システム開発を始めてしまった場合どうなるでしょう？
筆者によると、システムを作ってから「業務の流れと合わない」「この処理ができない」という問題は多く発生しているそうです。これは「業務の考慮もれ」が原因。
そして「ベンダーが業務をよく理解していなかったから」と責任を負わせてしまう。
｢業務フロー」を作るのが大事、と言いたいわけではありません。ベンダーに自社の業務を理解してもらう手段があることを知り、その例として「業務フロー」を活用しましょう、と提案しています。
ベンダーに自社の業務を理解してもらう努力をしていますか？
●『情シス・IT担当者［必携］ システム発注から導入までを成功させる90の鉄則』（技術評論社） 4月11日 発売
●本に関する詳しい情報、およびご購入方法は「株式会社インフィニットコンサルティング」の書籍紹介ページでご確認いただけます。
