「エンジニアリング組織のつくり方」を開催しました

人事部 高橋洸 です。

5/8 に当社京都オフィス Sansan Innovation Lab (以下 SIL) で勉強会「エンジニアリング組織のつくり方」を開催しました。

sansan.connpass.com

勉強会で使う和室は普段は集中できる静かなスペースです

今回のイベントのテーマは「エンジニアリング組織のつくり方」。プロダクトが成長すると、プロダクト自体、またはその組織の複雑性から様々な課題が生まれます。今回は Sansan に加え、さくらインターネットさん、はてなさんから 1 名ずつ登壇してもらい、それぞれが向き合ってきた課題について実例を交えて話してもらいました。

鈴木康寛 / Sansan株式会社「組織の多様性と向き合う」

speakerdeck.com

1人目の登壇は Sansan 株式会社の Eight 事業部でエンジニアリングマネージャーを務める鈴木(@yasuzukisan)です。
Eight はプロダクトの成長にしたがってエンジニアリング組織が拡大し続けています。その中でこれまでにどういった課題が生じたか、またエンジニアリングマネージャーとしてそれらの課題にどう立ち向かったか、について、 Will Can Must とゴールデンサークルのフレームワークに則って図示しながら語りました。
古参メンバーと新規メンバーのマインドセットの差異など、どこの組織でも生じうるものでしょう。万能な解決策は存在しませんが、取り組みの一つとして参考にしていただけると思います。

坪内佑樹 / さくらインターネット株式会社「SREの組織的実践」

speakerdeck.com

2人目はさくらインターネット株式会社で Site Reliability Engineering (SRE) の研究員である坪内さん (@yuuk1t , id:y_uuki) 。日本で SRE を語らせたらこの方の右に出る方はいないんじゃないかなと思います。
登壇では、まず前半でそもそも SRE とは何だったか？という問に向き合い、「SRE とはサイト信頼性を制御するための工学である」と定義します (「信頼性を制御」というところがミソ。信頼性を常に最大化しようとすると変更速度が落ちたりする) 。その上で SRE をどのように実践していくべきかについて、「工学は技芸と組織の組み合わせである」というポイントを軸に、 SRE が取り組むべき問題解決のフレームを述べられていました。

個人的に、前半パートの「コンピューターがどれだけ賢くなっても、人間による運用は残るはず。その運用を楽しくすることが重要。」という話が刺さりました。運用というとどうしても地味な印象をもつことも多いですが、楽しくてもいい & 楽しくするべきなんですよね。

粕谷大輔 / 株式会社はてな「エンジニア(リング)マネージャは何をする人なのか考えてみよう」

speakerdeck.com

最後は、株式会社はてなで Mackerel のチームディレクターを務められている粕谷さん (@daiksy , id:daiksy) の登壇です。
エンジニアマネージャは、抽象的なマネージャのエンジニアとしての実装です。発表では抽象的なマネージャの責務と、それをエンジニアに特化させた場合の責務について様々な例を挙げ、エンジニアマネージャとは何か、またその必要性について述べられていました。
例えば新しいツール導入の際。非エンジニアのマネージャに対してエンジニアが「何のために導入するのか」という説明をするためにかなりのコミュニケーションコストを要しますが、エンジニアマネージャであればそのコストがグッと下がります。ほかにも、技術的負債に対する考え方も、エンジニアマネージャの方が理解が速いでしょう。とはいえ、いずれにせよ意思決定のメリット/デメリットは冷静に判断すべきことではあります。

終わりに

懇親会では、参加者のみなさんが抱える組織的な課題について議論が盛り上がっていました。予想どおり時間が足りませんでした😇
私の周りでは「テックリード、エンジニアリングマネージャ、VPoEの違いとは？」「エンジニア採用どうやってる？」「新規メンバーの育成は？」など様々なテーマで語り合いました。

SIL での勉強会はありがたいことに毎回満席です。枠から漏れてしまった方や遠方の方にも届けたい...！ ということで、今回は YouTube でのライブ配信も行いました。配信でご覧くださった方々もTwitterを通し感想などをくださり、お届けできてよかったと感じました。今後も京都エンジニア界隈を盛り上げるべく、どんどん企画していきます！ ご期待ください。

