「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する

<追記>

追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949

 

エクセルでできることができない何百万のシステム・・

多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。

 

オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。

大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。

 

まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。

 

本当にやりたいことを見つける

システムの要件定義のキモは

• 必要なこと
• やりたいこと
• やらないこと

をうまく選別することにあります。

 

必要なことは、システム構築の目的そのもの。達成したい目標です。

やりたいことは、システム構築の主目的ではないものの、業務改善だったり、生産性向上につなげるための付加価値部分。費用如何では切り捨てる要望です。

やらないことは対象外要件。何でもかんでもシステム化したらお金が足りなくなるため、限界点を必ず決めます。

 

 

増田さんの状況の分解

さて、上記増田さんのネタを分解してみます。

 

Excel云々の話は、おそらく「やりたいこと」に分類できると想定できます。

基本的に、既存のExcelなどで実現できている業務を直接システム化することはまずありません。

だって、現状のツールで間に合っているわけですから。満足しているものをシステム化するってのは余計なコストを掛けることになるのでまずありえません。

 

情報管理という言葉があることから、EDIやECなどの売上管理、商品情報管理、顧客管理などの、おそらく情報更新（以下更新系）がある業務の改善が目的と推測できます。

 

更新系業務がある場合、私の経験上ですが「入力コンプライアンスのチェックによる情報整合性の確保」「情報の蓄積」「商品情報や売買情報の他社システムへの連携」など、情報の登録や連携を目的にシステムを構築することが多かったです。

で、この手の更新系業務の改善の場合、Excelなどのツールではシステムに太刀打ち出来ないことが多い。

与信管理などの複雑な情報の整合性を取り、誤りのないデータ入力は、どうしても人力チェックとなってしまうExcelによる情報管理では限界が出てしまうんですね。

 

 

てなわけで、おそらく増田さんの会社でも何らかの情報を入力や管理するための業務改善のためのシステム導入があり、その一環として情報を参照するためのツールであるExcel帳票の話になったッて感じと予想されます。

 

というわけで、勝手に要件を整理すると

• 必要なこと　　・・・　情報の登録更新などの管理機能
• やりたいこと　・・・　既存業務を変えないで情報参照と分析
• やらないこと　・・・　不明。。。※文章から読み取れませんでした

となるかと思います。

 

オッサンならこう要件定義する

こうなった場合、上司は「管理システムを使え！」となり、現場は「現在の業務を変えたくない！」となるわけです。

この場合、プロマネとしては「上司と現場、どちらの意見を尊重するべきか」という決断を迫られるわけですが、どちらを選んでもろくな事になりません。

上司の意見を選択すると、現場は混乱し、最悪ボイコットとなります。現場を尊重すると、もともとのシステムの目的を達成できず、投資の無駄ともなりかねません。

 

というわけで、こういう状況になった場合、オッサンは落とし所を検討します。

 

前述した分析が正しいことが前提ですが。。。

オッサンなら以下の方式を取ります。

• 注文や商品情報などの入力はシステムを利用する。システムからは入力された情報を参照できる最小限のリクエスト機能と、CSVの出力機能を構築する
• 現場では、リクエスト機能を使って情報を参照できるようにもなるが、CSVを今まで使っていたExcel帳票に読み込ませることで既存の参照や分析業務スタイルを変えずに業務継続を行う（このためにはExcelマクロなども開発する）
• （システム屋側は）エンハンスメント活動として、徐々に固定帳票や画面を追加したりして、Excel帳票の様な属人化されがちな業務から標準化された業務に改善する（様に提案する）

ッて感じかな。

 

要は、今回の目的となる最小限度の機能だけ導入し、既存業務は最低限維持できるようにする、で、最終的には完全システム化を目指して少しずつシステム改善を行う感じで。まあ、とはいえ、どうしても採算が取れない部分は出てくるのでそういったニッチな部分は既存のツールや紙帳票でカバーする感じですね。

※紙で業務を最低限度回せるようにしておかないと、システムトラブルの時にいろいろ終わることになってしまいますので。。。

 

まとめ

まあ、オッサンならこうするって例出してみましたけど、システム構築なんて半ば水物。人が違えば要件定義のやり方も違ったりするわけなので、他にも色々答えはあるかと思います。ただ、エクセルでやりたいことみたいな端々の話に囚われて、本来導入が必要な目的を疎かにすると、往々にしてシステム構築は失敗に終わります。

 

 

なので、上役はきちんと目標を現場に説明する、現場も上役の目標を理解しつつ自分らとして譲れない部分は明確にする、システム屋は双方の思いを汲み取り本当に必要なことをきちんと提示してあげる、っていう三者の歯車が噛み合った時、システム構築は成功できると思います。

 

まあ、とは言え最初から完璧なシステム構築は難しいので、少しずつ、できるところからシステム化するぐらいの気持ちで始めれば、失敗はグッと減るかと思います。

 

背伸びせずにできることからはじめましょうってことで。

 

 

以上

 

 

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術