会社としてのリファレンスコードを描く株式会社ユーザベース

たけうち　ひでゆき

アジェンダ

自己&会社紹介CTO事件簿出自そして思想

会社としてのリファレンスコードを描く

まとめ

会社&自己紹介

会社紹介

株式会社ユーザベース

2008年4月創業従業員数: 約190名 (インターン等含む)

エンジニア数: 約40名日本、シンガポール、香港、上海 で展開

自己紹介

たけうち　ひでゆき@chimerast

イノベーション担当執行役員チーフテクノロジスト(=CTØ)好きなAWSサービスは

DynamoDB

プロダクト紹介

SPEEDA企業・業界分析プラットフォーム

全世界300万社超 / 550業界のデータ

100万件以上のM&A情報データ

2009年6月ローンチ

500社超に導入済み(国外含む)日本、シンガポール、香港、上海で展開

NEWSPICKS経済ニュース共有サービス

独自コンテンツの展開

45万ユーザ

企業の経営者層やビジネスマンに人気

アジェンダ

自己&会社紹介CTO事件簿出自そして思想

会社としてのリファレンスコードを描く

まとめ

CTO事件簿

恐怖!!!○○○○○完全消失事件

・・・中略・・・

復旧手順

1. 何はともあれ即座に対象を unmount

2. 手を休めてじっくり考える!!!3. read-only でマウント4. 今回は extundelete でファイルを復元

重要なこと

あきらめない心

コンピューター少年的知識

アジェンダ

自己&会社紹介CTO事件簿出自そして思想

会社としてのリファレンスコードを描く

まとめ

自分のCTOとしての役割を話す前に

どんな道を歩んできたのか

経歴を少し話させてください

出自

個人事業主時代

学部生時代から個人事業主として

色々仕事を請け負う

iアプリ向けJava製Webブラウザとか、ネットワーク技術の開発支援とかいろいろ作る

学んだこと

お金の事=クライアントの欲しいものを考えて開発すること

起業1社目取締役CTO修士1年の時に情報系学生3人で起業特に作るものを決めていなかったので請負い

起業したもう1社が忙しくなりほかの2人に迷惑をかけたので抜ける

学んだこと

ビジネスとはなんなのか分からない状態で

起業してみても何も出来ない

起業2社目代表取締役CEO個人事業主時代に知り合った人 & 高校時代の友達と起業

・・・略・・・

・・・中略・・・

結果

体を壊してしまい継続させる意思を持てず

作っていたサービスも先が見えなかったので

会社を解散&精算

学んだこと

自分一人で抱え込みすぎない

他の人がやってくれることはやってもらう

自分しか出来ないことをやる

簡単にほかの会社が参入できるようなもの

は作らない

株式会社ユーザベース(2008年～)2008年 体を壊して倒れている中、弟の紹介でリハビリがてらSPEEDAを作る2011年 社員になりチーフテクノロジストの肩書きをもらう

2013年 イノベーション担当執行役員という謎の役職につけられNewsPicksを作る現在に至る

自分の経験をもってメンバーに語る

ユーザーの欲しいものを第一に考えて作る

ビジネスとはなんなのか分からない状態で

システムを作っても良いものは出来ない

他の人がやってくれることはやってもらう

なにが自社のサービスの特徴であり参入障壁になっているのかを考える

愚者は経験によって学び

と言うけれども

経験したからこそ

語れることもある

思想

学生時代の研究対象

アスペクト指向プログラミング

ASPECTJの功罪メソッド呼び出しやフィールドの読み書き等のイベントの前後に処理を差し込む

アスペクト指向という言葉を広めるのには非

常に貢献

ただしアスペクト指向の一つの側面の実装で

あってアスペクト指向そのものではない

ASPECT-ORIENTEDPROGRAMMING

