技術と営業の仕事や役割についてどの様なイメージをお持ちですか？
私は、営業と技術の境界はかなりあいまいだと思っています。もちろん、明確にここまでは営業、ここからは技術と分けられる部分もあります。反面、営業技術や技術営業という言葉があるように、人によってどこまでが境界になるのか、明確に線を引けないこともよくあるからです。
技術サポートとプレセールス、担当技術にしてみればやってることに大きな差はありませんが、前者は有償のサービス、後者は売るための投資のようなもの。前者にはサポート範囲がありますが、後者は営業次第でほぼ無制限となり、サポート業務に影響が出ても、上長による営業判断の結果技術マネージャー泣かせになることもありました。
ここでは、技術の仕事・役割、品質マネジメントが技術にとってどの様なメリットがあるのかについて説明します。
技術の仕事、役割
技術的な仕事の分担：営業、技術、製造、検査の役割と妥当性確認
技術の仕事、役割のイメージについて説明します。
-
- 営業は、お客様の要望（やりたい・実現したいこと、価格、納期。ISOでいう顧客要求事項）を聞いて会社に持ち帰り技術に伝える。
- 技術は、お客様の要望を実現する設計をする。
- 製造は、技術の設計（設計図）に基づき商品を作る。
- 検査（品質保証）は、設計図通りに商品ができているかを検査（確認）する。
- そして、お客様の要望通りにできているかを確認する（妥当性確認）のだが、これはなかなか難しい。
ＱＣＤ（品質、価格、納期）の優先順位は変わるもの
ＱＣＤ（Quality、Cost、Delivery：品質、価格、納期）の優先順位は、立場（例えば営業と技術）により違ってきます。だからこそ、関係者間でコミュニケーションを保ち良い意味での妥協点や解決方法を探ることが売れる商品には必要になると考えています。
- お客様
- 品質、納期は満足していて当たり前（前提）です。
- さらに、価格が安くなるとうれしい。
- 営業
- 納期が最優先です。
- 価格は見積書ですでに決定しています。
- 技術
- 品質を優先したいところですが、納期を前提に計画するのことが多いと思います。
- 設計者が満足するまで事前検討や設計をする時間はなく、納期まで時間がないからといって経験豊富で仕事の速い技術を割り当てられるわけでもないのが現実ではないでしょうか。
新商品であれば、商品企画で価格、機能・性能、仕様の調整（トレードオフ、バランスをとる）をします。
企画当初に最高スペックで価格を設定してしまうと（社内的に適正価格かどうかはおいといて）、製品出荷まで妥協の連続となりがちで、販売開始に間に合えば運がよいと思います。とはいえ、途中から仕様を減らすのは開発期間短縮にはあまり役にたたないのが現実です。
当初の仕様をいかに「実際にできること」に近づけるかが企画担当の腕のみせどころ、やりがいにもつながるのではないでしょうか？
- 妥協しすぎればお客様からみて魅力が薄くなり、低価格、販売低迷、利益圧迫と売れない道を歩まざるえなくなる。
- 盛り込みすぎれも、高価格で売れない。そもそも完成しないことすらあります。
業務改善する設計者と受け身の設計者
新製品開発だけでなく通常業務でも同様だと思いますが、設計者により、ルーチン化、定型化、ある意味マニュアル化を並行して進める技術と、こなすだけの技術とでは大きな違いがあります。
さらに、半年、１年、３年と過ぎれば、歴史（経験）が長いだけでは、技術者としてのレベルは３年前とほぼ変わらず、慣れた分だけ技術レベルが落ちてしまうことすらあります。
一方、考えてる技術者は、より多くの仕事を正確に処理し、過去の自分の仕事を見て恥ずかしいとすら感じることもあるのではないでしょうか。
これは設計・開発に限ったことではなく、例えば同じような書類でも３年前に作った書類を改めて読んでみると、思わず恥ずかしさを覚えることが私にもあります。
管理職によるマネジメント
設計・開発の管理職にとってのマネジメントは、設計開発の規模が小さければ、個々の良さ（長所、得意なこと）を引き出す仕事の配分、並行して、仕事のできるメンバーのフォロー、そして抜けた時の穴をいかに埋めるか考え手を打っていくことになると考えています。
また、技術サポート（顧客のサポート）と営業技術（営業のサポート）との配分も悩ましい問題です。
営業マネージャーと技術マネージャー、対立すれば上司が営業なら営業よりの判断となるのは避けられず、仕事のできる技術担当の時間を技術サポートに割けなくなり、それでも回すために技術サポートのやり方を変えていったこともありました。
設計開発の流れ
ISO9000シリーズで要求されている設計開発の流れについて説明します。
設計・開発の依頼
営業から技術への依頼内容について、新規開発（既存技術でいけるか、技術導入が必要な場合とがあります）、既存製品の設計変更（いわゆるマイナーチェンジ）でいけるか判断します。
ここでのポイントは、顧客の要望、要求を営業が聴き、それを明確に文書で表し、お客様と営業や技術を含む関係者間で共有し合意することだと思います。
お客様の要望（やりたいこと）を明確に文書で表していれば、設計・開発を進める中で変更点が出てきた場合、設計・開発開始時の合意点に戻ることができ、追加であればどうするか話し合うことができます。
合意した文書（紙だけでなく、電子ファイルなども含みます）がなければ、言った言わないの水掛け論になっても仕方ないとは思いませんか？
打ち合わせの議事録はありますか？
なかったら、さっそく記録を残すことから始めてください。
設計・開発の計画
責任者、担当者を決めます。
通常、技術者のリソースは限られていますし、全員が頼りになる技術者ではないのが現実です。このため、誰を開発チームに入れるかは社内的には（特に技術部署にとっては）重要な問題です。
社内リソースを当てにできず、社外を利用する方法もありますが、リソースがないから開発できないという議論ではなく、現在の人員でどうすれば設計・開発を進めることができるのか意見交換ができるとよいですね。
要求事項（設計・開発に使うインプット情報）の明確化
要求事項（設計・開発に使うインプット情報）を明確にします。自社の設計・開発を始めるために必要な情報を具体的に定めます。
設計・開発の流れと管理
ここでは、設計・開発の流れについて簡単に説明します。
設計図書作成
仕様書、図面を作成します。
ここでのポイントは、お客様の要求を設計図書、具体的には図面、仕様書に落とし込むことです。
この際、仕様書、図面が正確で具体的であることが必要です。
- モノを作れない図面は、製造時に問い合わせがきます。
- あいまいさや誤りは、製造品質、コスト増に直結します。
- 計画した利益に影響が出れば経営判断になりませんか？
設計図書（仕様書、図面）のレビュー
レビュー、これも説明しにくい言葉の１つです。DR（Design Review：ディーアール）とも言います。
レビューで何をするのかを具体的に決めておくことが大切です。
定義3.11.2レビュー（review） 設定された目標（3.7.1）を達成するための対象（3.6.1）の適切性，妥当性又は有効性（3.7.11）の確定（3.11.1）。
「JIS Q 9000 品質マネジメントシステム－基本及び用語」より引用
設計図書（仕様書、図面）の検証
仕様書、図面に誤りがないか、整合性がとれているか、企画がイメージしている製品になるよう設計されているかなどを確認します。
事前に設計図書（仕様書、図面）が関係者により検証されていることが前提で、設計変更などを実施するかどうかなどを決めたりします。
「書類さえあればいいや」の声が聞こえてきたハードウェア開発は、開発遅れにとどまらず問題が長期化してしまった。ソフトウェア開発では、仕様決定後の次のレビューで、設計を開始していたにもかかわらず大幅な仕様変更を要求したなど、事情はあったようですがISOを取っていても徹底されていない例はあるようです。
妥当性確認
設計図書（仕様書、図面）により妥当性を検証することで、必要に応じ試作や試験を行います。
モノづくりでは、意外にこれが難しいと考えています。お客様の要求に対し、でき上がったモノが妥当かどうかを考え始めると何を考えているのか分からなくなることもありました。
設計・開発の結果（アウトプット）
設計・開発の結果、つまり設計図書（仕様書、図面）の管理などのことです。
例えば、図面は設計データの１つとして技術部門で管理しているのではないでしょうか。
設計・開発の変更管理
具体的には、図面の変更や廃止に伴う管理のことです。
前項の「設計・開発の結果（アウトプット）」と合わせて管理していると思います。
設計開発からみたQMSのメリット
外部審査において、「品質マネジメントシステムの設計・開発は、よくできている、考えられたしくみです。」とのコメントを聞いたことがあります。
私も品質マネジメントシステムの設計・開発はよくできていると思います。ISO9001の設計・開発は決して難しいことを要求しているわけではありません。にもかかわらず、なぜ運用できずに「ISOの書類さえあればよい」といった弊害が出てくるのでしょうか？
少々厳しい言い方になってしまいますが、ミスを防ぐための仕組みなのに、アレコレ理由をつけてやらないからだと思います。「忙しい」とか、「納期に間に合わない」とか、何かと理由をつけ（言い訳をして）、必要なプロセスを飛ばしてした結果、どうなるか？
- 問題になる。（表面化しないこともあります。）
- 問題にならずとも何も成果（設計開発のノウハウ）が残らない。
- 仕事をこなすだけで頑張る人から消耗、疲弊していく。
このような負のスパイラルが始まってしまうと、これを止める、断ち切るのはなかなか大変です。それこそ、トップの決意と忍耐が必要になることが想像できませんか？
繰り返しになりますが、ISO9001の設計・開発は特別なことや難しいことを要求しているわけではありません。ISOの要求事項には、用語が分かりにくいことはあっても、いたって当たり前のことが書かれています。
ISOの要求事項をどのように満たすかかは、導入する会社が決めることです。だからこそ、ISO9000シリーズを導入する際、自社の実態、実力に合わせることが、とても重要で大切なポイントになるのです。
形から入るのも一つの手ですが、形だけ導入して運用するのは、まさに百害あって一利なしです。「何のためにISOを導入しようとしているのか」、事あるごとに振り返り社内で共有することをおすすめします。
では、どうするか？
- まず、要求事項に自社の設計・開発フローをそのまま当てはめる。
- できるだけ、大枠、シンプル、簡素化する。
- ここをスタートとして、運用（設計・開発）しながら改善を続ける。
これに尽きると私は考えています。
【まとめ】
技術と営業の仕事や役割、営業と技術の境界はかなりあいまいだと思っています。
ここでは、以下について説明しました。
技術の仕事、役割
- 技術的な仕事の分担：営業、技術、製造、検査の役割と妥当性確認
- ＱＣＤ（品質、価格、納期）の優先順位は変わるもの
- 業務改善する設計者と受け身の設計者
- 管理職によるマネジメント
設計開発の流れ
- 設計・開発の依頼
- 設計・開発の計画
- 要求事項（設計・開発に使うインプット情報）の明確化
- 設計・開発の流れと管理
