1.23 に恵比寿で開催されたCookpad Tech Conf 2016に行ってきました。公式ページはこちら

f:id:kentana20:20160124025832p:plain

タイムテーブル

No	Theme	Speaker
1	基調講演: ユーザーのために、技術をどう活かすか	舘野祐一 ( @hotchpotch )
2	おでかけスポット検索のむずかしさ - Holiday を支える検索技術	内藤雄介 ( @Yu_7110 )
3	Railsアプリ開発環境の高速化	国分崇志 ( @k0kubun )
4	R&D at Foodtech company	有賀康顕 ( @chezou )
5	技術力を事業の強みするために必要なこと	大野晋一
6	開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法	五十嵐啓人
7	「今日なに作ろう？」を支えるデザイン	木村真理 ( @mura24 )
8	確かめながら作るユーザー体験	出口貴也 ( @dex1t )
9	モバイルアプリのインタラクションプロトタイピング	多田圭佑
10	モバイルアプリ開発の"標準"を探る	藤吾郎 ( @__gfx__ )
11	DWHに必要なこと	青木峰郎 ( @mineroaoki )
12	基調講演: クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について	成田一生 ( @mirakui )

その内、すべてのセッションの資料が公開されると思います。

セッションメモ

やはり、というか基調講演のお二方(セコンさんとmirakuiさん)の2名のセッションが全体感があって、スライドの内容もわかりやすくてとてもよかったので、この2つのセッションにフォーカスして紹介したいと思います。

ユーザのために技術をどう活かすか( @hotchpotch )

CTOであるセコンさんのセッション。今日は 「ユーザファーストのための技術と組織」 という2つの点や情報共有についてのお話でした。

Cookpad社員数と構成、サービス規模

社員数と構成
- 250名(グループ会社含めて400名)
- ものづくりに関わっているのはだいたい100名くらい
  - エンジニア80名
  - デザイナー10名
  - 企画・ディレクター10名
サービス規模
- ユーザはだいたい5,500万人くらい

ユーザファースト

他にもこういったことを言ってる会社は結構多いが、他社と比べてもCookpadは 徹底してやっている のではないかと思う
Cookpadでは↓の2つを意識している
- ユーザファーストのための技術
  - 技術をユーザのためにどう使うのか
- ユーザファーストのための組織
  - どうやったらユーザファーストを実践しやすい組織になるか

ユーザファーストのための技術

エンジニアにすべてが求められる時代
- 求められる要素が多くなっている
- フルスタックエンジニアという言葉だったり

なんでもでやってくれ、と言わんばかりの要素
さらには技術だけじゃなくて、チーム作り、プロジェクトマネジメント、分析 etc...

ユーザのために技術をどう活かすか

仮説・検証・実行をできるだけ早く回すために必要なもの
- このサイクルを徹底的に磨くことを意識し続ける
- 「打席に立つ回数を上げる」ために技術をうまく使う
- 磨き続けることでユーザにとっての価値が何かを学習していく

このサイクルを高速化するための技術的取組みをいくつか。

仮説・実行で使われている技術
- Ex. Chanko
  - 一部のユーザに向けてプロトタイピングテストをするためのライブラリ(Gem)
  - OSSとして公開されている
検証で使われている技術
- Ex. Hakari
  - さまざまなメトリクスを図れる計測ツール
  - Kibanaっぽい感じのUIでした。こちらはOSSとしては公開されていない模様
ほかにもサイクルを早く回すための技術が数多くある
- サービスの機能が多くなって、テストが多くなり、デプロイに時間がかかるようになった
  - RRRSpecという分散テストツール(gem)を開発
  - テスト時間を圧縮してデプロイを高速化
ネイティブ開発
- アプリはサクッとリリースできない
- リリースしなくても仮説・検証・実行サイクルをどう回すかを考える
- Ex.
  - Flinto, Prottといったプロトタイピングツールを導入
Microservices
- Cf. コンウェイの法則
  - 組織を製品のアーキテクチャに当てはまるようにするべき、という話

エンジニアに求められること

変化を受け入れ、シーンに合った技術・開発を行う
- 変化できる組織とエンジニアを目指す
エンジニアに求められる技術
- ユーザ価値を提供するために何が必要かを考えて、技術を活かす
- 技術に強みを持って何が必要か(何が価値なのか)を考え実行する
プログラミングができるとか、プロジェクトをリードできるとか、個々の要素は当たり前のスキルとして持つ
- 当たり前のことを当たり前にやり続けることが大事

ユーザファーストのための組織

組織の形

集約型
- エンジニアだけの組織(チーム)をつくる
  - 事業部ごとにエンジニアを配置しない
- メリット
  - 技術知見の共有をしやすい
  - リソースの配分、最適化がしやすい
