| @WWW

登山道上のケルン

はてなブックマークがユーザーインタビューをするということで、はてブに対する思いをネットに発露している人達が散見された。

自分はコロナ禍になって気がつくとはてなブックマークばかり見ていてヘビーユーザーになっていた(ブックマークはあまりしてなくて見る専)。会社の人との雑談がなくなり、息抜きしたいときにははてブを見る暮らしをしている。

なのでインタビューに応募してみたのだが、どうも落選してしまったみたいなので、はてブについての考えを書いてみることにする。

はてブのバリュープロポジション

まずはじめに、はてブとは何なのか、どんなメリットがあって使っているのかを整理したい。はてブには以下の三つのバリュープロポジション(価値訴求)があると思う。

  • インターネットで何が話題になっているかがわかる
  • ほかの人がコンテンツにどのような評価をしているか確認できる
  • 見かけた情報をあとで参照するために保存しておける

インターネットで何が話題になっているかがわかる

そこを訪れればいま何がインターネットで話題になっているかがわかる。ニュースサイトに張り付いてくまなく記事を読まなくても、はてブを訪れれば話題になっている情報だけを効率的に摂取することができる。

ほかの人がコンテンツにどのような評価をしているか確認できる

SNS ・掲示板サービス的な側面であり、ほかのユーザーと交流することができる。また、ほかの人のコメントによって大まかなコンテンツの概要を把握することもでき、コンテンツの要約機能も提供している。

見かけた情報をあとで参照するために保存しておける

そのまんまブックマークサービス的側面のことだ。当初オンラインブックマークサービスはこの側面をウリにして始まったと思うが、今日、この部分よりも何が話題になっているかの確認や、他の人のコメントを読みたくて利用している人がほとんどだと思う。

はてブの中の人もその辺は認識済みのようで、はてブのウェブサイトを未ログインで訪れるとサインアップを促すダイアログが表示され、「同じページを読んだ人の感想が集まります」とメッセージが記されている。「ブックマークしておいてあとから確認できます」とか「異なるパソコン間でブックマークを共有できます」みたいなことは言ってない。正しいと思う。

はてブ未ログインダイアログ

プラットフォームとしてのはてブ

プラットフォームとしてはてブをとらえたとき、ユーザーはコンテンツ(ブックマークコメント)の生産者と消費者に二分される。コンテンツの最初のブックマーカーになること、面白いコメントを書いてスターを獲得することをモチベーションとし、公開でブックマークするのが生産者で、消費者は生産者がブックマークしたコンテンツや、生産者によるブックマークコメントを読むことを目的にはてブを訪れる。ブックマークコメントが面白ければはてなスターを送る。はてブのような CGM では生産者と消費者はスパッと二分できなくて、あるときには生産者でありあるときには消費者であるというのが特徴だ。書籍『プラットフォーム革命』ではこの生産者と消費者の価値交換のことを「コア取引」と定義している。

はてブ考(コア取引).svg

はてブというプラットフォームを成長させるためには、プラットフォーム内で価値交換の回数を増やすことが超重要だ。

なお、はてブの外にインターネットを置いてみると、はてブというのはコンテンツ消費プラットフォームという側面が見えてくる。はてブ内の生産者も消費者も、インターネット上に存在する様々なコンテンツを閲覧する立場には変わりがない。

はてブ考(プラットフォーム).svg

はてブに集まっている人は、コメントする人もしない人も、インターネット上の情報をみんなで消費しているのだ。

高い生産者率

少し前、インターネット利用者の行動がだんだん見えなくなってきているということについても記事を書いた。

あとの方になってからインターネットを使い始めた人々にとっては、インターネットとは自分から情報を差し出す場ではなく、情報を摂取する場なのだ。買い物をしたり、動画を見たり、音楽を聞いたりしているだけだ。自分でウェブサイトを持ってブログを作ったりしている我々は、今日のインターネットにおいて決してマジョリティではない。

受動的にインターネットを使うだけの人に、 1990 年代の終わりに我々インターネット老人が感じたのと同じような興奮や感動を与えられるのだろうか。多分、発想を転換しないと難しいだろう。我々が面白がったインターネットと彼らが欲しているインターネットは別のものなのだ。ただ受動的に使っているだけでより便利になり、快適になっていくインターネットをどうやって作っていくかが見えないインターネットの時代のテーマになると思う。

スマートフォン全盛時代になってインターネットを使い始めたユーザーは生産者側に回ることが少なく、ひたすらコンテンツを消費しているだけという話だ。

一方ではてブを見ると、ブックマークにコメントが付いている割合(生産者率)が高い。 2022年6月11日のホットエントリーの記事執筆時点でのコメント率を調べてみると以下のような感じだった。

コメント率

中央値 平均 最大 最小
38.1% 38.4% 76.8% 2.5%

この日のホットエントリーの 1/4 以上が 50% 以上のコメント率となっている。この生産者率は CGM サービスとしては高い方だと思う。

生産者率が高い理由とその影響

生産者率が高いのは以下の背景があると考える。

  1. コメントをしやすい設計になっている
    コメントが 100 文字一回だけで投稿の敷居が低く、また他人のコメントを読むコストも小さい。
  2. 安全地帯からコメントできる
    ブックマークされるコンテンツの著者からは直接言い返されることのない安全地帯からコメントすることができる。
  3. 無名ユーザーでも承認欲求を満たしやすい
    フォロワーの多寡に関係なく内容本意で評価されてスターをもらえるため、承認欲求を満たしやすい。例えば Twitter であればたくさんいいねをもらうためにはフォロワーが沢山いるか、拡散力のある人からフォローされていないといけない。はてブではブックマークされるコンテンツが主なので、今日登録したアカウント(お気に入られがゼロ)でもコメントが面白ければ評価される。

コメントをしやすいことと、反論されにくいこと、承認欲求を満たしやすい特性から、ときにはネガティブなコメントが集まる力学が働いてしまっていると考えられる。

ブックマークされるコンテンツ

ブックマークされるコンテンツの変化

はてブにブックマークされるコンテンツにはここ数年変化があったのではないかと思っている。昔は Photoshop や CSS テクニック、 jQuery プラグインの話のほか、 PHP やセキュリティの話題、シリコンバレーのテック界隈事情、ポール・グレアムやアーロン・シュワルツの翻訳などを見かけることが多かったが、ウェブ開発系の話題は減り、増田とニュースサイトの記事、そして Togetter が目立つようになった。

実際のところどうだろうと思って、 5/13 ~ 6/11 の 30 日間の人気エントリーページに掲載されているコンテンツのドメイン別のブックマーク数を、 2022 年から 2007 年まで遡って調べてみた。

2010 年頃までは個人のブログやウェブサイトでもランキング上位に入れていたが、 2011 年頃からまとめサイト系が勢力を伸ばしてきている様子がうかがえる。ただしまとめサイト系も転載問題や2ちゃんねるの規制強化で情報転載元がなくなりすぐに失速している。

2012 年から 2010 年と 2011 年に勢いがあった Photoshop VIP のサイトが下落し始める。 CSS や Photoshop 、 jQuery プラグイン的なアレだ。 2010 年代前半までは本当によく目にしていた。 2014 年に Photoshop VIP はランク外となる。

2010 年代中盤以降は今日と同じような顔ぶれに変わる。 ITmedia や CNET など老舗のネットニュースメディアや Lifehacker 、 GIGAZINE などの翻訳転載系・暇つぶし系ネットメディアは上位に入りづらくなった。かわりに NHK や新聞社が目立つようになる。かつて新聞社はインターネットにちゃんと取り組んでなくて、サイトにニュースはほとんどなく、ニュースはポータルサイトで読むみたいな時代が続いていた。スマートフォン全盛時代を迎えて一般ユーザーがインターネットに増えてきたので、それにあわせてマスコミも考えを変えてきたのだと思う。

なお一位と二位はここ数年はてな匿名ダイアリーと Togetter が確保している。この点については後ほど詳しく述べる。

下がるブックマークされるコンテンツの多様性

総ブックマーク数と総コンテンツ数を見るとこうなっていた。

