portal shit!

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの PM が書いたもの）でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。

以下は HTML バージョン

---

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

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

ビジネス上の成功とは何か？

Product/Market Fit

※図は Dan Olsen のスライドから引用

Product/Market Fit とは何か？

良い市場を見つけ、市場の要求を満たすプロダクトを作る

なぜ Product/Market Fit が重要か？

すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから

なぜプロダクトマネージャーが必要か？

• Market Driven な製品開発
  Market Driven でプロダクトを作っている会社の方が 31% 儲かりやすい
• 組織のゴールが明確になり、プロダクトのリリースと収益化が迅速化される

（良い） プロダクトマネージャーは何をするのか

• 何が作る価値があるものか、何がそうでないかを明らかにする
• すでに市場（ユーザー）で価値の検証が済んでいるものだけを作る

エンジニア・デザイナーとどう違うのか

• エンジニア・デザイナーは解決空間を担当
• プロダクトマネージャーは問題空間を担当する

具体的な役割

• ユーザーヒアリング
• 解決すべき課題の定義
  すでに存在する問題だけではなく、ユーザー自身も気づいていない問題も定義する
• 作るものの定義
  機能要件、スコープ
• 成功の定義とメトリクスの計測

※図は Making It Right から引用

プロダクトマネージャーが扱うデータについて

• データ分析チームとは異なり、ありのままの現実を調べる
  線形解析とか難しい統計とか機械学習などは担当しません

まとめ

• Product/Market Fit がミッション（ Objective ）です
• どうやったら Product/Market Fit したかを含め、成功そのものを定義します
• 成功するプロダクトを作ることに注力します（ Engineering からは身を引きます）

参考ページ

• Amazon.co.jp: Making It Right: Product Management For A Startup World (English Edition)
• Mastering the Problem Space for Product/Market Fit by Dan Olsen at Mind the Product San Francisco 2018 on Vimeo

今週、 YAMAP でブラウザーでコースタイム付きの地図を表示し、自由に印刷できる機能をリリースした。

開発の経緯

ユーザー要望が開発の起点だった。

YAMAP には Google Maps のようにウェブブラウザー上で登山道や登山口情報などを見る機能はなく、無料でダウンロードできる画像形式の地図は提供していたが、以下の課題があった。

• 磁北線・縮尺の欠如
• 任意の範囲を切り取っての拡大印刷はユーザー任せ
• 地図の更新（コースタイム、山頂データなど）には画像データの書き出しが必要（アプリ内で使う地図に比べて更新サイクルが遅れる）

切り取り拡大の課題を解決するためにサポートチームが画像編集ソフトの使い方を教えたり、サポートスタッフ自身が地図を編集・加工して渡すことがあり、非常に負荷が高かった。

Google Maps のようにブラウザーで地図を閲覧できて、任意の範囲を自由に印刷できれば問題が解決するのではないかという見通しがあった。

デモ版を作ってもらって得た気付き

API は既存のものを組み合わせて作れそうだったので、 F/E エンジニアにデモ版を作ってもらった。

デモを使ってみて、地図を印刷するための機能が、ウェブブラウザー上で山の情報を確認し、山行計画を練る際にも便利なものであることに気がついた。

ブラウザーで登山コースを確認できるサイトは他にもあるが、百名山などメジャーな山が中心で、低山や全国津々浦々の里山までカバーしているものはなかった。

YAMAP の強みはユーザーからのリクエストで地図データを更新していくところにある。紙の地図では最低でも一年待たないと更新されない情報が随時更新され、しかも他のウェブサイトや紙地図では登山者が少なすぎて地図化されないような低山の地図まである。今回の機能追加で、そのような豊富な地図がウェブブラウザー上で閲覧して印刷することもできるようになるのだった。

デリバリー

デモ版は数日で出来たが、実際にリリースするまでの道のりが長かった。

先行して磁北線関連の問い合わせてをしてきた一部のユーザーにベータ版として機能を提供して様子をうかがいつつ、エンジニア、デザイナー、カスタマーサポート、経営陣のあいだで利害を調整し、機能、デザイン、使い勝手に磨きをかけた。

エンジニアやデザイナーに、他の仕事を差し置いてなぜこの機能をいま作る必要があるのかをわかってもらうのはとても難しかった。またデモ版のラフなデザインが与える印象が非開発者にはクオリティの低いプロダクトに見えてしまい、調整が難航することもあり、デザインの大切さを実感した。

