「使ってもらえる」ツールを作るために使い手のことを考える

面倒だったりわかりづらかったりすればまともに使ってもらえない

システム担当ではないがデータアナリストとして色々な人に色々なツールを作ってきたが、ただツールを作るためのプログラムスキルやDBの知識だけでなくもっと広い視点からとらえなおす必要があると考え、「使ってもらえる」ツールを作るためにどういったことを考えているかについてまとめてみた。

使う人の業務を把握する

誰が何のために何をしているのか

まずは誰が何のために何をしているのかを正しく把握しなければならない。その業務をしている本人もきちんとわかっていないことが多いのに、業務を把握せずただ「こんな感じのツールが欲しい」と依頼された内容に沿って作られただけのツールでまともなものを見たことがない。実は内容に過不足があり困っている話はよく聞くし、ひどい場合は誰もその結果を使っていない、ということもあり得る。「いったい何が本当に必要なのか?」という問いはどんな場合にも必要だ。

きっちりとしたデータが必要か、ざっくりで十分か

重要な内容であれば精緻な値が必要かもしれないが、規模感を知りたい程度の話ならばもっとてっとり早く作ることができる。必要ないのにその数値を作るためにさまざまな条件をあちこちに確認して細かく場合分けをして注意深く検証することで遅くなるぐらいであれば早く使ってもらうほうがよい。

いつまでに必要か

あればうれしいが急いではいないのか、いつの作業に必要だからいつまでには必要だとか、当たり前の話だがこれが漏れてあとで大騒ぎというのもよくある。相手が急いでいると言わないから知らないと言ったところで、結局ぎりぎりになって残業する羽目になるのは自分なのだから、前もってきちんと把握しておかなければならない。

優先順位を決める

以上を踏まえて作業する順番を決める。できるかわからないことをできるなどとは言うべきではないし、すぐできると思っても少し時間を多めにとっておく。それでも急ぎの場合は品質の担保が難しいことの了承を得た上で着手する。無責任に「できる」と言ってできなければ謝れば済むというのは自分に被害が及ばないからであり、もしそのツールができないことで作業が出来なくなったり遅れて迷惑するのは同僚でありクライアントであるのだから、誠意をもって対応するべきだ。

前提を疑う

鵜呑みにしない

内容をよくわかっていない、あるいはデータの扱いに慣れていない人からの依頼は鵜呑みにすると出来上がってから「これが違うあれも違う」の大合唱でなぜか責めを受けるのは作った人になる。また、過去に作られたツールの改修に関しても経緯不明でツールだけが継承されていることがあり、今は不要なデータが残ったままだったりあるべきデータが入っていないことが発覚したりとトラブルの宝庫であるので、まずは把握した業務に沿って考える。ただし勝手に進めるとこれもトラブルの種になるので、きちんと依頼者と認識合わせをすること。

不要なデータを受け取っていないか

特定のデータが必要なのにその数百倍のデータ量があるトランザクションの生データを受け取っていてその分待ち時間が長くなっているとしたら、それこそ無駄な時間だ。また個人情報のように扱いが難しいデータは余計な疑いが掛るようなデータは必要ないならば受け取らないようにしよう。管理や破棄にかかる手間も馬鹿にできない。

データの受け取り方

受け取るデータの内容が変わったら、受け取り方も変わるかもしれない。極端な例だと重要なデータだからと特別なサービスを使って金も時間もかかっていたのが、必要なデータだけにしたらメールで送れば十分だったという話もある。以前のやり方を踏襲するのではなく必要に応じて最適な方法を選ぶ。

利用するアプリケーション

これもデータが変われば今まで使っていたツールで行う必要がないということになる可能性が十分にある。例えば大量データだったのでSPSSで処理しなければならなかったのが、excelで簡単にできるようになった、といったことだ。メディアからのダウンロードやサーバーへのアップロード、処理の待ち時間などを含めるとこれだけでも大分効率化されるし、頻度が高ければ高いほどその効果は大きい。

使う人のために考えるべきこと

できるだけ作業をまとめる

1つクリックして数分、また別の場所をクリックして数分・・・それが1回数十個。時間は細切れで他の事をやるにも集中できず、さりとてその場を離れるわけにも行かず。1クリックすればまとめて処理が行われるように作るべきで、もちろんそれで全て終わるのであればベストである。しかしどうしてもそうできない場合は、出来る限りまとまった単位でまとめて処理できるようにしよう。

エラーが起きる可能性があるなら途中から始められるようにしておく

とはいえ数十分経って戻ってきたらエラーが起きて最初からやりなおしでは時間が足りなくなる危険もあるしストレスもたまる。そのようなことが起きそうなら中間データを作成し、エラーが起きたら途中から始められるようにする。月次のデータならば1か月分取得したらアウトプットし、エラーが起きたらその月から始めるといったようにできればやり直す時間も短くなる。もちろんそのようなエラーが出ないようにするか、出ても自動でやり直すような仕組みまで入れ込めればそれに越したことは無いがあとはコストや優先順位との兼ね合いによる。

フィードバックを求める

残念ながら不満には思っていても多くの人は自分から改善策を提案してくることはない。なので使い手に対して「どうしたらもっと使いやすくなるか」「使っていて困ることはないか」というフィードバックが欲しければ自分で聞きに行く方がよい。聞けば結構出てくるものだ。

バックアップ体制

やり方をきちんと教えるかマニュアルを整備する

「作ったからあとは知らない」というのはむちゃくちゃだと思うが、よく見聞きする。そのツールを使うためにファイルを用意し、所定の場所に所定の名前で置き、しかるべき手順で進めればここにこのようなアウトプットがでる、と最初から最後まできちんと説明し、できれば最初はやってみせるのが良い。そこまで時間が無いのであれば、簡易的にでもよいのでマニュアルを作成して渡す。

トラブルシューティングも作っておく

何かとトラブルは起きる。その度にいちいち呼び出されて対応していたらいくら時間があっても間に合わない。マニュアルと同時に、「こんなトラブルが起きたらこうする」といったトラブルシューティングもまとめておけばかなり時間の削減になる。「止まったけど終了していいか」というような質問は「やればいいじゃん」と思うかもしれないが、初めて使う人やデータに慣れていない人には何かあったらどうしようと心配なのである。消しても問題が起きないことがきちんと書いてあればそれで電話がかかってくる回数はかなり減る(なくなるとは言わない)。

困った時に聞ける人は誰なのかはっきりしておく

「エラーが起きた、フリーズした、でも過去に経験は無い初めての現象だから問い合わせたいけど作った人はもういない。誰に聞けばいいのかもわからない。納期は明日なのにどうしたらいいの!」というのもまたよくある風景。vbaやプログラムでテキストを処理するような簡単なツールなら使える人も割といるので何とかなるかもしれないが、ある程度以上複雑ならば作った本人に聞くのが一番早い。この場合は作った人がいなくなる前に引き継ぎも必要だが、社内に同じレベルのことができる人が複数いないのであればそのツールの利用自体を見直したほうがいい。

極端な話をすれば、「今自分が死んでも動くツールが最良」である。もちろん全ての事に同じレベルで対応する時間はないのだが、そう思って作っておくといざというときのことを考えやすい。

正しく使えば正しく動くだけのツールは「二級品である」ではなく「不良品」である

結局のところ、自分の仕事をどう捉えるかの違いか。「ツールを作ること」を自分の領域とするか、「その仕組みを誰かが運用して問題なく回すことができるようになる」までを領域とするか。全ては無理でも、できる限り後者でいたい。

生産性

Posted by 管理人