delirious thoughts

by Kentaro Kuribayashi

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

この記事は、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年を参照のこと

2014年11月に読んだ本をブクログでふりかえる

今月は30冊。雑多ながら、わりとたくさん読んだ感じがする。

先月から引き続きコンサルブームだったので、『マッキンゼー』が面白かった。単純にコンサル業界の話というよりは、アメリカ経営史のひと幕として。その流れもありつつ、証券論や会計史に関する本もいくつか。『会計の時代だ!』は、簡便に会計の歴史を教えてくれる。会計期間の公準や発生基準という考え方がなぜ生まれてきたのかといったあたり、並行して読んでいた『証券論』と議論が重なって理解が深まった。また、『バランスシートで読みとく世界経済史』は、簿記から見た会計史を、面白エピソード満載で楽しく読ませてくれる。

その他、ふだんあんまり読まない系の本としては、『Fuzoku実践入門』『すべてはモテるためである』『なぜあなたは「愛してくれない人」を好きになるのか』の3冊が、どれもとてもよかった。『Fuzoku〜』は、その表紙でわかるひとにはわかるだろう某シリーズのパロディ的体裁だが、文章も論述もしっかりしていて、普通に勉強になる。二村ヒトシさんの本は、読もうと思いつつ機会を捉え残っていたのをようやく読んだ。何も知らない人がタイトルだけ見たらアレな感じだろうけど、とにかく読めばわかる、よい本でした。

仕事の調べ物とか、興味の流れであれこれ読んでしまうのだけど、今年も残すとこあとひと月なので、読みさしていたいくつかの大著をまとめて読みきらないとなあ。

kentaroの本棚 - 2014年11月 (30作品)
powered by booklog

「ペパランチョン」の記事掲載および「ペパボのフロントエンドスタンダード」リリースのお知らせ

勤務先関連で、僕が少し関わった物件がふたつほど世に出ていたのでお知らせいたします。

まずは、ペパボにおけるフロントエンド開発のスタンダードを述べる文書。

フロントエンドまわりの動きについては、いまさらあらためて述べるまでもない活況ぶりで、我々としてもよりよいサービス開発のために、こうしたものが必要かなと思って、有志により作成しました(僕はごく初期にフレームを示したぐらいしかしていませんが……)。

いろいろと不足もあるかと思いますが、インターネットのみなさんのお力もお借りしつつ、よりよいものにできていけるとよいのかなと思ったりしてます。

もうひとつは、ちょっと前に始めたペパランチョン | 採用情報 | GMOペパボ株式会社という施策について、マイナビさんにご紹介いただいた記事。

けっこう面白い試みだと思いますし、転職を考えられているみなさまにとってよい機会だと思いますので、ぜひご連絡いただければと思います。

Kindle Voyageを購入した

今日発売のKindle Voyageが早速届いた。

Kindle Voyage届いた

Kindleは、Fire初代 → Touch → Paperwhite初代と使ってきて、いまは

で読んでいる。なぜ分けているかというと、アカウント統合がうまくいかなかったからというのと、jpで買うのは漫画もあるのでという理由。今回Voyageを買ったので、jpについても書籍はVoyageで読むことにする。

で、早速空き時間に数十分ほど本を読んでみたのだけど、Paperwhiteとくらべて2倍ぐらい高いけど、なんでそんな高いのかはよくわからなかった。

  • Paperwhite初代に比べると反応はやいのはいい
  • ページ送りのハードウェアボタン(?)は悪くはないけど、なくても困らない
  • 他なんかいいところあるの?

という感じで、本しか読まないなら現行モデルのPaperwhite買うほうがいいように思う(2倍近くの金額出しても読書体験を向上させたい!というならVoyageがいいと思うけど)。僕が気付いてないだけで、他になんかいいことあるんですかね……。解像度が高いので、漫画読むにはいいだろうけど、上述の通り、漫画はiPadで読むつもりなので、自分的には関係ないかなあ。

以上、ファーストインプレッションでした。

追記

上記だけだと、Voyage買う必要なし、みたいに読めるかもなので追記。2倍近く価格差があるわけだけど、それに見合うほどすごいかというとそうでもないように思えるというだけで、1万程度の違いとかどうでもいいからいいものがほしい、ということならば、十分買いだと思う。実際、使ってみるとPaperwhiteよりいいのは明白だし、僕は本を暇さえあれば読んでいるので、読書体験を最適化するためなら価格差は気にならない(だからすぐに買ったわけだし)。

