業務アプリ開発の進め方｜4つの作り方と着手前に決める3つのこと

業務アプリの開発と聞くと、会社全体を作り替える計画を思い浮かべるかもしれません。
実際に多くの会社が始めているのは、日報の集計や在庫の記録といった一つの業務からです。
最初にどの業務を選ぶかで、その後にかかる手間も費用も変わってきます。

この記事では、業務アプリの開発に着手する前に決めることから、4つの選択肢の比べ方、進め方の5段階までを整理しました。
会計や労務のデータを扱う場合に確認したい法律の要件にも触れています。

業務アプリの開発は全社の作り替えではなく1つの業務から始まる

業務アプリの開発は、大きな計画から入ると途中で止まりやすくなります。
まずは、業務アプリがどこまでを担当するものなのかを整理しておきましょう。

業務アプリは特定の業務だけを処理するために作るソフト

業務アプリとは、社内の特定の業務を処理するために作るソフトウェアのこと。
たとえば、日報の提出、備品の貸出、車両の予約といった単位で作られます。
扱う範囲が狭いぶん、現場の手順に合わせて細かく作り込めるのが持ち味です。

会社ごとに違いが出るのは、まさにこうした細かい手順の部分でしょう。
市販のソフトでは合わない箇所が残るため、自社で作るという選択肢が生まれます。

業務アプリと業務システムは対象にする範囲が違う

業務アプリと業務システムという2つの言葉に、定まった定義はありません。
同じ意味で使う会社もあるため、この記事では規模の違いで呼び分けます。
業務システムは、販売管理や会計のように会社の基幹となる流れ全体を支えるもの。
業務アプリが受け持つのは、その流れの中の一部分です。
同じ「開発」という言葉でも、必要な期間も関わる人数も同じにはなりません。

規模を取り違えると、小さく始められる業務まで大きな計画に巻き込んでしまいます。
アプリで足りるのか、システムとして考えるべきかを最初に見極めてください。

最初に開発する業務アプリは3つの条件で選ぶ

最初の1本は、効果が見えやすく、うまくいかなくても影響が小さい業務が向いています。
次の条件に当てはまる業務から候補を挙げてみましょう。

3つとも当てはまる業務ほど、アプリにしたときの変化は現れやすいでしょう。

業務アプリの開発を始める前に決めておく3つのこと

業務アプリの開発でつまずく原因の多くは、作り始めた後ではなく前にあります。
ツールを選ぶより先に決めておきたいのは、次の3点です。

どの作業からどの作業までをアプリにするか線を引く

アプリにする範囲は、業務の入口と出口で区切ると決めやすくなります。
受注業務であれば、「注文を受けてから受注一覧に載るまで」といった形です。
請求や入金まで含めると、会計ソフトの領域まで広がってしまいます。

線を引かないまま社内の要望を集めると、機能は増え続けるでしょう。
最初はいちばん時間がかかっている作業だけに絞る判断が現実的です。

入力する人と管理する人を先に決める

業務アプリを動かすのは、日々データを入力する人です。
入力する担当が決まらないまま作ると、完成後に誰も使わないアプリになります。
あわせて、項目の追加や不具合の窓口になる管理者も決めておきましょう。

管理者が不在のアプリは、作った担当者の異動とともに使われなくなるものです。
社長自身が問い合わせ窓口になってしまう会社も見受けられます。

いま使っているソフトとのデータの受け渡しを確認する

業務アプリは、会計ソフトや給与ソフトと数字がつながって効果が出ます。
つながらない場合、手作業の転記が残り、狙った効率化には届きません。
着手前に確認しておきたいのは、次の3点です。

この3点が決まっていれば、開発会社との打ち合わせも短く済むでしょう。

業務アプリを開発する前に比べたい4つの選択肢

業務アプリを用意する方法は、大きく4つに分かれます。
開発するかどうかも、この4つを比べる中で決まるものです。
どれが優れているかではなく、自社の状況に合うかどうかで選びましょう。

市販の業務ソフトをそのまま使う

市販のソフトで足りるなら、開発せずに済みます。
勤怠管理や経費精算のように、会社をまたいで手順が似ている業務が向いているでしょう。
先に市販品を探し、合わないと分かってから開発を検討する順番が無駄を生みません。

