【連載12】テクノロジー×経営で社会を変える、レクター広木氏が語る事業のソフトウェア化に必要なこととは

f:id:pcads_media:20201021191033j:plain

こんにちは!TECH Street編集部です。
前回、TECH Streetメンバーが気になるヒト、株式会社VOYAGE GROUP取締役CTOの小賀昌法氏にインタビューをしましたが、今回は連載企画「ストリートインタビュー」の第12弾をお届けします。
※本取材はリモートで実施いたしました

「ストリートインタビュー」とは

TECH Streetメンバーが“今、気になるヒト”をリレー形式でつなぐインタビュー企画です。
企画ルール:

・インタビュー対象は必ず次のインタビュー対象を指定していただきます。
・指定するインタビュー対象は以下の2つの条件のうちどちらかを満たしている方です。

f:id:pcads_media:20200629154925p:plain

“今気になるヒト”小賀氏からのバトンを受け取ったのは、株式会社レクター取締役の広木大地氏。

f:id:pcads_media:20201021191102j:plain

広木大地 Daichi Hiroki/株式会社レクター取締役
2008年に株式会社ミクシィに入社。同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社。株式会社レクターを創業。技術経営アドバイザリー。著書『エンジニアリング組織論への招待』がブクログ・ビジネス書大賞、翔泳社技術書大賞受賞。一般社団法人日本CTO協会理事。
※2020年9月16日取材時点の情報です


――ご紹介いただいたVOYAGE GROUP小賀様から「広木さんの知識や経験、バックボーンから学ぶことが非常に多い」と推薦の言葉をいただきました。まずは広木さんのこれまでのご経歴、どういうご経験をされてきて現在に至るか、そのストーリーからお聞かせください。

広木氏:新卒で株式会社ミクシィに入社。当時、上場したばかりのタイミングで、新卒第一期生でしたね。当時、インターネットサービスが世の中を変えていくということに対して、確信めいた強い関心があったので、その中でミクシィという会社を選びました。

その後、長きにわたりミクシィのソフトウェアエンジニアとして、広告商品の開発、コミュニティ機能の開始をしていって、徐々に技術系のスペシャリストとしての道を歩んでいく事になります。

最初のターニングポイントは、CTO直下の部隊に配属となり、生産性の向上や難しい案件、火事場があると独力で解決するという役割が与えられたこと。

様々な炎上プロジェクトの火消し役として経験を重ねる中で、プロジェクトがうまくいったり、いかなかったりするのは、単なる技術的な要素だけではなくて、組織やコミュニケーションといった、人間的要素が多分に含まれているなと感じ取るようになりました。

このチームが大きくなり、マネジメントのキャリアを拝命。技術的な能力だけで解決するわけではない課題に関しても、併せて解決することが必要なのではないかという考えの元、チームのマネジメントに取り組むようになりました。それからほどなく、組織改革や経営の再生をするために、事業側へと私の管掌範囲が広がっていきます。

私にとって、このキャリアは連続的かつ自然なものと捉えています。自らがキャリアを選んだというより、ただ目の前にある課題をきちんと解決しようと思ったら、技術とビジネス、組織の人間関係の話に踏み込んだコミュニケーションをしていく必要がどんどん生じていきました。

その課題解決というテーマが常に私の主眼にはありましたが、周囲の頑張りもあって、ミクシィの経営は上向きになり、ひと段落したところで退職。この自分の経験を世の中に伝えていきたい考え、レクターという会社を起業しました。

レクターは、当時一緒にやっていた松岡と、小賀さんと竹内さんといった、CTO経験者4人で作った会社です。“RECTOR”の真ん中にCTOのスペルが入っています。CTOをリプロダクション(再生産)する。再現性を持ったノウハウとして教えていこうという思いを込め、さらに講師、校長先生という意味を持つレクターにCTOを掛け合わせた社名を冠しました。この会社をフックに、様々な会社の技術と経営の間にある課題に触れていくことになりました。

 

――レクターを立ち上げた際、その背景として、世の中をどうみられどういう課題解決の一つとしてレクターを打ち出していこうと考えられたのか教えてください。

f:id:pcads_media:20201021191134j:plain

広木氏:世の中、今でこそ「DX」という言葉が頻出していますが、創業当時の時代としては、この言葉は普及してはいませんでした。