[KICZALES ECOOP'97]

一つのプログラミングモデルだけで

実際のシステムを作ろうとすると、うまく表現出来ない部分が出てくる

システムを複数の側面でとらえ、複数の異なるプログラミングモデルで書き

最後にそれらを織り込む(weave)プログラミング手法の提案

得意な部分をそれぞれ担当し

それらを組み合わせてシステム全体を織り上げる

会社とアスペクト指向

会社にも当然いろんな側面がある

いろいろな人の得意な事を組み合わせて、うまく織り上げればすばらしい会社が出来る

エンジニアはITが絡むことに関して万能だという考え方を否定する

全然関係無い分野のことでも

応用すると世界が広がる

アジェンダ

自己&会社紹介CTO事件簿出自そして思想

会社としてのリファレンスコードを描く

まとめ

会社としてのリファレンスコードを描く

自律的に動く組織

ユーザベースでは会社全体として、個々のチームが自律的に動く組織を目指す

チーム内チーム外で自律的にコミュニケーションを取り

事業を進めていく

2014年人数が増えて自分自身がボトルネックになるように

なってしまったときに

これの重要性を特に痛感

ユーザベースの事例

人のマネジメントをしないCTO

ユーザベース

技術チームの経営体制

CTØとしての仕事: 指針の提案技術者としての技術へのふれ方

技術者としてのビジネスへの関わり方

ビジネスサイドの技術者への関わり方

これとは別で下記もやっています

基盤技術開発 & 先端技術開発火消し

採用&広報

リファレンスコード

リファレンスコードの存在意義

何か議論をしようにも、ベースとなるものがなければ議論が出来ない

ある程度まともで、動くものでなければ議論の対象にならない

リファレンスコードである意味

実装コードであってはならない

自律的に動くためにはあくまで全員で実装

コード(=文化)をつくっていく会社の実態に即したものにしなければなら

ない

よりよい実装コード、多様なやり方が出てきて欲しい

リファレンスコードであるために

自分自身が体現して示す

口で言うだけでは説得力が無い

CTOが絶対であるという雰囲気を作らない俺たちがCTOを倒したみたいな雰囲気を作れると最高

エンジニアと戦うためにエンジニアリングでトップに立つ

CTOだからこうでなくてはならないこれをしなくてはならないという

固定観念を捨てる

エンジニアのリファレンスコード

世界と技術の話

指先だけで世界を変えられる

エンジニアが世界を変えられることを見せる

小さいことから大きなことまで

狭いエンジニアの世界だけで閉じない

世界に対して興味を持つ

世界が先、技術は世界を実現するために使うもの

まず先に実現したい世界の事を考える

明確にどんな技術で作るかが決まる

システムを組まなくても世界を作る方法は沢

山あることを知る

最小限の労力で最大の効果を生み出すシス

テムを組む方法を知る

技術とのつきあい方

技術って何だろう

問題が先にあって

その解決策として技術が存在する

新しい技術と向き合う

何かとエンジニアは新しいモノ好き

何の問題を解決しようとしているのか、それは今立ち向かっている問題と

同じものなのかよく見てから適用する

世界の事を考えることでよりよい技術が生まれる

目的と解決策を明確にする

世界の事を考えることでちゃんと使ってもら

える技術が生まれる

それはたとえエンジニアのための技術であっ

ても同じ

システムの作り方

高速に試行錯誤をできるように

設計の正当性よりも、いかに簡単に変更が可能なように作るか

設計をしなくていいという話ではない

スタートアップであるための必要条件

作らずにすむ方法はないか考える

エンジニアがコードを書くよりも、直接DBを叩いてもらう教育コストの方が安い場合も

ある

不要な車輪の再発明はしない

ジェバンニ文化

ジェバンニが一晩でやってくれました

しかしジェバンニは「間に合う」と即答してくれました

プロトタイピングを一晩で

技術プロトタイピング程度であれば、時間もかからないのでさっさとやる

ビジネスサイドへの技術力アピールにもなり、信頼関係が醸成される

昨日の夜一晩でやりましたと言うと良く効く

簡単に業務改善が出来るものならさくっと作る

エンジニアが少し手を動かせば、劇的に改善するものも多い

「NicoNico SPEENYA」

最近やってみていること

社外のリソースも使って目的を達成する

目的を達成するために社内だけで

頑張ってやる必要はないのでは？

オープンソースで会社を超えて解決する

明日のTech Pitchで話します

まとめ

マネジメントを極力しない

というやり方がある

自律分散協調型組織

会社としての方向づけを達成するために

リファレンスコードを提案する

という方法がある

完全に蛇足ですが

実際のプロダクトでも

社内のリファレンス実装を

よく書いてます

提　供

ご静聴ありがとうございました

QAなにかあれば