注:スピーカーの所属は、2019 年 9 月 17 日 時点のものです。
パネル進行スライドは
こちらからご覧いただけます。
内製のためのチーム作り
小島:小野さんのブログに戻って、結局、自社内で開発をすることになったんですよね。その内製のチーム作りについて、教えていただけますか。
小野:内製のためのチームということですね。一般にどういう内製チームがあるのかというと 2 種類あると思います。1 つは社内の製造工場という役割を持つもの。社内からの要求に従って物作りをするというものです。そしてもう 1 つが、ユーザーにこういう体験を提供したいよね、こんな新しいものがあったら良いよね、というように、自らが作るものの内容も考えて物作りをするチームです。
私のチームは完全に後者です。最初は「プロジェクトがあまりうまくいっていない。予算ももうないので小野さんのところでならタダで作ってくれないか」というような依頼が何件かありました。ですが、そういう案件を受けることを仕事にしてしまうと、うまく進められていないプロジェクトを延命させるためのチームになってしまう。それは私たちが外部からエンジニアを採用して推進しようとしていたこととは違うことなので、丁重にお断りしていました。そういうやり取りが続くと、小野さんのチームは依頼されたものを作る工場じゃないんだね、という理解が浸透していきました。
エンジニアとして応募してくる人は半分くらいはベンチャー気質の人でした。カード会社は絶対ミスは許されないから常に厳しくチェックしながら仕事しなくてはいけないという人ではなくて、明日までにこれ対応しようぜ！というようなノリの人です。一方、しっかり確実にやって行こうというエンタープライズ系の人ももちろん必要です。文化の全く異なるエンジニアたちが一緒に仕事をしています。
そうすると、ベンチャーから来た人は、なぜこんなに硬い職場なの？となるし、エンタープライズ系の人や、クレディセゾン 70 年の歴史の上に立っている人からすると、なんでこんなチャラいやつらがいるの？ということになるわけです。
具体的なエピソードを一つ。ベンチャーから来たある人が、炊飯器を会社に持ってきていいですかという質問を Slack に書き込みました。その人は、社内規定を一語一句確認して、炊飯器を持参することがダメだとは書かれていないので、大丈夫だと判断したわけです。でも、一般的に規定にそこまで書きませんよね。
小島:そんなこと書かなくても、わかりますよねと普通は考えますね。
小野:そんな問いに答える間も無く、買いました！と Slack に書かれているわけです。でも、オフィスでご飯を炊かれたら困る人もいるわけです。匂いは気になるでしょうし、やめてくれという話もあるわけですよね。
小島:ちなみにその炊飯器持ち込みは最終的にはどうなりましたか？
小野:結果的には納得してくれました。最初は、「どうして炊飯器を持ってきたいの？」と聞いてみたんですね。すると、「炊きたてのご飯が食べたいんです」という。「なるほど、確かに。」となるわけですね。実はアプレッソ時代に、エンジニアが炊飯器を持ってきたことがあったんです。最初はみんな喜んで炊きたての米を食べていました。ただ、その後何が起きたかというと、毎回 4 合ぐらいを炊くので、どうしても食べきれない。そうするとラップに包んで冷凍庫に入れるようになる。そして、レンジで温めて食べることになる。あれ、これ、炊きたてのご飯じゃないよね？となって、結局しばらくして炊飯器は撤去されました。
そういう経験談を語ると、小野さんは規則だとか周囲の反感を買うからとか、そういう理由だけでダメと言っているわけではなくて、ちゃんと話を聞いた上で、自身の経験に基づいて言っているんですね、ということになり、理解を示してくれるのです。
小島:相手の考えをまず聞いてあげて、それに対して答えてあげることが大事だと。
小野:一方で、全く違う種類の苦労もありました。開発者には大きなディスプレイとハイスペックなマシンが必要ですが、「どうして他の社員は今の PC で我慢しているのに、小野さんのチームだけ良いマシンにしないといけないんですか？」というような話がありました。「本当に、その通りですよね。」とまずちゃんと話を聞いて、その上で、開発者にはなぜそれらが必要なのかを丁寧に説明してく必要がありました。
小島:仕事内容が違うから、枠にはめるのはおかしいということですよね。
小野:そうですが、それを言ってしまうと、マシンを調達している部門の意見を否定することになってしまうわけです。そこで、「自分は小学校からプログラミングしていて、（この）大きなディスプレイにすると開発生産性が 5 倍くらい違うと思うんですよね」と説くわけです。そうすると、小野さんがそこまで主張するのであれば仕方ありませんが、けれど今回は例外ですよとなるわけです。
小島:これまでのお話を聞くと、炊飯器を持ってきたとか、プログラミング経験も豊富な小野さんでないと説得できないみたいな感じになりますね。
小野:そうではなくて、全力で相手に歩み寄ることが大切ということを言いたいわけです。炊飯器を持ってくるという経験がなかったとしても、その人がなぜそうしたいのか、その背景には何かがあるはずだと考えることが重要です。それを理解した上で、相手にきちんと説明できるか、納得してもらえるかですね。皆を納得させていくことが一番難しいわけです。
辻:相手に歩み寄るには、その相手に愛情を持つことが重要という話を聞いたので、転職後に実行に移しました。部下が 35 人くらいいて、最初の 3 週間は、1 人あたり 40 分ほどかけて、全員と話をしました。業務の話は一切無し。40 分間、私があなたに惚れるような自慢話をすること、そして私が会社を大好きになるようにスバルの良いところを語ること、この 2 つをお題として出しました。
通常ですと、上司と部下ですから業務の話が中心になりますが、私は入社して間もない、まだ何もわからない者ですし、業務の話でお互いに歩み寄れる気がしませんでした。愛情を持ってこそ、相手に歩み寄れる自分が作れるなと思っていました。実際に、この対話をやってよかったですね。世界的に有名なゲーマーが実はスバルにいたこともわかりましたし。この体験から、あまり怒らないようになりましたし。
長谷川:昔はよく職場の仲間で飲みに行って、「お前の子、今度小学校だって」といった話をしていましたね。
小島:歩み寄ったわけですね。
長谷川:最近は One on One と言って、業務時間内に一対一で雑談や相談する機会を設けるところが多くなりました。昔は、タバコ部屋のようなところでしていた話を普通に会議室でする時代になっています。
小島:メルカリは新しい会社ですけど、カルチャーを明文化することは実は大事だったりしますか？
長谷川:明文化はとても大事ですね。阿吽の呼吸では会社はまわりません。「Go Bold - 大胆にやろう」ということを会社として掲げています。しかし、人によって持っている常識が違いますから、この言葉だけでは、解釈もまちまちです。明文化すること、文章にすることが実はとても大事だと考えています。メルカリとしては、バリューも毎年少しずつ変えていますし、会議でも議事録をきちんと残して、誰がみても、同じ結論になるように、そこはすごく気をつけています。
小島:透明性なのでしょうか？小野さんの炊飯器の件も、どういう経緯で炊飯器を諦めたのかという過程がクリアになっていることが大事ですよね。
小野:エンジニアにとって、説明責任は大事なことです。ペアプログラミングで、「うーん、このコード、ムカつく」ということはありますよね。でも、ファクトをもってストレートに非難するととても刺々しくなってしまいます。なので、わたしはそういうコードはヒヨコのコードという意味で「ヒヨコード」とか、ここピヨピヨしているよねといった、かわいい表現を使うようにしています。
こういうやり取りをボクシングに例えると、きつい言葉を使って相手を攻撃するのは、グローブに釘を仕込むようなことなので、相手が傷つくのはわかりますよね。それでは困るわけです。だから、グローブはふわふわのクッションにするわけですよ。パフっとかなって、はぁ気持ちいい、と。それが、炊飯器の話であり、調達部門へのディスプレイの説明であり、っていう感じです。
長谷川:Slack ってあるじゃないですか。メルカリでは Slack で 1:1 のやり取りは絶対にしない、つまりオープンで使うことを推奨しています。
少人数、3 人くらいで行う議論であったとしても、パブリックというかオープンチャンネルでやります。検索して、そのスレッドを誰でも見ることができて、入ることも、出ることもできる、そういう状態にしておきます。これは、とても重要なことで、あとから入ってきた人を嫌な気分にしてはいけませんから。
小島:主流派じゃないと思われる人に対して？
長谷川:プロジェクトを作ってオープンチャンネルでやるのとクローズドチャンネルでやるのとではかなりの差があります。クローズドチャンネルにすると、このプロジェクトが進まないのは、あそこの部が反対しているからとか、あいつが悪いとかそういう話になりがちです。オープンチャンネルの場合、誰でも入れるし、プロジェクトに興味のある人が入ってきます。だから悪口を言わない。オープンだと、ちょっとあの人を入れて議論しようとか、いろいろな人が入ってどんどん深い議論になっている、またそれをみんなが見ているので、決して殴り合いのような状況にはなりません。
小島:殴り合いにならないのは大事ですよね。マネジメントのそのいろいろ聞いて一対一でやると力関係が共通のゴールがあると、ここに行くために今回こちらを頑張ってサポートするけど、次はそっちが頑張ってやってね、という感じで 3 点目のゴールがあると、割と会話が成り立つっていう、習ったことがあるんですけどそういうのに近いかもしれないですね。その。殴れないから。ここに行きましょうよって話せざるを得なくて、そうするとチームはまとまりやすい。
ビジネス SaaS はどう活用する？
小島:さきほど、長谷川さんから社内システムでの SaaS 活用について話がありましたが、最後に、SaaS について、他のお二方、意見をお願いします。
辻:自動車業界はおそらく自分たちは特別な業界だ、もの作りのプロセスは違うという意識がどうしてもあります。なので、SaaS は使えないという考えがあるのかもしれません。少しでも危ない可能性があるとそれが車そのものの製造にも影響する世界です。なので、SaaS とかクラウドにいくのが、銀行よりも遅かったかもしれないですね。
ただ、一部、業務的に車自身に関係ないようなところ、バックオフィスものやお客様との接点では、SaaS で良いと思っています。あとは、企業のカルチャーとして、受け入れるのに少し時間がかかっています。部門による違いもありますね。
小野:ビジネス SaaS は積極的に使いましょうという考えです。私自身は、SaaS だろうが、PaaS だろうが、基本的にすべて積極的に活用しましょう派です。
しかし一方で、悩ましいこともあります。クレディセゾンは年間 5 兆円近いトランザクションがあるわけです。それをいきなりクラウドに全部データを送って BigQuery で分析することはできません。個人情報の塊ですから、慎重にステップを踏んで扱わなければならないレガシーを全否定し、BigQuery にデータがすべて載っていないことなどありえない！という人がいたら、こう後ろからそっと抱きしめて、「そんなこと言わせてごめんな」って、言いますね。
小島:小野のマネジメントスキルが高いってことだけはかなり理解できました。いや、こういうタイプでないと、テックカンパニーになるのは難しいというでしょうか。
小野:歴史がある事業会社と、テックのカルチャーって全然違うから、その文化的な対立が絶対起きるわけですよ。自社開発を始めると、そこに緩衝剤みたいな役割の人とかチームがいないと絶対否定しあってしまう。ほんとそこが一番肝だと思います。
小島:そろそろ時間もきたようなので、本日はこれにて終了としたいと思います。スピーカーの皆さん、また来場者の皆さん、どうもありがとうございました。
Posted by
Takuo Suzuki - Developer Relations Team
