第21回 AWS User Group - Japan 東京勉強会で話してきました
最近、イベントレポート系のエントリばかりなきがします。先日こちらのイベントで話してきました。
第21回 AWS User Group - Japan 東京勉強会(一般枠) - JAWS-UG東京支部 | Doorkeeper
nanapi.jpというサービス自体は今現在はオンプレミス環境で動いています。その他のアンサーや、ignitionといった新サービスがAWSで稼働しているので、そのあたりの内容です。
一緒に登壇する方々がすごい方ばかりでどんな内容発表しようかなぁと悩んだのですが、結局ふつうの発表です。まぁ５分の発表時間だったので、そこまで多くのことは話せませんね。
他社の事例をいろいろ見ることができて刺激をうけることができました。もうちょっといろいろと実験して、面白い構成にチャレンジしてみたいものです。
2020年のエンジニア像 ～ エンジニアがこの先生きのこるには？ で話してきました
5/16(金)にCTOによるCTOのためのこんなイベントで話してきました。
前半のプレゼンテーション
CTOという立場である以上、自分自身が技術者としてどうあるべきかだけでなく会社の風土をどうしていくべきか。そしてその風土に合わせてどういう人を採用していくべきかという仕事が出てきます。
今回はそのあたりに焦点を絞ってお話をしました。第一部でつかった資料はこちらです。
他社さんの事例もすごく興味深かったです。特に、cookpad舘野さんのエンジニアの評価基準の話はすごく具体的で参考になりました。
後半はパネルディスカッション
後半は、パネルディスカッションです。他社さんの事例がいろいろ聞けたのは個人的にもすごく勉強になりました。
「めんどくさいおじさんにならないようにしよう」「成功体験おじさんにならないようにしよう」みたいな感じです。
響きとしてはおもしろワードなのですが、結構重要なことですよね。過去の苦労話を押し付けるようなベテランになりたくはない。
そんなことよりもいまの新しいテクノロジー使って便利にやればいいと思うし、別に今の時代に不要なことは覚えなくてもいいと思うんです。
そんなことを意識しながら、若いエンジニアがより活躍できるような場を作っていきたいと思っています。
「ベンチャーCTOが語るこれからのエンジニアの未来像」で話してきました
こちらのイベントで話してきました。今回は技術的な内容というよりも、エンジニアとして今後どうすべきかというような内容です。 今回は、Vasilyの今村さん・ウェルセルフの恵比澤さんとのパネルディスカッションが中心でした。
これからのエンジニアの働き方
いままでもそうですが、技術の移り変わりはとにかく早いです。5年前にその技術だけで食えていた人は、いまでもそうとは限らないわけです。Webだけの開発をしていればOKなんて時代は少し前にすでに終わっていて、現時点ではアプリ開発が当たり前の世の中になっている。
もっと直接触れることのできるデバイスに対応する開発をするようになるのもそう遠くないでしょう。どのデバイスが覇者となるかはまだわかりませんが、少なくとも現在と変化するのは確実です。
そんな時代についていくために、会社として何ができるのか？というあたりを話しました。他の資料とかなり重複している部分がありますがこんな感じの資料です。
いま何を学ぶべきか？はただの各論
http://nanapi.co.jp/blog/2014/04/09/the-system-where-an-engineer-can-grow/
それに対応するために企業としてできることを以前にブログでまとめました。現時点でnanapiでは、2014年内に全員iOS/Android/サーバサイドをできるようにという目標を掲げています。
「iOSやるくらいならこっちやったほうがいいよ」みたいな意見も頂きましたが、まぁどの技術をいまやるべきかって話は各論です。重要なことは、そういったあたらしい技術をキャッチアップするための制度を整備しておくということです。そのあたりを勘違いせずに制度化するように意識しています。
とまぁこんな感じのことを話す珍しいテーマの勉強会でした。パネルディスカッションの内容はブログなどではお伝え出来ませんが、結構突っ込んだ質問もありなかなかおもしろい内容だったんじゃないかなと思います。
技術者向けの技術的な内容ではない勉強会もいいですね！
エンジニアナビ主催セミナーでnanapiのシステムについて話してきました
4/10に開催されたエンジニアナビ主催のイベントでnanapiのシステムについて話してきました。今回は珍しく、nanapiのワンマンライブ的な感じです。時間も40分ほどあったので何について話そうかなーといろいろと考えてました。
自分がインフラ出身なのでどうしてもその辺り中心にはなってしまいましたが、極力nanapiでの開発手法やフローなどについても話すように心がけました。イベント後のアンケートや質問などみても満足度が高かったようで良かったです。
質疑応答で答えられなかった内容
当日は付箋で質問をもらう形式だったのでたくさんの質問をいただくことができました。時間の関係で全部お答えすることができなかったので、もらった質疑応答に関してここでお答えします。近い質問は勝手にマージしちゃっています。
事業について
Q: 一人でやっているときの技術的な問題はどんなもので、どう解決したか？
A: 小さな技術的な問題はたくさんありましたが、エンジニアの知人などに質問して解決できるレベルの内容でした。そういった個人的なネットワークはあったほうがよいとおもいます。
Q: 海外向けのサービスの概要を知りたいです
A: 日本初のコンテンツを海外に届けるといったコンセプトでやっています。まだ国内では告知していませんが、英語圏でサービスが定着したらちゃんと国内でも告知したいと思っています。
Q: 収益のメインは何でしょうか？
A: 現時点では広告収益が主な収益源となっています。
Q: 一人CTOの時はどんなかんじでしたか？
A: すごい頑張っていました。電車のなかでもコードかいてて、エンターキーがうるさいってよこのサラリーマンに怒られたりしてました。また当時は受託開発もやっていたので、エンジニアとしてとにかくやることが多かったなぁという記憶です。
Q: エンジニアという道もあったがなぜCTOという道を選んだのか
A: 自己分析を行った結果、技術だけでなく経営やマネージメントなども含めた全体的なバランス感というのが自分の武器だと思ったからです。
チーム・組織
Q: コードレビューはどのようにして行っているか？
A: 基本的に、そのシステムのアーキテクチャを理解していないとコードレビューはできないので各チーム内でコードレビューは完結するようにしています。自分以外の人がレビューする、ということを必須としています。
Q: 非エンジニアむけの勉強会で嫌がる人はいないか？
A: いません。少なくとも現時点ではみんな前向きに受講してくれています。
Q: 非エンジニアむけの勉強会の内容
A: HTML/CSS/PHP/MySQLに加えて、どうやってインターネットはつながるかというネットワークに関する知識
Q: 「エンジニアの文化」を社内に広めるときに障害と感じたことは？
A: 今のところ特にありません。
Q: 人数が増えた時に開発/運営の自動化を考えたタイミング
A: いろいろな仕組みができてきたのはエンジニアが5名くらいになってからです。私一人で考えたというより、そういうことを好きで得意なエンジニアが入ってきてくれたというのが大きいです。
Q: 爆速かつ継続的な開発の仕組み化を図る秘訣
A: いままでの仕組みなどにとらわれずに、新しくて良さそうなものはどんどん取り入れることでしょうか。あと社内の面倒な手続きは極力排除しています。
Q: 小さな会社のエンジニア採用について
A: たしかに大変です。そのあたりはCTOの私が深くコミットしています。いかにして会社のことをわかってもらうかがエンジニア採用のキモなので、ブログや登壇するときなどもそのあたりを意識しています。
Q: エンジニアの自由とマネタイズでぶつかるが、それを解消する方法は？
A: All or Nothingではないので、本来であればそこはぶつからないはずだと思います。そういった問題が起きないよう、nanapiではエンジニアを事業に対してアサインしています。
技術
Q: 受け入れテストはどうしているか？
A: 開発環境で行うことが多いです。ここはもっと仕組み化していきたいところ。
Q: 中長期のタスク管理はどうしているか？
中長期になるとタスクというよりプロジェクトになるべきなので、管理方法が変わります。カンバンで管理されるべきタスクは、原則最長で1日で終わるものとしています。
Q: サーバ監視に利用しているツール
A: nagios, cacti, newrelic, sensuあたりです。環境によって最適なものを利用しています。
Q: サーバ台数はどれくらいか？
A: nanapiでは40台前後です。
Q: ローンチ済みのサービスへの緊急タスクなどはどう管理しているか？
A: スクラムを組む際に、バッファ用の時間を事前に確保しています。
Q: Chefでコミュニティのコードはどこまで利用しているか？
A: あるものはできるだけ活用しています。最初は全部書いていたので、過去の遺産が残っている部分もありますが。
Q: githubのissuesのタグは？
A: priority設定用のタグと、Problemやfeatureなどといった実装内容を示すタグを使っています。進捗は仕組みでは管理していません。
Q: デザイナー・非エンジニアはどの程度gitを使えるか？
A: branchきって開発して、pull request送ってくらいまでは全員できます。できない人には合わせずに、できる人の水準まで上がってもらっています。
Q: テストの自動化はどの程度やっているか？
A: phpunitをつかって、ユニットテストを書いています。
Q: インフラはAWS？オンプレミス？
A: nanapiはオンプレミスで、クララオンラインさんにおいています。それ以外のサービスは、AWSを使っています。
Q: クックブックのテストはどうやってるか？
A: まだテストはちゃんとかけていないです。serverspecでちゃんと書くべきだと思っています。
特に反響があった部分
スライドの中でも説明しましたが、特に反響があった部分が「エンジニアが成長し続けることができる制度」の部分でした。参加者の殆どがエンジニアだったということもあり、やはり興味のある内容だったのではないかと思います。
会社のブログの方にも書きましたが、年々テクノロジーの進化の速度は早くなっていっています。その進化に対してエンジニアがついていくことが大事で、それを会社として支援するといったような内容です。具体的な実施内容は以下からどうぞ。
http://nanapi.co.jp/blog/2014/04/09/the-system-where-an-engineer-can-grow/
当日の資料
別のエントリでもすでにアップしてしまっていますが、こちらになります。若干の修正を加えていますが、当日発表したものとほぼ同じ内容となっています。
こちらもどうぞ
公式のレポートもこちらにあがっていますのでどうぞ！
「グロースハックを支えるチームづくりと実践手法」で話してきました
少し前の話になってしまうのですが、4/7(月)にKDDIさん主催のイベントで話してきました。実は、グロースハック系のイベントでの登壇は今回が初めてです。
nanapi×VASILY×ランサーズ グロースハック大勉強会！！【グロースハックを支えるチームづくりと実践手法】｜IT勉強会ならTECH PLAY［テックプレイ］
グロースハックという単語は、ここ最近のバズワードになってきていますがnanapiなりの解釈を話すことができました。具体的には、データ解析は重要だよーという話がメインです。
どうでもいい話なのですが、今回一緒に登壇したメンバーはもともと知っているメンバーで、全員バンドマンという面白い共通点がありました。
講演の様子
60名ほどの参加者で、ほぼ会場は満席だったと思います。ざっくりアンケートをとった感じだと、技術者の方は1/3くらいだったでしょうか。
この後の懇親会でも感じましたが、グロースハックへの興味がある人はいろいろな職種の人なんだなぁと実感できました。
当日の資料
こちらにアップロード済みです。
その他のレポート
http://director.blog.lancers.jp/development/growth-hack/growthhack-seminar/
ランサーズさんもすでにブログにまとめられていますのでこちらもどうぞ！
