変化への対応力を養うヒントがここに
「10年プロダクト」の生生流転移り変わりの激しいIT・Web業界において、プロダクトやサービス、そしてエンジニア個人が「生き続ける」のに必要なものは何か。否応なく起こるさまざまな変化への対応力はどう養ったらいいのか。「10年以上続くプロダクト/サービス」が歩んできた歴史から答えを探る
変化への対応力を養うヒントがここに
「10年プロダクト」の生生流転移り変わりの激しいIT・Web業界において、プロダクトやサービス、そしてエンジニア個人が「生き続ける」のに必要なものは何か。否応なく起こるさまざまな変化への対応力はどう養ったらいいのか。「10年以上続くプロダクト/サービス」が歩んできた歴史から答えを探る
インターネットが急速に普及し始めた2001年に創業した株式会社はてな。『はてなブックマーク』や『はてなブログ』をはじめとした、ユーザーがコンテンツを発信できるサービスを多数運営する、言わずと知れたコンテンツプラットフォーマーだ。2021年現在、はてなユーザーの登録者数は約1,121万人に上り、エンジニアユーザーが多いことでも知られる。
今年10周年を迎える個人向けブログサービス『はてなブログ』は、2003年に生まれた『はてなダイアリー』(2019年にはてなブログへ統合)の後継サービスにあたる。すでに人気のブログサービスを持っていた中で、なぜ新たなブログサービスを立ち上げたのか。しかも当時はTwitterをはじめとした短文が主流のSNS流行の真っただ中。長文が前提のブログサービスはやや時代遅れのようにも思える。
そこには、多くのWebシステムがぶつかる「技術的負債」の問題が大きく関係していた。『はてなブログ』の立ち上げを指揮したサービス・システム開発本部長の大西康裕さんに話を伺った。
多くのユーザーに愛されるサービスに成長していましたが、リリースから8年経って技術がものすごく古びてしまっていました。
『はてなダイアリー』はその名の通り、もともと日記サービスとして作ったので、データベースはDATE型のカラムがプライマリーキーで、1日1レコードしか作れない設計でした。それがブログとしても使われるようになり、1日に何記事も書くユーザーに対応する必要が出てきたことから当初と違う方向に改築していった。そのため、設計にだんだん歪みが出てきてしまったんです。
Webサービスあるあるかもしれないですが、最後の方は一つ機能修正するだけでも工数が膨大で、私もエンジニアとしてめちゃくちゃ苦労させられていました。
今は信じられませんが、当時はテストコードも十分になくて、本番リリース後に不具合が出ることもよくありました……。あとは、単純に使っている技術、ミドルウエアやWebサーバーそのものも古くなっていました。
10周年が近づき、このあたりで一度大きくリニューアルしようというプロジェクトが立ち上がったんです。ただ、私としては、リニューアルではなく新しいものを作った方が絶対にいいという強い思いがありました。『はてなダイアリー』は技術的負債が積み重なって、にっちもさっちもいかない状態だったので。
はい。それともう一つ大きな理由がありました。サービスのコンセプトとして、書くことに集中できるシンプルなブログサービスを再設計したかったんです。作る側ではなく使う側、つまりユーザーにとっても『はてなダイアリー』は複雑になり過ぎてしまっていたので、分かりやすいものにしたいなと。そうすることで、インターネットを使いこなしている層だけではなく、もっと多くのユーザーに使ってもらいたいという気持ちもありました。
そうですね。まさに2011年はブログブームが落ちついてSNSの時代でしたが、SNS上の短文はすぐに流れていってしまう。もっとしっかり思いを書き残してもらえる、長文を書けるプラットフォームを作りたかったんです。
「ダイアリーがあるのにどうして?」という疑問は社内でも当然多く出ていたので、今言ったようなことを丁寧に説明しました。「なぜ今これを作るのか」を分かってもらうために、ユーザー向けにベータ版をリリースするかなり前から、社内向けにアルファ版をリリースして、みんなに実際にサービスを使ってもらいました。
開発に関わる者だけでなく、営業や事業開発といったビジネス側のスタッフにも相談に乗ってもらったりしながら、社内をなるべく巻き込もうという作戦で動いていました。
メンテナンス性などを考えて、はてなサービスの中では初めてフルクラウドを選びました。それまでもクラウドを使うことはありましたが、新規サービスをすべてAWSで動かすのは初めて。可用性があがり、長期的には運用コストが下がるだろうという判断でフルクラウドにしました。
「書く機能」に特化したのもこだわりです。シンプルに作って、機能は吟味しながら増やすことにしました。特に編集画面は大事にしていて、閲覧画面からそのまま編集できる機能は『はてなダイアリー』から踏襲しました。ただ、サードパーティCookieに依存した仕様は現代的ではないので、この部分は今後別の仕組みに変えていきます。
リリースした頃からちょうど検索エンジンの評価の指標が変わり、コンテンツの質が重視されるようになって、世の中に長文を書くプラットフォームが受け入れられたと感じます。さらに、コンテンツマーケティングに取り組む企業が増え、CMSとしての使い勝手のよさから、個人ユーザーだけではなく企業からのニーズが高まるようになりました。
そこから新たなビジネス展開も生まれて、2014年に企業のオウンドメディア向けCMS『はてなブログMedia』をリリースしました。
最初は一つのクライアント案件として『はてなブログ』への機能追加のリクエストがあったのがきっかけです。もちろん個別カスタマイズもできたんですが、今後ほかの企業に展開するチャンスが広がると考え、汎用的なシステムを作ることにしました。
そうですね。私は経営判断する意思決定者でもありましたから、初期工数との兼ね合いはかなり葛藤しました。ただ、エンジニアなら誰しも個別カスタマイズはなるべくしたくないと考えるのではないでしょうか。当時私はもうコードは書いていなかったのですが、やっぱり個別の仕組みで設計が複雑になるのは避けたかった。
開発時はビジネスとして成功するか分かりませんでしたが、結果的に多くの企業が導入してくれたので、この時の判断は間違っていなかったなと思います。
キャッチコピー自体は何代目かのものなんですが、“しっかり書き残す”というコンセプト自体はずっと貫いていますね。実は、最初の理念を忘れないために、フッターに最初のキャッチコピー「書き残そう、あなたの人生の物語」も小さく残しているんです。
作った時のコンセプトでずっとやってこられたことは誇りですし、著名人のコンテンツでバズるだけではなく、個人のユーザーが丁寧に書いたものが世に出るプラットフォームになれたらうれしいなと今も思っています。
バランス感覚ではないでしょうか。技術的負債を溜めないことは重要ですが、それだけに腐心してサービスがまったく成長しないのも困る。品質を良くしようと思えば、時間と工数はいくらでも掛けられますが、われわれは工芸品を作っているわけではない。自己満足で技術的な正しさを追い求めるのではなく、その努力がユーザーに届いているか、ユーザーに価値を与えられているかを意識できるかが重要だと思います。
技術的負債を溜めないエンジニアになるという観点では、「自分以外のエンジニアがこのコードを触る」という意識を持ってコードを書くこと。コードは書くのと同じくらい読むのも重要です。はてなではコードレビューを大事にしていますが、日常的に他人のコードを読むと、自分も読まれることを意識したコードを書けるようになると考えているからです。
そうですね。ただ、やはり10年経って古くなってきたところもあるので、データベースやミドルウエアなど少しずつ改善しています。
使っている技術にもよりますが、技術が古びてくるのも以前より早くなっていますよね。サーバーサイドならほったらかしだと2、3年で厳しくなって、5年もしたら作り直したくなるんじゃないでしょうか。フロントエンドのライブラリがモダンではなくなって、新しいものを使いたくなることもあると思います。
今のはてなでは5~10年続くプロダクトなら、開発リソースの20%くらいを技術的負債の返済に使おうという肌感覚でやっています。やっぱり技術的負債をまとめて返すのは非効率ですので。
経営としては、技術的負債の返済には一定の開発リソースが必要ということを理解して、しっかりとそこに投資することが、この先も長生きできるシステムに不可欠であろうと考えています。
あ、でもエラそうなことを言ってきましたが『はてなブログ』がめちゃくちゃ理想的に日々負債を返せているかというと、そう言い切れるわけではないです。正直に言っておかないと、社内のエンジニアからツッコミが入りそうなので一応……(笑)
ただ、負債を放っておくと、どんどん利子がふくらんでいつか破綻してしまうので、大事なのは一人一人の「技術的負債を溜めるのは悪」という強い意志なんだろうと思っています。
取材・文/古屋 江美子 企画・編集/根本愛美
NEW!
NEW!
タグ