20140410_geechs_nanapi_pub.pdf

Transcript

1. nanapiを支える技術 株式会社nanapi Co-Founder 取締役 執行役員 CTO 和田修一
2. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
3. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
4. 自己紹介 • 和田修一 / @wadap • 1981年生まれ（32歳） • 株式会社nanapi Co-Founder
 取締役 執行役員 CTO • インフラ〜サーバサイド開発 • emacs
5. 略歴 • 2005年 新卒にて楽天株式会社へ入社
 サーバ・インフラ系の部署に配属される • 2009年 楽天を退職し、弊社代表の古川と起業
 ロケットスタートCTO（旧社名）に就任 • 2011年 社名を株式会社nanapiへ変更
 株式会社nanapi 取締役 執行役員 CTOに就任
6. 主な仕事 • テクノロジーの文化を社内に浸透させること • エンジニア・デザイナーの採用活動 • nanapiすべてのインフラ • 役員業務もろもろ
7. 個人的にやってること 6/*9తͳΞϨ
   IUUQXBEBQIBUFOBCMPHDPN 6OJYͷೖ໳ߨ࠲
   IUUQTDIPPKQDMBTT
8. ஫ྗαʔϏε w ੜ׆ͷ஌ܙ͕ू·ΔαΠτ
 IUUQOBOBQJKQ
   w ༷ʑͳϋ΢πʔΛఏڙ͢Δα Πτͱͯ͠ϦϦʔε
   w ೥݄̍̕೔ϦϦʔε
   w ݄ؒສ66
 ݄ؒສ7JTJUPS
9. • 即レスQAアプリアンサー
 「アンサー」で検索！ • 質問してから数分以内に回答 がくるのが特徴 • 2013年12月リリース
 LineQとリリース被った！ ஫ྗαʔϏε
10. • 英語圏の人に向けた新サービ スをリリース • 4/1にリリース！
 ※国内へは未告知 • 英語圏を中心に展開をしてい く予定 ஫ྗαʔϏε
11. • ライタープラットフォーム
 http://works.nanapi.jp • 記事を書いてお金を貰えるク ラウドソーシングのサービス • 2010年8月リリース ライタープラットフォーム
12. • 特定のジャンルに特化したメ ディアを複数作成 • 月間300万〜400万PVほど • 数十ジャンルのメディアをリ リース済み • iOSアプリやAndroidアプリで も展開済み バーティカルメディア
13. • 取締役 3名 • 正社員 30名 • 従業員 75名（アルバイト含） 会社規模
14. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
15. nanapiの開発体制
16. 現在に至るまで ೥ʙ೥લ൒ ೥ ೥ ೥ ೥ ໊ ໊ ໊ ໊ ໊
17. 現在の組織体制 OBOBQJ Ξϯαʔ άϩʔόϧ &OHJOFFS &OHJOFFS &OHJOFFS Πϯϑϥσʔλղੳج൘
18. 事業単位にアサイン • nanapiのエンジニアはただコードを書く人ではな く、サービスをつくるクリエイター • ディレクター、エンジニア、デザイナーの距離を短 くし、相互に事業を理解し高速に開発するため • 職種を超えてサービスに対するアイデアは常に活発 に議論されるようになる
19. 職種間の情報共有 • デイリースタンドアップミーティング • 月１の社内勉強会 • 気になる情報は随時ChatworkとQiitaで共有
20. Chatworkでコミュニケーション
21. Team:Qiitaで情報共有
22. 開発フロー
23. プロジェクトの進め方 • 大枠のプロジェクトの進め方は、基本的に各プロジェ クトにお任せ • 現在は、全プロジェクトがスクラム開発を実施 • タスク管理には、ホワイトボードを使ったカンバン を活用
24. 実際に運用中のカンバン
25. スクラムのやり方 • 週のあたまに、対象となる期間（2週間くらい）の タスクを洗い出し、その工数を見積もる • TODO/DOING/DONE という３種類のステータス で管理をする • 毎朝の朝会で各タスクの進捗を確認する
26. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
27. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
28. • bugなどだけでなく、必要そう な項目はエンジニアでもどん どん追記 • チケット管理機能としては若 干シンプルだが、その分扱い やすい issuesの作成
29. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
30. 開発用にbranch作成 GFBUVSFcIPUpY JTTVFTͷ*%આ໌తͳϒϥϯν໊
31. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
32. • プロジェクト単位でエンジニ アのチャットが作成されてい る • その担当プロジェクトのチャッ トルームに、PullRequestの情 報が通知でくる • この情報をベースにコードレ ビューを実施 Pull Request
33. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
34. • コードレビューはGithub上で 行われる • PullRequestのコメントに対し て、いろいろかく • 問題なければ見たよアピール • 自動テストの結果もJenkinsが コメントとして通知してくれ る コードレビュー
35. 開発の流れ NBTUFS͔Β։ൃ༻ʹCSBODI࡞੒ CSBODIΛQVTI͠ɺQVMM
    SFRVFTU ίʔυϨϏϡʔޙɺNBTUFS΁NFSHF NBTUFS΁QVTIࣗ͠ಈUFTU
    
    ࣗಈEFQMPZ ̍ͭͷJTTVFTʹରͯ͠ɺCSBODIΛ ࡞੒͢Δ QVMM
    SFRVFTUΛૹΔ͜ͱͰɺࣗಈత ʹࣾ಺DIBU΁௨஌ NFSHF࡞ۀ͸HJUIVC্Ͱ͸࣮ࢪͤ ͣʹɺ։ൃ؀ڥ্Ͱ࣮ࢪ NBTUFS΁QVTI͢Δ͜ͱͰ͋ͱ͸͢ ΂ͯࣗಈͰ࣮ߦ͞ΕΔ JTTVFTΛ࡞੒ εΫϥϜͰ؅ཧ͞ΕͨλεΫΛݩʹ JTTVFTΛ࡞੒͢Δ
36. • Pushした通知をGithubから受 け取り、Jenkinsからテストを 実施 • テスト結果が問題なければ、 本番サーバへソースコードを Deploy • capistranoを裏側で実行 • その他Cache ClearなどのJob も搭載されている 自動test & 自動deploy
37. • nanapi botちゃんにツンデレ 気味に怒られる • テストが通っても、やっぱり 何故かツンデレ
 
 ※セリフを考えてるのは僕で はありません テストがおちたら
38. • 新しいプロジェクトでは、CI 専用のサービスを利用 • Jenkins＋テストサーバの運用 負荷は結構高い • CircleCIからTravisに移行して いく予定 • DeployもCIツール経由で実施 自動テストにCIツールを
39. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
40. なぜChefか？ • その手順書はメンテナンスされている？ • 手順書通りに開発環境も本番環境もつくられてる？ • 個々の開発環境を使いたいときどうするの？ • 100台のサーバでも同じことできんの？
 etc…
41. • インフラにおける作業を独自 DSLで記述することができる • Rubyで直接書くことも可能 • OSの違いなども抽象化するこ とで吸収 • 同様のツールでPuppetなど Chefを使った管理
42. 以下のrecipeで実現 remote_file "/tmp/httpd-2.2.22.tar.gz" do source "http://ftp.meisei-u.ac.jp/httpd/httpd-2.2.22.tar.gz" owner "root" group "root" mode "0644" end ! script "install httpd" do interpreter "bash" user "root" cwd Chef::Config[:file_cache_path] ! code <<-EOH tar xf httpd-2.2.22.tar.gz && cd httpd-2.2.22 ./configure make && make test && make install EOH end
43. サーバ管理方法 • すべてのサーバのセットアップ＋管理は、Chefを 通じて実行する • 本番環境や開発環境を含めると、様々な環境がある がすべてChefを経由して管理 • 直接サーバに入ってのroot作業禁止！
44. サーバ管理のいままで ̍୆ʙ̑୆͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ
    ֤αʔό͝ͱʹઃఆϑΝΠϧΛผ؅ཧ ̑୆ʙ̍̌୆͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங
    ѱ͘͸ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘౗ͩͬͨ ̍̌୆ʙ̎̌୆͘Β͍ DIFGTPMP
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ్த͔Β͸ɺLOJGFTPMP΋׆༻ ̎̌୆͘Β͍ʙ $IFG
    4FSWFS
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ։ൃ؀ڥ΋ಉҰͷDPPLCPPLͰӡ༻Մೳʹ
45. サーバ管理のいままで ̍୆ʙ̑୆͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ
    ֤αʔό͝ͱʹઃఆϑΝΠϧΛผ؅ཧ ̑୆ʙ̍̌୆͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங
    ѱ͘͸ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘౗ͩͬͨ ̍̌୆ʙ̎̌୆͘Β͍ DIFGTPMP
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ్த͔Β͸ɺLOJGFTPMP΋׆༻ ̎̌୆͘Β͍ʙ $IFG
    4FSWFS
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ։ൃ؀ڥ΋ಉҰͷDPPLCPPLͰӡ༻Մೳʹ
46. • よくあるオールドスタイルな 構築方法 • 100％ミスが起きるし、何よ りもめんどくさい • wikiもあまり更新されなくな るし、作業が属人化サれてい く 手順書がんばるモデル
47. • 各サーバ固有情報が入る設定 ファイル配布がきつい • ApacheのIPアドレスなどがは いるときなどがある • それぞれのホストごとに設定 ファイルを管理して、svn up • (´；ω；｀)ﾌﾞﾜｯ 手順書がんばるモデル
48. サーバ管理のいままで ̍୆ʙ̑୆͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ
    ֤αʔό͝ͱʹઃఆϑΝΠϧΛผ؅ཧ ̑୆ʙ̍̌୆͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங
    ѱ͘͸ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘౗ͩͬͨ ̍̌୆ʙ̎̌୆͘Β͍ DIFGTPMP
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ్த͔Β͸ɺLOJGFTPMP΋׆༻ ̎̌୆͘Β͍ʙ $IFG
    4FSWFS
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ։ൃ؀ڥ΋ಉҰͷDPPLCPPLͰӡ༻Մೳʹ
49. • 手順書うつのはだるいから、 最低限自動化したかった • 複数台のサーバを同時に構築 できるようになった！ • でも、結局このcapfileの管理 が大変 • 設定ファイルの配布はあまり 解決していない capistranoがんばるモデル
50. サーバ管理のいままで ̍୆ʙ̑୆͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ
    ֤αʔό͝ͱʹઃఆϑΝΠϧΛผ؅ཧ ̑୆ʙ̍̌୆͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங
    ѱ͘͸ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘౗ͩͬͨ ̍̌୆ʙ̎̌୆͘Β͍ DIFGTPMP
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ్த͔Β͸ɺLOJGFTPMP΋׆༻ ̎̌୆͘Β͍ʙ $IFG
    4FSWFS
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ։ൃ؀ڥ΋ಉҰͷDPPLCPPLͰӡ༻Մೳʹ
51. • 2012年くらいから、chefを順 次導入 • 最初は、各サーバでgit clone をしてそれぞれchef-soloを実 行していた • 途中から、knife-soloが出て きたので乗り換え chef-soloの登場
52. • httpd.confなど、設定ファイ ルの中に変数を持つことがで きる • それぞれの設定ファイル内で 使用したい変数は、ホストご とに設定することが可能 chef-soloで解決したこと
53. サーバ管理のいままで ̍୆ʙ̑୆͘Β͍ खॱॻΛϕʔεʹओಋͰؤுΔϞσϧ
    ֤αʔό͝ͱʹઃఆϑΝΠϧΛผ؅ཧ ̑୆ʙ̍̌୆͘Β͍ DBQJTUSBOPʹߏஙTDSJQUΛ͝Γ͝Γॻ͍ͯߏங
    ѱ͘͸ͳ͍͚Ͳɺ͍Ζ͍Ζͱ໘౗ͩͬͨ ̍̌୆ʙ̎̌୆͘Β͍ DIFGTPMP
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ్த͔Β͸ɺLOJGFTPMP΋׆༻ ̎̌୆͘Β͍ʙ $IFG
    4FSWFS
    
    DBQJTUSBOPͰߏஙʴӡ༻
    ։ൃ؀ڥ΋ಉҰͷDPPLCPPLͰӡ༻Մೳʹ
54. • 管理対象サーバはすべてChef Serverに登録されている • 各サーバは、1つのコマンドを 打つだけでChef Server側に定 義されているcookbookを実行 • 各サーバごとの変数も一元管 理されている Chef Serverの導入
55. 本番サーバへの反映 $ sudo chef-client # これを全サーバで実行させる $ cap -f ./deploy.rb chef:client # 実際はこう実行
56. CherServerからの反映 • Chefで管理されているサーバで自動反映させるこ とは可能だが、タイミングが指定できない分困る • そのため、設定変更を反映させるタイミングを指定 したいため、実行時だけはcapistranoで実施
57. 開発環境への導入 • 本番環境と開発環境をできるだけ同一のものにする ため、本番環境とcookbookを同一のものを使用 • 各環境ごとによる違いは、attributesを駆使してう まく使い分ける • これにより、開発環境のupdate忘れを防げる
58. ２種類の開発環境 • グローバルIPを持ったリモート開発環境と、 Vagrantで構築したマシン内開発環境 • 前者はChefServer経由で管理、後者はVagrant + Berkshelfで管理 • どちらもcookbookを最新にすることで、簡単に サーバの設定を保つことができる
59. ２種類の活用方法 • ローカルのほうが快適だけど、グローバルアクセス が必要なときもある • 社外にいるときに障害対応を行うときにあると便利 • VagrantShareとかもあるしそろそろ整理できる？
60. Vagrantでの開発環境の作り方 $ git clone git@github.com:nanapi/cookbooks.git $ cd cookbooks $ vagrant up nanapi
61. Vagrantでの開発環境の アップデート $ git pull $ vagrant provision nanapi
62. chefの環境まとめ
63. • 詳しくは個人BLOGのほうに書 いたので、興味あるひとは是 非どうぞ！ • さくらVPSをつかって便利な 開発環境を構築する
 http://goo.gl/EEcIXO • はてぶしてね！ 詳しくはBlogで！
64. • https://github.com/wadap/ emacs-chef • chefをより快適にかくための emacsマイナーモード • まだ実装中。思い出してpush したくらいのレベル 趣味的な活動
65. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
66. • 言わずと知れた、ログコレク トツール • Webサーバに散っていたログ を、一箇所にあつめることで すごいことができる • プラグインで様々な機能拡張 が可能 fluentdを活用
67. Log System Overview Fluentd Cluster Web Servers raw log archive log analyzer fluentd-plugin-mysql fluentd-plugin-s3 fluentd-plugin-td Result Output S3 + Glacier Web Servers Web Servers fluentd-plugin-elasticsearch
68. 効果的な使い方 • アプリログの収集（エラーログ） • アクセスログの収集（エラーログ） • アクセスログのステータスの推移 • ユーザーの行動解析
69. • ユーザーのアクセスデータは 宝の山である • まさにビッグデータ • それを解析しやすくするため に、fluentdを活用し集約する ビッグデータの利用
70. • クラウド上に構築されている データ解析プラットフォーム • ログを直接送ることで、あと からSQLでデータ解析を行う ことができる • Fluentdで集約したログを簡単 に送信することができる TreasureData
71. TreasureDataへの送り方 { "url" : “http:\/\/nanapi.jp”, "username" : "wadap" }
72. SQLで解析 $ td query -d db -w " SELECT * FROM tbl WHERE username = 'wadap'" -o ./result.csv
73. • SQLの発行はWebの管理画面 からも実行可能 • 実行結果の取得は様々な取得 方法が可能 • ResultOutputという機能を使 うことで、結果をMySQLのデー タに自動INSERTさせることも Webからも解析可能
74. アクセスログだけでは不十分 • ただのログ解析だけでは、いわゆるアクセス解析の 域を出ない • nanapiにおいて大事なのは、ユーザーのがどうい うコンテンツを欲しているか • そしてどういった行動をしているのかということ
75. 3FRVFTU )551
    WJB
    +BWBTDSJQU 'MVFOUE Overview Web Servers Web Servers Fluentd Cluster
76. access_logだけではできないこと • access_logだけで取得できるログは、WebServer で取得できるデータしか出せない • アプリケーションよりのデータなどをログとしては くことは難しい • また、ログフォーマットの変更などがカジュアルに できない
77. 実際に付与しているメタデータ • ページ属性 • ページのジャンル • 使用デバイス • リファラのホスト etc…
78. Log Format • データ解析を行う際に大事なのは、解析対象となる ログのデータ設計 • 取得するログは “非正規化” することが大事 • RDBMS感覚で正規化を行いすぎるととにかく解析 しづらいデータになる
79. • クエリの実行パターンはある 程度限られるのでドキュメン ト化 • データ解析をエンジニアのも のだけにしないことが大事 • SQLは非エンジニアでも触れ るくらいの心意気を育てる 非エンジニアも利用　
80. • アンサーで一部利用中 • APIのログをkibanaに流すこと でユーザーの行動解析 • バックエンドはElasticsearch • これも非エンジニアが使用 kibanaも利用中
81. アジェンダ ࣗݾ঺հˍαʔϏε঺հ ։ൃ͔ΒϦϦʔε·ͰͷྲྀΕ $IFGΛ׆༻ͨ͠%FW0QT΁ͷऔΓ૊Έ ϩάղੳϓϥοτϑΥʔϜ ςΫϊϩδʔΧϯύχʔ΁
82. これからの時代で言えること • 総合職の時代は終わった • これからは専門職の時代だ • そして、時代はこれからも変化しつづける • 変化できない人間は淘汰されていく
83. • これはエンジニアの仕事も同 じで、今の仕事は継続しない • 2000年前後って、HTMLかけ るだけで価値があった • いまのスキルはどこまで価値 が続くの？どこまで戦えるの • http://logmi.jp/7770 今の仕事は10年後にあるか？
84. • 2009年にはスマホがここまで 普及するとは思っていない • Webはいまよりは確実に衰退 する（なくならないけど） • もっと言うと、スマホですら 今後どうなるだろうか • 大事なのは変化に耐えていく こと 求めることは変化への強さ
85. 会社として提供できること • エンジニアは常に新しいスキルを • 非エンジニアはプログラマーレベルのスキルを • 常に新しいものをさわろう、常に最先端にいよう
86. • 1Qで学習するスキルを定め、 業務時間を使ってスキルを身 につける • 上記の学習も評価対象とする • これにより、サーバサイドの エンジニアも全員iOS開発がで きるように • 次はAndroidに挑戦 実際に取り組んでいること
87. • Sensuという監視ツールのiOS 版クライアントをつくってみ た • これから審査だすけど、超自 信ないけど・・・ • 通ったらちゃんとアナウンス します つくったアプリ
88. • 非エンジニアも技術を正しく 理解してもらうように • 週に１回、和田が直接研修を 実施 • たまに外部の人も混ぜる • 社内のレベルは高い方に合わ せることで、全体水準をあげ る 非エンジニア向けの研修
89. • CTOとは、すべての技術をコ ントロールする人ではない • 「技術の正義」を浸透させ、 それを遂行させていく人 • CTOが会社の技術レベルの キャップにならないように • http://goo.gl/38Mbk9 自分の考えるCTO像
90. • nanapi TechBlogで書きました • 変化に〜という点の話です • 興味ある方はぜひ読んでみて くださいね！
 http://goo.gl/6W2xip 詳しくはTechBlogで！
91. 事業に人をアサインしていくのではなく
 人が事業をつくっていく会社に
92. • Webアプリエンジニア • スマホアプリエンジニア • マークアップエンジニア • インフラエンジニア • デザイナー • ディレクター etc… nanapiでは人材募集中