工務店・ハウスメーカーの業務システム選定 同じ仕事を試して比較表を作る

業務システムの機能表に同じ丸が付いていても、自社で同じ仕事を完了できるとは限りません。見積を作れても承認済みの版を識別できない、工程を共有できても協力会社への公開範囲を分けられない、といった条件で採用の判断は変わります。

比較では、自社の代表的な一案件を全候補で同じ条件で試し、操作結果、必要だった支援、費用、残る未確認事項を並べます。その前に、満たせなければ採用できない必須条件を決めておくと、画面の印象だけで選ばずに済みます。

この記事では、契約前の業務試験を選定表へまとめる方法を説明します。ここでの試験は候補を比較するためのもので、契約上の検収・受入れの条件や手続は別途定める必要があります。案件、人数、時間などの例は架空で、実在製品の評価や標準値ではありません。

01.最初に、変えたい受け渡しを一つ決める

「情報を一元化したい」を、実際に起きている場面へ置き換えます。例えば「顧客と合意した見積変更が工程担当へ届かず、古い内容で発注準備を進める」という問題なら、変更後に必要なのは、承認済みの内容と影響先を同じ案件で追える状態です。

この架空例では、見積変更から工程担当への引継ぎまでを対象とし、会計処理の入れ替えは対象外にできます。ただし、金額を既存会計へ渡すなら、その接点は試す範囲に残します。

最近の案件をたどり、入力、成果物、次の担当、使う資料の版、待ちが起きる場所を書きます。重複入力、保存先の属人化、承認待ちは分けます。自動転記で入力が減っても、承認者が決まっていない問題は残るためです。命名や担当の整理で直せる課題は、運用変更として計画に含めます。

「探しやすい」という希望も、「案件番号を知らない担当者が、顧客名と工事場所から承認済み見積を開ける」と書けば試せます。時間を測るなら、課題を提示してから目的の版を開くまでなど、開始と終了をそろえます。現状値がなければ、既存の方法で同じ課題を試すところから始めます。

02.必要性と確認状態を別々の欄にする

要件の必要性は「必須・希望・対象外」、確認状態は「未確認・試験待ち・充足・未充足」などに分けます。「未確認」は必要性の種類ではありません。必須の未確認が一つ残ることと、希望機能が一つ未確認であることでは、決裁への影響が違います。

要件表の架空記入例

各行には社内担当、確認期限、資料や試験結果の保存先も付けます。提供元から「可能」と回答を得ても、自社の操作が必要な項目は試験待ちです。反対に、まだ試していないことを機能なしとも扱いません。

必須要件は、欠けるとどの仕事が止まるかを説明できるものにします。希望要件を代替操作で補う場合は、毎回の転記や管理者の対応時間も比較に残します。候補を見て要件を追加したら、必要性を見直し、他候補にも同じ条件を適用します。

書類の保存期間や法的適否は「法令対応」という説明だけでは決められません。契約書類、設計資料、経理書類など対象を特定し、適用条件と根拠資料、判断する担当を記します。必要に応じて専門家へ照会し、保存形式や閲覧方法へ反映します。設計や建物の安全性も、画面に警告がないことではなく、担当者が対象資料へ戻って判断する事項です。

03.全候補へ同じ業務の台本を渡す

提供元のデモは実現方法を知る機会です。それに加えて、自社担当者が普段の端末と役割で仕事を終えられるかを試します。実案件の情報を持ち込む前に登録・共有の条件を確認し、比較には不要な個人情報や機密情報を含まない架空データを使えます。

共通試験の架空シナリオ

端末だけでなく、通信環境、権限、対象プラン、事前説明と練習の範囲もそろえます。候補ごとに開始状態が違う場合は、そのまま時間を比較しません。同じ担当者が順番に試すことで課題に慣れる影響もあるため、実施順と練習回数を残します。

通常の流れに加え、承認後の仕様変更などの例外を分けて試します。何を変えるかと同時に、過去の承認記録や別案件の情報など、変わってはいけないものも指定します。

