Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

組織能力を圧倒的に成長させること

マネジメント

この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。

ここ半年ほど考えていることを、以下に述べる。

技術とは何か？

「技術とは何か？」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1。

すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。

(中略)

誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。

ここでいわれているのはふたつ:

  1. 「その結果として生まれてくる製品やサービス」というのは、単なる変換結果ではなく、インプットに対して「付加価値」を加えたものであるということ(そうでなければ買われない)
  2. そして、その「技術的変換」は、企業を成すことなく行うには難しい程度には困難であること

1)を図示すると、以下のようになる*2。

インプットを元に、企業が付加価値を加えてアウトプットする。それが「技術」である。しかし、1)を満たしさえすればそれが「企業にとって」有意味な技術足りうるかといえばそうではないというのが 2)のいわんとするところである。

延岡健太郎『MOT[技術経営]入門』*3は、その付加価値創造のプロセスを「価値創造」と「価値獲得」とのふたつに分けたうえで*4、日本企業は前者には長けてきたが、近年は、後者において困難に際していると述べる。

とすれば、冒頭の「技術とは何か？」の回答としては、ここではひとまず「企業が、インプットを、付加価値を加えたアウトプットに変換し、市場からその対価を獲得するのに必要な能力」ぐらいの意味ととらえておけばよかろう。

組織能力

価値を創造した上で、それを企業にとっての価値 = 事業価値としての「価値獲得」に結びつけるためには、それが顧客にとっての「付加価値」となる必要がある。すなわち、単に何かを作るだけではなく、競合との争いに打ち勝ち、顧客にとって真に望まれる価値を「付加価値」というわけである*5。

その事業価値をどのようにして作り出していけばよいのか。上図に示した通り、以下のふたつがあり得る。

  1. 差別化・独自性・オンリーワン
  2. 戦略・儲けの仕組み

いずれにせよ、3Cの関係において、自らを他とは違う存在として市場にアピールできるかどうかにかかってくるということだ。その時、どのように「違い」を示すかといえば、その方法として、大きくふたつがある。

  • 商品による差別化
  • 組織能力による差別化

いずれも重要であることは間違いないが、こと商品による差別化には困難がある。それが目に見えるものであることから模倣が容易であるため、長期にわたって企業を支え続けるのは難しい。そこで「見えざる資産」(伊丹敬之)であればこそ、他社の模倣が難しく、長期的な優位性をもたらす「組織能力」の向上が重要となってくるわけだ。

では、その「組織能力」とはなんであるか*6。

「組織能力」とは、企業が固有に持つ有形無形の資源と、それを活用する能力やプロセスである。このような能力は、通常組織が長年の試行錯誤を繰り返した結果、企業内に蓄積される。

具体的には、「技術的資源」(特許、データ、実験機器、製造機器など)や「人的資源」(個人の知識やノウハウなど)、およびそれらの資源を統合して効果的・効率的に活用するための組織プロセス(よい意味での「組織ルーチン」)として、蓄積される。

そのような過程で蓄積される組織能力は、特定組織に固有のものであり、暗黙的であったり属人的で あったりするので、他の企業が真似をしようとしても難しいし、市場で購入することもできない。

Webサービス企業の組織能力

技術の定義において見てきた「インプット」とは、Webサービス企業においては、「ヒト」が多くを占める。その人々により組織された企業が、顧客に対して「付加価値」をもたらすであろうサービスを提供することに、数多の競合としのぎを削っているわけだ。

そのような「ヒト」が重要な位置を占め、また、参入障壁の低いWebサービス企業においては、その名が示す通り、いかに付加価値をもたらす「サービス」を提供できるかが重要である。すなわち、一般に想像されるような、いわゆるプログラミング技術などのようなものが、必ずしもコアコンピタンスであるというわけでは、必ずしもない。例を示そう。

あるビジネススクールのケーススタディ*7は、クックパッドのコアコンピタンスとして、第一に以下のように述べている。

  • 市販のソフトやツールを使わず、全てのシステムを自前の技術で開発し、徹底的に検証 し改善を図っている。これは、Google と同じ発想である。
  • レスポンスタイムに対する徹底的なこだわりを持っている。具体的には、20 ミリ sec 以下(引用者註: 200msecの誤りであると思われる。)のレスポンス保証、16 時前後の圧倒的ピークにおいてもレスポンス低下させない 仕組みなどである。
  • その他として、以下のような技術について特筆すべき点が挙げられる。
    • アクセスログを解析する独自技術の確立&開発
    • 独自技術の追求の結果、2008(平成 20)年より Ruby 言語の全面採用
    • 徹底したユーザインタフェース(UI)へのこだわり

上記に示されるクックパッドの技術に高いものがあるのは、この業界にいれば誰もが知っていることではあろう。しかし、それに反して、中の人はこのように語っている*8。

『クックパッド』だと、技術ってコアコンピタンスじゃないんだよね。事業を成長させるという観点から見ると、新しい価値をつくっていくのは、新規事業やサービス開発とかの企画サイドだったりするわけで。

すなわち、主に「ヒト」という入力をもって、顧客にとって価値のある「サービス」や「事業」を提供するに際して、狭義の意味における「技術」とは、「組織能力」の一部に過ぎないことが述べられる。もちろん、それは付け足しで済むものではなく、重要な一部であるにしても、クックパッドほどの技術をもってしてなお、そのように語られることの意味は重い。

技術と組織

