要件定義が釈然としない状況での業務改善システム化について

質問

ある事業所で、日常的な事務業務を効率化するという話があったのですが、実際のオペレーターがその日常業務に困っているわけではない…という状況なんです。

それで、改善点のポイントをはっきりさせようと聞いてみたのですが、現状、問題なくこなしている訳ですから、システム化の動機として物凄く弱いんです。

データの流れを調べてみた所、テーブル構造になりにくいものばかりで、特にデータの加工集計をする必要もなく。

システム化で今上がっている改善点は達成できても、代わりに不便な所が出てきて、トータルにはマイナスになりそうな気がします。
しかし、ユーザはシステムの素人なので、現状の便利な部分は便利なまま、改善点分、便利が上乗せされると思い込んでいます。

「トータルではマイナスになる」部分をちゃんと説明しなければ納得できないと思うのですが、どうやって情報をまとめればいいのか…
それとも、多少強引にでもシステム化の方向で進んでいって、後はできるだけプログラミング等でユーザの要望を満たしていくべきなのか…

私としては、VBでPGをやってたくらいで、ユーザとの折衝、システム設計は初めての経験です。
何かアドバイス、経験談等あれば、よろしくお願いします。

回答No.2

aalext · ベストアンサー

こんにちは。

お志には共感するものがあります＾＾

ただ、企業が業務効率化といった時、それは経営者の視点の話です。オペレータの為では決してありません。例えばERPを導入する場合、あれは経営者の為のシステムであって、通常導入以降の何ヶ月も、オペレータは新しい＆余計な苦労をするものです。ある程度は、そういうモンだと思って割り切るしかありません。

経営者から見て良いことは、オペレータは我慢しなくてはいけません。こちらは両方の立場が見えるのでジレンマが無いでもないですがね。プログラミングで我慢しなくて済むように出来る部分については、出来る限り予算を効率的に使って、なんとか考えてあげて欲しいと思います。

「トータルでマイナス」とは？
誰の視点での、メリットとデメリットを分析した結果ですか？全員の立場での全ての、でしょうか。何をもってして、「マイナス」としていますか？
出来る事出来ない事、予測される不便や一定期間の非効率について説明しても、余りあるような真の要件があると経営者が判断すれば、それは「トータルでマイナス」ではない、という事です。またそれが、本当に何をすべきなのかを見つける手がかりです。

もしオペレータにヒアリングした結果、本当に今より件数が増えても処理しきれると分析できるならば、実はシステム化など必要ないという事かもしれません。何故、何件程度の処理が増える事が予測されるのかについても、一応知っておきたいですね。
又、そのオペレータが余裕を持って処理できる、と言ったところで、時間が余っているからといって（システム化すれば）30分で出来る事に、（従来の方法で）2時間かけて良いわけではありませんよね。オペレータの言っている事は、システム化をしないでよい理由にはならない気がします。

一番必要性を感じるのは、経営者（もしくはキーパーソン）とのコミュニケーションだと感じますが、いかがでしょうか。

お礼

＞企業が業務効率化といった時、それは経営者の視点の話です。オペレータの為では決してありません。…

なるほど、そういう視点もあるのですね。実際に使うユーザの使い勝手を最優先に考えていました。確かに視野が狭かったように思います。

＞誰の視点での、メリットとデメリットを分析した結果ですか？…

この点は感覚的なものでした。これを各立場ごとに計量的に表す必要があるとは思うのですが…。いかんせんその手法の知識がなく、途方に暮れています。

＞…真の要件があると経営者が判断すれば、それは「トータルでマイナス」ではない、という事です。

以前話をした中では、システム化することによって納期管理のようなものをしたいとのことでした。
しかし、運用を刷新するような大掛かりな話ではないので、今保持している情報に少し付け加える程のことしかできず、本当にそれが重要な要件（要望）なのか？という疑問があります。

＞何故、何件程度の処理が増える事が予測されるのかについても、一応知っておきたいですね。

これは事業所の統合という理由があるので、何件くらい増えるのか、今後MAXでどれくらいになりそうかもある程度ははっきりしています。

一件の作業に関わるデータは多いですが、扱う作業件数自体は結構少ないんです。
今もそんなに手間は掛からず、Excelシートをコピーする方法で問題なく運用されているので、それ以上劇的に短くするのは困難だと判断しています。せいぜい時間が同じくらいになるようにする程度になりそうです。

「自動化によって、データのコピーミスをなくす」「納期管理をできるようにする」というオプションはあるにしろ、最大の関心事であろう「一件に掛かる時間の軽減」が非常に難しい。これ以上ないくらい満たされていますから。
これを犠牲にしてまで、オプションである要件を満たすためにシステム化…というのは本来の定義から外れているように思うし、そうまでして望まれていることだという事が向こうからイマイチ伝わってこないんです。

＞一番必要性を感じるのは、経営者（もしくはキーパーソン）とのコミュニケーションだと感じますが、いかがでしょうか。