総ブックマーク数と総コンテンツ数

両者とも右肩上がりで好ましいように見える。 2022 年の総ブックマークが下がっているが、これはタイムラグが存在するためで、この集計後もブックマーク数はじわじわ伸びると思われる。

30 日間でブックマークされるホスト(ドメイン)の数を集計してみるとこうだった。

ホスト数

2014 年頃に 400 ホスト超あったのが 2018 年に 167 ホストまで大きく落ち込み、その後少し回復したが 2017 以前の水準には戻っていない。

なお、 2018 年に総コンテンツ数とホスト数が減っているが、この年の 5 ~ 6 月にはてブはシステムリニューアルをしていたようだ。総コンテンツ数とホスト数が減っているのはその影響だろう。

ブックマーク数が多い上位 10 ホストへのブックマーク数、ブックマークコンテンツ数の集中度合いを調べたものが以下だ。

ブックマークの集中度合い

ブックマーク数もコンテンツ数も年々集中度合いが高まってきている。 2018 年頃に 50% を超えて、いまでは 6 割近くが上位 10 ホストのコンテンツで埋め尽くされている。いつはてブを開いても同じようなサイトの記事ばかり並んでいるなぁと思っていたが、それが印象ではなくデータとして裏付けられた。

また昔の話に戻るが、ホームページを作る人のネタ帳というブログがある。 CSS ネタなどの合間に話題となるような世俗的な記事を挟み、かつては 1000 ブックマーク以上つくような記事を量産していた。最近、ホットエントリーに入っていないなと思ってる方も多いのじゃないかと思う。もうなくなったのかなと思ってサイトを見に行ってみたところまだ存在していて、かつてほどではないにせよいまも記事が投稿されていた。しかしこのサイトの最近のブックマーク数は 100 にも到達していない。一桁のものも目立つ。とはいえ 1000 ブックマーク付いていた頃と比べて内容が変わったようには思えない。

ホームページを作る人のネタ帳の人気エントリー ホームページを作る人のネタ帳の最近のエントリー
ホームページを作る人のネタ帳はかつては 1000 以上ブックマークされる記事を量産していた(画像一枚目)が、最近の記事は少ししかブックマークされていない(画像二枚目)

はてブのユーザー層が変わったから? それだけではないと思う。ブックマークされるコンテンツの集中度合いが高まることによる影響だと考える。

はてブではホットエントリーに入ることでブーストされてさらにブックマーク数が伸びるという現象がある。昔は個人サイト・ブログでもホットエントリー入りが容易だったが、今日ではマスコミのニュース記事がブックマークされるコンテンツとして大勢を占めるようなり、個人サイトがホットエントリー入りしづらくなってきている。ホットエントリー入りしなければ以前と同じようなコンテンツでもブックマーク数が伸びづらくなってくる。

伝統的な経済学は有限な資源をどう配分するかを問題としてきた。資源とは天然資源のことだけではなく、商品一般とかお金のことを指すこともある。しかしインターネットの世界では限界費用がゼロなので、コンテンツ自体は無限に複製できる。有限なのは人間の時間の方だ。なのでユーザーの時間をどのように効率的に配分していくかが重要になってくる。その貴重なユーザーの時間の争奪戦に個人サイトが参入しづらくなってきている。

ユーザー層の変化

ブックマークされるコンテンツが変わったということは、ユーザー層も変わってきているのではないかと考えられる。

上述の通りホットエントリーの総合でウェブデザインや HTML 系の話題を見かけることはなくなった。かつて目立っていたソフトウェアエンジニアやデザイナーの割合は減ってきていると思われる。かわりにオフィス勤務の事務職やフリーランスの非 IT 技術者が増えている印象がある。妄想ユーザー像は以下だ。

高学歴理系男性で IT リテラシーが高く、パソコンを使う仕事をしていて仕事中に自由にインターネットを使える人が多そうだ。

思想的な特徴はリベラル寄り(立憲民主党支持)だ。ただ、ロシアのウクライナ侵攻や立憲民主党の党首交代でちょっと雰囲気が変わった気もする。

資産運用やマンション購入などの記事が定期的に話題になるのでそこそこ経済的にゆとりがある人が多そうだ。ただしめちゃくちゃリッチな人は少ない印象。関東や東海、近畿の大都市で中の上くらいの暮らしをしていて実家は朝日新聞を購読してる、みたいな感じの人が多そうだ。

はてブに寄生するウェブサイト・サービス

Togetter の脅威

2021年どこのサイトが最もはてブのホットエントリに入ったかという記事があって、ここ 3 年のブックマークされたコンテンツ数をドメインごとに集計すると、一位がはてな匿名ダイアリー(増田)で二位が Togetter のようだ。段々増田と Togetter の差が縮まり、2021年は肉薄している。

増田 Togetter
2019 14.2% 13.3%
2020 13.3% 11.3%
2021 12.4% 12.1%

先ほどの表でもここ数年、一位と二位は増田と Togetter だったが、今年は Togetter に逆転されて匿名ダイアリーが二位になってしまった。

Togetter ははてなのエコシステムにとって脅威だ。折角はてブが集めたアテンションを奪っている。個人的に最も問題だと感じるのが Togetter に表示されるエログロマンガや豊胸、手のシミ除去、精力剤、毛生え薬、歯の黄ばみ除去、鼻の毛穴につまった脂除去などのグロテスクで低俗な広告で、はてブを見ていると必然的に Togetter も見ることになり、 Togetter の悪趣味な広告がはてブの UX も悪化させている。一時に比べれば減ったが、5ちゃんねる系のまとめサイトや Twitter まとめブログのようなものは今日も生き残っていて、はてブ経由で獲得したユーザーに対して低俗な広告を表示している。 Togetter とあわせてはてブに寄生する厄介な寄生虫のようなものだと思う。

はてブからまとめサイトなどを除外したホットエントリー一覧ページを作って公開しているサイトなんてのもある。自分のブログへのリファラーとして残っているだけでも以下だ。俗悪コンテンツを削除した上で独自の広告を入れているものもある。

Togetter やこれらのはてブのデータを加工したサイトは、はてブから獲得したアテンションやはてブのコンテンツを無料で利用し、お金(広告収益)に換えている。

はてブの競合

はてブの価値訴求が「インターネットで何が話題になっているかがわかる」と、「ほかの人がコンテンツにどのような評価をしているか確認できる」、「見かけた情報をあとで参照するために保存しておける」であることは最初に述べた。競合に関してはそれぞれの価値ごとにリストアップできる。

「インターネットで何が話題になっているかがわかる」サービスとしての競合

  • Twitter

Twitter の Explorer ははてブにとって驚異だと思う。まだいまはローカライズやパーソナライズが甘い(話題が広すぎる)気がするが、もっとニッチな情報や属性に応じた情報の出し分けが進めばいまはてブを見る専で使っている層にも響くかもしれない。現実問題、一般のインターネットユーザーやテレビ局の人達は Twitter の Explorer 経由でインターネットの動きを把握してそうだ。

「ほかの人がコンテンツにどのような評価をしているか確認できる」サービスとしての競合

  • NewsPicks
    • ニュースに対する識者のコメントを読める
  • Yahoo! ニュース
    • 有象無象のコメントを読める
  • Twitter
    • いろんなユーザーのコメントを読めるがあまりまとまっていない
  • 5ちゃんねる?
    • まともな人はもう使ってなさげ

ニュース記事に他の人がどんな評価をしているか、ニュースの背景に何があるのかを知りたくてはてブを見ることが多い。はてなユーザーのなかにはその分野の識者のような人がいて、ニュースの背景にある事実を解説してくれてたりする。

その識者のコメントを読める部分を強化しているのが NewsPicks だと思う。ちょいと前に以下のような記事を書いた。

人間は見たものをどう評価・解釈するかを他の人と共有したい欲求がありそうだ。また、他の人がどう思っているかを知りたい、それを見てからコンテンツを消費するか決めたいというコンテンツ消費の二軍みたいな人たちもいる。コンテンツが無数に溢れているから、あまり面白くないコンテンツで時間を無駄にしたくないという心理が働くのだろう。

