システム導入

使いにくいシステムが出来上がるまで。失敗しないシステムの導入方法

昨今はSaaSに代表されるようにさまざまな業務ソリューションがパッケージ化され、自社用に一から業務システムを作ることは稀になってきました。

オンプレ、クラウド問わず、必要なパッケージを組み合わせて業務をシステム化するのが今のトレンドであると言えるでしょう。

しかし、「これならば!」と大きな期待を抱いて導入してみるも、思ったほど成果が上がらないと感じることもあるのではないでしょうか?

実は、その原因のほとんどはユーザーのツールに対する理解不足によるものだと言ったらどうでしょう?

「このシステムは使えない」「今回のSIerは無能だった」という評価をする前に、システム導入までのプロセスが果たして理にかなったものだったか見直してみてはいかがでしょうか。

使い方が間違っているから使いにくい

世に出回っているパッケージソフトは、「ユースケース」を定義した上で作られています。

ユースケースとは、開発時に「このシステムはこういうシーンでこういう人が、こうやって使うだろう」という実際の利用シーンを想定することです。

言い換えれば、「こうやって使ってほしい」という開発者の思いであるとも言えます。

開発技法としては「ユースケース図」というものを用いて定義するのが一般的ですが、そのような技法を用いない場合でも「きっとこうやって使うよね」という共通認識を関係者間で共有した開発が進められます。

システムは、このユースケースから逸脱した使い方をした時に「使いにくい」と感じます。

身近な例としてハサミとカッターを考えてみましょう。

どちらも紙を切る道具ですが、ダンボールのフタを開けるときはどちらを使うでしょうか?

カッターをフタの隙間に差し込んで、サーッ!とテープを切るのが簡単ではないでしょうか。ハサミでも似たようなことはできますが、カッターの方が使いやすいのは想像いただけると思います。

このような「やってできないことはないけど、本来の使い方ではない」という感覚が、ユースケースから逸脱している状態に近いものです。

ソフトウェアの世界は導入前の使い方が想像しづらく、ダンボールのフタを開けたいのにハサミを買ってしまうような、ユースケースの取り違いが発生しやすいのです。

無駄に高機能なシステムも使い勝手が悪いと感じる

また、システムを導入する過程ではさまざまな要望が現場、管理者、経営層などの異なる利害関係者から多数上がってきます。

利用者の声に耳を傾けることは大事ですが、すべての要望を満たそうとして身の丈以上のシステムを導入してしまうことがあります。

高額なシステムは多機能なものが多く、「あれもできる」「これもできる」と多くのユースケースに対応しており、一見使いやすそうに見えます。

しかし、機能が多いということはシステムを使いこなすには覚えなくてはいけないことが多いということでもあります。

自社のレベルにあったシステムでないと理解が追い付かなくなり、結果使いにくいと感じるようになります。

普通自動車の免許しか持たない人がF1に乗るようなものです。

例えば、F1の運転席(コックピット)には大量の計器とボタンがついています。

F1は各計器の意味とそれを適切にコントロールする術を覚えないと大事故につながる危険性が出るため、走るだけでも普通自動車より多くの知識が求められるでしょう。

スピードも時速300キロ以上出ますから、それをコントロールする技術も必要です。

知識的にも技術的にも、普通自動車免許ではF1に乗れないことはご想像いただけるかと思います。

このように普通免許しか持たない会社がF1を購入するような、自社のレベルを無視したシステム導入が現場ではよく発生します。

最近のIT業界はAIやデータ分析といった、データ活用に関するテーマが多く、それを売りにしたパッケージソフトも多く出回っています。

しかし、そのようなパッケージを買っても社内にデータ分析に精通したプロがいなければ、宝のもち腐れになってしまうでしょう。

カスタマイズで使い勝手が悪くなる

自社のレベルにあった使い勝手の良いパッケージを選んだとしても、さまざまな部門の要望を聞いて機能を付け加えていった結果、結果的に使いにくくなってしまうこともよくあります。

完成されたパッケージに無理やり機能を追加しているため、最初から高機能であるシステムよりも使い勝手が悪くなる傾向があります。

子供がおもちゃの変形ロボットを厚紙やセロテープでかっこよくカスタマイズしたところ、変形できなくなってしまった、といったことと同じです。

これは、そういうカスタマイズをメーカーが想定していないから起きる問題です。

システムも同じで、ユースケースを捻じ曲げたカスタマイズは当初からあった機能を制限させることにつながり、使い勝手の悪化を招きます。

最悪なのは、自社独自のカスタマイズであるため、ソフトウェアの定期バージョンアップが適用できなくなる可能性があることです。

バージョンアップによって使いやすくなったとしても、カスタマイズが邪魔して最新バージョンに入れ替えることができず、使い勝手の悪いシステムをずっと使い続けなくてはいけなくなってしまう恐れがあります。

