無印吉澤

ソフトウェア開発、運用管理(俗にいう DevOps)、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

「入門 監視」を読みました

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

あまりにシンプルなタイトルで話題になっていた「入門 監視」を読みました。

プログラミング本で言うと「リーダブルコード」くらいの判型と厚さでサッと読めて、自分たちがやっている監視を見直すきっかけになる良書でした。

内容の簡単な紹介と、個人的な感想(というか読みながら考えたこと)をメモしておきます。

内容の簡単な紹介

本書は二部構成です。

前半(第I部「監視の原則」)では、「監視」を考えるときに出てくる基本的な用語の解説と、監視でやりがちなアンチパターンとその逆(デザインパターン)が手短にまとめられています。メトリクス、ログ、インシデント管理といった基本的な用語から、中央値やパーセンタイルといった監視ツールでよく出てくる統計用語まで触れているので、いままで監視に関わっていないようなエンジニアでも読みやすいと思います。

後半(第II部「監視戦略」)では、いくつかの章に分けて、具体的な監視項目と、そのために使える手段を解説しています。本書の良いところは「ユーザ視点での監視」の重要性が強調されているところで、章の並び順もそうなっています。

  • ビジネスを監視する(5章)
    • ビジネス KPI(月次経常利益など)や、コア機能が利用される頻度など
  • フロントエンド監視(6章)
    • 実際のユーザが見ているページのロード時間など
  • アプリケーション監視(7章)
    • アプリケーションのメトリクス・ログ、ヘルスチェック、分散トレーシング
  • サーバ監視(8章)
    • OS のメトリクス、SSL 証明書、Web、データベースなどなど
  • ネットワーク監視(9章)
    • SNMP の基本的な解説など
  • セキュリティ監視(10章)
    • コンプライアンス規制を満たしていることを監視で確認する例

本書では全体を通して、監視の SaaS サービスを活用することを推奨しています。本書の付録には Mackerel プロダクトマネージャの @songmu さんによる「実践 監視 SaaS」がついていて、監視 SaaS を使ったことがない人向けのよい入門になっています。

感想

ビジネスに関する監視をもっと増やしてみたくなる

ユーザ視点での監視が重要、というのは常識として理解しているつもりでしたが、本書でビジネス KPI の話が最初に来たのはちょっと驚きました。

また、コア機能の利用頻度については、Yelpの例では「検索実行」「レビュー投稿」などの回数が監視対象に挙げられてました。ビジネス KPI はキャパシティプランニングにも直結するところなので、継続的に追うのは重要ですよね。

いまの現場でも運用コストについてはある程度可視化されているのですが(参考:re:dashでAWSのコストを分析してみた)、ビジネスに関する監視をもっと増やしてみたくなりました。

クラウドサービス前提の話はほとんどない

本書全体を通して、AWS や GCP に関する話はほとんどありませんでした。監視の基本は変わらないから、あえて触れていないのだろうと思います。

AWS などのクラウドサービスを使う場合、CloudWatch のようなビルトインの監視サービスが使えることと、ネットワークが抽象化されているので本書の「ネットワーク監視」の範囲はあまり関係ない、というくらいでしょうか。

分散トレーシングの監視は難しい

マイクロサービスと分散トレーシングについては、7章「アプリケーション監視」のなかに含まれていました。本書の著者は、分散トレーシングは非常に時間と労力がかかるので、他の手段で監視できるならそちらを用いるべき、というスタンスでした。

分散トレーシングは、正しく実装するのは非常に難しく時間がかかる監視の仕組みであり、業界内の一部でだけ役に立つものです。分散トレーシングは根気がない人や、スタッフ不足だったり過労気味のエンジニアリングチームには向いていません。必要なメトリクスやログはすべて取得していて、それでも分散システムにおけるサービス間のパフォーマンスを把握したりトラブルシューティングをするのに困るようなら、分散トレーシングを使うべきかもしれません。(p.106)

確かに、Zipkin を導入するためのコスト(監視システム側の構築・運用の複雑化に加えて、アプリケーション開発者での配慮も必要になる)が、そこから得られるメリットに見合うかどうかは、場合によるだろうなあと思います……。

