はじめに

─本日は、はてなブログチームからプロデューサー兼ディレクターの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で「はてなブログの開発フロー」について話してきました - 大西ブログ）

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

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

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

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

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

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

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

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

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

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

id:onishi

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

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

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

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

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

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

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

おもしろ画像を貼る

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

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

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

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

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

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

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

onishiそれも良い。

hitode909LGTM.inっていうサイトをよく使ってます。「良いと思います（Looks Good To Me＝LGTM）」と言いたいときに貼れる画像が集まっているサイトです。

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

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

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

shiba_yu36僕だけだと思います（笑）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

onishi毎週出してます。93週連続リリース中です！（編注：座談会の時点で）

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

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

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

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

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

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

hitode909LGTM.inですね。最新ツール。

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

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

─分かりやすい。

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

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

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

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

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

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

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

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

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

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

id:cockscomb

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

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

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

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

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

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

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

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

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

shiba_yu36それはある。

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

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

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

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

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

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

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