人々は情報を摂取するときに、みんなで情報を咀嚼したいという欲求があるように思う。ラピュタの放送があるときに Twitter で「バルス」と言ったり。みんなでコンテンツを消費する方が楽しいのだ。

また数多くあるコンテンツの中からどれを消費すれば良いかわからない、というのもある。自分が信頼するあの人(はてブのお気に入りユーザー、 NewsPicks の著名人)がコメントしているものを読みたい、という欲求もあるだろう。

はてブはこのような仕組みを作ったパイオニアだとは思うが、 NewsPicks はもっと洗練したやり方でこの手法をコピーしていると思う。

はてブと NewsPicks の比較.svg

はてブにはかつてははてなダイアリー、いまははてなブログや匿名ダイアリーなどがあってブックマークしたくなるコンテンツがあり、そこにブックマークコメントが集まってみんなでコンテンツを消費する循環ができていた。

NewsPicks がその仕組みを真似たのかどうかは知らないが、一般のニュースや識者によるコンテンツと企業経営者などを集めてきてコメントしてもらい、一般のユーザーを集めている。

「見かけた情報をあとで参照するために保存しておける」サービスとしての競合

  • Pocket
  • Instapaper
  • ブラウザーのネイティブブックマーク
    • Safari や Chrome にはリーディングリスト(あとで読む)機能がある

最近はブラウザーにリーディングリスト機能が実装され、クロスデバイスでブックマークを同期するようになってきているのでオンラインブックマークの役割は薄れつつある。またブラウザーのブックマークと違い、オンラインブックマークを繰り返し見ることはないはず。ショートカット的な利用はブラウザー内のブックマークの方が便利だ。

はてブはニュースサービス、コメントサービス(ほかの人の感想・要約確認サービス)としての側面を強化していくのが良いと思う。ブックマーク機能ではブラウザーのネイティブブックマークに勝てないと思う。

はてブのマネタイズ

はてブの課題は、折角集めたアテンションを Togetter などの寄生するサービスに奪われてマネタイズの機会を逃していることだ思う。ユーザーは俗悪・低劣な低俗広告を見せられ、儲かるのは寄生サービスだけだ。はてなもユーザーも損をしている。折角はてブで獲得したアテンションを外部の人達にマネタイズされないようにしないともったいない。

UA で外部サイトからブロックされてしまう危険も伴うが、有料プランを作って有料プラン加入者には AdBlock サービスを提供したり、 Reader モードでの閲覧を可能にすると良いだろう1。 Twitter Blue のようなサービスだ。 Togetter などに表示される手のシミ、インプラント、増毛、豊胸、エログロマンガなどの低俗広告を見なくて済むようになるのであれば自分は加入したい。

はてブの中でもっとも価値があると思われるホットエントリーの情報をぶっこ抜いて自サイトの広告に置き換えて流用するサイト、サービスも問題だ。 Twitter が外部クライアントの API 利用を制限してきたことは問題視されてきた。一インターネットユーザーとしては Tweetbot など好きな Twitter クライアントで Twitter を利用したいが、 Twitter 自体のマネタイズを考慮すると、(広告を入れるために)あのような API 利用制限は仕方がなかったと思う。はてブでも何らかの近しいことをして、ホットエントリーなどの貴重な情報を簡単に他者が利用できるような状況は是正しなければならないと思う。もし使いたい第三者がいるならば、登録制にしてきちんと対価を得るべきだ。

いまはもうなくなってしまったはてブの有料プラン、はてなブックマークプラスの機能を見ると、想定するターゲットユーザーがはてブのアクティブなユーザー(プラットフォームの生産者的な側面が強い人達)を対象にしていたように思う。例えばタグの一括編集とか。そんなのにお金を払いたい人は多くはないだろう。

Autify CEO の近澤さんのブログに書かれているみたいに、顧客の Burning needs をつかみに行くことが大切だ。

はてブの大多数の物静かなユーザーは何を求めているのだろうか。

はてブの未来

この記事を書いていてはてブを作った伊藤直也さんのブログ(元ははてなダイアリー)を読んだ。

直也さんは HBFav を作ったときの記事(「はてブよりソーシャルゲームじゃなかったのかセニョール」)で、今後人々は知っている人経由でニュースを読むようになるというマーク・ザッカーバーグの発言を引用している。

また以下の記事で、他人との関係性がコンテンツ価値に影響を与える( t_wada さんの食に関するツイートは無価値的な話)とも書いている。

これまでは確かにそうだったかもしれないが、今後は違うのではないかと思っている。上の方で述べたブックマークされるコンテンツの集中度合いが高まってきていることからも明らかだが、より普通の人がインターネットに増えてきていることが関係している。普通の人は SNS で気が合いそうな人を見つけてフォローしたりしない。 Instagram で誰かフォローするにしてもセレブや有名人ばかりという人は多いんじゃないだろうか。

ソーシャルなつながりによって閲覧するコンテンツを探したいと思っているのは我々インターネット老人だけなのではないかと思う。デジタルの世の中では時間が最も希少価値が高いものだと書いた。そういう時代にあって人々が求めるのは外さないコンテンツだろうと思う。ど定番の巨人・大鵬・卵焼き的なコンテンツか、その人の趣味嗜好を反映し高度にパーソナライズされたコンテンツだろう。

その上で、これからのはてブが提供できる価値は他者と共同でコンテンツを消費する部分にあるのではないかと思っている。

  • みんなと一緒に一つのコンテンツを消費することで理解を深める
  • より深くコンテンツを楽しめる
  • ソーシャルリーディング

跋文

最後に、今回のユーザーインタビューの募り方に関しては疑問がある。公式ブログでインタビュー候補者を募るとはてブ愛が強い層が応募してきてインタビュー結果に偏りが出ると思う。

日頃のはてなブックマーク開発ブログの文面からも、はてブ開発チームの皆さんが既存ユーザーを大切にしていることが伝わってくる。もちろん既存ユーザーを大切にすることは大事なのだが、はてブはインターネットが大好きなインターネットおじさんをターゲットにしているだけでは伸び代が限られると思う。

スマートフォンが普及してからインターネットを使うようになった層ははてブを通り越して NewsPicks やスマートニュースなんかを使っていそうだ。そういうライトユーザーをどう引き寄せるかがはてブの今後の成長の鍵になると思う。インターネット老人はいずれ死ぬし数も限られている。

難しいかもしれないが、はてブに登録してすぐ使わなくなった離脱ユーザーとか、そういうおとなしいユーザーを見つけてきてインタビューする方が有益なインサイトが得られると思う。少なくともインタビュー相手は応募してくるのを待つのではなく、利用状況を分析してはてブ側が話を聞きたい相手をリクルーティングしていくやり方の方がよいと思う(もし見えないところでそういうことをされてたらすみません 🙇🏻‍♂️ )。

インターネットはこのまま放っておくと我々インターネット老人がインターネットを始めた 1990 年代末期とは異なる世界になっていくと思う。自分には進化しているようで退化しているように感じられる。そのうち別に記事を書こうと思っているが、 RSS が使われなくなったかわりにメールマガジン(ニュースレター)が流行るとか、トラックバックがなくなって、誰かのブログに言及してブログを書いたときには SNS で知らせる必要があるとか、文章で読めば 1, 2 分で済む内容がわざわざ動画化されていて 10 分強じっと動画を見なければならないとか、昔のインターネットの方が進んでいた、というような状況はいくつかある。我々が失ったウェブ的な話だ。

はてブとはてなにはインターネットの先進性をキープしつつも、 2020 年代の人々のニーズにマッチする機能を提供していって欲しい


  1. ただしはてな自体が広告モデルのビジネスをやっているので蛸が自分の足を食べるみたいな状況になってしまう懸念はある 

| @技術/プログラミング

ブログ過去記事の閲覧 UI にはこだわりがある。これまで何度か記事を書いた。

このブログの維持管理で一番時間を割いているのが Archives ページだ。しかしアクセスログを見ると自分以外はほとんど利用していない。完全に自己満なのだが、過去の自分を振り返ることができてとても自分には有意義なページだ。

