portal shit!

去年の秋（ 2018 年 11 月）に、 Flickr が課金ポリシーを変更することがアナウンスされていた。これまですべてのユーザーに無料で与えられていた 1TB のストレージは撤廃され、無料ユーザーは 1000 枚までしか画像をアップロードできないことになった（上限を超えている分は削除される）。料金プランも見直され、既存の Pro ユーザーは $24.95 / 年で Pro プランを利用できていたのが $49.99 / 年（アメリカ国外在住者は $59.99 / 年）と大幅な値上げとなった。 Flickr は 2018 年の 4 月に SmugMug に買収されている。

SmugMug CEO Don MacAskill's statement

Flickr を買収した SmugMug の CEO の Don MacAskill が Flickr のブログで記事を書いている。

要約するとこんな感じ。

• SmugMug は写真を撮る人にフォーカスしたビジネスを 16 年以上続けてきた
• 資金調達はしておらず、自己資金で運営されている
• ユーザーのデータを広告業者に売って広告収入を得ることもしていない
• 写真家の人々と向き合い、彼らが何を必要としているのかを注意深く聞いてきたのが成功の秘訣
• そのやり方を Flickr にも適用したい
• 我々はユーザーのためのサービスであり、投資家や広告会社のためのサービスではない
• 無料プランは残すが 1000 枚までしかアップロードできず、広告が表示される（プロには表示されない）

要は SmugMug で成功したやり方を Flickr でも踏襲したいということらしい。広告主の為にユーザーを売りたくないと言っておきながら相変わらずフリープランはあって広告を表示するというのは矛盾している気がする。

Flickr VP of Product Andrew Stadlen's statement

Flickr のプロダクト責任者の Andrew Stadlen も無料ユーザーへの扱いの変更について書いている。

• Yahoo! 子会社時代に無料ユーザーに 1TB のストレージを与えた結果、非常に大きな負の影響があった
• 無料に釣られて入ってきたユーザーによるコミュニティの破壊
  • 無料のストレージに釣られてくるユーザーは写真に情熱を傾けるユーザーとは属性が異なり、従来 Flickr を特別なものとしていたコミュニティでの交流や関心を共有する場としての雰囲気を後退させた
  • 活気のあるコミュニティを愛する多くの Flickr ユーザーはこのような変化を望まないはずであり、もう一度、写真コミュニティでの交流にフォーカスすることにした
• 脱広告主優先
  • これまで無料のストレージを提供するために、ユーザーではなく広告主ファーストの状態になっていた
  • Flickr を買収した SmugMug の "You are not our product. You are our priority." というポリシーに共鳴し、広告主ではなく、ユーザーが喜ぶ機能開発を行う
• Flickr = 無料というイメージの打破
  • 1TB の無料ストレージを与えたことで、ストレージや Flickr 自体が無料のものという認識が広まってしまった
  • 活発に利用しているユーザーにサイトの安定運営と成長、イノベーションを継続するための支援をしてほしい

Pro プラン値上げに対する Flickr ユーザーの反応

ヘルプフォーラム内に上の Andrew Stadlen が既存ユーザー向けの料金プランを改定する旨を書いていて炎上している（ 1300 個以上レスがついている）。

Pro であることで得られるメリットは広告なしブラウズとアクセス解析と制限なしのアップロードだが、いまでも値段に見合わないと思いながら払っている、という書き込みがほとんどで、このままメリットが増えない状態で値上げされるんだったら更新しない、という書き込みが目立つ。

この説明では結局なぜ値上げをするのかが書かれておらず、「2年は値上げしないという約束を守ったんで上げますね」ということしか書かれていない。 SmugMug の最安料金プランが $48 / 年なのでそれに合わせるように SmugMug から指示されたのだと思う。

---

考察

Flickr が直面している事業領域は、写真共有（家族・友人）、クラウドストレージ、 SNS という三つだと思う。今日ではそれぞれの市場に強豪がひしめいていてかなり厳しそうだが、昔はそうではなかったはずで、 Flickr が Yahoo! に買収された 2005 年頃は以下のような感じだったはずだ。