Kindle Voyage Wi-Fi、キャンペーン情報つきモデル

Kindle Voyage Wi-Fi、キャンペーン情報つきモデル

Kindle Paperwhite

Kindle Paperwhite

老害について

老害とは、ある集団の中で相対的に年齢や立場が上位にある者が、経験に基づく判断にのみ過度な信を置くことにより発生する弊害のことです。わかりやすくいうと、年齢を重ねることにより頭が悪くなって、抽象的・論理的思考ができなくなり、経験的にしか物事を判断できなくなってしまうということです。

具体的にそれは、純粋なスペック的な意味での能力だとか頭のよさ、瞬発力、発想の柔軟さ、考えの実直さなど、若いひとが主に持つ特質に敬意を払えないという症状として現れます。そこで勝負すると必ず負けるという無意識による、防衛反応です。

経験は、よい判断にとって重要なことではあります。しかしそれは、どんなひとでも、ただ生きているだけで増えていきます。もちろん、その量や質にそのひとの人生が反映されるわけですが、ま、ひとひとりの人生なんてたいしたものではありません。

また、経験に基づく判断は、反証不可能です。正確には、経験に基づく判断が、反証可能な形で示されることはありません。そのような判断に対しては、受け入れるか拒絶するかのどちらかを採るしかなく、議論によって判断を深めることができません。

なぜ老害という現象が起こるのでしょう。一般に、ひとは年齢を重ねると、

  1. 脳のスペック的な意味での思考力が衰える
  2. 社会的責任が増えてくるので、判断速度をあげなければならなくなる

1については、これはもうしかたがないことです。ただひとは、年齢を重ねて脳が弱くなるのを、経験に基づく直感によって補う。それが歳をとることのよさでもあるし、成長ともいうのでしょう。

また、年齢を重ね、関わるひとや物事が増えるとともに責任が増え、年々判断すべきことも増えていきます。そうすると、ひとつのことに対してじっくり取り組んで、熟慮を重ねるというのも難しくなってきます。経験に基づく直感によって、判断速度をあげなければなりません。

そのようなこともあって、ひとは老害へと傾いていくわけです。そしてそれは、単に悪いことであるとばかりはいえません。それはそれで、年齢を重ねるという変化への対応であるわけです。ただ、だからといって考えるのをやめ、経験的判断のみに頼るのは単なる退廃です。

どうすれば老害に陥ることを防げるのでしょうか。たとえば以下のような取り組みが役立つかもしれません。

  1. 経験的判断を、議論可能な要素に分解する。言語化する。
  2. 他者の経験・思考に興味を持つ。触れる
  3. 常に苦手な分野に取り組み、克服する。

1について、先述の通り、経験に基づく直感的な判断には、速度の面でメリットもあるわけです。なので、それを反証不可能な形でしか提示できないことに問題があります。よりよい判断のために、それをできるだけ分解し、言語化することで、他者にとっても役立つものになるし、思考の訓練にもなるでしょう。

ひとは誰しも、自分の経験や直覚に大いに信を置くものです。それらがそのひとを形作ってきたのだから、当然のことではあります。しかしそれが、年齢を重ねたからこその他者を容れる懐の深さにつながらないなら、単なる硬直です。小説や哲学、ドキュメンタリ、数学などに親しみ、他者の、直感の及ばない経験・思考に触れることで、寛容さを養いたいところです。

最後に、経験を積み重ね、得意なものをより得意にすることで自己の強みとすることは、それはそれで重要ではありますが、安易なことでもあります。常に苦手分野に取り組み、自らが最弱となる場所(物理的なそれに限らず)を探し、克服を図ることこそが、老害予防の最たるものではないでしょうか。

2014年10月に読んだ本をブクログでふりかえる

今月は39冊。『GUNSLINGER GIRL』を大人買いして全巻読んだりしてたので、数字としては多く見える。