過去記事を振り返るときには検索をしたくなる。タイトルのみであればページ内検索で探せるが、やっぱり本文込みで検索したい。 Lokka の検索はあるが、検索結果ページは 7 件ずつ(この値はカスタマイズできる)表示で全文表示される。自分は検索キーワードに関する記事が存在するか知りたい訳ではない。著者なのでキーワードに関連する記事があるかないかくらいわかってる。じゃなくて過去の自分がいつ頃どの密度でそのトピックについて書いていたかを知りたいのだ。

タグやカテゴリーで絞り込む手もある。しかしカテゴリーやタグは理想的な分類ではない。二つのカテゴリーを横断するような記事があるし、タグは設定し忘れていることが多い。全文検索が一番頼りになる。

SQL で全文検索的なことをやろうとするとパフォーマンスが良くないだろう。やっぱり全文検索システムが欲しい。

Tantivy と Tantiny

とはいえ、個人のブログで全文検索エンジンを導入するのはしんどい。確かに Apache Solr や Elasticsearch を個人ブログに入れるのはきつい。もっと手軽に使えるものはないか探していて、 Rust 製の全文検索システム Tantivy と、その Ruby クライアントの Tantiny を発見した。

これがめっちゃ簡単で昨日数時間サンデープログラミングをして導入できた。システム環境に適合するビルド済みのバイナリが GitHub にあれば Rust 環境のセットアップすら必要ない。 Gemfile に gem 'tantiny' と書いて bundle install するだけで使えてしまう。

うまくいかなかったもの

最初、同じ Rust 製で Wasm までセットで提供してくれる tinysearch を試した。 JSON 形式で全ファイルを書き出すだけで使えるやつだ。しかし残念なことに日本語では全く使えなかった。自然言語処理をやろうとしていてあるあるのパターンだ。日本語は MeCab などでトークナイズしてやる必要がある。

デフォルトのトークナイザーでもそこそこに優秀な Tantivy

Tantivy にもトークナイザーをカスタマイズできる仕組みはあるが、標準の Simple Tokenizer でもそこそこ精度が高い。固有名詞にちょっと弱いが、辞書ファイルがないので仕方ないだろう。

個人ブログでも全文検索できる時代

このブログは個人ブログだが、画像のリアルタイムリサイズサーバーを動かしている(おかげで S3 の転送量が安くて済んでいる)し、 TF-IDF で関連の高い記事も表示している。それに加えて全文検索まで入れてしまった。こういうのは大手のブログサービスを利用しないと使えない機能だったが、 OSS と新しいプログラミング言語( Go や Rust )のおかげで個人でもそこそこのスペックのサーバーでこれらを利用することができるようになってきた。 MovableType でサイトを構築していた時代から何も進歩していないようで実はとても進歩している。こういう文化の灯火が消えないようにしていきたい。

| @登山/ランニング

上高地

今年の夏、もし気力・体力・精神力・財力が整えば北アルプスに登山に行ってみたいと思っている。

ただネックになるのが交通手段で、東名阪からだと数千円握りしめて家を出てバスに乗って寝ると目が覚めたら上高地みたいな感じだが、福岡からだとそういうわけにはいかない。どういうルートで行くと時間を無駄にせず、お金もかからずに済むかを考えてみた。


TL;DR

  • お金がなくても飛行機で松本入りがおすすめ
  • 下山日に福岡まで帰るのは難しく、要後泊で最低でも山行日程 + 一泊必要

基本的な行き方

上高地バスターミナル

上高地に着くのを何時にするかが問題で、夜行バスで上高地に入るか、中継地までの移動を夜行バスにして午後から上高地に入るか、そもそも飛行機で松本まで直行するか(上高地入りは同様に午後となる)が分岐点となる。

夜行バスで上高地に入れば早朝から活動可能となり、登山初日に移動距離を稼げる。飛行機で松本入りしたり、中継地点までの移動に夜行バスを使ったりすると上高地入りが午後になり、初日は少ししか歩けない(標高が高い山では遅い時間まで歩くのは危ない)。

まとめるとこんな感じだ。以下の三つから選ぶことになる。

  • 午前入りプラン
    新幹線か飛行機で中継地点まで移動し、夜行バスで上高地入り
  • 午後入りプラン A
    飛行機で松本までアクセスし、電車とバスで上高地入り
  • 午後入りプラン B
    夜行バスで中継地点まで移動し、昼行バスで上高地入り

旅程

飛行機から見る槍ヶ岳・穂高連峰

奥穂高岳へ涸沢経由で往復する場合、旅程は以下となる。

日程 午前入りプラン 午後入りプラン A 午後入りプラン B
一日目 午後から移動開始 朝から上高地まで移動、午後上高地着、徳沢か横尾に宿泊 午後から夜行バスで中継地点まで移動
二日目 夜行バスで早朝上高地着、涸沢宿泊 徳沢 OR 横尾から登山開始、奥穂高岳登頂、穂高岳山荘泊 朝から上高地まで移動、午後上高地着、徳沢か横尾に宿泊
三日目 涸沢から奥穂高岳登頂、再び涸沢宿泊 穂高岳山荘から一日で上高地まで下山、上高地か松本市内泊 1 徳沢 OR 横尾から登山開始、奥穂高岳登頂、穂高岳山荘泊
四日目 涸沢から上高地まで下山し、上高地 OR 松本市内宿泊 2 上高地 OR 松本市内から帰宅 穂高岳山荘から一日で上高地まで下山、上高地か松本市内泊 1
五日目 上高地 OR 松本市内から帰宅 - 上高地 OR 松本市内から帰宅

どのプランであっても下山日の福岡への帰宅はかなり厳しい。上高地から出るバスに夜行便はなく、 15:30 頃までのバスに乗らないと大阪にも名古屋にもたどり着けない。名古屋・大阪に 21:00 ~ 22:30 頃に着いてもすでに福岡まで帰れる新幹線はなく、頑張れば夜行バスで帰ることはできるが、三日間北アルプスを歩いて疲れている状態でさらに夜行バスに乗れる体力は自分にはない。というわけで飛行機で直接松本入りする午後入りプラン A 以外は移動と後泊で 5 日間必要になってしまう。

それぞれのプランの移動経済性

午前入りプランは経由地をどこにするかでさらに三つに分類できる。大阪まで新幹線で行くパターン、名古屋まで新幹線で行くパターン、名古屋まで飛行機で行くパターンだ。午後入りプラン A 、 B とあわせて、上高地着時間と移動時間、片道交通費を一覧表にするとこうなる。

プラン 経由地 交通手段 上高地着 所要移動時間 片道交通費 移動経済性
午前入りプラン 大阪(新大阪) 新幹線→夜行バス 5:30 11時間 ¥27110 29.8
午前入りプラン 名古屋(名古屋駅) 新幹線→夜行バス 5:30 12時間 30分 ¥26140 32.7
午前入りプラン 名古屋(セントレア) 飛行機→夜行バス 5:30 12時間 30分 ¥17120 21.4
午後入りプラン A 松本 飛行機→電車・バス 12:36 6時間 ¥22500 13.5
午後入りプラン B 大阪(梅田) 夜行バス→昼行バス 13:45 17時間 30分 ¥13910 24.3

表中右端の 移動経済性 は、交通費 × 所要移動時間 ÷ 10000 という式で出している。交通費と所要時間を掛け合わせることで大体のコストパフォーマンスがわかる(移動時間も交通費も小さければ小さいほどよい)。数字がでかくなりすぎるのでテキトーに 10000 で割っている。この数値が小さいほどお得(効率的な移動手段)となる。

飛行機で松本入りする午後入りプラン A が一番交通費が高くなりそうな気がしていたが、実は新幹線移動の大阪経由プランが一番高い(その割に結構移動時間は長い)。大阪・名古屋からの夜行バスが意外と高い。一方で飛行機は早割チケットの購入や、セントレアを経由する場合は LCC を使うなどで安くできるので意外と高くならない。