Photo Sharing Product Market 2005

この頃は iPhone も Android もなかったし、 iCloud も Picasa Web Album も Google Photos も、 Facebook も Twitter も Instagram もなかった。家族と写真を共有するには CD や DVD に写真を「焼いて」手渡すか、メールに縮小した画像をちまちま添付して送るしかなかった。そこに Flickr が登場して、インターネット越しに簡単に家族や友人に対して写真を共有できるようになった。煩わしいリサイズのことは考えなくてもよい。

家族や友人と共有するだけではなく、写真をインターネット全体に公開して見ず知らずの人と交流することもできた。この頃、写真を公開して人々の反応を得ることができる SNS は Flickr だけだった。他のサービスは家族・友人間の共有やクラウドストレージの機能を売りにしていたが、見ず知らずの人と写真を通してつながれるのは Flickr だけで、そこが写真愛好家の心を捉えた。共有範囲をコントロールできる仕組みと SNS 機能（コミュニティ）によって初期の Flickr は成長した。

その勢力図がいまでは以下のようになってしまった。

Photo Sharing Product Market 2019

スマートフォンが普及して人々がスマートフォンで写真を撮るようになると、WhatsApp や LINE のようなメッセンジャーで写真が共有されるようになった。 日常的に利用しているチャットアプリでの写真共有は Flickr よりもはるかに便利で、身近な人に写真を共有できる Flickr の強みはコモディティ化し、強みではなくなってしまった。

クラウドストレージ市場には Apple や Google がそれぞれ iCloud Photo Stream と Google Photos を投入し、 iPhone ユーザーと Android ユーザーはデフォルトでこれらのサービスを利用することになった。 OS に統合されたこれらのクラウドストレージの利用にはアプリのインストールすら不要でユーザーが深く意識することなくクラウドストレージに写真が保存されるようになった。おまけに Dropbox や Evernote 、 Amazon Drive などの競合もこの市場に参入し、瞬く間にレッドオーシャンと化してしまった。 Google Photos がローンチした 2015 年から Flickr への画像アップロード数が減少し始めている（How many photos are uploaded monthly to Flickr? Flickr may… | Flickr）。

SNS としての Flickr の強みも揺らいでくる。普段使っている SNS で写真を公開できるようになると、わざわざ Flickr を使う必要がない。 Facebook や Twitter で写真を共有できるならわざわざほかの SNS を使う理由はなくなるだろう。写真をキーにオンラインで人とコミュニケーションするときに、 Flickr を使う必要がなくなった。

極めつけは Instagram の登場で、まだスマートフォンで撮られた写真の画質が悪い頃からフィルターをかけるという機能を呼び水に人を集め、スマートフォンによる写真共有 SNS の代表格として君臨した。ハイアマチュアの人々が撮影した綺麗すぎる写真を敬遠して普通のスマートフォンユーザーは Instagram を使ったのだ、と書いている人もいた。

In recent times the nature of photography has shifted quite far from what it used to be. Ten years ago, both amateur and professional photographers were focusing on taking breath-taking pictures of landscapes, people, nature and different environments and cultures. These days people are taking pictures of their cats, their shoes and their meals.

— Why is Flickr not Growing as Quickly as Instagram? - Flickr Embed

この辺はバカと暇人の話に通じるのかもしれない。インターネットがバカになって Flickr が廃れ、 Instagram が流行った。超絶美麗な風景写真よりも自撮り画像とかメシ写真の方が人目を引くのだろう。

こうして Flickr は写真共有、クラウド画像ストレージ、 SNS のすべての市場において強みを失ってしまった。

収益モデル

収益モデルを検証する。 Flickr の収益モデルは 3 つあって、 Ad （無料ユーザー向け）と Subscription （ Pro ユーザー向け）と Merchandise （写真のプリント）だ。

Flickr 同様に広告モデルを採用している Instagram や Facebook は、写真好きではない普通の人の生活に深く入り込んでおり、 Flickr の何倍もの PV を集めているはずだ。広告による収益モデルはとにかく PV を集めてインプレッションを増やすことが重要なのでこの分野で Flickr は苦戦することが予想される。しかも無料ユーザーに対する制限を強化するとなれば、益々広告収入の額は少なくなっていくだろう。