しかし、この先あっという間にソフトウェアが、すべてを飲み込んでいくであろうと予測していましたし、今後もどんどん加速するでしょう。

今までは、人が人に指示をすることで事業が成立する時代でした。なので、スタッフに適切な指示ができたりマニュアルを作れる人が重宝されてきました。ですが、これからの時代は事業のオペレーションの多くはコンピュータに置き換わっていきます。ですので、人に命令する能力ではなく、コンピューターに命令する能力(プログラミング能力)が重要視される時代になっていくと考えています。

ところが、コンピュータに指示する側の人間(ソフトウェアエンジニア)が、極端に少ない。すなわち、プログラミングをできる人は人口の1%にも達していません。コンピュータはどんどんと安くなってきています。また、少子高齢化で労働者はどんどんと少なくなっていきます。

そのため、コンピュータのほうが労働者よりも圧倒的に調達しやすくなっているという状況です。にもかかわらず、ソフトウェアで問題解決をするCTOやソフトウェアエンジニアが少ないというのは、誰が見ても明らかな社会的課題です。

ところが、多くの経営者が正しくその状況を理解していない現状があります。単にコンピュータがいままでの手作業を減らしてくれる、自動化してくれるといったレベルの発想でしかなく、もっと根本的なところで大きな変化であることに気づいていません。

インターネットを通じて取引コストが減っていくことで、あらゆるビジネスの前提となっていた境界面が変わるというパラダイムシフトです。

例えば、その昔には、家具屋さんは店舗を構えないと販売ができなかったのに、今はECが主流になった。そうなると製造の現場を持って、直接取引できるのであれば、間に入る業者はほとんどなくなっていきます。他のCtoC取引においても、個人がエンパワメントされていく例もあります。こうして中間の取引コストが下がることによって、企業・組織の境界線が変わっていくようなことが、そこかしこで起こっています。

境界線が変わっていく時の経営の改革、変化というのは大きな痛みが伴います。変わろうとしてアクションをとるために、事業のソフトウェア化をしていく事は非常に重要です。

それを経営の立場でコミュニケートして、それを実行できる状態にするのはとても難しいです。それを可能とするのは先端テクノロジーと経営、これからの社会変革をつなげていくようなビジネスと組織の設計ができる人材ということになります。

しかし、現状では非常に少ない人数しかこういった人材はいません。だから、そういった人材をどんどん増やしていかなければなりませんし、そういうことに対して僕らができることが何かあるのではないかと思っています。

 

――今の考えを完全に理解してくれる経営層はそれほど多くはなさそうですが、彼らとの間でコンフリクトが起きたら、どのように突破していくのでしょうか。

f:id:pcads_media:20201021191159j:plain

広木氏:企業自体が持っている“今のままでありたいという力”は、かなり強いものです。それを、いかにして変化を当然のものとして受け入れられるようにしていくか、それが重要です。

変化には失敗が伴いますが、小さな失敗を埋め尽くされて潰されてしまったら、うねりにならないわけです。どうやって文化自体を変えて、失敗が評価され、大きく学びに変えていく力を企業に養わせるかが重要で、そのためには異文化、異なる価値観との交流が必要になります。

しかし、異なる価値観との交流があると、当然、文化の衝突が起こるわけです。その文化衝突は、異なる価値観の中で会話を続けていくと生まれますが、一度の衝突やトラブルで諦めずに何度か混ぜあわせていくと、どこかの時点で急に、両者の価値観を混ぜ合わせた新しい価値観を持つ人たちが生まれ始めます。

少なくとも日本企業の場合、同じ業種の、同じような人たちが組織に集まっていることで、文化衝突やその結果生まれるかもしれないイノベーションは起こりにくくなってしまっています。どの程度まで文化の衝突を許容して新しい価値観を取り入れた人を増やしながら組織に変えていくかというのが、経営のかじ取りの中でかなり重要です。

このようなイノベーションを生むために多様な価値観の中で仕事をしていくことが求められてきている背景には、社会のソフトウェア化が関連しています。どんどんビジネスや世の中がソフトウェア化していくと、単純な部分が機械化していきます。

