レッスン4：業務アプリを組み立てる——申請・台帳・集計

このレッスンで学ぶこと

申請フォームを作るときの基本発想を理解する
承認の流れをデータモデルとして表現できる
台帳として蓄積することの意味を理解する
集計と絞り込みの基本的な考え方を身につける
入力してもらう項目を減らす設計の重要性を理解する

前の2つのレッスンでは、トリガー・アクション・条件分岐という業務の流れの言語と、テーブル・レコード・リレーションというデータの持ち方の言語を学びました。このレッスンからは、それらを実際の業務に当てはめていきます。まず取り上げるのは、フォーム／データベース型の代表的な使いどころである、申請・台帳・集計の3つです。

申請フォームの作り方の発想

多くの職場には、紙やメールで回している申請の仕組みがあります。「休暇申請」「経費精算」「備品購入の依頼」といったものです。これらをノーコードのフォームに置き換えるとき、最初にやるべきことは、画面の見た目を考えることではありません。「この申請が最終的にどんなデータとして残ってほしいか」を、先に決めることです。

レッスン3で学んだ考え方に沿えば、申請フォームは「申請一覧テーブルに、新しい1件のレコードを追加する入り口」と捉えられます。フォームの各入力欄は、テーブルのフィールドに対応します。つまり、フォームを設計する作業は、実質的に「テーブルのフィールドを決める作業」と同じです。

申請日（自動で記録される場合が多い）
申請者（ログインしている人の情報から自動で入る場合が多い）
申請の種類
金額や日数などの数値
理由や備考

先にテーブルの形を決めてからフォームを作ると、あとから「この項目が足りなかった」と気づいて手戻りする回数が大きく減ります。

💡 ポイント フォームは「見た目の入り口」、テーブルは「データの本体」です。順序としては、テーブルの形を先に決め、その入り口としてフォームを配置する、という考え方をおすすめします。

承認の流れ

申請には、多くの場合「承認」という工程が伴います。承認の流れは、レッスン2で学んだ条件分岐の典型的な応用です。

シンプルな例では、「申請が送信されたら、上長に通知が届き、上長が承認すると完了する」という1段階の流れになります。もう少し複雑になると、「金額に応じて承認する人数が変わる」「複数人の承認をすべて得て初めて完了する」といった流れも出てきます。

flowchart TD
  A[申請が送信された] --> B{金額は5万円以下か}
  B -->|はい| C[上長のみ承認する]
  B -->|いいえ| D[上長が承認する]
  D --> E[部門責任者が承認する]
  C --> F[申請完了]
  E --> F

承認の流れをデータの面から見ると、「承認状況」というフィールドが、申請一覧テーブルの中でどう変化していくかという話に置き換えられます。「未承認」「上長確認中」「部門責任者確認中」「承認済み」「差し戻し」といった状態を、あらかじめフィールドの選択肢として用意しておくことで、いまどの段階にあるかが一覧ですぐに把握できます。

📝 補足 承認の流れを複雑にしすぎると、確認する人数が増えるほど、どこかで滞留しやすくなります。承認の段階は、本当に必要な人数まで絞り込むことをおすすめします。段階を増やすことは簡単ですが、減らすことは、関係者との調整が必要になり、あとから難しくなりがちです。

直列の承認と並行の承認

複数人の承認が必要な場合、レッスン2で学んだ直列と並列の考え方がそのまま当てはまります。

「上長が確認したあとに、部門責任者が確認する」というように、順番に確認が進む形は直列の承認です。前の人の承認が終わるまで、次の人には回りません。一方、「上長と経理担当者が、それぞれ独立に確認する」というように、互いに待たずに同時進行できる形は並行の承認です。

直列の承認は、承認する順番に意味がある場合（金額の妥当性を確認してから、予算の範囲を確認するなど）に向いています。並行の承認は、確認する観点が互いに独立している場合に向いており、全体の完了までの時間を短縮できます。承認フローを設計するときは、「この2人の確認に、順番の意味はあるか」を自問すると、直列にすべきか並行にすべきかを判断しやすくなります。

台帳としての蓄積

申請が積み重なっていくと、それは自然に「台帳」になります。台帳とは、過去の記録を時系列で蓄積し、あとから参照・検索できる状態にしたデータのことです。

紙の台帳との大きな違いは、検索と絞り込みが容易な点です。「先月の交通費申請だけを見たい」「特定の申請者の申請履歴だけを見たい」といったことが、ノーコードツールでは条件を指定するだけで実現できます。紙の台帳でこれをやろうとすると、1件ずつめくって探す必要がありました。

台帳として設計するときに意識したいのは、「あとから消さない」という前提です。申請の状態が「差し戻し」になったからといって、そのレコードを削除してしまうと、「なぜ差し戻されたのか」という経緯の記録が失われます。状態を更新して残す、という発想を基本にします。

⚠️ 注意 「間違えて登録したものは消せばよい」という感覚で運用を始めると、あとから「あの申請はどうなっていたか」を追えなくなります。誤って登録した場合も、削除ではなく「取消」という状態を用意して記録を残す設計のほうが、あとで振り返るときに安心です。

集計と絞り込み

