ほんとうの調達・購買・資材理論（坂口孝則）
・25のスキルと知識が調達・購買を変える
今回も増刊号ではあるけれど、通常号とおなじく調達・購買の５×５マトリクスを使い、調達・購買スキルや知識を紹介していく。この連載をお読みの方はおわかりのとおり、私は調達・購買人員に必要なスキルや知識は25に集約されると考えており、その解説を行なっている。
＜クリックして図を大きくしてご覧下さい＞
今回は、「コスト削減・見積り査定」のＤ「開発購買の推進」だ。
＜クリックして図を大きくしてご覧下さい＞
開発購買とは「研究・企画・開発の上流段階からコスト、品質、納期、サプライヤなどの情報を考慮しながら業務を進める取組み」と定義しておきたい。すると、「そんなこと当然ではないか」と思うひとがいるだろう。私もそう思う。べつに調達・購買部門が気にしなくても、設計・開発部門は、ＱＣＤをはじめとするさまざまな要素を考えながら、製品開発や研究を進めているからだ。皮肉ながら、開発購買という言葉自体、調達・購買部門側からの一方的な想いを象徴しているかのように見える。いわば、これまで当たり前のこと（研究・企画・開発の上流段階からコスト、品質、納期、サプライヤなどの情報を考慮しながら業務を進めること）を調達・購買部門が実施できなかったので、当然の姿になるべく「開発購買」なる単語が創出された。
しかし皮肉はやめておこう。これまでの調達・購買部門の姿を嘆いてもしかたがない。調達・購買部門が上流に介入することで、よりよい調達構造を実現できる。ここでは、この開発購買の方法論について述べていこう。
では、上流に介入することは、どれくらい重要なのだろうか。一般的に経験カーブとして、製品コストの決定率が語られる。
＜クリックして図を大きくしてご覧下さい＞
この図が表現しているとおり、製品コストの80%が企画・開発の上流工程で決定する。実際、某社で調査した結果も、ほぼ同じだ。ようは、これ以降の交渉を頑張ってみても、左右できる価格はプラスマイナス20％でしかない。それよりも、根本的なコスト削減を目指すのであれば、上流に介入するしかない。企画・設計上流段階でのＱＣＤの作りこみが企業収益にダイレクトにつながるのだ。
・開発購買が実施できない理由
では、開発購買の名のもとに、すぐさま調達・購買部門と設計・開発部門の協業を始めればいいじゃないか。しかし、各社ともなかなかうまくいかない。今回の連載では、各社の実例を述べ、設計・開発部門との具体的な対話スキルを伝えていく。しかし、まずは、「なぜ開発購買がうまくいかない」のか。その理由について考えてみる。
私が思うに、その理由は二つある。
1.各部門目標の違い
当然ながら、設計・開発部門は、新たな技術を適正な価格で製品化することを目指している。単に安価な製品や安価なサプライヤであれば、ありふれている。しかし、設計・開発部門は、あくまでも「新たな技術」を採用し製品化することが指名だから、調達・購買部門が単純な「コスト削減」だけを目標にしている場合は、ギャップが生じる。加えて、製品開発に調達・購買部門を参入させることで、どのような効果がもたらされるのかわからないことがある。これも当然ながら、メリットがない、あるいはメリットがわからないものに積極的に動くひとは少ない。
2.情報の質の問題
設計・開発部門は、自らが携わる技術領域のプロフェッショナルだ。調達・購買部門が、情報を提供しようと思っても、「そんなこと知っているよ」と設計・開発部門が感想を抱く情報となりかねない。それに、設計、要求元が何らかの情報を欲しいと思っても、その要求を察知できず、情報をタイムリーに提供できないことがあるだろう。
3.調達・購買部門の評価設定問題
設計・開発部門が調達・購買担当者に相談し、新たなサプライヤを探すとする。そのときに、調達・購買担当者がサプライヤを検索することは、あきらかに全社的に寄与する行為だ。しかし、調達・購買部門内で、そのような活動が担当者として評価される項目ではなかったらどうだろう。調達・購買担当者としての最適解は、開発購買など行わず、単に受領した仕様書にたいして見積りを取り、交渉を繰り返すだけだろう。
ここで、端的に解決策を述べるならば、1.については、「開発部門に対する動機づけ」、2.については「開発購買推進のための仕組みづくり、情報共有のシステム化、組織・体制づくり」、3.については「評価軸設定を含めた、トップダウンのアプローチ。加えて、調達・購買担当者からも積極的に情報を提示するようなボトムアップのアプローチ」が必要となるだろう。
そして、各社ともどのようにして、開発購買を実現しようとしているのだろうか。方法論としては、これも三つにわかれる。一つ目は、（物理的な意味を含めて）さまざまな部門からひとを集めてチーム化するもの。二つ目は、ＩＴを使いシステム化していくものだ。そして三つ目は、ルール化などにより開発購買を強制化するものだ。
・方法論１．チーム化による開発購買
チーム化とは、文字通り、多部門からメンバーを集める方法だ。自動車産業のように大型プロジェクトを発足させるものは、専任化することがある。大部屋方式と呼ばれるもので、製品・商品開発に関わる設計部員・生産技術部員・実験部員・購買部員を、数十人単位で集め、全員で開発を進めていく。この方式では、物理的に近いことが有効といわれ、実際に一つの大部屋に集約させる。これが「大部屋方式」の由来だ。
また、近くにメンバーが座っている、物理的に近接していることが大きい。このように大掛かりではなくても、すぐに実行できることもある。それは、たとえば、調達・購買部員の席を設計部門に置くことだ。実際に、若手バイヤーの席を設計部門に置く場合がある。最初はコピーなどの雑用が多いけれど、そのうち人間関係も構築でき、設計部門から技術的な相談も受けるようになる。
逆に、某自動車部品メーカーでは、以前は同じフロアに調達・購買部門と設計・開発部門があったものの、フロアがわかれると、設計・開発部門から調達・購買部門に相談する機会が少なくなったという。いまだに「近い」という事実は重要のようだ。
・方法論２．ＩＴ活用による開発購買
このＩＴ活用とは、調達・購買部門の推奨部品を設計段階から伝達するためにシステムを利用することが多い。製品設計時に、設計・開発部門が勝手に部品を選定していると、その品目数は莫大となる。そこで、あらかじめ「選んでほしい」部品を、データベース化しておき、使用を促す。
某社では、ＣＡＤに連携して、推奨部品を提示している。具体的には、設計・開発部門がたとえばチップ抵抗器を選定するとしよう。スペックを入力すると、これまでの実績部品がリストアップされる。そのときに、調達・購買部門が推奨するものは無色、調達・購買部門が推奨しないものは赤色で表示される。そのようにして、一つひとつの部品選定に調達・購買部員が介在せずとも、自動的に推奨部品を選択してもらう仕組みを構築している。
また、企業によっては、部品選定の際に、競合を強制化しているところもある。システム上で、必ず調達・購買部門に競合見積りを依頼しなければ、部品を決定できないようにしているのだ。
・方法論３．ルール・仕組み化による開発購買
このルール化・仕組み化とは、開発購買せざるをえなくすることだ。たとえば、某社では設計・開発部門は図面を書くことができるが、サプライヤや価格を決めることはできないルールにしている。すべての部品について、サプライヤ名と価格を記載するリストを登録せねばならないが、その役割と責任は調達・購買部門のみにある。ちなみに、その企業では、設計・開発部門が勝手にサプライヤや価格を決定することを「越権行為」と呼び、三回ほどそれを犯すと、懲戒免職となるという。年に一度、そのような越権行為をなくすよう、調達・購買部門から設計・開発部門に講習を行い、講習の最後にはその旨を理解したとサインまで求める。
また、仕様決定と価格決定を完全に分離しているところがある。なぜ、設計・開発部門がサプライヤや価格を決定したがるかというと、それは最終的に自分の責任になるからだ。最終的に自分の責任になるのであれば、調達・購買部門などに任せておられず、自分で交渉したくなる気持ちもわかる。そこで、いくつかの企業では、仕様決定と価格決定を完全に分離している。設計・開発部門は、仕様を決定し、理論コストとして与えられた目標コストに到達していれば、それ以上の責任は問われない。その理論コスト通りに調達できなければ、調達・購買部門がその責任を負うというわけだ。その理論コストとは、両部門が作成したコストテーブルで計算される。調達・購買部門も納得し合意したコストテーブルで試算するわけだから、それよりも高かったら、設計・開発部門の責任ではないとうわけだ。もちろん、このやり方をやろうと思えば、前回に説明した通り、厳密なコスト査定力とコストテーブルを持つことが必要だ。
また、昨今の流行りの言葉である「ユーザーマネジメント」とか「要求元管理」とは、仕様・前提条件決定の前に仕様決定・数量決定に対するサポートを行うことだ。
・そして集中購買について
そして最後に集中購買について触れておく。開発購買によって、社内の要求をまとめることができれば、次は全社の数量を集約することで安価に調達できる。順番が逆ではない。集中購買をするから、開発購買ができるのではない。開発購買ができるから、集中購買が可能となる。
事業部門が複数の場合、まずは各事業部門で調達品をまとめること。そのあとに、集中購買の検討となる。集中購買を考えようとしても、各事業部で各調達品の数量がまとまっていなければ、集めたところでたいした数にならない。
ところで、集中購買とは何か？ それは、文字通り、調達・購買機能を特定部署が一手に担うことだ。大企業にみられる日本・世界拠点分散型企業では、多くの場合、その拠点数だけの調達・購買部門が存在するだろう。そこで、集中購買のアイディアが登場する。
たとえば、同一企業内で、調達している類似・同一製品がいくつもあるのに、バラバラの数量で買っていてはもったいないというわけだ。まとめて交渉・発注することで、折衝対象のボリュームが増え、交渉力も増し、安価になる。これが集中購買誕生の背景でだった。
しかし、やり方を間違えると集中購買も効果がない。よくある例として、本社の調達・購買企画部門が全拠点をとりまとめようとしたものの、協力も得られずに頓挫することがある。これは、現在多くの集中購買取り組み企業で見られる。
集中購買のコツを一言でいうと、「実利を得る主体が、実行の主体である」ことだ。逆に、実行者と利益享受者が同一ではない場合は、失敗する。より具体的にいえば、集中購買の旗振り役が、最大購入事業部門の購買部門であるべきということだ。事業部門が、Ａ・Ｂ・Ｃ・Ｄ・Ｅあるとする。そのときに、本社が旗振り役になって、代表交渉するのではなく、最大需要者の事業部門が交渉すべきということだ。たとえば、その最大需要者が事業部門Ｃとしよう。各数量をまとめ、代表交渉をするのは事業部門Ｃであるべきだ。
＜クリックして図を大きくしてご覧下さい＞
なぜならば事業部門Ｃは、少しでも量が増えれば交渉力が増すチャンスなので、各拠点の仲間を増やそうとするからだ。しかも、増えなくても、量が少なくなることもない。他事業部門にしてみれば、安価な製品を買えるチャンスに相乗できる。だからこそ、実行者と利益享受者が同一であるべきなのだ。
このような仕組みがわからない企業の集中購買においては、ときとして、本社から各拠点にたいして「非協力的だ」などという批判がなされる。もちろん、各事業部は本社の指示にしたがって集中購買に加担することが求められるかもしれない。しかし、各事業部門のインセンティブを欠いているのだ。
長々と書いてきた。これらを意識したうえで、開発購買や集中購買を推進してほしい。
＜つづく＞
