tchikuba's blog

Beer Driven Developer / Lean Engineerの徒然

イベント「人工知能ハッカソン」に参加してきました!

最近、人工知能について非常に興味関心があります。 ロジスティック回帰による数値予測や機械学習、特にニューラルネットワーク・ディープラーニングへの興味関心が発展して最近では専ら人工知能についての話題に釘付けです。 そんな折に丁度タイミング良くサムライインキュベートさんからのメルマガで「人工知能ハッカソン」 が開催されることを知り、応募してみたところ見事参加抽選に当選したので過日(2015/5/23-24)参加してきました。

(当選時の喜びの声)


ハッカソン当日の模様

1日目前半にアイディアソンやって1日目後半、2日目に開発をやるというガチなハッカソン自体、 初参加でしたので良い経験になりました。今回のハッカソンでは基本ハスラー、ハッカー、デザイナの3つの役割の人が各チームに均等に割り振られるルールのようでした。 私がいたチームはハスラー2名、ハッカー3名(サーバサイドエンジニア2名、インフラエンジニア1名)な構成でした。 やはりデザイナかフロントエンドエンジニアがいないとプロダクトの見栄えが・・・な感じでした。。

ネタとしてはうちのチームでは「みんなのカイシャ(仮)」というタイトルで開発を行いました。 過去の判例の情報解析を手掛けるUBICさんが用意した自然言語処理系の人工知能APIを使って 選択肢に企業理念を候補として出力して選択していくと企業理念が似通った企業を推薦してくれるというものです。 クローラによるデータの収集や前処理に時間をかけすぎて肝心の人工知能APIバックエンドの実装が中途半端だったのが悔やまれました。

(2日目の成果発表の様子)

以下の通り、優勝したのはダイエット家庭教師等を手掛けるFiNCのインターンの方がいたチームでした。

ハッカソンに参加して感じたこと

参加して思ったのはハッカソンは(アイディア出しよりは)開発メインでテック寄りな方が良いかなという点です。 アイディア出しに注力するならハッカソンじゃなくてアイディアソンとして別枠でやった方が時間的な制約で中途半端にならずに良いかなと思います。 開催する側のメリットとしても2点あると思っていて、1点目はAPI提供側が開発時にストレスなく組み込めるか温度感を見る点、 2点目は提供したAPIが具体的な課題解決にどのように応用されるかアイディアの幅を見る点。 この2点の検証が盛り込まれた今回のハッカソンだったと思うのですが、提供されたAPIがシンプル過ぎてちょっと拍子抜けした参加者もいたようで 両方の検証がUBICさん的に十分に出来たのかはちょっと疑問が残る内容だったかもしれません。

ところで今回のハッカソンのメンターがトレタ増井雄一郎さん東京大学准教授の松尾豊さんだったのも参加理由の一つでした。 増井さんのお話を1年前のデブサミ2014で聞いたことがあり、 スタートアップ的な考え方からのツッコミが聞けそうだなと思っていたところ まさに想像通りのフィードバックがあってその視点が非常に参考になりました。

また、松尾豊さんは人工知能の専門家で 人工知能は人間を超えるか (角川EPUB選書) という有名な本の著者だということを知っており一度お会いしてみたかった方でした。 (この書籍は後日読んで興味深かったので次回のブログ記事のネタで書こうかと思います) ハッカソンの中間と発表時にチームへのフィードバックをいただいたのと、ハッカソン終了後にご挨拶して 日頃の興味関心事等について色々意見交換が出来たのは収穫でした。

ハッカソンで実際に何を作るのかという以上に、ハッカソンのテーマ(今回なら人工知能)に興味関心が近い人と繋がれる、 という意味でハッカソンに参加することは有意義だなと思いました。 初日にハスラー2名と私の3人で飲みに行って意見交換したんですが、参加者やメンターの方と直接会って意見交換するのは貴重な時間だと思います。 私は常日頃人が会うことで生じる「場のエネルギー」を信じているところがあり(別にオカルトという訳ではなく) 共通の指向性を持った人同士が出会う場としては相当良い場ですね。

人工知能ハッカソンの記事

参加者の方のレポート

td-clientを使ってHiveより早いPrestoクエリを実行する方法をrakeタスクで

最近、Hadoop(Tresure Data)と格闘してます。

td-clientを使ってTresureDataからデータを取得するrakeタスクを書いててHiveクエリだと遅いのでPresto使いたいなと思うことがありました。 td-clientのREADMEなど公式情報をざっと確認したところ見当たりませんでしたが、 td-client-rubyのソースコードを見たら案の定クエリタイプを指定するインタフェースがありました。