サブスクリプション領域で最大の競合である iCloud や Google Photos をやっている Apple と Google はハードウェアが売れたり iOS / Android のプラットフォームが拡大することが目的なので、サブスクリプションモデルではあるがぶっちゃけ単体で儲からなくても大丈夫なはずだ。 Flickr や SmugMug は単体で利益を上げることを重視して運営しなければならないので、いわゆる捨て身の状態で運営できる iCloud や Google Photos とまともに勝負するとかなり苦戦を強いられるだろう。

写真のプリント販売に関しては、この先は厳しくなっていくばかりだろう。むかし iPhoto にあったプリント販売を利用したことがあるがいまいちだったし、もはや Photos にはそんな機能は付いてない（ App Store でプリントできるアプリを探しましょうと表示される）。印刷したければ印刷サービスを使えばいいだけで、わざわざ中間マージンを取られる Flickr を使うメリットがない。そもそもプリントした写真を好むユーザーは Flickr を使うとは思えない。高齢者はプリントを好むかもしれないが、 Flickr の主なユーザー層はミレニアム世代以下の若い世代だろう。

どの領域においても Flickr が儲けられる要素が見つからない。

課金ポリシー

個人的には $44.95 / 2 年 で Flickr Pro を利用していたので今回の値上げはかなり高いなという印象だった。アメリカ国外居住者に対しては $49.99 ではなく $10 上乗せした $59.99 を提示するなど料金プランには不公平感がある。

さらに運営にかかるコストを、コミュニティに貢献し最もアクティブに使っているユーザーから徴収するというのもいい印象を持てない。リポジトリに課金していた頃の GitHub が OSS には無料で利用させていたように、コミュニティに活気をもたらすユーザーはむしろ優遇しなければならないのではないかと思う。熱心に良い写真を投稿し、 Flickr の PV や MAU 増に貢献する Flickr にとってありがたいユーザー（プラットフォーム革命でいうところの生産者）に課金して、ただ見に来るだけのユーザー（消費者）は無料で使えるのには違和感がある。

あるいは Flickr は写真を投稿せず見に来るだけのユーザーこそコミュニティに活気をもたらすと考えているのだろうか。 SmugMug CEO の Don MacAskill のブログ記事には「無料ユーザーがコミュニティに活気をもたらす」と書いてあったので、そういうスタンスなのかもしれない。写真を投稿するユーザーはいいねが欲しく、いいねをもらうために Flickr にお金を払って Pro ユーザーになり写真をアップロードする。すると無料で利用している閲覧ユーザーたちがやってきていいねを押していく。いいねをもらった Pro ユーザーは承認欲求をみたされる。この考え方ではいいねを送る方が生産者であり、受け取る（写真をアップロードする）方が消費者だといえるのだろう。そうなると写真をアップロードする側に課金するポリシーは分からなくもない。

ただ一方で VP of Product の Andrew Stadlenは「無料の 1TB ストレージにつられてやってきたユーザーはコミュニティを破壊した」とも述べている。いいねをもらったり送ったりを Pro ユーザー同士で行わせたいのだろうか。誰もが消費者であり誰もが生産者である eBay や Etsy のような市場構造にしたいのかもしれない。ただそれでは市場（コミュニティ）はしぼんでしまうだろう。

SmugMug way は Flickr に適合するか

Flickr は家族や友だちと写真を共有する他に、 SNS 上で写真をベースに交流するという側面があった。プロではない、普通の写真好きな人たちが撮った写真を披露しあい、お互いの写真を褒め合う場所。上の方で引用した記事にもそのようなことが書かれている。

一方で SmugMug は交流というよりも、写真を生業としている人たちのためのオンラインストレージで、無料プランはなく、利用するには必ず費用を払う必要があった。収益モデルこそ似ていて Subscription モデルだが、そもそものビジネスモデルが異なる。 Flickr はプラットフォームだが、 SmugMug はプラットフォームではない。プラットフォーム革命の定義にならうなら、 SmugMug はネットワーク効果の働かない単なる SaaS で、 20 世紀型の直線的ビジネスモデルに過ぎない。