その結果、個人がおこなう業務の領域は拡大していきます。数十年前のマネジメント層が複数のチームを抱えて行っていたことと同じような役割を今のミドル層が担わないといけないし、さらに数十年後は今の部長職と同じようことを、一個人がやらないといけなくなるという風に、個人ができる範囲が広がることで、意思決定がどんどんダウンサイジングしていくわけです。

そうなると、これまで同質的で単一の職能を持ったチームでの仕事に対して、一つのチームの中にマーケティングのプロフェッショナル、インフラやソフトウェアのプロフェッショナルといった、決して同質でない人たちが集まってきて、ひとつのチームでソフトウェア、商品開発、事業開発をしていくのが当たり前になっていきます。

すると異なる価値観の中でアウトプットを出してコミュニケーションを取っていくことが必須のスキルになっていきます。これまで、そのような機会が相対的に少なかった日本企業では、そういった機会を増やしていくだけで、イノベーションが生まれやすくなるのではないかと思います。

 

――広木さんは常に課題を解決する時に、単純に目の前の課題を解決することだけではなく、もう少し視野が広いような気がしています。課題を解決するためにゴリゴリと技術をやってひたすら行ってしまう人もいる中で、なぜそのような感覚が持てるのでしょうか。

f:id:pcads_media:20201021191345j:plain

広木氏:そうですね。まず、考えられる一つの要素として、三人兄弟の真ん中で生まれ育ったという環境があるかと思います。

姉と親がけんかをして、妹が駄々こねているのを親があやす、そういうのを間で見て育ってきたので、世の中で起きていることをとりあえず見て、少しいい具合に立ち振る舞おうとする習慣が身についたのかもしれません。

もう一つは、仕組みというものに興味があったという性質的な要素です。エンジニアにも、作ることが好きな人と、分解して中身を知ることが好きな人がいるかと思いますが、私は完全に後者。プログラミングにしてもそうですし、社会に対しても同じ目線を持っています。

中学生くらいの時に図書館に引きこもり、社会学や文化人類学や哲学の本ばかり読み漁っていたという時期がありました。世の中の仕組みがどうなっているのか、社会に対してその仕組みの中に手を入れて、流れを少し変えていくことに興味を抱いたというか、新しい社会や仕組みの中に、自分がいる感覚が強かったですね。

“システム”という言葉を聞いたときに、情報処理システムのことを指すのだと思い込んでいる方が多いように思います。システムというものの本来の意味は人間や社会という大きな仕組みの「組み合わせ」を指す言葉です。

たとえば、エコ”システム”という表現がそうであるように複雑に入り組んだフィードバックループ(循環関係)のある仕組みのことがシステムです。そうした仕組みの中で、それらを制御していく事がシステムエンジニアリングだという認識を持っていました。

そういった観点で見た時に、単なる1パーツである情報処理の機構であるソフトウェアを見て、エンジニアリングを語りがちになってしまうけれども、そうではないと考えています。システムとは何か?という語義の部分に立ち戻ってシステムエンジニアリングを考えると、当然のように人間活動が含まれるな、と捉えられるようになりました。

>>次のページへ続く


――ありがとうございます。では、少しお話を変えて広木さん個人のキャリア、エンジニアとして働き方に対するお考えを教えてください。

広木氏:バックキャスティングという考え方をよく使います。“将来、こうなるから、今、こうふるまう方が良い”というような、逆算でキャリアを作っていく考え方です。

将来こうなりたいというイメージもとても低俗に聞こえることでもいいと考えています。多くの人がキャリアの話をするときに、難しい話をしすぎていると感じていて、本音は「お金持ちになりたい」「モテたい」「時間に余裕が欲しい」くらいなものではないですか。少なくとも僕は俗っぽい人間なので、そうでした。

そのためのに自分の本能の中で、ちょうど心地の良いラインを自分で決めて、そこから働き方、キャリアを逆算して考えるようにしています。その逆算に沿って動いていくことができると、思った通りのキャリアが築かれていくわけです。うまくいくことばかりではないけど、僕の個人的なキャリアの考え方です。

ずっとその目標に固執しているわけではありません。立派なキャリア展望を持つのは良いのですが、世の中が変化しているのに、まったく変わらないようなキャリア展望は自縄自縛で辛いものですから。この先、どうなるかわかりませんからね。