https://github.com/treasure-data/td-client-ruby/blob/master/lib/td/client.rb#L182

client.rb#L182付近gist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  # @param [String] db_name
  # @param [String] q
  # @param [String] result_url
  # @param [Fixnum] priority
  # @param [Fixnum] retry_limit
  # @param [Hash] opts
  # @return [Job]
  def query(db_name, q, result_url=nil, priority=nil, retry_limit=nil, opts={})
    # for compatibility, assume type is hive unless specifically specified
    type = opts[:type] || opts['type'] || :hive
    raise ArgumentError, "The specified query type is not supported: #{type}" unless [:hive, :pig, :impala, :presto].include?(type)
    job_id = @api.query(q, type, db_name, result_url, priority, retry_limit, opts)
    Job.new(self, job_id, type, q)
  end

上記の通りqueryメソッドの第5引数にoptsというハッシュで指定するオプションがあり、 type: :prestoな指定をするとHiveではなくPrestoでクエリが発行されます。

以下、rakeタスクでのサンプルコードです。

rakeタスクでのサンプルコード
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
namespace :execute do
  desc 'download treasure data by presto'
  task presto: :environment do
    apikey = 'your api key'
    db = 'your_db_name'
    query = 'select count(*) from your_table_name'
    client = TreasureData::Client.new apikey
    job = client.query db, query, nil, nil, nil, type: :presto
    until job.finished?
      sleep 2
      job.update_status!
    end
    job.update_status!
    p job.result if job.finished?
  end
end
実行
1
bin/rake execute:presto
結果
1
[[100]] # your_db_name.your_table_nameの件数

上記のように単純なクエリの場合、Hiveだとパフォーマンス的にwebアプリ等から動的に取得するのが 現実的に時間がかかりすぎたクエリでもPrestoであれば動的にデータ取得可能なので利用の幅が広がりますね。

合わせて読みたい

好きなことを仕事にするという論調を何故批判する向きが多いのかふと疑問に思った

私はちょっと前にこのブログ記事を読んで凄い共感しました。 記事のコメント欄を読むと比較的肯定的な意見が多いようです。 一方、はてブのコメントだとかなり批判的な意見が多いように思います。 コメントも合わせて読んで色々思うところがあったのでちょっと自分としての考えをブログにまとめておこうと思いました。

個人的には自分が正しいと思う価値観や信念に素直になって自分の仕事を選んで行こう。 何も規模や効率化だけを選ばなくても食べていける選択肢はある、って解釈しました。

この記事の方に対する嫉妬が邪魔するのか、単に価値観が違うのか、理解できない向きもあるようで、 それが個人的には不思議だったんですよね。一般的には好きなことを仕事に出来ていない人が想像より多いのかな?と。 そこでちょっと好きなことを仕事にするという切り口で色々な考え方を調べてみることにしました。



否定的な意見



肯定的な意見



中立的?な意見



その他



私見

上記の通り色々意見がありますが、職業を選択するときははなんだかんだ言って好きか、 好きになれそうかを基準にした方がこれからの時代にはマッチしていると改めて思いました。 で一度選択したら多少何があっても好きになれるまで修行だと思って踏ん張ってみて、 その仕事を好きになって自他共に認められるようになったら次のステージを検討しても良いのかなと。

あと学生を卒業したばかりの新社会人や第二新卒などのジュニアクラスの人は修行だと思って、 選択した仕事を好きになる為に一定の努力をするのは必要ってことでしょう。 といっても所謂ブラック企業でただひたむきに働き続けるのはブラック企業に加担することになってしまうので良くないので、 そういうケースに該当するかも?って思ったら経験豊富な人に相談した方が良いですけどね。

一番重要なのは、好きな仕事でどうやったら継続的に稼げる(少なくとも食っていける)ようになるかを 真剣に考えて行動していくということ。 そして個人的にはよりクリエイティブな仕事を選択すると好きな仕事で継続的に稼げる可能性が高いと思っています。 好きな仕事って1つじゃない可能性もあるので、もし色々好きになれそうで1つに絞れないって人は よりクリエイティブな仕事を選択すると幸せになれると思います。

金融イノベーションビジネスカンファレンス(FIBC)2015に参加しました

縁あって金融イノベーションビジネスカンファレンス(FIBC2015)に参加してきました。 普段参加するイベントはweb技術系かスタートアップ系のものがほとんどですが、 いつも参加するスタートアップ関連イベントに比べてスーツ率がかなり高いのが金融らしいなと思いましたw 同じ感想持った方がいましたねw


