Pushで標準化し、Pullで差別化する

包丁で食材を切るとき、わたしは押して切るくせがある。しかし料理番組を見ても、身近な人を見ても、ふつうは包丁を引きながら切るようだ。ちなみに、自分が料理を覚えたのは、3ヶ月ほどアメリカの留学生寮に一人で住んでいたときだった。アメリカ人は、押して切る人が多い。別にそれを見て真似たつもりは全然ないのだが・・でも、日本とアメリカとでは、ちょっとした道具の使い方が正反対なことが意外だった。ノコギリや鉋などでも、日本と西洋では方向が反対である。日本は引いて切るのに、彼らは押して切る。

そのことから、「米国はPush型、日本はPull型だ」などと陳腐な比較文化論を述べるつもりはない。だが、それにしても、セールスのあり方などで日米はずいぶん違うな、と感じることはある。アメリカ人のセールスは、やはりPush〔押し)が基本である。来日した米国の大手ベンダーのシニア・マネジメントなどと話していると、「我が社の製品はこれほどの市場シェアを持っており、TOP 500企業の内、あの会社もこの会社も使って満足している。」という自信満々の話が続き、「だからお前も、買うのが当然だ」みたいな雰囲気になってくる。余計なお世話だろ、と思うが、こちらが「よく考えさせてくれ」と婉曲話法で言っても、「じゃあ、よく考えてくれ。きっと、導入すべきという結論になるはずだ。」と、こちらの心中を意に介さず、どんどん話を進めてしまう。まあ、そういうビジネス文化なのであろう。

ところで、わが同胞の技術者や営業マンたちはどうか--いや、そんな第三者目線で語るのはやめよう。自分自身はどうなのか? ちょうどその逆である。ちょっと弱気な笑顔で受け答えし、顧客の強引とも思える要求にも、あまりNOと言わない。「NOと言えない日本人」の典型かもしれぬ。ただ、多少弁解するならば、海外ビジネスの現場で行き会う同胞たちも、それほど違うようには見えない。わたし達は、よほど「お客様本位」あるいは「ご無理ごもっとも」のスタンスが骨がらみなのだろうか。まあ、その昔、日本が輸出産業花盛りで「電子立国ニッポン」などと自信満々だった時代には、もっと違っていたのかもしれない。だが、受注ビジネスが取引の主流になりつつある現在、建設業であれ、機械系インフラ輸出であれ、はたまた通信システムであれ、なんだか皆さんずいぶんPull〔受け身〕に見える。

もちろん海外ビジネスの場合、言語の壁や文化の障壁などがあって、あまり自信を持ちにくい点はある。しかし、では、ひるがえって国内ビジネスの現場ではどうか。建設、産業機械、物流、SIなど、いわゆる受注産業の人々は、やはりけっこうPull型スタンスが多いように思われれる。

受け身といっても、消極的という意味では、必ずしもない。顧客の出してくるいろいろな高度な要求を、どう技術的に実現するか、との観点で考えているエンジニアは多いはずだ。そこには無論、チャレンジもある。難しい仕様を、きちんと実装できる能力は当然、高く評価されるべきだ。ただ、技術面ではそれで良いとしても、受注価格や納期や契約条件といった、いわゆるコマーシャルな営業条件まで、相手の言いなりでずるずる土俵際まで引いてしまうようだと、ビジネス全体としてはかなりつらいことになる。

いや、技術面でも、Pull型の態度には一つ問題がある。わたしがしばしばそれを感じるのは、たとえばITエンジニアのスタンスがPull型すぎることだ。受託開発のSIer、社内の情報システム部門、いずれの場合も「ユーザからの要求仕様」をどう実現しようかと、必死に知恵を絞る。だが、逆にユーザに対し「こういう機能があるから、こう業務をかえてみたらどうですか」という提案能力をこそ、実はユーザ側も望んでいるのではないか。提案というのは、まさしくPush型の態度である。

自分の経験も、ひとつ書いておこう。エンジニアリング会社につとめているが、もう随分前、わたしがはじめてキーパーソンとして顧客向けの仕事をしたとき、それは新工場建設を前提とした情報系の構築だった。設計フェーズで客先と打合せた際、例によってNOとうまく言えなかったわたしは、新しい追加要望をひきうけて会社に戻った。上司に怒られるだろうな、とは予期していたし、事実叱られたが、叱られる理由は、工数が増えたとか納期が厳しくなった、といったことではなかった。「言われたことを何でも引き受けるな。お前には設計のスタンスというものがないのか!」といって怒られたのだ。

スタンスと言ったって、機能モジュールの構成やDB構造などは、ある意味こちらが勝手に設計したことではないか。それが崩れるからと入って、顧客にNOといえるのか。当時のわたしは、怒られた理由がよく分からなかった。