つまり、逆算でもキャリア・目標を建てる理由は「今の自分のアクションが変わるから」です。もし、高い目標を持ったら、読む本が変わり、インプットしている内容も変わります。そこを考えずにキャリア展望だけ作りなさいと言われれば、それは今の延長線上なので、持っても持たなくても変わりません。

見えるものが変わるようなところに自分を置けば、必然とインプットが変わるので、習慣も変わり、行動も変わるはずだと考えています。

 

――広木さん個人はどうでしょうか。

f:id:pcads_media:20201021191724j:plain

広木氏:僕個人は「ある程度もっているけど変わっていく」というのが自然なことだと受け入れています。

必ず“そうならないといけない”というような強迫観念はなくて、基本、“楽しく生きていたい”というのがまずあります。私が楽しいと思うのは、目の前に適度な量の難しい問題がやってきて、面白いことができる、これが続く状態というのが好ましいです。ゲームと同じですね。ただ同じことをやっていると飽きるので、どんどん、その問題が難しくなっていってほしいわけです。

チームがあって、組織があって、企業があって、いま様々な企業を見ているといったときに、次に良くしたいものは何かと聞かれたら社会だと答えます。なので、自分としては自分の趣味の範疇にあるような課題をどんどん大きくしていければよいと思っています。

最初から、こんなに世界を変えたいとは思っていなかったけれども、自分の周囲の社会が大きく変わっていってほしいし、そのために何ができるのか、周囲の人たちがよりhappyになるためにはどうしたらよいかを考え、実現していくのが楽しいし、それを続けていきたいですね。

 

――組織づくりに対して、どういったこだわりやお考えをもっているのでしょうか。エンジニア組織をどのようにつくってきたのか、そのあたりの基本的な考え方を教えてください。

広木氏:ソフトウェアづくりって一般的には理数系の頭を使う活動だと思われているのではないでしょうか。もちろん、それも使うのですが、もう一面ではプログラミング言語という文章を書いているわけです。

この書いた文章であるコードは非常に明晰で機械がなもので、そこに関わっている人の認識が一致しないと作りあげられないという性質ものものです。なので、結構人文的な頭もコミュニケーションのためのEQも使う、知の総合格闘技的なものだと思っています。

ソフトウェアは作りたいと思っている時は曖昧な状態で、できあがった時には厳密なものになっていて認識が一致している。これがソフトウェアプロジェクトの基本であり原理だと思います。言い換えるならば作業を分担しながら、認識が一致するように精緻化していくという過程です。

しかしながら、ソフトウェアの初学者は、このような認識を持ち合わせていません。コミュニケーションの認識を一致させることや、厳密化させることに対するコストを支払わないでいるため、結果的に最終工程で認識の不一致が生じたり、できあがったものにバグが多く潜んでいたりしてしまいます。

ソフトウェアを作るということは厳密化しながら認識を一致させていくプロセスだと捉えながらプロジェクトマネジメントしていくことが必要で、そういった意味でもアジャイルなどのプロセスは、その本質を捉えていると思っています。

私はコミュニケーションを大事にするし、実際に作ってもらったものをみてもらうことを非常に大事にします。こういったアクションは、認識が一致していない曖昧な部分を突き詰めながらやっていくので、精神的に辛いのですが、きちんとプロジェクトは回るようになります。それは企業においても同様です。

 

――今後の日本企業がIT化、ソフトウェア化されて行くという中で、御社のようにCTO的な知見を世の中に根付かせていくことで日本企業が変わっていくということは分かりました。そういった流れを作っていくと理解したうえで、では企業はどういう勝ち方をすべきなのでしょうか。

f:id:pcads_media:20201021191602j:plain

広木氏:いかに小さく失敗するかということに対して、どれだけのエネルギーを割けるかということだと思います。

IT企業にとって重要なのは、トライアンドエラーを繰り返しながら、様々なイノベーションの仮説検証をしていくことです。その速度が速く、失敗から学ぶスピードが早ければ早いほどチャンスが生まれます。

たまたま勝つこともありますし、戦略が良くて必然的に勝つこともありますが、俯瞰で見た時に再現性をもって、いくつも事業を展開しながら、いくつもポートフォリオを組んでいくためには、やはりイノベーションを維持することが非常に重要です。

