総務システム開発の開発期間・スケジュール・納期について

総務システム開発は、業務を棚卸しして形態と対象を決め、段階的に進めると、現実的な納期で運用を始められます。

対象範囲、導入形態別の期間、工程ごとの進め方、遅延への備えを順に説明します。全体像は、次に紹介する完全ガイドにまとめています。

▼全体ガイドの記事
・総務システム開発の完全ガイド

総務システムとは何か——”何でも屋”ゆえの開発の難しさ

総務システムを中心に、備品発注、会議室予約、押印申請、社内問い合わせの4領域を示す図。
扱う業務を選ぶことが、開発範囲の出発点になります。

総務システムは、一つの明確な業務だけを扱うシステムとは性質が異なり、複数の業務を扱います。一方で、会計システムは仕訳と決算を、勤怠システムは出退勤の打刻と集計を扱うように、それぞれ一つの業務を中心に扱います。

総務システムが扱うのは、備品発注、会議室予約、押印申請、社内問い合わせです。

防災備蓄、株主総会・取締役会、賃貸やリース契約の期日管理も対象になります。

業務の性質が異なり、中核となる単一のマスタもありません。この構造が、開発期間を読みにくくする根本的な理由です。また、対象範囲によって、期間は数週間から1年以上まで変わります。

総務システムがカバーする業務領域の広さ

総務システムに含めうる業務は幅広く、下の具体例からもそれが分かります。どこまでを作るかによって、開発規模が決まります。

  • 備品管理:什器や消耗品の在庫・発注
  • 場所の予約:会議室やフリーアドレス席
  • 申請・問い合わせ:押印ワークフローや総務窓口
  • その他の運営:防災備蓄、会議運営、契約期日

コピー用紙、文具、トナー、清掃用品の在庫を把握します。発注点を下回ると申請と承認を経て発注し、これにより在庫切れや保管場所の属人化を防げます。

会議室や座席の予約では、ダブルブッキングを防ぐとともに、使われない空予約を見える形にして稼働率を分析します。

社印や契約書の押印申請では、書類と印の種類を指定し、上長や法務の承認を回付します。

押印台帳と監査証跡を残し、電子契約や電子印との連携も検討します。

総務ヘルプデスク(社内問い合わせ)は、チケットで問い合わせを管理します。

「経費精算のやり方」や「入館証の再発行」などを受け付けて分類し、回答したうえで、FAQにまとめます。

名刺発注、郵便物、防災BCP、株主総会、取締役会も対象になり得ます。また、オフィス賃貸やリース契約の更新期日も管理対象です。これらのなかから対象業務を線引きすることが、期間の見積もりの出発点になります。

資産管理・人事管理・情報共有・社内ポータルとの違い

開発範囲を決めるには、隣接するシステムとの違いを押さえておく必要があります。

  • 資産管理:固定資産の取得価額、減価償却、除却を台帳で管理
  • 人事管理:氏名、所属、雇用条件、異動履歴など人のマスタを扱い、給与や勤怠のハブになる
  • 情報共有:ファイルやナレッジを蓄積・検索する基盤
  • 社内ポータル:社内報やお知らせを発信し、交流やエンゲージメントを促す
  • 総務システム:場所・モノ・手続き・人の困りごとが対象。承認・在庫・期日など固有のロジックを扱う

「総務のシステムを作りたい」と曖昧に要件を出すと、資産・人事管理まで含むことになり、範囲が膨らんで期間が読めなくなります。そのため、対象の庶務・ファシリティ業務を絞ることが、納期を守る第一歩です。

ポイント

期間は対象範囲で大きく変わるため、対象業務を線引きし、隣接システムとの境界を決めてから期間を見積もることが判断の目安です。

開発期間を左右する3つの変数

総務システムの開発期間に影響する業務モジュールの数、承認の複雑さ、既存ツールとの連携数を3つのパネルで示す図。
どの要素も、要件の段階で規模を見比べられます。

開発期間は、業務モジュールの数、承認の複雑さ、既存ツールとの連携数の3つで決まります。3つの変数はそれぞれ期間に影響するため、どれか一つが大きくなるだけでも期間は延びます。そのため、これらの変数を意識してスコープを調整できれば、総務システムの納期を十分に見通せます。

変数1:対象業務モジュールの数

対象業務モジュールの数は、開発期間を最も直接的に左右します。

  • 会議室予約だけ:表示・予約・キャンセル・重複確認で、数週間が目安
  • 複数業務:備品発注、押印、ヘルプデスク、防災備蓄には個別のデータモデル・画面・ロジックが必要で、合算すると数ヶ月規模
  • 要望の膨張:何でも屋の性質から要件定義で現場担当者の「これも入れられる?」が相次ぎ、当初の2倍、3倍になる例も珍しくない
  • 初期リリース:効果が大きく困りごとが明確な業務に絞り、残りはフェーズ2以降に回す

変数2:承認ワークフローの複雑さ

