Alignment and Autonomyな組織づくり

はじめに

サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。

背景

現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。

メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置される、全社で見ても大規模な部署となっています。

課題感

モバイルアプリ「クックパッド」は2009年に最初のリリースが行われました。iOS, Android共に何度かリニューアルを経て今に至り、コードベースも関わる人の規模も大きなアプリです。部署としてはモバイルアプリの開発にフォーカスを行う中、このような環境下で価値を早く多く生み出していきたいという思いはあるものの、部署が立ち上がって2, 3ヶ月ほど経過した時点で次のような課題感を抱きました。

チーム内での課題

前述の通り、チーム規模も大きいものになっていることからか、なかなか開発のスピードが上がらないという現象が生まれていました。純粋に開発そのものの速さについての課感もありましたが、マネジメントの観点での課題が目立ちました。例えば、方向性の確認、デザインのすり合わせ待ちなど、チーム内でコミュニケーションの渋滞が起きるケースも少なくなく、「もっと意思決定を早く行い進めることができるはず」という考えを持っていました。

チーム外での課題

クックパッドでは、部署内の役割や施策の目的に応じて「グループ」という単位で組織を分割を行うケースが多くあります。たとえば私の部署では、レシピ検索の体験向上を目的にした「さがすグループ」調理後の料理の記録体験を目的にした「きろくグループ」など、期初の段階で幾つかのグループを設置していました。

一方、グループで分割されたメンバーは、良くも悪くもグループでの施策に閉じてしまう傾向がありました。たとえば「レシピをさがす観点で記録系プロダクトはどうあるべきか」「レシピの調理という観点で、記録のあるべき姿を考える」など、グループをまたいでサービスを捉え、どのような体験をユーザーに提供すべきか?という議論は十分に実施できていませんでした。

個人の成長の課題

前述のような観点での課題に対する取り組みを進め、部署の目標達成を目指す中、個人の成長を促す機会もしっかりつなげたい思いがありました。つまり、ただ業務効率の最適化を目指すだけではなく、業務を通じて個人の役割と責任範囲を広げ、結果として各メンバーが成長している状態を目指したいと考えました。

Spotifyモデルの適用

このような課題を解決する上で、自分たちだけでいろいろ試行錯誤を行うことも可能でしたが、まずは他社の「うまく回っている」開発スタイルについて事例調査をすすめることにしました。そんな中、Spotifyの考え方、カルチャーにたどり着きました。

この中で、特に注目したものは「Alignment and Autonomy」という考え方です。

f:id:ryokatsuma:20171009162924p:plain
図1: Alignment and Autonomy / Spotify engineering culture (part1) より引用

ここでの「Alignment」とは、いろいろなものや人を1つの考えのものに一致させていくこと、「Autonomy」とは、自律的に動いていくことです。これらの概念は、相反するものといっても過言ではないですが、「リーダーがどの課題をなぜ解くのかということにフォーカスし、どのように解くか?はチームに任せる」というアプローチによって、両立を目指そうとする考え方です。

会社の方向を向きながら、チームメンバーは自律的に垣根を超えて協力体制を作り進んでいく。これは、前述の課題に対して最適なアプローチで、理想の姿の1つとして目指していく価値はあるのでは?と考えました。

なぜSpotifyか?

Spotifyは以下のような特徴を持っています。

  • 組織の人数規模が数百人
  • グローバルな開発チームを構成
  • 音楽プレイヤーという1つのアプリケーションを多くのプラットフォームで展開

これらは、エンジニアが国内だけでも約100人、レシピサービス「Cookpad」をグローバルで展開するクックパッドの今の状況と非常に似ています。

また、Spotifyの取り組みについて研究、および言及されている文献も非常に数多くあります。たとえばHarvard Business Schoolでもその開発スタイルについて言及されており、アジャイル開発における1つのスタイルとして、デファクトスタンダードと言っても過言ではありません。

国内外含めていくつかの企業の事例を調査していましたが、これらの背景からSpotifyのモデルの導入検討は十分に価値があるものとして考えました。

Spotifyモデルの導入

以下の3つのステップでSpotifyモデルの導入を試みました。

ミッションの棚卸し

期初でも会社の方向性とそれに基いた部署で実施していくことのすり合わせは実施していましたが、Alignmentを改めて強化する観点で

  • 会社としてやるべきこと
  • 部やメンバー自身がやりたいと考えていること

を再整理しました。

