はてなアプリケーションエンジニア座談会

はてなでは、さまざまなサービスの開発を、複数のチームに分かれて行っています。サービス開発の現場で、アプリケーションエンジニアはどのように仕事をし、どんなことを大切にしているのでしょうか。はてなブログやはてなダイアリーを開発する「はてなブログチーム」から、id:onishi、id:hitode909、id:shiba_yu36、id:cockscombの4人に話を聞きました。
はてなエンジニア 左からid:shiba_yu36、id:hitode909、id:cockscomb、id:onishi

目次

はじめに

本日は、はてなブログチームからプロデューサー兼ディレクターのonishiさん、そしてアプリケーションエンジニア3名にお集りいただきました。はてな社内にはいろいろなチームがありますが、特にブログチームではこのように開発している、という話をお聞きしたいと思います。よろしくお願いします。

onishi こんにちは、onishiです。はてなのチーフエンジニアも兼任しています。

この中で、onishiさん以外でチームに一番長くいるのは?

hitode909 僕です。2012年5月くらいから。

cockscomb 僕はそれよりも後で、shiba_yu36さんより一瞬早いくらいだったはず。

shiba_yu36 ほぼ同期だ。

onishi 今ブログチームのエンジニアは、この他にもう1人と、アルバイトエンジニアが2人ですね。

エンジニア、足りてますか?

cockscomb ちょっと足りないです。

onishi 最近、忙しいです。人がいくらいても足りない!

YAPCの発表から、かなり変わった

onishiさんは「YAPC::Asia Tokyo 2013」で「はてなのイマドキの開発フロー」というトークをされましたよね。この中ではGitHub Enterprise(以下GHE)のIssueやPull Requestの活用、Jenkinsを使った継続テストなどの話をされています。

