【事例】社内ツールを短いサイクルで形にした話｜要件の切り方（匿名・型）

社内の業務改善のために「ツールを作ろう」と決まった際、多くのプロジェクトが「要件定義の長期化」という罠に陥ります。現場の要望をすべて聞き入れ、例外処理を網羅し、完璧なUIを求めた結果、リリースまでに半年を要し、その頃には業務フロー自体が変わってしまっている――。これはIT実務の現場で頻発している事象です。

本記事では、社内ツールを短いサイクル（1〜2週間）で形にし、現場に素早く定着させるための「要件の切り方」と、具体的な実装事例を解説します。高額なスクラッチ開発や多機能すぎるSaaSを導入する前に、まずは「最小限の機能」で現場の課題を解決する手法を身につけましょう。

社内ツール開発で「リリースまで半年」はなぜ失敗するのか

社内向けのシステム開発において、開発期間が長引くことは、単にコストが増える以上のリスクを孕んでいます。

現場の熱量と業務フローの賞味期限

現場から「不便だ」という声が上がった瞬間が、改善の熱量が最も高い時期です。要件定義に3ヶ月、開発に3ヶ月かけていると、現場の担当者はその不便さに「慣れて」しまうか、あるいは独自にエクセルマクロ等で場当たり的な対策を講じてしまいます。また、昨今のビジネス環境では3ヶ月もあれば組織図やオペレーションが変わることも珍しくありません。時間をかけた「完璧なツール」は、リリース時点で既に「現状に合わないツール」になっている可能性が高いのです。

要件を「盛りすぎる」ことで発生する実装のコンフリクト

「あれば便利」な機能をすべて盛り込むと、データの依存関係が複雑化します。例えば、「承認機能」「在庫連動」「会計ソフト連携」「自動メール通知」をすべて最初から実装しようとすると、それぞれの仕様変更が他方に影響し、デバッグと調整だけで数週間を浪費します。社内ツールにおいて、機能の多さは使い勝手の良さに直結しません。むしろ、一つの目的に特化したシンプルなツールの方が、ユーザーの学習コストを抑え、定着率を高めることができます。

短いサイクルで形にするための「要件の切り方」3つの型

「どこまで機能を削るべきか」という問いに対し、実務で有効な3つの型を紹介します。

【型1】「入力」と「蓄積」だけに絞る（参照・加工はスプレッドシートで完結）

最も工数を削減できるのが、この型です。UI（フロントエンド）はデータの入力画面だけを用意し、データの表示や高度な分析は、バックエンドにあるGoogle スプレッドシートやExcel、あるいはBIツールに任せます。

• 残す機能：スマホ・PCからのデータ入力、写真アップロード、必須項目のバリデーション。
• 捨てる機能：ダッシュボード表示、複雑なグラフ、検索・フィルタリング画面、PDF出力。

この型を実践する際、特に重要なのがデータ基盤との連携です。例えば、以下の記事で解説しているようなデータアーキテクチャの考え方は、社内ツールのデータ設計においても非常に参考になります。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

【型2】既存の紙・エクセルを「1機能だけ」デジタル化する

業務プロセス全体をデジタル化しようとせず、最もボトルネックになっている「1ステップ」だけを切り出します。例えば、交通費精算全体ではなく「領収書の写真を撮ってOCRで金額を読み取るだけ」のツールを作る、といったアプローチです。既存の運用（エクセルへの貼り付け等）は残しつつ、入力負荷だけを下げることで、開発期間を劇的に短縮できます。

【型3】通知・承認フローの自動化に特化する

「データの保管」よりも「情報の伝達」に課題がある場合に有効です。SlackやMicrosoft Teamsへの通知、およびシンプルな承認ボタンの実装に絞ります。複雑なデータベース構築を後回しにすることで、即座に「動くもの」をリリースできます。

【事例】10日間でローンチした社内備品管理・申請ツール

実際に、ある中堅企業の総務部で実施した「備品管理ツール」の高速開発事例を紹介します。従来は紙の台帳で管理されていましたが、これを10日間でアプリ化しました。

プロジェクト開始時の「捨てた」要件一覧

開発着手時に、以下の要件を「フェーズ2（あるいは実装しない）」として切り捨てました。

• バーコードリーダー機能（手入力で十分と判断）
• 在庫切れ時の自動発注機能（メール通知のみに変更）
• 部門別の予算管理機能（スプレッドシート側で集計すれば良いと判断）
• 過去1年分のデータの初期移行（直近1ヶ月分のみ移行）