ここで再び米国のIT企業人の態度を思い起こそう。いささか居丈高だが、ともかく「あなた方ユーザはこうすべきです」という主張に満ちあふれている。それを『ベスト・プラクティス』です、などと売りつける豪腕さも持っている。だから、彼らはパッケージ・ソフトの開発に強い。また米国企業はパッケージ・ソフトの普及も早い。OSやOfficeソフトなどにパッケージを使うのは当然として、いわゆる業務系システムなどにも、かなりパッケージが売られている。パッケージ・ソフトはまさに「Push型」の文化が生み出した製品と言えよう。そして、多少業務に合わないところがあっても、パッケージに業務を合わせる形で使いこなしていく。

ところが、わたしの知る限り、日本ではERPパッケージなどでも、アドオンとカスタマイズがてんこ盛り、というのが普通の事情である。そりゃまあ、伝票の1行を入力するのに数画面を行き来しなければならないようなパッケージは、何か一工夫したくなるのも道理ではある。また、長期手形決済だとか販売完了後の値引きだとか、西洋ではあまり見かけない商慣習を実装する必要も、たしかにあっただろう。しかし、それだけでなく、各ユーザ部門の固有で独特の要求事項、例外処理などもかなり盛り込んで、膨れあがった事例も多いはずだ。そして、それ以上に多いのは、「やはりパッケージはウチの業務には合わないから」ゼロから自社開発するケースではなかったか。個別開発は、まさにPull型スタンスの極致と言うべきだろう。

誤解しないでほしい。わたしはなにも、パッケージ・ソフトが素晴らしくて自社開発がダメだなどと主張しているのではない。米国が何でも良くて、日本は何でも遅れている、などと主張したいのでもない。米国製のパッケージの低品質には、正直、何度も煮え湯を飲まされた。じっさい米国人は、バグはユーザが見つけるべきものだ、と思っている節がある(笑)。以前、JUASの統計を紹介したが、日本のソフトウェアは、見かけは格好良くなくても、とにかくバグは段違いに少ない。

ただ、これはある米国のIT企業の副社長から面と向かって言われたことだが、「ITエンジニアは基本的に自分で作るのが好き」なのである。だから、(予算が許す限り)自分で作りたい。パッケージを買ってきて箱から出すだけ、では仕事をしたという気持ちになれない、のだろう。こうして自社開発や委託開発が増えていくわけだが、当然その行く先は見えている。ユーザ要件に対して、基本的にNOは言わないのだから、システムは膨れるに決まっている。運用も修正改善もどんどん負担は増えるばかり。かくして、高額のIT予算にいきり立ったトップから、ある日ばっさりと切って捨てられることになりかねない。仕事が好きなるが故に、一生懸命努力した結果、自分の仕事の土台を失う結果をもたらすのである。

では、パッケージで、ソフトに仕事を合わせる(Push型)べきなのか、作り込みで、仕事にソフトを合わせる(Pull型)べきなのか。ここまでの書きぶりでお分かりだろうが、わたしはどちらかが正解で他方は間違いだ、という風には考えていない。使い分けなのである。だが、賢い使い分けとはどういうものか?

わたしが学んだ答えは、とても単純である。もし、ある業務が、業界内で共通な仕事、あるいは業界を超えてどこでもほぼ共通な仕事なら、パッケージを利用して標準化すべきである。その方が当然コストが安くなる。たとえば今さら誰もワープロを自社開発しないのは、文書作成がどんな組織でも殆ど共通の作業だからである。

他方、ある業務が、他社にない独自なもので、自社の差別化や競争力強化に大きく貢献しているなら、それは自社で作り込むべきである。よそにはない業務なのだから、第一、パッケージ標準機能にあるはずがない。

パッケージ(Push)で標準化し、作り込み(Pull)で差別化する。これは単純な原則で、誰でも落ちついて考えれば、同じ結論になるだろう。「内示でPushし、かんばんでPullする」トヨタ方式と、ちょっとだけ似ている。

しかし、もちろんこの原則があったとしても、社内の論議は簡単には決着しない。なぜなら、「どの仕事が差別化業務か」を見分けるためには、そもそも「自社の強みは何か」を、客観的に知らなければならないからだ。他社と違うことがすべて差別化ではない。自社の強みにつながらないような独自業務は、たんなる「変な習慣」でしかない。「強み」なのか「因習」なのか。それは、当事者にはじつはなかなか分からないものだ。客観的に見分けるられるのは、第三者的なコンサルタントか、あるいは、いろいろな範囲の業務プロセスを見てきたITエンジニアであるはずだ。

だから、提案能力のある、Push型のITエンジニアがもっと必要だとわたしは考えるのである。かつて上司が言った「設計のスタンス」も、その事を指していたのだと、今になるとようやく分かる。もっと若いうちに、理解しておけばよかった。というわけで、せめてこの拙文を読む人には、分かってほしいのだ。そして、ユーザがへんてこな要求をしたら、“それは設計思想に合いません”と、NOと言えるだけの『Push力』を持ってほしいと願うのである。


<関連エントリ>
 →「Pushで計画し、Pullで調整する
 →「ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係

by Tomoichi_Sato | 2014-03-04 22:17 | ビジネス | Comments(0)
<< 『ポジティブなリスク』の正体をさぐる Push vs. Pull -... >>