ノーコード・ローコードのツールで作る

ノーコードは、プログラムを書かずに画面や項目を組み立てられるツールです。
ローコードは一部だけコードを書き足せるため、細かい要望にも応じられます。
社内の担当者が自分で直せる点が、現場の業務アプリと相性の良いところでしょう。

作りながら形を決められるため、要件が固まりきらない業務にも使えます。
ツールごとの進め方は、FileMaker開発ガイドもあわせてご覧ください。

開発会社に依頼して作ってもらう

自社に合わせて一から作る方法なら、要望を細かく反映できるのが利点です。
その代わり、要件を伝える側の準備が結果を左右します。
何をしたいかを言葉にできていないと、見積もりの前で話が止まってしまうのです。

打ち合わせの前に、次の資料をそろえておくと話が進みます。

依頼先の探し方については、経理システム開発の依頼先の選び方で判断基準を解説しています。

社内の担当者が内製する

社内にシステムへ強い担当者がいるなら、内製も選択肢になるでしょう。
現場の要望をその場で反映できるため、修正の速さは他の方法に勝ります。
ただし、その担当者が退職した後に誰も直せない状態は避けなければなりません。

内製する場合は、画面と項目の一覧を書面で残すことを条件にしてください。

選択肢	向いている場面	注意したい点
市販の業務ソフト	手順が他社と似ている業務	自社独自のルールには合わせられない
ノーコード・ローコード	現場の要望が変わりやすい業務	ツールの機能を超える処理は作れない
開発会社へ依頼	自社独自の手順が多い業務	要件を伝える社内の準備が必要
社内で内製	修正が頻繁に発生する業務	担当者の退職で止まるおそれがある

費用の見方については、業務システム開発費用の相場で内訳とあわせて整理しています。

業務アプリ開発の進め方は5つの段階に分かれる

作り方が決まったら、開発の進め方を確認します。
業務アプリを新たに作る場合の流れは、次の5段階です。

試作を現場で試す段階を飛ばすと、完成後に使われないアプリになりがちです。
社内の合意は、説明よりも実物を触ってもらう方が早く得られます。

会計・労務のデータを扱う業務アプリの開発では保存の要件を確認する

業務アプリで扱うデータには、法律で保存の仕方が決まっているものがあります。
請求書や賃金台帳がその代表。
設計の段階で見落とすと、完成した後の作り直しは避けられません。

請求書や領収書をデータで受け取るなら電子帳簿保存法の要件がかかる

メールやクラウドで受け取った請求書は、電子取引のデータとして保存しましょう。
国税庁は、保存にあたって真実性と可視性を確保する要件を示しています。
自社で作ったアプリで保存する場合も、満たすべき要件は変わりません。

真実性の確保については、次の4つのいずれかを行う方法が示されています。

自社開発のアプリで選びやすいのは、3つ目の仕組みか4つ目の規程でしょう。
可視性については、画面と書面へ速やかに出力できる状態と、検索機能の確保が求められます。
検索の基準とされているのは、取引年月日・取引金額・取引先の3項目です。

なお、基準期間の売上高が5,000万円以下の会社では、検索機能の確保が不要になる場合があります。
税務職員からのダウンロードの求めに応じられるようにしていることが条件です。
ただし、社内で必要な書類を探す手間を考えれば、検索できる設計にしておく方が実務は楽でしょう。

自社開発のアプリは委託して作った場合も概要書の備付けが必要

見落とされやすいのが、自社開発のプログラムを使う場合の書類です。
電子取引データの保存では、自社開発のプログラムを使うときに限った要件があります。
国税庁が求めているのは、システムの概要を記載した書類の備付けです。
市販のソフトを買って使う場合には求められません。

ここでいう自社開発には、会社が主体となって開発会社へ委託したプログラムも含まれます。
そう示しているのは、国税庁の取扱通達です。
市販のソフトやノーコード・ローコード製品は、利用方法によって扱いが異なります。
自社が該当するかどうかは、個別に確認してください。

国税関係帳簿を電子データで保存する場合は、備え付ける書類の種類が増えます。
自社開発のプログラムを使うときに取扱通達が挙げているのは、次の4種類です。

