1on1ツール開発の開発期間・スケジュール・納期について

1on1ツール開発の期間は、機能の範囲、権限設計、外部連携によって変わります。機能を絞ったMVPの3〜4ヶ月から、AI分析や高度な外部連携を含む大規模案件の8〜12ヶ月以上まで幅があります。さらに、期間は工程ごとの配分や進め方、遅れを招く要因によっても左右されます。

▼全体ガイドの記事
・1on1ツール開発の完全ガイド

1on1ツール開発の全体像とプロジェクトの特徴

1on1ツールを中心に、日程調整、アジェンダ共有、面談記録、次回への引き継ぎを結んだ図。
準備から次回への引き継ぎまでをひと続きで捉えられます。

1on1ツールは、面談の準備から記録、振り返り、次回への引き継ぎまでを支えるシステムです。主な機能は、日程調整、アジェンダ共有、面談記録などで、フィードバック履歴や目標管理(OKR/MBO)との連携も含まれます。

開発では、面談の内容を記録するだけでなく、記録を次の面談や評価、エンゲージメント把握へどうつなぐかまで設計します。面談メモを保存するだけのデータベースに留まる場合は、開発は完結しません。エンゲージメントの状態が分かるダッシュボードも、上司・部下・人事の権限に応じて作り分けます。特に、要件定義や権限設計の判断が、開発期間と使い勝手を左右します。

勤怠管理・タレントマネジメントとの違い

計画の前に、1on1ツールと既存の人事系システムとの違いを整理しておきます。勤怠管理は、出退勤や労働時間といった事実のデータを正確に記録します。一方で、タレントマネジメントは、スキル・評価・配置などの人材データを蓄積して活用します。

どちらも確定した情報を管理する性格が強く、1on1ツールとは目的が異なります。これに対して、1on1ツールは、上司と部下が毎週・隔週で繰り返す対話に寄り添い、その質を高めるシステムです。

たとえば、面談の準備を促し、テーマや約束事を記録します。さらに、前回の振り返りを次回に引き継ぎ、対話からモチベーションの変化を捉えます。

  • 傾聴を助けるUI:上司が対話を進めやすい画面。
  • リマインド:面談が空いてしまう期間を防ぐ通知。
  • 履歴表示:過去のやり取りを時系列で確認できる表示。

対話の質やエンゲージメントの状態を見える形にするには、単なる入力フォーム以上の作り込みが必要です。

期間見積もりを難しくする固有の論点

期間は、画面の数より、権限設計とシステム連携の複雑さに左右されます。

  • 権限の粒度:部下は自分の記録、上司は配下、人事は全体のエンゲージメント傾向を見るため、閲覧と編集の権限を分けます。
  • 面談データ:機密性が高く、権限設計が不十分だと手戻りが起きます。
  • システム連携:人事基幹、目標管理、カレンダーとの連携範囲。

要件定義では、連携先、権限の粒度、扱う面談データの範囲を洗い出します。単独で完結するか、複数のシステムと双方向に連携するかで、設計・実装・テストの負荷が異なります。

ポイント

判断の目安は、面談の記録や目標連携まで含めるかどうかと、権限を役割ごとにどこまで分けるかです。ここが決まると、期間の見積もりを立てやすくなります。

規模別の開発期間の目安

小規模・中規模・大規模の1on1ツール開発期間を3枚のカードで示す図。
規模の段階に沿って、開発期間の目安も広がります。

開発期間は、機能の範囲、権限設計、外部連携の有無で変わります。スモールスタート(MVP)は、記録、基本的なユーザー・部署管理、簡易検索やダッシュボードに機能を絞る規模です。この規模の目安は3〜4ヶ月(約12〜16週)です。

複雑な権限、外部連携、詳細な分析を含む中規模は、5〜8ヶ月です。また、本格的な業務利用を想定すると、期間は約20〜32週が現実的な範囲です。

AI分析や次のアクション提案、人事基幹システム(ERP)との高度なAPI連携を含む大規模案件は、8〜12ヶ月以上です。数万人規模の複数拠点・全社データ統合まで行う場合は、要件次第で1年を超えることがあります。なお、全機能と全社展開を最初から同時に狙うと、長期化やプロジェクトの頓挫につながります。

小規模・中規模・大規模それぞれの中身

期間の違いは、各規模で作る機能や連携、運用の範囲に表れます。

  • 小規模:予定登録や記録、フィードバック蓄積、部署・ユーザー管理などに絞った構成。
  • 小規模の進め方:3〜4ヶ月を目安に一部部署で試し、現場の反応を見ながら育てます。
  • 中規模:三者の権限、OKR/MBO・Google/Outlook連携、分析レポートの運用基盤を5〜8ヶ月で構築。
  • 大規模:AI分析や双方向連携、全社統合を含み、8〜12ヶ月以上かかります。

中規模では、要件定義や権限・データ設計、機能開発に加えて、外部連携も中心になります。チームは、PM、フロントエンド、バックエンドのエンジニアで編成するのが標準です。

