案件を実行する段階では、各工程でリアルタイムな情報（データ）で最適な業務判断を下していきます。
リアルタイム名情報は受注した案件の最適な判断材料といえます。
工程ごとで可視化できる要素は下記の通り。
１） 工程進捗
工程負荷状態の把握
計画立案と進捗の可視化
２） 原価管理
原価進捗
目標原価・利益管理
３） 手配状況
発注機材等の手配情報
納期管理
４） 負荷管理
社内工程と外注工程の負荷管理
５） 在庫把握
他社購買製品の確定手配による在庫管理（現在庫と在庫予測）
確定品目と未確定品目区分
６） 図書管理
図書閲覧（改定図書と承認図書などの区分含む）
納入する機器(機材)を複数台使用するシステム構成の場合、
対象とする機器のMTBFからシステム運用期間内で発生する稼働期間における故障回数
を算出することが出来ます。
故障回数は、機器ごとの算出としていますが、システム維持を行うために機器の信頼
性を把握することができますので有益な試算になる。
故障回数（ｎ回/日）の算出式
同一機種を複数台備えたシステム構成機器の場合、下記の算出式により、論理上の
故障回数を算出することが出来る。
パラメータ
故障回数（ｎ） ｎ 回
運用（稼働）年数（Y） Y 年
機器台数（Ａ） A 台
平均故障間隔時間（MTBF） MTBF 時間
1年間日数 TY 日（365日固定）
1日時間 DT 時間（24時間固定）
1年間1台当たりの故障確率：F=365×24/TMBF
1台当たりの故障回数から試算した故障確率：F=n／Y／A
等価式 n／Y／A＝365×24/TMBF
故障発生回数 ｎ＝（365×24/TMBF）×（A×Y）
500台の機材、10年間維持 平均故障間隔時間（MTBF）=500万時間のシステムの
場合
n=（365×24×/5000000）×5000×10=0.001752×5000×10=87.6回
－－－－－－－
1年の故障頻度=n×A/Y
ポワゾン分布を用いて、
1ヶ月（30日）で発生す故障確率=1-exp（F×30/365）
近似式=F×30/365
概算算出
MTBFから概算で1台当たりの故障回確率を出す場合、
システム構成の最小MTBFから算出する方法
MTBF 100万時間の装置（ユニット機器）を1年使った場合、および、2年、3年
使った時の故障確率は、
1年目の確立：Ｆ=1×365×24/MTBF
2年目の確立：Ｆ=2×365×24/MTBF
3年目の確立：Ｆ=3×365×24/MTBF
設計のインプットと設計過程、そして成果物（アウトプット）、及び権利や権限が
効率的に考えられた委託方式ですので、受注事業のスキルとして理解しておくこと
がベターです。
違約方式には3つの要素がある。
承認図（Approved drawing）方式
発注者が、基本仕様を提示し、受注者が、その基本仕様に基づいて使用に沿っ
た開発を行い、設計図を作成し発注者の承認を受け、承認が完了した段階で製
造する方式を承認図方式と言う。
貸与図（Drawing Supplied）方式
発注者が、設計・開発を担当し成果物（設計書）を提示し、受注者が、設計書
に基づいて製造を行う方式を貸与図面方式と言う。
委託図方式
発注者が、要件（要求）仕様を作成、提示し、受注者が、その要件（要求）仕
様書に基づいて基本設計、詳細設計を行い製造する方式。受注者が、基本設計
や詳細設計のアイデア（知恵）を出して設計する行為となり知的財産権（及び
人格権）がこの請負委託で発生する場合がある。
これを回避する目的で、契約段階で両者の合意を得て発注者に帰属させる等を
事前に講じておく。
もしくは、要件（要求）仕様を提示する段階で、必要な特許権が発生する設計
時には、申告すること。と一文をいれ、特許権が発生しない設計にするなどの
方法もある。
※要件(要求)仕様は、電気設備委託の場合、外注仕様として扱われる。
※外製は、外注と同義語とした。
※品質保証の責任は、システム全体として委託時の要件に提示している場合を
除き、発注物単体としての瑕疵が対象となる。
◆上記の表から、意図した成果物を納入するために、
要件(要求)使用と基本設計（委託物の主構造）で発注物を確定していることが分
かる。
委託先に見積を依頼する場合、必ず文書により行うことが必須事項です。
抜粋：
5 外注仕様書：外部へ依頼し製造する物品の一般条件，使用条件，型名，操作
（動作）方法，性能，外観や構造，機能，非要求機能，責任分界点，
付属品，台数，納期等を記載（注意：非要求機能は誤記です正し
くは、「非機能要求」です。
知的財産権や製造物責任、保守機能など、主機能以外に必要とされる要求は、
全て非機能要求に明記する。
必要な条件をしっかり纏めた上、「言った言わない」にならない方法で依頼す
ることが重要と言える。
重要なことは、
委託する内容により、委託方式を使い分けることが効果的です。
１）能動要素の場合は、貸与図方式化、委託図方式
特に、プログラム要素が含まれている場合、処理の入出力のロジックなど
動作振る舞い（シーケンス図など）を書面（図書)にして提出することで、
ロジック上の仕様の解釈違いが無くなる。
２）受動要素の場合は、委託図方式、承認図方式
入力と出力の関係や、与える電圧や電流などを規程した要件（要求）仕様
書（電気設備の場合、外注仕様書と言う）として、しっかり伝え、内部設
計は、委託者一任とするケースが多い。
ただしこの場合においても、図書関係は全て改修する契約とする（特に承
認図方式であっても）。
３）委託物の著作権
方式に左右されずに、委託物の著作権は、発注者に帰属させることです。
受注者が勝手に利用してはならないことを明言しておくことです。特許等
が発生した場合、委託者考案であっても、本契約により考案された経緯で
ある場合、共同出願とするなど、事前に取り決めておく。
免責とは、
① 責任を問われるのを免れること。
② 債務者が債務の全部または一部を免れること。
顧客提出図書では、免責と言う表現は使わない。
受注システムや量産製品の場合、免責事項に置き換わる用語としては、
保証外事項、例外事項（責任の範囲、品質の範囲の項目の一つ）
が有ります、また量産製品では、
正しくお使いいただくためのご注意
取り扱いについて
安全のために
で表記されています。
これはJKC（JKPIの製品）も同様です。
量産製品や受注システム製品、サービス提供などでは、下記の様に言葉を換えて記
載している。
量産製品の取扱説明書に記載する場合の例。
① 正しくお使いいただくためのご注意
② 取り扱いについて
③ 安全のために
なっどの表記で記載されています。
また、その他の重要事項は、
④ 必ず守る、禁止
として喚起している。
上記①から④を行った場合、それぞれの重大事故（火災、感電など）に繋がる可能
性があることとして表示されています。
従って、裏を返せば、①から④の行為で事故が起きても対処できないと言っている
ことにも繋がる。
PL法や民法で定めている法的扱いではないが、容易に想定できる範囲の注意として
安全性を訴求していることになる。
一方、免責が明確に明記されている商品（債務が明確なもの）もある。
例：保険商品の場合の免責事項は、
保険金を払わない。・・・・・自殺、事故招致 は保険商品を購入しても保
険金が出ません（ほとんどの会社で適用され
ていると思う）。
しかし、受注システムでは、客先固有の仕様で受注する仕事です。
責任分界点（品質の境界線）として顧客要求を前提として責任を全うします。
責任分界点で責任の範囲（保証の範囲）を定めることが基本です。
その基本は、機器が故障した場合であっても動作させる要求であれば、
並列稼動とする。・・・・・・常に2台が稼動し、どちらかが異常停止して
も機能を維持する。
現用予備稼動とする。・・・・異常停止した信号を受け、他方が起動し機
能を維持する。
（シーソー稼動：俗称）手動切替でも良い場合もあります。
製品や受注システム製品の免責に置き換わる記載方法は、
例外事項（保証外事項など）
自然災害（地震、津波、噴火など）や人災（全損火災、自ら招いた事故
など）による該当装置全体が崩壊した場合は、その限りではない。（免
責事項と同じです）
ただし、PL法、民法では、免れることができない範囲（人命に係わる事
故等、事故の因果関係を証明し、訴訟を起こされた場合）は逃れること
ができません。
顧客が要求している場合、その要求に沿ったシステム設計やシステム保
証が必要（免責にはできないことになる）。
システム設計者が設計段階で想定出来る事項は、請負システム設計の段階でシ
ステム稼動の維持を前提とした設計とし構築する。
設計時に想定できたが、要求（仕様）に含まれていないから対応しない。
「対応しない」と言うことを納入前に客先承認もらい進めることです（そ
の為に納入仕様書で歯止めをかける）。
自己判断は絶対に行わないことです。
契約後に出た仕様の追加などは、機能追加契約として扱うが、請負金額
の中で出来る範囲は、そのまま作業として取り込むことが多い（見積の
甘さ→次回の見積時には、抜け我ないように行う）
顧客要求で冗長不用、1系統で稼動すればよい、と言う仕様の場合、
構成要素の説明で1系統冗長無とした上で納入（完成）図書に明記する。
特定（特殊）業務などの受注システムでは、公知の事実として異常系処
理とて対応しなければ、システムの機能が維持できなくなり、システム
を導入した意味がなくなる場合もあり、顧客のクレーム対象になる。
システム上異常処理が出来ない場合、（顧客の意思で異常処理が不用の
場合でも）例外事項に明記して顧客の承認を得ておくことが受注システ
ムとしての責務になります。
（受注業務を遂行している途中でも、不明確な仕様や発見した異常を、
客先に都度相談していくことが大切と言えます）
参考
操作運用を越えた使用による障害などは、
予め予測できる事項は、使用や運用を超えた段階で報知や回避等による動作
（この内容が異常処理系です）を行うべきとされ、操作者に対して警告でき
ることが必要になる。
種々の成果物（客先打合覚書、議事録、要件定義書、納入仕様書、など）の作成
時の考え方は、いたってシンプルです。
インプット情報を元に事実を書く。
それでは、この事実とは、何が必要になるのでしょうか・・・・これが問題です。
実際に書く目的は、フェーズにより異なります。
しかし、商談であれば、お客様と打合せやこれからの案件などの情報を遣り取り
するわけです。よって、それぞれの目的の達成するために書いていく。という行
為になります。
客先仕様の掘り下げ
要件定義であれば、客先の要求に対してどの様に具現化していくのか。
・・・・・要求に対応した実現方法です。
運用上で必要な抜けが無いか
・・・・・客先の運用で当たり前のことは要求に出てこない場合が多いです。
この場合、抜けると後になってクレームになる場合が多々あります。
客先が運用することを想定し、どの様な使い方をしていくのか、ど
の様な制限まで許容できるのか。など掘り下げて要求を出していき
ます。
保守や点検はどの様にするのか、
・・・・・万が一異常が発生したらどうするのか、システムはどうなるのか。
見え隠れする要求もありますので、客先が実運用するときを描いて
もらい抽出していきます。
後工程の必要事項
後工程で必要なことは、要求をどの様に具現化していくのか、これをある程度誤
解しない範囲で書いておかないと、システム仕様やシステム設計の段階で、時間
が掛かってしまいます。出来るだけ合理的に観点ブラすことなく書くことです。
設計の後工程も同様、
取付に条件のあるものは、設置要領書として発行しなければ、工事担当に伝達で
きない場合も出てきます。
現地調達で用意するものも、場合によっては、仕様を明示しなければならない場
合もあります（異金属腐食（ガルバニック腐食）などのため）。
接続方法では、単純に動線をつなげばよい場合もありますが、平衡回線を用いた
場合では、条件（洗剤の処理やインピーダンス）が出てきます。また、接続方法
によっては、誤動作する場合も出てきます。
これらを伝達するために、作業者が入れ替わっても見ればわかるようにしなけれ
ばならないことなども理解し成果物を作成していきます。
