既製品を使う？独自開発する？機器点検の仕事で比べる方法

まず、点検のどの仕事をできるようにしたいかをそろえる

「点検管理機能がある」だけでは、自社の仕事が収まるかは分かりません。点検の記録を残すところまでなのか、次回の案内候補を出すところまでなのか、その情報を会計や顧客管理へ渡すところまでなのかで、確認する範囲が変わります。最初に、現場が普段行う一連の仕事を、両案へ同じように示します。

この例では、顧客の機器を選び、点検の内容を登録し、その機器の過去の履歴を確認し、次回案内の候補を確かめる流れを置きます。さらに、会計と顧客管理へ何を受け渡したいかを尋ねます。必要な情報や受け渡し方は、現在の運用と各システムの担当に確認して決める事項です。

• 業務担当は、入力から次の仕事までを説明する

  いま使っている帳票や画面を基に、何を入力し、どの情報を見て、次に誰が動くのかを伝えます。困っている点と、今回も残したい仕事を分けます。古い画面と同じ見た目を再現することが、必ずしも目的とは限りません。

• IT発注担当は、既存システムとの境界を確かめる

  会計と顧客管理のどちらへ、何の情報を、どのタイミングで渡す必要があるかを担当者と確認します。「連携できる」という説明の対象を、自社のシステムと具体的な仕事へ絞ります。

• 判断する人は、残す仕事と変えてよい仕事を確認する

  新しい仕組みに合わせて手順を変えられる部分と、業務上残す必要のある部分を整理します。便利そうな機能があっても、今回の目的に必要かが不明なら、その理由を確かめてから比較へ加えます。

自社で用意するのは、まず機器一件と点検一回をたどれる入力例です。顧客や機器を特定しない仮の情報で、必要な入力項目と期待する結果を示します。この一件を試せば全業務が確認できるわけではありません。最初の比較をそろえるための出発点として使い、必要な例外は後から同じ条件で追加します。

既製品・設定・追加開発・独自開発の違いを知る

既製品と独自開発は、完成品か未完成品かだけの違いではありません。使い始めるまでの作業、自社へ合わせる方法、使い続けるときの変更の仕方を含めて見ます。以下は、この比較で使う言葉の意味です。実際の提供範囲は製品や提案ごとに確かめます。

既製品・標準機能

複数の利用者向けに提供される製品やサービスと、通常の提供範囲に含まれる機能です。点検履歴の表示が標準機能にあっても、自社の入力方法、必要な情報、権限、連携まで合うとは限りません。

設定

用意されている選択肢や設定項目で、表示や動きを調整する作業です。次回案内の条件を設定できるか、誰が変更し、変更後に何を確認するかを尋ねます。設定でできる範囲と費用は、提供側の回答を確認し、未回答なら未確認と記録します。

追加開発・個別改修

標準の提供範囲だけでは足りない部分に、プログラムなどの作業を加える方法です。製品本体を直すのか、外側に処理を追加するのか、接続部分を作るのかを分けて説明してもらいます。名称だけで、更新時の影響や保守の担当は決まりません。

独自開発

自社の仕事に合わせたシステムを開発する方法です。全てを一から作るとは限らず、外部の部品や既存サービスを使うこともあります。提案書の記載と、試作で確かめた動作、今後作る範囲を区別します。

連携とデータ移行

連携は、使い続けるシステムの間で必要な情報を受け渡すことです。移行は、古い管理ツールの情報を新しい仕組みへ持っていくことです。日々の受け渡しができても、過去の点検履歴を移せるとは限りません。

クラウドで使うかどうかは、この区別とは別の軸です。既製のクラウドサービスも、自社向けに開発するWebシステムもあります。「クラウドだから連携済み」「独自開発だから何でも変更できる」とは判断せず、対象の案で何をどう実現するかを確かめます。

既製品に一部の追加開発を組み合わせるなど、中間の方法も考えられます。ここでは選択肢を無理に二種類へ固定するのではなく、検討中の二案について、標準で使う部分、変える部分、外部とつなぐ部分をそろえて比較します。

試用で見た表示と、提案書に書かれた案を分ける

