1,000万人が熱狂するマンガ雑誌を目指して - はてなが集英社と振り返る「少年ジャンプ+」の10年【後編】

創刊から10周年を迎えた「少年ジャンプ+(以下「ジャンプ+」)」。同サイトが軌道に乗る要因のひとつとなったサービス「ジャンプルーキー!」を開発したのがはてなでした。はてなはその後、ジャンプ+のビューワ開発も担当。「GigaViewer」と名付けられたビューワは現在、24もの媒体に採用されています。

GigaViewerを得てさらに飛躍を遂げた「ジャンプ+」は今後、どこを目指すのか。そのために集英社がはてなに期待することとは何か。「ジャンプ+」編集長・籾山悠太氏(@momiyama2019)と、はてな執行役員・石田樹生(id:jusei)の対談を通して、これからを考えます。聞き手はライターの山田井ユウキさんです。

前編はこちら:前代未聞の挑戦を成功させた戦略とは - はてなが集英社と振り返る「少年ジャンプ+」の10年【前編】 - Hatena Developer Blog

左:株式会社集英社 「少年ジャンプ+」編集長(デジタル担当) 籾山悠太さん / 右:株式会社はてな 執行役員 石田樹生

はてなの組織風土が集英社の思想と共鳴した

――前編では「ジャンプルーキー!」の投稿システムの開発をはてなが担うことになった経緯についてお聞きしました。「ジャンプルーキー!」の開発において、特に意識したのはどんな点でしょうか。

石田:「ジャンプ」のブランドで開発するというまたとない機会を得たわけですから、安易なものを作るわけにはいきません。投稿システム自体はドワンゴ時代に開発していた経験が生かせますが、それをどうすればマンガ家さんにとって使いやすいものにできるのか。ユーザーであるマンガ家さんへのインタビューなどを行い、「普段どんな感じでコンビニで作品をスキャンしてるんですか?」みたいな細かいところから徹底的にリサーチしました。

籾山:はてなさんにお願いしてよかったと思うのは、常にクリエイター目線であることです。実は「ジャンプ+」を始める前後、いろいろな会社からご提案をいただいていたんです。ただ、その多くは「もっとこうしたら売上が上がりますよ」とか「こうすればユーザーが増えていきますよ」といったものでした。

もちろん、売上もユーザー数も大事です。ですが、僕が「ジャンプ+」や「ジャンプルーキー!」で目指したのは、「新しい才能がたくさん集まって、ヒットマンガが生まれる場所」だったんです。それには単純な数字だけでなく、マンガ家さんも含めたユーザーにとって使いやすいサービスであることが重要です。当時、はてなで開発をご担当されていた二宮さん(id:nmy 参考:はてな卒業生訪問企画)は、その点をしっかり理解した上で面白いアイデアを出してくれました。結果論ではありますが、はてなさんとはそうした考え方やカルチャーが合っていたのだと思います。

石田:ありがとうございます。たしかにはてなはそうしたカルチャーを持つ会社だとは思いますが、でも同じような企業もIT業界にはたくさんあると思うんですよね。そうした企業とはてなの違いが何かというと、それは“フラットな目線”を持てるかどうかかもしれません。

というのも、有り体に言えば「ジャンプ」というブランドってお金になりそうじゃないですか(笑)。「ジャンプ」の名前を使ってサービスを始めるとなると、ふつうはユーザーをとにかく集めて売上を上げたいと思うはずなんです。そこを我慢できる会社が少ないから、籾山さんのところには売上やユーザー数を重視する提案が多く来たのでしょう。

一方で、はてなの姿勢はもう少しフラットです。強力なブランドを扱えるとなっても、浮足立ったりはしません。常に「ユーザーにとって最高のサービスを作る」という軸をぶらすことがないんです。

籾山:そうですね。きっと他社さんは、「ジャンプならもっとこうすれば儲かるのに」と歯がゆく思って提案してくれたんだと思います。

たしかに人気マンガをさらに広めて売上を上げることも大事です。ですが、「ジャンプ」がより大切にしているのは、才能の原石である作家さんがどうすればヒットマンガを生み出せるのか、そのゼロイチの部分をサポートすることなんです。はてなさんとは、その想いが一致していました。

石田:ありがとうございます。僕自身、前職時代に籾山さんから「ジャンプ」の思想についてはうかがっていましたし、「ジャンプ」のドキュメンタリー本が好きで読んだこともあったので、そうした方針には共感していました。

また、はてなの開発チームには、「自分たちだけの価値観でサービスを作るのではなく、一緒に組む方々の思想を“インストール”する」という文化があります。僕が“通訳”として入ることで、集英社さんの思想をスムーズにチームに伝えられたのだと思います。