AFTER RubyKaigi まとめたよ！

こんにちは。SBB編集部の鈴木です。
このブログを開始した頃に書いた「鈴木対談」以来の登場です。
本ブログの運営の他に、勉強会の企画や運営なども行なっています。

最近企画した勉強会のひとつに、ラクスルさんとZOZOテクノロジーズさんと合同で開催した「AFTER RubyKaigi」があります。
こちらは、その名の通り RubyKaigi での知見を共有しよう！ という勉強会です。
RubyKaigi に参加した人もそうでない人も、語りたい人も聞きたい人も、みんなで集まって楽しい時間を過ごそうよ、というわけです。

本記事では、来られなかった方や参加した方の振り返りになるよう、当日のLT資料をまとめました。
が、非エンジニア目線でのゆるゆるなご紹介となりますことをお許しください！🙏

登壇資料のご紹介

「RubyKaigiを振り返ってみた」/ Sansan株式会社 石畑翔平 (@pekepek)

10ページ目くらいまでは「RubyKaigiは美味しい」話。
え？ こういうのが続くの？ と思ったところで、中盤からは Curses / Committee をさわった話にうつり、デモも披露。
この登壇で石畑が「Committee が OpenAPI ver 3.0.0 でしかうごかなかった」とお話ししたところ、＠ota42y さんがその場で ver 3.0.x で動くようにしてくれるなど、エモさ爆発の展開となりました。*1

speakerdeck.com

「糸より軽い(?)繊維の話」 / ラクスル株式会社 小林寛武 氏 (@hkobayash )

Ruby 1.9 で登場した「Fiber」の話。タイトルの繊維ってそのことだったんですね。
Fiber は「継続」を変数として扱えるように実装されたものということ。(え、状態を数で表すってすごくない)
またWebアプリケーションを実装、 falcon を puma と比較されています。

speakerdeck.com

「ファッションチェックランキングRubyKaigiの裏側」/ 株式会社ZOZOテクノロジーズ 田島克哉 氏 (＠katsuyan121)

RubyKaigi のブース企画。これはすてきなコンテンツですよね。自社サービスのPRもきちんとしながら、参加者を楽しませてくれました。わたしも1日目に8位(たしか)に入って嬉しかったです。
男性より女性の方が想定いいね数が低くつきがちと聞きましたが、なんででしょう？
1日目から2日目になるときにアプリをアップデート(2列対応)された話は、ブース運営側としてとても参考になりました。

speakerdeck.com

「RubyKaigiでもらった熱量がOSSに変換された話」(ゲストLT) / 22 Inc. 大薮 永 氏 (＠yaboojp)

ピンク色のRubyTシャツでご登場！ 実はこのTシャツは、パネルディスカッションに参加した弊社南谷(@yuki3738)主催のランニング企画「5K」に参加してくださった方に差し上げたものでした。*2
プレゼンしてくださったのは「美味しいごはんが熱量となり、それがよりRubyに燃える原動力になった」お話。
資料の最後のページに想いが溢れています！

speakerdeck.com

「Q&A for 
How to use OpenAPI3 for API developer」(ゲストLT) / おおた 氏 (＠ota42y)

RubyKaigi で登壇された「How to use OpenAPI3 for API developer」のおさらいと、寄せられた質問への回答をお話しくださいました。本家 RubyKaigi のスピーカーの方がゲストLTなんて、豪華すぎです！
資料の24ページ目にその場で対応くださった Committee OpenAPI ver 3.0.1 のことも追加されています！

speakerdeck.com

LTのあとは休憩をはさみ、モデレータにRubyコミッターのそのっつさん(@sonots)を迎え、ラクスル株式会社の二串 信弘 氏(@nikushi_jp)、株式会社ZOZOテクノロジーズの木曽 貴裕 氏(@takanamito)、Sansan株式会社 南谷 祐貴(@yuki3738)がパネラーとなったディスカッションを行いました。
議論が白熱し時間内に終わらないほどだったのですが、資料のご用意がないので、どんな内容だったかは Twitter で「#afterRubyKaigi」と検索をかけてみてください🙇‍♀️

おわりに