監視システムの開発・維持は本書の対象外

本書を読んでいると監視を改善するアイディアはいろいろ浮かびますが、一度監視項目を設定しても、サービスを開発・運用していると状況は色々変わって、実態に合わなくなるものです。この監視の仕組み、システムをどう開発・維持するかは本書の対象外で、そこから先に興味を持ったら DevOps や SRE の本に移るのが良さそうです。

ともあれ、いろいろ考え直すきっかけになる良書でした。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE Advent Calendar 2018 の個人的おすすめ記事(おまけ:Mackerel Drink Up の話)

12月は色々ありました。今回はそのへんを雑多に振り返る記事です。

SRE Advent Calendar 2018 の個人的おすすめ記事

SRE Advent Calendar 2018 は、スタディストのかつひささんが企画したアドベントカレンダーです。1個目のカレンダーがすぐ埋まってしまったので、2個目(SRE 2 Advent Calendar 2018)も作られてました。僕も11日目に投稿しました。

qiita.com

qiita.com

1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。

冬休みに入ったので、この機会に SRE Advent Calendar の記事を全部読み返して、個人的おすすめ記事をピックアップしてみました。どれも面白かったのですが、個人的にはいま SRE の組織体制に興味があるので、主にそのへんの記事に偏ってます。ご了承ください。

Day 10: DevOps文化の組織にSRE活動を導入した話

kusuwada.hatenablog.com

(記事を読み限りおそらく)過去5年かそれ以上の間に、

  • 開発チームとインフラチームが分離していた体制
  • 各開発チームにインフラメンバーを送り込む体制(DevOps 体制)
  • インフラメンバーを組織横断で繋ぐSREを導入した体制(SRE 体制)

と組織体制を見直してきた現場での、それぞれの体制のメリット・デメリットをまとめた記事です。

最新の体制は、SRE チームと開発チームを兼務する SRE と、SRE チーム兼任の SRE(Core メンバー)を組み合わせたもののようです。これは是非参考にしたいと思いました。

Day 14: プロダクト横断のSREチームを組成したい話

qiita.com

オプトの渋谷さんによる記事。

渋谷さんは SRE Lounge #5 で SRE チーム立ち上げについての話をされてました。この記事は、その今後の展開についての話で、SRE が複数のプロダクトチームを横断して活動するように変えていきたいという構想についてのものです。

記事の最後の方にある「乗り越えるべき壁」のところは、僕もよくわかる悩みで……特に、プロダクトをまたぐことで「一人のSREが知るべき内容はすごく多岐に渡ってしまいそう」という点は、実際やってみた結果を是非お聞きしたいです。

ちなみに、

SREのマトリックス的な配置についてはヌーラボさんの取り組みを参考にしています

とのことで、参考にしてもらえて嬉しい!

Day 16: SLO設定/超過監視にまつわる活動の振り返り

www.m3tech.blog

エムスリーテックブログの記事。SLI の測定方法から、SLO 超過時のプロセスまで、具体的なユースケースが詳細にまとめられた良記事です。

SLO を超過したかどうかの検知から、超過した場合のチケット作成まで自動化されており、これから SLO を導入しようという人は必読かと思います。あと、elastalert(Elasticsearch にクエリ投げて結果によって通知するツール)については僕も知らなかったので、今度使ってみます……。

Day 4 (SRE 2): データ基盤をHadoopからBigQueryに移管するときのアンチパターン

yuzutas0.hatenablog.com

Hadoop のようなデータ基盤を持つサービスで、SRE が果たすべき役割に関する記事です。

この記事では、データを処理するフローの途中で組織が分かれていたために、データの欠損や不整合が発生してしまった自社事例を紹介しています。

各組織が「自分の見える範囲で手っ取り早く済ませよう」とした結果、そうなってしまったようです。ソフトウェア開発じゃなくて、データ基盤の開発でも「コンウェイの法則」が出てくることあるんですね……。

最終的に、このような問題を解決するには「プロダクト」と「分析」の間を取り持つ DataOps ロールが必要で、そのロールはシステム全体を最適化する部隊(つまり SRE)が担うべきと結論づけています。

Day 24: SRE風のインフラエンジニアにならないために