最も移動経済性が良いのは松本経由の午後入りプラン A で、 13.5 となっている。新幹線を使う午前入りプランは 29.8 と 32.7 で移動経済性が著しく悪い。金額的には最安の午後入りプラン B についても移動経済性 24.3 でセントレアを経由するプランよりもお得ではない。移動時間が 17 時間以上もかかるとなるとどれだけお金を節約できても時間のロスがもったいない。

名古屋(セントレア)経由のプランは移動時間と交通費のバランスが取れていそうだが、セントレアから名古屋駅まで移動して夜行バスに乗るという手間をかけても、松本に直行する場合と比べて 5000 円しか節約できないのが痛い。往復なら 10000 円の節約になるかもと思うかも知れないが、復路は上高地から出る夜行バスがないためこのプランは名古屋宿泊が必要になり、往復で大幅に節約できるわけではない。

それぞれのプランごとのメリット・デメリットと向いている人を書き出してみた。

午前入りプラン 大阪経由(新幹線)

メリット

  • 早朝に上高地着
  • 天気が悪くなりそうなときには柔軟に日程を調整出来る
    悪天候時の変更・キャンセル費用が安い
  • ガス缶・アルコール燃料などを持ち運べる

デメリット

  • 時間がかかる割に交通費が高い

向いている人

  • 仕事が忙しくいつまとまった休みを取れるかわからない人
  • 優柔不断で直前まで予定を決められない人
  • 北アルプスに行くからには好天に合わせて行きたい人
  • お金に余裕がある人
  • 大阪が好きな人

午前入りプラン 名古屋経由(新幹線)

メリット

  • 早朝に上高地着
  • 天気が悪くなりそうなときには柔軟に日程を調整出来る
    悪天候時の変更・キャンセル費用が安い
  • ガス缶・アルコール燃料などを持ち運べる

デメリット

  • 時間がかかる割に交通費が高い

向いている人

  • 仕事が忙しくいつまとまった休みを取れるかわからない人
  • 優柔不断で直前まで予定を決められない人
  • 北アルプスに行くからには好天に合わせて行きたい人
  • お金に余裕がある人
  • 新幹線が大好きで一秒でも長く乗っていたい人
  • 名古屋が好きな人

午前入りプラン 名古屋経由(飛行機)

メリット

  • 早朝に上高地着
  • LCC を使えば飛行機代が格安
  • マイルを貯めている人は特典航空券を使って飛行機代を 0 円にすることができる
  • ガス缶などを名古屋ヨドバシで調達可

デメリット

  • 悪天候時の変更・キャンセル費用が高い
  • セントレアから名鉄BCへの移動・待ち時間

向いている人

  • 多少の悪天でも山行を結構する覚悟・技術がある人
  • 悪天候のときは割り切って上高地・松本観光に切り替えられる人
  • キャンセル料・変更費用が苦にならない人
  • マイルを貯めている人
  • 名古屋が好きな人

午後入りプラン A 松本経由(飛行機)

メリット

  • 最速
  • 前日からの移動不要
    初日に上高地入りできるため、他の行程より旅程を一日節約できる
  • 移動の疲労が少ない

デメリット

  • 悪天候時の変更・キャンセル費用が高い
  • 上高地着が午後になり、登山開始日に稼げる距離が短い
  • ガス缶・アルコール燃料などを持ち運べない

向いている人

  • 多少の悪天でも山行を結構する覚悟・技術がある人
  • 悪天候のときは割り切って上高地・松本観光に切り替えられる人
  • キャンセル料・変更費用が苦にならない人
  • 自由に使える時間が少ない人
  • 夜行バスで寝るのが苦手な人

午後入りプラン B 大阪経由(夜行バス)

メリット

  • 最安
  • 天気が悪くなりそうなときには柔軟に日程を調整出来る
    悪天候時の変更・キャンセル費用が安い
  • ガス缶・アルコール燃料などを持ち運べる

デメリット

  • 移動時間が長く、上高地に着いたときには疲労困憊の可能性
  • 上高地着が午後になり、登山開始日に稼げる距離が短い
  • 福岡→大阪の夜行バスが遅れると上高地便への乗り継ぎに失敗するリスクあり

向いている人

  • 時間に余裕のある学生
  • とにかくお金を節約したい人
  • 体力に自信のある人
  • 夜行バスが好きな人・夜行バスでも快眠できる人

結論

お金と移動時間をバランスよく節約したい → 松本まで飛行機移動プラン

ベストな天候のときに登りたい・予定が直前までわからない → 大阪経由の新幹線・夜行バス乗り継ぎプラン

参照


  1. 下山時刻的に当日中の帰宅は不可能。上高地から出る夜行バスはない。 

  2. 涸沢からかなりハイペースで下山しないと当日中の帰宅は難しい。もう一泊するのが無難。 

| @Mac/iPhone

Dolby Atmos

Apple Music がロスレスやハイレゾ、 Dolby Atmos Spatial Audio に対応した。ロスレスやハイレゾは音質の向上で、 Bluetooth で音楽を聞くことが当たり前となった今日では一部の音質マニアの人にしか影響がないと思う(特にハイレゾは有線接続で USB-DAC などを利用しないとメリットを享受できない)。

一方、 Dolby Atmos の Spatial Audio (空間オーディオ)は 2000 円のイヤフォンで音楽を聞く人から数十万円の高級オーディオセットで音楽を聞く人まで恩恵がある。 Apple Music 内の空間オーディオ解説コンテンツでパーソナリティの人が「革命」と言っているけど決して大げさな言い方ではない思う。音質ではなく音の聞こえ方が変わるからだ。 Apple Music に入っている人は是非イヤフォンで Apple が用意している聞き比べ曲を聞いてみて欲しい。

聞き比べコンテンツは二つあって、一つは Marvin Gaye の "What's Going On" 、もう一つが The Weeknd の "Save Your Tears" だ。個人的には Marvin Gaye 版の方が違いがわかりやすかった。 The Weeknd の曲はシンセサイザーを多用してエフェクトがかけられていて、こういう曲は空間オーディオの効果がわかりづらい。一方で Marvin Gaye の曲は昔ながらの生演奏で、楽器の数も少ないので Dolby Atmos の威力を確認しやすい。最初はモノラルから始まり、次にステレオ、最後に Dolby Atmos となる。ステレオで二方向から聞こえていた音が、 Dolby Atmos では縦方向からも聞こえるような感覚を覚える。楽器ごとに音が細分化される感じ。これまで聞こえなかったギターのフレット移動音や、小さいパーカッションの音がはっきり聞こえるようになる。

Apple Music 空間オーディオの世界

聞き比べコンテンツのほかに「空間オーディオの世界」というプレイリストが用意されており、最近の曲から古い曲までいろんな曲が Dolby Atmos で聞けるようになっている。誰でも一つくらいは聞いたことがある曲が入っていると思うので、ここにある曲を聞いてみると違いが分かりやすいと思う。個人的には Jackson 5 の "I Want You Back" や Iggy Pop の "The Passenger" は違いが分かりやすかった。

なお、 AirPods など Apple 謹製以外のイヤフォンを使う場合は設定で「ドルビーアトモス」を「常にオン」にしておく必要がある。初期値は「自動」で、 AirPods など対応するチップを搭載したイヤフォンでしか Dolby Atmos を適用できない。

「ドルビーアトモス」を「常にオン」

ちなみに、自分の手持ちのデバイスの対応状況を確認したところ以下の通りだった。

デバイス 接続方式 Mac iPhone
AirPods Pro Bluetooth
Bose QuetComfort 35 Bluetooth
有線接続
Bose Sound Link Mini II Bluetooth
有線接続 -
Bose Computer Music Monitor 有線接続 -

Bose の Bluetooth ヘッドフォンでも Dolby Atmos で再生できたが Mac との接続時には動作が非常に不安定で、どうもマルチポイント接続をしているときは Dolby Atmos モードにならないことがあるようだった。有線接続の場合は問題なく Dolby Atmos で再生される。比較的最近の iPhone や Mac であれば本体スピーカーでも Dolby Atmos で再生できるようだ。この辺のことは Apple のサポートページで詳しく説明されている。