あと、いつも参加するイベントに比べて50-60代くらいのおじさまがいるのも新鮮でした。


オープニングスピーチ

  • ソーシャルトレーディング
  • ロボット取引
  • 英語であんまり聞き取れずキーワードのみメモ。。

finピッチ第1部

  • 7分で1ピッチ
  • 参加者も投票可能

クラウド給与計算ソフトfreee

  • 給与計算を半分くらいが社長がやってるのって理不尽な気がする
  • スモールビジネス向け

メリービズ

  • 自力で経費書類入力行うやつ
  • プレゼンがアナログでおもろい
  • 経費データを業界毎に解析して生ハム保険(笑)など新たなサービス開発も

Dr.Wallet

  • Drつけて人っぽいネーミング
  • レシートを写メってアプリ経由で送信、在宅ワーカーが入力
  • クーポンの仕組みも CLO(card linked offer: 見せないクーポン)
  • テンポの良いしゃべり方する人、赤メガネ
  • 生涯使えるお金管理サービス <ー キャチフレーズ
  • リブセンスがやってるお祝い金モデルに近い<CLO
  • データ入力平均6時間後
  • CLO: 現在amazonポイントほぼ現金
  • 在宅ワーカーはクラウドワーカーで地方の主婦とか

Moneytree

  • CEOはオーストラリア出身
  • appleのbestアプリを2013,2014連続で受賞
  • お金だけじゃなくてポイントにも対応
  • 70万DL、リワード広告とペイドインストール一切使ってない!この数字にこだわらない法が良い(至言)
  • 未来から来たアプリ
  • セキュリティ頑張って結果大手とパートナーシップを締結
  • アカウントアグリゲーションは金融機関の顧客に不利益でなければOKとされている

coincheck for EC

  • ビットコイン決済
  • 送金に優れている
  • 怪しいイメージだが最近は大手がスタートアップに投資開始
  • ビットコインは自民党が支援
  • ビットコイン取引所 月間1億円取引
  • ビットコイン決済めちゃ便利!手数料1%!
  • デモでは日本を訪れる外国人向けにsimカードを売っているサイトで利用可能
  • 和田CEO 1990年生まれ!
  • 越境ECにビットコインは相性が良いと考えている
  • 自主規制団体作ったりしてる

Liquid

  • 生体認証システムの会社
  • カードでID一致させた後画像照合してるのが既存の指紋認証
  • 指紋そのものをキーとしているのが大きな違い
  • 100ホテルで利用開始予定
  • 国内800店舗で利用可能になる予定
  • 手数料に依存しないビジネスモデルも構築中
    • 面白そう
  • 10秒で登録可能
  • 指紋読み取りデバイスは10-200ドルくらいの幅がある

ここまでで1部完了

finピッチ第2部

スーパー乱数表

  • WBCの特集で取り上げられた
  • 色々凄い技術の特許とか持っている人らしい

Capy

  • 社長コレない
  • 元々画像をパズルで認証するやつで有名になったがパズル屋やめた
  • 有名になると撃破されるのでパズルやめても良いんじゃないか みつを
  • そこでリアルタイムブラックリスト
  • captchaから入ってくる攻撃者のIPリストを提供(現在無料)
  • アバターcaptcha: 人に帽子を被せて下さい
  • 画像解析だけでなく意味解析も合わせて行う
  • 1認証1円で提供

ETFラップ

  • 白髪のおじさん56歳での起業
  • ロボットによる投資アドバイザリーサービス
  • 時代が変わり円建てでの資産形成はリスクが大きい
  • 5000以上あるETFから50銘柄をピックアップしてグローバル分散投資
  • 諸々カスタマイズして提供する
  • www.money-design.com

アノマリーサーチ

  • ANOMARY: 市場の歪み=取引チャンス
  • 節分天井彼岸底(初めて聞いたw)
    • ジブリの法則もアノマリーの一種なのかな
  • 投資はどこまで人工知能で代替できるのか(というより支援できるのか)
  • シグナル配信&他の人の戦略をコピー出来る
  • バックテストも実施可能
  • 人によって投資する対象は違うのでカスタマイズ可能に

ZUU SIGNALS

  • フィナンシャルメディアプラットフォーム
  • 月間150万UU 配信先含めると1000万超え
  • 30-40代の70%が運用未経験だがこの世代に団塊の世代の資産が移ってくる
  • 保有資産のシグナルを信号に見立てて青・黄・赤の3色で配信してくれるサービスを提供
  • 投資を分かりやすくするのがコンセプト。ちょっとみんかぶに似ているサービス
  • 初心者向けだと情報が多過ぎる程投資判断に迷うことがある
  • なのでメディアを作って段々投信判断が出来るように教育も兼ねている