苦労してリリースにこぎつけたあと、リリースノートを書いて PR 担当に Twitter や Facebook での広報を依頼した。普段の機能リリースよりも少しだけ大きい反響を得られたようだった。

【新機能リリース】地図表示・印刷機能をリリースしました。ウェブブラウザーで地図を拡大・縮小し、好みに応じて地図を閲覧・印刷することができます。PCで地図を確認したいとき、紙の地図として山に携帯したいときに便利なので、ぜひご活用ください。

▼詳細はこちら▼https://t.co/vtN3pxHFYo pic.twitter.com/sSb6UbZmua

— YAMAP / ヤマップ (@yamap5586) February 20, 2019

所感

3 ヶ月前にエンジニアからプロダクマネージャーに社内でジョブチェンジしたので、今回のリリースで自分は一切コードを書いていない。初めてプロダクトマネジメントのロールに徹したリリースだった。

エンジニアであれば気にすべきことは自分のことがほとんどで、調子が上がらないときは遅くまで残ってやるとか家に持ち帰ってやるとか色々帳尻を合わせる方法はあった（もちろんいいやり方ではない）。プロダクトマネージャーは自分でコードを書くのではなく、周囲の人の間でもろもろ調整したり働きかけたりが仕事になるので、マイペースでのんびりやってあとで帳尻を合わせるということができない。かといってコミュニケーションを取り過ぎてエンジニアやデザイナーの邪魔をしてもいけない。塩梅が難しい。

もともと自分自身で手を動かしてソフトウェアを作ることが仕事だったから、エディターを開いてもドキュメントしか書かず、何も作ることがない日々に不安はあった。何か機能をリリースしても自分が作ったわけではないという虚しさが訪れるのではというような心配もあった。しかしリリースノートを書き終えたときには、これまでエンジニアとして機能をリリースしてきたときとは別の達成感があった。

プロダクトマネジメントについて書いてある『 Making It Right 』という本に、「プロダクトマネージャーは八つ裂きの刑に処されているようなものだ」というフレーズがある。手足を紐で別々の馬に繋がれて、それぞれ異なる方向に引っ張られるという刑だ。ビジネスサイド、開発チーム、サポート、ユーザーといった様々な人たちの利害を調整し、なんとか落とし所を見つけて説得し、開発チームに納得してソフトウェアを作ってもらう必要がある。リリースする前までは「プロダクトマネージャーつらすぎるだろ…」と思うこともあったが、苦労した分、リリース後の達成感はひとしおだった。

まだまだプロダクトマネージャーとしては新米で至らないところが多々あるが、ユーザー、サポートチーム、開発チームに寄り添いながら、多くの登山者に喜ばれるソフトウェアを届けていきたい。加えて、プロダクトによって山登りのハードルを下げ、まだ山に登ったことはないけれど興味がある、という人達に対して山登りの楽しみを広めていけたらと思う。

Soundcore （ Anker のサブブランド的なやつ）の Liberty Lite を買ったところとても良かった。

これまでも Anker のイヤフォンは二つ買っている。どれも 2000 円くらいのやつだったが、イヤーピース（チップ）がポロポロ取れるやつで、何度もイヤーピースを無くしてしょうがなく左右で違うサイズのものをつけて誤魔化しながら使っており、かなりストレスが溜まっていた。

💸 Anker のイヤフォンで安物買いの銭失い

Anker 製品には全幅の信頼を寄せているのだけど、購入したイヤフォンが立て続けに 1 年もたずに壊れてしまって安物買いの銭失い感を味わった。富裕な元同僚の皆さんがやれ BeatsX だ、 Ai...

portalshit.net

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 の圧勝だろうと思う（使ったことないから知らんけど）。

ケースに入れても電源が入り、 iPhone と接続されてしまう

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 世紀からある物作りサービスと本質的には変わらないビジネスにしかなり得ない。ソフトウェアを売るだけのビジネスでは製品の配布や顧客の維持に課題を抱え、プラットフォーム型の同業者に参入され市場を支配されてしまうだろう。かつては市場を我が物にしていた日本の電気メーカーが中国・韓国勢に劣勢を強いられているのも根本的にはビジネスをプラットフォーム化できなかったことが原因だといえると思う¹。

最近、リストラを発表したマップルなどを作っている昭文社もプラットフォーム企業との闘いに苦戦している直線的ビジネスの良い例だろう。 Google Maps や、その仕組みを利用した食べログや Retty 、旅行情報アプリの隆盛により赤字に転落し、リストラを強いられることになってしまった²。

