ほんとうの調達・購買・資材理論（牧野直哉）
開発購買 ２ ～バイヤー視点での開発購買
前回、筆者の経験したもっとも避けるべき、誤った開発購買の一場面をご紹介した。そして開発購買にまず必要なものとして、購買するモノ・サービスに関する情報の早期入手の重要性を書いた。購入するモノ・サービスの価格へバイヤーとして影響力を及ぼすためには、何よりもまず実質的 にコストの決定度合いが低い段階で情報を入手し、適切な施策を講じることが非常に重要なのである。今回はその「適切な施策」についてお話したい。
バイヤーにとって必要なスキルに、製品やサービスの仕様に関する知識がある。価格の妥当性を探る際にも、自社の要求仕様の実現可否をサプライヤーに見出す折にも不可欠な知識だ。では、モノやサービスの仕様知識だけを持ち合わせていれば、バイヤーができるかといえば、決してそんなことは無い。それは前回の誤った開発購買にありがちな、設計出身バイヤーの発言に象徴されている。確かにバイヤーが製品・サービスの仕様に関する知識を深く持っていることは武器になる。しかしそれだけではバイヤーとしての存在感の確立はできない。重要なのは、その知識の使用方法である。その使用方法について一つの示唆を与えてくれるデータが、以下のグラフである。
＜クリックすると拡大します＞
前回の記事では、バイヤーとして発注するモノ・サービスの情報をいち早く入手することが、開発購買実現への第一歩であるとした。早期に情報を入手し、バイヤーとしての影響力を行使しながら仕様を決定してゆくことが開発購買である。では、究極的に早期、例えばエンジニアと同じタイミングで情報入手すれば、より適正な価格での購入が可能になるかと言えば、決してそうではない。早期に情報を入手することと同じくらい、バイヤーの持てる知識・スキルを総動員して影響力を行使するタイミングが非常に重要なのである。情報の入手は早くても良い。しかしバイヤーの影響力を行使するタイミングは、注意深くはかる必要がある。具体的には次の2点だ。
（１）エンジニアの考えがある程度まとまった時点
（２）エンジニアが、バイヤーの持てる情報を欲した時点
（１）は上記グラフで、エンジニアとバイヤーの情報入手を同じタイミングとしたときに描ける近似曲線には、R2係数の有意性に著しい低下が見られる。特に設計期間全体へ２／３以上踏み込んだ場合はほぼ有意性が見られなくなる。この有意性の低下はなにを物語るのだろうか。
私は、この有意性が低下する期間をバイヤーがエンジニアを見守る時間としている。客先のニーズを踏まえて、具体的に提供するモノ・サービスの内容を決定する初期の段階は、バイヤーとしての影響力の行使を控え、エンジニアに考えてもらう必要がある。エンジニアの考えがある程度まとまった段階で、初めてバイヤーが設計・開発プロセスへ参加していく意義を、このR2係数の有意性の低下が示しているのだ。
では、エンジニアの考えがある程度まとまった段階とはいつなのか。様々な状況が想定可能だ。ここでのポイントはエンジニアとのコミュニケーションの取り方だ。設計という創造的な作業に対して、スケジュール管理をおこなうこと であり、デリケートな対応が必要となる。製品開発の定期的な情報共有の場があれば、進捗をチェックし、サプライヤーとのコンタクトが必要になった段階でバイヤーとしてエンジニアとサプライヤーの間を取り持つこと で実現できる。これは、モノ・サービスの内容に大きく左右される。高度な技術を必要とする場合は早い段階でのコンタクトとなるであろうし、過去の類似品との同程度の技術であれば、要求仕様が明確になるまで待っていても良いだろう。外部リソースが必要なのかどうか。バイヤーとして技術レベル、対応できるサプライヤーの有無等から勘案し、具体的な手段・方法を具体的に提示すればよい。実現可能なサプライヤーがあれば、どういった検討をするのか、そういった内容をエンジニアの合意を得ながら一つ一つおこなってゆけばよいのである。お客様からの要求が高度・もしくは非常に新しい技術的ノウハウを必要として、自社としても過去に経験がない、エンジニアとしても雲を掴むような場合だ。エンジニアが雲を掴む……そんな状況にバイヤーとして尻込みをする必要はない。こんな場合にこそ、開発購買の実践が有効かつ、意義深くなる。ただし、これには事前準備が必要だ。
開発購買に必要な事前準備……それは、購入製品、構成部品の生産技術、必要材料といった現在購入しているモノ・サービスに関する将来展望を持つことだ。自分が担当しているモノ・サービスの未来予想図を描けているかどうか。その描いた未来予想図に関連して、将来的に不足するであろうリソースへの準備をエンジニアにも先んじて、継続して実践できるかどうかである。こう書くと、開発購買は精神論なのかとも思われるかもしれない。それは違う。そう遠くない将来を見越して、自社にどんなリソースが必要になるのか。それが今確保できるサプライヤーで充足できるのかどうか。そんな仮説立証の繰り返しをバイヤー自らセルフスタートでおこなうことができるかどうか。将来的に必要となる社外リソースの存在を具体化にしていく、リソース拡大のロードマップを描く、それが、バイヤーが実践する開発購買そのものなのだ。
「エンジニアだってさ、サプライヤーのことはわからないんだよ」
私があるエンジニアから聞かされた言葉である。既存サプライヤーはもちろんのこと、あらたな可能性を秘めているポテンシャルサプライヤーも含め、バイヤーは社内で誰よりも詳しいべきだ。しかし、これまで継続して事業をおこなってきた企業の調達・資材部門の場合、バイヤーは、新しいリソースを求めなくても仕事ができる。前任者のおこなっていた通り、前例にならってサプライヤーの選定をおこなうケースだ。長きにわたって事業を行っている場合には、地理的、歴史的なしがらみで、その会社特有のサプライヤーの棲み分けが形成されている事もある。バイヤーとしては、その棲み分けに沿ってサプライヤー選定をおこなえば良いことになる。あたかもバイヤーとして作り上げた秩序の如くに、である。
このような状況の中にあるバイヤーは、顧客の高度な要求は勿論、自社起点での新たな取り組みにも対応に苦慮することになる。顧客の高度な要求や、新たな取り組み、それに対応してゆくことは、これまで作り上げた秩序とは別ものだ。新技術や、新たなサプライヤー、新たなリソースを必要とする。それは従来の秩序の中には存在しない。
開発購買は将来的に必要になるリソースを具体化することだと書いた。ただでさえ不確実性が高まっているこの時代にそんな雲を掴む話と思われるかもしれない。短期間で明確な成果など現れないだろう。具体的に実感を伴って成果を得るためには、年単位でのアクションが必要になる。開発購買が今、必要とされているとすれば、これまで従来然の枠組みの中で、限られたサプライヤーのなかでしか仕事をしてこなかったバイヤーがいかに多かったかの証左ともいえる。しかし開発購買とは、新たな外部リソースの発掘である。バイヤーがやらずして誰がおこなうのだろうか。