前者は、「Spotify Rhythm」と呼ばれる全社的な戦略立案のフレームワークをそのまま採用しました。Data→Insight→Belief→Betという観点で現状を整理し、サービス開発の観点で「Company Bets (会社として賭けるもの)」について、上長(本部長)との議論を通じてお互いの認識を揃えました。また、後者は、私自身の考えや部署のグループリーダーたちの考えをもとに再整理しました。

結果として、部署で進めるテーマは期初に計画していたものと大きく変わることはありませんでしたが、Spotify Rhythmによって関係者の認識を改めて整理し、揃えることに大きく貢献をしました。

グループを撤廃した少人数のチーム編成

前述の通り、部署において「グループ」という構造を置くことで、メンバーは「これはxxグループの担当だから」と、グループ間の線引きを無意識に行ってしまうことがありました。 マネージメントの観点では、グループを作ることが重要ではなく、KPI達成に向けて目標管理を含めメンバーの日々のマネージメントを行うことが重要です。 そこで、思い切って組織構造上のグループを全て撤廃することにしました。メンバーは全て部付けにして、「みんな同じ立場である」ということを組織構造上で再認識してもらいました。

とはいえ、45人前後の部付けメンバーを全て直接私がマネジメントすることは不可能なので、さすがにチームの概念は導入します。チームはAutonomyを向上させる観点で以下の戦略で構成しました。

  • Spotify Rhythmで再定義した部署で開発をすすめるいくつかのテーマを「ミッション」と定義
    • たとえば「日本中の料理を記録する」「日本中の人がクックパッドで毎日の料理を見つけている状態にする」などのミッション
  • 各ミッションには、リーダー役として「ミッションオーナー」を設置する
  • ミッションに応じて1~2のチームに分割
  • 1チームは最大で5人前後
  • ロールは下記の人たちで構成し、チームによってはエンジニアはiOSエンジニアのみ、ディレクターはなしのようなケースも
    • チームリーダー(1チームの場合はミッションオーナーと同義)
    • エンジニア (バックエンド / iOS / Android)
    • デザイナ
    • ディレクター

f:id:ryokatsuma:20171010225406p:plain
図2: 組織構造の変更

人数を5人前後に絞っているのは、既存の10人前後のグループでの構成において、コミュニケーションに渋滞を引き起こし意思決定のスピードを下げていると判断したことが背景です。人数を絞った上で、ミッションに紐づくチームの役割を明確化することで、チーム内での意思決定を推し進めてAutonomyの強化を図りました。

余談ですが、ここでの「チームリーダー」のロールはエンジニアやデザイナ含めて若いメンバーにもどんどん挑戦してもらっています。チーム規模を小さくすることで、チームをまとめることが最悪うまくいかなかったとしても影響範囲を小さく留めることで、「将来的にミッションオーナーを任せたい人」「ミッションオーナーに興味がある人」「個人の役割を広げてもらいたい人」などに、積極的にトライをしてもらっています。

チームをまたいだ横断会の実施

小さいチームに分割しただけでは、結局既存のグループを分割しただけでチーム間の連携を取る、チームを俯瞰してユーザー体験を考えることは大きく変わらないと考えました。

そこで、ディレクターのチーム横断会、デザイナーのチーム横断会、Androidエンジニアのチーム横断会など、職種別の横断会を設けて、参加者のコンテキストを揃えた上で、お互いの持つ課題を解決できる環境を作ることにしました。各横断会では責任者を立て、それぞれの会ごとに最適な運営を実施しています。たとえば、ディレクター会ではチームを横断した知見共有を目的において、互いの施策に活かしたりスキルの向上に役立て、 iOSエンジニア共有会では、普段抱えている開発上での課題感や設計方針について議論をするなど、技術力の向上に繋がる取り組みを行っています。

このように、横断会を通じて、俯瞰して物事を捉え各メンバーのスキル向上の実現を試みています。

導入の結果

Spotifyモデルを導入し、組織構造に手を入れてから3ヶ月ほど経過しました。全て数字で測れるものではありませんが、次のような変化が見えてきました。

意思決定の速度向上

少人数のスモールチームを推し進めたことで、関係者とのコミュニケーションパスの数が減り、チームの中での意思決定を早く進められるようになりました。あわせて、少人数化を進めることによって施策における1人当たりの責任感が増すことになることで、施策における課題の定義の議論も徐々に活発になってきたように感じられます。

チーム間の協調