なぜ使いにくいシステムを作ってしまうのか?

最初から「使いにくいシステムを導入しよう」と思ってプロジェクトをスタートさせる人はいないと思います。

それなのになぜ、こうも使いにくいシステムが出来上がってしまうのでしょうか?

その理由は次の3点に集約されます。

目的をぼかしたまま進めている

例えば、自分たちはサッカーをやりたいのか? それとも野球をやりたいのか? それを決めないままバレーボールを買ってしまう。

そんな意味不明なことが、起こります。

改めて、システム導入の目的とはなんでしょうか?

目的について考えるとき、「業務改善」「生産性向上」「効率化」このようなキーワードが出てくると思います。

「誰の」「どんな業務を」「どのように改善したい」のでしょうか?

私が今まで関わった中では、「どのように改善したいのか?」の部分がない会社が多いように思います。

システム導入後の姿をイメージできてないのですね。

例えば、製造業の生産現場でIoTを活用したい場合。センサーから精度の高いデータを収集して生産管理や故障検知をしたいといった要望があるとします。

データ精度が上がればよりきめ細やかなフォローができたり、トラブルにも迅速に対応できるようになるでしょう。その結果……どうなりますか? どうなることを期待しているのでしょうか?

そこまで考えることで、ようやく本来の目的が見えてきます。

トラブル対応を早くすることで生産のリードタイムを短縮したいのか、従業員の残業を抑制したいのか、原価低減したいのか……。

「そんなの全部だよ!」と思われるかもしれませんが、目的には優先順位があるはずです。

主目的をはっきりさせることで、検討すべきシステムの方向性が変わってきます。

例えばリードタイムを短縮したいのであれば、多くの従業員がデータを監視できるようにライセンスは多めに必要かもしれません。残業抑制が目的であればRPAと相性の良いシステムの方が良いかもしれません。

目的をはっきりさせないと、このような優先すべき事柄の判断基準があいまいになり、結果的に「なんとなくよさそう」と思うシステムを選んでしまうことになってしまいます。

業務にシステムを合わせている

先ほども申し上げた通り、システムには想定するユースケースが存在します。

ユースケース通りにやればスムーズに進むのですが、「ウチの仕事のやり方はこうだから」と流れを捻じ曲げてしまうことでシステムの使い勝手を自ら下げてしまいます。

タクシーの運転手が「こっちの道の方が近いですよ?」と言っているのに、「違う!」と言い張って、自分の知ってる遠回りな道で結果的に高い料金を支払っているようなものです。

業務の流れに関係する要望は、オペレーションを担当する現場から上がってくることが多いです。

現場は既存システムに慣れており、新システムは一から操作方法を覚えなおさなくてはいけないため抵抗感があります。少しでもシステム変更の負荷を減らすために仕事の流れを変えたくないといった発想になるのは、至極自然であると言えます。

仕事のやり方を変えない場合、やり方が合わない部分はカスタマイズして合わせることになりますが、これによって使い勝手が悪くなる可能性が高いです。

通常、システムは多くの人がよく使うメニューをアクセスしやすい位置に、アクセス頻度の低いメニューは目立たない位置に配置されます。

カスタマイズすることによって、よく使うメニューにアクセスしづらくなったり、流れを意識して作られたメニュー構成の配置が変わってしまったり、やたらとメニューが増加したりといった弊害が生まれやすくなります。

自分たちの会社は「特殊」だと思っている

業務にシステムを合わせる話にも関係するのですが、多くの人は「自分の会社は特殊である」と思っています。

この思い込みによって「一般向けに作られたパッケージソフトは合わない」という先入観を持ってシステム導入に臨んでしまっています。

新しいシステムを検討するとき、直面した課題に対して他の会社がどうやっているのか気にされる方は多いと思います。

しかし、そこで「他の会社はこうしてますよ」という情報提供しても、だいたい返答は「ウチは特殊だからなー」と笑。

最初から一般的なやり方に合わせる気がないようで、失礼ながら「聞くだけ無駄じゃね?」と思ってしまいます。

そもそも何を基準に「特殊」と判断するのでしょうか?

伺ってみると「発注単位が他社より細かい」とか「組織が複雑」とか、そんなに特殊か?といった理由がほとんどです。

世の中に全く同じ会社はありませんから、それでは世の中の会社すべてが「特殊な会社」になってしまいます。

そもそも、パッケージ製品は基本的にターゲットとする業界を入念にリサーチした上で設計されているものが多く、そこで考えられたユースケースは業界標準であることが多いのです。(例えばトヨタのカンバン方式など)

標準であるということは有識者が考えた効率的な手法や考え方であり、多くの会社が採用しているということであり、ベストプラクティスに近いものであるということです。

