ITシステム開発はなぜ失敗するのか？

１） 業務要件が決められない業務担当者

今回のシステム化の領域は、紙やEXCEL、断片的に存在する個別のシステムで行われている一連の業務のシステム化であった。　そのため、各部署での業務内容をヒアリングし業務要件を整理していく必要があったのだが、システムエンジニアが何度もヒアリングをして業務内容を整理し、担当部署に確認してもらっても、なかなか業務要件が確定できない。　理由は、担当部署がそもそも業務を正確に理解できていないことが少なく無かったからである。　"先代から受け継いだ作業"(?) を粛々とやっている状態であり、業務の全体像、詳細内容とその目的や理由が現場の担当者ですら見えていないことがあった。　この状態を克服するためには、システムエンジニアが忍耐強くヒアリングを重ね業務を理解するしかない。　結果として、システムエンジニアが業務担当者よりも業務をより深く知ることができ、後工程であるTo-Be の業務フローのデザインはスムーズに行うことができた。 システムエンジニアには、強い忍耐力とコミュニケーション能力、そして理解力が求められる。

２） 汚れたデータのクレンジング

断片的に存在する個々のシステムや個々のEXCELに保存されているデータは、もともと他のシステムとの連携や他の目的での利用を前提としていないため、個別の業務上で問題なければよいという入力のしかたによって蓄積されたデータであった。　そのために、入力方法に相当なバラツキがあるだけでなく、多くの貴重なデータが "備考カラム" に非定型フォーマットで書かれているケースが多かった。　また、各種マスターについても作成ルールが曖昧で、例えば同一企業に複数のコードを割り当てているなどといったケースも少なくなかった。　さらにEXCELに至っては、"お絵描きツール" 的なレイアウトでのデータ入力が行われていてレコードとして抽出できないようなものや、削除すべきデータをEXCELの書式によってグレーアウトしていたり文字に取り消し線をいれていたりして、一括抽出しようとすると本来削除されているべきデータまで抽出されてしまうということもあり、大いに悩まされた。　このような "汚れたデータ"　のクレンジング作業は、パターンを見つけ出してクレンジングツールをプログラムで作成し対応することもやってみたのだが、それでも限界があり、最終的には現場の業務担当者の手作業に頼らざるを得ない。　多忙な担当者および担当部署長に、理由や作業の目的、結果として得られるメリットなどを説明し納得いただくことで、相当な工数がかかったものの、無事にデータ移行に耐えられる品質のデータにクレンジングすることができた。　システムエンジニアには、卓越した交渉力が求められる。

３） ネガティブキャンペーン

どんなシステム開発においても、業務の現場の保守的な対応に悩まされることが少なくない。　今回のシステム開発においては業務要件の整理や全体設計、それに伴うマスターやデータベース設計をしっかりと行った上で、細かい画面レイアウト、画面遷移や例外的な業務フローについては所謂アジャイル的に開発を行った。　粗々な画面とクレンジング前の不完全なマスターやデータによるプロトタイプを作成し、各業務の現場のユーザーに見てもらい修正すべき点や不具合を洗い出してもらい、修正していく。　そんなやり方をとった。　しかしながら、これに慣れていないユーザーにとっては、開発サイドからのテスト／確認の目的の説明や摺合せが不足していたこともあり、少しでもおかしい挙動があったり、おかしなデータが見つかった時点で、「こんなもの使い物にならん！」、「あいつら、とんでもないもの作っている」 となり、テストを中止してしまうことが多々あった。　それでも、テストしてもらわないことには開発が進まないこともあり協力を依頼したのだが、コミュニケーションミスもあり、結果的には業務部門、ユーザー部門からのシステム開発に対するネガティブキャンペーンに発展してしまう事態となってしまった。　「あんなやり方では、絶対に上手くいかない」、「とんでもないシステムをつくろうとしている」、「そもそもあんな画面ではユーザーに対して失礼だ」というような声が業務部門側でささやかれてしまう状況である。　事前にアジャイル開発を行うこと、テストしてもらうものは試作品であり完成品とはほど遠いものであるが大まかな動きを確認することが目的であること、データはテストデータであることなどを説明し理解してもらっていたはずであったが、システム開発側の説明不足、コミュニケーション不足によってこのような事態を招いてしまったと反省している。　システムエンジニアには、相手の気持ちに立つことのできるカウンセリング能力が求められる。

４） システム開発の主役

上記１～３の根本原因もコレであると思うこと。それは、システム開発の 「主役」 は業務部門であるということのコンセンサスが得られているかどうかということである。　特に中規模以上のシステム開発を経験していない業務部門担当者は、システム開発部門が "完璧なもの" をつくり、"不具合なくすぐに使える" 状態に仕上げ、それを使うと "現場はすぐに楽になる" と考えがちである。　ユーザー部門は　「お客様」 であるという意識がどこかに残ってしまうのだろう。　　非常に難しいことではあるが、プロジェクトの計画段階で、システム開発の主役は　"業務部門"、"ユーザー部門"　であること。　その主役の要件、意見をシステムに最も良いカタチで反映するために開発のプロセスをウォータフォールとアジャイルの組み合わせで行うこと。　それゆえ、"業務部門"、"ユーザー部門" に主体的に動いてもらう必要があること。　最終ゴールを共有し、システム開発部門との "共創" していくこと。　それらを明文化しコンセンサスを得ておくべきだったと思う。　システムエンジニアには、プロデューサー能力が求められる。