portal shit!

一つ前の記事で書いたように、最近よく走っている。

毎回最低 4km は走っていて、走ると着ている服が汗でびっしょりになるので毎回洗濯しないといけない。頻繁に走ると換えの服がなくなるので新しく短パンを買った。

これまでは NIKE の球技用短パン（サッカーやラグビー用）をはいて走っていた。球技用短パンのせいかちょっと丈が長く、またポケットがないため（ラグビー用の短パンはポケットがあるとそこを掴まれて引き倒されたりするのでポケットがない）走るときは実用性がいまいちだった。今度はポケット付きにしようと思って、金をケチって NIKE や ASICS などのスポーツメーカー製のものではなく、ノーブランドのとにかく安いポケット付きの短パンを買った（送料込み 2200 円）。

届いてはいてみたところ何か具合が悪い。サイズが小さいわけではないのに足の動きを邪魔されるような感じでまとわりつく。どうも股上が深いようだった。腰骨のあたりにゴムがくるようにするとまるで腰ばきしているみたいになって、大腿部に引っかかりを感じる。おへそが隠れるくらいまで引き上げると引っかかり感はなくなるが、はいてる姿が大きめの服を着せられてる小学生みたいだし、走ると裾がめくれあがってきて意図せずセクシーな感じになってしまう。正直失敗だった。やっぱり短パンはケチらずお金を出さないといけないのかも知れない。

はき心地が最高なのは山と道の Light 5 Pocket Shorts で、足の動きを一切妨げず、はいている感覚がない。通常版の 5 Pocket Shorts は生地の頑丈さは申し分ないが、盛夏にはいて山に登るとめっちゃ暑くて少々不快感が残る。 Light 5 Pocket Shorts で一度走ってみたところめっちゃ快適だったが、税込みで 13200 円もするので日々のジョギングでボロボロにしてしまうのは忍びない。 5000 円しないくらいで快適に走れる短パンが欲しい。

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

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

---

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 大阪経由（夜行バス）

メリット

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

デメリット

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

向いている人

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

結論

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

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

参照

• ルートガイド | 穂高岳山荘
• 大阪・京都　－　上高地 | 路線詳細 | 《公式》さわやか信州号
• 上高地｜名鉄バス
• 路線バス | 長野のバス・鉄道ならアルピコ交通株式会社

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 では縦方向からも聞こえるような感覚を覚える。楽器ごとに音が細分化される感じ。これまで聞こえなかったギターのフレット移動音や、小さいパーカッションの音がはっきり聞こえるようになる。

聞き比べコンテンツのほかに「空間オーディオの世界」というプレイリストが用意されており、最近の曲から古い曲までいろんな曲が 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 型人間であるべきと述べられている。再び同書から引用する。

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 版.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

---

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

Apple TV+ で『テヘラン』を見てる。イスラエルのモサド工作員がイランのテヘランに潜入して作戦に失敗し、イスラエルに戻れなくなったというスパイドラマ。

HOMELAND 見てても思ったけどイラン関係のゴタゴタは基本的に全部モサドが悪い気がする。イスラエルが作ってる番組でもあまり良くは描かれない。少なくとも『テヘラン』を見る限りではイランの革命防衛隊よりもモサドの方がやり方が汚い。

イラン人の俳優が良くて、 HOMELAND にも出てるナヴィド・ネガーバンとショーン・トーブがいい味を出してる。ナヴィド・ネガーバンもショーン・トーブも HOMELAND では果てしない悪者という感じで描かれていたが、『テヘラン』では理性的なキャラクターとして登場する。 HOMELAND では見られなかった渋いおっさんの色気を感じる。主人公の女性スパイのビジュアルはあまり好きになれなくて、イラン系のイスラエル人ということなので HOMELAND に出てたナザニン・ボニアディなんかだともっと良かった気がする。イランの人々は男女ともに美形が多い気がする¹。日本在住のイラン人女優サヘル・ローズも美人だと思う。