――はてなの技術力はどのような点で生かされましたか。

石田:ふたつあります。まず、アクセスが集中してもサイトが落ちないように安定した基盤を提供していること。もうひとつは、UI/UXとデザイナーのスキルです。サービスに向き合い、ユーザーの使い勝手にこだわっています。ここは、編集部の皆さんではできない領域で、我々IT側の人間が最も力を発揮すべきだからです。

籾山:石田さんがおっしゃったように、マンガを投稿するユーザーのことを本当によく考えていただいています。「ジャンプルーキー!」はもう10年以上サービスを提供していますが、投稿システムの機能やUIなどは当初とそれほど大きく変わっていませんし、変えたほうがいいという話も出てきていません。10年前から完成度が高く、ユーザーの皆さんが満足されているということです。それが本当にすごいと思いますね。

「ジャンプルーキー!」(旧名称「少年ジャンプルーキー」)リリース時のトップページ / はてなプレスリリース(2014年9月22日)より

Webマンガのスタンダードを作り出したGigaViewerの革新

――「ジャンプルーキー!」で開発したビューワ機能の評判がよかったこともあり、2017年には「ジャンプ+」ブラウザ版でも採用されました。また、2024年3月からは「ジャンプ+」アプリ版でも採用されています。どのような経緯で導入に至ったのでしょう。