アメリカの人々によるIT系のノンフィクション3冊『ゼロ・トゥ・ワン』『How Google Works』『フラッシュ・ボーイズ』(これをIT系というのはちょっと違うかもしれないが、僕的には技術的な側面に興味を惹かれるのでそういう感じ)は、どれもそれぞれに評判に違わない面白さ。ピーター・ティールのガチなリバタリアンとしての面からくる「競争を避けるためには?」という発想は、表面的にはリンスタDISに見えるものだが、深みが違う。

最近読まなくなってしまった系の本でいうと、『岸信介の回想』あたりが久々のそれ系ジャンル。戦後の政治の世界よりも、戦間期を商工省の官僚から商務次官、大臣にまで登りつめたあたりの話に、岸に対する興味があるのだけれども、回想だとなかなかやったことの具体的内容まではわからない。しかし、この頃の政治家の鷹揚な話しぶりは面白い。

kentaroの本棚 - 2014年10月 (39作品)
短夜明かし
佐々木中
読了日:10月07日
評価3

powered by booklog

エンジニア/エンジニアリングのビッグピクチャ

社外のある技術者たちと「会社のエンジニア、あるいは、エンジニアリングがどうなっていくべきかというビッグピクチャみたいなものがあるか?」という話になった。その場ではいろいろな内容が出てきたわけだが、不詳わたくし、技術責任者という役職を務めている者としてどう思うかというと、そんなにかっこいいことを考えているわけではなかったりする。実際にかねがねいっていることがあるとすれば:

  • 変化に対応できるよう、エンジニアとして成長しつづけよう
  • 他のひとにない、何か自分が一番の得意分野を作ろう

というぐらいである。このフレーズだけでいえば、なんのことはない、いってみれば当たり前、というか、誰でも思いつくような話だ。しかし、ことはそう簡単ではないと思っている。

ひとくちに「成長」といったところで、どれぐらい成長すればいいのかという問題がある。一番わかりやすい基準は、我々は上場企業であるということからいうと、市場の期待成長率を上回ることである。その上で、個々のエンジニアとしての能力の総和としての組織能力が、事業としての成長にどれぐらい寄与するかという問題もある。つまり、エンジニアリングに関する組織能力を業績に変換する際の歩留まりがどれだけあるかという問題だ*1

以上をまとめると、我々は以下の不等式を満たす必要がある*2:

エンジニアリングに関する成長率 × 歩留まり > 市場の期待成長率

歩留まりに関しては、開発プロセスの改善や、そもそも、ビジネスの構想・実行の精度によるが、これは直接にはエンジニアリングにおける成長の問題ではないので、ここでは議論しない(興味がある向きは、開発プロセスという面において我々が書いたWEB+DB PRESS Vol.78を読んでいただきたい)。その歩留まりをかけてなお市場の期待成長率を上回るというのが、上記にいう「成長」の意味するところである。

その「市場の期待成長率」がどれぐらいかというのを公開情報に基いてここで計算してもよいが、それはそれでいろいろ問題があり得るので止す。「エンジニアリングに関する成長率 × 歩留まり」がそれを上回るにはどれほどの「成長」が必要かは、少し考えただけでもそれなりの努力を要することは想像できるだろう。

という前置きをした上で、適当な数字を当てはめて考えてみる。上記の式を変形すると:

エンジニアリングに関する成長率 > 市場の期待成長率/歩留まり

その上で、以下のような前提があるとする:

  • 歩留まり: 50%
  • 期待成長率: 20%(しつこいですが、あくまでも例です)

これを上記の式にあてはめると:

エンジニアリングに関する成長率 > 20%/50% = 40%

となる。「変化に対応できるよう、エンジニアとして成長しつづけよう」というフレーズには、そのような含意が込められている。エンジニアのひとりひとりの問題として、自分の能力が前年比で140%になっていると自信を持って述べるのはなかなか難しいことだろう。「成長しつづけよう」というのは、体裁の良いキャッチーな「ビッグピクチャ」には見えないかもしれないが、それなりにチャレンジングな課題であると思う。

*1:「歩留まり」というと、1以下を取るイメージだが、実際には1以上、すなわち組織能力をスケールさせることもあろう。いい言葉を思いつかなかったので、とりあえずこの言葉を用いている。

*2:他に職種がたくさんあるのにエンジニアリングのみが成長率に寄与するかのような前提はかなり乱暴ではあるが、乱暴なぐらい高い目標は、それはそれで文脈上よかろうとは思う。