わたしは昨年初めて RubyKaigi に参加したのですが、ものすごく楽しくて衝撃を受けたことを覚えています。
今年も福岡でブースに立ち「そうそう！この感じ！」とわくわくしました。RubyKaigi に一緒に行った人、そこで出会った人とは、なぜかすごく距離が近くなりますよね！

ひとえに Rubyist のみなさんが本当に Ruby を愛しているから生まれる雰囲気(そしてそれが、わたしみたいな非エンジニアにも伝わってくる)だと思うのですが、今回の AFTER RubyKaigi も、そんな場になっていれば幸いです！ また来年もやりたいですね…！

そして、まとめ記事に資料を掲載することを快くご了承くださった皆さま、ありがとうございます！

最後まで残っていたメンバーで！

*1:https://github.com/interagent/committee/pull/223

*2:#RubyKaigi5k - Twitter Search

Sansan iOS メジャーアップデートの舞台裏

Eight 事業部 iOS エンジニアの河辺です。2019年2月から2019年4月までの2ヶ月間、 Sansan の iOS チームに異動し、先日メジャーアップデートした Sansan iOS の開発をしていました。 Sansan iOS ではメジャーアップデートに伴って、アーキテクチャ刷新や開発基盤の構築を行いました。この記事では、開発基盤の構築の内の一つである UI Component 化の取り組みを紹介したいと思います。

UI Component

UI Component という言葉が出てきましたが、この記事では アプリケーションの画面を構成する UI 部品 を UI Component と定義します。

UI Component 化の取り組み前の課題

以下の 2 つの画面の氏名を表示する UILabel、 会社名, 部署, 役職を表示する UILabel は Style が全く同じという特徴があります。ですが、各 UILabel で Style の設定がされており、共通化できていませんでした。 UILabel に限らず、 UITextView, UIButton, UIImageView, UISearchBar においても同様に共通化できていませんでした。

名刺一覧画面	同僚一覧画面

画像はデモデータです

共通化できていないことによって以下の課題がありました。

• 一つ一つ Style を設定する必要があり非効率
• デザイン定義に変更があった際の修正作業が非効率
• Style を設定する回数が多い分、設定ミスをする可能性も増える

顧客データHub開発の裏側（後編）

CTO藤倉です。今年3月、法人向けクラウド名刺管理サービス「Sansan」の新機能「顧客データHub」を発表しました。

これは、Sansanがこれまで蓄積してきた技術とノウハウを応用したテクノロジーで、独自の「名寄せエンジン」を用いて社内のあらゆる顧客データを統合できる機能です。

今回は、顧客データHubの開発を牽引したエンジニアである千田智己に話を聞きました。前中後編の3回に分けて紹介します。

後編では、顧客データHub開発の経緯やプロジェクトにかける思いについて語ってもらいました。

プロジェクトはどうやってスタートしたか？

藤倉：顧客データHubのプロジェクトがスタートした経緯として、「Sansan・Eightという2つのメインプロダクト以外にも、僕らの持つテクノロジーを活用することでユーザーさんに新しい価値を提供したい」という話が経営層のなかで出てきた。

いろいろな案が出てくる過程で「企業が持っている膨大な顧客データを、僕らのテクノロジーで“名寄せ”できたら、大きな価値を提供できるんじゃないか」という軸が定まって、プロジェクトがスタートしたんだよね。

千田：プロジェクトの開始時点では、仕様はほとんど決まっていなかったですよね。正直にいうと、モチベーションは最初すごく低かったです。プロジェクトに参画してから1か月くらいは低空飛行していました。

藤倉：そうだったんだ。どうして？

千田：もともと自分は、「名刺管理」で世界を目指すという姿勢に魅力を感じて、この会社に入ったんです。自分以外にもそういう社員は多いと思います。だから、それ以外のものを扱う機能を開発するのは複雑な気持ちでした。

けれど、徐々にですけど、このプロジェクトによって自分たちが目指してきた方向が変わるわけではないし、「Sansanがこれまで培ってきたテクノロジーと新しい価値を結びつけることで、会社を次のフェーズに進めたい」という（代表取締役の）寺田さんの思いが理解できるようになり、だんだんとやる気が出てきたんです。

顧客データHubのアーキテクチャ

藤倉：アーキテクチャはどうやって考えていったの？