提供元には、事前設定、追加契約、個別開発が必要な項目を区別して回答してもらいます。管理者の代理入力や外部表計算で補った作業があれば、その内容も結果に含めます。デモだけに用意された上位プランの機能を、契約予定の範囲と混同しないためです。

04.「できた」に、支援と未完了の理由を添える

観察では、完成物の有無だけでなく、自力、手順書の参照、口頭支援、代理操作のどれで完了したかを分けます。代理操作で完成しても、自社担当者が日常運用できることまでは確認できません。

操作結果の架空記入例

初回の説明で解消する迷いと、毎回管理者に頼む操作では、教育や運用の負担が違います。「使いにくい」という感想には、どの検索条件で止まり、何を追加して進めたかを添えると、設定、習熟、機能制約のどれを調べるかが分かります。

時間切れは「未完了・原因確認中」と記録します。制限時間内に終わらなかっただけで、機能が存在しないとは言えません。平均所要時間を出す場合は、完了した試行の合計時間を完了試行数で割り、単位、回数、条件を付けます。同時に未完了件数と、完了試行数÷全試行数で求めた完了率も示せば、成功分だけの短い平均で判断する偏りを避けられます。

観察記録は、入力する人と結果を受け取る人の両方から集めます。経営者には集計が見やすくても、現場の登録が増える場合があるためです。権限を設定した人だけで終わらせず、一般利用者の操作結果を別の担当者が見れば、管理者権限のまま試していたといった見落としも拾えます。

画面の撮影・録画は提供元と可否を確かめ、必要な情報だけを残します。資料の回答、実際の操作結果、契約で約束される内容はそれぞれ別の根拠なので、選定表から参照できる形で持ちます。

05.権限・復旧・移行・解約は契約前に確かめる

日常の画面が使いやすくても、情報を守れない、移せない、取り出せない場合には運用を続けられません。この部分は便利さの採点と分け、業務開始に必要な条件として扱います。

IPAの中小企業の情報セキュリティ対策ガイドライン案内は、経営者向けの指針と社内で実践する手順を紹介し、バックアップを基本対策に含めています。以下は工務店が候補製品を試すための提案であり、IPAによる個別製品の認定や適合判定ではありません。

禁止した操作も、許可されたテスト環境・範囲で試します。メニューに表示されないことだけでなく、検索、通知、保存したリンク、出力といった利用経路を対象にします。想定外の相手へ情報が見える、本番データを変更しそうになるなどの事象は操作を止める条件とし、報告先と再開を判断する人を決めます。

復旧を実演できない範囲は、資料と手順で確かめた範囲として記録します。CSV出力があるだけで、添付や設定を含む環境全体を復元できるとは限りません。

移行は件数だけでなく内容とつながりを照合する

移行対象を、日常利用、参照用、移行しない情報に分けます。移行しない過去案件も、必要な期間に読める方法が必要で、旧環境を残すなら利用費と閲覧条件を含めて判断します。

少量の移行試験には、複数の添付、長い備考、特殊な文字、変更履歴を持つ案件も含めます。元データと比べ、件数、欠損、重複、図面・写真の開封、案件との対応、金額と版を照合します。金額は税と丸め条件をそろえます。顧客の統合や明細の分割がある場合は、単純な件数一致ではなく変換対応表で追います。

切替時には更新を止める時点と差分の反映を決めます。戻す場合も、新環境へ登録した情報を旧環境へどう引き継ぐかが必要です。元データの保全、戻す条件と責任者、再開後に正式な記録とする場所までそろえておけば、各担当が独自に旧運用へ戻る混乱を抑えられます。

出力は別環境で読み直します。CSVの文字コード、先頭ゼロ、改行、日付、帳票の対象版、添付の実体と対応情報を見ます。「返却できる」という口頭回答は、必要範囲と形式、期限、費用を具体化し、契約文書や仕様範囲と結び付けます。

06.支払額と社内の作業時間を同じ条件で並べる

比較期間、利用人数、対象機能、税の扱いをそろえます。費目は初期設定、利用料、追加利用者・容量、オプション、連携、移行、教育、保守、解約時の作業に分け、未見積をゼロ円にしません。