FINATEXT

  • 最後のセッション
  • あすかぶ!という株アプリ(iOS&Android)
  • 初心者・若年層にターゲットを絞る
  • 思ったより経験者が多く
  • プレゼンうまい、情熱的
  • みんかぶと似たような仕組みで予想結果によるランキングとか企業の豆知識とか
  • 3ヶ月で作ったアプリ
  • 若者が熱くなるポイントは手軽さ

これで2部完了

FinPitch大企業枠

マネックス証券

  • answerという資産運用目標や保有銘柄を管理出来るアプリ
  • 一部の金融機関でアグリゲーションでデータ取り込み(スクレイピング)
  • 設定した目標にどの程度到達しているのかをスコアで評価する

リクルートライフスタイル

  • AirREGIの紹介
  • POSレジアプリ
  • 他社サービスとも連携している Squareとか

キーノートスピーチ

  • シンクタンク・ソフィアバンク藤沢久美氏。ダボス会議でヤングリーダー。7回程参加して感じるのは今、社会全体の転換期にあること
  • 貨幣経済から贈与経済へ。相手に心を使う。結婚式のご祝儀が貨幣経済。
  • 金融とはそもそも何か?非常に考えさせられる。富を再分配するプラットフォームが金融。現在の銀行や証券会社の限界を感じる。slow&nallow
  • グローバル化は多様化だ。IT革命やグローバル化が与えてくれるもの。1人1人の個人の力がエンパワーメントされること。権力が入れ替わる。革命の言葉そのもの
  • 個人が権力を行使するのは勇気がいる。それに必要なのが安心、仕組み。その仕組を提供するのが今日のピッチイベントで披露されていたサービスなど
  • ビジョンがあるものがワクワクする
  • 大阪で先物取り引きが生まれた
  • 大仏を作ったのも究極のクラウドファンディング=勧進 お金が出せない人は土や労働力を提供
  • なぜ投資したか?アンケートに儲けたいから10番目だった。共感したから、応援したいからが1,2番目だった。
  • 日本は不思議な国。全体的なレベルが高いのは日本の凄いところ
  • もっともっと大きな夢を持って失敗を恐れずチャレンジして欲しい

ピッチの表彰式

  • オーディエンス賞:メリービズ
  • ソニー銀行イノベーション賞:ZUU Signals
  • FIBC2015大賞:Capy
  • 審査員特別賞:Dr.Wallet
  • ISID特別賞:あすかぶ!

この後、ネットワーキングの時間がありました。 ピッチ登壇者がブースを出し、軽食をつまみまながら登壇者と参加者が交流するという形式でした。 個人的にも非常に刺激的な時間を過ごすことが出来て楽しかった!

Bufferにインスパイアされて、以前から私が書き溜めていた21世紀型ニュータイプ組織を晒してみました

CEOの年収2000万円ほか全社員の給与を公開中、Buffer創業者に聞く「過激な透明性」のワケ というHRナビの記事に興奮したのでこれは久しぶりにブログ記事を書しかない!と決意しました。 興奮したのは自分が起業したらこういう会社にしたいな、こういう組織が良いな、と思って以前から書き溜めていた内容と結構重複するところがあったからです。 この記事、タイトルが内容のごく一部というか表層的な部分しか表現出来ておらず、何かチープな印象すら受けるんですよね。。 給料を公開してる事実自体、実は物凄く小さいことで、もっと根源的な組織論みたいなものがテーマで、21世紀に新たに拡大していく有機的な組織の本質を 浮き彫りにしてくれていることが、この記事の核心なんです。なのでまだ読んでない方は是非熟読をオススメします。

まず本題に入る前にこの記事を読んだ人の感想をピックアップしてみます。

こういう捉え方はちょっと寂しいような気もしますが、私はむしろこの規模の企業の社長としては貰ってない方だなと率直に思いました。 と同時に従業員の平均給与はそこそこ良いのかなとも思います。 ビジネスは仕組み作りなので、Bufferはそれが着実に出来ているということなんじゃないでしょうか。


この意見は私もその通りだなと思いました。これからは資本主義で競争するのではなく人道主義で競争する時代になっているのだと確信します。 インターネットが普及したことで物事がオープンになり、資本主義の為に多少なりとも人道主義を犠牲にすることが出来ない程、衆人監視の目が光っているのだと思います。