千田：最初の頃は、「多種多様なデータが大量に入ってくるので、そのデータをどこかに書き出して使いやすい状態にする」くらいのざっくりとした仕様しか決まっていませんでした。まずはそれを前提として、並列分散処理の方法や多種多様な形式のデータをどうやって保存するかという部分のアーキテクチャから考えていきました。

藤倉：データストアは何を使ってる？

千田：データの永続先としては、Azure Table Storageを使っています。Amazon DynamoDBのような、KVS（Key-Value Store）形式のデータストアですね。

藤倉：データ構造そのものが多種多様だから、スキーマレスな状態で持った方がいいということだね。

千田：Azure Table Storageはあくまでデータを永続化しておくための保管場所という意味合いが強くて、ここに格納されているデータを直接的に使うことはないですね。

ユーザーが使える状態に加工する際には、Azure Table StorageからElasticsearchに読み込んでいます。汎用性高く文章データを扱うにはElasticsearchはすごく便利ですけど、データを永続させることはElasticsearchだと難しいので、両方で補い合っている形ですね。

藤倉：今回のプロジェクトではAWSやGCPではなくAzureを選定したけど、良かったと思う？

千田：選んで良かったです。これまでと同じようにAWSを使っていたら、良くも悪くも設計やインフラの使い方がSansanの既存仕様に引っ張られていたと思います。自由な発想が出にくくなったというか。過去のプロジェクトでAzureを使ったことはなかったですけど、未知の領域に踏み込んだことで、自由な発想でアーキテクチャ構築ができました。

個人の意見が反映されやすい環境

藤倉：一緒に働いているチームメンバーや、プロジェクトの雰囲気はどう？

千田：優秀なメンバーと一緒に働けているな、と感じますね。具体的な個人名は伏せますけど、めちゃくちゃ実装スピードが速い人や、細かい部分に気づいて良い提言をしてくれる人、みんなのことを取りまとめてくれる人、機能のあるべき姿を真剣に考えている人などがいて。1人ひとりの個性がかみ合って、各々が自分で考えて自分で動ける状態になっています。

それから、顧客データHubのプロジェクトは1人ひとりの意志が機能に反映されやすいのも良いところですね。少ないメンバーでやっているので、会社のなかでも特にそれぞれの意見が反映されやすいプロジェクトになっていると思います。

顧客データHubをどう成長させたいか？

藤倉：じゃあ最後に、顧客データHubを今後どう育てていきたいかを語ってほしい。

千田：多くのユーザーさんにこのサービスを使ってほしい。膨大な量のデータを入れてほしいです。何億、何十億、何百億という数のデータが入ってきても、完璧に捌けるようなシステムを構築したいですね。その目標を実現するために、ユーザーさんがデータを取り込みたくなるような、「もっと使いたい」と思ってもらえるような体験づくりをしていきたいです。

ETLやデータウェアハウスなどのシステムって「カスタマイズが便利にできるものは、使い方を覚えるのがすごく難しい」という永遠の課題があると思っています。でも、顧客データHubはそうではなく、直感的に、自然に使えるけれど便利なものを目指していきたいです。

Sansanが提供している名刺のスキャナーに近い概念かもしれません。Sansanがこだわっているのって、「スキャナーからの名刺取り込みは簡単だけれど、生成されるデータの精度は高い」という体験じゃないですか。それと同じように、顧客データHubも「簡単に使えるのに、超便利」というSansanらしい機能にしていきたいです。

＜前編・中編＞

interview：中薗昴
photo：ブランドコミュニケーション部　高橋淳

顧客データHub開発の裏側（中編）

CTO藤倉です。今年3月、法人向けクラウド名刺管理サービス「Sansan」の新機能「顧客データHub」を発表しました。

これは、Sansanがこれまで蓄積してきた技術とノウハウを応用したテクノロジーで、独自の「名寄せエンジン」を用いて社内のあらゆる顧客データを統合できる機能です。

今回は、顧客データHubの開発を牽引したエンジニアである千田智己に話を聞きました。前中後編の3回に分けて紹介します。

中編では、彼の持つ技術や過去に担当したプロジェクトについて語ってもらいました。

入社直後に携わった戦略案件

