寝る前にラーメン

Software Engineer at Wondershake

2012-04-30

エンジニアの生産性と集中力、スタートアップと少しからめて

GWなのに具合が悪くて(´・ω・`)

もう寝ようと思っていたら、
WEB+DB vol.68 pp.2-3「プッシュ型メディアが生産性に及ぼす影響」
を読んで感化されたのでブログ書くことにしました!

全くまとまりのないタイトルで残念なのですが、自分の最近の働き方と絡めて感想を綴りたいなと思います。


記事の中では、 

知識労働の中でも、プログラミングは特に高い集中力が必要な仕事である。
十分に集中力の高まった状況(「ゾーン」と呼ぶ人もいる)に自分を持っていくのにはそれなりに助走時間がかかるので、1日に何度も入れるものではない。そのうえ、集中して仕事をするのにはかなりの体力も必要なので...

 とエンジニアはとても集中力が必要なんだよと説明しています

それにはとても共感していて、私自身もプロジェクト初期の設計段階や大事な認証部分などのロジックを考える時はひとりモレスキンを持って静かなカフェに篭ったりもしていました。

手慣れた実装や「刺身たんぽぽ」のような作業は集中力が浅い状況でも問題はないのですが、そういった作業は極力自動化されるべきですよね。


それを踏まえた上で「プッシュ型メディア」の影響について書かれています。

「集中力」を高めてゾーンに入って」コーディングしなければならないソフトウェアエンジニアにとって、このプッシュ型メディアの影響はとても大きい。
たとえ「Facebookに新しい投稿されたメッセージをチェックすること」そのものには10分しか費やさなかったとしても、せっかく入った「ゾーン」から引きずり出されてしまうのであれば、失われた時間は 10分よりはるかに大きくなる。

まさにその通りだと思っていて、TwitterFacebookからのプッシュ通知を全て受け取っていたら浅い集中力の領域から抜け出せないと思います。

これは「プッシュ型メディア」だけでなく、単純に近くの人に話しかけられたりすることも一緒ですよね。

自分も集中力の高さがウリだったので、作業中に話しかけられたり、喧騒な場所で作業をするのをとても嫌っていました。

今でもスカイプを起動していないのもこの理由です笑

とはいえ、それによって相手の作業が滞ったり、チームとしてのスピード感が無くなってしまうのは本末転倒なので、最近は極力即時的にレスポンスを返せるように努力しています。

いわゆるスタートアップと呼ばれるようなチームにおいては1人の領域がとても広いので、決まった領域のことを淡々とこなせばいい時間は非常に少ないと感じています。

圧倒的な集中力が必要なエンジニアリングとコミュニケーションの速さのバランスが難しいのですが、これにはソフトウェアエンジニア以外の人の理解が欠かせないと思います。


ところで、naoyaさんのブログにこのような記事があったのを思い出しました。

naoyaの寿司ブログ
"時間をこま切れにされたら、人は何ものにもなることができない"

その中で紹介されている吉本隆明さんの 『ひきこもれ』という本の中で

「分断されない、ひとまとまりの時間」をもつことがどんな職業にもかならず必要なのだとぼくは思います。

とあります。

ひとりでいると欝になるので引きこもって作業するのは好きじゃないのですが笑、「分断されない、ひとまとまりの時間」はとても大事で、その領域を極めるためには絶対必要なものだと思います。

差がつくのはこの時間の質に依るはずです。それがソフトウェアエンジニアの領域においては集中力だと思っています。


ソフトウェアエンジニアには集中力が必要です。

だからといって、エンジニアには仕様書以外渡すなとか笑、SNSは全くやらないほうがいいといった類いの主張ではありません。

ただ、そういった周りの理解がより高品質なサービスを生むと信じています。

自分もコミュニケーション量をうまく保ちつつも、集中力を高めて作業できるようにしてきたいなと思いました:-)

2012-04-21

Heroku JP Meetup #4に参加してきました

4/20(Fri)にATNDで見つけたHeroku JP Meetup #4に参加してきました!
あまり長いセッションではなく、短時間でしたがとても面白いイベントでした。

基本的にセッションは英語で、Heroku Add-onを提供している方がそれの解説をしてくれました。
主に3つで、、、 

  • IronMQ
    名前の通りMessageQueueを提供する。
    ローカルよりは遅いけど、Amazon SQSよりも早く動くよって。
     
  • WebSolr
    テキスト検索の話から順を追って解説してくれた。
     
  • Papertail
    集約したログをウェブから閲覧できる。
    検索もできるし、条件に合うログが吐かれるとメールをしたりiPhoneに通知したりできる。 

どれも興味深い内容。

そもそも自分は、お恥ずかしながらHerokuをまだ使ったことがなかったので、
紹介されたサービスの魅力に加えHeroku Add-onのパワーに驚きました。

またHeroku, PaaSの代表としての勢いも感じました。
ハードウェアを意識しなくて良いAWSも素晴らしいけど、
Herokuのようなサービスが地理的にも言語的にもどんどん広がっていってくれれば、
小さなサービスのイニシャルコスト(ほとんど人的なものだし)は大幅に減らせると思うので。

是非是非自分も使ってみたいのだけれど、
日本向けのサービスを中心に作っている今ではやはり西海岸からのレイテンシは無視できない(´・ω・`)