kenjiszk.hatenablog.com

はてブでバズってた記事。SREがどういうものかを知ってほしいときには、まずこのページを読んでもらおう!と思ったくらい、説明が必要十分で読みやすい記事でした。

ちなみに、この記事の分類に従うと、僕の今年の仕事は「インフラエンジニアではなくSREとしてどう高速リリースを実現するか」のところにずっと注力してました。CI の改善、リリースプロセスやリリース自動化ツールの改善、開発チームが監視に使えるツールの充実などなど……。

Day 25: [SRE Advent Calendar] SRE Advent Calendar 2018 を終えて

kths.hatenablog.com

企画者のかつひささんによるまとめ記事です。SRE Advent Calendar の全記事に一言コメントが付けられています。興味のある記事だけ読みたい人は、まずはここをざーっと読むのがいいかも。

ちなみに、この記事の最後に「@katsuhisa__的ベスト3」のコーナーがあって、そこで僕の書いた記事を1位に選んでくれていました。まったく予想してなかったのでびっくりしましたが、頑張って書いた甲斐がありました。ありがとうございます。

ヌーラボSREの吉澤さんのこちらの記事が、SRE Advent Calendar 2018 の@katsuhisa__ 的1位でした。

SREの文脈では、一般的に、SLI といえば、レイテンシやエラーレートを指すことが多いですが、この記事では、自社のチームの課題に焦点を当て、社内向けSLI を整備した話が書かれています。

私が登壇する資料では、度々「ウェブオペレーションは、技芸であり、科学ではない」( by 『ウェブオペレーション ―サイト運用管理の実践テクニック』 )という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。

また、それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。

SRE Advent Calendar 2018 に投稿した記事

で、この流れで僕が投稿した記事も紹介。SRE Advent Calendar 11日目の記事として、Backlog プロジェクトにて SRE メンバを中心に試してきたサービスレベル指標と、それぞれについて感じたメリット・デメリットをまとめました。

nulab-inc.com

9月の SRE Lounge #5 の講演では時間の都合で話せなかったネタがあって、年内にアウトプットするならこれがラストチャンスだ!と思って飛びついて、なんとか書き上げられました。結果的には、発表時間が1時間あっても足りなそうなくらいに分量が膨らみましたね……。

あまりにも泥臭すぎる内容だし、人によっては「この会社はレベルが低い」と思うのではないか……と思って、公開前には色々悩んで書いたり消したりしました。それでも最終的に公開したのは、SRE について考えるときには組織の話は外せないし、その具体的なケーススタディの価値は高い、と思うからでした。

SRE の組織体制は、この記事に書いたものが最終形ではなくて、来年以降も徐々に改善していくことになりそうです。半年〜1年後には、また新たな話ができると思います。

おまけ:Mackerel Drink Up の LT 発表

あと、この記事の公開日にちょうど Mackerel Drink Up #8 Tokyo というイベントがあり、Backlog での Mackerel 利用事例について発表しました。Advent Calendar の記事中にちらっと出てくる監視システムについて、もう少し詳しく話しています。

ゆううきさんが東京に来るということで講演を聞いて、色々お話もできてよかったんですが、その数日後に退職ブログが出てびっくりしました。

ゆううきさんが話していたことで、印象的だったのはこのあたりでした。

  • 書籍「Webオペレーション」には、運用は技芸で科学ではない、という趣旨の文がある。しかし、個人的にはむしろ、技芸から科学へ進んでいると思ってる。一例として、reliability engineeringという分野が生まれてきている。
  • チーム内に SRE がいると、Dev と Ops のトレードオフを取りやすい。チームが分かれているとそこがやりにくくなる(=変更速度が下がる)のでは。同じチームに SRE がいることで、開発者と SRE の間で、お互いに業務を融通できるようになった。
  • メルカリのアドベントカレンダーの記事にも、1つのチーム内で開発と運用に責任を持つという話があった(マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog)。いまのトレンドはその方向なのかも。

個人的に考えている SRE のあるべき姿と、ゆううきさんの話が近かったので、その点は勇気づけられました。運用が科学に進んでいる、という点は、僕はあまりそうは思わないのですが、そうであったら面白い、とも思うので、ゆううきさんの今後の活躍に注目したいと思います。