そもそもSpotifyモデル導入にあたって「もっとチーム間の協調を推し進めよう」という話をしていたという前提もありますが、「これはXXチームとやろうとしていることが似てるから、声をかけて一緒に進めよう」「XXチームが次の方向性を掘り下げようとしているみたいだから、話を聞きに行こう」のような会話が増えてきました。施策を進めるに上で、相乗効果を生み出すために、お互いに気を配る姿が見受けられます。

これらの効果の1つ1つはまだ小さいものではありますが、当初から期待している効果でした。継続的に取り組みを磨き込むことで、より高いレベルの「Alignment and Autonomyな組織」を目指したいと考えています。

新たな課題感

一方で、今回の取り組みを実施しても、また新たな課題感も感じています。

数字レベルでの成果

施策を遂行するスピードは上がってきていますが、まだまだ十分に数字レベルで目に見える効果が出てきているものは多くありません。より数字や効果の規模を意識した施策の進め方を考える必要がある、言い換えれば、Autonomyは高い状態になっているものの、施策の方向性についてのAlignmentはまだ高いレベルを目指す必要があると言えるでしょう。

もちろん、チームリーダーを含めて若いメンバーも多く、経験が十分に無いということもあると思いますが、同時にミッションに対して目指す方向性と高さについて、自分を含めてマネジメント側がメンバーと認識をもっと合わせていく必要があるでしょう。

開発そのもののスピード向上

作るものを決める、リリース計画を立てるなど、開発以外のマネジメントの観点において今回の取り組みによって開発のスピードの改善は進みました。 一方で、マネジメント以外での開発のスピード向上、つまり開発そのもののスピード向上については、今回の取り組みのスコープ外ではありますが、まだまだ工夫の余地があると考えています。

アプリ開発とWeb開発は当然、単純に比較することはできませんが、アイディアを形にしてユーザーに届けるまでに現状は大きな差があることは事実です。この点については、技術部など他部署を巻き込み、コードレビューや採用などいろんな観点で課題の整理と解決方法の模索をしているところです。スピードを上げることは同時に品質の問題も発生することになるので、なかなか難しいテーマですが、継続的に改善を目指していきたいです。

まとめ

規模が大きな組織において、意思決定のスピード向上や個人の成長を目指すために、Spotifyの開発モデルを自分たちなりに導入し、「Alignment and Autonomyな組織」を目指した経緯を述べました。背景として抱えていた課題感は少しづつ解決されてきたものもありますが、理想として目指したい状態とはまだまだギャップがあるのも事実です。

組織は生きもの」と(2年前から同じことを)言いますが、組織のサイズもメンバーも常に変化し続ける中、同じ取り組みをし続けても効果はありません。課題に対して、常に最適なアプローチを考え、時には外部から適切な手段を導入するなど、トライし続ける必要があります。読者の皆さんの周りでも規模はともかく、組織的な課題感があると思いますが、本エントリがそのトライの手助けになると幸いです。

また、「もっと良い組織を目指せるんじゃないの?」と思ってもらえた方は、ぜひ一緒により良い組織作りを目指しましょう!)

クックパッドのデータ活用基盤

インフラ部 & 技術部の青木峰郎です。 クックパッドでは全社的にAmazon Redshiftを中心としたデータ活用基盤を構築しています。 今日はその全体像についてお話ししたいと思います。

データ活用基盤の全体像

まず、以下にクックパッドのデータ活用基盤の全体像を示します。

f:id:mineroaoki:20171005230822p:plain

大きく分けると入力が2系統、内部処理が1系統、出力が3系統あります。 入力はMySQLからのインポートとログのロードがあり、どちらも独自に構築したシステムで行われています。 DB内部のデータ処理はSQLバッチのみです。 そして出力は管理画面やBIツールからのアクセスとバッチ処理によるエクスポートに大別できます。

以下1つずつ説明していきましょう。

入力その1: MySQLインポートシステム

MySQLからRedshiftへのマスターテーブル取り込みにも独自のインポートシステムを使っています。 このインポート処理には、つい最近まではごく普通のバッチジョブを使っていたのですが、 現在は独自開発の専用システム(pipelined-migrator)に乗り換えつつあります。

専用システムを作った理由は、インポートするテーブルの追加を誰でも簡単にできるようにするためです。 pipelined-migratorにはウェブベースの管理画面が付いており、 この画面からボタン1つでインポートするテーブルの追加や削除が行えます。 またインポート状況などを確認することもできます。