分散型
- いろいろな部署にエンジニアが配属
  - 事業部ごとにエンジニアを配置する
- メリット
  - チーム(事業)のビジョンを共有しやすい
  - 事業に対するナレッジを蓄積できる

会社や事業のステージ、方針などによってどっちが良いとかは全然異なるので、一概に「コッチのほうが良い」とは言えないと思っている。

Cookpadの組織

マトリクス型
- 横串の技術部・インフラ部
  - 基盤整備、インフラなどを担当
- 縦串の各部室・チーム
  - サービスや事業の背景共有(重要)をしつつ、集中して継続的な価値をつくる

いまはこの形になっているが、今後変わることもあると思っている。

情報共有

掛け算の組織にしたい
- 単純な人員数での成果ではなく、有機的にコラボレートして人員数以上の成果をあげたい
対面での情報共有と非対面での情報共有
- 対面: プロダクト編成会、技術リーダー会、デザイナー会など
- 非対面: Groupad, GitHub Enterprise

どちらも重視している

Groupad

Blog + Wiki的なサービス
- パッと見た感じ、はてなスターみたいな機能とか気軽にフィードバックできるような仕組みになっているっぽかったです
- 社内のカメラで写真を撮ると自動でアップされたりする
情報とコミュニケーション
- 解りやすく情報を伝える
  - 誰に何をどう伝えるかを日頃から意識することもユーザファーストにつながっている
  - それを日常的に考えて動く仕組みも組織作りの一環で、重要なこと
- 日々の情報発信
  - めちゃ大事
  - たとえば、開発者ブログ
    - 持ち回りでやっていて、効果もある

1人1人の成長の場をつくる

設計・実装・フィードバック
- GitHub Enterpriseを通したコードレビュー
  - 「デキる人」からのフィードバック
    - 詳しい人が1人いると、すごいスピードで伝搬していく
    - なんで？がすっきり解決する
様々な視点を得る
- 他の組織・開発を経験する
  - 自分が得たスキル・知見をさらに活用してチーム、組織にフィードバックする
  - 同時に他の組織に入ることで、自分が知らない視点のインプットにもつながる
- 100を120にするより、10を50にする方が効果的
  - とある知見を持っている人が、知見を持たない人がたくさんいる組織に入っていくことで組織全体がレベルアップしていく

自発的な組織改善

個人的にはこの部分がかなり刺さりました。

Cookpad Lounge
- 定期開催のキッチンでの料理＆飲みイベント
- 他部門とのコミュニケーションの活性化
- 自主的に企画＆開催
- エンジニアが始めたイベント
エンジニアも主体的に組織改善に関わる
- ちゃんと組織改善を評価する(評価制度もセットでないと、続かない)
- 社内外に良い影響を与えているか

質疑

ユーザファーストは創業当時から？
- 考え方自体は創業当時からあったものだけど、言葉にするとユーザファーストだったという感じ

クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について

インフラ部長である @mirakui さんの発表。

今日のテーマ

限られたリソースで、どうやって組織や事業の変化に強い開発をするか
長寿化したアプリケーショとどう向き合っていくか

これは両方共、今の一休.comに当てはまる部分が多いテーマで、とても興味深く聞かせていただきました。

前提

事業は変化する
組織も変化する
プロダクトやコードには寿命がある
開発リソースは有限である

事業やサービスの変化によって、コードも適切に変えていかなければいけない。

デカイアプリケーション

起動に時間がかかる
テストに時間がかかる
静的解析ツールが動かない
ライブラリが動かない
デプロイが大変
レールに乗れない

デカいだけで、いろいろなことがものすごく大変だったり、遅いせいで面倒になることが多いという話はとても共感できました。

コード、環境は老朽化

人は書き直したくなる
- 2010年頃にフルリニューアル計画
  - エンジニアは10名くらい
  - コードが巨大・複雑すぎて新機能の実装が困難
  - いまのサービスはこれでよいのか
  - コアな部分だけをつくって理想的なCookpadにしたい
サービスのコアバリューを抽出する
キレイなコードをスクラッチで書く

を2つを同時にやろうとして大失敗した。

学び: 仕様整理とリファクタリングは同時にやらないほうが良い

学び2: 手遅れになってからやらない

仕様整理とリファクタリングを同時にやり始めると、いつまで経っても仕様整理が落ち着かずに、効果的にリファクタリングできず、効率的に進めることができなくなる。「ココがもうヤバいから、なんとかしよう」という状況まで引っ張ってしまった時点でもう手遅れで、そうなる前にアクションしないといけない。2つとも、めっちゃよく分かる話。

2007のリニューアルはうまくいった？