とはいえ、Webサービス企業が、ソフトウェアという純粋に技術的産物によってサービスを提供するという業態である以上、そのサービスを提供するプロセスにおいて、比重の多くを狭義の「技術」が占めるのは確かなのであってみれば、「技術」に関する組織能力を高めていく必要があるのはいうまでもない。

そのため、当社であれば「技術基盤チーム」のような横串の組織を導入し、コアコンピタンスとしてのサービス提供能力や、これまでの蓄積をより効率的に付加価値へ変換するために、狭義の意味における「技術」の下支えを行っているわけだ。そして、その重要性について適切に経営へ反映するために、幹部社員としての技術責任者*9という役職を設置している。

また、組織能力を高めるという観点からは、このブログでも縷々示してきた以下のような制度が挙げられる。

このような、組織に関する制度により、直接的に能力の向上を図るという取組みは、どのような会社も大なり小なり行っているだろうし、その事例も昨今では多く公表されている*10。

組織能力のトップラインを上げる

それらはいまも変わらず重要なことだが、ここで新たに述べたいのは、もっと別のことである。すなわち、エンジニア/エンジニアリングのビッグピクチャで述べたような、単に狭義の「技術」のみでない、組織能力という意味においての「技術」のトップラインを上げることについてである。

上述のエントリにおいては、エンジニア個々人の能力のトップラインを、市場の期待成長率になぞらえてみたが、他にもいろいろな観点があり得るだろう。より大きな成長を見据えるならば「100倍で考える」*11ということでもよいだろう*12。

そのためには何が必要か。技術的な能力を上下左右に大きく広げる必要があると考える。上下左右とはすなわち:

  • 上下: いまできることを、さらに大規模にできるようになる。あるいは、さらに深掘りしてより本質的な技術を極める
  • 左右: いまもっていない知見・能力を獲得するべく、幅を広げる

たとえば上方向の意味においては、僕自身の例を挙げてみよう。先述の通り、「技術責任者」という役職を担っているからには、自分自身の技術的限界が、会社の技術的成長において制限となり得る。もちろん、個別の「技術」において僕より優秀なひとはいくらでもいるが、役職というのは、反面ではそのような制限をもたらし得るものだ。

そのような制限のために、たとえ上述したような制度的仕組みを策定し、うまく回せたとしても、能力の不足によって長期的な構想に基づく大規模なプロジェクトを企画・実施できないようなことになれば、なんのための役職かということになってしまう。その意味において、僕はいまでも自己の能力を大いに向上させることに余念がないし、実際に、「主に技術を用いた問題解決能力」という意味における「技術力」の成長率は、他のエンジニアたちにひけを取らないと考えている。

左右方向でいえば、先般公表した「ペパボのフロントエンドスタンダード」という取り組みが挙げられるだろう。これは、ますます複雑化・高度化する技術環境の変化に、我々が必ずしもキャッチアップできていないかもしれないという、強い危機感のもとに始まったプロジェクトだ。そういうジャンルは他にもいくつかあるが、まずはこうした取組みによって、不確実な将来に対してよりよく立ち向かえるための基礎作りを行うことが、組織能力のトップラインを上げるということだと考える。

まとめ

Webサービス企業は、競合とのせめぎ合いの中で、いかに顧客にとって「付加価値」となるアウトプットをもたらすかという戦いのただ中にある(3C)。その際に拠り所となるのが組織能力だが、これは単に狭義の「技術」のみからなるものではない。そうはいっても、技術が組織能力の枢要を占めることは確かであるのだから、それを飛躍的に向上させるには、成長への強い決意を持って組織全体を引っ張っていく必要がある。

ゼミナール 経営学入門 ゼミナールシリーズ

ゼミナール 経営学入門 ゼミナールシリーズ

MOT“技術経営”入門 (マネジメント・テキスト)

MOT“技術経営”入門 (マネジメント・テキスト)

技術を武器にする経営 日本企業に必要なMOTとは何か

技術を武器にする経営 日本企業に必要なMOTとは何か

How Google Works

How Google Works

*1:伊丹敬之・加護野忠男『ゼミナール経営学入門 第3版』日本経済新聞社、2013年、pp.1-2

*2:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.21より筆者作成

*3:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年

*4:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.33より筆者作成

*5:このような見方を、競合(competitor)・顧客(customer)・自社(company)の3つの頭文字をとって、3Cと呼ぶ。

*6:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.50

*7:「事例研究 クックパッド株式会社」http://www.wbc.ac.jp/pdf/h25jigyou/p2-3-6.pdf

*8:「【後編】 元・超ワガママエンジニアのクックパッドCTOと語る、「CTOって何する人だ？」論 / 飲み会で探るエンジニアのホンネ #naoya_sushi 編」http://tenshoku.mynavi.jp/it-engineer/knowhow/naoya_sushi/02

*9:「GMOペパボ株式会社の技術責任者に就任いたしました」http://blog.kentarok.org/entry/2014/08/01/150159

*10:直近の例では、「エンジニアの評価観点について」https://gist.github.com/katzchang/52eb6c8520f2fd4a1025、「エンジニアのキャリアパスと役職定義」http://tech.gmo-media.jp/post/104968432114/careerpath2014

*11:「100倍で考える | Preferred Research」http://research.preferred.jp/2014/10/100x/

*12:しかし我々は、Google的な「スマートクリエイティブだけ採用してればいいじゃん！」的エリーティズムを、その魅力を認めつつも、採ることはしない。「スマートクリエイティブ」に関しては、エリック・シュミット + ジョナサン・ローゼンバーグ『How Google Works』日本経済新聞社、2014年を参照のこと