一方で、大規模では大量データの性能設計、厳格なデータガバナンス、段階的な全社展開が必要です。ただし、期間は目安であり、選ぶ技術や自社の体制によって変わります。

開発期間を左右する変数

同じ中規模でも、5ヶ月で済む場合と8ヶ月かかる場合があります。

  • 権限とデータモデル:深い階層や兼務・マトリクス組織で、役員まで閲覧範囲を分けると設計・テストが増えます。
  • 外部連携:カレンダーのみか、目標・人事評価・チャットまで双方向連携するかで工数が変わります。
  • 分析機能:入力集計か、面談テキスト分析・AI要約・感情分析かで作り込みが異なります。
  • セキュリティ:機密情報を扱うため、要件が厳しいほど設計と検証に時間がかかります。

これらを要件定義の段階で明らかにしておくことが、納期見積もりの精度につながります。

ポイント

判断の目安は、機能と連携の範囲がどの規模に当たるかです。全機能と全社展開を同時に狙うと長期化しやすいため、初回は範囲を絞るのが現実的です。

工程別のスケジュールと期間配分

要件定義・設計、開発・実装、テスト・リリース・定着の各工程と全体に対する期間比率を示す図。
開発・実装の期間枠が3工程の中で最も大きくなっています。

全体を工程に分け、各工程にどれくらいの割合を充てるかを把握しておくと、計画を立てやすくなります。

IPA(独立行政法人情報処理推進機構)のソフトウェア開発データ白書では、一般的な工期の比率が示されています。目安は、要件定義が約25%、設計からテストまでが約75%です。

全体6ヶ月(約24週)の中規模案件なら、要件定義に約1.5ヶ月(約6週)を充てます。残りの約4.5ヶ月(約18週)は、設計・開発・テスト・リリースに割り当てる計算です。

費用内訳の割合を期間に換算すると、設計が約22〜24%、開発が約48〜50%、テストが約15〜17%です。したがって、期間は開発、設計、テストの順に多く配分するのが標準的です。

権限や面談データの設計は、要件定義・設計の重要な論点です。上流の判断は開発工数と使い勝手を左右するため、そこに十分な時間を取ることが、納期遵守につながります。

要件定義・設計フェーズ(全体の約25〜35%)

要件定義・設計は、1on1ツール開発の成否を左右する重要工程です。まず、発注側と開発会社で、実現したい目的を明確にします。目的には、面談記録や対話の質、エンゲージメント変化の把握などがあります。

目的によって必要な機能の優先順位が変わるため、想定する面談の運用フローも整理します。

  • 機能要件:日程調整、記録、履歴、目標連携、サーベイなどの範囲。
  • 非機能要件:レスポンス速度、セキュリティ、可用性の水準。
  • 権限とデータ:閲覧・編集の範囲、評価との連動、退職・異動時の扱い。

権限モデルとデータの扱いを先に固めておくことが、後工程の手戻りを防ぎます。

要件定義は2週間〜1ヶ月が目安です。ただし、権限・データ設計まで含めると、上流に全体の3割近くを充てる場合もあります。その分、後工程の効率を高められます。

開発・実装フェーズ(全体の約45〜50%)

開発・実装は、プロジェクト全体の半分近くを占める最も工数の大きい工程です。まず認証・権限管理を作り、その後に面談関連の機能を実装します。

  • 面談機能:スケジュール、アジェンダ共有、記録、フィードバック履歴の扱い。
  • 連携と表示:目標管理連携と、エンゲージメントを示すダッシュボード。
  • 運用を支える機能:時系列表示と、面談漏れを防ぐ通知。

品質を左右するのは、部下のプライバシーに配慮した閲覧範囲です。

開発では、実装を2週間〜1ヶ月単位のスプリントに分け、利用者に近い人の反応を受けて改善する方法が適しています。また、中規模では、このフェーズに13〜16週程度を見込みます。

権限の実装は、結合時に調整が起きやすいため、検証の時間を多めに取ります。

テスト・リリース・定着フェーズ(全体の約15〜20%)

テストでは、要件と権限が意図どおりに実現されているかを確かめたうえで、本番運用へ移ります。特に、部下が他人の記録を見たり、上司が権限外の情報へアクセスしたりする不具合は重大です。機密性の高い面談情報を守るため、この確認は省けません。

  • 権限:役割ごとの操作で、閲覧と編集の境界を確かめます。
  • 性能:想定ユーザー数でのレスポンスの確認。
  • 通知:リマインドを含め、必要な相手に正しく届くこと。

権限の検証は、見た目の実装以上に工数がかかる点に注意が必要です。

定着の準備も、1on1ツール固有の重要な工程です。リリース後に利用方法や意義が伝わらないと、面談記録が形だけのものになるおそれがあります。

操作マニュアルや進め方ガイドを用意し、パイロット部門での先行運用と意見の収集を計画に含めます。そのうえで、一部の部門から段階的に始め、現場の声を受けて改善していくのが有効です。