ホントそうですよね!記事では自律分散型の組織運営としてフレデリック・ラルーの講演内容から引用して紹介していますね。 このフレデリック・ラルー(Frederic Laloux)という人、カタカナでググっても全然情報出てこないんですが、 Reinventing Organizationsという本の著者のようです。

直訳すると再発明組織ですね。まさにこのブログ記事のテーマ。


確かにBufferはグローバル企業で日本に閉じた場合に上手く行くかは必ず議論として出るところかと思うのですが、 ここはむしろ日本でも組織のイノベーションの波からは逃れられないと思います。実感値として。


Kaizen PlatformのUSオフィスとBufferが同じビルってのはへぇ×2でしたw


このようにざっとSNSから声を市況かぶ全力2階建てばりに並べてみましたけど概ね好意的な意見が多かったように思います。 中には少数ながら給料公開とかダメでしょって見解の方もいましたが。 そしてやはり給料のことよりも組織論の部分に感じ入る方が多かったんじゃないかなと。

んで、このHRナビの記事読んで思い出したのが、私が常日頃書き溜めていた「もし自分が起業するなら」というタイトルのgoogleスプレッドシート。 かなりこっ恥ずかしいようなタイトルではあるんですが、今回の記事で紹介されていた事例のいくつかと共通する点が少なからずありました。 情報をオープンにした方がより良い方向に進むという実感があるので思い切って晒してみようと思います。

明朗会計

全社員が貰っている報酬を内外問わず公開する。

透明性

小声でヒソヒソ隠れて話をする必要のない会社にしたい。ヒソヒソ話が多い職場は気持ちが悪い。

アメーバ経営

会社の組織を10人前後で構成する小集団に分け、独立採算制を徹底させる「部門別採算制度」の仕組み。

小組織

10人前後のスペシャリスト同士が集まって高効率な組織を作る。報酬も会社の利益の山分け方式など。 この組織はスペシャリストだけがおり自身でマネージメントを兼務する為、マネージャーは必要ない。

評価制度

四半期毎など従来型のスパンでの目標管理シートではビジネス環境の変化による目標変更に柔軟に対応出来ない。 そこでよりアジャイルな評価制度を取り込む。

自社開発

技術を外部に委託せず自社で賄いこれを財産とする。

社会的意義

会社が社会に提供している価値に内外問わず誰もが共感してくれる。むしろ共感しない人がいない。

ノー残業

従業員の残業を原則禁止とする。家族や勉強会など社外のコミュニティを大事にすることを奨励する。


ここ1年くらいで書き溜めてきたものなんですが、読み返すとまだ抽象的過ぎるものもありますがベースラインは的を得ている気がしています。 Bufferのジョエル・ガスコインCEOもインタビューで言ってましたが、これまで既存の組織にいくつか所属していて感じた違和感をベースに、本来あるべき組織について、理想論じゃん無理無理的なことは全く考えずに書き溜めてきたものです。 個人的にはまだまだ網羅的にちゃんと考えきれていない点もあるかなと思っているので今後この記事をちょっとずつ更新していこうと思います。

書籍『「納品」をなくせばうまくいく』から見えてきたエンジニアのキャリアのこれから

結構時間が経ってしまいましたが、3ヶ月程前に 「ビール片手にプログラマーを一生の仕事にするために出来ることを考えてみませんか?」 というイベントに行ってきました。

兼ねてから直接お会いしてみたかったソニックガーデン倉貫義人さんの話を直接聞けるということで参加しようと思いました。

このイベントで紹介もされていた倉貫さんの著書 「納品」をなくせばうまくいく をちょうど読んでいたということもありました。

このイベントで本の感想をブログに書きますと倉貫さんに宣言しておきながら大分遅きに失した感があるのですが、、 この本を読んで見て感じたことを徒然に書き残しておきます。


sonicgarden book 1

エンジニアに求められるパラダイムシフト

納品のない受託開発ではビジネスにおいてソフトウェアを所有することから利用するという発想の転換が必要ですが、 エンジニアにも発想の転換が必要でそれはシステムを完成させることから持続発展させることにより重きを置くということ。

具体的には以下の様な思考の変化が必要でこれが分かりやすいです。

  • バグをなるべく出さないようにする → バグが出てもすぐ直せるようにする
  • サーバーは停止しないようにする → 停止してもすぐに復旧できるようにする
  • 機能追加をやりやすいように作っておく → 今どうしても必要なものだけに集中する(=YAGNI)