確かにそうですね。もっと話し合う場を作ってもらおうと思います。アドバイスありがとうございました。

回答No.6

takuya1663

まず仕事の目的や使命などはユーザーという「利用者や乗客」に満足いくようなわかりやすいサービスを提供させていくことではないかと思います。

苦情や問題はないように見えても、潜在問題の方が多いというニーズは必ずあるはずです。

そして、改善をすることは　あくまで手段であるので、最も最優先で最重要なのは現状を正しく認識して問題点はどこにあるのかということをなくして要望や目的が叶うシステムにはならないと思います。

現状を正しくリサーチして問題点を把握し真の問題・課題解決の手段をとり実行し改善に向けた上で効果と歯止めや定着をフォローするというサイクルも大切かと思います。

システムの専門家ではなく申し訳ありませんが参考にでもなれば幸いです。

お礼

十分なリサーチの後は、優先順位を付けて、ユーザに認識させることも重要なんですね。
潜在的なものもフォローできるように、要件定義を固めていこうと思います。
アドバイスありがとうございました。

回答No.5

hoshisan

用件が漠然としているユーザー（経営者・管理者・業務担当者）、
あたらしい会社で初めてシステム設計の上流工程を担当することになったのに、会社にはアドバイスをもらえる人がいないあなた、
私自身の２５年前を思い出します。
会社の開発標準に則って、システム開発をするのではないのであれば、あなた自身が今回の事例で自分なりの標準を作り、それを会社の標準にしていく、良いチャンスだと思います。
まず現状分析として、業務の範囲や流れ、その中で情報やデータの入力や出力、ＤＢなど計数的に把握できるものはしていくというのはいかがですか、お客様の業務改善要求をひきだすための材料作りから始めてみては。
業務改善にあまり熱心でないなら、システム基盤を最新の物にしていく、Ｗｅｂベースのアプリケーションにして今後の開発効率を高め、コストを下げられるようにする、という手も考えられます。
プログラム段階に課題を先送りすることなく、プロトタイプをつくる、ドキュメントをもとに「聴きだす」など設計段階で明確にしておくことをお勧めします。
優秀なアプリケーションエンジニアやＩＴコンサルタントを目指して頑張ってください。

お礼

アドバイスありがとうございます。

＞プロトタイプをつくる、ドキュメントをもとに「聴きだす」など設計段階で明確にしておくことをお勧めします。

先日話があって、まず、ユーザに見せれるモノを作る…ということになりました。そこから、もっとこうしてほしい、これは使い勝手が悪そうだ、という意見が積極的に出そうですね。
不慣れなことなので、そのプロトタイプの作成自体にも時間が掛かりそうですが…。なんとか良い前例になるよう頑張ってみたいと思います。

回答No.4

palmmy

＞納期管理に関しては、先程も書きましたが、運用自体は大きく変えるつもりはないので、成果が出にくいんです。
これだけを満たすなら、極端な話、今あるExcelシートにちょっとマクロやVBAを埋め込めばできそうな話です。

例えば、EXCELシートを各自が使って行っている場合、使用者しかわかりません。マクロやVBAで出来るのは作業者のための改善だと思います。

たとえば、これらをDBで一元管理すると、納期遵守率や受注傾向、ネックとなる品番などがわかるかもしれません。経営者から見るとこのような情報が欲しいのかも知れません。

欧米の企業では、担当者がEXCELシートで…は嫌われます。
AさんでもBさんでも新入社員でも、システムに向かって決まった処理をすれば同じ結果が出てくることを望みます。

納期管理ですが、実は納期短縮も視野に入れているかもしれません。この場合、システムは分析の出来るツールでなければなりません。

少ない情報で書いていますので、このケースに当てはまるかわかりませんが、このような考え方もあります。

#2　さんも書いていますが、経営者（もしくはキーパーソン）とのコミュニケーションは大事です。そのなかで今何が問題で、何を望んでいるのか本質の部分を見極める必要があります。

要件定義書も重要です。電話での話、口頭でのやりとりでも文書にした方がいいと思います。

お礼

データベース化すると、情報の分析ができることが一番の利点だと思うのですが、話を聞く範囲ではデータの加工や集計の必要性は無さそうでした。とにかく帳票を出すのを便利にしたいというのが主な話の流れなのに、現状ではそんなには困っていない。
データの正確さを求めると今の方法とは変わってくるので、オペレーションとしては返って不便になるかもしれない…やっぱり要件が煮詰まっていませんね。ここを重点的にチェックしようと思います。

・経営者（もしくはキーパーソン）とのコミュニケーション・何を望んでいるのか本質の部分を見極める・要件定義の文書化
この点がポイントになりそうですね。ためになるアドバイス、本当にありがとうございました！

回答No.3

aalext

#2です。

＞実際に使うユーザの使い勝手を最優先に考えていました