採用した技術スタック（AppSheet × Google Workspace）

開発期間を最短にするため、Google Cloudが提供するノーコードツール「AppSheet」を採用しました。

• データベース：Google スプレッドシート
• アプリ本体：AppSheet（スプレッドシートから自動生成）
• 通知：Google Apps Script (GAS) 経由のGmail通知

このようにGoogle Workspaceの既存機能を活用することで、インフラ構築の手間をゼロにしました。同様の手法は、以下の記事でも詳しく解説しています。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

社内ツールの高速開発に最適なツール比較

要件を絞り込んだ後、どのツールで実装すべきかは、既存のライセンス環境と求める自由度によって決まります。

実務で使える「最短開発」ステップバイステップ

ツールを1週間でリリースするための具体的な手順を解説します。

ステップ1：データ項目（テーブル）の最小単位を定義する

UIを作る前に、必ず「どのデータを保存するか」を決定します。この際、スプレッドシートの1行を「1つの事象（トランザクション）」として設計するのがコツです。「いつ・誰が・何を・どうした」という4つの要素が含まれていれば、後からどのようにでも加工できます。多すぎるカラム（列）は入力のハードルを上げるため、必須項目以外は極限まで削ります。

ステップ2：UIは「標準機能」のまま、カスタマイズを一切禁止する

「ボタンの色を青くしたい」「ロゴをここに置きたい」といったデザイン上の要望はすべて無視します。ノーコードツールのデフォルトデザインをそのまま使うことで、CSSの調整やレスポンシブ対応にかかる時間を100%カットできます。社内ツールにおいて、見た目よりも「データが正しく保存されること」が100倍重要です。

ステップ3：ユーザーテストではなく「実業務」でいきなり使わせる

入念なテスト期間を設けるのではなく、一部の信頼できる現場スタッフに「今日からこれで入力してみて、不具合があったらすぐ直すから」と伝えて使い始めてもらいます。これを「Dogfooding（ドッグフーディング）」と呼びますが、実業務で使って初めて「実はこの項目は不要だった」「この順番で入力できないと使いにくい」という真の要件が見えてきます。

よくあるエラーと対処：

・データ型の不一致： 数値を入れるべき場所に「不明」などのテキストが入ると、集計時にエラーとなります。入力フォーム側でバリデーション（数値のみ許可など）を必ず設定しましょう。

・権限設定ミス： AppSheetやPower Appsでは、共有範囲を誤ると全社に公開されてしまう、あるいは閲覧できないといったトラブルが発生します。リリース前に「テストアカウント」でアクセスできるか必ず確認してください。

負債化を防ぐための「運用とガバナンス」

「短いサイクルで作る」ことと「作りっぱなしにする」ことは違います。将来的にシステムの規模が大きくなった際の出口戦略が必要です。

例えば、最初は簡易的なアプリで管理していた経費精算や会計業務が、会社の成長に伴い手に負えなくなることがあります。その場合は、無理に自作ツールを拡張せず、バクラクやfreeeといった専門のSaaSへ移行すべきです。以下の記事では、そのような「ツールの責務分解」について詳しく論じています。

【完全版】「とりあえず電帳法対応」で導入したシステムが経理を殺す。Bill One等の受取SaaSと会計ソフトの正しい責務分解

ドキュメントは「ER図」と「権限設定」だけで良い

詳細なマニュアルは不要ですが、以下の2点だけはスプレッドシートの別タブ等に残しておきましょう。

• データ構造（どのテーブルが何と紐づいているか）
• 誰にどの権限を与えているか

これさえあれば、担当者が変わってもシステムの全体像を数分で把握できます。

拡張が必要になった時の「SaaS移行」判断基準

自作ツールを使い続けるべきか、SaaSに切り替えるべきかの判断基準は「法対応」と「外部連携」です。インボイス制度や電帳法のような法改正への対応が必要な場合、あるいは他のSaaS（Salesforce等）と高度なAPI連携が必要になった場合は、自作ツールの限界です。その時点で、蓄積されたデータをCSVでエクスポートし、専門ツールへ移行しましょう。

社内ツール開発の成功は、機能の多さではなく「いかに早く現場の負を解消するか」にかかっています。今日から、最も小さな要件を一つだけ切り出し、形にすることから始めてみてください。