SmugMug による Flickr 買収はきっとうまく行かないだろう。 The Verge の記事には以下のように書いてある。

But technology-wise, this acquisition might be a tall order for SmugMug, which isn’t nearly as big as the photo service it now owns

— Flickr acquired by professional photo hosting service SmugMug - The Verge

サービス規模的には Flickr の方がでかいので、技術的には SmugMug には手に負えない仕事を請け負ってしまったことになりそうだ。

---

Flickr は単独で収益モデルを確立する前に Yahoo! に買収されて飼い殺し状態が長かったことが悔やまれる。正しくスマートフォン時代に適応できていたら、今頃は女子高生が利用するのは Instagram ではなく Flickr だったのかもしれない。

10 年前に書いた記事にこんなことを書いていた。

2007年の春、僕は病気で入院してた。抗がん剤やってたから自由に外を出歩くことは出来なかった（抗がん剤の副作用で免疫力が極端に低下し、すぐ風邪をひくから。免疫力が低下している状態で風邪をひくとすぐに肺炎になり、死に至る）。せっかく辺りに桜が咲いているのに、それを見に行くことも出来ない。でもFlickrがあった。僕はWILLCOMの遅い回線でFlickrにアクセスし、「桜」で検索した。健康な人達がアップロードした桜の写真を見ることが出来た。2007年春のささやかな花見でした。

— Photo publication for the rest of us

さようなら、これまでありがとう。

Archive ページ をリファクタリングした。

これまで gulp をビルドに利用していた（Archive ページを React Router 化）が、 webpack を使うように変えた。

React のコードも見直して、 DOM の状態に依存して表示・非表示を切り替えるコードがあったりして（ 🐙 Archive ページにカテゴリごとの記事件数を表示する機能を追加 ）ごちゃごちゃしてたので DOM を直接ごちゃごちゃ操作するのをやめて React で管理するように変えた。親コンポーネント、子コンポーネント、孫コンポーネント、子コンポーネントの兄弟コンポーネント間で状態を共有する必要があって、結構難儀した。

実際の画面を見るとこんな感じ。

App というコンポーネントがルートにあって、子に CategoryList 、CategoryList の子コンポーネント（ App からすると孫）に Category コンポーネントがある。記事一覧自体は CategoryList と兄弟コンポーネントである Archive コンポーネントが担当している。

こんな感じで特定の Category が選ばれたことを Category のクリックイベントをトリガーに CategoryList に伝達し、 CategoryList はさらにそれを App コンポーネントに伝える。その結果が App から Archive コンポーネントに伝えられ、表示内容が変更される。

この辺を参考にして実装した。コールバック関数を props として引き回し、状態を回収する感じ。

ただこういう込み入った状態の管理を React で行う場合は Redux などを利用するのが良いようだった。

前職のとき、 Redux とか Flux が出てきた頃に F/E のエンジニアの人たちが熱狂してたけど自分はいまいち理解できなくて、傍観するだけだったが、いまさらにして何となく Flux アーキテクチャの概要的なものを把握することができた気がする。ただ自分の場合は深みに入り込まず極力シンプルに作りたいと思っていたので Redux などには手を出さず、 Callback で愚直に状態を親コンポーネントに伝達していく方法をとった。

React 、やっぱり大分良いものだとという感じがした。 jQuery でクラスや CSS で show - hide を Toggle していた頃とは隔世の感がある。

ATOK がサブスクリプションを始めて結構経つが、自分は相変わらず 3 年おきくらいにパッケージ版を購入して利用する使い方を継続していた。最後に購入したのは ATOK 2014 で High Sierra くらいまではインストールして使えていたが、 Mojave でとうとうインストーラーが不正と出てインストールできなくなってしまった。最後のパッケージ版の ATOK 2017 for Mac を買うかサブスクリプションに加入するか迷ったが、迷っている間にパッケージ版の販売が終了しており、仕方なく ATOK Passport に加入した。

