読者です 読者をやめる 読者になる 読者になる

狐に騙され覚書

あぁこれ便利だなってことを忘れてもいいように覚書。主にプログラミング言語主体ですよ。

本当はリリース告知だった話

おはようございます。 株式会社Nicogory の技術責任者(CTO)をやってます。

昨日、弊社のリリースイベントを東京大学本郷キャンパスで行わせていただきました。 それで、本当はリリース告知する予定だったんですけど色々あってリリースが来週になりました。

でもなんか書きためてしまっていたし、これ以上放置しても鮮度が下がるので公開します。

転職したこと

2年と少し前に、比較的大手のWEBサービス運営企業へ就職しました。 それから、1年と10ヶ月くらい働いて、今から 5ヶ月くらい前に退職しました。 あまりその辺りの心情について話したことがなかったので、自身への備忘も込めて書きます。

私は高専の出ですが、当学では 5年生(大学 2年生相当)で卒論を書きます。 その後、専攻科に進むと更に 2年間研究をすることになります。 その時に画像処理と機械学習の研究を行っていました。

大学院ではそれとはあまり関係のない、どちらかと言うとグラフ理論寄りの研究をしていたのですが、 ちょうど就職した時期辺りで世の中は人工知能ブームで、 あぁ知ってる知ってる!ということで、オープンソースのプロダクト で遊んだり を検証したりしていました。

人工知能のブームは1950年頃から何度かあるのですが、人工知能という言葉がひとり歩きしてしまい、 実際にできることと理想とのギャップが大きすぎて衰退するという流れを繰り返して来たようです。

松尾豊先生による『人工知能は人間を超えるか』にこのあたりの話が書いてあります。 端的に言えば、人工知能とは何か、今話題の深層学習(Deep Learning)とはどんなもので、何ができて何ができないのかと言ったことを簡潔に書いた本です。 数式は登場せず、専門でない人も読みやすくなっています。

弊社の顧問である中西先生は、もう少し広い枠組みで『スマートデータ・イノベーション』という本を書かれています。 こちらは人工知能だけではなく、ビッグデータや IoT なども合わせて、データとどう向き合っていくかを考えるきっかけに良いと思います。

そもそも人工知能という言葉に私自身あまり積極的ではなくて、ずっと機械学習(または Machine Learning)と言っています。 人工知能という言葉のニュアンスが余りにも広く、専門的な分野では扱いにくいためです。 つまり "人工知能" がもてはやされているということは、一般の人々に訴求するような話題として上がっているので、 例によって実際にできることと理想とのギャップに冬の時代を再び迎えるかもしれません。 ただ、できることが増えている以上、何かそれで楽しいものが作れないかな?と考えるのがエンジニアの本質だと思っているので、 ひっそりと検証したり外部の勉強会に参加したりしていました。

それで、外部の方々、特に共通言語として数学を持つ方々と触れ合ううちに、 「あぁそういえば数学って楽しいよね」 という感覚が戻ってきて、一方で業務内容はと言うと数学が利益に直結する環境ではなかったのでモヤモヤが溜まっていました。 松尾先生が以下の記事でも語られていますが、機械学習の精度を上げることがそのまま売上を向上させるという構造を作り上げた GoogleFacebook は、 この辺りのインセンティブ作りが非常に上手いと思います。

http://www.rieti.go.jp/jp/events/bbl/15060301.html

さて、私個人としては、機械学習関連の検証やアウトプットにそこそこ時間を使ったものの、 周りの反応であったり雰囲気であったりを見て、あっさり会社を辞めました。

ダメなら自分から動いて周りから変えていこう!というのはまぁ確かにもっともなんですが、 ちょうどその頃、数社からお誘いをいただいていたこともあり(特に転職活動していたわけではないんですが)、 そこにエネルギーを使うのであれば、もっとリターンの大きいところはあるし、 職業柄あと5年くらいは食いっぱぐれないだろうなとふんでいたので、その他色々あって決意しまいた。 私は院卒なので、そもそも後先考えずにチャレンジできるのは高々あと 4年くらいだなというもの考えました(矛盾)。

本筋から逸れすぎるので、この辺りでやめます。 聞きたい人はお寿司おごってください。

5ヶ月でやったこと