既製品の試用画面と独自開発の提案書を、そのまま同じ「対応可能」の印で並べると、確かめた範囲が見えなくなります。実際の操作を見た項目、文書に書かれた案、まだ何も確かめていない項目を分けて残します。提案の説明が具体的でも、動作の確認とは別です。

図の既製品側は、架空の試用画面で点検履歴と次回案内の候補が表示されたという設定です。案内メールの送信、会計への反映、顧客管理との一致まで確認した設定ではありません。独自開発側は、履歴・案内・受け渡しの構想が提案書にある段階で、実装や動作、納品、契約が済んだ意味にはしません。

確かめた範囲を分けるのは、片方を不利にするためではありません。両案の何が判断材料としてそろい、どの追加確認が必要かを分かるようにするためです。標準機能の説明、提供側のデモ、自社の入力による試用も、同じ記録へ混ぜずに条件を明記します。

二つの案を、同じ項目と確認の状態で並べる

既製品案は、架空の試用画面で履歴と次回案内の表示を見た設定です。独自開発案は、提案書に書かれた構想です。表示を見たこと、文書に書かれた案、まだ回答が必要な条件を分けて比べます。提案に記載があっても、動作・納品・契約が確認できたことにはしません。

以下は、同じ架空の機器点検業務を比べるための二案です。内容がない欄は「未確認」と表示します。二案の仕事と入力例をそろえた上で、表示を見た項目と、文書の構想、回答が必要な項目を読み分けます。

この状態で「既製品は連携できない」「独自開発なら必ずつながる」と結論を出すことはできません。次に比べるのは、既製品側へ連携・移行・維持の説明を求めた回答と、独自開発側へ同じ入力での動作案や保守範囲を求めた回答です。未回答が多いからといって、実際の機能の優劣まで決めつけないようにします。

同じ入力で、履歴から案内・受け渡しまで確かめる

比較の試用では、両案へ同じ入力と期待する結果を渡します。既製品なら使える試用環境を確認し、独自開発なら試作でどこまで示せるかを相談します。まだ動くものがない部分は、文書による説明として記録し、後で何を試すかを決めます。

1. 機器を選び、点検内容を登録する

   業務担当が、どの顧客のどの機器へ点検を結びつけるかを示します。登録する情報と、入力後に残る内容を確かめます。画面に入力できたことだけで、保存や後からの検索まで確認済みにはしません。

2. 同じ機器の履歴を開き、今回の点検をたどる

   保存した内容を開き直し、別の機器や顧客と取り違えずに読めるかを確かめます。必要な項目を見つけられるか、修正した場合にどう扱うかも、現場の手順に沿って質問します。

3. 次回案内の候補を確かめる

   どの情報や条件から、誰への案内候補が表示されるかを確認します。候補の表示、担当者の確認、実際に連絡する操作を分けます。自動送信が必要なら、その条件と確認方法を別に尋ねます。

4. 会計と顧客管理へ渡す情報を確かめる

   必要な情報を、渡す側で用意し、受け取る側でどう確認するかを示します。ファイルを出すだけなのか、読み込みまでなのか、入力を直した際の更新も含むのかをそろえます。受け取るシステム側が試せない場合は、未確認の境界を残します。

ここまでを最初の一件で確かめたら、現場で問題になる例外を追加します。例えば、同じ顧客が複数の機器を持つ場合、点検内容を後で訂正する場合、案内を出さない条件がある場合です。自社に必要な例外を選び、両案へ同じ条件で追加します。外出先で入力する仕事があるなら、使う端末と通信条件も試用の条件に含めます。

これは質問の例で、送信済みの依頼や確認結果ではありません。試せた項目には使った入力・環境・確認した範囲を添え、試せなかった項目には理由と次の確認先を残します。画面の見た目が整っていることだけで、仕事全体の適合を判定しません。

足りない機能を、業務変更・設定・追加開発に分ける

必要な仕事と製品の違いを洗い出す作業を、フィット＆ギャップ分析と呼ぶことがあります。ここでは「合う仕事」と「そのままでは足りない仕事」を具体的に分けると考えてください。機能名に丸やばつを付けるだけでなく、不足をどう扱うかまで相談します。