イノベーションを維持するためには、失敗体験がたくさんできるような企業にしていくことだと思っていて、若いうちに権限がこない、失敗する機会がないようではいけません。失敗は学びになるのに、何がなんでも成功させないと駄目で、そのために圧力をかけて、少しでも失敗したら出向だという半沢直樹的な世界観を持っているようでは駄目ですよね(笑)。

一番手っ取り早いのは、失敗できそうな環境を作ることですよね。社会的責任を負っているので失敗することができないというのはわかります。でも、失敗しないようにするために、細分化が進み、全体感がみられなくなって大失敗するというのはよくある話です。

小さく失敗ができて、隠蔽せずに誰かが失敗に気が付いたら、気が付いたところから失敗の改善ができる、改善のアクションが取れるだけでいくらでも修正できることを理解する。

また、自分の仕事に対して顧客の見えないところ、会社の中でだけ仕事をしてしまうと面白くないので、顧客と近い所に接点を持ち失敗できる環境を作るという事が一つのセオリーだと思います。私も小さな失敗をたくさん重ねてきました。そのくらいは恥ずかしくないよねと思った方が良いですよね。

 

――「withコロナ」というキーワードがあります。その中でエンジニアの方々も二極化しているようで、リモートの環境で働けると自信を持っている方と、その半面で不安を抱いている方がいらっしゃいます。広木さんが考える、エンジニア的withコロナの働き方をご提言いただけたらと思います。

広木氏:これは、コロナ禍やリモートでなくてもそうですが、大きな変化があれば、慣れていないので不安にもなるし、失敗することも当然だと思います。過去を振り返ってみても、大きく環境が変化することは多々あって、私たちの時代ならクラウドが登場してきたときに、オンプレミスにこだわる人がたくさんいました。

新しいフレームワークができて、今までとは違う方向に乗ったとか、違う言語を使うとか、そういう時代の変化がある中、今まで使っていた言語や技術でも十分できるのではないか?と思うこともあります。

それをやってみたら、当然、失敗することもありますが、新しいことをやってみて、失敗してしまうのは当然だし、むしろ早めに失敗したほうが良いですよと伝えたいですね。そういう他人の失敗をあげつらうようなことをするのではなく、小さな失敗から学びを得るような社会に変えていきたいですよね。

withコロナで、色々な企業が失策や失敗をしたと思いますが、そこからいかにして学ぶかが重要です。自分たちの失敗に目を向けられないのではあれば、それはwithコロナだろうとなかろうと、良いスタンスにはなれないと思います。

人生100年の時代ですから、その激動を必ず体験するわけです。それが起きた時に、どういうアクションを取るかというのは、失敗経験から学びを作っていくしかありません。

 

――最後に、次回の取材対象者をご指名ください。

広木氏:同じ会社の人間が続いて恐縮ですが、レクターの松岡がまだ登場していないので、推薦をさせていただきたいと思います。

松岡は、CTO協会の理事をしているので、そちらの話をメインに聞いていただければと思います。松岡は突っ込まれやすいタイプの頂点にいます。失敗は指摘されなくては気づかないことが多くて、失敗を指摘しやすいキャラクターであることはとても大事です。松岡はそういうタイプの人間なので、そのあたりが伝わると良いなと思います。

f:id:pcads_media:20201021191816j:plain

以上が第12回のストリートインタビューです。
広木さん、ありがとうございました!

こちらのインタビュー企画、実は12人で終了の予定だったのですが…コミュニティメンバーからの要望もあり延長することにいたしました!!

ヒトと知識とテクノロジーが行き交う、個人の可能性や価値が拡がるコミュニティ「TECHStreet」。そんなコミュニティを表現し、ヒトをつなぐ「ストリートインタビュー」。今後、どのようにつながっていくのでしょうか…

次回はレクター株式会社代表取締役の松岡剛志氏にバトンタッチ。今後のストリートインタビューもお楽しみに。

▼ご紹介いただいたVOYAGE GROUP取締役CTO小賀昌法さんの記事はこちら
【連載#11】VOYAGE GROUP 取締役CTO小賀流の技術組織の作り方とエンジニアの巻き込み方とは

f:id:pcads_media:20201019115225j:plain

(取材:伊藤秋廣(エーアイプロダクション) / 撮影:古宮こうき / 編集:TECH Street編集部)