イノベーションがプラットフォームを可能にした

この本はインターネット企業のビジネスモデルについて書かれた本だが、経済学とイノベーションの歴史にも触れつつ、なぜプラットフォームが支配的になってくるのかが書かれている。 20 世紀の中頃、資本主義の経済学者ハイエクと社会主義国ポーランドの経済学者ランゲによって、経済計算論争というものが繰り広げられた。物の値段を政府が決める（社会主義）のと市場に任せる（資本主義）のではどちらが効率的か、という論争だ。ハイエクの見解が優勢で（のちにハイエクはノーベル経済学賞を受賞した）、その後の経済学の考え方のベースになった。売り手は他人に対して積極的に情報を開示しないので物の値段を政府が決めるのは難しく、市場で決まる値段こそが効率的な資源配分を実現する、という考え方だ。しかしコンピューターとネットワークが当時とは比べ物にならないほどに進化した今日では、政府ではなくプラットフォームがプラットフォーム内部の情報に関して細部にいたるまで把握することが可能で、最適な値段を計算することが可能になった。実際に Uber は場所と時間に応じて乗車料金を変動させている。

ある意味で現在のグーグルは、強大なソ連が実現できなかった社会主義のユートピアを作りつつある。

—アレックス・モザド; ニコラス・L・ジョンソン. プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか (Kindle Locations 1437-1438). 英治出版株式会社. Kindle Edition.

社会主義者が夢見たユートピアをシリコンバレーのテクノロジーカンパニーが実現させた。そのユートピアはプラットフォームと呼ばれるものだが、そこは効率的な取引を参加者に促す一方、自らはプラットフォームがもたらす強力なネットワーク効果により市場でますます支配力を強めていく。どんな SNS も Facebook には対抗しようがないし、どんな検索エンジンも Google のシェアを奪うことは難しいだろう。少なくとも、プラットフォームでない企業がプラットフォーム企業に立ち向かうことは無理だと思う。

評価経済やトークンエコノミーの下地にある経済システム

一昨年、仮想通貨の文脈で『お金2.0』という本が流行って、会社でも回し読みした。価値や評価、信用が重要というのは何となくわかったが、なぜ価値や評価や信用が重要になるのかがはっきりしなかった。あの本に書いてある考え方を可能にするものこそがプラットフォームなのだと思う。お金2.0を読んでしっくりかなかった、という人にもこの『プラットフォーム革命』はおすすめです。

追記 2019/01/21

7 年前にはてな匿名ダイアリーに投稿された以下の翻訳記事がまさにプラットフォームの重要性を説いており面白かった。プラットフォームのないプロダクトはプラットフォームのあるプロダクトに置き換えられる、プラットフォームになるためには外部に整備された API を提供し、外部の開発者の力を借りる、人が欲しがるものを自分で作ろうとしないこと、などはまさにこの本で書かれていることと同内容だった。 Google+ しかり、 Google が SNS を作ろうとして失敗するのはプラットフォーム化しようという意識が乏しいからなんだろうなぁ。確かに Google の API はどれも使いづらい。

• Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（中編）
• Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（後編）

母のガラケーを買い替えたい - hitode909の日記

母は10年もののガラケーを使っている あまり電話している様子はないが、友達の連絡先とかはガラケーに入っている データはある日消えるのでバックアップの効いたソリューションに移行してほしい 日常的にiPadを使っているので、iPhoneに買い替えてもらえばよさそう 悩むのが、各種アカウントの運用 LINEはiPadからやってくるが、2つの端末でログインすることはできないはず gmailも父と共用の、実家用メールアドレスみたいなものがある Apple IDもiPadで使ってるやつと分けるべきなのか悩む 観点 端末 iPhoneを買ったら良いと思ってる キャリア docomoのメールアドレスから、アド…

blog.sushi.money

昨年末に自分の両親の携帯をガラケーからスマートフォンに移行したときのことを書いておきます。

前提条件

• 両親とも docomo でガラケーを使っていた
  • 充電器を共用できるという理由で同じ機種の色違いにしていた
  • スマートフォンに変えても同じ状況が良いと言っていた
• docomo からはさっさとスマートフォンに移行しろというようなハガキが定期的に届きプレッシャーを感じていた
• 自分と弟のお古の iPhone 6 （ docomo 機とSIM Lock Free 機）が余っていたのでそれを渡すことにした