Coldfusion -> Rails
- エンジニア5名くらい
決してうまくいってなかった
- サービス規模が小さかったからなんとかなった
- すでに壊れかけてたから、それ以上悪くなることはなかった
- 移行後、かなり不安定だった
- 若さで乗り切った

なぜ、書き直したかったのか

サービスを継続的な改善 がしたかった
- 謎のレガシーコードが多くて、機能追加・改善がめちゃやりづらく、継続的改善の支障となっていた

つまり、フルリニューアルでなくても

開発速度を落とさず、継続的な改善 ができればよかった

Chanko

リニューアル失敗が生み出したプロトタイプテスト用Gem A/Bテストをキレイなコードで書ける。

2012年頃は多サービス時代

脱・"World's largest rails monolith"

プロジェクト分割方針
- 本体と密結合にしなければいけないとき以外は新規サービスは別のRailsプロジェクト
- 既存サービスも分離できるものは順次分割していった

ref. もう失敗しない！プロジェクト書きなおして、最高の開発環境を手に入れる

本当は何がしたいのかを見極める

シンプルな作りにしたい
不要なコードが重なり、動作が遅くなっている部分を解消したい
新しい技術、ライブラリを取り込めるように

大事なこと

1つずつやる

おいしい健康を分離した話

第一段階
- forkして要らないコードを消す
- テストを通して、健全性を担保
第二段階
- rails newしたプロジェクトにコードを移植
注意
- ロジック移動のみ実施する
- リファクタリングしたくなっても我慢する
- テストをパスすることを重視
学び
- フルスクラッチで描き直さない
- 仕様、リファクタリングの変更をなるべくせずに分割していくと良いことがある
  - 小規模に少しずつ進めることで小さな成功体験(メリット)、事業的なメリットを享受できた

コード品質はビジネスに影響がある

Cookpadでは コード品質はビジネスに影響がある と考えている
コード品質が影響するもの
- 開発効率
- 属人性
- コード

どこまでやるべきなのか

きれいなコードを書くことが目的ではない
- 事業フェーズにとって必要な品質を目指す
コードレビューで担保する
- 質の高いコードレビューで品質をそれなりに担保する
- 負の遺産を残しにくくする
コードレビューアンチパターン
- もめる
  - インデント、括弧
  - とにかく不毛
コード規約はコードレビューの効率・コード品質向上に役に立つ
- GitHubに公開している
- 最初は反対意見も多かった
  - mirakuiさん自身も反対派だったらしい
- 重要なのはビジネスのコードレビュー
- コード品質に直接的には寄与しないが、効果はある

ここまでが開発についての事例でした。

インフラの老朽化

2011年(AWS移行), 2012年(VPC移行)

2度の移行
- よくわからないサーバは淘汰された(使っていないサーバの炙り出し)
- 全サーバは Infra as Code 化した
- OSや各種パッケージをアップデートできた
インフラの課題
- 存在しないサーバのmanifestファイルなど、不要なコードが残る
- OS, ミドルウェアのバージョンが古い
インフラ老朽化の特徴
- アプリケーションが動いていれば、老朽化問題が顕在化しない
- 大幅なバージョンアップは大変で時間がかかるので、必要になってからでは遅い

老朽化しないための式年遷宮

作りなおすことを前提にすることで、システムが長寿命化することを目指す

既に、Cookpadでもインフラの式年遷宮が計画されて、動き出している

まとめ

長生きする事業のために技術ができること・考えられること

事業の変化、限られたリソースをどう活かすか
品質や新しさを保つこと自体を仕組み化する
- 難しくなる前から計画する
- 少しずつやる
手遅れになる前に少しずつやる
小さな成功体験をつくり、アップデートの価値を組織に実感させる
- 「これくらいのコストでここまで成果が出てるなら、次のXXXもやりましょう」という流れをつくる

所感

セコンさんの発表や、他の技術セッションの発表で出ていた、開発環境を良くする仕取り組みで一休でも実践できている点が何箇所かあって、うまくできていてる部分もあると感じた
- Ex. 開発環境を自動構築する仕組み、開発環境から本番相当DBを参照する仕組み、CIを活かしてデプロイを高速化する仕組み etc..
エンジニア主体で社内のコミュニケーション活性化を図る取り組みと「エンジニアも組織改善に主体的に関わることを評価する文化・制度」が素晴らしいと思った
- Groupad的なBlog, Wiki機能の社内活用や、共有イベントを企画したりといったアクションについても当たり前のように継続してやっている点がすごいと思った。この部分は一休でもこれから強化していこうと思っているので、できるところからやっていきたい
mirakuiさんの発表であった 品質や新しさを保つこと自体を仕組み化する ことはとても良いと思った
- リソースは有限であり、「やりたいと思ってることが放置されっぱなし」という状態に陥りがちなので、ここは仕組み化しておくべきという話はとても共感できた