こんにちは、マンガチームアプリケーションエンジニアのすてにゃん ( 
id:stefafafan ) です。マンガチーム以前はMackerelチームに所属していて、その時の仕事については以下の記事を参照ください。
「はてなではどういうものを開発しているのだろう？」「あの方はどういう仕事をしていて、どういう事を意識しているのだろう？」など、気になっている人もいると思うので、今回ははてなのマンガチームでの仕事を紹介したいと思います。
はてなのマンガチームとは？
はてなでははてなブログやはてなブックマークのサービスで培った技術やノウハウを元に、企業のWebサービスの開発や運用の支援をしています。マンガチームでは直近でマンガアプリ「ジャンプルーキー！」の開発にも関わりました。
hatenacorp.jp
上記のスマホアプリの他にもGigaViewerというマンガビューワの開発もしています。ユーザーとしても快適に利用できることを目的としている上、サイトを運営する出版社への支援として広告の運用・販売なども行っています。このマンガビューワは現在5つのサイトに導入されています。
hatenacorp.jp
hatenacorp.jp
hatenacorp.jp
hatenacorp.jp
hatenacorp.jp
はじめてのチーム異動
僕ははてなに新卒で入社して最初の2年くらいMackerelチームに所属していました。なので、社会人として仕事する際にMackerelチームでのやり方しか知りませんでした。そこで、チーム異動の提案があり、自分でも確かに色々な環境は経験出来るうちにしたほうがよいと思い、マンガチームに2017年の8月にジョインしました。はじめてのチーム異動が僕にとってどうだったかというと、結論から言うとあらゆる面で良い刺激になりました。会社が変わったわけではないのにチームや関わるプロダクトが変わると自分が思っている以上に色々な点が変わるのですね、と気付きました。
具体的に変わった点としては:
- チームメンバーが変わった、Slackなどの雰囲気が違う
- Mackerelチームでもマンガチームでも雑談はよくあるけど、何だかとにかく雰囲気が違う、もちろん雑談するネタが監視サービスかマンガビューワかとその時点でも違う
- チームでの開発のフローが違う
- Mackerelチームではスクラムに少し手を入れたような手法を取り入れていて、2週間置きにタスクを振り返ったり割り当てたりする、というのを繰り返していた。マンガチームはそういうのはやらずに、タスクやメンバーの状況に応じて柔軟にアサインをつけたり外したりしていました。スクラムに慣れていた自分としては、週の途中で突然タスクが変わったりするのは最初戸惑いましたが最近は慣れてきました
- 使っている技術が違う
- MackerelではScalaやPostgreSQLやGoを使っていました。マンガチームではPerlやMySQLを使っています。また、Mackerelに所属していたころには使っていなかったVarnishなども使っています。
- プロダクトの性質が違う、ユーザー層が違う
- Mackerelはグラフを描画したり通知したりするサービスです。なので、書き込みは多いし、グラフもなるべくリアルタイムな値を表示したい。マンガチームで僕がここ最近メインで関わっていたGigaViewerはマンガビューワなので、書き込みよりは読むほうが多いし、大体が画像です。また、マンガ画像は毎分変わるようなものではなく、変わるとしても毎時0分とかが多い。
- 更に、Mackerelはエンジニアが昼間に見ていることが多いのに比べて、GigaViewerはユーザが休み時間（通勤時、昼休み、深夜コンテンツが切り替わった時間など）に見に来ることが多いです。
などなど。元々Perlを1行も書いたことなかったので、それだけでも結構不安が大きかった印象があります。Mackerelチームに新卒で入った直後は結構戸惑ったのにこのタイミングでマンガチームに入ってどれくらいで一人前になれるのだろうか、と。ちょうどその頃以下のような記事を書いてました。
わりとアウトプットすることを意識していそうですね。ちょうど同じタイミングで先輩エンジニアがマンガチームに同じように異動となり、彼はとにかくアウトプットを沢山しているのを目の当たりにしていたので結構意識していました。困っていてもそれを外に出さない限り誰も助けようがないですからね。幸いはてなでは些細なことでわからないと言っても誰も馬鹿にはしないしむしろ助けてくれるので安心感はあると思います。
GigaViewerに関わり始める
異動直後の1ヶ月ほどはPerlの勉強をしつつ、コードの雰囲気を眺めたり、細かめのタスクをやったりリリース作業を経験したりしました。1ヶ月くらいしたらわりと慣れてきたのでもう少し本格的に仕事に参加するようになりました。上長と面談などもしつつ、僕はGigaViewerをマガポケのWeb版で採用するための準備をすることになりました。この時は不安いっぱいでしたが、今思えばここで関わったおかげでGigaViewerの全体像が突然見えてくるようになりました。
GigaViewer採用3例目「マガポケ」
GigaViewerは僕がチームに入る前にすでに少年ジャンプ＋にて採用されており、その後2例目としてとなりのヤングジャンプでも採用されました。
いずれも僕はそこまで深く関われなかったので、3例目のマガポケでの採用でも具体的に実装のどこをどうすると横展開できるのか、エンジニア面以外でどういうことをする必要があるのか、広告面はどうなっているのか、よくわからない状態にいました。
ありがたいことにこの時は周りのエンジニア、デザイナー、ディレクター、プロデューサーに助けられながら10月末に無事リリースできました。
この時僕がやったこととしては:
- マガポケでのマンガ画像のアップロードに必要な情報などをまとめる・管理画面を用意し、マンガの公開日の調整が出来たり連載の設定が出来るようにする
- 手元/開発/ステージング/本番環境でちゃんと確認できるようにする
- 特定のロジックでトップページや連載一覧ページに特定の作品のエピソードなどを出すようにする
- トップページにある「おすすめ試し読み枠」は今回新しくGigaViewerに追加した機能
- 広告の設定、OGPの設定などを入れる
- 横展開する際に実装面で対応が必要な面を洗い出し、レポジトリにドキュメントとして残す
こうしてみるとそんなに大変な作業ではなかったような気がしてきますが、既存のサイトになにかを増やすというのではなく、新しくWebサービスを立ち上げるという感じなので、見落としが無いかとか、気をつけるポイントは色々あります。
更にMackerelチームの頃全く意識していなかった点としては、
- Internet Explorer 11だとか、iOSやAndroidもちゃんと対応する必要がある（MackerelのWebサービス場合はChrome/Firefoxの最新版を対象としていました）
- OGPを気にする（Twitterでのシェア時など）。現状のMackerelは大体のページがログインが必要な画面で、Twitterでそのままシェアするみたいな用途は意識していなかった。
- Varnishのキャッシュが強力なので、手元でキャッシュ切った状態で実装してよさそうと思ってもデプロイしたら実はキャッシュされてしまい上手くいかないなんてことが起きうる
最終的にリリースされたサイトは、僕にとってははじめて色々な面に自分で関われたログイン不要のサービスということでしばらくずっと夜中とかに眺めていました。
pocket.shonenmagazine.com
自分が関わったサイトずっと眺めてる
— すてにゃん (@stefafafan) 2017年10月31日
また、自分はアニメを見るのが好きなので、自分が関わったマガポケで見たことあるアニメの作品が読めることに少し感動しました。はてなブログチームに所属している同期にも良いサイトだね、GigaViewer最高だね、と言われて結構嬉しかったのを覚えています。技術的に面白いことをやっているみたいなのも大事ですが、自分の好きなコンテンツに関われたり、別のチームの方に褒められると良いですね。もっと他のチームや他の会社のサービスを褒めていきたいと改めて思いました。
GigaViewerについての解説記事を社内向けに書いた
マガポケの対応を終え、次のタスクを進めている間に時間を見つけて社内向けに「GigaViewerとは実際なんなのか」という記事を書きました。これは特に誰かに書いてくれと頼まれたわけではなく、単純に社内の他のチームの人が実はマンガチームが何をやっているのかわかっていないのではないか？GigaViewerにどういう機能があるのかわかっていないのではないか？ということが気になり自発的に書きました。実際今書いてるこの記事も、「はてながGigaViewerというマンガビューワを開発していることを知っている人がまだ社外だと少ないのではないか？」と思ってそういうモチベーションで書いています。
自分がその時書いた内容をまとめると、
- GigaViewerは2018年1月時点では少年ジャンプ+、となりのヤングジャンプ、マガポケで採用されている
- マンガビューワという名前だけど、ビューワページのみがGigaViewerではなく、運用側が利用する管理画面や、連載一覧画面など全部まとめてGigaViewerです
- 汎用的な機能をどんどん増やしており、横展開しやすくするにはどうすると良いかなど設計も考えて開発進めています
- 次に対応予定のコミックDAYSはどのような機能が増え、どのように難しいのか
などなど。
この記事はわりと沢山の社員に読まれ、昼休みなどに「あれいい記事だった、GigaViewerのことあまりわかっていなかったみたい」と違う職種の方などにもコメントをもらいとても嬉しかったです。同じ会社に所属していても、チームが別だといくらチェックしていてもわからないことは沢山あると思うのでこういう活動は大事なんじゃないかなと僕は思います。はてなだと定期的に開催されるTGIFで「ホットなタスクを手がけたで賞」というのがあり、そこでそれぞれのチームのホットなタスクを投稿して投票するというのをやっていてそれも似たような意図があると思いますが、さすがにプロダクトの具体的な説明までそこで一気にやる感じでもないかなと思って社内日記に書きました。
GigaViewer採用4例目「コミックDAYS」
マガポケの際は一応僕がリードエンジニアという感じで進めていましたが、コミックDAYSは僕はサポートする側という感じでした。
コミックDAYSの際はタスクが結構多くて、上記のプレスリリースを確認するとわかりますが、「GigaViewerの特徴一覧」のリストがかなり増えています。GigaViewerの機能として新しく色々と実装をしていったという感じです。また、はてな側だけで実装を進めれるものばかりではなく、スマホアプリに関してはグッドパッチさんが担当されているので、グッドパッチさんとの会話もしつつ進める形となります。
さて、僕は今回はリードエンジニアではなくサポートする側と言いましたが、コミックDAYSの対応でもかなり成長できた面があると思います。1から実装するものが沢山あり、プレリリースも2月15日と決定している。エンジニア、デザイナーの方もみんなタスクは沢山持っていて、みんな2月までに最高のプロダクトを仕上げることに集中している。この状況下で求められているのは、「スピード感を保ったまま丁寧に仕事をする」でした。丁寧に仕事をすることはこれまでずっと意識はしていて、他職種の方とのコミュニケーションもなるべく丁寧にしようと思っていました。ですが、ある程度急ぎつつかつ丁寧にやるというのは実は今まであまり意識できていなかったような気がします。
もちろん、急いでコードを書くとか、タイピング速度を上げるとかそういうことではないと思います。急いでコード書いてバグを生んでしまうと全くよくないので。どちらかというと、ある機能を実装する際の実装イメージを頭の中で前もって持てるかどうか、過ちは早めに気づいて修正していけるか、自分一人で悩まず困った際は他のエンジニアにすぐに頼れるか、などでしょうか。趣味のコードならまだしも、仕事のコードはある程度スピード感は保っておきたいですね。そういう意識がはじめてしっかりと持てるようになったのがこれくらいのタイミングだと思います。
グッドパッチさんとの会話については始めはテキストコミュニケーションでしたが、途中顔を実際に合わせたり、ビデオ通話をすることによって緊張感がほぐれた気がします。リモートで働く際にも言えますが、やはり人は相手の顔が見えると安心感があるのでしょうか。
GigaViewer採用5例目「くらげバンチ」
コミックDAYSの次にGigaViewerが導入されたのはくらげバンチで、これはリニューアル日がコミックDAYSの3月1日の本リリースから約1ヶ月後の4月6日と決まっていました。マガポケの時と同様にメインエンジニアは僕が担当する形でしたが、今回は周りに甘えるというよりはもっと僕が責任を持って進める形でやりましょうという事で自分の中でも緊張感を結構持っていました。
くらげバンチのサイトデザインに関しては慣れたデザイナーさんがデザインをして、実際のデザインのコーディング（HTMLやLESSを書いていく）の方は最近入社されたデザイナーさんがやる形をとりました。
くらげバンチの際に僕がやったことはマガポケのときと似ていますが、以下の点で違いました。
- 自分がもっと責任を多く持つことを意識し、自分自身のエンジニア面でのタスク以外に、デザインタスクやインフラ面のタスク、またリリース当日の作業などを念入りに確認してなにかしら上手くいかない・間に合わない点が無いか確認
- くらげバンチのリニューアル後のサイトのイメージをもって実装的におかしな点が無いかユーザー視点でも考える
- GigaViewerがこれまで対応してきたサイトの多くが深夜0時更新なのと比較して、くらげバンチは基本毎週金曜の昼更新なので、そこの仕様は大丈夫かどうかなど考えたりもした
- インフラ面では、今回のWebオペレーションエンジニアが以前までと違う人が担当することになったので、今までの横展開との差異や具体的にどういう機能が増えるか、リリース当日にどういう作業があるかなどなるべく丁寧に伝えた
- コーディングを担当されるデザイナーさんのことは入社後から近くに座っていてたまに会話したりしていました。そこで気づいた点としては、デザイン以前のGit操作や開発環境周りでハマっていそう（だけど周りに相談しづらそう）にしていたので、そういうわからなそうなところはなるべく先回りして日記にまとめて共有したり、他にデザイン作業で遅れそうな部分・不安な部分など無いか随時確認したりした
- くらげバンチ以前と以後でどういう機能が増えたのか、どういう経緯で何故こういう仕様になっているのか、などを軽くドキュメントにまとめてレポジトリに入れた（これまでのサイトではやってこなかった）
結果として、特に大きな問題もなく無事4月6日にリニューアルが完了しました。
メインのWebアプリケーションエンジニアとしてくらげバンチの多くのタスクの責任を持った（コードレビューや細かい点で手伝ってもらったりはしています）ので、やっぱりマガポケの時より緊張感は高かったけど、その分全体的に上手くいったのはよかったし、GigaViewerのことがもう少しだけ「自分のプロダクト」という感覚が強まりました。
デザイナーの方に色々なデザイン作業以前のことを教えていて思ったのは、エンジニアが作ったエンジニア向けの導入用のドキュメントは一応あるけど、ちょっとハマった時どうすれば良いかなど（特にデザイナーさん向けに）まとまっていないので理想はそういうのをまとめることかなと。また、相談しづらそうな状態になっていたのであれば改善したいと思いました。他には横展開の際、これは5例目ですが、結構毎回直前まで調整していることが多くて緊張感があるので、その緊張感は減らしたいなと思っています。直前まで最高なものにするため調整したいというのは仕方ないかなと思いますが、直前まで「ほんとうに全部上手くいってるかな？」と不安を持つのはあまりよくなさそう。ということで、「くらげバンチ以前と以後のGigaViewer」みたいなドキュメントは残していますがそれとは別に、「横展開する際にやるタスク」「リリース前に確認するチェックリスト」のようなしっかりしたものをこのあと用意しようかなと思っています。
振り返り
最近は仕事をしていて以前より成長している実感があり、実際に「マンガチームのすてにゃんすごい成長している」と言われる機会も増えてきました。
以前から確かに真面目に仕事をこなしていたつもりでいましたが、あの頃は周りのメンバーに頼りがちだったなと自分でも思います。自分のWeb系の技術に対する知識の少なさとかも関係していると思いますが、いまと比べるとそれほど自分主導でタスクを進めるとかできていなかったような気がします。
振り返ると、マンガチーム内ではコミックDAYSの対応の途中からくらげバンチ辺りでわりと成長した気持ちが強いです。自分もがんばらないといけない、周りの人のこともサポートしていきたい（更に、4月から新卒の方も入ったのでその方にとっても良い先輩になりたい）、など色々な気持ちが強くなっていった気がします。
はてなのマンガチームではこういうプロダクトを作っていて、すてにゃんの場合はこういう仕事をここ半年していましたという紹介でした。これからもこういった記事を書いてできる限りアウトプットしていきたいと思っています。そしてよかったらGigaViewerで漫画を読んでみてください。フィードバックもお待ちしております。