注意したいのは、操作説明書を作っただけでは1つ目の概要書にならない点です。
操作説明書にシステム概要書と同等の内容が含まれていなければ、システムの構成や処理の概要も用意します。
1つの書類が複数の区分を満たす場合は、区分ごとに別の書類を作る必要はありません。
これらの書類は、紙以外の方法で備え付けても構いません。
オンラインマニュアルやヘルプ機能に同等の内容が入っていれば、備え付けたものとして扱って差し支えないというのが国税庁の説明。
ただし、画面と書面へ速やかに出力できる状態が条件になります。
要件の詳しい内容は、国税庁の電子帳簿保存法一問一答をご覧ください。

賃金台帳や労働者名簿は労働基準法で保存が義務づけられている

勤怠や給与を扱うアプリで確認したいのは、労働基準法の定めです。
労働者名簿は第107条、賃金台帳は第108条が、会社に作成を義務づける条文です。
これらの記録の保存期間は第109条で5年間とされ、当分の間は3年間とする経過措置が置かれています。

アプリの中で古いデータを自動的に消す仕組みにしていると、保存期間を満たせません。
保存期間の数え方は、厚生労働省の解説にまとまっています。
設計に入れておきたい項目を、下の表に整理しました。

設計に入れておく機能	必要になる理由
訂正・削除の記録が残る	電子帳簿保存法の真実性の確保
取引年月日・取引金額・取引先で検索できる	電子帳簿保存法の可視性の確保
画面と書面にすぐ出力できる	税務調査や労働基準監督署の調査での提示
操作説明書や概要書を残す	自社開発の場合に求められる書類の備付け
保存期間が過ぎるまでデータを残す	労働基準法による記録の保存
閲覧できる人を役割で分けられる	給与など機密性の高い情報の管理

自社の帳簿がどの要件に当たるかは、税理士や社労士に確認しましょう。
人事のデータについては、電子帳簿保存法と人事システムでも書類の整理の仕方を解説しています。

業務アプリ開発でよくある失敗と防ぎ方

業務アプリの開発で起きる失敗は、原因がはっきりしているものがほとんどです。
起きやすい4つを、防ぎ方とあわせて整理しました。

よくある失敗例	起きる理由	防ぎ方
機能が増え続けて完成しない	社内の要望をすべて入れようとした	最初の範囲を書面にして固定する
完成したのに使われない	入力する担当を決めていなかった	試作の段階で現場に触ってもらう
作った人しか直せない	画面と項目の仕様を残していない	一覧表と操作説明書を必ず作る
会計ソフトと数字が合わない	データの受け渡しを後回しにした	着手前に項目を突き合わせておく

3つ目の失敗は、担当者ひとりに知識が集まる属人化そのものです。
仕様を残す手順は、中小企業の業務マニュアル作成の考え方がそのまま使えます。

業務アプリの開発を自社だけで進めにくい3つの場面

自社で判断しきれない場面では、早い段階で専門家に相談する方が費用を抑えられます。
次の3つに当てはまるなら、設計に入る前の相談をご検討ください。

いずれも、作り直しになれば費用が二重にかかる論点。
代わりに判断できる人が社内にいなければ、社長自身が仕様を決める側に回るほかありません。

まとめ｜業務アプリの開発は対象を絞ってから方法を選ぶ

業務アプリの開発は、対象を1つの業務に絞るところから始まります。
範囲と担当を決めてから方法を選べば、途中で計画が膨らむ事態は避けられるでしょう。
会計や労務のデータを扱うなら、保存の要件を設計に織り込んでおいてください。

業務アプリの開発では、作り方だけでなく、対象業務や法令の要件まで含めた設計が欠かせません。

JNEXTグループでは、DX推進室を窓口に、税理士・社労士の知見も踏まえて支援しています。
相談できる範囲は、アプリ化する業務の整理から、会計・労務データを扱う際の要件確認までです。

社内にDXを進める人材がいない場合の進め方は、DX推進人材がいない企業の解決策でも解説しています。
開発の方向性が固まっていない段階でも、まずは無料相談をご利用ください。