製品資料
無料トライアル
お問い合わせ社内の稟議や経費精算を効率化したいものの、専用ツールの導入費用は抑えたいとお悩みではありませんか。ワークフローシステムは、ExcelやGoogleスプレッドシート、ノーコードツールなどを活用して自作可能です。自作によりコストを抑え、自社に最適なシステムを構築できる一方、属人化やセキュリティ面でのリスクもあるため、正しい開発方法の理解が不可欠です。
この記事でわかること
- 自作するメリットと注意すべきデメリット
- Excelや無料ツールを使った5つの作成方法
- 失敗を防ぐための開発手順4ステップ
- 自作する際の注意点と現状業務の整理方法
- 自作と専用システム導入のコスト効率の違い
ワークフローシステムを自作するメリット
既存の製品を導入するのではなく、ワークフローシステムを自作するメリットとして、まず挙げられるのが柔軟性の高さです。企業ごとに異なる稟議や承認のプロセスに対して、妥協することなく最適な環境を構築できます。
コストを最小限に抑えられる
コストを最小限に抑えられる理由は、初期費用や月額利用料が発生しないためです。市販の専用システムを導入する場合、ユーザー数に応じたライセンス費用や、導入時のサポート費用などの多額の投資が必要になることが少なくありません。
一方で、社内にすでに導入されている表計算ソフトやグループウェアを活用して構築すれば、追加の金銭的負担をかけずに運用を開始できます。限られた予算の中で業務効率化を進めたい企業にとって、非常に有効な選択肢となります。
| 項目 | 市販システム導入 | 自作 |
|---|---|---|
| 初期費用 | 数十万円から数百万円 | 基本的に無料（既存の環境を利用する場合） |
| ランニングコスト | ユーザー数に応じた月額課金 | 既存の環境の利用料のみ |
| 追加オプション費用 | 機能追加ごとに発生 | 自社対応のため不要 |
自社の業務フローに完全対応できる
自社の業務フローに完全対応できることで、現場の従業員が戸惑うことなく新しい仕組みに移行できます。市販の製品は汎用的に作られているため、どうしても自社の特殊な承認ルートや独自の入力項目に合わない部分が出てくることがあります。
そのような場合、業務の進め方をシステムに合わせて変更しなければならず、現場の負担が増加する原因となります。社内でゼロから構築すれば、現在の紙の申請書と全く同じレイアウトを画面上で再現したり、複雑な条件分岐を伴う決裁ルートをそのままシステム化したりできます。現場の混乱を避けつつ、スムーズな電子化を実現できるのが大きな強みです。
小さく始めて柔軟に改修できる
小さく始めて柔軟に改修できるアプローチをとることで、現場のフィードバックを素早く反映できます。最初から全社規模で大規模な仕組みを構築しようとすると、要件定義に膨大な時間がかかり、実際に稼働するまでに数ヶ月から半年以上の期間を要することがあります。
自社で開発を進める場合、まずは特定の部署や簡単な申請業務だけでテスト運用を開始できます。実際に利用した従業員から意見を集め、入力項目の追加や承認ルートの変更といった改善を即座に行えます。環境の変化や組織改編に合わせて、システムを常に最適な状態へアップデートし続けられる点も魅力的です。
注意すべきワークフローシステム自作のデメリット
ワークフローシステム自作にはコストを抑えられる魅力がある一方で、事前に把握しておくべきデメリットが存在します。開発に着手してから後悔しないよう、代表的なリスクをあらかじめ理解しておくことが大切です。
開発・メンテナンスに専門知識が必要
システムを安定して稼働させるためには、開発・メンテナンスに関する専門知識が欠かせません。初期構築だけでなく、OSのアップデートや不具合対応なども自社で行う必要があるのが理由です。知識を持った人材が不足している場合、業務の遅延を招く恐れがあります。
担当者退職時の属人化リスク
特定の従業員のみがシステムの中身を把握している状態に陥りやすく、担当者退職時に属人化リスクが顕在化します。仕様書や設計図が残されていない場合、誰もシステムを改修できなくなるブラックボックス化の問題を抱えることになります。
セキュリティ対策を自社で行う必要がある
外部からのサイバー攻撃や内部からの情報漏えいを防ぐためのセキュリティ対策を、すべて自社で行う必要があります。IPA（独立行政法人情報処理推進機構）が公開している中小企業の情報セキュリティ対策ガイドラインなどでも指摘されている通り、脆弱性を突かれた場合の被害は甚大です。専門的な知見に基づいた強固な環境を維持するには、多大な労力とコストがかかります。
完成までに時間がかかる
要件定義から設計、開発、テストまでの一連の工程を自社で進めるため、完成までに時間がかかる傾向にあります。専用の市販システムを導入する場合と比較して、稼働開始までに長い期間を要します。本業と並行して開発を進める場合はさらに負担が大きくなり、急を要する業務改善には不向きなケースがあります。
| ワークフローシステム自作のデメリット | 具体的な影響 | 推奨される対策 |
|---|---|---|
| 開発・メンテナンスに専門知識が必要 | 不具合対応の遅延、運用停止 | ノーコードツールの活用、外部研修の受講 |
| 担当者退職時の属人化リスク | 担当者不在時の改修不能、ブラックボックス化 | 詳細な仕様書の作成、複数人での開発体制 |
| セキュリティ対策を自社で行う必要がある | 情報漏えい、サイバー攻撃による被害 | 定期的な脆弱性診断、最新のガイドライン参照 |
| 完成までに時間がかかる | 業務改善の遅れ、担当者の疲弊 | 小さく始めて段階的に拡張するアプローチ |
ワークフローシステムを自作する方法
企業の要件やリソースに合わせて、ワークフローシステムを自作する方法は多岐にわたります。それぞれの開発手法によって必要な技術レベルや構築にかかる期間が異なるため、自社の環境に最適な手段を選択できます。以下の表は、代表的な5つの手段を比較したものです。
| 自作方法 | 必要なスキルレベル | 初期コスト | 適した企業規模・環境 |
|---|---|---|---|
| ExcelとVBA | 中級（マクロ・VBAの知識） | 低（既存ソフトを利用） | 小規模・単純な承認フロー |
| Google Formsとスプレッドシート | 初級〜中級（GASの知識） | 低（既存アカウントを利用） | 小〜中規模・リモートワーク環境 |
| オープンソースソフトウェア | 上級（サーバー構築・プログラミング） | 中（インフラ維持費） | 中〜大規模・専任エンジニア在籍 |
| Microsoft 365 | 初級〜中級（ツールの基本操作） | 低（既存ライセンスを利用） | 中〜大規模・Microsoft製品導入済み |
| ノーコード・ローコードツール | 初級（業務フローの理解） | 中（ツール利用料） | 規模問わず・現場主導で開発したい組織 |
方法① Excelで申請書とフローチャートを作成する
Excelで申請書とフローチャートを作成する手法は、従業員にとって馴染みのあるインターフェースをそのまま利用できるのが大きな特徴です。VBA（Visual Basic for Applications）を組み合わせることで、承認ルートの自動判定やメール通知などの機能を実装できます。
既存の業務フォーマットを大きく変更せずに移行できるため、現場の混乱を最小限に抑えられます。ただし、ファイルが複数作成されることによるバージョン管理の煩雑さや、同時編集が難しいという課題も発生しやすい点に留意が必要です。小規模な部署での運用や、複雑な条件分岐がない単純な承認フローの電子化に最適な手法となっています。
方法② Google FormsとスプレッドシートでWeb申請を作る
Google FormsとスプレッドシートでWeb申請を作るアプローチは、インターネット環境さえあれば場所を問わずに申請や承認作業を完結できます。Google Workspaceを導入している企業であれば、追加費用なしですぐに開発に着手できます。
GAS（Google Apps Script）を活用することで、フォーム送信時に上長へ自動で承認依頼メールを送信したり、承認結果をスプレッドシートに記録したりする仕組みを構築できます。スマートフォンからでも手軽に申請内容を入力できるだけでなく、リアルタイムで進捗状況を共有できるのが強みです。
方法③ オープンソースのシステムを活用する
オープンソースのシステムを活用する手段は、ライセンス費用をかけずに本格的なワークフロー基盤を構築できます。無料で公開されているOSS（オープンソースソフトウェア）を自社のサーバーやクラウド環境にインストールして運用します。
ソースコードが公開されているため、自社の独自の業務要件に合わせて自由にカスタマイズできます。一方で、サーバーの構築やセキュリティパッチの適用など、インフラ周りの保守運用をすべて自社で担う必要があるため、高度なITスキルを持った人材が不可欠です。社内に専任のエンジニアが在籍しており、コストを抑えつつ大規模なシステムを構築したい企業に向いている選択肢となっています。
方法④ Microsoft 365（Power Apps・Power Automate）を使う
Microsoft 365（Power Apps・Power Automate）を使う方法は、すでに同サービスを導入している企業において非常に親和性の高いアプローチです。Power Appsで直感的に申請画面のユーザーインターフェースを作成し、Power Automateで承認ルートや条件分岐などのバックエンド処理を自動化できます。
TeamsやSharePointといった他のMicrosoft製品とシームレスに連携できるため、チャットツール上で直接承認ボタンを押すといったスムーズな業務体験を提供できます。高度なプログラミング知識がなくても、ドラッグ＆ドロップの操作で視覚的にシステムを組み立てられます。
方法⑤ ノーコード・ローコードツールで開発する
ノーコード・ローコードツールで開発する手法は、専門的なコーディングの知識がなくても短期間で業務アプリケーションを作成できます。kintoneに代表されるクラウド型のプラットフォームを利用することで、画面上の設定のみでデータベースの構築から承認フローの設定までを完結できます。
業務プロセスの変更が発生した場合でも、現場の担当者自身が素早くシステムの設定を変更して対応できます。また、各ベンダーが提供する強固なセキュリティ基盤を利用できるため、自社で脆弱性対策を行う負担を大幅に軽減できます。IT部門の負担を減らしつつ、現場主導で業務改善を継続的に進めたい組織に推奨される手法です。
失敗しないワークフローシステム自作の4ステップ
失敗しないワークフローシステム自作の4ステップを確実に踏むことで、自社の業務に適合した実用的な環境を構築できます。事前の準備を怠ると、完成後に現場で使われないといった事態を招く原因となるのが理由です。各段階で実施すべき具体的な作業内容を順に確認できます。
ステップ1 目的の明確化と要件定義
ステップ1の目的の明確化と要件定義を丁寧に行うことで、開発の手戻りを防ぎ、実用性の高いシステムを設計できます。現状の業務における課題を洗い出し、何を解決したいのかを具体的に設定できるのが理由です。
現状課題の洗い出しと対象業務の選定
現状課題の洗い出しと対象業務の選定を進めることで、システム化すべき範囲を正確に把握できます。紙の申請書による回覧の遅延や、承認経路の複雑さなど、現場が抱える具体的な問題点を担当者から直接ヒアリングできます。
対象とする業務を決定する際は、すべての申請業務を一度にシステム化するのではなく、優先順位をつけることが大切です。利用頻度が高く、かつフローが比較的単純な業務から着手することで、スムーズな導入を実現できます。
ステップ2 開発方法の選定
ステップ2の開発方法の選定では、自社の技術力や予算、将来的な拡張性を総合的に評価して適切な手段を決定できます。選択した手法によって、開発期間や運用後のメンテナンスにかかる負担が大きく変わるためです。
開発方法を比較検討する際は、以下の表のような基準を用いることで、客観的な判断を下すことができます。
| 比較項目 | 評価のポイント |
|---|---|
| 必要な技術力 | 社内にプログラミング知識を持つ人材がいるか、ノーコードツールが必要か |
| コスト | 初期費用だけでなく、ライセンス料や保守費用などのランニングコスト |
| 拡張性 | 将来的な組織変更や、他システムとの連携に対応できるか |
自社の現状のリソースと照らし合わせることで、無理なく運用を継続できる開発手法を選択できます。
ステップ3 システムの設計と構築
ステップ3のシステムの設計と構築では、要件定義で定めた内容を実際の画面や動作に落とし込む作業を実施できます。業務の流れを正確に反映させることが、使いやすいシステムを生み出す鍵となるのが理由です。
業務フローの可視化とデータ項目の定義
業務フローの可視化とデータ項目の定義を行うことで、申請から承認、決裁に至るまでの経路を迷いなく設定できます。誰がどのタイミングで確認し、どのような条件で次の担当者へ差し戻すのかといった分岐条件を詳細に整理できます。
また、申請フォームに必要な入力項目を過不足なく配置することで、入力者の負担を軽減できます。必須項目と任意項目を明確に分け、一意の識別子を付与してデータを管理することで、後から検索や集計を容易に行うことができます。
実際のシステム構築作業
実際のシステム構築作業では、選定したツールを用いて画面の作成や承認ルートの設定を進めることができます。複雑な機能をはじめから詰め込むのではなく、最小限の機能でプロトタイプを作成し、実際の動作を確認しながら調整を重ねる手法が効果的です。
ステップ4 テスト運用と社内展開
ステップ4のテスト運用と社内展開を通じて、構築したシステムが実際の業務で問題なく機能するかを検証し、組織全体へ定着させることができます。いきなり全社で導入するのではなく、段階的に利用範囲を広げることが推奨されるためです。
ユーザー参加型の動作確認
ユーザー参加型の動作確認を実施することで、開発者側では気づきにくい操作上の不具合や、業務実態とのズレを発見できます。対象業務を担う一部の部署や担当者に実際にシステムを操作してもらい、率直なフィードバックから改善点を抽出できます。
テスト運用で得られた要望を反映してシステムを修正することで、現場の満足度を高めることができます。
マニュアル作成と本格運用への移行
マニュアル作成と本格運用への移行を計画的に進めることで、新しいシステムに対する従業員の抵抗感を和らげることができます。画面のスクリーンショットを用いたわかりやすい操作手順書を用意し、必要に応じて説明会を開催できます。
本格的な運用が開始された後も、定期的に利用状況をモニタリングし、現場からの問い合わせに対応する体制を整えることで、継続的な業務改善を実現できます。
ワークフローシステムを自作する際の注意点
現状の業務フローを先に整理する
現状の業務フローを正確に把握し、可視化することが不可欠です。紙の書類やメールで行われているやり取りをそのままシステム化するだけでは、かえって業務効率を落としてしまう可能性があります。誰がどのタイミングで承認を行い、どのような条件で差し戻しが発生するのかを洗い出し、不要な工程を省いた上で新しいフローを設計できます。業務の棚卸しとプロセスの最適化を事前に行うことが、システム導入を成功させる鍵となるのが理由です。
拡張性・組織変更への対応を考慮する
拡張性・組織変更への対応を前提として、承認ルートや権限の設定を後から簡単に変更できるような構造で設計しておくことが重要です。企業の成長や人事異動に伴い、部署の統廃合や役職の変更は頻繁に発生します。特定の個人名に依存した承認ルートを作ってしまうと、担当者が変わるたびにプログラムや設定の修正が必要となり、運用負荷が増大してしまいます。役職や部門といった一意の識別子を基準にして権限を付与する仕組みを取り入れることで、組織変更時にも最小限のメンテナンスで柔軟に対応できます。
自作が向いているケースと向いていないケース
自作が向いているケースと向いていないケースは、自社の状況や目的によって明確に分かれます。開発リソースや求める機能要件を客観的に評価し、最適な選択を行うことができます。以下の表に、それぞれの状況における特徴を整理しています。
| 判断基準 | 自作が向いているケース | 自作が向いていないケース |
|---|---|---|
| 組織規模 | 少人数のチームや小規模な企業 | 承認ルートが複雑な中規模から大規模な企業 |
| 業務の複雑さ | 直線的でシンプルな承認プロセス | 条件分岐や代理承認が頻繁に発生するプロセス |
| 社内リソース | ITスキルの高い人材が継続的に在籍している | 専任の担当者を配置できず、退職時の引き継ぎに不安がある |
| セキュリティ要件 | 社内ネットワーク内で完結し、機密情報が少ない | 高度なアクセス制御や監査ログの長期保存が求められる |
自作のワークフローシステムは、コストを抑えつつ自社の業務に合わせた細かな調整を行えるのが魅力です。しかし、規模が大きくなるにつれて維持管理の手間が増加するため、長期的な運用を見据えた慎重な判断が求められます。
自作が難しいと判断した場合は、既存のExcel申請書をそのまま活用できる専用のワークフローシステムを検討するのも有効な選択肢です。
よくある質問（FAQ）
ワークフローシステムはExcelだけでも自作できますか？
マクロやVBA（Visual Basic for Applications）の機能を活用することで、高度な承認ルートの自動化を実現できます。社内で日常的に使用している表計算ソフトをそのまま活かせるため、新たな学習コストをかけずに申請業務を電子化できるのが大きな利点となっています。
一方で、複数人での同時編集が難しく、データ量が増加するとファイルの動作が重くなったり破損したりするリスクが高まります。データの一元管理や複雑な条件分岐が必要な場合は専用のデータベースと連携させるなどの工夫が必要となるため、小規模な部署内での運用にとどめるのが無難な選択肢となっています。
プログラミング知識がなくても自作は可能ですか？
ノーコード開発プラットフォームやクラウド型のフォーム作成サービスを利用することで、直感的な操作のみで構築できます。画面上の部品をドラッグアンドドロップで配置するだけで申請画面や承認フローを作成できるため、IT部門以外の現場担当者でも業務に合わせたシステムを迅速に立ち上げられます。
ただし、自社の複雑な業務ルールを完全に再現しようとすると、標準機能だけでは対応しきれない場面も出てきます。そのような場合は、連携用のAPI（Application Programming Interface）を利用して他のシステムからデータを取得するなどの拡張機能を追加できます。
自作と専用システム導入はどちらがコスト効率が高いですか？
企業の規模や運用期間、求める機能の複雑さによってコスト効率の良さは変動するため、一概には言えません。利用人数が少なくシンプルな承認フローであれば、既存のライセンスを活用して自作したほうが圧倒的に安価に運用できます。
以下の表は、自作と専用システム導入におけるコスト効率の違いを整理したものです。
| 比較項目 | 自作 | 専用システム導入 |
|---|---|---|
| 初期費用 | 既存のオフィスソフトなどを活用すれば無料から低コストで開始できます | 初期設定費用やソフトウェアの購入費用が発生します |
| ランニングコスト | 追加のライセンス費用はかかりませんが保守運用の人件費が必要です | 月額利用料や年間保守費用が継続的に発生します |
| 運用保守の負担 | トラブル対応や機能改修をすべて自社で行うため担当者の負担が増加します | ベンダーのサポートを受けられるため社内リソースを節約できます |
長期的な視点で見ると保守運用にかかる隠れた人件費が膨らむ可能性があるため、社内のリソース状況を慎重に評価したうえで判断することが重要となっています。
自作した場合のセキュリティ対策はどうすればよいですか？
クラウドサービスが提供する標準のアクセス権限設定や、多要素認証などの機能を活用して安全性を高めることができます。誰がどのデータにアクセスできるかを厳密に制御し、退職者のアカウントは速やかに無効化する運用ルールを徹底することで、情報漏えいのリスクを最小限に抑えられます。
また、システムの脆弱性を突いたサイバー攻撃を防ぐため、利用しているソフトウェアやサーバーのOS（オペレーティングシステム）を常に最新の状態に保つアップデート作業を実施できます。具体的な対策手法については、総務省の国民のための情報セキュリティサイトから最新のガイドラインや推奨される設定方法を確認できます。
自作から専用システムへ移行するタイミングの目安は？
組織規模の拡大に伴い、承認ルートが複雑化した段階が一つの基準となっています。従業員数が増加し、部署をまたぐ決裁や条件分岐が多発するようになると、自作のシステムではメンテナンスの限界を迎えるためです。
さらに、システムの保守を担当していた社員の異動や退職によって、ブラックボックス化のリスクが顕在化し始めた時期も移行のサインとして捉えることができます。内部統制の強化や監査対応が求められるようになったタイミングで専用システムへ切り替えることで、企業の成長に合わせた適切な業務基盤を整備できます。
まとめ
ワークフローシステムの自作は、コストを抑えつつ自社の業務に合わせた柔軟な構築ができるメリットがある一方で、専門知識の必要性や担当者退職時の属人化リスク、セキュリティ対策といった課題も伴います。現状の業務フローを整理し、自作が適しているか慎重に見極めることが大切です。
もし、自作に伴う開発・保守の負担や属人化に不安を感じる場合は、専用システムの導入を検討するのも一つの解決策です。使い慣れたExcelの申請書をそのまま活用できるワークフローシステム「AppRemo」なら、スムーズな導入と運用が可能です。詳しくは、AppRemo製品ガイドをご覧ください。