総費用は、一時費用、月額費用×対象月数、従量費用、追加作業費を、重複しないように合計します。年払いの場合は対象期間と支払時期を分け、途中解約や人数変更の条件も付けます。見積有効期限、更新条件、価格が変わる可能性のある費目は、決裁時に見える位置へ置きます。

架空計算：追加人数と教育負担

基本利用者8人に加え、3か月目から2人を追加し、全体の比較期間を12か月とするなら、追加利用分の数量は2人×10か月＝20人月です。基本8人分の料金を含む総額ではなく、追加部分の数量計算です。実在製品の課金方式を示しておらず、登録人数、同時利用数、案件数など、候補の課金単位に合わせて計算し直します。

教育時間は、受講者6人が各2時間、別の教育担当者が準備と対応に4時間を使う架空例なら、6人×2時間＋4時間＝16人時です。この例では教育担当者は受講者6人に含めません。追加の受講や通常業務の代替対応があれば別に計上します。

社内の作業時間は外部支払額と分けて示します。金額へ換算する場合は単価と対象作業を明記します。「移行一式」に自社での名寄せや添付整理が含まれるか、教育費が何人・何回までかも確かめると、見積外の負担を把握できます。

教育の完了は、出席だけでなく役割ごとの課題を終えられるかで見ます。問い合わせの社内窓口と代替者を置き、現場の作業や経理の締め日との兼ね合いも導入時期の判断に含めます。

07.必須条件を満たした候補から、費用と使い方を比べる

選定の順序は、必須条件の充足、重要な未確認の解消、操作結果と負担、費用の比較です。必須の閲覧制限を満たさない候補を、便利な集計機能の加点で採用可能にはしません。設定を直して再試験できるなら保留、解消できないなら見送りとします。将来の開発予定も、現在使える機能とは別です。

希望要件を点数化する場合は、候補を見る前に同じ評価尺度と重みを決めます。加重平均を使うなら「各項目の評価点×重みの合計÷重みの合計」で計算します。ここで分子は、項目ごとの積をすべて足した値です。共通の項目・重みで比べ、未確認をゼロ点で補ったり、候補ごとに評価項目を外して分母を変えたりしません。必要な確認がそろうまでは順位を確定しない方法が適しています。

契約条件やデータ返却は、無理に点数にせず、契約書で確認済み、回答のみ、未確認といった根拠の状態で示せます。役割別の評価差も平均へ埋めず、現場の入力が増える一方で経営の集計が楽になる、といった負担の移動を決裁資料に残します。

条件付き採用は社内の候補決定とし、契約や本番開始の許可とは区別します。例えば閲覧制限の修正が条件なら、確認前の本番データ投入は保留するなど、進めてよい範囲を明記します。契約前に解消すると決めた必須条件は、未達のまま契約へ進めません。

全候補を見送る結論もあります。既存運用の改善で対応するなら、選定中に分かった課題を改善担当へ渡せます。契約へ進む場合は、直前のプラン、仕様、価格、利用人数、支援範囲を決裁時の資料と照合し、変わった条件が影響する箇所を再確認します。

08.導入後も、選定時に試した仕事へ戻る

選定表は、導入時の設定・教育・移行と、その後の見直しへ引き継ぎます。限定した案件と利用者で始めても、送り手と受け手の必要な役割は参加させ、情報の受け渡しが一巡する範囲で運用を見ます。

利用状況はログイン数だけでなく、登録、承認、引継ぎ、出力まで終わったかを見ます。別の表計算や電話で補っているなら、その理由と負担を調べます。問い合わせは操作、不具合の疑い、運用判断、追加要望に分け、同じ質問が続く箇所を教材や設定の見直しにつなげます。

当初の目的が見積変更の引継ぎなら、導入後も変更記録から受け手の確認までを同じ定義で測ります。対象件数、期間、案件の種類、人員が違えば併記し、前後の差だけで製品の効果とは断定しません。担当変更や契約更新の際には、権限、必要な費用、出力、残る課題も見直します。採用時に残した根拠があれば、続けるか、運用を直すか、範囲を縮めるかを同じ目的から判断できます。