自社の手順を変えて対応できるか

例えば、案内候補を確認する順番を変えることで仕事が収まるなら、業務担当と変更内容を確認します。手順が変わる人、追加の入力、教育や確認作業も含めて見ます。提供側が「運用で対応」と書いただけで、自社が了承した扱いにはしません。

用意された設定で対応できるか

案内候補の抽出条件や入力項目を設定で調整できるなら、対象の設定と制限を示してもらいます。設定後に同じ入力で確かめ、変更を管理する人も確認します。標準機能の存在と、自社向けの設定が済んだことを分けます。

追加開発が必要か

設定だけで足りなければ、何を追加し、どこに手を加えるかを尋ねます。対象の製品版、接続先、試験、今後の更新対応を含むかを確認します。追加の説明がなければ、実現可能・価格確定と記録しません。

独自開発の案でも、必要な仕事が全て作る範囲へ含まれるかを確認します。「専用に作るので合わせられる」という説明から、例外処理や会計・顧客管理への接続まで含むと推定しないようにします。画面の試作で見た動きと、まだ提案だけの仕事を分けて、残る作業の範囲を返してもらいます。

比較が一番安い設定例と、全機能を作る独自開発例になっていたら、今回残したい仕事へそろえ直します。一方で、必要性が未判断の機能まで無理に両案へ追加する必要はありません。まず業務担当と判断の理由を確かめ、比較の対象へ含めるかを決めます。

連携と移行は、渡す内容と試し方を具体化する

点検履歴が表示できても、別の会計・顧客管理で同じ情報を利用できるかは、別の確認です。提供側だけで答えが出ない場合には、既存システムの管理担当にも相談します。接続機能の有無だけでなく、両側が同じ顧客・機器・点検を対応させられるかを確かめます。

会計と顧客管理へ、何をどう渡すか

必要な情報の例は、顧客や機器を対応させる情報、点検の内容、会計側で必要な区分などです。実際に何が必要かは受け取る側へ確認します。自動で渡すのか、人が確認してファイルを取り込むのか、どの時点で更新するのかも、同じ比較条件へ書きます。

「API対応」という説明がある場合、APIはシステム同士が情報をやり取りするための窓口と考えてください。その窓口があることだけでは、今回の情報を受け取る処理や、必要な利用条件まで整っているとは限りません。対象の情報、使える環境、接続を作る範囲、動作を確かめる人を確認します。ファイルで受け渡す案なら、出力と取り込み、照合に残る自社の作業を同じように確認します。

同じ点検を二度取り込んだとき、点検内容を修正したとき、受け渡しに失敗したときに、何が起き、誰が気づいてどう直すかも質問します。最初の正常な一件だけでなく、自社で必要なやり直しの条件を試すことで、日常の確認作業まで比較しやすくなります。

古い管理ツールの履歴を、新しい仕組みへ移せるか

移行では、旧ツールから出せる情報と、新しい仕組みへ入れられる情報を対応させます。顧客と機器の結びつき、点検履歴、次回案内に使う情報がどこへ入るかを、サンプルで確かめます。旧データの修正、重複や欠けの確認が必要なら、自社と提供側のどちらが行うかを明らかにします。

移行後に、同じ機器の履歴をたどり、必要な情報が読めるかを業務担当が確認します。対象範囲の件数や内容をどう照合するか、切り替え時に追加された情報をどう扱うか、問題があった場合に何を戻すかも相談します。この架空例では移行方法も結果も未確認で、履歴を全て移せたという実績はありません。

機器と顧客を結びつける情報を扱うため、試用や社外説明に使うデータの扱いも社内で確認します。閲覧・修正できる担当、外へ出せる情報、保存先やバックアップの確認を、実際の利用条件へ結びつけます。個別の製品の安全性が、この記事の説明だけで確認できた扱いにはしません。

更新後に使い続ける条件と、費用の範囲をそろえる