藤倉：千田さんが最初に担当したのは、「Sansanスマートフォンプラン」のプロジェクトだったね。

千田：それまでのSansanとは違うビジネスモデル・販売モデルの構築を目指していました。このプロジェクトは仕様策定に難航して、ビジネスモデルが最終的に確定したのはリリース1か月前くらいでしたね。

藤倉：Sansanスマートフォンプランは戦略案件だったから、僕も案件の詳細まで細かく確認していた。設計についても、千田さんとよく一緒に議論したよね。

千田：ホワイトボードに書きながら、話しましたね。

藤倉：千田さんが「いまこういう案を考えているんだけど」と言って、ホワイトボードに設計案をバーっと書いてくれて、夜中まで2人でワーワーギャギャー言いながら仕様を詰めていた（笑）。当時から、（代表取締役の）寺田さんは千田さんの働きぶりをすごく評価していたと思う。

トランザクションログからのデータ復旧

藤倉：千田さんの仕事で特に印象に残っているのは、トランザクションログからデータ復旧をしたことかな。

千田：3年前の12月でしたね。

藤倉：バックアップデータから、特定のデータを復元する必要があったんだよね。でも、スナップショットからの復元では完璧な状態のデータに戻せなくて、用途に対して不十分だった。みんなが「どうしようか」と相談し合っていたところに、千田さんが「トランザクションログから戻せばいいじゃん」と言っていたのを覚えてる。

千田：完全な状態でデータをもとに戻すなら、絶対にその方法がいいと思ったんです。他のメンバーには内緒で、年末年始のうちにPostgreSQLのトランザクションログの仕様を調べて。

年が明けてから「こういう手段でトランザクションログからデータ復旧できそうですけど、どうですか？」とあらためて提案しました。

藤倉：トランザクションログはバイナリファイルだけど、PostgreSQLの公式ドキュメントやソースコードを読んで仕様を調べれば、どんなデータ構造になっているかバイナリからでも解析できるんだよね。「C言語のint型は何bitだから、バイナリファイルのこの位置からこの位置まではint型のデータを持っているはず」って感じに。

千田：そうなんです。ソースコードとトランザクションログを突きあわせながら、力技で内容を解析していきました。PostgreSQLは構造体を多用しているので、解析は一筋縄ではいかなかったですけどね（笑）。

藤倉：でも、それで結果的にちゃんとデータ復旧まで持っていくのが、千田さんらしいなあと思う。

名刺検索のパフォーマンス改善

藤倉：千田さんが印象に残っているプロジェクトはある？

千田：Sansanの名刺検索のパフォーマンス改善ですかね。昔は、名刺検索のパフォーマンスが悪かったんですよね。社員数の多い企業を検索すると、結果が返るまで随分と時間がかかっていました。画面リニューアルのプロジェクトは別途立ち上がっていましたが、完了まで何か月もかかる。待っていられなかったので、検索処理のリファクタリングに自分1人で取り組みました。

藤倉：どんな処理に手を入れたの？

千田：まずはデータベースを非正規化しました。もともと名刺検索の処理では、検索時に複数のテーブルをJOINするようなSQLを投げていたんです。でもSansanはサービスの特性上とてもJOINの数が多いので、どうしてもクエリのパフォーマンスが悪くなってしまいます。

それを解消するために、検索用のJOIN済みテーブルを事前に作っておく設計にしました。実はこの施策で、先ほど話したトランザクションログ解析の経験が活きているんです。

藤倉：お、ここで役立つんだ。

千田：PostgreSQLでは、テーブルに格納される各データはアライメントされていて境界を跨がないようになっています。余ったデータ領域はどうなるかというと、パディングされて容量が調整されるんです。逆にいえば、アライメントを意識してデータを格納すれば、テーブルのデータサイズを最小化できます。

それから、Redisを使って検索結果をキャッシュする仕組みも改善しました。この処理では検索結果のキャッシュを作成・使用するためにシリアライズ・デシリアライズが走ります。名刺の量が数十万枚くらいになるとキャッシュサイズが数MBほどになるので、変換処理がかなり重くなっていたんです。

藤倉：どうやって改善したの？