バッチとpipelined-migratorのいずれにしても、 MySQLからテーブルを取り込む方法としてはごく単純な全行ダンプ・全行ロードのみを実装しています。 分析システムの構築当初はbinlogを使った差分更新も検討したのですが、運用が面倒すぎることと、 「全行ロードでも間に合うから」という消極的な理由によってこの実装になりました。 将来的にパフォーマンスが間に合わないなどの理由があれば差分更新にするかもしれません。

入力その2: ログをロードするStreaming Loadシステム

ログのロードには自前で開発した bricolage-streaming-loaderbricolage-streaming-preprocessor を使っています。 loaderはRuby製でpreprocessorはJava製です。

このシステムは、一言で言うと、fluentdからS3に書き込んだJSONファイルを前処理しながらロードするシステムです。 またRedshiftはコミットの遅延が比較的大きいため、そこを軽減するためにバッファリングも行っています。 このシステムの設計方針については本ブログの過去の記事 「Amazon Redshiftへ継続的にデータをロードする際に気をつけること」 で詳しく説明しているので、そちらをごらんください。

このStreaming Loadシステムには専用の管理画面が用意されており、 ログが処理されていく様子を1オブジェクトずつ丁寧に見守ることができます。

入力その3: Redshift Spectrum向けロードシステム(未リリース)

さきほどの図には存在しませんでしたが、 RedshiftからS3のデータをアクセスできる「Redshift Spectrum」への対応も計画しています。 Spectrumはまだ東京リージョンに来ていないので計画に留めていますが、来た瞬間に稼働させるつもりです。

Spectrumを使う目的は、第1にログのロードのレイテンシを短縮すること、第2にディスク節約です。 特に、巨大なわりにあまりアクセスのない過去ログなどは、Spectrum(S3)に逃してやると、 Redshiftの高速性とS3の安価なストレージをいいとこ取りできるので大変いい選択肢だと思います。

データの加工: SQLバッチ

いったんRedshiftにデータを取り込んだら、あとは原則としてすべての処理をSQLで記述します。 このSQLによるバッチ処理はBricolageというSQLバッチフレームワークと、 ジョブ管理システムKuroko2の組み合わせで構築しました。

この2つについては過去にだいぶいろいろ書きましたので、 Bricolageについては 「巨大なバッチを分割して構成する 〜SQLバッチフレームワークBricolage〜」 を、 Kuroko2については 「クックパッドのジョブ管理システム kuroko2 の紹介」 を、それぞれごらんください。

Redshift内のデータアーキテクチャ

SQLバッチは全体で一番地味ですが、最も重要な部分でもあります。 データ分析基盤と言うとデータを取り込むところばかりが注目されがちですが、 データ取り込みは本番前の準備にすぎません。 その後ろに連なるデータの統合と分析こそがデータ「活用」の本丸です。

クックパッドではRedshift内を論理的に3層に区切り、 1つめを入力層、2つめを論理DWH層、3つめを論理データマート層としています。

入力層は名前の通り、他のデータソースからデータを入力する層です。 基本的に送られてきたデータが元のままの形でそのまま入っています。

論理DWH層は、いわゆるデータウェアハウス(Data WareHouse)です。 入力層のデータをクレンジングし、複数システムのデータを統合し、場合によっては集計もして、 全社の分析基盤となるデータを作ります。

……と書くとかっこいいですが、まだこの層はあまり成長させられていません。 まだここまで手が回っていないというのが正直なところで、今年末から来年にかけての最大の課題だと考えています。

最後の論理データマート層は特定のデータ分野ごとの特化領域です。 例えばクックパッドの場合だと、レシピ検索、広告、有料会員、レシピサービス、などの分野が存在します。

またこの層は対応する部がはっきり決まるので、その部に全権を委任しています。 逆に言うと、入力層とDWH層はインフラ部が管理しており、 他の部のメンバーが何か変更したい場合はpull requestが必須ということです。

これらの主要領域以外に、それぞれのメンバーは自分専用のスキーマを持つことができ、 その中では自分の自由にデータを加工・保存することができます。いわゆるサンドボックスです。 エンジニアはもちろん、ディレクターやプランナーも場合によっては自分のスキーマを持ち、 自分でSQLを書いて分析することがあります。 最近の社内におけるSQL熱の高まりを受けて、先日はインフラ部メンバーによる社内向けSQL講座も行われました。

