初回リリースのあと、何から直すか ── 最初の3ヶ月の改善の決め方

リリースして2週間たつと、チャットに要望がたまっています。一覧の並び順を変えてほしい。この項目は要らない。検索に取引先名を足したい。スマホだと送信ボタンが下すぎる。集計をグラフで見たい。数えると20件ほど。どれも、言われてみればもっともです。

そして「全部やってほしい」と言われます。気持ちはよく分かりますが、全部を同時には直せません。月の稼働時間には上限があるし、上限がなかったとしても、全部を一度に変えると現場は覚え直しになります。

この記事は、最初の3ヶ月で、どの要望から直すかの決め方です。リリース後に発生する費用の内訳や保守の中身はシステムは作ったあとにお金がかかるに書いたので、ここでは改善の順番だけを扱います。

最初の2週間は、直す前に集める

リリース直後は、要望が来た順に直したくなります。直せば喜ばれるし、直す側も手応えがある。ただ、来た順に直すと、声の大きい人の要望から片付いていきます。毎日黙って使っている人の困りごとは、後回しになります。

なので、最初の2週間は、動かない、数字が合わないといった不具合を除いて、要望を1つの表に集めることに使います。表の列は5つで足ります。誰が、どの画面で、何に困ったか、何回起きたか、そのとき代わりにどうしたか。

いちばん大事なのは最後の列です。「代わりにどうしたか」に「Excelに書いておいた」「紙にメモした」と入っていたら、そこでシステムの外に業務が漏れています。この列があるかないかで、次の判断のしやすさが大きく変わります。

使われていない画面を、先に見る

要望の表とは別に、画面ごとに使われているかを見ます。要望が出ていない画面は、問題がないとは限りません。誰も開いていないから要望も出ない、ということがあります。

見るのは、画面で登録された件数と、実際の業務の件数の差です。週に50件の注文があるのに、登録が20件しかないなら、30件はどこか別の場所にあります。この見方は作ったのに使われないシステムになる原因にも書きました。

開かれていない画面が見つかったら、現場の人に理由を聞きます。そもそも要らなかった、という答えなら、その画面は消すかメニューから外して構いません。入口が分からない、入力が面倒、項目が足りない、という答えなら、直せば使われる画面です。使われていない画面を直すのは、新しい画面を足すより先です。

現場が紙に戻った箇所を、いちばん先に直す

要望の表の「代わりにどうしたか」に紙やExcelが出てきた行は、優先順位の一番上に置きます。

紙に戻った箇所を放っておくと、そこから広がります。架空の想定例です。取り消しの処理が画面にないので、取り消しが来た注文だけExcelで管理し始めた。1ヶ月後には、取り消しが入るかもしれない注文もExcelに書くようになり、3ヶ月後にはExcelのほうが正になっている。システムには、正しいかどうか分からない数字が残ります。

この手の直しは、画面としては小さいことが多いです。取り消しのボタンを1つ足す、状態を1つ増やす、備考欄を足す。小さいわりに効くので、最初の1ヶ月の稼働はここに多めに使うのがよいと考えています。

残りの要望は、頻度と影響で並べる

紙に戻った箇所を片付けたら、残りを2つの物差しで並べます。どれくらいの頻度で起きるか。起きたとき、業務にどれくらい響くか。

	業務が止まる、間違いが出る	手間が増える、見にくい
毎日起きる	すぐ直す（例: 締めの前に件数が合わない）	次に直す（例: 毎朝同じ絞り込みをやり直している）
月に数回	次に直す（例: 月末だけ取引先別の集計ができない）	まとめて後で（例: 帳票の文言を変えたい）

毎日起きて業務が止まるものは、表に載る前に直しているはずなので、実際に並べるときに迷うのは右上と左下です。迷ったら、その要望を出した人が毎日使う人かどうかで決めます。毎日使う人の手間は、1日数分でも1ヶ月で積み上がります。

右下の「まとめて後で」は、捨てるわけではありません。文言の変更や並び順の調整は1件ずつは軽いので、他の作業のついでに数件まとめて片付けられることがあります。

月20時間の中で、どう配分するか

ニカゲツのライトプランでは、月額20万円に運用と保守、改善のための稼働が月20時間分まで含まれます。月1回30分の定例は、この時間に数えません。20時間でどのくらいの変更が収まるかの目安は開発中に「やっぱりこうしたい」が出たときに書いたので、ここでは配分の考え方だけを書きます。

架空の想定例で、最初の3ヶ月を並べてみます。1ヶ月目は、紙に戻った箇所と、毎日起きる手間に大半を使う。2ヶ月目は、月に数回起きて業務に響くものと、まとめて片付けられる小さな変更。3ヶ月目に、ようやく「集計をグラフで見たい」のような、あると便利なものに手が回る。

ポイントは、毎月すべてを使い切る計画にしないことです。新しく使い始めた人から、予想していなかった困りごとが出ることがあります。少し余白を残しておくと、その月のうちに対応できます。

20時間を超えそうなときは、着手する前にご相談します。翌月に回すか、上位プランに変えるかを一緒に決めます。黙って超過分を請求することはしません。

月次レポートで、次の月を決める

月が終わると、何に何時間使ったかを月次レポートでお出しします。そのレポートと要望の表を並べて、月1回30分の定例で次の月にやることを決めます。

定例で見るのは3つです。先月直したところで、紙やExcelへの漏れが止まったか。登録件数と業務の件数の差が縮んだか。要望の表に、新しく上のほうに来るものが増えていないか。直したのに漏れが止まっていなければ、直し方がずれています。次の月は、新しい要望より先にそこを見直します。

30分で決めきるには、要望の表を定例の前に共有しておくことです。頻度と影響で並べ替えた案が先にあれば、定例の場では決めるだけで済みます。

3ヶ月たったら、やらないものを決める

3ヶ月たつと、要望の表の下のほうに、ずっと手が付いていない行が残ります。それはたいてい、なくても業務が回っている要望です。この時点で、やらないと決めて表から消して構いません。表が長いままだと、本当に困っていることが埋もれます。

同時に、リリースの前に決めていた「何を見てうまくいったと判断するか」に戻ります。転記の時間が減ったか、誤出荷が減ったか。最初に決めた線を越えていれば、残りの9ヶ月で次の業務に広げる話ができますし、越えていなければ、広げる前にもう一度いまの業務を見直す時期です。判断の線の引き方はMVPで何を検証するのかに書きました。

最初の3ヶ月で全部を直す必要はありません。紙に戻った箇所を止めて、毎日使う人の手間を減らす。そこまでできていれば、残りの期間でシステムを育てていく土台はできています。