こんにちは、価格.comショッピングシステム部のNです。最近ではプロダクトのコードを書くことはほとんどありませんが、ときどき業務効率化のためのツールなどを作っています。

この記事は業務効率化にあたってのツールを作るという選択をするプロセスについてと、そのメリットをまとめたものです。どうやってツールを作るかというお話ではないのでご了承ください。

こんなことありませんか？

業務効率化ツールを作ってみたいけれど、何もアイデアが思い浮かばない
なんとなく作ってみたけれど、何を改善するものなのか自分でも説明できない
作ったきりでほとんど誰も使っていないし、フィードバックももらえていない
使おうと思ったらメンテナンスされていなくて動かなかった

あるあるですよね。ツールを作ることができるというのはエンジニアとしての大きなアドバンテージではありますが、そもそも業務効率化に対する解像度が低いままではその効果をうまく活かすことができません。

そもそも業務効率とは

まずは業務効率の話をしましょう。「業務効率が低い」と「業務効率が高い」では後者の方が良いことはわかりますが、具体的な業務効率をどのように測るかはなかなかに難しい問題です。

いろいろと方法はあると思いますが、QCDなどはわかりやすいフレームワークです。QCDはもともとは生産管理の用語ですが、ビジネス全般にあてはめることができます。

Quality（品質）
Cost（コスト）
Delivery（納期）

これらの要素を改良すれば業務効率が改善したと考えることにしましょう。1つだけをターゲットにすることもあれば、複数を同時にターゲットにすることもありますね。

何を解決したいのか（課題やニーズを見つける）

何を解決することによって業務効率を向上させるかを考えます。基本的には徐々にドリルダウンしていくのがわかりやすいです。

テーマの設定

一言に業務といっても自身やチームが担当する仕事すべてを一気に効率化することは現実的ではないため、「不定期に発生する○○に対しての調査」など業務のターゲットをざっくりと絞っていきます。特に目星がついていないのであれば、この業務はどうだろうと順番に見ていくのも良いです。

「毎回この作業しているな」「何かこの作業、効率が悪いな」「とりあえず地道にがんばるか」などの感覚は解決すべきテーマの気配を感じます。

現状分析

テーマを決めたら現状を分析します。業務フローを可視化したり、作業ごとにかかる時間を分析したり、関係者を一覧化してみたり。細かいプロセスに分割するのももちろん良いですが、いくつかの切り口で分析できるとなお良いです。「明文化されていないので業務を正しく定義できない」というのもある種の立派な現状分析になります。

解決すべき課題の選定

現状分析ができたら解決すべき課題を洗い出して選定します。必ずしも1つでなくても構いません。QCDの観点で考えるのであれば、例としては以下のような分析結果は改善の余地がありそうです。

ミスややりなおしが頻繁に発生している（Quality）
得られる成果に対して、かかるコストが高すぎる（Cost）
得られる成果に対して、かかる時間が長すぎる（Delivery）

解決の手段を考える

解決すべき課題が見つかったら解決の手段を考えます。ついついすぐに手を動かしたくなってしまう気持ちはわかりますが、「何かを作る」をいきなり解決方法にしない自制心も大切です。

解決のアイデア

そもそものムダな業務をなくしてしまう
マニュアルを作ることによって属人化解消とスピードアップ
仕組みやルールを整備してムダや悩みを減らす
既存のツールなどを使って自動化
新たにツールを作成して自動化

課題の選定と解決手段の検討は行ったり来たりすることがあります。また、どんなに重要な課題でも解決手段が見つからない場合には優先度を下げることもあります。

解決手段が見つからない課題をストックしておいて、ふとした拍子にアイデアが思い浮かんだり、前提条件が変わるのを待つのも良いかと思います。

解決手段の判断基準

解決できる度合い
制限事項
難易度やかかるコスト
スキルアップや成長

解決度合いは低くても、すぐに取り組めるのでまずはサクッとやろうというのも1つの選択肢です。ツールという観点だと市販のツールであれば作る時間やメンテナンスコストは大幅に削減できますが、会社の規則やコスト的な観点でNGになることもあるかもしれません。もちろん課題の種類によっては別の判断基準が必要になる場合もあります。

ツールを作る

さて、検討の上でツールを作るという解決手段を取ることになりました。最初に記載したとおり、この記事ではツールの作り方自体を解説はしませんので、少しだけTipsを。

いきなり100点を目指す必要はない
→0か100かである必要はありません。フィードバックを得ながら徐々にブラッシュアップしていくのもGoodです。
できるだけ普段担当しない領域にもチャレンジしてみる
→バックエンドを専門としている場合にはUI/UXにこだわってみるなど、新たな知見を得るチャンスになります。
当初の目的からズレていないか
→作っていくうちにやっぱりこっちのほうがいいんじゃないか、こういう機能もあった方がいいんじゃないかというアイデアが出てくることはよくあります。ツール作りのおもしろいところではあるのですが、当初の目的からズレていないかだけは定期的に確認したいところです。