出力その1, 2: BIツールと管理アプリからの参照

データベースへの入力と加工について話したので、残るは出力系です。 まずBIツールと管理アプリ(社内用ウェブアプリ)について話しましょう。

BIツールと管理アプリのアクセスは傾向が似ており、 ごく少量のメタデータ読み書きと、大量の統計データ読み込みが発生します。 前者はO/Rマッパーによる構造化されたアクセス、 後者は直SQLとカーソルを使ったアクセスが主になるでしょう。

Redshiftにおけるカーソルの特徴と使いかたについては過去の記事 「ActiveRecordを使ってRedshiftから大量のデータを効率的に読み出す」 を参照してください。

なお、BIツールとしては現在のところ、社内で動かしているRedashをメインに使っています。 しかし正直なところRedashはキューまわりのできが悪すぎて、 アドホックな社内ローカルパッチを大量に当ててなんとか回しているような状況です。 いま真剣に移行を検討しています。

移行先の第一候補はなんだかんだでTableauでしょうか。 Tableauは以前から細々と使ってはいたのですが、 ついにTableau ServerのLinux版が出そうなのでいよいよ本格導入の時かもしれません。

ところで、RedashやTableauは共有ダッシュボードを作るために使われることが多いですが、 それ以外に個人単位のアドホックな分析も多く行われます。 そのような目的には、Posticoのような普通のPostgreSQLクライアントや Jupyter、 それに弊社社員の外村が開発したbdashなどを使っています。 bdashは手軽にグラフが書けることと、過去のクエリーを記録しておける点が非常に便利で、 個人的にも気に入っています。

出力その3: バッチからの参照

3つめの出力系統は、主に他システムへのエクスポートを目的とした、バッチからの参照です。 以前はこの処理のためには単純にRedshiftへ接続してselectさせていたのですが、 最近はQueueryというHTTP APIシステムを挟むようにしています。

Queueryは、APIでselect文を受け付けて結果をS3にUNLOADし、そのURLを返すだけの単純なシステムです。 このシステムを作った一番の理由は、バッチからの読み込み方法をRedshiftのUNLOADだけに限定したかったという点です。

Redshiftのカーソルはleader nodeにデータをマテリアライズするうえに、カーソルがクローズされるまでコネクションを占有しつづけます。 いずれの特徴もleader nodeにかなり負荷をかけることになります。 そこを考えると、長時間に渡って大量のデータを転送する可能性のあるバッチアクセスは、ぜひともUNLOADにしておきたいのです。 UNLOADはcompute nodeからS3へ直接に、並列でデータを転送するので安心です。

また特に、Redshiftで作ったサマリーをMySQLへ単純転送する用途のためには、 redshift-connectorというRubyのライブラリ(gem)を用意して対応しました。 むろん、このredshift-connectorも抜かりなくQueueryに対応しています。

データベースのドキュメント: dmemo

さて、ここまでで、データを入れて、きれいにして、サマリーも作り、 他のシステムから参照・利用できるようになりました。ではそれで終わりでしょうか?

当然、違います。データを作ったら、それを使えるように説明する必要があります。 ようするにドキュメントがいるのです。

データのドキュメントのためには、これまた弊社社員の小室が開発したdmemoを使っています。 これにも過去記事があるので、詳しくは下記の記事をごらんください。

まとめ

今回はクックパッドのデータ活用基盤について、その全体像をお話ししました。 これまでそれぞれの部分について書いたり話したことはたくさんあったのですが、 よくよく考えてみると全体を説明したことがなかったので、この機会にまとめてご紹介しました。 過去に書きためてきたブログ資産も生かすことができて一石二鳥ですね! ネタが思い付かないときはまたこの手で行こうと思います。

[宣伝] 『ふつうのLinuxプログラミング』の第2版が出ました

www.amazon.co.jp

わたしが12年前(!)に書いた書籍『ふつうのLinuxプログラミング』の第2版が出版されました。 第2版には、各方面からリクエストされまくっていたKindle版もついに出ています。 よっしゃ、いっちょ久しぶりにLinuxでCでも書いたるか! などという(わりと珍しい)機会がありましたらぜひご活用ください。

しかし、なぜわたしがブログ当番のときに限ってこう毎年毎年新しい本が出るのか…… まったく狙っていないのに、本当に不思議です。

Cookpad Tech Kitchen #9 〜1行のログの向こう側〜 を開催しました!

こんにちは! @yoshiori です。