千田：シリアライズ・デシリアライズそのものを不要にしたんです。構造体で作った最も効率のいいメモリレイアウトを、そのままRedisに転送する設計にしました。キャッシュを使う際には、Redisから取得した構造体の情報をそのままメモリ上に展開します。

藤倉：発想がすごいね。

千田：最終的には、大きなバグもなく狙い通りのパフォーマンス改善ができました。速度が3倍くらい速くなりましたね。

藤倉：ふり返ってみると、千田さんに担当してもらっているのは難易度の高いプロジェクトが多い。他のメンバーがさんざん議論して「これ無理だ。どうしよう」と言っていところに、千田さんが横から「こうやったらいけるじゃん。絶対できるでしょ」と話しかけている場面をよく見かけるよね（笑）。そして、確実に良いアウトプットを出してくる。

千田：あえて難しいプロジェクトに首を突っ込んでいますね（笑）。

藤倉：そういう仕事の方が燃えるんだよね。

千田：そうかもしれません。自分の仕事におけるスタンスは昔からずっと、「自分にしかできないことをやる」なんです。

＜前編・後編＞

interview：中薗昴
photo：ブランドコミュニケーション部　高橋淳

顧客データHub開発の裏側（前編）

CTO藤倉です。今年3月、法人向けクラウド名刺管理サービス「Sansan」の新機能「顧客データHub」を発表しました。

これは、Sansanがこれまで蓄積してきた技術とノウハウを応用したテクノロジーで、独自の「名寄せエンジン」を用いて社内のあらゆる顧客データを統合できる機能です。

今回は、顧客データHubの開発を牽引したエンジニアである千田智己に話を聞きました。前中後編の3回に分けて紹介します。

前編では、彼の人となりや過去に担当したプロジェクトについて聞いていきたいと思います。

インタビュイー
千田智己：Sansan事業部 プロダクト開発部 エンジニア。（SIerを経て、2013年6月にSansan株式会社に入社。以来、法人向けサービスSansanの開発に携わる。）

「0から作って世に出すことの面白さ」に気がついた

藤倉：まずは千田さん自身について聞きたいんだけど、Sansanを選んだ経緯から話してもらっていい？

千田：Sansanに入ったのは、ちょうど6年前くらいですね。当時は「世の中の課題を解いている会社がいい」と考えて転職活動をしていました。

藤倉：そう思ったきっかけって何だったの？

千田：前職で最後に経験した証券会社のシステム開発プロジェクトが、自分にとってすごく面白いものだったんです。前職ではSIに勤めていて、いろいろな案件に携わったんですが、証券会社のプロジェクトで初めて一般の方々が使うサービスを作りました。「自分が作ったものが、世の中の役に立つっていいな」とそのとき感じたんです。

それから、会社選びのもうひとつの基準として「自分自身で新しいサービスを作ってみたい」とも思っていました。そう考えるようになったきっかけも証券会社のシステム開発です。
そのプロジェクトではJavaを使うことだけが決まっていて、設計方針やアーキテクチャなどは自由に決めることができました。自分で方針を決めてプロジェクトを進めていく経験をしたことで「0から何かを作って世に出すのはこんなに面白いのか」と気づいたんです。

そういった基準で転職先を調べていたとき、エージェントが紹介してくれた企業のなかにSansanがありました。

藤倉：千田さんとの一次面接はけっこう印象に残ってる。

千田：（取締役の）常楽さんと藤倉さんが一次面接で話してくれましたよね。ほとんどは常楽さんがしゃべっていて、藤倉さんからはたった1つだけ「いままで触ったなかで、一番いいと思ったフレームワークは何？」って聞かれたのが印象に残っています。いい質問だなと思って。

藤倉：その質問したの覚えてないな（笑）。でも、面接が始まってすぐの段階で「この人はめちゃくちゃ優秀だ」と確信できたんだよね。開始から数十秒でそう思った。常楽さんの質問に対して、めちゃくちゃセンスある回答をしているなと。

技術選定における千田さんなりの軸がちゃんとあったし、かつ僕と同じような水準の理解をしてくれていた。だから絶対に採用しようって決めていたけど、何も質問しないのもアレだから、当時の自分はエンジニアの価値観が表れやすい質問をしたんじゃないかな。

藤倉：千田さんの性格についても聞いていきたい。千田さんは、昔からずっと「難しい仕事の方が燃える」っていうタイプだよね。