私としてはこれは経験的にその通りだという実感があります。 ただし一般に直感的には正しくないような気がしてしまうので一定の経験がないプログラマだと前者の方にウェイトを置いてしまいがちな気がします。

大事なことはビジネスドメインに近接する場所でエンジニアが仕様の決定から実装、運用まで一気通貫で対応しているか?という点です。 こういう立場で日々の開発を行っているエンジニアであればこのパラダイムシフトは非常に受け入れ易いと思います。

sonicgarden book 2

エンジニアが会社を選ぶ基準

「顧客と社員の両方を幸せにする仕組みが会社の本質」とは至言だと思いました。 倉貫さん曰く

そのために精神論を語って働かせるというのはナンセンスであり、 会社やビジネスできちんとお金が回り、評価される仕組みを作ることが経営だと思います

とのこと。裏を返せばエンジニアが現実に妥協せずこういう評価軸を持ってちゃんと会社を選別していく必要があるんでしょうね。

また会社に拡大志向があるか否かについても自分の考えを持っておく必要があります。 倉貫さん曰く

会社は大きくなくても良い。むしろ小さな会社の方が良い。

とあり、ソニックガーデンはそれほど拡大志向は持ち合わせていないと判断出来ます。 どちらが良いかは価値観の問題もあると思いますが、個人的にはこのソニックガーデンの方針に非常に共感した次第です。 この会社の方向性が自分の方向性とあまりに合わない場合はどこかで必ず歪みが出てきてしまうので注意した方が良さ気です。

そもそも倉貫さんのこのツイートのようにエンジニアがもっとビジネスセンスを持った方が良い(人が多い)ということかもしれないとも思いました。

求められるパーソナリティ

サッカーなどのチームスポーツと同じようにエンジニアにも優れた人格であることやチームの為に貢献できる性格であることが求められる、とありました。 そもそもエンジニアである以前に社会人や人として当たり前のことだとは思うのですが、 技術を追い求めるあまり個人主義に走りがちなエンジニアであるからこそ、常にチームの大事さを意識しておきたいところですね。

エンジニアは職人気質だから気難しいところがあっても仕方がないなどと私がエンジニアになりたてだった10年前は言われたものですが、 これからはそういうスタンスでは一流のエンジニアにはなれないと思います。

そして個人的には更にもう一歩進んだ考え方として「人間臭いエンジニア」を目指したいです。 人は感じて動くから「感動」というそうです。決して理屈で人が動くのではないと思います。 理屈が必要とされるエンジニアリングだからこそ、感情豊かに日々の開発ライフを送ることが必要だと思います。

sonicgarden book 3

よりスピーディーに進化していく人間としてのエンジニア

ケント・ベックリンダ・ライジング の印象的な言葉が最後に紹介されていました。 曰く

Embrace Change – 変化を抱擁せよ
Fearless Change – 変化を自然と捉えるようになった時、自ら変わることを恐れてはいけない
Social Change – 自らを変化できるようになったならば、自らの変化を周囲に広めていく

これはもはやエンジニアに限った話ではなく、より普遍的な、これからの時代に生きる人への重要な示唆に富んだ教訓ですね。 人がインターネットを得た結果、空間的な距離が問題にならなくなりより早いスピードで世の中が変化するようになっています。 裏を返せば、人の成長のスピードもより早くなる可能性があるということだと、私は前向きに捉えています。

紹介された言葉は、より早く人が成長していく為に必要なことそのものだと思いました。 そしてより深い次元では自らの変化を周囲に広めることで他の人が良い方向に変化する手助けをすることこそ、 人が更に成長する為に必要なたったひとつのことだと信じています!

Ebisu.rb#9に参加してきました!

Ebisu.rb#9に参加してきました。 #7, #8に続き 3ヶ月連続の開催で、Ebisu.rbが再開してからは今のところ皆勤賞です! yandoさん、いつも会場提供ありがとうございます!

会場の様子

ebisu rb 1


以前もこのブログに書いた通りですがEbisu.rbは最初にビールで乾杯して自己紹介から始めます。 今回#9ではビール新商品がたくさん持ち込まれていつもにも増してビールの消費量が熱かった気がします。 飲みながらtech話をやるってのは個人的には結構盛り上がるので楽しいな、と。

ただ今回結構酔っ払って何の話したのか良く覚えてないのが玉に瑕。。 翌日PC立ち上げたら残っていたのがRuby Warriorというブラウザゲームでしたw ちょっとやってみたけどなかなか面白い!

次は内容を忘れないようにして、、引き続きまた参加したいと思います!

兵どもが夢の跡