艦これアーケードイベント全5回分の攻略率・周回数の時系列データ(CSV)を公開しました

f:id:muziyoshiz:20170128164643p:plain

Admiral Stats とは?

僕は2016年9月から2年以上、艦これアーケードのプレイデータ管理ツール Admiral Stats を開発・運用しています。Twitter アカウントと、艦これアーケードをプレイ済みの SEGA ID を持っている人なら、誰でも使えるサービスです。

www.admiral-stats.com

このサービスを作った経緯などに興味のある方は、Admiral Stats カテゴリー から過去のブログ記事をどうぞ。

艦これアーケードの期間限定海域とその攻略率

この2年以上の間に、期間限定海域(約1〜2ヶ月だけプレイできる特別なステージ)が5回リリースされており、その5回すべてのプレイデータも溜まっています。各難易度の最終的な攻略率は、Admiral Stats 上で誰でも見られるようにしています。

例えば、これは最新の第5回イベントの攻略率です。最高難易度(甲)をクリアしたプレイヤー(提督)は、全体のうち49.6%いるというのがわかります。

イベント攻略率(AL作戦/MI作戦 Extra Operation)

過去5回のイベントすべての、「甲」難易度の攻略率だけ並べるとこんな感じ。

イベント名 前段作戦 後段作戦 Extra Operation 備考
第1回「敵艦隊前線泊地殴り込み」 56.3 % - - これは乙の攻略率(第1回は丙・乙のみ、作戦の区分なし)
第2回「南方海域強襲偵察!」 57.9 % 57.5 % - 第2回は前段・後段のみ
第3回「索敵機、発艦始め!」 72.4 % 72.1 % - 第3回は前段・後段のみ
第4回「決戦!鉄底海峡を抜けて!」 71.8 % 62.0 % 56.1 %
第5回「AL作戦/MI作戦」 66.9 % 65.7 % 49.6 %

ここから難易度の傾向がある程度わかります。例えば、第4回イベントは後半になればなるほど難しくなっている、第2〜3回と第5回イベントは前段と後段の難易度がほぼ同じらしい、等々。

SEGA 公式はこういうデータを公開していないので、(Admiral Stats という特殊なツールを使ってくれるヘビーユーザーに偏っている可能性が高いとはいえ)貴重なデータです。

イベント期間中の攻略率・周回数の時系列データを公開しました

こんな感じで、イベント終了時の最終的な攻略率は、Admiral Stats のイベント攻略率ページ 上で誰でも見られる状態にしていました。

ただ、この攻略率が、時間経過とともにどういう感じで上がってるかは公開してませんでした。例えば、最終的な攻略率が同じ60%でも、

  • 最初の1週間で攻略率が60%になって、イベント終了までそのまま横ばい
  • 最初の1週間で攻略率40%、そこからじわじわと攻略率が上がって終了時に60%

では、後者のほうが難易度が高かったと言えそうですよね。

Admiral Stats 上でそういうグラフを見られるようにしようかと思ったんですが、そこまで実装する時間がなかなか取れなかったのと、どういう切り口でグラフを書いたら面白いか思いつきませんでした。

なので、今回、イベント攻略率・周回数に関する統計情報を CSV ファイルとして公開しました。ぜひ自由にいろいろ集計して、面白い結果が出たら Twitter やブログで紹介してください!

gist.github.com

なお、イベント開始から、Admiral Stats での対応までに時間がかかったために、最初の数日間のデータが欠けているイベントもあります。そのへんは非公式ツールの限界ということでご容赦ください。

この CSV ファイル内の統計値の詳しい計算方法が気になる方は、こちらのコード(↓)をどうぞ。

CSV ファイル作成バッチのソースコード

具体例:この CSV ファイルからこういうグラフを描けます

Admiral Stats にプレイデータを登録した人の数は、イベント開始時から終了時に向けて徐々に増えていきます。このプレイデータ登録者数と、攻略率の推移を比べてみましょう。

第1回イベントで、プレイデータ登録者数と、乙難易度(第1回での最高難易度)の攻略率を比べるとこうなります。

