常務執行役員 CTO・小野和俊氏 1999年、慶應義塾大学環境情報学部卒、サン・マイクロシステムズ株式会社入社。米国Sun Microsystemsでの開発を経て、2000年株式会社アプレッソ代表取締役就任。データ連携ミドルウェア『DataSpider』を開発。2002年同ソフトでSOFTICソフトウェア・プロダクト・オブ・ザ・イヤー受賞。2013年よりセゾン情報システムズでHULFT事業CTO、常務取締役CTOなどを歴任。2019年より株式会社クレディセゾン取締役CTOに就任し2020年より現職。

テクノロジーセンターの立ち上げで目指したのはどのようなチーム作りですか。ブログでエンジニアを採用した際の選定基準も教えて下さい。

テクノロジーセンターの立ち上げ時に意図したのは、バイモーダルチームです。エンタープライズ系のSIer出身者とベンチャー出身者がおよそ半々の構成になることを意識しました。エンタープライズ系のエンジニアは、とにかく事故が起きないことや品質を非常に大事にします。一方、ベンチャー出身者は、スピードと技術力を重視し、他部署の事業に関することでもどんどん意見を言ってくるような文化を持っています。これらの違いを、「SoR」「SoE」、あるいは「モード1」「モード2」などと表現することもありますが、全く違う2種類の人たちをあえてハイブリッドで混ぜました。 採用で重視したことは、まず、このような全く違う文化が混在するチームでやっていけるかどうかです。また、クレディセゾンは事業会社ですので、開発力だけではなくアイデアも大事であることから、色々なことに興味を持って、自ら提案が出来るかどうかも重視しました。 技術面では、特定な技術の練度の高さより、新しい技術が出てきた時に、初心者として向き合うことを厭わない人であることを重視しました。技術者の中には技術スタックで会社を選ぶ人が少なくありません。そうなるとその技術を使わなくなった時、お互いが不幸になってしまいます。 特にシニアの方は初心者になることが恥ずかしいし怖いと感じる傾向にあります。若いエンジニアから、「そんなことも知らないんですか」などと言われたくありませんから。例えば私の場合、JavaとかC♯をずっとやっていましたが、ある分野で権威のようなポジションを確立したことがある人であればあるほど、初心者に戻ることは難しいものです。しかし、何かを作るために最適な技術に対して初心者に戻ることが出来なければ、自分が使い慣れた技術を無理やり使ってしまうという方向に流れてしまいます。 そもそもプログラム言語や技術ありきで、何を作るかと考えるような物作りは、技術の使い方を間違えています。初めに考えなければいけないことは、何を作れば世の中にとって意味があるかです。そして2番目に、それを作るために何が最適かという視点で言語や技術を選ぶ。それが本来的な物作りだと考えています。

個人ブログで採用された方が過去の同僚を誘ってチームが拡大したと伺いました。皆さんはどういうところに魅力を感じておられるのでしょうか。

人によってそれぞれあると思いますが、例えばベンチャー出身のエンジニアは、自身の今後のキャリアを考えた時、自由さを取るか、マーケットの大きさを取るか、方向性を1つに絞らなければいけないと思っていたと言います。ベンチャー企業はスピード技術重視で自由に生きていけることが魅力ですが、一方ではリーチ出来る絶対数が少ないことが悩みです。大手企業はシェアを持っているので、プロダクトを届けられるマーケットが大きくなる。その分、慎重にならざるを得ませんので、手堅くならざるを得ず、スピードも遅くなります。この2つの要素を備えたIT企業というのはなかなかありませんので、エンジニアとして生きていく以上、どちらかを選ばなければいけないと思っていたということでした。 ところが弊社は歴史も信用もあって非常に大規模なお客様の基盤を持つ一方で、新しく設立したテクノロジーセンターには私を含めてベンチャー出身者が何人もいて、スピード感を持って仕事をしている。つまりどちらか一方の「or」ではなく、大手企業の良さとベンチャーの良さを両方備えた「and」の環境が魅力だと話していました。 もう1つは心地よく働ける環境です。テクノロジーセンターは心理的安全性を重視するチームです。そのために“HRTの原則”を守るべきルールとして定めています。“Humility＝謙虚さ”“Respect＝敬意を払うこと”、“Trust＝信用すること”の頭文字を取って“HRT（ハート）”です。全く異なる人が集まれば、それぞれ常識も違ってきますので、下手をすれば衝突してしまいます。例えば「未だにこんな古いやり方して」と言いたくなった時に、“HRTの原則”を思い出す。違う人がお互いの強みを持ち寄るからこそチームが強くなると考えて、このルールは徹底しています。また、それと関連して、お互いの短所を言い合うことも禁止しています。長所について言うのはいいけど、短所について言い始めると、実際には長所があるのに短所ばかりクローズアップされてしまいます。 このような文化面でのルールをいくつか設けることで、すごく心地よく働ける。それが元同僚や知り合いのエンジニアを誘う要因になっているものと思われます。

外部のエンジニアを採用する一方で、社内公募でもメンバーを募ったとのことですが、その狙いをお話し下さい。