千田：負けず嫌いなんですよ（笑）。

藤倉：他のみんなが「どうしよう」と言っちゃうような場面でも、千田さんは「それ、俺できるわ」と言って実際にやっちゃうことが多いよね。千田さんとはたまに一緒にボルダリングをやるけど、ボルダリングにも性格がそのまま出ていると思う。他の人ができない課題を解いているときが、一番面白いでしょう。

千田：面白いです。でも、ボルダリングはそうも都合よくいかないことの方が多いですけど（笑）。

藤倉：それと意外なのが、千田さんって座学は嫌いであまりやらないんだよね。

千田：嫌いですね。目的のない勉強が好きじゃないんです。技術についての知識は、仕事を通じて覚えていきます。仕事で壁にぶち当たったときに、それを乗り越えることを目的にいろいろな調査をして学んでいくことが多いかな。目的意識があってはじめて、勉強に手をつける感じです。

藤倉：でも一度やりだしたら、集中力がすごい。課題を乗り越えるために、尋常じゃなく努力をしているんだと思う。

千田：やっているときは意地ですね。自分がやると言ったなら、責任を持ってやるスタンスなので。

藤倉：そのスタンスだから、スキルも伸びるんだろうね。メンバーを千田さんに鍛えてもらう「千田塾」*1の経験者はめちゃくちゃ成長するけれど、それは一緒に働く人のスキルが千田さんの水準に引き上げられるからだと思う。

千田：メンバーが出したPull Requestにコメント100個とかつけることもあるので、教えられている側は大変だと思いますけどね（笑）。

エンジニアとしての責任

藤倉：千田さんの「できます」という言葉にはめちゃくちゃ信用があるよね。「できます」と言って、できなかったことがない。これは千田さんの長所だと思う。

千田：「できるかもしれない」みたいな曖昧な返事をすることはまずないですね。そして、「できる」と返事をしたときは必ずやり切ると決めてます。顧客データHubプロジェクトの初期フェーズでも、（代表取締役の）寺田さんに質問されたときは「できる」「できない」をはっきり答えるようにしていました。

藤倉：できる可能性がクリアになっていないと、頑なに「わからないです」って言うよね。寺田さんがどんなに「できるっしょ」って言っても「いや、わからないです」と返すじゃない（笑）。めちゃくちゃ千田さんらしいと思う。

千田：深く考えずに「できる」と言って、プロジェクトが大変なことになるのが嫌なんです。エンジニアとして、自分の考えや発言に責任を持ちたいじゃないですか。

藤倉：千田さんがSansanにいてくれてよかったと思うのが、まさにその部分なんだよね。僕はSansanの初期の頃からいて技術的な方針決定やマネジメントに携わってきたけど、自分自身も完璧なエンジニアではないから、判断が正しかったのか迷うことも正直ある。

そんなとき、千田さんが「いいと思う」と言ってくれると「だよね」と安心できるような信頼感があって。技術的な判断に対して正直な意見を言ってくれるのは、本当にありがたいことだと思う。

＜中編・後編＞

interview：中薗昴
photo：ブランドコミュニケーション部　高橋淳

*1:千田と同じチームになった期待のルーキーが、千田の愛のあるスパルタ指導を受ける会。千田塾を経験したメンバーは、その後に大きな飛躍を遂げるという噂。