籾山:「ジャンプルーキー!」は集英社からお願いして、はてなさんに開発していただいたわけですが、それを機にはてなさんでマンガビューワをサービスとして開発するという話を石田さんからお聞きして。「ジャンプ+に入れませんか?」とご提案いただいて、ブラウザ版に導入することにしたんです(参考:2017年1月18日 はてなプレスリリース

その際、石田さんや二宮さんに現状の課題感をいろいろヒアリングしていただいたのですが、そこで出てきたのが「サイト内の回遊」に関する話題だったんです。

――といいますと。

籾山:「ジャンプ+」をはじめ、現在の多くのデジタルマンガサービスは、ページを開くとまずマンガビューワがあり、その下にコメントや各話へのリンクといった関連情報が表示されますよね。

でも、実はこのUIは「ジャンプ+」に採用されたGigaViewerで“発明”されたものなんです。それ以前のマンガビューワは、ただマンガを表示するだけだったんですよ。マンガの概要や関連情報などは別ページにまとまっていて、各話へのリンクをタップすると新しいページでビューワが開くという仕様が一般的でした。

――たしかに言われてみればそうでしたね!

籾山:これだとマンガ本編を開くまでに1タップ分の手間がかかりますし、SNSでのシェアも煩雑になります。マンガの概要ページのURLをシェアする人もいれば、ビューワで開いた各話のURLをシェアする人もいるからです。

また、マンガビューワと同じページに関連情報が表示できないと、読み終わった後に他の作品に飛んでもらいにくくなります。読者にはお目当てのマンガだけでなく、他のマンガも読んでもらいたい。そのために、なるべくサイト内を回遊しやすいビューワにしてほしかったんです。

石田:籾山さんからその課題感をお聞きして、帰り道にid:nmy さんとふたりでブレストしました。今でも覚えているのですが、丸ノ内線で乗り換えて東京駅に歩いていく途中に、id:nmy さんが「YouTubeだ!」と言ったんです。

――YouTubeですか!

石田:YouTubeはビューワと概要、コメント欄がひとつのページにまとまっていますよね。まさに同じ課題をUIで解決しているんです。ということは、YouTubeのようなマンガビューワをつくれば「ジャンプ+」の課題を一気に解決できるのではと考えたのです。

会社に戻って、このアイデアをエンジニアにぶつけてみたところ、「ものすごく大変です」と言われたのですが、それは聞かなかったことにして(笑)。「できない」じゃなくて「大変」と言ったということは、できるってことですから。

籾山:この発明は本当に時代をつくりましたよね。今、GigaViewerってどれくらいの媒体が採用しているんですか?

石田:24媒体(2025年5月時点)ですね。

hatena.co.jp

籾山:業界スタンダードといっても過言ではないですね。それから、「ジャンプルーキー!」と同じくGigaViewerでも安定性はすごく大切にしています。人気マンガの更新日や、衝撃的な展開がSNSで話題になったときなんかは、ものすごくたくさんのトラフィックが来ます。それでもスムーズに読めるかどうかは非常に重要なんです。僕はぜんぜんわかりませんが、たぶんすごく苦労して対応いただいているのかなと感謝しています。

石田:トラフィックについては正直、お金をかければ何とかなる世界ではあります。でも、マンガって読まれてすぐ売上になるわけではないので、コストを抑えられるならそれにこしたことはありませんよね。

実は同じ問題を抱えているのがブログサービスなんです。はてなはブログサービスも運営しているので、その問題を解決するノウハウも持っています。これを「ジャンプ+」にも応用し、マンガが読まれたら広告収入が入る仕組みを実装しました。少ない広告でインフラ費用を回収できるようにできたのは、はてなの技術力があったからこそだと自負しています。ここはまだ他社さんが追随できていない部分だと思いますね。

籾山:広告といえば、「ジャンプルーキー!」では作品の最後に入る広告の収入を100%作者に還元しています。あのアイデアもはてなさんからご提案いただいたものでしたね。

1,000万人が熱狂する媒体を目指して

――「ジャンプ+」が創刊されて10年がたちましたが、紙のマンガ雑誌とデジタルマンガ雑誌で読者層やマンガの読み方に違いはあるでしょうか。

籾山:違いはありますね。「週刊少年ジャンプ」のような紙のマンガ雑誌の場合、多くの読者は一冊とおしていろいろな作品を読んでくれることが多いです。そこから、次のヒット作が生まれていくんです。

一方で「ジャンプ+」のようなWebマンガは、お目当ての作品だけを読んで、他の作品はあまり読まない傾向が強いですね。ただ、SNS等での拡散力はWebマンガのほうが上ですし、世界中に届けやすいというメリットもあります。

加えて、媒体としての大きな違いはページ数の制限の有無です。「週刊少年ジャンプ」はページ数が決まっているので、席の取り合いが起きます。この競争が作品をより面白くしてくれるんです。

「週刊少年ジャンプ」ではアンケートで作品人気を測り、競争を促す仕組みが確立されていますが、「ジャンプ+」ではまだ読者の反応の取り方と競争を促す仕組みが完成しきれていません。そこは今後の課題ですね。

――石田さんは集英社と一緒にサービスを開発する上で意識していることはありますか。

石田:ITサービスにこだわらず、面白い話題であれば積極的にお伝えしてアイデアをご提案することです。逆にいえば、世間的に話題であっても有用でなければ持っていきません。集英社さんには、「はてなが持ってこないということはまだ早いんだな」とか、「持ってきたということは機が熟したんだな」のように思っていただきたいですね。単なる開発会社ではなく、一緒に面白いことをやるパートナーだと思ってもらえたら嬉しいです。

――最後に今後の目標や展望について教えてください。

籾山:「週刊少年ジャンプ」は最盛期で600万部以上発行していました。とある昔のデータによると、だいたいジャンプって回読率が3くらい、つまり1冊を3人で読んでいるんだそうです。ということは、600万人×3で1,800万人。最低でも1,000万人は「週刊少年ジャンプ」を読んでいたことになります。将来は「ジャンプ+」も更新するたびに1,000万人に読まれるような媒体にしたいと考えています。

石田:1,000万人に読まれる媒体を実現するのは技術的にも大変です。というのも、現時点ですでにそれを基盤として支えるインフラ面では限界近くに達しているからです。でも、「ジャンプ+」が1,000万人を目指すなら僕らもチャレンジしていきます!

籾山:ぜひお願いします。現代は娯楽が多様化して、読者も分散しているのですが、個人的にはその流れにあえて逆行してみたいですね。マンガ雑誌が何百万部も売れ、テレビの視聴率が何十%もあり、CDが何百万枚も売れていた時代、日本中の人がひとつの作品に熱狂するような、そんな国民的作品が生まれる場所に「ジャンプ+」がなれたらいいなと思います。

***

現在のWebマンガの盛り上がりを牽引してきた「ジャンプ+」。今後、同サービスはさらなる拡大を目指し、海外展開も視野に入れているといいます。1,000万人が読むマンガサイト・アプリという夢を実現するため、はてなは今後も「ジャンプ+」をサポートし続けます。


▽ 関連書籍のご紹介
www.shueisha.co.jp
戸部田誠(てれびのスキマ @u5u / id:LittleBoy)さんが多くの関係者に徹底取材し、「少年ジャンプ+」の秘密に迫るノンフィクション『王者の挑戦 「少年ジャンプ+」の10年戦記』(集英社)が2025年5月9日に発売されました。集英社 籾山さんはもちろん、はてなの石田 id:juseiも取材に協力させていただき、「ジャンプルーキー!」への開発協力や、「少年ジャンプ+」に「GigaViewer」を提供させていただくことになった経緯などが掲載されています。Hatena Developer Blogの記事とあわせて、ぜひご覧ください。

参考:はてな マンガチームのアウトプット

hatena.co.jp
developer.hatenastaff.com