2-4-3 エンジニアリング
エンジニアリングとは、システム提案から現地試運転調整やメンテナンスまでの一連の業務をさす。
この業務は、常に客先との接点があり、そのニーズの調査やシステム引渡し後のメンテナンスサービスも含み、広範囲に及ぶものである。
一方、的確に業務を進めるには、客先要求と実施コストのバランスを考慮して、両者の最適な調和を図ることが重要である。
なお、本文においては、一般的なエンジニアリング業務について解説する。
3．1 市場特化の原則
エンジニアリングを行うにあたり、エンジニアを管理するマネージャーレベルで行うべき重要な業務の一つが市場特化である。
担当する市場によってエンジニアリングの内容はかなり変わってくる。品質と効率を考慮すれば経験のあるエンジニアとそうでないエンジニアでは雲泥の差がある。
移動やその他の要因で該当市場担当エンジニアが居なくなることも考慮して後輩の育成も必要である。
3．2 ソフトウェアのパーツ化
エンジニアリングは、仕様決定までのプロセスとそれに従ったソフトウェア製作に大別できる。
ソフトウェアのカスタムメイドで製作した場合、5年経てば作った本人でもわからなくなることがある。
ソフトウェアの製作にあたっては、各市場に別に統一したスタイルで製作し、パーツ化を図ることが重要である。これは上記（1）にも関連する。
3．3エンジニアリング業務の体系化
3．3．1 体系化の必要性
エンジニアリングの体系とは、その業務進捗に合わせて最適に分割した業務区分をいう。適切な管理及び運営のもとで、業務を円滑に進めることを目的としており、結果として生産性と品質の向上を意図するものである。エンジニアリング業務では、品質（Q）・納期（D）・コスト（C）をコントロールすること、すなわち正確なスケジュール管理が必要である。
しかし、多くの関連部署・業者・担当者等が関わっている場合は、業務の進捗を正確に把握することは困難である。さらに、未決定・不確定・不具合事項の発見が遅れるほど、その修正・手直し等に時間がかかり、コストアップや納期遅延をもたらす。
そこで、エンジニアリング業務を機能的に分類し、各々の業務（工程）における作業を明確化にすることにより、不具合等の早期発見及び正確な進捗管理を実現すること可能となる。また、体系化は作業の集中化や効率アップを実現する。
エンジニアリングの質は、人材に依存するところが大きいが、会社としては業務の体系化への取組み姿勢によって決まると言っても過言ではない。近年、「品質（Quality）」の側面から会社自体が評価される時代になりつつある。
納品されたシステムの品質が悪いと、会社として次回の仕事に差し支えるなど問題を大きくする可能性があるので、担当者はコストをにらみながらより良いエンジニアリング（CS）を心がけることが重要である。
3．3．2 体系
エンジニアリングの業務を以下の6工程に分類する。
（1）要求仕様検討
客先ニーズを探り、その実現可能性について技術・納期・体制・金額の面から検討する。
（2）基本設計
客先ニーズを統一化し、システムの実施項目を明確にする
（3）詳細設計
具体的な実現方法をハードウェアおよびソフトウェアの面から決定する。
（4）製作
各機能・項目を細分化し、修正・仕様変更・将来の増設を考慮して製作する。
（5）試験
関連するハードウェアを可能な限り取り揃え、総合出荷テスト及び客先立会いテストを実施する。
（6）試運転・運用・メンテナンス
現地にて試運転調整を行い、システムの引渡しを行う。
また、メンテナンス契約により、システムの稼動を保証する。
各工程の実施において、次の項目がポイントになる。
- 必要な生産物（仕様書、図面等）の明確化
- 仕様の客先承認
- 工程完了時のレビュー実施
- 次工程への移行のタイミング
- 問題点の把握
3．4 エンジニアリング業務の説明
3．4．1 要求仕様検討
- システムの目的の明確化その市場・アプリケーションの特徴や関連技術状況を把握するために文献や最新技術の情報を収集し、客先要求の理解及び現場イメージを把握することにより、システムの目的を明確にする。類似例がある場合、そのシステムを十分に理解し、問題点を明らかにしておくことも必要である。
- 実現可能性の検討技術、期間的および費用の観点から、実現可能性について検討する。
- この段階で客先と仕様の概要を取り決め、後工程に大きな影響を及ぼさないようにする事が重要である。
3．4．2 基本設計
客先ニーズを整理し、真の要求事項を明確にすることにより、システムで何を実現するのかを設計する。
（1）仕様の明確化
曖昧な仕様や客先要求を明確にすることにより、潜在的不具合・矛盾等を除去することが必要である。
この段階では定期的な客先打合わせより、電話・FAX・電子メールなどで詳細な仕様に決定していくケースが多々ある。これらの履歴はFAXや返信メールで再確認、または一括して議事録を作成して、後にトラブルのもととならないように残しておく必要がある。
ヒューマンマシンインタフェースは、客先の運用と密接に関連するため、異常処理も含めて慎重に検討し、決定すべきである。特に、異常処理はなるべく単純明解にし、できる限り運用に任せる方向で検討するのがよい。後の作業に大きく影響するからである。
（2）システム構成の決定
実施内容に基づいて、仕様・処理能力・性能・実績等を考慮し、ハードウェアおよびソフトウェアの構成を決定する。これによって、他システムとのインタフェースの有無が確定するため、客先等との責任境界が明確になる（スコープ）。この境界については、後に疑義が生じないように客先と打合わせを実施し、決定事項は議事録に明確に記載して双方が承認のサインをすることが重要である。
3．4．3 詳細設計
前工程で決定した実施項目をさらに細分化し、ハードウェアおよびソフトウェアによってその機能をどのような方法で実現するかを設計する。
（1）各種の詳細設計
データ定義、データベース設計、制御設計、外部インタフェース設計等を行う。
特に、外部システムとのインタフェース仕様はできるだけ明確にすべきである。
製作に入る前に、客先に詳細設計仕様・図面として提出し、承認を得る必要がある。
（2）履歴
最終仕様になるまでの仕様変更（改訂履歴）やそれに費やした工数などは履歴として残すべきである。
3．4．4 製作
後に発生するであろう仕様変更・追加等を予測考慮したコーディング・製作を行う。
（1）ソフトウェア製作について
個人テクニックに依存した手法や性能を重視した最適化は、メンテナンス性に欠けるため禁止し、一定のルール（方式や書式）の下で製作する。これは、検証性・保守性・拡張性に優れるからである。
（2）単体テストの実施
単体テストは、総合テストの効率化のために十分に実施すべきである。
3．4．5 試験
現地納入前に行う出荷テストであり、可能な限り現地に近い環境をセットすることが必要である。
（1）総合出荷テスト
余裕のある十分な時間を確保し、様々な角度・環境でテストすることは、潜在的不具合の発見に有効である。
また、トラブルが発生しても効率的に対応できる。テスト方法は、事前に関連担当者間で十分に検討する。
（2）客先立会いテスト
客先要求が満たされているか否かのテストであり、仕様にずれがないかを最終チェックする。また、不十分な状態での現地搬入は、客先にとっても不利益になるので絶対に避けるべきである。
3．4．6 試運転・運用・メンテナンス
（1）現地試運転調整
事前準備が重要である。現地においては、様々な要因から作業の効率が下がる可能性があるため、前もってスケジュールや調整内容を十分に検討しておく。段取り8分仕事2分という言葉もあるように、常識と言っても過言ではない。
また、現地立会いテストは、調整の完了を証明する意味において重要なイベントである。
一方、不具合修正・仕様変更の実施は、その都度個々に行うのは避けるべきである。システムは、一定の設計思想に基づいて体系的に作られており、そこから逸脱する可能性があるからである。
（2）運用・メンテナンス
操作手順・方法等が取扱説明書・トラブルシューティング等に正確に記載されている必要がある。
また、定期点検、部品交換、製造中止部品の保持等のメンテナンス契約により、システムの稼動が保証される。
予め、数年間分のメンテナンス・交換部品を納入し、後は保証範囲外としてエンジニアリングサイドの不要ストックやラストバイを減らす工夫も有用である。
本編で使用している会社名・商品名・役務名は、各社の登録商標または商標である。
参考文献
マイコンシステム開発・導入マニュアル太田政弘著
日刊工業新聞社
