お客様の言葉を鵜呑みにしてはいけない
お客様の「こんなものを作りたい」という言葉を起点として作るべきシステムを機能分解していきます。
そのとき、目に見える機能の実現だけをゴールにすると、できあがったときに足下をすくわれることがあります。
それは、お客様の言葉や業務からは直接聞こえてこなかった要求が実現できていなかったというようような場合です。
性能が足りないとか、かえって業務が増えてしまったとか、技術レベルが高くて今の人材では対応できないとか、あまり想定していなかったことが起こります。
例えば、性能の面でいうと、1年に数回しかないけれどもとても注文が多くなる日があって、その日に処理するには性能が足りなかったというような場合。
「そんなこと聞いてないよ」
といいたいところでしょうが、求められる処理性能について質問していなかったから、最も処理が多くなる日について考え及ばなかったとも言えます。
こういう機能要件でないものを「非機能要件」と呼びます。
非機能要件を満たしていない場合、顧客満足が下がることもあるので結構重要です。
どんな業務にも見えない要件がある
業務をシステム化するときに、今の業務がどのように流れているか、ということを把握する必要があります。
そのために、現場がどんな手順でやっているのかをヒアリングしながら理解し、どういうシステムにすればいいかを考えています。
業務をやっている人はシステム構築のプロではありませんから、システムの要件として話ができる人はおらず、「こういうことをやっています」という説明を聞くことになります。
なるほどやっていることはわかるのですが、そこにはあまり出てこない話もあります。
どんな頻度でやるのか、どのくらいのスピードでやるのか、どのくらいのスキルがあるのか、など意識して聞いておかないと把握が難しいことも少なくありません。
例えば、「システム化するので私は別の作業をする予定になってます」となれば、人が全く不要になる仕組みを作らなければなりません。
そうすると、その会社ではなくリモートで保守できるような仕組みが必要になるかもしれません。
そうするとずいぶんと新しいものが必要になりそうです。
そういうことを引き出していくことが求められます。
今までの業務を変えていいところ、いけないところ
非機能要件の難しさは、現場で行われる業務を知ってはじめて出てくるものも少なくないことが理由としてあります。
今まで、エラーが起きるとすぐにお客様に連絡して確認していたとすると、システム化してそのエラーを即座に通知して、従来と同じようにお客様に聞いてもらえるような仕掛けが必要です。
また、お客様に聞いて間違いの箇所がわかったら、すぐに修正できるようなUIも必要になります。
「1日分まとめてエラーファイルを作り、修正した内容翌日一括して読み込むつもりでいたので、1つずつ変更するUIを用意していなかった」
ということになれば、お客様も会社も困るわけです。
システム化によって便利になる反面、従来できていたことができなくなってしまっては元も子もありません。
同じことをより効率的にやれるようにするのがシステム化です。
新しい業務には何らかの業務支援機能が必要になる
新しい業務を設計してシステム化すると、そのシステムに満足しがちですが、何か穴がないかをよく考えることが必要です。
頭で考えると非の打ち所のないシステムに見えても、実際に使うとボロボロだったり、ぼろくそに言われたりということも決して少なくありません。
人は新しいものを使うのにどうしても抵抗感がありますし、慣れるにも時間がかかります。
これまでならコピペできていたのに、コピペできなくなったらとても効率が下がります。
画面を開くと戻らないといけない分だけ面倒だと言われるかもしれません。
それを回避するため、一括でCSVでダウンロードやアップロードする機能が必要かもしれませんし、一覧性の良い画面レイアウトが解決策かもしれません。
システム化は一つ一つの現場の要求を拾い上げながら、業務上の最適化も実現しなければなりません。
それ以外にも、納期や予算もありますから、非機能要件を拾い上げて、そこも含めた機能を実現することがなかなか大変なことであります。