特殊ということは、これとはかけ離れているということですので、異端であるかもしれないということです。

システム導入の目的は業務の効率化や改善であって、現状維持ではないはずです。

従来の考え方に固執しているせいでうまく回ってないところがあるのでは? という疑いを持つことが重要です。

システム導入を成功させるには

それでは、自社にあった使いやすいシステムにするにはどのようにすればよいのでしょうか。

重要なのは、システム導入の目的をはっきりさせること。そしてシステムに合わせて業務を変えていくという心構えです。

システム導入の目的をはっきりさせる

最も重要なことは、システム導入の目的をはっきりと決めることです。

自分達はサッカーをやりたいのか、それとも野球をやりたいのか?

サッカーをやると決めたなら、サッカーボールが必要です。スパイクシューズもほしいですね。

しかし、野球のようにヘルメットやグローブはいりません。

このように、目的を決めると必要なものと不要なものがはっきり分かってきます。

これを「球技をやりたい」のようにぼかしたままだと、社内から上がる「ウチはサッカー」「こっちは野球」「いやいやバレーでしょ」といった声に振り回され、どれも中途半端な結果に終わってしまいます。

適切な目的を設定することは以降のシステム導入に関わる全ての作業に影響してくるため、とても重要です。

では、どのように目的を設定するか。

目的は課題の裏返しであることが多いため、導入したいシステムに関する業務の課題をまず洗い出すことから始めるとよいでしょう。

課題の大小は問いませんが、「その課題が解決したらどういう状態になるか」といったところまでセットで考えることが効果的です。

「どういう状態になるか」の部分が課題の裏返しとして、目的を考えるヒントになります。

例えば、次のようなセットで考えていきます。

課題 課題解決後の姿
子会社や各部門から売上データを集めたり、データ提出の催促をするのが大変 決められた日にデータが自動収集されている
売上レポートの作成に手間がかかる データ収集後に自動計算が行われ、レポート作成まで行える
営業部門の営業報告が遅い 商談後、スマホなどから営業報告を即座に送信できる

このような細かい課題をいくつも集めると、最も解決すべき課題が見えてきます。

この例では、現場と管理部門での売上データの取り扱いに課題があると考えられます。

そうすると、目的は「売上情報を早く正確に把握すること」となります。(たった3つの課題で結論づけるのはかなり乱暴ですが、例ということでご容赦ください)

システムに業務を合わせる

システムのユースケースは、業界標準をベースにしていることが多いです。

システム導入時には「他社がどうやっているか」を気にする方も多いと思いますが、このユースケースに倣うことで実は簡単に業界標準のやり方を手に入れることができるのです。

では、どうやって自社の運用をユースケースに合わせていくか。

それを検討するには、新システムの機能と使い方を十分に理解しなくてはいけません。

複数の機能を組み合わせることで、今までと変わらない運用を実現できることもありますし、運用次第で機能をうまく使えることに気づくこともあります。

運用部門との折衝も必要になりますし、非常に地味で面倒くさい作業です。

しかし、これを乗り越えられると非常に多くのメリットが得られるのです。

まずシステムをカスタマイズしないため、低コストでの導入が実現します。

ソフトウェアのバージョンアップも簡単にでき、それに伴うコストも最小になります。特に会計システムのような法改正に即時対応しなくてはいけないようなものでの恩恵は大きいでしょう。

そして業界標準の考え方、やり方を身につけることができ、自社のレベルアップにつながります。レベルが上がることで、次回のシステム刷新時にはより高度なシステムの導入を検討することができるようになります。

システム導入の際、現場部門からは「こんなやり方では仕事がまわららない」といった反発が多かれ少なかれ出てきます。

ここで思い出していただきたいのが、システム導入の目的は「現状維持」ではなく「改善」です。

いままでのやり方が本当に良いのか。そこに費用をかけてまでカスタマイズする意義があるかをよく検討してください。

まとめ

システム導入はSIerと一緒に進めることが多いため、SIer側のSEがプロジェクトをリードしてくれることと思います。

優秀なSEであれば要望を的確にコントロールしてくれますが、みなさんの社内業務に精通しているわけではありません。

そのため、依頼者側が「どうしても必要」というのであればそれをSIer側が覆す論理は持ち合わせていないのです。

システムが使いにくそうだなと感じたら、目的は合っているか、システムのユースケースと使い方がずれていないかをぜひ確認してみてください。

スポンサードリンク
  • この記事を書いた人

SATORU

長野県在住のシステムエンジニア。仕事はソフトウェア開発、Web、デジタルマーケティング、組み込み、プロマネ、商品企画、システム導入、運用支援などなど。特化型ではなく万能型のエンジニア。田舎住まいなのでその方が重宝されるのです。

-システム導入
-

© 2021 SYSTEM-CREATOR.COM