それで転職してから、開発環境に関してはまぁほぼ何もなかったこともあって、ほぼ丸々作りました。 主要なやったこと一覧は以下の通りです。

Ruby on Rails + AngularJS による WEBアプリケーションの開発

  • 法律相談ポケット執事 『Nicogory』の設計・開発・リリース(来週)

www.youtube.com

  • 株式会社Nicogoryの運営するサービスを横断的に使用できる NicoID の設計・開発・リリース(来週)
  • NiCO MATCHING(士業向け)の設計・開発・リリース
  • コーポレートサイト の設計・開発・リリース
  • NicoSys(士業向け、未リリース)の設計・開発
  • マイクロアプリケーション(モノリシックアプリケーションとの対比)としてのアプリケーション設計(DB、サーバー構成など)

構成管理

  • chef によるサーバー構成管理

私がジョインしたタイミングでは、サーバは構成管理されておらず、そもそも構築手順書も存在しなかったため、 それらを chef で管理するようにしました。

  • serverspec によるサーバー構成テスト

構成管理を抽象化してコードによって管理するため、 正常に動いているように見えて実際には期待通りに動作していないというバグが介入する可能性があります。 したがって、コードによって構成管理されたサーバに対してテストを書くことは自然な流れであるので、serverspec によるテストを導入しました。

  • CircleCI によるテスト自動化

開発速度向上のため、テストを自動的に実行し、その成否をマージの基準の一つとしています。

情報整理

  • 社内redmineサーバー構築
  • ドキュメント管理サービスの選定(esa.io)

社内に情報管理するための基板が存在しなかったため、redmineesa.io を導入しました。

NoSQL DB

  • redis の導入

まずはセッションキャッシュとして、後に各種集計用のオンメモリDBとして使用します。

  • 分散KVS Cassandra検証

RDS以外の DB として最近再度注目されている Cassandra を検証しました。 サービスのスケールに合わせて導入予定です。

検索エンジン

OSSの中で最も勢いのあり、かつ私の使用経験もある elasticsearch を導入しました。

  • fluentd によるサーバーログ転送および集約機構の構築
  • elasticsearch + kibana によるログ可視化

サーバログを始め、各種ログを集約し、集計するための基盤を構築しました。

機械学習

検索エンジンでは行えない、または行いにくい価値をユーザーに提供するための基盤です。 数理最適化手法によるコスト関数最小化にも使用します。

監視

  • nagios によるサーバーおよびサービス死活監視
  • NewRelic によるサーバー死活およびリソースの視覚化、監視
  • slack への各種通知設定

サーバやサービスの死活を監視する機構を設計、導入を行いました。 ダウンタイムを極力減らすことが目的です。

その他

  • hubot による簡易勤怠管理システムの構築、デプロイの一般化、各種集計機能の実装、ごみの日通知機能の開発

エンジニアしかできないことを減らし、リスク分散を行うことを目的としています。 情報の取得障壁をできるだけ減らし(例えばDAU集計のために経営者が SQL を叩くなんて馬鹿げている)、意思決定を迅速に。


我ながら、結構働いたなという感じはあります。

それはそれとして、弊社では上記のような開発環境を持ちあわせています。 私個人としては(つまり弊社の技術方針でもありますが)、 使用している技術を公開するデメリットが大きいと考えられていたのはすでに昔の話で、 現在では公開することのメリットの方が大きいと考えています (もちろんセキュリティ上のリスクや最終的には利益とを天秤にかけた上で載せられる範囲で)。

弊社は、技術に関してはそういう方針ですし、論文を書くことも技術ブログを書くことも推奨しています。

サイバーエージェントのかたは、むしろ「公開しないことのリスク」とおっしゃっています。

seleck.cc


さて、ここから先はリリースしました!うぇーい!みたいな記事になる予定だったのですが、 事情が変わったのでもう淡々と人材募集します。

WEBエンジニアやリサーチャーの方はこちらです。

corporate.nicogory.co.jp

アナリストや法律家の方、SIer の方はこちらです。

corporate.nicogory.co.jp

募集していない職種の方でも、ご興味・ご関心のある方はぜひご連絡ください。 ご質問等々、私個人に facebook とかで聞いていただいても構いません。

はい、余談扱いになってしまいますが、来週またリリース告知します。