テクノロジーセンターを立ち上げる際、事業部門の知見・経験と、ITの知見・経験を融合させるために、社内から公募をかけて採用していくような仕組みはどこかで必要になると思っていました。 背景を説明すると、世の中のITに対する見方が変わったということがあります。1990年代までは、ITはどちらかというと業務の自動化、効率化のための道具であり、非常に限定的なものでした。ところが日本でも近年一気に広がったUberEatsなどデジタル・ディスラプターが提供する顧客体験は、単に自動化や効率化といった次元を超越しています。注文するとアプリで自転車が移動している様子が表示され、見当違いの方向に逸れていったら正しい道を指示出来る。届けば良いだけなら不要な機能ですが、顧客体験としては新しかったわけです。ITやデジタル技術の使い方次第で、サービスの魅力や体験の価値、さらに競争優位性が変わる。かつては効率化の道具でしかなかったインターネットが、スマホが登場したことで、事業の骨格となる価値を作る極めて重要なものに変わったのです。 そうであるならば事業会社の中にこれから作るIT部門は、単なるコストカットのための部門でもなければ、外部に任せて良い部門でもなく、企画する人と作る人が仲間として隣同士で議論を重ねながら価値の高いサービスを作って行くというふうにしなければいけないと思いました。そういうふうにITの位置づけを変えていかなければいけない。 一方で、内製化チームを作っても、外部から来た人達が好き放題言って、正論を振りかざしているという感じになってしまうと、もともといた人たちからすると排除したい対象となってしまいます。スペシャリストを採用したものの、前からいた社員と合わずに結局は出島戦略などと言ってデジタル戦略子会社を作るといったことは珍しくありません。そのデジタル戦略子会社は稟議規程も緩くて、服装はカジュアルで良く、時間もルーズで良いというような会社はよくあります。 私はそれはやりたくないと思っていました。「あの人たちは好き勝手やっていて良いよな、本業の俺たちはそういうわけにいかないよ」となってしまうと良くない。会社が大きく変わるための一番の近道は、ど真ん中のところを変えてくことです。そのためには内部に影響を与えるチームを作らなければいけません。今回社内公募でテクノロジーセンターに異動してきた人達は全部署から採用しています。そうすることで何かアイデアが生まれた際に相談がしやすくなると考えました。 公募に当たっては、まず全事業部門から採る方針を掲げました。そして元の部門とのタイアップのような感じで快く動いてくれる人、さらに、新しいことを学ぶことになりますので、学習意欲が高い人といった基準で選定していきました。

多様な方々が集まるテクノロジーセンターですが、マネジメントで気をつけていることをお話し下さい。

それはやはり、先ほど申し上げたの“HRTの原則”、“心理的安全性”などの文化面のルールですね。これまでダイバーシティと言えば、宗教や人種、性などについて言われて来ましたが、最近はタスク型ダイバーシティということが言われています。異なる職能を持った人たちが一つのチームに集まってやって行く。そこでは性格的な長所や短所がバラバラです。これまでのバックグラウンドが全部違うし、常識も違う。だからこそ短所については絶対言及しない。自分の長所で相手の短所を補うことが出来れば、レーダーチャートが綺麗な花を描かなくても良いわけです。あるとこだけ突き抜けていて、あるところは0点でも良い。チーム全員のチャートを全部重ね合わせたときに面積が広くなれば良い。それが私の考えです。 その時に「お前なんでここ0点なんだ、社会人失格だぞ」とか言っちゃったらアウトです。例えば一般的に言えば遅刻なんて絶対に駄目ですが、エンジニアには遅刻する人が多いわけです。だから「遅刻とかありえない」とか言わないでねと言っています。もちろんそれで業務に支障が出ることもあります。その時、私なら「最近ハマっているゲームあるの？」と聞きにいくわけです。「いや、ちょっと実は」となれば、「そうなんだ、あのゲーム良いよね」など肯定した上で、「ただやっぱり3回連続で遅れちゃうと、連絡が1人だけ届いてないということもあるから、次はちょっと頑張ってみようよ」と促します。そうすれば「わかりました」となるわけです。そういう感じでコミュニケーションをしていけば傷つけずにやっていけます。

最後に転職活動をしているエンジニアにお伝えしたいことをお話し下さい。

ソフトウェアの開発に携わるスペシャリストの多くは、自分たちの成果によって喜ぶ人の顔が見たいという気持ちを持っています。ただ、場合によってはそれが見えないような仕事をしている人たちも少なくありません。私達は社員向けのものを作るにしても、お客様向けのものを作るにしても、喜ぶ人の顔が見えやすい仕事の仕方をしています。直接話しもしますし、お客さんの反応を自分たちで見に行きます。そういう意味で「この仕事の意味は、誰がどういうふうに喜んでくれることなのか？」ということも感じてもらいやすい環境です。お客様の層が厚いこともあり、そういう種類の仕事が出来ていると思いますので、「作って納品はしたけど、本当にお客さんが喜んでくれるかどうかわからない」といった悩みを持っている人には、すごくミートするのではないでしょうか。 もう1つ。ITの世界にはプログラマー35歳定年説という言葉があります。ある年齢から「マネージャーにならないとこれ以上給料上がらないよ」と言われることもあります。それに対して、弊社はスペシャリストのキャリアパスをちゃんと用意しています。「ずっとコードを書いていきたい」「ずっと技術に磨きをかけていきたい」という人も、しっかり成長して条件も上がっていくことが可能です。スペシャリストとして技術を磨きながら、事業会社でお客様や社員が喜んでくれるものを作って行きたいと考えている人がいたら、ぜひご連絡いただきたいと思います。