『テヘラン』のドラマ自体はテヘランではなくアテネで撮影されたみたい²だけど、テヘランという街にめっちゃ興味出てきた。街の遠景に雪の積もった山が出てくるシーンが何度かあって、中東といえば暑いところというイメージなんだけど、きっと寒くて乾燥して日本とは全然違う気候の国なんだろうと思う。イランといえば北朝鮮並みに閉ざされた国という印象があるが、ヨーロッパとの関係は悪くなさそうだし、日本とイランの関係も悪いわけではないはずなので、パスポートにイラン入国のスタンプが押されてその後のアメリカ入国時の審査がきびしくなることを覚悟すれば旅行できないわけではなさそう。死ぬまでに一度旅行してみたい。

"Your Computer Isn't Yours" という記事が先週バズってた。

概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。

この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。

2020-11-25 9:16 追記

日本語訳追加してもらいました。

---

起きていることをまとめると以下のような感じだ。

1. Apple は Mac ユーザーのアプリ起動データを IP 付きで Apple のサーバーに集めている（ログ送信）
   • 各アプリの署名有効期限チェックやマルウェア対策のためということになっている
   • Mac から Apple への通信は暗号化されていない
     • ISP や CDN （ Akamai ）、ネットワークを盗聴している他人が内容を確認可能
   • この通信はユーザーが自分の意思で無効化できない（「Mac解析を共有」をオフにしても送信される）
2. Mac （特に Big Sur でしか動かない Apple Silicon Mac ）を使いたければ利用ログ送信を甘受するしかない
   • Big Sur から、上述のログ送信や Apple 製のアプリは VPN やファイヤウォールを無視するようになった
   • OS の挙動を変更しようとすると Mac が起動しなくなる
3. iCloud Backup は iMessage の秘密鍵も一緒にバックアップするので Apple がメッセージの内容を読むことができる
   • 自分自身が iCloud Backup 利用していなくても、メッセージの送信相手が iCloud Backup を使っていると自分が送ったメッセージが iCloud 上に保存される
4. Apple はプライバシー保護を売りにしながらユーザープライバシーをなおざりにしている
   • iMessages/iCloud Backup のバックドアを放置している
   • 過去にアプリ開発者には HTTPS を強制しながら自分たちは OCSP の通信を平文で行っている
   • ログ送信の件について対応を発表したが、対応時期を明確にしていない

その結果、以下のような状況に陥ることが懸念されている。

• Apple が集めている情報は NSA や FBI に筒抜けになる
  • Apple はアメリカ軍の諜報機関や FBI にユーザーログデータなどの閲覧を令状なしで認める協定を結んでいる
  • iCloud Photo や iMessage の内容を Apple だけでなく軍や FBI も見られるようになっている
• ユーザー保護を隠れ蓑に Apple が力を増大させる
  • マルウェアから守る、を大義名分にして、ユーザーがどのアプリを動かせるかを Apple がコントロールできる可能性がある
  • 原理的には Apple が気に入らないアプリを起動できなくしてしまうことが可能

---

モバイルアプリの利用状況の収集は多分いろんなアプリがやっている。 Mac で Apple が集めている程度以上の情報を集めているアプリも多いだろう（位置情報を取得しているアプリなど）。なので最初この件については過剰に反応しすぎなのではないかと思っていたが、よくよく考えてみると自分の感覚の方が麻痺していたのかもしれない。アプリの利用履歴を IP アドレス付きで送るということは、どこで何をしているかがアプリ開発者に筒抜けだ。そしてそのログを公権力が自由に閲覧可能だとしたらいい気持ちはしない。

アプリと Apple の場合で決定的に異なるのは、アプリはそのアプリが起動している間（あるいはバックグラウンドでのログ送信を許可されている間）だけログを送信するが、 Mac に関して言うとずっーっと起動しっぱなしで使い続けるものなので、ログデータからユーザーの行動履歴・生活様式がわかってしまう。地図アプリで検索した場所の情報も送られていたということなので、 Jeffrey Paul 氏が書いているように、その人がこれから行く予定の場所もわかってしまう。

