【業務改善】設備工事会社が、請求書業務のお助け社内アプリを 2か月で開発した話②

※別媒体で公開している記事の転載です。内容は2022年3月時点のものです。

おさらい

こんにちは！
株式会社エコテック(クロスティーホールディングス)のデジタル推進室の大村です。(北海道にある設備工事会社のIT部門の社員です)
前回は社内アプリ開発までの背景と完成したもの について紹介したので、
今回は私がしてきた失敗と、そこから得た学びを熱く共有していきたいと思います。

これから業務改善していこう！という方々にとっては学びに。熟練の皆様には共感していただけるような内容になっているはず..!!

前回のお話はこちら ↓

要件定義~開発~運用

業務に関する知識が何もなかった私は、まずは担当者のところへ赴いて、「請求書のチェックって何をしているの？」「請求書を持ち運ぶときのはどのような状況なの？」などのヒアリングをしていきました。
前から問題になっていた分、問題の大枠を掴むのには時間もかからず、自分の中で今回のアプリに必要な機能がいくつか見えてきて、機能を書き出したりしながら、固まったところからアプリの作成も進めていきましたが、ここが良くなかった….!!

その道のプロじゃなくても

内製開発では、大手ベンダーのように、各工程のプロが連携して進めていくことはできません。課題発見 > 要件定義 > 開発 > 運用まで通しで自分が密に関わっていく必要があります。

内製開発の強みとして、運用->改善のサイクルが早いというものはありますが、作るものが最初は品質の悪いものでも良いということにはなりません。
自分自身この２か月で多くの失敗や手戻りをして、開発前の設計や準備が何よりも大事だと感じました。
そこで「業務改善担当者が改善前に最低限やっておくべき３つのこと」を失敗を交えながら紹介いたします。

1. 一言でアプリの役割を表すコンセプトを立てる

大枠で課題を掴めてはいても、ゴールが明確ではないまま進んでしまったため、担当者さんの要望や作りたい機能の積み上げになってしまい、拡張性が損なわれてしまったり、手戻りが多く発生してしまいました。

「結局このアプリは一言でいうとなにができるの？」
これが説明できれば、開発途中に迷ったときの取捨選択が容易になります。
逆にこれが説明できないと、夢中になって走っている時に 積み上げ思考になってしまいがちです。
作成する機能も、やりたいことの積み上げではなくコンセプトからの逆算で決めていくべきでした。

2. ユーザー(担当者)とゴールの認識を合わせる

積み上げではなくゴールを考えることが大事だ…! と分かったのは良かったのですが、"ゴールを達成した状態"とはどういう状態なのかを定義できていなかったため、運用の段階で発覚した考慮漏れなどがありました。

例えば、家事の業務改善をするとして、その中のフローに「洗濯を終わらせる」というゴールがあるとします。
・洗濯機の稼働が終了したら完了なのか
・洗濯して乾燥機を回し終わったら完了なのか
・洗濯物を出して干したら完了なのか。
この認識が業務担当者と開発者で違うと大きな手戻りや予想外の工数がかかってしまいます。
そして開発者は、業務担当者が洗濯し終わった後、次に何の家事をするのだろう？とか、２回以上洗濯機を回すこともあるのか？を知る必要があります。
共通認識を合わせるためにも、画面を見ていただく機会を定期的に作るなどの施策をして、軌道確認をしながら進めていくべきでした。

3. 業務改善の効果測定は"開発前"にする

効果の測定なのに開発前？
大げさな言い方ではあるのですが、間違いではないのです。
私は ある程度業務のことを分かってアプリの構想も固まってくると、何度も担当者さんの業務時間を奪っているという意識と、アプリを待っている人がいる！という焦りも相まって、すぐに開発を始めてしまいました。

請求書一枚探すのは大変だし時間かかる　ということは分かっていますが、その作業に何分かかっていますか？などは定量的に分からないという状態です。定量的な評価は経営判断にも必要な大事な指標のため、効果測定の枠組みと現状の計測は開発前に実施して、運用フェーズでは答え合わせをするだけ にしておく必要がありました。
これが出来れば 課題がより具体化されて、1のコンセプトの決定も容易になりますし、プロジェクト成功への道しるべが明確になります。

出来上がったモノと、その先にあるもの

運用が始まって半月ほど経ちましたが、良い声も改善要望も直接自分に届く状況にモチベーションを感じます。「300万円ほどの入金設定漏れの早期発見にアプリが役に立ったよ！ 」と聞いた時は凄く嬉しかったですし、改善点も普段の雑談から聞けるのは社内開発ならではです。

冒頭の自己紹介でも書いたように、私は元々エンジニアとして Slerで開発メインで働いていたのですが、その時はアプリを開発したら納品して終わりで、納品先の会社ではどのくらいの利益が出るのか・作ったものがどの業界に影響があるのか は自分が知り得ることでもないし、知る必要もない とすら感じていました。
しかし今は、課題を担当者の方と一緒になって考え、開発して、これからも運用していくうえで、完成の先にあるもの がいかに大切かを深く感じています。
私のいるデジタル推進室は、当社の役員室と距離がとても近く、頻繁に役員の方が部屋に訪ねてきてくださいます。そこでは、「請求書アプリのデータを使ったら資金繰りをもっと改善できるのではないか？」や「請求金額の推移をみたらこんなこと分析できるかもしれないね！」など、エンジニアだけでは出てこない発想が溢れてきます。これを吸収して、この発想ができる人間になるのが、社内エンジニアとして目指すべき姿なのではないかと思っています。

まとめ

当たり前のような学びの共有になってしまったかもしれませんが、これが結構難しい...。 本記事が 日々業務改善と奮闘している方々の振り返りや学びに少しでも繋がっていれば嬉しいです。また、あわよくばエコテックという会社が何やらDXを頑張っているらしいという事を知ってもらえると嬉しいです。(前回に引き続き 失礼します)

これからも更新していく予定ですので、興味もっていただけたら他の記事もぜひ….!!!