ポイント

判断の目安は、権限と面談データに関する要件を上流で固められるかです。曖昧なまま開発に入ると、実装とテストの両方で手戻りが増えます。

開発期間を短縮する進め方

進め方を工夫すると、開発期間を現実的に短縮できます。工程をすべて直列に進めず、開発とテスト、システム開発と定着準備を並行させます。さらに、機能を絞るMVPも、開発期間を縮める方法の一つです。

CI/CDによる開発とテストの並行、変革推進タスクの同時進行

開発とテスト・デプロイを並行できる仕組みが、期間の短縮につながります。たとえば、DevOpsやCI/CD(継続的インテグレーション/継続的デリバリー)の環境を用意します。

  • 自動化:静的解析やユニット・結合テスト、デプロイ承認を、手作業に頼らず進める。
  • 定着準備:運用ルール、面談ガイド、マニュアルを、開発と並行して作る。
  • 教育:管理職への操作教育とコーチング研修。

手動テストを減らすことで、不具合を早く見つけられます。テストからリリースまでを連続して進めると、週次や隔週のリリースも実現しやすくなります。さらに、定着の準備を前もって進めておけば、完成後すぐに利用を始められ、プロジェクト全体の期間も縮められます。

機能を絞ったMVPアプローチと段階的検証

MVP(最小限の機能を備えた製品)は、初回リリースの範囲を絞る方法です。

  • 機能の詰め込み:日程調整や記録、AI要約などを一度に揃えると複雑になり、合意にも時間がかかります。
  • Phase 1:面談記録やフィードバック履歴など、運用に不可欠な機能に絞ります。
  • 試験導入:権限モデルを簡素にし、3〜4ヶ月で一部部署に導入して、利用者の反応を次の開発に生かします。
  • 段階的に拡張:Phase 2以降に目標管理連携や分析を加え、初期の成果を社内理解や予算につなげます。
  • スプリント:動く画面を関係者に見せ、認識のずれを直して大きな作り直しを防ぎます。

ポイント

短縮を検討するときは、開発とテスト、定着準備を並行できるか、初回に絞る機能を決められるかが判断の目安です。

納期を膨張させる要因と対策

遅延の要因を把握して、あらかじめ対策を講じておくと、スケジュールの破綻を防げます。

要件定義の曖昧さとスコープクリープ

1on1ツールでは、運用を起点にした要望が出やすいため、スコープ管理が重要です。

  • 要件の曖昧さ:権限や運用フローが未確定だと仕様変更が続きます。
  • 工数の膨張:要件定義を軽視すると工数が1.3〜1.5倍、場合によっては1.8倍になります。
  • 機能の追加:優先順位や変更管理がないと、機能が増え続けるスコープクリープが起きます。
  • 変更の管理:Phase 1の範囲を決め、追加要望は影響と工数を見積もってから合意します。
  • 初回範囲の維持:要望はPhase 2以降のバックログに記録します。

利用が始まったあとも、記録の閲覧範囲やテーマ分類の変更要望が出やすいため、注意が必要です。

非機能要件の後回し・意思決定の遅延・無理な短納期

遅延を避けるには、設計、意思決定、体制の各面で対策が必要です。

  • 非機能要件:速度、セキュリティ、既存連携を後回しにすると、工数が膨らみます。
  • 意思決定:権限や評価連動を決められる経営・人事の担当者の参加。
  • 人員追加:遅れている案件へ増員するかどうかの判断。
  • 調整方法:安易な増員より、スコープと優先順位の見直し。

面談情報は機密性が高く、暗号化やアクセスログを後回しにすると、直前に作り直しが起こりえます。

決裁者の判断が遅れると、現場だけでは決められず、開発やテストが止まります。また、遅れた案件に人を急に足すと、さらに遅れてしまう経験則は、ソフトウェア工学で「ブルックスの法則」と呼ばれます。

ポイント

要件の追加を範囲の中で扱えるか、決裁者が定例会議に加わっているかが判断の目安です。遅れが出たときは、増員より先に範囲と優先順位を見直せるかが問われます。

まとめ

1on1ツール開発では、権限とデータ設計、面談運用との適合、機能の範囲が、期間と品質を左右します。1on1ツールは、勤怠や人材属性の管理とは異なり、対話を支えて、エンゲージメントの変化を見えるようにするシステムです。

IPAのデータ白書に基づくと、要件定義に約25%、設計からテストに約75%を配分するのが目安です。開発とテストの並行、定着準備の同時進行、MVPによる段階的な拡張を組み合わせると、早期の稼働を目指せます。

要件の曖昧さや機能追加、非機能要件の後回し、判断の遅れを防ぐ準備も欠かせません。特に、範囲と変更管理を明確にし、意思決定者がプロジェクトに参加することが納期遵守の鍵です。

▼全体ガイドの記事
・1on1ツール開発の完全ガイド

会社紹介

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

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

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

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

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

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