結果的にそうなる事が望ましいのは当然ですが、ある程度は理想論です。業務効率化のそもそもの目的はおわかりですよね？普遍的かつ当然な事です。システム化が経営者の為のものだというのは、視点というより、前提ですよ・・。

因みに、本気で”ユーザの為”と思って悩んでばかりいると、重要な事を見逃す事は、往々にしてあります。結果誰の為にもならなかったりするので、一歩ひいてビジネスの観点で考え直してみてはいかがでしょう？

「トータルでマイナス」の件ですが、考えるべきことは、計量的にいかに表現するかではなく、本当にそうなのか？という事だと思います。これについて的確な判断が出来れば、ノウハウどうこうよりも、説得力のある説明は可能になるはずです。感覚的との事ですので、より具体的にするのが先決です。

要件ですが、ご質問やお礼を総合した限りでは、優先度は明らかに

２．「自動化によって、データのコピーミスをなくす」
１．「納期管理をできるようにする」
３．「一件に掛かる時間の軽減」

では？？？

処理時間の削減が最大の関心事とは思えません。
それこそ”システムありき”の発想では？
システム化以前に、業務改善の視点で考えれば明らかです。また、納期管理の徹底とデータのコピーミスの削減の為だったら、処理時間の削減は充分犠牲にするに足る要素であるとの判断が妥当です。
それ位は、多少のブーイング覚悟で「ご了承ください」と言いましょう。

#2にお礼をいただいた中で初めてでてきましたが、「納期管理」が最重要ではないのでしょうか？

クライアント側で要件がぐらつくのは最悪のパターンです。要件定義書（名称は何でも良いですが）など文書できっちり残し、物事をうやむやに変形させないために、出来る限りは形式的にきちんと仕事を進める事をオススメします。これはプロジェクト管理の手法の細かい点だったりしますが、誰かの恣意的な判断で物事が曲げられないようご注意ください。また会議をもったらきちんと成果を確認するなど、最低限行なったほうがよいですよ。

又、クライアント側のぐらつきよりも、ヒアリングの中から本質的な問題を見つけ出し的確にアドバイスするのはこちら側の仕事ですよね。頑張ってください。

お礼

再びありがとうございます。

＞システム化が経営者の為のものだというのは、視点というより、前提ですよ・・。…
＞処理時間の削減が最大の関心事とは思えません。

必ずしも、作業者のため＝経営者のためということではないのですね。
ただ今回は、話が入ってきた一番最初の出だしが”作業件数が増えるので、時間を短縮したい”との要望でした。だから、これが最優先事項として話を進めてきた経緯があります。

これは要件定義をしている内に、要件の重要順位が変化してきた…と捉えた方がいいのでしょうか？
思ったより短縮は難しい→他の要件はないのか？→納期管理、データの正確さがより重要だと気づいた…という感じで。

納期管理に関しては、先程も書きましたが、運用自体は大きく変えるつもりはないので、成果が出にくいんです。
これだけを満たすなら、極端な話、今あるExcelシートにちょっとマクロやVBAを埋め込めばできそうな話です。

データの正確さ…に関しても、どれくらいの確率でミスが生じているのか？ミスを失くすためにどれくらい時間が掛かっているのか？も分からないので、成果も分からず。これは調査の必要がありそうですね。

後半の話は大変ためになりました。前の会社でPGをやってる頃は、上流工程をやってみたなぁと漠然と思っていたのですが、この過程がまさにそうですよね。
今の会社では指導してくれる人は全くおらず、全てが手探り状態ですが、何とか会社の役に立てるようやっていきたいと思います。
ありがとうございました。

回答No.1

palmmy

＞日常的な事務業務を効率化するという話があったのですが

いいだしっぺに構想を聞いてみてはいかがでしょう？
経営者と、作業者では捕らえるポイントが違うこともあります。

事務業務を効率化だと、経営者の場合、システム化によって人員が削減できると考える人もいます。

・業務改善の本当の目的を探る
・キーマンは誰か
はまず見極めた方が良いと思います。

お礼

早速の返信ありがとうございます。
いいだしっぺは作業者じゃないことは確かです。

＞事務業務を効率化だと、経営者の場合、システム化によって人員が削減できると考える人もいます。

主力はほとんど一人でやっているような状態です。その人に他の仕事をさせたいのかな？とも思いましたが、そういう様子もなく。
ただ、最初は事業所の統合などにより、作業件数が増えるから…という話でした。でも、後でオペレーターから聞いた所によると、現状以上の作業件数でも、問題なくこなしていたようです。

どうも、最初からシステムありき…の話になってしまっているようで。上の人にとっては「業務のシステム化」という一つの「成果」として残るけれども、実際のオペレーターは前の方がよかったって思ってそうな…。その点の意識を統一させずに、まぁシステム化すれば便利になるだろう…という雰囲気がユーザから見受けられます。

一応ここまでは見極められましたが、それを踏まえた上でどうすればいいのか…考えあぐねてしまいます。