f:id:muziyoshiz:20181129211937p:plain

一方、最新の第5回イベントで、プレイデータ登録者数と、甲難易度の攻略率を比べたものはこちら。

f:id:muziyoshiz:20181129211959p:plain

この棒グラフの傾きが緩やかだと、クリアまでに時間がかかった提督が多い、つまり難易度が高いと言えそうです。そう考えると、

  • 第1回イベントは開始1週間程度で最終的な攻略率まで上がったので、難易度が低かったかも?
  • 第5回イベントはEOが一番簡単で前段が一番難しかったのかも?

といったことがわかります。そこから掘り下げて、でも第5回イベントでEOの最終的な攻略率が49.6 %と低かったのはなぜ…?とか考察していくと面白そうです。

この CSV ファイルには、1回クリアした提督が、同じ難易度を周回した回数のデータも入っています。攻略率に加えて、周回数でもグラフを描いてみると面白い結果が出ると思います。ぜひお試しください!

ボルダリングジム Rocky がリリースした新アプリ「サテライトロッキー」がすごい!

f:id:muziyoshiz:20181027214926p:plain

去年の8月に同僚から誘われてボルダリングを始めて、いまは週2でジムに行くくらいハマっています。具体的に言うと、無意識にこんなこと言い出してしまうくらいハマってます。

一応IT業界の人間なので、ボルダリングをもっと楽しむのに使えるサービスやアプリって無いのかな……と色々探してるんですが、意外といいのがありません。

そんな中、今月の10日に「Rocky」というボルダリングジムが、「サテライトロッキー」というアプリをリリースしました。このアプリはとても良くできていて、今後ボルダリングジムがこぞって提供し始めるような、デファクトになる可能性を秘めていると思います。

そこで今回は、ボルダリングにハマるとどういうサービスやアプリが欲しくなるかと、その観点から見て「サテライトロッキー」がどれくらいイケてるアプリなのか、をご紹介します。

ボルダリングとは?

ボルダリングを知らない人向けに、話の前提として簡単に説明します。

ボルダリングは、高さ5m前後の壁(屋内)や岩(屋外)を、予め決められたスタート地点からゴール地点まで登って、達成感を味わうスポーツです。細かいルールは色々ありますが、基本はそれだけのシンプルなスポーツです。

実際に体験してもらわないと面白さを伝えるのは難しいので、とりあえず1回、経験者と一緒にジムに行ってやってみてください。僕の知り合いの人なら、呼んでもらえればホイホイついていくのでぜひ行きましょう。

ボルダリングにハマると欲しくなるもの

ボルダリングにハマると、「もっと難易度の高い課題(※ボルダリング用語でコースのこと)を登りたい」と思う一方で、「最近あまりうまくなってない気がする」という壁にもぶつかるものです。

そうなると、だいたい以下の2つのニーズが出てきます。

  • うまい人がどうやってるのか知りたい
  • 自分の成長を記録したい

「サテライトロッキー」が出る以前に、いままで僕がどういうことを試してきたかを、一例として書いていきます。

うまい人がどうやってるのか知りたい

まずはちゃんと知識を得たい、ということで本を読み漁りました。自分で買ったり、会社の同僚(ボル部の部長)から借りたりして読んだなかで、特に参考になったのはこのあたり。

インドア・ボルダリング練習帖 (RS Books)

インドア・ボルダリング練習帖 (RS Books)

完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版

完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版

パフォーマンス・ロック・クライミング

パフォーマンス・ロック・クライミング

  • 作者: デイルゴダード,ウドノイマン,Dale Goddard,Udo Neumann,森尾直康
  • 出版社/メーカー: 山と溪谷社
  • 発売日: 1999/04/01
  • メディア: 単行本
  • 購入: 2人 クリック: 8回
  • この商品を含むブログ (4件) を見る

Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!

Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!

  • 作者: 中根穂高(ジャック中根),江崎善晴
  • 出版社/メーカー: 山と渓谷社
  • 発売日: 2018/01/11
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

しかし、関連書籍はあまり多くないですし、一通り読み終わると「用語は覚えたけど、どういうときにどのムーブを使えばいいのかよくわからない」という状態になりました。