回線

• 回線は MVNO に移行してスマートフォンに変えてもガラケー時代と変わらない程度の料金で済むようにした
  • 月額料金が跳ね上がることがスマートフォンに移行できない理由の一つだった
• キャリアはイオンモバイル経由の IIJmio にした
  • 近隣のイオンの店舗で即日 MNP が可能なため
• docomo のキャリアメールは諦めてもらった
  • 家庭内での連絡にしか使ってなかったので　Apple の Messages で問題なさそう
  • 母は LINE を使ってるかもしれない。

Apple ID とメールアドレス

• 実家には iPad と iMac があって Apple ID も取得済みだったが夫婦共用状態だった
• いい感じの移行は無理だと思ったので両親ともに Gmail のアドレスを取得して新たに Apple ID を作成した

感想

• スマートフォンに移行できて喜んでいた
• iMac と iPad を使っていたので App Store やソフトウェアアップデートの概念に慣れていたのがよかった
• 一族郎党全て iPhone になったので写真の共有や FaceTime ができるようになり便利
  • 息子殿がじいさんばあさんに FaceTime してしりとりしたりできる
• 渡した iPhone 6 はさすがに古すぎるので新しいのに変えてやりたい
  • 実家は山間地で寒いため冬になると iPhone 6 では急に電源が切れる
  • 3 ~ 4 万円で買えるお手軽 iPhone があれば良いのに…
• docomo ショップのサポートに頼れなくなるので自分が全力でサポートする必要がある
  • 自分のサポート負荷を考えると両親とも同じ機種、キャリアの方が良さそう

追記 2018-12-31 09:50:16

ひとでさんの記事には バックアップの効いたソリューションに移行してほしい とあったけど自分の移行記では完全にその観点が抜け落ちていた。 uzulla さんが書かれた以下の記事の方がプラクティカルだった。

daisensei gyoumu

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

パスワード管理は自分（子どもの方）がやるという点やバックアップは iCloud に金払って任せるという点はなるほど感あった。うちの両親は iCloud でアドレス帳などはバックアップされていると思うが、写真に関しては多分バックアップ取りきれてないので正月実家に帰った時にその辺の管理を見直したい。

格安 SIM にしない方が良いという点に関してはまぁそうなんだろうけど、僕の両親の場合は大して使いもしない携帯電話に毎月 8000 円（夫婦で 16000 円）も払いたくない、今と同じくらい（夫婦で毎月 6000 円程度）でスマートフォンに移行したい、という希望があったので格安 SIM にした。

キャリアの窓口はデジタル介護施設として存在している。

面白かった。ただキャリアのサポート窓口、自分がかつて docomo や SoftBank を利用していたときに有効なサポートをしてもらった経験がほとんどないので MVNO で良いだろうという結論に達してしまった。

この記事は登山 Advent Calendar 2018 22 日目の記事ですが遅れて書いています。大変申し訳ありません。

---

今年の山行

年初、成人式の三連休で家族で二丈岳に登った。登り始めが午後だったので下りは真っ暗闇の中を下ることになりめっちゃ嫁さんから怒られた。もう多分家族では二丈岳には行かない。

四月の頭に息子殿と二人で十坊山に登った。お手軽に登れて二丈岳と同じような、パノラマ感では二丈岳を上回る眺望が得られてお得だと思った。今年はこの後も二回、十坊山に登った。

家の近所の山を息子殿と二人で登った。バーナーを持っていき忘れてカップラーメンとクッカーを持ってきていたのに食べられなかった。おにぎりとスーパーの惣菜チキンだけ食べた。初めて高地山に登って景色の良さと低山ながら整備されたルートの歩きやすさに感動した。

家族 3 人で十坊山に登った。福吉方面から登ったので結構距離がありまた嫁さんに文句を言われたので十坊山にももう家族で登ることはないと思う。

社内登山で阿蘇山に行った。地元ながら登山をしたことはなかった。ミヤマキリシマが目的だったが天候が良くなく、雲の切れ間からチラッとしか見ることができなかった。中岳には登頂したが高岳には登頂できなかった。鹿らしき野生生物の白骨化死体などがあり Into The Wild 感あった。また行きたい。

社内登山で久住に行った。去年の平治岳以来。炎天下のなか 10km 以上歩いてくたびれた。また自分は社内の強い人たちにくらべたら雑魚だなということが思い知らされてよかった。