どんなに Spotify のレコメンドが素晴らしくても、空間オーディオで音楽を聞きたければ(いまのところは) Apple Music を使わざるを得ない。自分の周囲では Spotify 派の人が圧倒的に多かったが、少なくともこの空間オーディオをきっかけに Apple Music に興味を持つ人が増えたように思う。久々に技術的なイノベーションがバリューイノベーションになる瞬間を見た気がする。

| @労働

夕刻の今津湾

2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。


プロダクトマネージャーになった理由

夕影

ソフトウェアエンジニアだったとき、プロダクトマネージャーが不在のプロジェクトにアサインされたことがあった。機能コンセプトと画面デザインはあったが明確な仕様ドキュメントはなく、未確定の仕様をつまびらかにしつつ、関係者の合意を得ながらコードを書いていく必要があった。エンジニアだった頃の自分は機能的な仕様は誰か他の人に決めてもらって、自分は技術的な仕様を考えてコードを書くことに集中したかった。

このときは正直とてもつらくて、結局機能をリリースすることもできずプロジェクトはぽしゃってしまった。このような経験を自分はもうしたくないし、他の人にもさせてはいけないと思った。ビジネス的に成功するためだけでなく、エンジニアやデザイナーが不幸にならないためにも、きちんと作るものを定義してくれるプロダクトマネージャーが極めて重要だと思った。

その後しばらく時間が経ち、転職した職場でエンジニア・デザイナーが増えるにつれて専任のプロダクトマネージャーが存在しないことによる課題が露呈するようになった。プラットフォーム間での仕様の食い違いや、勘や憶測に基づく機能開発など。このままではプロダクトが間違った方向に進みかねないし、かつての自分のようにデザイナーやエンジニアが苦労をすることになると思った。誰か一人が専任のプロダクトマネージャーとなって交通整理をする必要があるだろうと考え手を挙げた。

プロダクトマネージャーの役割

プロダクトマネージャーの役割や定義については様々あるが、自分は「ユーザーに必要とされる製品を定義し、ビジネス的な成功を達成すること」だと考えている。プロダクトマネジメントについての本を何冊か本を読んだが、その中で最も感銘を受けた『 Making It Right 』という本にはこのように書いてある。

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.17). Smashing Magazine. Kindle 版.

この本を読んだ後に書いた記事ではこの部分を以下のように訳している。

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

プロダクトマネージャーの Job Description - portal shit!

この記事の内容はいささか抽象的ではあったが、いま見てもそんなに違和感はない。記事内で引用した Dan Olsen の図から特に重要な部分を抜き出すと以下だろう。

プロダクトマネージャーの仕事

上図の赤枠で囲われた部分、ユーザーのニーズとプロダクトをマッチングさせ、売れる製品を作ってユーザーの問題を解決すること( Product/Market Fit )がプロダクトマネージャーの役割だ。ユーザーの課題を解決する画期的な製品を作ることが出来たとしても、収益性が悪ければプロダクトマーケットフィットしたとは言えず( Solution/Problem Fit に過ぎない)、プロダクトマネージャーの役割を果たしているとは言えない。

I-shaped people

プロダクトマネージャーにふさわしい人物像として、プロダクトマネージャーは I 型人間であるべきと述べられている。再び同書から引用する。

First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically.

日本語訳: プロダクトマネージャーは雲の上に頭を置いておく必要がある。未来を見越すリーダーであり、戦略的な思考が求められる。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.22-23). Smashing Magazine. Kindle 版.

But good PMs also have their feet on the ground. They pay attention to detail, and they know their products inside out. They are the product’s biggest users — and its biggest fans and critics.

日本語訳: しかし同時に、良いプロダクトマネージャーは地に足を付けていなければならない。良いプロダクトマネージャーは細かいところまで注意を払い、プロダクトの表と裏を知っている。良いプロダクトマネージャーはプロダクトの最大のユーザーである。最大のファンであり、批評家でもある。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.23-24). Smashing Magazine. Kindle 版.

Most importantly, PMs know how to ship. They know how to execute and rally a team to get products and improvements out in the world where the target market can use them and provide feedback.

日本語訳: 最も大事なこととして、プロダクトマネージャーは製品のリリース方法を知っている。開発チームをとりまとめて開発プロジェクトを遂行し、製品を求めフィードバックを与えてくれる外の世界(=対象とする市場)に届ける方法を知っている。

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (p.24). Smashing Magazine. Kindle 版.

雲の上から俯瞰して戦略的にものごとを考えることも出来るし、地に足を付けていてプロダクトの細かいところも把握している。ユーザーの課題を発見するところから始まり、課題を解決する方法をとりまとめて世に送り出し、フィードバックを得るところまでできるのがプロダクトマネージャーにふさわしい人物像ということだろう。

具体的な仕事内容を挙げると以下のような感じではないだろうか。

1. 何がユーザーの問題かを特定する

  • ユーザーインタビューやユーザーアンケートを実施する
  • アクセス解析や利用ログに基づく定量的な分析を行う
  • 競合製品と自社製品の機能比較を行う

2. その問題を解決する製品を定義する

  • 要件定義・仕様書の作成
  • ユーザーストーリーの作成
  • カスタマージャーニーマップの作成

3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる

  • プロダクトロードマップ(リリース計画)の作成
  • プロジェクトの推進(プロジェクトマネジメント)
  • 他部署(セールス、マーケティング、サポート)との調整

4. 製品が「正解」であったかの評価を行う

  • 利用状況の調査やユーザーアンケートを実施し、プロダクトがユーザーの問題を解決したか評価する
  • 1 に戻り、製品を継続的に改善する

実際になってみてのギャップ

本から得た知識をもとに、意を決してプロダクトマネージャーになってみたものの、想定と現実の間には大きなギャップがあり苦しんだ。具体的には、作るべき製品を定義するのがプロダクトマネージャーの仕事だと思っていたがそうではなかった。

エンジニアは作りたいものを作りたいし、プロダクトマネージャーが作るべきものを定義するまでもなく機能は開発されていく状態だった。開発すべきものがわからないのではなく、開発したい機能が多すぎて困っているという状態だった。

自分が思い描いていたのは以下のような役割分担だった。プロダクトマネージャーが必要な機能と要件・機能仕様をまとめ、デザイナーがデザインに落とし込み、エンジニアが機能を実装する。

プロダクトマネージャーが開発プロセスに関与する

しかし実際は以下のような感じで、機能のアイディアを出す企画段階からエンジニアが担当し、プロダクトマネージャーは他のプロジェクトチームや営業、マーケティングチームとの調整が主な役どころだった。製品の仕様に関われるのは既存機能の不具合対応のときくらいで、後は開発チームによって作られたソフトウェアを受け入れるだけの存在だった。

プロダクトマネージャーが開発プロセスに関与しない

エンジニアが機能の企画・要件定義も行う体制では人手が足りず実装に十分な時間を割けないので、企画・要件定義を担当するエンジニアとは別に実装者のエンジニアがアサインされるようになった。企画・要件定義を担当するエンジニアがプロジェクトリーダーとなって実質的なプロダクトの責任者となる。プロダクトマネージャーは外部や経営陣との橋渡しをするだけの調整役になってしまった。

プロジェクトリーダーが実質的なプロダクトマネージャー

上図のプロジェクトリーダーと呼ばれるロールこそが自分の中ではプロダクトマネージャーだという認識だったが、このロールはプロダクトマネージャーのものではなかった。

プロダクトマネジメントの認知度が原因?

なぜ期待と現実のずれが生じたのか。当時の自分は、プロダクトマネジメントというものへの認知が不足しているからだと思っていた。

プロダクトマネージャーという職能が日本で一般的に認識されるようになったのは伊藤直也さんや Higepon さんが Rebuild ポッドキャストで話していた 6 年くらい前からでないかと思う。その後 antipop さん達がプロダクトマネージャーの Slack コミュニティなどを作り、一時期プロダクトマネージャー界隈が盛り上がっていた。

しかし、一般的な日本のソフトウェア企業でその存在が認知されるようになってからはまだ日が浅い。プロダクトマネージャーという役割に対する理解は圧倒的に足りていない。それが自分の役割に苦しんだ最大の原因だと考えた。