承認フローの複雑さは、開発期間を左右する二つ目の変数です。備品発注、押印、慶弔金、会議室の特別利用には、いずれも申請と承認が伴います。

  • 一直線の承認:申請者から上長、総務へ進むルートは実装しやすい
  • 条件分岐:一定額を超えると部門長に加えて役員承認が必要な場合がある
  • 回付先:押印の種類により法務・経理・代表へ分岐し、拠点ごとに異なる場合もある
  • 開発とテスト:複雑なルートに柔軟対応するエンジンほど設計・開発の工数が増え、全分岐の検証でテスト期間も延びる
  • 既存機能の活用:グループウェアやワークフロー製品の承認機能で開発を大幅に短縮できる

変数3:既存ツール・システムとの連携数

総務システムは周辺ツールと連携することで価値を発揮しますが、連携先は業務の領域ごとに分かれ、どこまで連携するかで、必要な作業と判断の中身が変わります。

  • 予約:入退室管理、スマートロック、Google Workspace、Microsoft 365
  • 押印・備品:電子契約、購買サイト、会計システム
  • 問い合わせ:SlackやTeamsなどのチャットツール
  • 連携作業:API調査、認証、データ変換、エラー処理に加え、連携先の仕様変更への追随とテストが必要
  • 導入判断:連携先と連携の深さを早期に洗い出す

全社員が日常使うカレンダーやチャットは効果が大きい一方で、工数もかかります。そのため、初期導入にするか、手動運用後のフェーズ2で連携するかを、期間と合わせて判断します。

ポイント

期間を読むには、業務モジュールの数、承認の複雑さ、連携数の3つを要件の段階で見比べることが判断の目安になります。どれか一つでも大きくなると、期間は延びます。

導入形態別の開発期間の目安

SaaS・ローコード型は数週間〜2ヶ月、パッケージ型は2〜5ヶ月、フルスクラッチ型は6ヶ月〜1年以上という期間目安を並べた図。
独自要件や統合の範囲が広い形態ほど、期間も長くなります。

開発期間は導入形態によって大きく変わります。

標準的な庶務業務で足りるか、独自要件や統合が必要かを見極めたうえで、SaaS・ローコード型、パッケージ型、フルスクラッチ型の期間と向き不向きを比べます。

期間の目安は、SaaS・ローコード型が数週間〜2ヶ月、パッケージ型が2〜5ヶ月です。一方、フルスクラッチ型は6ヶ月〜1年以上を見込みます。

クラウドSaaS・ローコード活用型:数週間〜2ヶ月

標準機能で業務を回せるかどうかが、この形態の期間を左右します。

  • 形態:総務向けSaaSを組み合わせるか、kintoneなどで業務アプリを構築
  • 標準機能で足りる場合:会議室一覧、備品カタログ、承認ルートを設定し、数週間〜2ヶ月で運用開始
  • 導入負担:開発より設定・カスタマイズに近く、初期投資も抑えられる
  • 向いている要件:独自ワークフローや複数ツール統合を避け、標準的な総務業務を素早くデジタル化する場合

独自ワークフローや複数ツールの統合が必要なら、追加開発で期間が延びます。

パッケージ(グループウェア)カスタマイズ型:2〜5ヶ月

グループウェアやワークフロー製品を土台にして、総務業務に合わせた追加開発を行います。

  • 既存機能:承認、設備予約、掲示板を使い、ゼロから作るより開発量を抑える
  • 追加開発:備品の在庫ロジック、問い合わせ分類、押印台帳、周辺連携を新たに作る
  • 期間の目安:必要な追加開発を含め、おおむね2〜5ヶ月
  • 選定の観点:標準機能と追加開発のバランスが期間を左右する。業務を製品標準に寄せるほど日程を抑えやすく、自社らしさを盛り込みたい中堅・中規模企業向け

フルスクラッチ型:6ヶ月〜1年以上

独自要件を広く実現したい場合は、次のような条件に当てはまるかを見て選びます。

  • 適する要件:複数拠点のファシリティ・サプライヤ管理や、複雑な押印・回付の再現
  • システム連携:基幹システム、入退室、IoT機器との密な連携
  • 期間:要件定義から設計・開発・テスト・全社展開まで、対象モジュール数に応じて6ヶ月〜1年以上
  • 大規模統合:複数のSaaSやExcelをまとめる大企業向けでは、さらに期間が長くなる
  • 選定時の確認:自由度は高いが期間・費用の負担もあるため、不可欠な要件かを見極める

ポイント

標準機能で業務を回せるか、独自要件や統合が必要かを見極めてから形態を選ぶことが、期間の見込みを立てる際の判断の目安です。

工程別のスケジュールと各フェーズのポイント

パッケージ型やフルスクラッチ型の工程を、要件定義から本番稼働まで順に説明します。

全社員が使い、業務も見えにくいため、一般的な業務システムに比べて要件定義と全社展開に手間がかかります。

