IVS CTO Night & Day 2014に参加してきた
http://www.infinityventures.com/ivs/cto/
http://www.infinityventures.com/ivs/cto/
今回初の取り組みとなる、IVSに併設されたIVS CTO Night & Day 2014というCTO同士のイベントに参加をしてきました。内容が非常に素晴らしかったのでブログに書いてみたいと思います。
IVSとは
まず、知らない方もいるかもしれないのでIVSのおさらいからです。
Infinity Ventures Summit（インフィニティ・ベンチャーズ・サミット。以下IVS） は、インターネット、モバイル、ソフトウエアなどＩＴ業界の国内外の経営者・経営幹部を対象とした年2回の招待制のオフサイト・カンファレンスを中心に新サービスの発表の場「Launch Pad」、未来を日本を支える学生に対して起業家教育を行う「ワークショップ」などベンチャー起業の生態系・コミュニティ作りに力をいれています。動画や書き起こしの記事などの情報発信にも力を入れております。
http://www.infinityventures.com/ivs/
年に２回開催される、経営者同士のイベントです。CTOという立場の方で参加している人はあまりいませんが、私も2014年5月に代表の古川と一緒に参加しすごく刺激を受けたことを覚えています。
そして今回は、IVSとAmazonの共同主催でさらに技術によったCTO向けのイベントが実現しました。
どんな内容を話したのか
前夜祭的なものを含め、3日間にわたって実施されました。登壇やパネルディスカッション、アンカンファレンスといった様々な形式で実施されました。
内容としては技術的な内容もありましたが、全体的にはやっぱりCTOという目線での話がおおかったなぁという印象です。とくに評価制度などは盛り上がる内容だなぁと。ただ、テーマによってはセンシティブな内容もあるので、細かい内容はブログとしてはあえて書かないようにします。
私自身は技術選定に関するお話をしましたが、どちらかというとこれも組織的な内容です。これは公開しても問題ない内容です。資料はこちらにあげましたのでどうぞ。
https://speakerdeck.com/wadap/how-to-choose-technology
IVSとCTO Nightが併設されたことのメリット
IVSと同時に実施されたことのメリットは、個人的には大きく３点あったと思っています。
- 地方で３日間開催された
- Launch Padを見ることができた
- CTO NightでCEOセッションがあった
それぞれ自分なりの考察をまとめます。
地方で３日間開催された
まぁ100%思いますよね、地方行く意味ねぇだろって。これIVSに参加するまで僕も思っていました。このエントリを拾い読みした人は確実にdisりtweetしちゃいそうな気もします。
しかし、実際に行ってみるとこれがよかったりします。東京で実施されたら確実に途中で会議で抜けることがありますし、すごく中途半端な参加になってしまいます。
普段の業務から抜けて、経営陣として・CTOとしてという立場で議論したりセッションを聞いたりという事自体がすごく大切なんだと思います。また、懇親会もじっくり話すことができるので、久々にあった人たちともちゃんと話すことができるのもメリットだなと思っています。
Launch Padを見ることができた
IVSの目玉でもある、LaunchPadを生で見ることができるというのはすごい価値だなぁと。LaunchPadに出ている人はとにかくプレゼンがうまい。サービスも素晴らしいし、とにかく刺激を受けることができます。
オンラインでも見ることができますが、やっぱりあの緊張感というか雰囲気を生で見ることができるのはすごい価値だなぁと思います。また今回は、前職の同期が登壇するということもありより楽しみでした。
Launch Pad 勝者はギャラクシーエージェンシー「akippa（あきっぱ）」 #IVS 2014 Fall Kyoto | BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
CTO NightでCEOセッションがあった
そして、最後はこれ。うちの代表もでていましたが「CEOからCTOへ」というなかなか無いテーマでのセッションがすごく良かったなぁと思います。これもIVSと同時開催していないとできない内容です。
100人いるCTOに向けて、社長同士がパネルディスカッションをする機会ってなかなかないですよね。しかもそこに登壇しているCEOの会社のCTOは全員その場にいたので、やりづらかったとは思いますがこういう機会って頻繁にあっても良いと思うんですよね。むしろ、IVS側でCTOが話すとかもあっても良いと思います。
おなじ経営陣である以上、お互いの仕事のことはよく知るべきだしどう考えているかは会社によって確実に違うのでそういった場はもっとできるべきだなぁと思いました。
今回参加してよかったこと
とまぁ、普段の業務から離れてこうやって議論したり話を聞いたりできるのは本当に素晴らしい会だったなぁと思います。なんとなく恒例になってしまった「CTO事件簿」という昔やっちゃった話の共有なんかもああいう場くらいでしか話せないのでなかなかよかったなぁと。
今回はAmazonさんがいろいろと企画してくれていましたが、ぜひ今後もこういったイベントは続けていってほしいなぁと思っています。今回は呼んでいただき、本当にありがとうございました。次回の開催も期待していますので、ぜひともよろしくお願いいたします！
nanapiのこれから、変わることと変わらないこと
すでにメディアで取り上げられているのでご存じの方もいると思いますが、本日このような発表をいたしました。
変わること
「変わることと」表現していますが、我々がもともとやろうとしている「What」の部分が変わるわけではありません。あくまで「What」を叶えるための「How」の部分が変わるだけです。
株式会社nanapiは「できることをふやす」というミッションを掲げています。そのミッションをいかにして達成するのかを考えた結果、もっとも最適な選択肢として今回の結果になりました。
変わらないこと
連結子会社となっていますが、株式会社nanapiとしては基本的にやることは変わりません。我々が運営するnanapi.jpやアンサーに関しても今までどおり運用し続けますし、これからもよりよいサービスになるよう進化をし続けます。
いろいろな勉強会で登壇するときにいつも言っている通り、nanapiは技術を軸にした風土を重視しています。
こういった風土は変わりませんし、いままで以上により大切にしていきたいと思っています。すでにあるサービスに囚われることなく、これからもどんどんと新しい価値を創造できるようなサービスを作っていきます。
nanapiのこれから
nanapiをリリースした2009年はiPhone3GSが出たばかりでまだまだスマホが日本においてはそこまで普及しておらず、携帯といえばフィーチャーフォンが全盛期の時代でした。
しかし、時代は変わりインターネットをブラウザだけで使う時代ではなくなってきています。アプリがあり、IoTという考え方も普及してきていて確実に5年前と業界は変わりつつあります。
また、いまから5年後もそれと同等かそれ以上の変化をし続けることでしょう。そこでnanapiが会社としてできることは、変化し続ける時代に対応し新しい価値を生み続けることです。そして、その場を提供する。これが株式会社nanapiとしてこれまでやってきたことで、これからもやりつづけなければいけないことです。
だからこそ、今まで以上に良いサービスを作り続けていき、新しい価値を創出し続けていきたいと思っています。
元ロッキーの名物店長が新しく作る馬肉専門店「Roast horse」を全力応援したい！
一部の渋谷IT界隈で有名なお店、ロッキー馬力屋の元店長が独立して新しいお店を作ろうとされています。ご存知の方もいると思いすが、ロッキーといえば馬肉がとにかく美味しいお店です。
そんなロッキーの元店長である、平山峰吉さんが次作る店舗への支援プロジェクトが立ち上がっています。とにかく応援したい！
日本一の馬肉専門店で、石釜で焼いた最高のローストホースを食べさせたい！ ｜マクアケ - アタラシイものや体験の応援購入サービス
なぜクラウンドファンディングか
今回新しく作るお店の名物は、石窯で調理した馬肉だそうです。まだ味わったことはありませんが、写真を見る限りとにかく美味しそうですね・・・しかしながら、この石窯は非常に高価で、今回はそのためにクラウンドファンディングを活用するとのこと。
どんな馬肉が食べられるのか、想像できません。ただ、うまいことは確実だと言えるのでそれだけで楽しみです。
ステマじゃないよ
こういったことを書くと「ステマ乙」とか絶対に言われてしまいますが、当然ですがステマではありません。ステルスしてないし、マーケティングじゃないし、そもそもお金もらってるわけないし。
私はこのプロジェクトの支援者のうちのひとりとしてただ応援したいだけでブログを書いています。理由は単純です。平山さんを応援したい、そしてうまい馬肉を食べたいという理由です。
というわけで是非応援したい、と思う方はぜひこちらからどうぞ！
日本一の馬肉専門店で、石釜で焼いた最高のローストホースを食べさせたい！ ｜マクアケ - アタラシイものや体験の応援購入サービス
fluentdで集約したerror_logをslackに流すと捗る
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。
http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/
ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。
ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあると思います。
集約したログもchatに流す
というわけで、error_logもChatに流したほうが捗るよねという話です。fluentdはみんな使っていると思うのでこのあたりの細かい説明は割愛します。Slackに流すためのpluginもすでに開発されています。
GitHub - sowawa/fluent-plugin-slack
これをつかうことで簡単に流すことができます。ただ、そのままだと若干不便なのでnanapiの設定の仕方を紹介します。使用するPluginはこのあたりです。
次からは、設定方法を紹介します。
環境構築用のVagrant
とりあえず試すにはVagrant + Chef + Berkshelfを使うのが便利です。td-agent用のcookbookが用意されているので、それを使ってインストールがラクでしょう。Vagrantfileは以下のようになります。
# -*- coding:utf-8 mode:ruby -*- Vagrant.configure('2') do |config| config.berkshelf.enabled = true config.vm.define :vm do |config| config.vm.box = 'centos-6.4' config.vm.box_url = 'http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130731.box' config.vm.provision :chef_solo do |chef| chef.json = { 'td_agent' => { 'plugins' => [ 'file-alternative', 'forest', 'slack', 'rewrite-tag-filter', ], } } chef.run_list = [ 'recipe[td-agent]', ] end end end
ログ送信側のtd-agent.conf
まず、error_logを集約する必要があります。fluentdは標準でapacheもcombinedをparseする設定をもってくれていますが、error_logはそのままだと動きません。以下のようにして、設定することでerror_logをちゃんと取得できます。
<source>
type forward
port 24224
</source>
<source>
type tail
format apache
path /var/log/httpd/access_log
pos_file /tmp/access_log.pos
tag nanapi.httpd.access_log
</source>
<source>
type tail
format /^\[[^ ]* (?<time>[^\]]*)\] \[(?<level>[^\]]*)\] (?<message>.*)$/
time_format %b %d %H:%M:%S.%L %Y
pos_file /tmp/error_log.pos
path /var/log/httpd/error_log
tag nanapi.httpd.error_log
</source>
# apache logs
<match **.**>
type forward
<server>
host forward_host
port 24224
</server>
</match>
APIKEYの発行
SlackのIncomingWebHookという機能を使います。以下のURLからアクセスできます。
https://xxx.slack.com/services/new
ここから設定すると、この画面にいきます。このURLの中で指定されているTokenがあとで使用するAPIKEYになります。
集約した側のtd-agent.conf
さて、つぎは集約してSlackに送る側の設定です。まず
そして、そのあと、rewrite_tag_filterを経由してerror_logのlog_levelをみてタグを付け直しています。これによって
<source>
type forward
</source>
<match {nanapi,nanapiworks}.httpd.error_log>
type copy
<store>
type forest
subtype file_alternative
<template>
buffer_chunk_limit 2g
path /var/log/fluent/${tag_parts[0]}/httpd/%Y/%m%d/${tag_parts[2]}.%Y%m%d
time_slice_format %Y%m%d
compress gzip
</template>
</store>
<store>
type rewrite_tag_filter
rewriterule1 level error slack.error
</store>
</match>
<match slack.**>
type buffered_slack
api_key xxxxxxxxxxxxxx
team xxxxxx
channel %23fluentd
username fluentd
color danger
icon_emoji :fluentd:
buffer_path /tmp/td_slack_buffer
flush_interval 5s
</match>
より効率的なchannel運用を
さて、こんな感じでerror_logを運用していたりします。slackのpluginは設定にもある通り、colorなども設定できます。このあたりと、投稿するchannelをうまく設定することでベストなerror_log運用を目指したいですね。
JAMTRACK CENTRALを知った
最近知ったのですが、こんなサービスがあるんですね。
ギタリスト向けのサービスで、プロギタリストの曲の楽譜＋動画＋オケトラックが販売されているサイトです。僕が知っている有名なギタリストもそこそこいました。
実際は、このサイトをしるきっかけになったギタリストがいます。Jack Thammaratというギタリストでこのサイト内で販売もされています。この曲に完全に虜になってしまい、つい購入してしまいました。
Jack Thammarat - "Awakening" (Original) Live in ...
iTunesでも販売されていますが、素晴らしいギタリストだなぁと思います。なんかの大会の優勝者らしいですね。タイの方のようです。
アンプもLANEYとエンドース契約をしているみたいですね。素晴らしい音しています。あまり高くないしちょっと気になるところですね。
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=451%5Eirtstudio%5E%5E
文章の書き方を変えるだけで社内の情報共有は加速する
社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。
そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。
生産性を向上させる情報共有ツール - キータチーム（Qiita Team）
全員がMarkdownで文章を書く
実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。
Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書くことができます。これが情報共有においてはすごく重要なことだと思っています。
文章構造を意識する
Markdownで文章を記述するということは、ちゃんと文章構造を考えて書く必要があります。マークアップほどこだわる必要もありませんが、headingやparagraphやlistくらいは理解する必要がありますね。
このあたりをしっかりと使いこなすということは、結果的に文章が簡潔になり読みやすくなりますよね。
最初から出来ないにしても、nanapiでは社内がそのような文化になっているため全員ができてあたりまえという風土になっています。その結果、メンバー全員が簡潔な文章をかけるようになり、より意思疎通がスムーズできるようになっています。
個人依存の記号は使わない
よくあるパターンが、アジェンダや議事録でその人ルールの記号がでてくる場合です。
☆本日のアジェンダ 【議題１】次期プロジェクトについて ＜決議事項＞ ・プロジェクトメンバー ・予算 ・リリーススケジュール
恐らくこういったテキストを目にしたことがある方は多くいるのではないでしょうか。テキストを書いた本人にしかわからない、謎の記号であふれています。
たちがわるい場合は、アジェンダや議事録によって記号の意味が変わります。こういった訳のわからない独自ルールを使わせないという意味でも、Markdown化する意味はあると思います。
スピードが大事
議事録など、会議が終わった瞬間に出てて欲しいんですよ。Qiita:TeamならPull Requestみたいなのが送れるし、違っていたらすぐに指摘できます。
でも会議がおわって翌日に議事録があがる時点で価値が半減します。参加した人の記憶も薄れるからです。お互いに記憶が新鮮なうちにブラッシュアップしなければいけない。
もっというと、プロジェクタに映しながら直接Markdownで書きながら終わった時点で議事録があがってるくらいにすべきですね。
どのようにして社内に浸透させるか
これは導入した人が必死に書き続けるしか無いです。そのようにして社内の風土は形成されますし、口でいうより使い方を見せた方が早いです。
nanapiでは以下の順番で広めました。
- 和田１人が書き続ける
- エンジニア中心に展開
- デザイナー・ディレクターを含め展開
- 全社員に展開
- アルバイトを含めた全従業員に展開
実際に、非常にうまくワークしていると思います。やり方はいろいろあると思いますが、変に敷居をあげすぎずにとりあえず投稿させていくというところから始めるのがコツなのかな、と思っています。
最後に
というわけで、文章の共有方法についてすこし考えてみました。重要なのは、自分のやっていることを自分に閉じないような風土にすることだと思っています。
これにより社内の情報共有は加速しますし、確実に成果がでるものだと思っています。nanapiではTechBlogをやっていることもあるので、社内・社外問わずこれからも情報発信を続けていきたいと思っています。