ATOK 2014 時代に便利だったのが ATOK から Mac の辞書やカレンダーを参照する機能（ Mac スマート連携）で多用していた。 ATOK Passport プレミアムに移行したところ、広辞苑やウィズダム英和・和英辞典（クラウド電子辞典）は使えるが、 Mac の辞書やカレンダーの内容を検索する機能はデフォルトで使えない状態だった。「 Mac スマート連携をオンにしますか？」というダイアログが出たときに「はい」を選択したので十分だと思っていたが、そうではないようだった。以下の通り Mac の辞書で検索されていないことがわかる。

実際にはプラグインとしてインストールが必要のようだった。ただググったときに出てくる以下のやり方は旧バージョンの情報で、最新の ATOK Passport では機能しない。

正しくは以下のページに書いてあるが、 JUSTオンラインアップデート というアプリを起動し、プラグインをインストールしていく必要がある。

その上で ATOK の環境設定を開き、「電子辞典検索」の項目から「追加」を押して、入力時に参照する辞書に「ATOKダイレクトビュー for 辞書」や「ATOKダイレクトビュー for カレンダー」などを追加していく必要がある。めっちゃわかりづらい。

ここまで設定してようやく Mac の辞書で検索されるようになった。

ATOK の日本語変換の精度は好きだし「今日」と打ってその日の日付に変換できるところなど機能自体は便利なのだけど、 UI が特殊すぎたり、設定が複雑だったり、公式サイトのドキュメントの情報が古すぎたりで総合的な使い勝手がよくない。これではパソコンに詳しくない層には使いこなせないと思う。

具合が悪いときにテレ東の廃墟の休日が見たくなってどこでやってるか探したころ Hulu にあると Google の検索結果に出たので Hulu に入ったが、なんと不運なことにすでに Hulu での配信は終了しており見ることができなかった。

ドラマ名で Google 検索するとアフィリエイトサイトがいっぱいヒットして「○×は Hulu で見られる？」みたいな記事ばかり検索結果に表示されて地獄みがある。 Google の↑みたいな表示は便利だけど常に最新の情報だとは限らないみたい。

そんで代わりに何か見られるものはないかと物色していると、ダミアン・ルイスが出ているドラマ HOMELAND があったので見始めたところ、かなり面白い。

ダミアン・ルイスは HBO の『バンド・オブ・ブラザース』で主人公のリチャード・ウィンターズを好演しており、好きな俳優だった。バンド・オブ・ブラザースでは少佐まで昇進したあと少尉時代に自分をいじめていた元上官（大尉）とすれ違うときに、自分のことを無視して通り過ぎようとしたのを呼び止めて敬礼させるシーンがとにかく良い。

We salute the rank, not the man.

HOMELAND は時代を現代に移しているが、ダミアン・ルイスは同じ軍人役で登場している。ただバンド・オブ・ブラザースのときと違ってとにかくかっこよい理想のヒーローとは異なり、ダークなヒーローを演じている。イラク戦争でアルカイダの捕虜になり、 8 年ぶりに救出された海兵隊員の話。帰還してマスコミにちやほやされヒーローのように取り扱われているが、アルカイダに洗脳されていてテロリストに転向したのではないか、というもの。イスラエルのドラマのプロットを借りてアメリカで作り直したものらしい。

人のパソコンや携帯に入り込んで何でも監視したり盗聴したりしててさすがにそこまではできないのではという感じなんだけど（ターミナル風の黒い画面でカチャカチャターンとやると何でもできる）、スノーデン事件なんかを見る限り CIA やアメリカの諜報機関はああいうことをやっているのかもしれない。

全部でシーズン 7 まであって、 4 以降はダミアン・ルイスは出てこなくなり、話の舞台もアメリカからパキスタンやヨーロッパに移るが、アルカイダやシリア動乱などを反映しており中東をはじめとした世界情勢の復習になる。その点でアメリカ国内に閉じて話が進む Netflix の House of Cards よりも話に広がりがあって面白い

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの 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

この記事は登山 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 していきましょう🤑