2017/07/26、技術系イベント「Cookpad Tech Kitchen #9 〜1行のログの向こう側〜Cookpad Tech Kitchen #9」を開催しました。 (はい。僕が記事公開するの忘れててだいぶ遅くなっちゃいました>< ごめんなさい)

クックパッドの技術的な知見を定期的にアウトプットすることを目的とする本イベント。第9回目となる今回は「ログの活用方法」をテーマに開催しました。(月に1回程度開催しています)

月間6000万ユーザが使っているクックパッドには大量のログが集まってきます。そのログを効果的に活用してサービスやユーザに還元するための取り組みについて、インフラ、広告事業、サービス開発それぞれの視点で知見の発表を行いました。

発表資料を交えてイベントのレポートをしたいと思います。

f:id:cookpadtech:20171003220443p:plain イベントページ:

Cookpad Tech Kitchen #9 〜1行のログの向こう側〜 - connpass

発表内容

「クックパッドのログをいい感じにしているアーキテクチャ」

一人目の発表者であるインフラストラクチャー部部長の星(@kani_b)は、SRE としてAWSやセキュリティ関連でのサービスインフラ改善に携わっています。

今回は AWS Summit Tokyo 2016 Developer Conference で発表した内容 の続きとして発表を行いました。 具体的な数字として Fluentd に流れているログベースで言うとデータ総量は 400 〜 600GB / 日、レコード数は 8 億レコード以上 / 日(秒間 8,000 〜 25,000 レコードくらい)という規模のデータを扱っています。これをどのように集めて処理しているのかを紹介しました。

資料

「広告ログのリアルタイム集計とその活用」

二人目の発表者であるマーケティングプロダクト開発部の渡辺(@wata_dev)は、主に配信基盤の改善やマーケティングプロダクト開発部で開発しているサービスの基盤周りのサポートを行っています。

クックパッドでは広告の配信も自社で行っており、そのためにどのようにログを活用しているのかを、過去どういった問題点があってそれをどのように解決していったか、異常検知だけではなく配信制御や在庫予測などなど広告配信というドメインで実際に必要になるケースを出しながら紹介しました。

資料

「ログを活用したサービス開発」

3人目の発表者であるサービス開発部の外村(@hokaccha)は、バックエンドからWebフロントエンド、モバイルアプリの開発など幅広い分野でCookpadのサービス開発に携わっています。

発表ではモバイルアプリのロギングのやりかたから始まり、実際のログの活用方法としてサービス開発側でログをどのように扱っているか、どう活かしているかを紹介しました。 行動分析としてログの設計、ログの分析やその可視化によってサービス改善の意思決定に使われていること、ログを利用した機能開発として調理予測という実際にログがサービスとして使われている事例を紹介しました。

資料

「ログ」をテーマにしたご飯も登場!

クックパッドのイベントではご来場の感謝を込めて、会場で手作りしたご飯でおもてなしをします(食べながら飲みながら発表を聞いていただくスタイル)。今回はテーマである「ログ」にちなんだメニューを用意してもらいました。

f:id:cookpadtech:20171003220752j:plain

こちらはメッセージ入りのライスケーキ。クックパッドのインフラエンジニアが大切にしている言葉に「1行のログの向こうには1人のユーザがいる」というものがあります。画面で見るとたった1行のログだけど、その向こうには大切にすべき1人のユーザがいる、ということを思い出させてくれる合言葉です!

f:id:cookpadtech:20171003221913j:plain

川嶋シェフの粋な心意気で、素敵なメッセージもテーブルに並びました。

f:id:cookpadtech:20171003221721j:plain

こちらはログ=丸太をイメージした湯葉のデザートです。中に入っているのは甘すぎないところがおいしいあんこです。

まとめ

いかがでしたか。クックパッドでは毎月テーマを変えて技術イベントを開催しています。ご興味のある方は是非ご応募ください。

cookpad.connpass.com

新しい仲間を募集中

■ 日本最大の食のビッグデータを扱う「データ基盤」の開発に興味がある方 https://info.cookpad.com/careers/jobs/careers/data-infra-engineer

■ 広告事業の「Webアプリケーション開発」に興味がある方 https://info.cookpad.com/careers/jobs/careers/marketing-product-engineer

■ クックパッドアプリの「Webアプリケーション開発」に興味がある方 https://info.cookpad.com/careers/jobs/careers/software-engineer

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('http://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('http://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/