去年 に引き続き、 Circle に行った。
今年もペトロールズが一番の目当てだったが、ペトロールズよりも以前から聞いていた toe の演奏もあって非常に堪能できた。今年は最近よく行く糸島の COFFEE UNIDOS がお店を出していて、前売り券を UNIDOS で買ったところコーヒーを二杯飲める特典が付いてきてお得だった。
Circle は去年行ってその平和さに感銘を受けたが、今年も平和で非常に良かった。去年よりも早い時間のバスで向かったためバス乗り場では待たなければならなかったが、路線バスにすし詰めに詰め込まれることもなく、渋滞に巻き込まれることもなく、快適な観光バス（座席に電源付き）で移動できてよかった。会場の食べ物や飲み物もぼったくりとは言えない値段でほどよいし、酒を飲みすぎて暴れている人もおらず、アーティストの間で変な MC は入らず、前川清も馴染める良いフェスだった。
ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの PM が書いたもの）でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。
以下は HTML バージョン
ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する
Product/Market Fit
※図は Dan Olsen のスライドから引用
良い市場を見つけ、市場の要求を満たすプロダクトを作る
すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから
※図は Making It Right から引用
今週、 YAMAP でブラウザーでコースタイム付きの地図を表示し、自由に印刷できる機能をリリースした。
ユーザー要望が開発の起点だった。
YAMAP には Google Maps のようにウェブブラウザー上で登山道や登山口情報などを見る機能はなく、無料でダウンロードできる画像形式の地図は提供していたが、以下の課題があった。
切り取り拡大の課題を解決するためにサポートチームが画像編集ソフトの使い方を教えたり、サポートスタッフ自身が地図を編集・加工して渡すことがあり、非常に負荷が高かった。
Google Maps のようにブラウザーで地図を閲覧できて、任意の範囲を自由に印刷できれば問題が解決するのではないかという見通しがあった。
API は既存のものを組み合わせて作れそうだったので、 F/E エンジニアにデモ版を作ってもらった。
デモを使ってみて、地図を印刷するための機能が、ウェブブラウザー上で山の情報を確認し、山行計画を練る際にも便利なものであることに気がついた。
ブラウザーで登山コースを確認できるサイトは他にもあるが、百名山などメジャーな山が中心で、低山や全国津々浦々の里山までカバーしているものはなかった。
YAMAP の強みはユーザーからのリクエストで地図データを更新していくところにある。紙の地図では最低でも一年待たないと更新されない情報が随時更新され、しかも他のウェブサイトや紙地図では登山者が少なすぎて地図化されないような低山の地図まである。今回の機能追加で、そのような豊富な地図がウェブブラウザー上で閲覧して印刷することもできるようになるのだった。
デモ版は数日で出来たが、実際にリリースするまでの道のりが長かった。
先行して磁北線関連の問い合わせてをしてきた一部のユーザーにベータ版として機能を提供して様子をうかがいつつ、エンジニア、デザイナー、カスタマーサポート、経営陣のあいだで利害を調整し、機能、デザイン、使い勝手に磨きをかけた。
エンジニアやデザイナーに、他の仕事を差し置いてなぜこの機能をいま作る必要があるのかをわかってもらうのはとても難しかった。またデモ版のラフなデザインが与える印象が非開発者にはクオリティの低いプロダクトに見えてしまい、調整が難航することもあり、デザインの大切さを実感した。
苦労してリリースにこぎつけたあと、リリースノートを書いて PR 担当に Twitter や Facebook での広報を依頼した。普段の機能リリースよりも少しだけ大きい反響を得られたようだった。
【新機能リリース】地図表示・印刷機能をリリースしました。ウェブブラウザーで地図を拡大・縮小し、好みに応じて地図を閲覧・印刷することができます。PCで地図を確認したいとき、紙の地図として山に携帯したいときに便利なので、ぜひご活用ください。
— YAMAP / ヤマップ (@yamap5586) February 20, 2019
▼詳細はこちら▼https://t.co/vtN3pxHFYo pic.twitter.com/sSb6UbZmua
3 ヶ月前にエンジニアからプロダクマネージャーに社内でジョブチェンジしたので、今回のリリースで自分は一切コードを書いていない。初めてプロダクトマネジメントのロールに徹したリリースだった。
エンジニアであれば気にすべきことは自分のことがほとんどで、調子が上がらないときは遅くまで残ってやるとか家に持ち帰ってやるとか色々帳尻を合わせる方法はあった（もちろんいいやり方ではない）。プロダクトマネージャーは自分でコードを書くのではなく、周囲の人の間でもろもろ調整したり働きかけたりが仕事になるので、マイペースでのんびりやってあとで帳尻を合わせるということができない。かといってコミュニケーションを取り過ぎてエンジニアやデザイナーの邪魔をしてもいけない。塩梅が難しい。
もともと自分自身で手を動かしてソフトウェアを作ることが仕事だったから、エディターを開いてもドキュメントしか書かず、何も作ることがない日々に不安はあった。何か機能をリリースしても自分が作ったわけではないという虚しさが訪れるのではというような心配もあった。しかしリリースノートを書き終えたときには、これまでエンジニアとして機能をリリースしてきたときとは別の達成感があった。
プロダクトマネジメントについて書いてある『 Making It Right 』という本に、「プロダクトマネージャーは八つ裂きの刑に処されているようなものだ」というフレーズがある。手足を紐で別々の馬に繋がれて、それぞれ異なる方向に引っ張られるという刑だ。ビジネスサイド、開発チーム、サポート、ユーザーといった様々な人たちの利害を調整し、なんとか落とし所を見つけて説得し、開発チームに納得してソフトウェアを作ってもらう必要がある。リリースする前までは「プロダクトマネージャーつらすぎるだろ…」と思うこともあったが、苦労した分、リリース後の達成感はひとしおだった。
まだまだプロダクトマネージャーとしては新米で至らないところが多々あるが、ユーザー、サポートチーム、開発チームに寄り添いながら、多くの登山者に喜ばれるソフトウェアを届けていきたい。加えて、プロダクトによって山登りのハードルを下げ、まだ山に登ったことはないけれど興味がある、という人達に対して山登りの楽しみを広めていけたらと思う。
Soundcore （ Anker のサブブランド的なやつ）の Liberty Lite を買ったところとても良かった。
これまでも Anker のイヤフォンは二つ買っている。どれも 2000 円くらいのやつだったが、イヤーピース（チップ）がポロポロ取れるやつで、何度もイヤーピースを無くしてしょうがなく左右で違うサイズのものをつけて誤魔化しながら使っており、かなりストレスが溜まっていた。
Liberty については rebuild.fm でだいぶ前に miyagawa さんが紹介していて良さそうだったので目を付けてはいたのだけど、これまで買ってきた 2000 円程度のものならいざ知らず、 6000 円近くしてまたイヤーピースが外れやすくて 1 年程度で買い換えることになったら嫌だなぁと悩んでいた。年末に Amazon を覗くとポイント還元キャンペーンをやっていたのでリストカット感覚で購入してみた。
冷たいケーブルを首の後ろにたらんと垂らす必要がないのがこんなに快適だとは思わなかった。本体が耳からぽろっと取れるということもないし、イヤーピースもしっかりしていて簡単に外れたりしない。
ノイズキャンセリングではないが、カナル式なので耳の穴をしっかり塞いでくれて電車や街中など結構周囲の音がやかましい所で使っても音がよく聞こえる。 iPhone の標準イヤフォンでは線路脇を歩いていて電車が通るとめっちゃうるさくて何も聞こえなくなってしまうが、 Liberty であればちゃんと音楽を聴ける。
直近まで使っていた Anker の SoundBuds は 3 時間くらいしかバッテリーが持たなくて、いざ聞こうとするとバッテリー切れ、ということが多かった。 Liberty Lite も本体は 3.5 時間程度だが、ケースと合わせて 12 時間バッテリーであり、使わないときはケースに入れて保管している間にケースのバッテリーから本体に充電されるので大体本体は満タン状態になっている。
イヤーピースが外れるなど苦労しながらもこれまで Anker のイヤフォンを使ってきたのは値段の割に音が良いだからだった。 Liberty Light も個人的には十分満足できる音質。
例えば主に iPhone で使っていてたまに Mac でも使いたいとなると、いちいち iPhone でペアリングを解除して Mac で接続し直す必要がある。これをやってると iPhone との接続が不安定になって、接続の解除だけでなくリセットしないと iPhone と繋がらなくなるということが何度かあった。この辺は AirPods の圧勝だろうと思う（使ったことないから知らんけど）。
Liberty Lite はケースに入れたら勝手に Bluetooth 接続が切れて充電が開始される仕組みだが、稀にケースに入れても iPhone との接続をキープしてしまいバッテリー切れになってしまうことがある。あるいはケースに入れて Bluetooth 接続は切れたが充電がされないこともある。買ってすぐの頃頻発していたが、しばらく使っていると起こりづらくなった。
残念なところがないわけではないが、これまで使ってきた両耳が繋がってるものに比べて使い勝手もバッテリー持続時間も改善されて嬉しいという気持ちしかない。耳から外したら自動的に音楽が止まるような機能や iPhone と Mac でシームレスにペアリング先を切り替えられるような機能はないので、そういうのが欲しい人は 2 万円近く払って AirPods を買ってもらうしかないと思いますが、 Mac とモバイル機器でイヤフォンを分けてるような人には Liberty Lite は十分満足できるコストパフォーマンスの良いイヤフォンだと思います。買ってよかった。
『プラットフォーム革命』という本を読んで非常に考えさせられることが多かった。かつては一世を風靡したものの今では名前も聞かなくなった Nokia と BlackBerry がスマートフォン市場で僅か数年で Apple と Google に敗北したというエピソードから話が始まる。非常に衝撃的だった。この本を読むまで自分はソフトウェア企業で働いているという認識を持っていたけど、その視点では本質を見誤ると思った。自分が作っているのはソフトウェアではなくプラットフォームなのだということを意識させられた。
プラットフォームとはマッチングの場所で、何らかの価値を提供する生産者と、その価値を評価して対価を支払い消費する消費者に二分されるサービスのことを指す。ウェブサービスが一番分かりやすい。例えば Uber や Airbnb はプラットフォームだ。日本ではメルカリなんかがプラットフォームの代表例だろう。 Nokia や BlackBerry を崩壊に追い込んだ iOS や Android のエコシステムもプラットフォームといえる。
Nokia や BlackBerry は世界中の開発者が自由にソフトウェアを提供できる環境を用意できなかった。 BlackBerry はセキュリティとハードウェアキーボードこそがユーザーが求めているものであると断定し、自由に開発者がアプリケーションを開発できる環境を用意しなかった。 Nokia は開発プラットフォームを構築しようとしたが、 Symbian OS は開発者を惹きつけるプラットフォームではなかった。 Apple や Google は自分達だけで最高のスマートフォンを作ろうとせず、世界中の開発者に場所を提供して、自分達だけでは想像もできなかったようなアプリケーションを開発してもらい、ユーザーに届けた。結果はご覧の有様だ。この本では BlackBerry のようなビジネスモデルを直線的ビジネスと定義し、 20 世紀から続く古いビジネスモデルであると揶揄している。
プラットフォームを構築することなく、作った製品を販売するだけの企業はそのうち衰退してしまう。プラットフォームというビジネスモデルは既存のビジネスよりも圧倒的に効率的で成長速度が速く、またほぼ無限といえるほどのスケーラビリティを備えているからだ。単にソフトウェアを売るだけのビジネスモデルではソフトウェアやネットワークの特性をうまく利用できておらず、 20 世紀からある物作りサービスと本質的には変わらないビジネスにしかなり得ない。ソフトウェアを売るだけのビジネスでは製品の配布や顧客の維持に課題を抱え、プラットフォーム型の同業者に参入され市場を支配されてしまうだろう。かつては市場を我が物にしていた日本の電気メーカーが中国・韓国勢に劣勢を強いられているのも根本的にはビジネスをプラットフォーム化できなかったことが原因だといえると思う1。
最近、リストラを発表したマップルなどを作っている昭文社もプラットフォーム企業との闘いに苦戦している直線的ビジネスの良い例だろう。 Google Maps や、その仕組みを利用した食べログや Retty 、旅行情報アプリの隆盛により赤字に転落し、リストラを強いられることになってしまった2。
この本はインターネット企業のビジネスモデルについて書かれた本だが、経済学とイノベーションの歴史にも触れつつ、なぜプラットフォームが支配的になってくるのかが書かれている。 20 世紀の中頃、資本主義の経済学者ハイエクと社会主義国ポーランドの経済学者ランゲによって、経済計算論争というものが繰り広げられた。物の値段を政府が決める（社会主義）のと市場に任せる（資本主義）のではどちらが効率的か、という論争だ。ハイエクの見解が優勢で（のちにハイエクはノーベル経済学賞を受賞した）、その後の経済学の考え方のベースになった。売り手は他人に対して積極的に情報を開示しないので物の値段を政府が決めるのは難しく、市場で決まる値段こそが効率的な資源配分を実現する、という考え方だ。しかしコンピューターとネットワークが当時とは比べ物にならないほどに進化した今日では、政府ではなくプラットフォームがプラットフォーム内部の情報に関して細部にいたるまで把握することが可能で、最適な値段を計算することが可能になった。実際に Uber は場所と時間に応じて乗車料金を変動させている。
ある意味で現在のグーグルは、強大なソ連が実現できなかった社会主義のユートピアを作りつつある。
—アレックス・モザド; ニコラス・L・ジョンソン. プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか (Kindle Locations 1437-1438). 英治出版株式会社. Kindle Edition.
社会主義者が夢見たユートピアをシリコンバレーのテクノロジーカンパニーが実現させた。そのユートピアはプラットフォームと呼ばれるものだが、そこは効率的な取引を参加者に促す一方、自らはプラットフォームがもたらす強力なネットワーク効果により市場でますます支配力を強めていく。どんな SNS も Facebook には対抗しようがないし、どんな検索エンジンも Google のシェアを奪うことは難しいだろう。少なくとも、プラットフォームでない企業がプラットフォーム企業に立ち向かうことは無理だと思う。
一昨年、仮想通貨の文脈で『お金2.0』という本が流行って、会社でも回し読みした。価値や評価、信用が重要というのは何となくわかったが、なぜ価値や評価や信用が重要になるのかがはっきりしなかった。あの本に書いてある考え方を可能にするものこそがプラットフォームなのだと思う。お金2.0を読んでしっくりこなかった、という人にもこの『プラットフォーム革命』はおすすめです。
7 年前にはてな匿名ダイアリーに投稿された以下の翻訳記事がまさにプラットフォームの重要性を説いており面白かった。プラットフォームのないプロダクトはプラットフォームのあるプロダクトに置き換えられる、プラットフォームになるためには外部に整備された API を提供し、外部の開発者の力を借りる、人が欲しがるものを自分で作ろうとしないこと、などはまさにこの本で書かれていることと同内容だった。 Google+ しかり、 Google が SNS を作ろうとして失敗するのはプラットフォーム化しようという意識が乏しいからなんだろうなぁ。確かに Google の API はどれも使いづらい。
アメリカ企業が作ったプラットフォームに中国・韓国勢が低コストでハードを提供するが、日本勢は自らプラットフォームを構築することもできず、そのプラットフォームに参加することもできなかった、あるいは参加が遅れた。 ↩
この記事は登山 Advent Calendar 2018 22 日目の記事ですが遅れて書いています。大変申し訳ありません。
年初、成人式の三連休で家族で二丈岳に登った。登り始めが午後だったので下りは真っ暗闇の中を下ることになりめっちゃ嫁さんから怒られた。もう多分家族では二丈岳には行かない。
四月の頭に息子殿と二人で十坊山に登った。お手軽に登れて二丈岳と同じような、パノラマ感では二丈岳を上回る眺望が得られてお得だと思った。今年はこの後も二回、十坊山に登った。
家の近所の山を息子殿と二人で登った。バーナーを持っていき忘れてカップラーメンとクッカーを持ってきていたのに食べられなかった。おにぎりとスーパーの惣菜チキンだけ食べた。初めて高地山に登って景色の良さと低山ながら整備されたルートの歩きやすさに感動した。
家族 3 人で十坊山に登った。福吉方面から登ったので結構距離がありまた嫁さんに文句を言われたので十坊山にももう家族で登ることはないと思う。
社内登山で阿蘇山に行った。地元ながら登山をしたことはなかった。ミヤマキリシマが目的だったが天候が良くなく、雲の切れ間からチラッとしか見ることができなかった。中岳には登頂したが高岳には登頂できなかった。鹿らしき野生生物の白骨化死体などがあり Into The Wild 感あった。また行きたい。
社内登山で久住に行った。去年の平治岳以来。炎天下のなか 10km 以上歩いてくたびれた。また自分は社内の強い人たちにくらべたら雑魚だなということが思い知らされてよかった。
山の日に近所の低山に登った。夕方から登り始めたので帰りは暗くなってしまって結構危なかった。鐘撞山は良い山なので毎月登りたい。
盆に実家に帰ったときに両親も含めて杵島岳に登った。阿蘇はかなり上の方まで車で行けるので 1000m 以上の山でも低山感覚で登ることができて便利。登山の格好じゃなくても道も整備されているのでハイキング感覚で楽しめる。
北アルプス遠征で白馬岳に行った。素晴らしすぎた。詳しくはこちら。
午前中仕事をして昼からちょいとチームビルディング登山で二丈岳まで。このとき調子こいた発言をしてしまって同僚殿に縦走を焚きつけられ翌月敢行することに。
自分史上、最高につらい登山だった。 20km 、約 10 時間を一人で黙々と歩いた。後半はアルプスで痛めた膝が痛み始め非常にしんどかったが、今になって思い返すと結構いい思い出でまた行きたいと思ってしまうので怖い。こちらも別に記事があります。
会社のイベントで宝満山へ行った。良い山だった。英彦山といい、修験の山は人を惹きつける何かがある。
登山、最初はおっかなびっくりだったがやっていくうちにどんどん楽しくなってきた。一人でサクッと登れるところがとても良い。登っているときに自分と向き合えるような感覚になるところも良い。一人で体を動かせるものといえばジョギングがあるが、悩みごとや嫌なことを忘れるのには向いているものの、深く考えごとをしたりということに向かないと思う。登山は歩きながらいろんなことに考えを巡らせることが出来る。ゲーテはかつてハイデルベルクの街を歩いて思索にふけったというが、歩くことには考えることを助ける側面があると思う。というわけで逃げられない悩み事や考えごとがある人は登山をお勧めします。一人で黙々と縦走しましょう。
YAMAP に入ってからは 1 年半になる。今年はなんとエンジニアからプロダクトマネージャーにジョブチェンジすることになってしまった。登山経験はしょぼいし体力なくてダメダメなんだけど、これまでいくつものサービス開発で失敗したり成功してきた経験を活かして、皆さんに楽しんで使ってもらえるプロダクトをお届けできるように全力を尽くしていく所存です。
この記事は CircleCI Advent Calendar 2018 19 日目の記事ですが間に合わず一日遅れて書いております。すんません 🙇🏻
CircleCI を使った Rails アプリのデプロイフローみたいな話を書こうかなと思ったのですが、すでに他の方が書いてる内容とかぶりそうだし、自分自身ブログに過去何回も書いた話なんで今回はエモ方面の話を書くことにします。技術的な情報はないのでそっち方面を期待している方はすんません。
いまの職場で働き始めて 1 年半なんですが、当初は CI はなく、テストコードもありませんでした。いまはそこで当たり前のように CI が回り、テストのカバレッジもまぁまぁ高く、デプロイは CircleCI 経由でじゃんじゃん行われるような状況となっております。新しく会社に入った人も GitHub の Organization に入ってもらえたらその瞬間から deploy 実行できます。具体的な話は昔書いてますのでよかったらご覧下さい。
8 年くらい前の自分はどうやったら CI だとか自動デプロイだとかできるようになるのか皆目見当が付きませんでした。いま 8 年前の自分と同じような状況にいる人（回りにテストを書く習慣を持つ人がいない人、 CI 動かすためにどうすればよいかわからない人）に何か言いたいと思い筆をとりました。
まずは何はなくとも頑張って一つテストケースを書いてみましょう。最初からカバレッジ 100% とか目指さなくてもよいです。どれか一つ、テストが書きやすそうなコードを見つけてテストを書き、ローカルで実行してテストがパスするのを確認しましょう。テストファーストとかも最初から目指さなくてよいです。
手元でテストが通ることを確認したら、 CI 環境でもテストを実行できるようにしましょう。
昔は Jenkins しか選択肢がなく、 Jenkins が動く環境をセットアップする（サーバーを調達する、 VPS を借りてもらう、などなど）に社内調整が必要でしたが、 CircleCI ならプライベートリポジトリでも 1 プロセスなら無料で使えますので社内調整が非常に楽です（外部にコード出してはダメな職場だと厳しいですね…）。
最初にプロジェクトを追加して言語を選ぶと設定ファイルが自動生成されるので、それをコピペして .circleci/config.yml として保存し、リポジトリにコミットするだけでとりあえずビルドが実行されるようになります。
昔は難しかった CI 環境構築のうち、お金の問題、設定の難しさの問題を CircleCI は解決してくれます。あとはあなたが頑張るだけです。
CircleCI ならビルド終了ごとに結果を Slack などチャットシステムに通知させることができます。まずはテストケースが一つでもよいのでリポジトリへの push をトリガーにビルドが実行されたら結果を Slack に通知してみましょう。
リポジトリに GitHub を使っているなら Pull Request にビルド結果が表示されるようになるはずです。
これらで「なんかようわからんけどやっとる感」を出していきましょう。
そして過去のコードのことは一旦無視して、あなたが新しく追加する部分に関してはテストコードをセットで書くようにしていきましょう。あなたがコードレビューを依頼するときには必ずテストがグリーンな状態で依頼するようにするのです。
そうこうしているうちに他の人が出した Pull Request でテストが失敗するケースが発生します。 Slack の #circleci チャンネルに赤色の Failure 通知が届き社内が騒然とするかもしれません。しかしこれはチャンスです。
「よかった、これでバグが未然に防げましたね」
あなたのこの一言でテストや CI がもたらす開発効率の向上がチームの皆さんに伝わるはずです。こうなったらもう一押しです。あなたがテストと CI の伝道師になりましょう。テストを書くことが当たり前になってきたら、 CircleCI からの deploy や定型処理を CircleCI でやらせるような使い方にチャレンジしていきましょう。どんどん周囲を巻き込んで、 CI 文化を定着させていって下さい。
何はともあれ、最初は一つのテストコードを書くことから始まります。変更に強いコードを書いてじゃんじゃん deploy し、じゃんじゃん Money making していきましょう🤑