ブログやウェブサイトも探したのですが、初心者の役に立つようなものは山と溪谷社の CLIMBING-net くらい。じゃあ動画を、と思って YouTube で「ボルダリング 解説」などで検索しても、意外とあまり動画がありません。

ボルダリング関係のちょっと変わった動画サイトとして、OnlineObservation というサイトがあります。このサイトは、課題を3Dモデルで確認した上で、クリア動画も見られるのですが、作るのが手間だからか、動画数が少ないのが難点です。

最終的に「これは良い」と思ったのは、自分が行ったジムの名前で YouTube や Instagram を検索して、自分が登れなかった課題を登ってる動画を探す という方法でした。これなら、自分が一度トライしているのでどういう課題かわかるし、自分が登れなかった部分に絞って何回も再生したりできて、勉強になります。

自分がよく行くジムに行っているユーザーの YouTube チャンネルをチャンネル登録したり、Instagram でフォローするのも良いと思います。おかげで、最近は YouTube と Instagram がすっかりクライミング動画アプリになってしまいました……。

自分の成長を記録したい

うちの会社と1つ上の階の会社のメンバで「ボル部」を作って、毎週水曜に3〜5名でボルダリングジムに行ってます。お互いに動画を撮って Google Photo のアルバムで共有しているので、それが成長記録みたいな感じになっています。

ただ、そんなに常にお互いの動画を撮ってられないし(そんなことより登りたいし)、細かい成長度合いはよくわかりません。

そこで、最近になって自分のトレーニング内容を日誌に記録し始めました。これは書籍(「パフォーマンスロッククライミング」や「Jack中根のクライミング道場」)で推奨されていた方法です。主に以下のようなことを書いています。

  • 挑戦した課題の難易度や、その数
  • 完登した課題数
  • フラッシュした(1回で完登した)課題数
  • その日の体の調子

こういうのを記録する良いアプリがあればよかったんですが、結局普通の手帳に書いてます。

アプリ「サテライトロッキー」の機能とイケてるところ

そこで、今回の「サテライトロッキー」です。

「構想から開発、完成まで2年」と宣言するだけのことはある、よくできたアプリになっています。正直に言うと、アプリとしての使い勝手にはまだ改善の余地が多いのですが、Rocky というボルダリングジムのシステムと非常によく噛み合ってます。

公式サイトにも説明はあるのですが、僕の注目するポイントからも機能紹介します。

https://www.rockyclimbing.com/2018/09/20/satelliterocky-news/www.rockyclimbing.com

機能1. 完登した課題を記録して、あとから写真込みで確認できる

ロッキーの店舗でサテライトロッキーを起動すると、自分が完登した課題を登録できる「チャレンジモード」に入れます。店舗にいるかは GPS で判定されます。このチャレンジモードで登録した結果は、あとからいつでもアプリで確認できます。

会員証代わりにアプリを提供しているボルダリングジムはたまにありますが、まずこんな記録機能自体がいままでに無いものです。ロッキーは、サテライトロッキーの提供以前から、すべての課題に対して、難易度順に一意な番号を振っています。そのシステムが元からあるからこそできる。これは結構すごいことです。

f:id:muziyoshiz:20181027215553j:plain:w640

それに加えて、完登した際に、それがフラッシュかどうかも記録できます(フラッシュの場合はカミナリのアイコンが表示されます)。フラッシュかどうかをクライマーは重視するので、そのあたりわかってる人がアプリ開発してるの良いですね。

f:id:muziyoshiz:20181027220030j:plain:w320

さらに、ここから課題番号を選ぶと、なんとその課題の写真も見られます。いままでは気になる課題を自分で撮影したりしてましたけど、その手間もなくなるなんて……。この画像の用意はさぞかし大変だろうと思いますが、ここまで徹底すると他のジムには簡単に真似できない価値になってます。

f:id:muziyoshiz:20181027220059j:plain:w320

機能2. 全来店者でのランキングを確認できる

先ほど書いた通り、ロッキーではすべての課題に対して、難易度順に一意な番号を振っています。自分が完登した課題の上位10個の合計値でランキングを競う「集大成」というシステムがあり、ランキングの集計結果が約2ヶ月に1回公開されています。