採用の比較には、最初の導入作業だけでなく、使い始めた後に残る仕事も含めます。点検管理の製品や会計・顧客管理が更新された場合、設定や接続部分を誰が確かめ、必要な修正をどう頼むかを質問します。既製品なら全て提供側、独自開発なら全て開発会社と、名前だけで決めないようにします。

• 設定・追加開発と、更新の関係

  どの部分が標準機能で、どの部分が自社用の設定や追加処理かを残します。製品や接続先が更新されたとき、影響を調べる担当、試す範囲、修正の依頼方法を尋ねます。独自開発で使う外部サービスや部品の更新も、対象を確認します。

• 日常の問い合わせと、不具合への対応

  履歴を開けない、案内候補が違う、情報が渡らないときの窓口と対応範囲を確かめます。自社で確認してから連絡すること、問い合わせを受けられる条件、調査や修正の扱いを示してもらいます。

• 人数・データ・使い方が変わった場合

  利用者や機器、履歴が増えたときの制限と、確認すべき利用条件を聞きます。実際に使う端末や運用に必要な性能も、両案で対象をそろえます。現在の一件の表示確認から、将来の全規模へ適合すると推定しません。

• 使うのをやめる場合の情報の扱い

  顧客・機器・点検履歴をどの形式で取り出せるか、資料や設定をどう引き継ぐかを確認します。独自開発でも、納める資料やプログラムの扱い、別の担当へ渡す条件は提案と契約で確かめる事項です。

費用を比較するときは、利用する人数や期間、初期設定、追加開発、接続、移行、確認作業、保守・更新対応など、何を含む見積もりかをそろえます。既製品の利用料金だけと、独自開発の導入から保守まで含む金額を、そのまま並べても判断できません。自社が行う作業も、担当と用意できる条件を確認します。

この例では両案の費用と契約条件が未確認なので、価格差や「何年で得になる」という計算はしません。まず今回の仕事と比較する期間を示し、含む作業・含まない作業・まだ見積もれない条件を説明してもらいます。金額と範囲がそろった段階で、開発見積もりを同じ条件で比べる方法へ進めます。

回答後に比較を直し、採用・保留・見送りを判断する

回答を受け取ったら、説明を足すだけでなく、どの欄を何の根拠で更新するかを決めます。機能が追加される、設定で対応する、自社の手順を変えるといった回答は、条件が変わった部分を同じ入力例で試し直してから評価します。文書だけの回答なら、文書で分かった範囲にとどめます。

採用の候補として判断できる状態

今回必要な点検の仕事を、どの条件で行えるかが分かり、残る設定・開発・自社作業の担当と範囲を確認できている状態です。必要な連携・移行・維持・費用契約の回答をそろえ、試せた範囲と残る確認を判断者へ渡します。採用の判断と、発注・契約・着手の手続きは区別します。

保留する状態

必要な仕事へ対応できるか、追加の範囲や維持条件が分からず、選ぶ根拠が足りない状態です。未回答の項目、質問先、欲しい回答、回答後に試す内容を決めます。情報不足を、その案の機能不足や不合格と同じ意味にはしません。

見送りを検討する状態

自社が残す必要のある仕事へ対応できず、設定・追加開発や業務変更の代案でも条件が合わないと確認した場合です。必要な自社作業を用意できない、維持や利用条件が合わない場合も、理由と確認した範囲を残します。未回答だけを理由に、対応不可と記録しません。

判断者には、どちらが好みかだけでなく、同じ仕事の比較、確認の根拠、足りない条件、自社へ残る作業を一緒に示します。費用や開発期間は、提供側の回答と社内条件がそろうまで未確認として扱います。例の二案は、現時点で採用・保留の判断に必要な回答がそろっていない状態です。

同じ仕事と確認条件を、両案へそろえる

同じ入力と確認条件を両案へ示し、自社で確かめた事実、文書の案、回答待ちを分けて比べます。本文の架空の二案を、実際の結果として扱わないでください。

比較の版を更新したら、何の条件と回答が変わったかを担当者へ伝えます。製品や入力条件が変わったときも、影響する仕事だけを同じ条件で再確認します。比較条件を記録したこと、説明を受けたことを、実際の導入・承認・動作確認の完了へ置き換えません。