Railsでeコマースサイトを効率的に開発する為のgem, Spree (Tokyo Rubyist Meetup)

eコマースとRails – Spreeの全て というTokyo Rubyist Meetupのイベントに参加してきました。

イベント会場はVOYAGE GROUPのお洒落オフィスの Bar AJITOにて。 有料だったんでお酒を飲みながらのイベントでした。

spree 1

Oh My Glassesは中の人を知っていてRails+Spreeで出来ているというのは 知っていたのですが、Spreeがどういうgemなのかはあまり知らなかったのと、 これまでeコマースwebサイト開発にそれなりにどっぷり漬かっていたので業務ドメインを どういう感じで抽象化しているのかという点に興味があり参加しました。

Oh My Glasses白土さんの当日の資料はこちら。


迂闊だったんですがTokyo Rubyist Meetupコミュニティの説明にも書いてありましたが このコミュニティ、公用語は英語で、2つ目のセッションであるデジカ(Degica)の 中の人の発表は英語だったので、英語が得意でない私には内容3割くらいしか理解が出来なかったかなと。。

spree 2


・・・英語少しずつでも勉強しよっと。

イベントWhy Choose Ruby on Rails?に参加してきた

Why choose Ruby on Rails?というイベントに参加しました。 メンバーズさんってあまり知らなかったんですが初めてオフィスにお邪魔してきました。

Why choose Ruby on Rails 2

メンバーズさんのオフィスは晴海にあります。 私は築地から都バスに乗ったんですが本来降りるハズの駅から2駅先まで間違って行ったりで迷いました。。 正直ちょっと不便な場所だなーと率直に思ったんですが、、37階からの眺めは最高でした!

Why choose Ruby on Rails 1

イベント聞きながらメモがあまり取れなかったんですが、印象に残ったところを中心に書き残しておきます。


Sansanさん(変なイントネーション(笑))の話は以前聞いたことがあったので私にとって真新しい話はそれほどなかったのですが、 改めて話を聞いて思ったのは、「.NET文化からRailsを採用したのは勇気のいる決断だったんじゃなかったのかなぁ」ということですね。

メンバーズさんがTDDメインでraisで受託開発しているという文脈で直面した課題に、gitでブランチ切って開発終了後の動作確認時に その動作環境を用意する煩わしさを解消する為に、dokku, dockerを使った 該当ブランチの自動デプロイツールを自社開発で整備して使用し始めた、という話が印象に残りました。 gitにブランチをpushしたタイミングで該当ブランチの動作環境がデプロイされるだけでなく、hipchat等のチャットにURLが流れるようにしているそう。 このURLにwebディレクターがアクセスして動作確認をするということで、一気通貫で考えられ整備されているなぁと感心しました。

フィードフォース鈴木さんが現場で実践しているというブラウンバッグミーティングを 実践してみたいな、と思いました。簡単に言うとランチを食べながら今気になる技術やサービスについて雑談的な感じで話をするそう。 毎週火曜13:00から開催しているそうです。これはコミュニケーション促進として非常に良い取り組みだと思いました。

あと、スクラムを実践する中で、新しい人が入ってきた時やり方に合わせてもらうというやり方から、異質なものを受け入れ組織が変化していくようになってきたそう。 管理することは弊害の方が大きく、管理より信頼して現場に任せるとうまくいくという話に共感出来ました。 極論、スクラムやアジャイルってより人間的なチーム作りをどうすれば良いかってことだと思います。

話されている内容はプレゼンの中でも実際紹介されていたGoogleエンジニアのチーム作りの話が書かれているTeam Geekという本の内容に近いことなぁという印象でしたが、 良かったのは実経験に基づいた現場の話をされていたことで、聞いていて説得力がありました。 Team Geek、私も読みましたが非常にオススメです!

クラウドワークスがrailsエンジニア採用に困ってやったことが、クラウドワークスを使ってrailsエンジニアを募集したそう。 2012年当時11名応募があって6名お願いしそのうちの数名は現在もお願いしている人もいるとのこと。 eat own your dog foodが大事だねと。分かります。

CIはSEMAPHOREを採用しているそう。Circle CIは 無料枠だと15分で問答無用でインスタンスが切られるということでその制限のなかったSEMAPHOREを選択したとのこと。 CW大場さんが紹介されていたレガシー依存の悪循環って図が面白かったです。

あとクラウドワークスのエンジニアはPHPにうんざりした人が嬉々としてRubyのコードを書いてる感じだ、という話に PHPカンファレンスの実行委員を長年されているメンバーズ川井さんが「しばらく落ち着いていたPHP disりが久々に炸裂ですねぇ でも大したことないか」 というようなニュアンスの発言されていたのがクスっときました。