www.rockyclimbing.com

これと同じシステムがサテライトロッキーにも実装されています。違うのは、ランキングの集計が1日1回に変わったこと。

いままでは2ヶ月に1回の更新だったので、他のクライマーとのポイント差を意識するようなことはあまりありませんでした。しかし、頻度が上がったことで、自分と近いレベルの人(例えばよく一緒にジムに行ってる友達)との接戦を楽しんだりできそうです。

これは、アプリで新たに実装した機能というよりは、もともとロッキーというジムに存在していたシステムをアプリに導入したものです。この機能も、他のジムが真似しようとしたら、ジムのシステムから見直す必要があり、容易ではなさそうです。

f:id:muziyoshiz:20181027220748j:plain:w320

機能3. 他のクライマーをフレンド登録して、フレンドのチャレンジ結果も確認できる

最後に、このサテライトロッキーには SNS のようなフレンド機能があります。現状では、フレンド(フォローした相手)の完登記録を確認したり、次の来店予定日を共有できたりするようです。

サテライトロッキーの開発側は、グレードの高いクライマーをみんながフォローするようになり、グレードが上がるほどフォロワーが増えてモチベーションが上がる、といったことを考えているのかもしれません。

僕のような普通のクライマーにとっては現状ではフォロワーとフォロイーを一覧できる程度ですが、この機能も、発展させていけばかなり面白くなるんじゃないかと思っています。

f:id:muziyoshiz:20181027221254j:plain:w320f:id:muziyoshiz:20181027221305j:plain:w320

サテライトロッキーへの要望いろいろ

そんな感じで非常に良いサテライトロッキーなんですが、もっとこうだったら、という点もいくつかあります。

要望1. 挑戦したけど完登できなかった、という記録も残せるようにしてほしい

サテライトロッキーは「自分の成長を記録したい」というニーズをかなり満たしてくれているのですが、現時点では「挑戦したけど駄目だった」記録は残すことはできません。

ロッキーには半年以上通っていますが、3回目かの来店でやっと完登できた課題や、2ヶ月以内に完登できずに壁を張り替えられてしまった課題なんかもありました。そのときの課題も、記録に残しておいてあとから見返せるとちょっと嬉しいです。

要望2. 課題から Youtube, Instagram 動画へのリンクを張れるようにしてほしい

上記のように記録機能は充実している一方で、「うまい人がどうやってるのか知りたい」というニーズはまだあまり満たしてくれません。

せっかく他のクライマーの完登記録を見る機能があるので、そこから一歩進んで「この課題の完登動画」へのリンクを登録できるようにしてほしいです。例えば、自分が完登した課題を選択したら、そこから Instagram に完登動画を登録できる、とか。

課題と動画を紐付けられれば、課題のページにその課題の完登動画をリストアップできるようになります。そうしたら、クリアできない課題があったらサテライトロッキーを開いて完登動画を見て再チャレンジ……ってことがその場ですぐできるはず。

あと、現在でもプロフィールに Instagram アカウントへのリンクを設定できるようになってますが、YouTube チャンネルへのリンクも設定できるといいんじゃないでしょうか。

要望3. フォロー関係を使って各種 SNS に投稿された動画を通知してほしい

要望2の延長で、もしフレンドが完登動画を登録したら、それを通知してもらえると嬉しいです。

今でも Instagram アカウントでフレンドを直接フォローしてしまえば、もちろん動画は見られます。ただ、Instagram にはクライミング関係以外にもいろいろ投稿するのが普通なので、クライミング動画を見たいときはサテライトロッキーを見る、という感じで使い分けられるといいんじゃないでしょうか。

まとめ

サテライトロッキーは、「自分の成長を記録したい」というクライマーのニーズを満たしてくれるアプリです。また、フレンド機能が今後発展していくと、「うまい人がどうやってるのか知りたい」というニーズまで満たしてくれる可能性も持っています。

この記事を読んでちょっとでも興味をもってくれたら、ぜひ以下の公式サイトからサテライトロッキーをインストールしてみてください。そして一緒にボルダリングしましょう!(ダイレクトな勧誘)