本に書かれているプロダクトマネージャーのロールを押し通そうとして軋轢を生んだこともあった。『 Making It Right 』にも以下のように書いてある。

Common objections to the role include:

  • “We have different people in the organization who fulfill each of these functions as part of their roles.”
  • “I don’t see how the role will make us more money.”
  • “Product managers will just slow us down.”
  • “I don’t want to relinquish control of the product to someone else.” (OK, that one is usually thought without being said out loud.)

プロダクトマネージャーという役割に対する反対意見の例:

  • 「うちの会社にはプロダクトマネージャーの役割を部分的に果たす人々がすでに存在してるんだ」
  • 「プロダクトマネージャーとやらが会社を儲からせてくれとは思えないな」
  • 「プロダクトマネージャーって連中は開発チームのスピードを下げるだけの存在だよね」
  • 「プロダクトについての決定権を手放したくないんだよ」(通常、声を大にして言われることはない)

— Merwe, Rian van der. Making It Right: Product Management For A Startup World (pp.19-20). Smashing Magazine. Kindle 版.

プロダクトマネージャーが存在しない組織では、プロダクトマネジメントのロールをデザイナー、エンジニア、カスタマーサポートなど様々なロールの人々が少しずつ分担しながら製品が作られていく。そこに突然プロダクトマネージャーが現れて「それ僕の仕事なんで僕がやりますよ」と言うと反感を買ってしまう。

プロダクトマネージャーの存在が認知される以前から、ソフトウェアの仕様を固めたり、ステークホルダーと調整したりする仕事自体は存在していて、大体はエンジニアの中のリーダーがその役割を受け持っていたのではないだろうか。少なくとも自分がこれまで勤めてきたプロダクトマネージャーのいない職場ではそうだった。ビジネスサイドから提示された大まかなビジネス要件を元にエンジニア(もしくはデザイナー)のリーダーが機能要件をまとめていた。

同じような話が伊藤直也さんのプロダクトマネジメントについてのブログにも書かれてある。

一体型のソフトウェア開発と分業型のソフトウェア開発

なぜこのような慣習が出来たのかを考えると、日本のソフトウェア産業の構造が響いているような気がする。受託開発が中心だった日本のソフトウェア産業1では、ソフトウェア開発はひとまとまりに開発者(ソフトウェアを作る側)の仕事ということになっている。受託開発であったとしても受託者側で作るシステムの要件定義を行うケースがほとんどではないだろうか2

日米受託開発の割合

総務省|平成30年版 情報通信白書|日米のICT投資額の推移

このため作るべきものの定義と作る作業の境界が曖昧なのだと思う(一体型のソフトウェア開発)。一方でシリコンバレーではジョブデスクリプションが明確で役割分けに敏感なので、作るべきものの定義とその結果に責任を持つ人(プロダクトマネージャー)と、作ること自体に責任を持つ人(エンジニア・デザイナー)が明確に区別されているのだろう(分業型のソフトウェア開発)と推察する。

エンジニアとプロダクトマネージャーの職能の分離

したがって、プロダクトマネージャーの役割の認知が広がらない限りはこの問題は解決できないと思うようになっていた。半ば諦めというか、自分では解決できない問題に立ち向かわなければならないようで、とても苦しく悶々とした日々を過ごした。

しかし一方で、プロダクトマネージャーの役割は会社によって異なると良く言われる。『逆説のスタートアップ思考』の馬田さんが書かれている記事には以下のように書いてある。

組織のリソースが豊富な場合はプロダクトの仕様を策定するだけの PM なのかもしれません。スタートアップのようにまったくリソースのない組織の場合は、全部の機能を一人がやらなければいけないのかもしれません。人を採用して少しリソースが増えたら、また PM に求められるバランス感が変わってきます。

組織の今の状況に応じて PM はその役割を変えますし、同じ組織においても時間が過ぎれば役割が変わっていくと認識しておくほうがよいのでしょう。

プロダクトマネジメントトライアングルと各社の PM の職責と JD | by Taka Umada | Medium

当時の自分はこの観点が抜け落ちていた。もっと柔軟に振る舞って、どうすれば良いプロダクトをユーザーに届けられるかという視点に立ち、所与の環境でどういう働きをすべきかが考えられていなかった。

プロダクトマネジメントのない組織にプロダクトマネジメントを浸透させる方法

自分の失敗経験を踏まえ、一人目のプロダクトマネージャーとしてどう動けば良かったのかを振り返ってみる。

まず、プロダクトマネージャーが存在しない初期状態が以下だ。経営陣が戦略を、開発チームが戦術を担当する。

役割の戦略性 - 初期状態

そこにプロダクトマネジメントの仕組みが導入されるとこうなる。プロダクトマネージャーは戦略と戦術の両方を股にかける動きをする。 What の領域に主眼を置きつつも、 Why や How にも関わる。

役割の戦略性 - プロダクトマネジメント導入

自分がプロダクトマネージャーになったとき、会社はプロダクトマネージャーに戦略性の高い領域を守備範囲とすることを期待していた。

役割の戦略性 - 戦略寄りのプロダクトマネジメント

しかしそれに反して自分自身は機能仕様の策定など、戦術的な領域を守備するつもりでいた。

役割の戦略性 - 戦術寄りのプロダクトマネジメント

この認識の違いのせいで会社、開発チームとの軋轢が生じ、仕事のやりづらさや違和感につながったと考える。

本で読んで得ていたプロダクトマネージャー像はどれも中規模以上の、プロダクトマネージャーが何人かいる組織でのものだった。なので一人目のプロダクトマネージャーとしてどう動くべきかという観点での参考資料にはなり得なかったのだろう。その点は自分の反省点だと思う。

一方で、組織が大きくなってプロダクトマネージャーの数が増えると、以下のように役割を分担できるようになる。

役割の戦略性 - プロダクトマネージャーの役割分担

戦略性の強い仕事を上級のプロダクトマネージャーが担当し、戦術領域に関してはジュニアなプロダクトマネージャーが担当すればよい。

少し前に読んだ『プロダクトマネジメント』という本では、以下のような説明がなされていて納得感があった。

 プロダクトマネージャーの戦術的な仕事では、機能を作って世に出すという短期的な行動に焦点を当てます。次にすべきことを決めるのに使うデータを処理したり、日々、開発者やデザイナーと一緒に作業を分解してスコープを決めたりすることも含まれます。

 戦略的な仕事では、マーケットで勝利して目標を達成するためにプロダクトや会社のポジショニングを考えます。プロダクトや会社の将来像や、そこに至るために必要なことに着目します。

 運営の仕事では、戦略を戦術的な仕事に結び付けます。プロダクトマネージャーは、プロダクトの現状と将来像をつなぐロードマップを作り、チームはそれに沿うように仕事を進めます。

— Melissa Perri 『プロダクトマネジメント』オライリー・ジャパン

以下の図もわかりやすい。

プロダクト関連の役割における戦略、運営、戦術の仕事の割合(10人以上のチームの場合)

自分がプロダクトマネージャーの役割だと思っていたのは図中で言う「アソシエイトプロダクトマネージャー」か「プロダクトマネージャー」だったのだと思う。しかし会社は「プロダクト担当ディレクター」か「プロダクト担当 VP 」相当の存在を求めていた。戦術の領域はエンジニア・デザイナーに任せ、プロダクトマネージャーは戦略と運営にフォーカスするような働きが期待されていた。一方で自分は戦術にフォーカスしたプロダクトマネージャー像を持っていたため、組織のニーズにマッチできていなかった。

スタートアップのような小さな組織では常に人手が足りていないので、いくつかのロールを兼任することが求められる。小さな組織でプロダクトマネージャーが一人しかいないときには、戦術はある程度手放してエンジニアとデザイナーに丸投げし(エンジニア・デザイナーにプロダクトマネジメントのロールを兼任してもらう)、プロパーのプロダクトマネージャーは運営と戦略にフォーカスすべきだったのかも知れない。自分はそれができなくて、戦術に拘泥して失敗してしまったのだろう。