山の日に近所の低山に登った。夕方から登り始めたので帰りは暗くなってしまって結構危なかった。鐘撞山は良い山なので毎月登りたい。

盆に実家に帰ったときに両親も含めて杵島岳に登った。阿蘇はかなり上の方まで車で行けるので 1000m 以上の山でも低山感覚で登ることができて便利。登山の格好じゃなくても道も整備されているのでハイキング感覚で楽しめる。

北アルプス遠征で白馬岳に行った。素晴らしすぎた。詳しくはこちら。

北アルプス遠征に行った

仕事で長野県、富山県、新潟県の県境に跨がる北アルプスの白馬岳に行った。山行記録はこちら。当初は以下のように栂池高原 -> 白馬岳 -> 朝日岳 -> 蓮華温泉という縦走の予定だ...

portalshit.net

午前中仕事をして昼からちょいとチームビルディング登山で二丈岳まで。このとき調子こいた発言をしてしまって同僚殿に縦走を焚きつけられ翌月敢行することに。

自分史上、最高につらい登山だった。 20km 、約 10 時間を一人で黙々と歩いた。後半はアルプスで痛めた膝が痛み始め非常にしんどかったが、今になって思い返すと結構いい思い出でまた行きたいと思ってしまうので怖い。こちらも別に記事があります。

2018/10/13 糸島四座縦走（失敗）

北アルプスから帰ってきたあと「二丈岳に行ったけど物足りなかった」とぼやいていたところ同僚に福吉駅から十坊山、浮嶽、女岳、二丈岳を経て深江駅までの四座縦走をやってのけられ、これに触発されて一ヶ月ほ...

portalshit.net

会社のイベントで宝満山へ行った。良い山だった。英彦山といい、修験の山は人を惹きつける何かがある。

---

登山、最初はおっかなびっくりだったがやっていくうちにどんどん楽しくなってきた。一人でサクッと登れるところがとても良い。登っているときに自分と向き合えるような感覚になるところも良い。一人で体を動かせるものといえばジョギングがあるが、悩みごとや嫌なことを忘れるのには向いているものの、深く考えごとをしたりということに向かないと思う。登山は歩きながらいろんなことに考えを巡らせることが出来る。ゲーテはかつてハイデルベルクの街を歩いて思索にふけったというが、歩くことには考えることを助ける側面があると思う。というわけで逃げられない悩み事や考えごとがある人は登山をお勧めします。一人で黙々と縦走しましょう。

YAMAP に入ってからは 1 年半になる。今年はなんとエンジニアからプロダクトマネージャーにジョブチェンジすることになってしまった。登山経験はしょぼいし体力なくてダメダメなんだけど、これまでいくつものサービス開発で失敗したり成功してきた経験を活かして、皆さんに楽しんで使ってもらえるプロダクトをお届けできるように全力を尽くしていく所存です。

この記事は CircleCI Advent Calendar 2018 19 日目の記事ですが間に合わず一日遅れて書いております。すんません 🙇🏻

CircleCI を使った Rails アプリのデプロイフローみたいな話を書こうかなと思ったのですが、すでに他の方が書いてる内容とかぶりそうだし、自分自身ブログに過去何回も書いた話なんで今回はエモ方面の話を書くことにします。技術的な情報はないのでそっち方面を期待している方はすんません。

---

いまの職場で働き始めて 1 年半なんですが、当初は CI はなく、テストコードもありませんでした。いまはそこで当たり前のように CI が回り、テストのカバレッジもまぁまぁ高く、デプロイは CircleCI 経由でじゃんじゃん行われるような状況となっております。新しく会社に入った人も GitHub の Organization に入ってもらえたらその瞬間から deploy 実行できます。具体的な話は昔書いてますのでよかったらご覧下さい。

📝 CircleCI と autodoc で Rails API のドキュメントを自動更新

autodoc を導入して Rails プロジェクトで Request Spec を書くと自動的にドキュメントが更新されるようにした。 autodoc 自体は前々職の頃から利用していて大変お世話...

portalshit.net

🏭 Docker を Production 投入するメリットを考える

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導...

portalshit.net

👺 Hubot で Slack から AWS ECS にデプロイ

前書いてた記事の続き。 🏭 Docker を Production 投入するメリットを考える 仕事で開発中のシステムで、 master...

portalshit.net

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 していきましょう🤑