東京リージョン期待!のような旨をプレゼンに挟まれている方もいらっしゃったが、本当にそう。
マルチリージョンそろそろこないかなー

下部に貼り付けてある写真は、会場の様子。
(パソナさんのFacebook Pageから拝借) 

ちなみにパソナの社員さんはとてもフレンドリーで会場もとてもきれいだった。
会場のご提供ありがとうございました:-)

そしてこのような場を提供して下さったHerokuの関係者の皆さん、ありがとうございました:-)
こういったコミュニティの発展に、微力でも貢献していかなきゃいけないなと思いました。 

2012-02-22

ONLAB Hackathonに参加してきました!

2/18~2/19の週末に行われたOpen Network LabのHackathonに参加してきました。
チームはいつものWondershakeのメンバー。

100人ぐらいのエンジニアが集まり、もうお祭りでした笑

大人数が黙々と作業をしていたのでどんな雰囲気になるんだろう、と思っていましたが、
会場は心地良い音楽と周りのチームの話し声が混ざって、とてもいい空気感でした。

f:id:thleave:20120218142503j:plain

私たちのチームは、「Wondershakeの業務では作らないようなアプリを作ろう!」と話していました。
いろんなアイデアが生まれ、中には他のチームが実際に作っていたアイデアもあったのですが笑、
結局このようなアプリを作ることにしました。 

f:id:thleave:20120222022216p:plain

どこかのソーシャルグラフを使ってそこでVoIP通話が出来るようにしたいと思っていたのですが、
Hackathonで出来る作業量では無いことに気づき笑

Twilioに頼っても現状では実装が難しいことが分かり、
録音した音声をリアルタイムにiPhoneに転送することにしました。 

f:id:thleave:20120222022858p:plain

これが意外にもウケて。
通話しなくていい気軽さと、
録音した音声が(止めない限り)エンドレスにリピートされる面白さが良かったのかな、
身内ではかなりの高評価でした。

Hackingの後は44チームによるプレゼン大会。

f:id:thleave:20120222023709j:plain

 (2分間で、iPhoneを2台使ってデモをするのはなかなか大変でした)

f:id:thleave:20120219182630j:plain

どのチームも面白いアイデアばかり。
また、モノは出来上がってないけど、プレゼンが面白いチームもいくつかあって笑
エンジニアという名前に甘えて、プレゼンをうまく出来ないのはダメだな〜と改めて思いました。

その後、みんなで懇親会&表彰。
36時間のHackingだったので寝てない人も多く、
自分を含め不思議なテンションの人が多かったかな笑

f:id:thleave:20120219191840j:plain

私たちのチームは、DNP大日本印刷)さんに特別賞を頂くことができました!
図書券5万円分です!これでオライリー本を買います笑

 

今回のイベントは本当に有意義なものでした。
運営の方々に本当に感謝しています。 

また、たった2日でもこれくらいの品質ものもが作れるんだという自信も生まれました。

エンジニアなんだから作ってナンボ。デモしてナンボ。
もっともっとモノづくりに励みたいなと思える2日間でした。 

2012-01-08

Rails3で論理削除と多対多の関係を作ろうとしたら詰まった

Rails3で、以下のふたつを同時に実装しようとしたらダメだった。

  • rails3_act_as_paranoid
    テーブルにDATETIME型のdeleted_atを
    追加すると論理削除が簡単に作れるもの
  • モデル間の多対多の関係(habtm; has_and_belongs_to_many)

 どうダメかって、こんな風に怒られた。

SystemStackError (stack level too deep):

もちろん前者の rails3_act_as_paranoid を外せばうまくいく。

どうやらrails3_act_at_paranoidを使うと、

has_and_belongs_to_many :hogehoge

のところでエンドレスになっちゃう。

他の論理削除を実装する同様のgemも探してみたけど、
同じエラーを吐いたので諦めた。

素直にModelにdefault_scope書いてとりあえず蓋をした。

こういうのをforkしてひょひょいと直しちゃえる人に今年はなりたい、というかなるー