ただし、『プロダクトマネジメント』では、経営陣が期待するアウトカムではなく特定の機能( HOW )の実装を開発チームに要求し、一貫した戦略が存在しないためビルドトラップに陥る、ということも書かれている。プロダクトマネジメントの仕組みを整えるには、 CEO をはじめとした経営陣も一定程度戦術(どんな機能を作るか)からは手を引き、プロダクトマネージャーに権限を委譲していく必要がある。もちろん、なかなか簡単には HOW の領域から手を引いてもらえない(「プロダクトについての決定権を手放したくないんだよ」)ので、プロダクトマネージャーはうまい具合に立ち回って経営陣には戦略策定に特化してもらい、プロダクトについてのイニシアチブを自分で獲得していく必要があるだろう。

まとめ

  • プロダクトマネージャーの役割を明確に
    • 会社はあなたに何を期待しているのかを明確にする
      • 戦略なのか? 戦術なのか? 運営なのか?
    • 本に書いてあること = 会社が求めているプロダクトマネージャー像ではない
      • 会社のステージによってプロダクトマネージャーに求められることは変わる
  • プロダクト開発のイニシアチブをとる
    • 経営陣から特定の機能の開発( HOW )を要求されたきたとき、それは何を目的としているのか( WHY )、どんな結果をもたらすのか(アウトカム)を問う
    • 経営陣には期待するアウトカムと戦略の策定にフォーカスするよう促す
      • 機能開発を一任してもらえるように信頼を獲得する
  • 開発チームからの信頼を得る
    • 自分が関与する必要がないところからは手を引き、信頼してお願いする
      • 「船を作りたいのであれば、木を集めさせたり船の作り方を指示するのではなく、果てることがない広大な海への熱情を説く」

今年の前半に取り組んだプロジェクトで、プロダクトマネージャーになったときに自分のミッションだと思っていた Product Market/Fit を達成することが出来た。ユーザーがお金を払っても欲しいと思うものを考え、健全なマネタイズ手法を提案してリリースするところまで成し遂げた。これまで苦しんだ 2 年間だったけれども、ようやく自信を持って「プロダクトマネージャーやってます」と言えるようになった気がする。

長垂海岸の夕焼け


  1. アメリカは受託の割合が半分強なのに対して、日本は 9 割弱が受託開発。アメリカはシステムを内製する傾向にあるので、内製システム開発も含めると受託の割合はさらに下がりそう。 

  2. 大規模なプロジェクトではどうか知らない。自分が以前勤めていた Web デザインに毛が生えたようなシステム会社では受託者側が要件定義書を作って顧客の承認をもらっていた。 

| @技術/プログラミング

いろいろスパム対策は行っているもののやはりまだスパムが届くので NG ワードの設定を簡単に行えるようにした。こんな感じ。

NG ワード設定

これまで一つのテキストフィールドにカンマ区切りで入力しないといけなかったのを、フィールドを分けて単語ごとに入力できるようにした。

モダンなやり方はしてなくて全部サーバーサイドの Ruby でやってる。動的に新規登録フィールドを増やしたりはできない。新規登録したいときは都度都度フォームを保存する必要があるが、十分速いので実用上は全く問題ない。

同様に、スパマーの餌食になっている過去記事のコメント欄を閉鎖する機能も便利にした。

コメント欄を閉じる記事の設定

仕事では全然プログラミングしていないので久々にコードを書いた。

| @雑談

2020 年、時系列でふりかえるとこんな感じだった。

できたこと

ハワイ旅行

ハワイで最近の SUV に乗って Car Play に感動した。車の買い換えを検討するきっかけになった。ハワイ楽しかったのでまた行きたい。

Akaka Falls Cadillac XT4 Volks Wagen Atlas

ブログの ActiveRecord 化

脱 DataMapper できた。

ブログ UI 刷新

トップページの見た目、アーカイブページにグラフを表示するようにした。ブログ記事を書いてきた実績が可視化されるとやる気が出る。

ウッドデッキの塗り替え

サンドペーパーをかけて塗り直した。

ウッドデッキ塗り直し

庭で焼き鳥

バーベキューに飽きて焼き鳥おじさんになった。

焼き鳥

ハンモック入門

ウキグモ Light & ウンカイ Light 購入。

ハンモック

UL クッカー購入

アルコールストーブ、チタンカップ、メスティン、アルミフライパンなどなど。

アルコールストーブ

山で肉まん・焼売・炊飯

カップラーメンとおにぎりからの卒業。メスティンでの炊飯はめちゃ美味くて感動する。

焼売 メスティンで炊いた米でたまごかけご飯

車の買い換え

スバルインプレッサから Jeep Compass へ。ハワイ旅行でアメ車の SUV に乗って車に対する考え方が変わり、車を買い換えたくなった。国産車はディーラーとの交渉がわずらわしすぎて値引き交渉やオプションがほとんどない外車になってしまった。アメ車はアホみたいにガソリン喰って笑える。プラスチック部品の質が悪い(ゴルフ 2 を思い出す)。

Jeep Compass

ソロで脊振山・金山を縦走

2 年ぶりのソロ縦走。盛夏にソロで 20km 歩いてつら寂し楽しかった。

脊振山 猟師岩鼻

腕時計の買い替え

Pebble Time Round から Apple Watch へ。

Apple Watch

朝駆け登山

明け方前に出発して日の出を山頂で見るというやつをやった。

天山から見る日の出

友だちとキャンプ

家族以外とのキャンプは初めてだった。複数の男手がある状態でのキャンプは楽だった(力仕事を分散)。食事は taketin さんが作ってくれて超楽だった。

ピザを焼く taketin さん

ジョギング再開

年末から走るようになった。Apple Watch でリング閉じたい病にかかった。走るときに聞くのは Podcast よりも音楽の方が良い( Podcast だと気が散る)。

一切れ 3000 円の肉を焼く

肉屋で ¥880/100g のリブロースを厚さ 3cm でカットしてもらった。良い肉を低温調理すると柔らかくなりすぎてブヨブヨになった。和牛は普通に焼いてうまくなるように育てられてるのかも知れない。

一切れ 3000 円の肉

Rebuild サポーターに登録

RAW エピソードと Extra エピソードが聞けて全文検索できるようになった。全文検索できると N さんが昔言ってたあの話をもう一回聞きたいというときに便利。サポーター向けの機能差別はもうちょいあってもよいのではと思ったけど( Rebuild を聞くに際してお金払わなくても困ることがない)、実利を得るためというより支援のためにみんな入っているのかな。

できなかったこと

こっちは箇条書きで。

  • Lokka の ActiveRecord 化を master に merge
    • あと一歩のところで燃え尽きてしまった
  • iOS / Mac のプログラミング
    • 毎年やりたいと思ってやれない
    • Xcode がでかすぎる&重すぎる
  • Rust の勉強
    • ちょびっとやってたけど難しくて途中でやめてしまった
  • 英会話の勉強
    • 会社の制度でレアジョブを始めたけどなかなか時間を捻出できない
    • 休みには休みたくなってしまう
  • ブログを 100 記事書く
    • 11 月に重めの翻訳記事を書いて燃え尽きてしまった
  • 庭の屏の塗り替え
    • ウッドデッキの流れで塗り替えたかったが梅雨入りして夏が来て冬になってしまった
  • 体重の維持
    • 前回リモートワークをしていたとき( Kaizen Platform 時代)はリモートワークしながら減量できたのに今回は太ってしまった
  • ソロでハンモック泊
    • ハンモックを買ったはいいが、ソロで山に泊まりに行けていない
  • 高い山に登る
    • 今年は標高 1500m 以上の山(ハワイーの Pu'u Kalepeamoa は除く)に登っていない
    • 火山規制が解除されたので阿蘇高岳に登りに行きたかったが、休日にソロでの外出はなかなか難しい
    • 年に一回は久住か祖母山、九州脊梁の山(標高 1700m 程度)に登りたい
  • 仕事でめざましい成果を残す
    • いつも通り

いつものようにあまりパッとしない一年だった。