Leaders Circle (in Google Cloud Next '19)

CTO の 藤倉 です。

すでに同行した弊社エンジニアからのレポートが上がっていますが、この 4 月にアメリカのサンフランシスコで開催された Google Cloud Next '19 に参加してきました。Google Coloud Next の内容については、それぞれの記事に任せるとして、私は Google Cloud Next の一部（？）として催されている Leaders Circle を中心にレポートしたいと思います。

buildersbox.corp-sansan.com

buildersbox.corp-sansan.com

Leaders Circle とは？

初日のレセプションパーティの様子。結構スーツの方もいますね。

Leaders Circle とは、Google Cloud Next イベントの一部として用意されているパッケージで、Google Cloud ユーザ企業におけるリーダー層の方々が参加する招待制のイベントです。その規模や内容は開催年度や場所（サンフランシスコ、ロンドン、東京）によっても様々なようですが、’19 のサンフランシスコでは、丸二日間に渡る密度の濃いものとなりました。参加者は、Google Cloud を社内システムの基盤として利用している各種業界の企業や、我々のように Google Cloud 上でプロダクトを開発してサービス提供しているような企業の方など様々です。

Google Cloud Next は 4 月の 9、10、11 の三日間で開催されましたが、Leaders Circle は前半の二日間を使って行われます。以下は Leaders Circle のスケジュール概要です。

4 月 9 日（火）

11:00 - 12:15 Leaders Circle Keynote
12:35 - 13:45 Regional Lunch
14:00 - 16:35 Sessions
19:00 - 22:00 Reception

4 月 10 日（水）

11:00 - 12:35 Sessions
12:45 - 14:15 Industry Lunch
14:20 - 15:00 Leaders Circle Closing Keynote
15:30 - 16:30 Happy Hour

Leaders Circle の基調講演では、最近特に注目されている DX (Digital Transformation) に焦点を当て、これは単にデータ（とそれを扱う技術）をビジネスに活用するだけではなく、企業文化そのものを変化させるものであるべきというメッセージが強調されていました。これは、参加者の中でも特に、エンタープライズ企業が Google Cloud を導入する動機として DX を挙げており、それを成功させるための秘訣として語られていたようです。単純に今までのやり方を踏襲しつつ、ただデータだけを意思決定に取り入れようとしても、当然うまくはいきません。これは、理屈では理解できるものの、実際には思った通りにできないことが多々あるわけです。それらに対する打開策については、セッションにおいて業態ごとの事例として語られていました。

Leaders Circle では、ネットワーキングのためのランチも提供されます。初日のランチは地域ごと、二日目は業界ごとにエリアが分かれており、世界各国から参加している方々や Google Cloud の担当者を交えての食事です。地域ごとのランチでは日本から参加されているエンタープライズ企業の CIO の方々もいて、普段はあまり持つことができない接点があったのが非常によかったです。当社では法人向けサービスの提供もしていることから、大企業の CIO の視点を学ぶことでの気づきも多くありました。また、業界別のランチでは、Google Cloud を社内インフラとして使うというよりは、サービスの基盤として使っている人たちが集まるため、話題の中心も Google Cloud で提供されている技術、特に今回発表があった Anthos などに話が集中します。

両日のスケジュールが 11:00 からなのは、その前に Google Cloud Next 本編の基調講演があるためです。私も基調講演を聴講した後に Leaders Circle の会場に移動しました。会場は隣接しているので、相互の移動が容易です。また、専用のラウンジも用意されているので、隙間の時間に作業をすることもできます。

Leaders Circle のラウンジ。もちろん電源も WiFi も完備です。

感想

イベントに参加するときは常にそうなのですが、特に海外のイベントに出て世界中の方々と交流をすることで、自分の目線を上げることができます。Google Cloud で提供される技術の話だけではなく、各社のエンジニアリングへの取り組みやその成功体験、学びなどを聞くたびに、まだまだ自分たちができることがたくさんあることを思い知らされます。エンジニアの育成や採用、チームビルド、技術課題の解決方法など、さらに加速させていかなければならないという想いを強くした二日間でした。

まとめ

Leaders Circle は招待制のイベントなので Web 上にはあまり情報がなく、実際に参加してみるまではどんな雰囲気なのかがわかりにくいです。私も参加を決める際にはいろいろと調べてみたけどよくわからないという状態でした。この記事でもあまり多くのことは書けないのですが、今後参加を検討されている方にとって少しでも参考になれば幸いです。

今回の Leaders Circle では、全編を通して Google Cloud がエンタープライズ領域に力を入れていこうとしていることがひしひしと伝わってきました。また、顧客の声に耳を傾ける姿勢も強調されており、この領域においても今後の成長が見逃せません。

なお、Leaders Circle 終了後の日程では、Google Cloud の OCTO（Office of the CTO の略。Google Cloud がユーザ企業の CTO をサポートするためのチーム）の方々と議論をしたり、Google キャンパスのある Mountain View に移動して各種サービスのプロダクトマネージャの方々とのプライベートなミーティングをするなど、最後まで充実した日々でした。