台帳にデータが蓄積されると、次に必要になるのが集計と絞り込みです。「今月の経費申請の合計金額はいくらか」「部署ごとの申請件数はどう推移しているか」といった問いに、すぐ答えられるようにします。

ノーコードツールの多くは、テーブルのデータをもとに、条件を指定するだけで合計・件数・平均などを自動で計算する機能を備えています。表計算ソフトで言えば、集計関数やピボットに近い働きです。ここでも、レッスン3で学んだ「データの持ち方」が生きてきます。金額が1つのフィールドとしてきちんと数値で入っていれば、合計はワンクリックで求められます。逆に、「3万2千円（交通費含む）」のように文章の中に金額が埋め込まれていると、自動での集計はできません。

絞り込みについても同様です。「承認状況が未承認のものだけ」「金額が10万円を超えるものだけ」といった条件は、フィールドがきちんと分けられていれば、組み合わせて指定するだけで実現できます。

集計の結果は、次のような一覧として自動的に作られます。

部署	申請件数	承認済み金額の合計
総務	12件	84,000円
営業	27件	231,500円
経理	8件	45,200円

このような集計を人の手で毎月作ろうとすると、台帳から該当する行を探し、電卓で合計するといった作業が必要になります。データの形さえ整っていれば、この作業はノーコードツールの集計機能に任せられます。

📖 もっと詳しく 集計の結果を、さらにグラフのような形で見せたい場合もあります。多くのノーコードツールは、集計した数値を棒グラフや折れ線グラフとして表示する機能も持っています。ここでは深く扱いませんが、「集計できるデータの形にしておけば、あとから見せ方は自由に選べる」という考え方だけ押さえておいてください。

入力してもらう項目を減らす設計

申請・台帳・集計の仕組みを組み立てるとき、最も見落とされやすいのが「入力する人の負担」です。管理する側が欲しい情報をすべて盛り込もうとすると、入力欄がどんどん増えていきます。

入力欄が多いフォームには、次のような問題が起こります。

入力に時間がかかり、後回しにされる
必須ではない項目まで埋めようとして、適当な値が入力される
入力ミスの起きる箇所が増える

これを避けるための考え方が、「あとから追加できる情報は、最初のフォームに入れない」というものです。例えば、詳しい理由の説明は、承認する人が必要と判断したときだけ追記できるようにする、といった工夫です。最初の入力は、判断に最低限必要な項目だけに絞り込みます。

本当に申請の判断に必要な項目か
別の場所（申請者一覧テーブルなど）からすでにわかる情報ではないか
選択肢から選べる項目を、自由記述にしていないか

自由記述の欄は、書く側にとって負担が大きいだけでなく、あとで集計や絞り込みをするときにも扱いにくくなります。可能な限り、選択肢から選ぶ形に変えておくと、入力する側と、あとで使う側の両方が助かります。

🔰 初学者の方へ 「項目を減らす」と聞くと、情報が足りなくなるのではと心配になるかもしれません。ですが、実際に運用してみると、最初に想定した項目の半分も使われないことが多くあります。まず少ない項目で作り、使いながら本当に必要な項目だけを足していくほうが、結果として無駄のない仕組みに育ちます。

講師の現場メモ：項目を削っただけで動き出した申請フォーム

私（岩井）が業務改革部門で担当していたときの話です。ある部署から「備品購入の申請が、紙の稟議書のままで時間がかかっている。ノーコードで仕組みを作ってほしい」という依頼を受けました。

最初に作ったフォームは、紙の稟議書をそのまま置き換えるつもりで、項目を17個用意しました。購入理由、緊急度、代替案の検討有無、過去の同種購入の実績、想定される効果、関連部署への影響、など、紙の稟議書に書かれていた項目を、ほぼすべて引き継いだ形です。

ところが、公開してから2週間、申請の件数はほとんど増えませんでした。使ってもらえるかを確認するために、実際に使うはずだった数名に話を聞いたところ、「入力に15分もかかる。結局、紙のほうが早い気がして後回しにしてしまう」という声が返ってきました。

そこで、項目を17個から6個まで減らしました。購入したいもの、金額、個数、緊急度、簡単な理由、担当部署だけです。「代替案の検討」のような、本来は上長が判断すべき項目は、承認する側が必要に応じて申請者に確認する運用に変えました。

結果、入力にかかる時間は2分程度まで短くなり、翌月には申請件数が紙の時代の3倍近くまで増えました。使われる仕組みとそうでない仕組みの差は、機能の豊富さではなく、入力する人の負担の大きさにあることを、このとき強く実感しました。管理する側の「知りたい」を優先しすぎると、使う側の足が止まってしまいます。

まとめ

このレッスンでは、以下のことを学びました。

フォームは入り口、テーブルは本体。テーブルの形を先に決めてからフォームを作る
承認の流れは、条件分岐と「承認状況」フィールドの状態の変化として表現できる
台帳は削除ではなく状態の更新で記録を残す前提で設計する
集計と絞り込みは、フィールドがきちんと分けられていて初めて自動化できる
入力してもらう項目は最初から絞り込み、あとから追加できる情報は最初のフォームに入れない

次のレッスンでは、複数のサービスを組み合わせて動かす「ワークフロー自動化型」のノーコードツールを扱います。申請フォームで受け取ったデータを、ほかのサービスに自動でつないでいく考え方を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。