GDPR や様々なプライバシー保護は、アプリを作りサービスを運営する側としては正直厳しいなと思うところはあるけど、 Apple がアメリカ軍と結んでいる PRISM のような取り決めが存在すると、様々な個人情報が政府機関に流れてしまって、アメリカのサスペンスドラマのように個人の位置情報を携帯の使用履歴からいとも簡単に割り出せるようになってしまう。それはやはり恐ろしい世界だ。

プライバシーの侵害のみならず、プラットフォーマーである Apple の匙加減次第で、ユーザーが使えるアプリが決まるという状況も好ましくない。たびたび iOS の App Store で起こる Apple の恣意的な審査基準改変などはその一端だ。 Hey の件で Apple とやり合った DHH は痛烈に Apple を批判するとともに、かつて邪悪な Microsoft に対抗するための救いとも言えた Apple が以前の Microsoft 以上に邪悪になってしまったのが嘆かわしいと Twitter に書いていた。学生の頃、 Mac を広める活動をやって大学のクラスの半分の同級生のラップトップを Mac にしたというエピソードや、 Rails の開発でも Mac を激推ししたという話は胸熱だった。応援してきた Apple が Evil になってしまい、人一倍残念に思っているのだろう。

That's a formative experience! To have Apple be the escape pod from Microsoft and Windows. I spent so much effort in the early days evangelizing them because of that. Converted half my university class to Macs. Pushed it hard with Ruby on Rails. Team Apple through and through.

— DHH (@dhh) November 18, 2020

Apple はかつて "The computer for the rest of us" というコピーで Macintosh を宣伝していた。しかし今日、 Mac は彼らのコンピューターになってしまったのだ。

今年も寒くなって SIERRA DESIGNS のマウンテンパーカーの記事へのアクセスが増えてきた。シェラデザインのパーカーを買っても問題ないか（友だちから馬鹿にされないか）確認しているのだろう。検索キーワードは「シェラデザイン ダサい」というのが一番多い。

防寒に関しては登山やキャンプをして思うところが増えてきたので、自分の考えをまとめておこうと思う。ちなみに以前、ゴアテックスのジャケットを買ったときに書いた記事では「あまり暖かくないがこれでいいのだ」的なことを書いていたが、登山を始めて寒さのなんたるかを理解するようになってゴアテックスを街中で着るのはやめた。

寒さの原因と対策

寒さの原因は雨、風、気温があって、登山用の防寒着はそれぞれの要因別に作られている。

• 雨
  • 雨ガッパ（レインウェア）
  • ゴアテックス
• 風
  • ウィンドシェル
  • ゴアテックス
  • ロクヨンパーカー
• 気温
  • 中綿入りジャケット
    • ダウン
    • 化学繊維

ゴアテックスのジャケットは雨と風由来の寒さは防げても、あまりに気温が低いときや立ち止まっているとき（休憩中など）は防寒の役に立たない。そういうときにはダウンや化繊など中綿の入った服が必要になる。以下順に見ていく。

風

標高の高い山だと晴れてるのに風がビュウビュウ吹いていて寒いということがある。バイク乗りの人が温かい季節でも革ジャンを着るのと同じ感じで風から体を守るための上着が必要になる。それがウィンドシェルと呼ばれるものだ。雨具でも風はしのげるが、登山などでは動きながら防寒しなければならないので湿気や熱を外に逃してくれる方がいい。というわけで風が強い時には薄手のウィンドシェルを着る。風の寒さだけから身を守り、体から出る熱や湿気は外に逃してくれる。

雨