話を聞いて改めて再認識しましたが、Railsはアジャイルの文脈で対になって語られるということです。 一言で言うとThe RSpec Bookでの語り口のような感じですね。

あとメンバーズさんが TDD + CI でテスト回すの素晴らしいってプレゼンの流れの中でDHHTDD is deadが触れられてました。 というか、TDD,テストファーストの論争はここでは触れませんという話だったんですけどもw やっぱりこれ、色んな所で論争を引き起こしてるようでちょっと楽しくなっちゃいました。 少なくとも世界中で改めてTDDやテストのことを再考しようじゃないかと問題提起したDHHが凄いなぁと思いました。

最近scalaが流行りつつあるような兆しもありますし、将来的にRailsがレガシーになる可能性も考慮に入れておく必要はありそうかもですね。 Restfulな設計思想であるRailsはRDBMSのテーブルと画面が密結合しているwebサイトではかなり開発が効率的ですが 一方でその限りでないwebサイトも今後増えてくるとRailsのアドバンテージは下がりそうな気がします。

大事なことはRailsに現状どっぷりでも、最新技術動向には常にアンテナを張り思考停止しないようにすることですかね。 とはいえRailsはちょっとした動的webサイトを量産するのに現状だとベスト・プラクティスかなと個人的には思います。 なのでしばらくの間はたくさんのRailsアプリを開発しまくりたいと思っています!

Railsでテストを書く場合、FactoryGirlなDB接続するかmock_modelなモック作成か(Ebisu.rb#8)

前回のEbisu.rb#7に引き続き、 Ebisu.rb#8も参加しました。

勉強会の形式は前回同様で飲みながらRuby関連ネタを語り合う感じでした。 前回は19:30集合でしたが前回のKPTから20:00から開始でした。 今回は事前に仕込んだLTネタが3件あり話題が豊富でしたね。 当日の雰囲気はハッシュタグ#ebisurbの 4/25の参加者のつぶやき見てもらえればイメージ湧くかと。

後半ひと通りLT的な発表が終わってからお酒も進んでの雑談の中でRailsでのテストをどんな感じで書いてるか? という話題になりました。個人的に今回LTネタ的な感じで発表してみようかなと思っていて結局できなかったので 考えを整理する為にも書き残しておこうと思います。


結論から言うと私が関わるプロジェクトの場合はpoltergeist+turnip+Capybara+FactoryGirlで受入テストを、 Rspec+mockでユニットテストをそれぞれ書いています。 受入テストは正常系やKPIに直接関わるテストを中心に実装しています。 ユニットテストは基本カバレッジベースでモックを用いて疎結合なテストを実装しています。

前者の受入テストについては参加者の中での議論でpoltergeistやturnipを使うか否かで違いはあるものの それほど大きな違いはなさそうでした。翻ってユニットテストでFactoryGirlでDBに接続するテストを書くか、 モックを用いて疎結合にテストを書くかでは少なくとも参加者の中では二分していました。

個人的にはコンテキストによりけりでよりbetterな選択を繰り返していくことが大切だと思います。 なのでFactoryGirlでDB接続するテストを書くかモックでDB接続を極力せずテストを書くかは ケース・バイ・ケースでプロジェクト毎に合意を取りながら決めていけば良いのかなと。


という前提を踏まえながらも私がモックを使うテストを書く理由についてまとめておきます。

  • RailsはRestfulな設計思想が秀逸でその設計思想のレールに乗ると開発効率が上がる
  • Railsの設計思想を端的に表しているのがActiveRecord
  • 規模が小さいうちはthin-controller, thin-modelでスマートな開発が可能
  • ある程度のデータ量や複雑なビジネスロジックが追加されると段々これがfat-modelになりやすい
  • fat-modelをリファクタリングする方法としてこの記事が有名ですが、このようなリファクタリングや最初からクラス設計に組み込んで実装する場合、クラスやモジュールの依存関係が発生する
  • この依存関係を実装段階で出来るだけ分離しながら進めていく設計手法の助けとしてモックやスタブを駆使する

大体こんな感じです。


余談ですがこの辺り、Rails作者のDHHのブログエントリ 「TDD is dead. Long live testing.」 でTDDに一石を投じたエントリにも通じるような気がしています。 (和訳はこちら)

この話に言及し出すと長くなりそうなので別の機会に。次回のEbisu.rb#9のネタにでもしようかなw