(*はてなのイマドキの開発フロー - YAPC::Asia Tokyo 2013

onishi 実は、この発表からだいぶ変わってます。昨日また、大きくやり方を変えようという話をチームでしました。やっぱり開発フローは完成することがなくて、メンバーやチームの状況に応じて変わります。常に変わり続けるのが重要!ということでこの座談会の結論としたいですね。

終わらないでください! どういうタイミングで「変えよう」となるんですか?

onishi うちのチームは自発的に振り返って、「変えよう」という声が日々上がってきます。有機的な組織である! 自己学習している!! とアピールしたい。

と言ってますけど、実際そうなんですか?

hitode909 だいたいそうです。日々、仕事していて、先週より調子が悪い、このツールおかしいから変えよう、こういうこと忘れがちだからこうやったらいい……とかIRCで話してて、ツールとか勝手にすぐ作る。

onishi メインの仕事をいったん置いて、そういうフロー改善をやってもかまわない、というチームにしています。なので、そういうことがどんどん起きる!ということを対外的にアピールしたい。

対外的な部分をそこまで意識しなくても大丈夫です。

開発フローが合わなくなると、みんなで声をあげる

同じはてな社内でも、開発フローはチームによって違いますか?

onishi かなり違うかな。プロジェクト管理にRedmineを使っているチームもあれば、Trelloでタスク管理しているチームもあります。

id:onishi id:onishi

ブログチームでは、タスク管理はどのように?

onishi GHEのIssueです。でも破綻しかけてます。YAPCのころはギリギリなんとかなっていたのですが。

shiba_yu36 タスク量が増えてきたのが一番大きい原因ですね。Issueがあったら必ず誰かにアサインしてたんですけど、最近は1人50個とかになってしまって、その中で優先度を決められなくなっています。

hitode909 飲んでいるときに、みんなが「もう無理だ」って言いはじめて。やり方を変えないとだめそうって、すぐにonishiさんと話しました。

onishi 1人20個くらいまでならいけるけど、40個とか50個になると本人も分からないし、僕も管理できない。もともと僕はあんまり管理してなかったんですよ。各自20個くらいなら自分で管理できるから、管理コストはゼロだったんですよね。

変わっていく状況にあわせて、開発フローも常に試行錯誤、ということですね。新しいフローを決めるにあたっては、どのように進めていますか?

onishi 具体的な提案を持ってきてもらうことが多いです。で、検討して、それでいこうと。

おもしろい画像を貼る

GHEを使ってPull Requestベースで開発を進めるというフローは、今では多くのWeb企業が導入に前向きですが、自然とそこに辿り着いたんでしょうか?

hitode909 みんなもともと個人でGitHubを使ってたし、会社でも使えるならそのまま使いたい、という話になった感じです。

shiba_yu36 最初はフロー関係なく、とにかくGHEを導入したいという気持ちでした。検討していたころは「どこどこがGHEを導入した」という記事が話題になりはじめてて、特にどこかを参考にしたわけではないけど、1年くらい経ったら他の会社と同じような結論に至ってました。

hitode909 コードについて簡単に話せるのが良い。

onishi しかもそれが残るのがいいよね。

shiba_yu36 行ごとにコメントを書けるのも良いんです。アルバイトからコードレビューしてくださいと言われたとき、それまではファイルを送りあったりしてた。

hitode909 コメントに画像を貼れるので、おもしろい画像を貼ったりしてます。

onishi それも良い。

hitode909 LGTM.in/gっていうサイトをよく使ってます。「良いと思います(Looks Good To Me=LGTM)」と言いたいときに貼れる画像が集まっているサイトです。

shiba_yu36 でも、たまにイラっとする画像があって、あんまりむかついたら消してる……(笑)

hitode909 今それが一番問題になってる。

cockscomb これ怒ってるのshiba_yu36さんだけかもしれない。

shiba_yu36 僕だけだと思います(笑)

onishi たしかに貼られたらイラっとするのはある(笑)

cockscomb LGTM.inは、はてなスペースのチームから輸入したんですよ。

onishi GitHub用のブックマークレットもあって便利ですね。

ペアプログラミングと「アサインおみくじ」

日々の開発についても少し教えてください。例えば、ペアプログラミングはどれくらいやっているでしょうか。

onishi 一応、ペアプロは義務にしているけど、毎週必ずやるっていうほどでもないかな。

hitode909 でも最近、ペアプロちょっと流行ってます。みんな、飽きてきたらペアプロをやる。

id:hitode909 id:hitode909

onishi 気分が入れ替わる、みたいな効果があるのかな。

cockscomb つらいタスクをやるときに良いですね。

onishi もともとペアプロは、エクストリーム・プログラミング(XP)のプラクティスのひとつですが、普段からどんどんやったらええやん、と導入したんです。確かに、集中力が持続してコードの質が上がる、などの効果もあったし、重いタスクをやるきっかけになるとか、開発環境が整備されるといった効果も出てきました。

hitode909 詳しそうな人をつかまえてペアプロしたり。

onishi アサインおみくじ」というものを導入して、アサインをランダムに当てるようにしたんです。結果、そのコードに詳しくない人がアサインされたりする。仕方がないから、詳しい人をペアプロ相手として捕まえてコードを書く。

アサインおみくじ! タスクの担当者を選ぶおみくじがあるんですか?

hitode909 僕が作りました。あるタスクを誰がやるかを、どう決めるか……という問題があって。

cockscomb 最初はonishiさんが決めてたけど……。

hitode909 どうしても属人化していく。このタスクは誰々が好きそうだからやってもらおう、みたいな。そうなると、そこのコードはその人しか分からなくなって良くない。毎回いろんな人がやった方がいいだろう。そうなると、おみくじしかない。そう確信して、10分くらいで作りました。

onishi いろいろな施策が絡み合って、相乗効果を上げていますね。ときにはチームのメンバーが入れ替わったりもするので、属人化すると良くないですから。

hitode909 最近onishiさんの能力が増してきて、狙ってこの人に当てる、みたいなことができるようになってる。

cockscomb いやいや、目押しできるはずないです(笑)

エンジニア以外もGHEに入ってくる

少しベタな話で恐縮ですが、チーム内のコミュニケーションの話も。口頭でも話したりしますか? 以前、「はてなは会議室以外では会話禁止」という誤解が広まったことがありましたけど。

shiba_yu36 それ自体は誤解だったけど、半年くらい前はブログチームでは、集中が途切れるからGitHubで非同期コミュニケーションした方がいいじゃん、という状態でした。でも最近は、その場でパッと話し合った方が、困ったことを他の人も気付けていい、となりつつあります。

id:shiba_yu36 id:shiba_yu36

cockscomb 意識してやっているわけではないんですけど、結果的に今は口頭が流行ってますね。

shiba_yu36 僕の中でGitHubはすごく便利で、コードのレビューはやりやすいけど、誤解を生むことも多々あると思ってて。文字だけじゃ全然伝えられないんですよ。こっちのコメントに対して、相手が「えっ」て思ってるかもしれない。「これはこうじゃないんですか」という言葉が、怒ってたり、非難してるように見えてしまうことがよくある。ちょっと気になってることは、本人をつかまえて直接話すようにしています。

口頭の方が良い場合は口頭で、GitHub上での方がよければGitHubで、という感じですね。そういえば、エンジニアだけでなくデザイナーともGitHub上でやり取りしているんですよね(参考:座談会デザイナー編)。

cockscomb そうですね。デザイナーさんもGitHubをガリガリ使ってて、全然問題なさそう。

shiba_yu36 GHEを導入してから、デザイナーさんとのやりとりが楽になったんです。新機能を作りましょうというとき、Issueがひとつあって、エンジニアがコード書いて、「じゃあここからデザインお願い」って言うと、デザイナーさんがそのままIssue上で作業して、みんなで見て……という。全部、時系列で見えるのがやりやすい。

cockscomb GHEで垣根なくコミュニケーションできてて、はてなのデザイナーすごい。

onishi 最近はユーザーサポート担当もGitHubを見てるし、直接Issueを立てるようになってますね。

Web企業だとデザイナーもGitHubで、というのは増えてきてると思いますが、ユーザーサポートまで使ってるのはすごいですね。エンジニア以外の方がどんどんIssueを立てるという運用で、困ったこととか、少し感覚が違うなどの問題は起きませんか?

hitode909 感覚のズレは今のところないです。

onishi エンジニアにうまく合わせてくれていますね。企画担当ともGitHub上でやり取りしています。

エンジニアが使いやすいツールに、他の職種の人もどんどん入ってきているわけですね。

onishi ただ一方で、社内では「はてなグループ」を長年使っていて、何かあれば社内グループにどんどん書いて残していくという文化だったんですけど、最近はGHEが便利すぎて、グループを検索しても情報が得られない、という問題も出てきてます。この辺りはもっとうまくやりたいですね。

テストとコードレビューを大切にし、サービスをどんどん進化させる

そのほかに、ブログチームで大切にしていることはありますか? 例えばテストについて。以前hitode909さんが「テストは書きすぎるくらい書いた方が良いと思う」とブログで書かれていましたね。「人間は手抜きするから、執拗にテストを書こうって言ってると、自然とそれからちょっと下がったくらいの品質になる」という話は面白いなあと思いました。

shiba_yu36 テストを書かないと怒りますね。

hitode909 テスト、書きすぎるくらいじゃないと怒る。

onishi テストは重視しています。テストディレクトリが、プログラムのディレクトリの倍くらいの行数になってます。書きすぎるくらい書いた方が、長い目でみたときに開発効率は上がってると思うし、それがユーザーさんのためになると思うんですよね。

cockscomb 書きすぎるくらいテストを書いていないと、コードレビューが通らないので、そもそもリリースできないです。

コードレビューの話も出たので、そちらの話も。

hitode909 14時からレビュー時間にしています(編注:はてなは13時から14時までがランチタイムなので、14時は「午後の始まる時間」に当たる)。すぐたまってきちゃうから、1日1回やろう、みたいな。

「コードレビューこわい」という人もいたりしますが……。

shiba_yu36 レビューされてバグが発見されるというよりも、レビューされるようになって、「見られるから、ちゃんと書こう」という意識が高まった、という方が大きいです。忙しいから良くないコード書いちゃうみたいなことが昔はあったけど、それだとレビューが通らないから、ちゃんと書こうという気持ちになる。レビューはとても良いですね。

なるほど。ところで、はてなブログはどんどん新機能を出していますよね。

onishi 毎週出してます。93週連続リリース中です!(編注:座談会の時点で)

hitode909 新機能を毎週出すのが前提になってて、文化になっています。

onishi サービスをどんどん進化させていこう、という思いがあります。はてなのサービスは、ユーザーの要望に応えて進化する。そういう期待を持っていただいてると思うんです。その期待に応えていきたいですね。

個人でサービスやアプリを作る場合と、はてなのサービスとして作る場合とで、意識が変わる部分はありますか?

hitode909 同じものを作るにしても、はてなとして作るときは、より多くの人に使ってもらうことを意識します。いろんな人が使うものだから、ちゃんと使いやすいものを作ろうと。個人だと妥協してしまうところでも、はてなとして出すときは妥協しないように。

「楽したいから、めっちゃがんばる」

そのほか、最近新しくやっていることはありますか?

hitode909 LGTM.inですね。最新ツール。

それはもういいです……。

shiba_yu36 細かいものだと、Jenkinsのテスト結果をIRCに投稿するようにしました。通ったら【朗報】、落ちたら【悲報】って書かれます。

分かりやすい。

onishi 今日は悲報多いなーとか。

今日の話を聞いていても、メンバー個々人が「良くしよう」というモチベーションを高く持っているように感じますね。

hitode909 悪いままだとずっと悪い。良くしたいです。

cockscomb そもそも自分が便利になるためにツールを作るのは面白いです。

onishi 開発ツールもそうだし、はてなブログというサービス自体も、僕らたくさん使ってますしね。

働き方という面では、皆さん、けっこう早く帰っている印象があります。

onishi ブログチームでは、8時間で9時間分の仕事するために、開発効率どう上げるか考えて、開発フローを効率化したほうが良い、という考え方で仕事をしています。

shiba_yu36 昔、残業したら次の日に効率が落ちて。そういうのは良くない。チームでも、仕事が終わってないから残業しようよ、みたいな雰囲気は無いですね。

onishi 特にはてなは、今日やると翌日大きく効果が出る、というタイプの開発ではないことが多いので。1~2時間でも多く働けばすごく良くなるとか売上が上がる、みたいなものではないですし、継続的に良いものを作るしかない。そうなると、無理して残業してもしょうがない、というケースが多いんです。

cockscomb 8時間で、異常な効率で、異常な速度で開発するの最高、というのがブログチームですね。

id:cockscomb

hitode909 最近はもう毎日なにかしらリリースしていて、これは今日中に出したいから速くやろうとか。

shiba_yu36 1日3回とか。デプロイするコストがほとんどないので、どんどん出す。

onishi ホットデプロイの環境があるので、ユーザーさんにも迷惑を掛けないで済みます。

cockscomb まとめてリリースするとおかしくなるし。

onishi diffが1万行たまったら、そろそろ出さないとやばい、みたいな。

cockscomb 1万行を超えると、一気に変えたら絶対おかしくなる。

shiba_yu36 ユーザーさんに不具合を出したくない、という気持ちでやってます。

onishi みんな意識高いよね。できればサボりたいみたいな人が1人いると崩壊しそう。

cockscomb 楽したいからめっちゃがんばる、という感じです。

shiba_yu36 それはある。

どんどん改善してくれる人に来てほしい

では最後に、はてなへ入社してほしいのはどういうエンジニアですか、という質問で締めたいと思います。

cockscomb おもしろいことをしでかしそうな人に来てほしいです。

shiba_yu36 ブログチームは、はてなの中でもけっこう独特な感じで、業務時間中に突然、別のことをしたりしてる。さっき言ったツールの改善とか。なので、普通に仕事をしつつも、これは嫌だと思ったところをどんどん改善してくれる人だとうれしいなと思います。

hitode909 突然コメントにおもしろ画像を貼ったりするので、嫌な顔せず一緒に貼ってくれる人がいいですね。

onishi 今日お話しした、スピード感のある環境に飛び込んでみたい人をお待ちしています。技術スキルももちろんですが、Webサービスが好きな人、新しい技術やトレンドに興味がある人、コミュニケーションスキルのある人、どんどん発言する人ですね。ぜひ一緒に、はてなで働きましょう。

ありがとうございました。