雨の寒さは濡れることによる寒さだ。濡れると水の冷たさで寒いし、水は蒸発する（乾く）ときに体温を奪うのでダブルで寒い。それに風が当たると低体温症まっしぐらだ。その状況から身を守るのが雨具だ。レインウェアは登山では必須アイテムで、レインウェアがない状態で雨に降られると夏でも低体温症になって死んでしまう。ゴアテックスのジャケットは防水でありながら透湿性があり、汗をある程度外に放出してくれる。おかげで自転車通学の中学生が着る雨合羽のように雨には濡れなかったけど合羽の下は汗でびしょ濡れということにはならない（と言われている）。

低気温

風や雨はなくても気温自体が寒い時もある。低気温には中綿（インサレーション）入りのジャケットが有効だ。インサレーションとは生地内に化学繊維やダウンが封入されていることを意味する。登山では山頂に着いて休憩するときやテント泊するときに着用する。動いていないときは体が冷えるので、体からの熱を閉じ込めておく必要がある。そういうときにダウンや化繊の綿入りジャケットを着る。自分はパタゴニアのナノパフを持っているけど、山でも日常生活でも使っている。

ナノパフは化繊で洗濯機で雑に洗えるけど、汚さない前提ならダウンの方が軽くて温かい。ダウン自体は雨に弱く、濡れると空気の層を作る役割を果たせなくなるのでめっちゃ寒い。なのでもこもこのダウンジャケットを単独の上着にするのはおすすめできない。ダウンは薄くて軽いものを選び（ユニクロのウルトラライトダウンは便利そうだ）、その上からゴアテックスなどを着ると完璧だ。

結論 普通の人にゴアテックスの高いジャケットはいらない

ゴアテックスのハードシェルジャケットは山で風や雨が強い状況で動いてるときに寒さを凌ぐことを目的に作られているので、無風で雨も降っておらず、重い荷物も斜面もない街中でゴアテックスを着ていても体からの熱が少ないので寒いだけだ。 Patagonia や ARC'TERYX のゴアテックスジャケットはかっこいいが、値段が高い割に低気温での寒さを凌げずコストパフォーマンスが悪い。

日本の東北地方以南に住む現代人の日常生活で、風や雨（雪）の寒さを考慮しなければならない状況は稀だろう。移動は公共交通機関か車だろうし、雨に降られたり風に吹かれたりは家や職場から駅まで移動する間の 10 分程度のことだろう。こういう状況では化繊の中綿入りジャケットが便利だ。風や雨を考慮したゴアテックスのジャケットを街中で着てもオーバースペックというか、防寒の役割を果たせない。

加えて、今回記事を書くために ARC'TERYX の Alpha SL を引っ張り出してみたら何と縫い目のところを埋めてあるシームテープがところどころボロボロになっていた。買ってから 7 年経つが、単独では防寒性能が高くないこともあってここ 3 年は登山のときに雨具として持っていくのがもっぱらでほとんど着ていない。買ったときは 5 万円くらいした気がするのでめっちゃコストパフォーマンスが悪い。

そういうわけで、登山をする予定がない普通の人は中綿入りのジャケットを買うのがおすすめです。もし予算に余裕があれば上でも触れている Patagonia のフーディニジャケット（通称「パタゴニアのシャカシャカ」）を追加で買われることをおすすめします。パタゴニアのシャカシャカは非常にコンパクトに畳めるウィンドシェルで、何かと重宝する。山で寒いときはもちろんのこと、真夏にはクーラーの冷気から身を守ることもできる。 Kaizen Platform 退職時に元同僚の @glidenote さんが餞別としてプレゼントしてくれたが、もらってからの 3 年半、外出するときはほぼ常に持ち歩いている。

glidenote パパにもらったパタゴニヤのナイロンジャケット、本当に便利で小さくたためるので常にリュックの中に入れといて雨の日やクーラーが寒いときにめっちゃ活用してる。ご恵贈ありがとうございました＆パパ活始めて本当によかった。https://t.co/pf084qQmgz pic.twitter.com/TA5871rrfw

— morygonzalez (@morygonzalez) June 6, 2017

一年中着られて超おすすめです。セールのときに買えば 1 万円くらいで買えます。