各フェーズで押さえるポイントを知っておくと、納期を守るうえで役立ちます。

要件定義フェーズ(1.5〜2ヶ月):業務の棚卸しが最大の山場

総務システム開発では、要件定義が最も重要で、難所となるフェーズです。

  • 業務の実態:記憶や慣習で運用される業務を、現場担当者へのヒアリングで棚卸し
  • 確認する内容:発注の判断者・時期、押印書類ごとの承認者、問い合わせの種類・頻度
  • 期間と決定事項:1.5〜2ヶ月かけ、対象モジュールと承認フローを確定
  • 進め方:現場ヒアリング、業務フロー図の作成、対象範囲への合意を順に行う
  • 不足時の影響:後工程で「そういえばこういうケースもあった」と要件が次々出て、手戻りで予定が崩れる

設計・開発フェーズ(3〜5ヶ月):予約・在庫・ワークフローの実装

要件が確定したら、設計・開発へ進みます。決まった対象と承認フローを、機能として作り込む段階です。

  • 中核機能:予約カレンダー、在庫と発注点の管理ロジック、申請・承認のワークフローエンジン
  • 機能の要件:予約の排他制御、発注点アラートと棚卸照合、条件分岐に対応する柔軟なルート
  • 利用環境:直感的なUI、部署・役職ごとの権限管理。周辺連携があれば並行開発
  • 期間と進め方:対象数によるが標準3〜5ヶ月。モジュール単位で開発・レビューでき、アジャイル型とも相性がよい

テスト・移行・全社展開フェーズ(1.5〜3ヶ月):定着までを見据えた進め方

開発後は、テスト、データ移行、全社展開を進めます。

  • テスト:承認分岐、予約の同時アクセス、在庫数の整合性を重点確認
  • データ移行:備品カタログ、会議室一覧、契約期日などをExcelや紙から移す
  • 全社展開:一部担当だけのシステムと異なり、会議室予約や備品申請を全従業員が日常利用する。マニュアル、説明会、窓口を用意し、期間は1.5〜3ヶ月
  • 定着の進め方:部署や拠点ごとに始め、現場の反応を受けて段階的に広げると混乱を抑えられる
  • 完了の状態:展開を終えて、システムが「作った」状態から「使われている」状態になる

ポイント

要件定義で業務の実態と承認フローを確定させることが、設計・開発、テスト・移行、全社展開の期間を読む判断の目安になります。

総務システム特有の遅延要因と納期を守る工夫

納期が遅れる要因と対策を取り上げます。総務特有の落とし穴を知っておくと、スケジュールの崩れを未然に防げます。

遅延要因:業務の見えにくさと、後から出る要件

最大の遅延要因は、業務の実態が見えないまま、要件が後から出てくることです。

  • 発生の背景:例外が多く、文書化されず担当者の経験で処理される業務がある
  • 後から出る要件:開発中に発覚する例には、役員用会議室の別ルールや特定書類の代表印がある
  • 事前確認:通常フローに加えて例外も洗い出し、繁忙期を含む実業務を一定期間観察
  • 記録の活用:問い合わせ履歴や申請記録を分析し、業務のばらつきを把握

納期を守る工夫:スモールスタートと繁忙期回避

納期を守るには、スモールスタートが効果的です。

  • 先行リリース:会議室予約や備品発注など、効果が大きく困りごとが明確な業務から始める
  • 段階的な拡張:一つか二つの独立したモジュールで成功し、現場の信頼を得てフェーズ2、3へ広げると、リスクを抑えて総務DXを進められる
  • 一括導入のリスク:全業務を対象にすると範囲が膨らみ、要件が固まらずテストも増えて、納期を守れなくなる
  • 繁忙期の回避:年度替わり、株主総会、年末調整は業務が集中し、全社展開時に定着しにくい場合がある
  • 展開時期:閑散期に合わせると、実際に使われ始めるまでの期間を短縮できる

ポイント

業務の例外を事前に洗い出し、効果が大きく困りごとが明確な業務から段階的に広げることが、納期を守る判断の目安です。繁忙期を避けた展開時期も、定着を左右する要素になります。

まとめ

総務システムは、備品発注、会議室予約、押印申請、社内問い合わせなどを効率化します。一方で、人事管理、資産管理、情報共有、社内ポータルとは、目的や対象が異なります。

開発期間は、モジュール数、承認フロー、既存ツールとの連携数に左右されます。

導入形態別では、SaaS・ローコード型が数週間〜2ヶ月、パッケージ型が2〜5ヶ月です。また、フルスクラッチ型は6ヶ月〜1年以上が目安です。

要件定義で業務と例外を棚卸しし、効果の高い機能から段階的に展開します。さらに、繁忙期を避ける計画も、納期と定着を守るうえで大切です。

構築を検討する際は、対象業務を絞り、複数の開発会社に相談して現実的な予定を描きます。

▼全体ガイドの記事
・総務システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。