無印吉澤

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

Wiki のページ、[[タイトル]] から作るか、いきなり作るか?

f:id:muziyoshiz:20170827200124p:plain:w480

最近、職場で Wiki について話していて、Wiki のページの作り方は2通りあるよね、って話になりました。

  1. ページ本文のなかに [[タイトル]] と書いて保存し、あとからそのリンクを踏んで「タイトル」ページの作成画面を表示する
  2. いきなりページの新規作成画面を開いて、タイトルを記入する

僕はだいたい1番で作る方なんですが、毎回2番で作る、という人もいました。

そんなことがあって「僕の Wiki の使い方は普通じゃなかったのかな?」と思って調べてみたら、最近の Wiki の一部(Qiita:Team や esa.io)は 1番のようなページの作り方ができない んですね。

そうなのか!これは面白い!と思って、Wiki の歴史を遡って色々調べてみました。今回はそんなネタです。

Wiki ソフトウェアそれぞれのリンク記法

まず、Wiki の機能を持つソフトウェア(以下、Wiki ソフトウェア)について、その Wiki 内のページにリンクするための文法を調べてみました。僕が有名だと思うソフトウェアと、最近登場した国産のソフトを主に取り上げています。

登場時期 ソフトウェア名 記法 WikiName [[pagetitle]] その他
1994 WikiWikiWeb Yes
1999 UseModWiki Yes Yes
2000 YukiWiki Yes Yes
2001 PukiWiki Yes Yes
2002 MediaWiki Yes
2002 Tiki ((pagetitle))
2003 Hiki Yes Yes
2004 Trac Yes Yes [wiki:pagetitle]
2004 Confluence [pagetitle]
2006 Redmine Yes
2006 Backlog Markdown Yes (※)
2008 GitHub Markdown Yes (※)
2011 GitLab Markdown [text](pagetitle)
2013 Qiita:Team Markdown [text](url)(作成前にリンク不可)
2014 Crowi Markdown <pagetitle>
2015 esa Markdown [text](url)(作成前にリンク不可)
2015 DocBase Markdown [text](url)(作成前にリンク不可)
2016 Scrapbox [pagetitle]
2017 Kibela Markdown [text](url)(作成前にリンク不可)

(※) 相対パスで書けばリンク可能だが、[[pagetitle]] 記法と比べたメリットが無いので省略

以下、この表の読み方と補足事項です。

  • 「登場時期」列
    • ベータ版と正式版があるときは、正式版のリリース日を登場時期とした
    • 正確なリリース日がわからないものは、確認できた最も古いリリースの日付とした
  • 「記法」列
    • 最近は Markdown 記法(またはその独自拡張)が多いため、その場合は “Markdown” と記載した
    • Wiki ソフトウェアが複数の記法をサポートしている場合は、Markdown 記法での仕様のみ記載した
  • WikiName 列が “Yes”
    • ページ本文に CamelCase で単語を書くと、それが自動的に Wiki ページへのリンクになるもの
  • [[pagetitle]] 列が “Yes”
    • ページ本文に [[タイトル]] 形式で単語を書くと、それが自動的に Wiki ページへのリンクになるもの
  • 「その他」列
    • WikiName と [[タイトル]] 以外の文法を採用しているもの
    • ページ作成前にリンクを張れる Wiki ソフトウェアのほうが多いため、作成前にリンク不可のものはそのように明記した

[[タイトル]] 記法の歴史は古い

ウォード・カニンガムが最初に作成した Wiki(WikiWikiWeb)は、CamelCase で単語を書くと、自動的にその名前を持つページへのリンクになります。また、その名前を持つページがまだ作られていない場合は、CamelCase? のように末尾に ? が付いて、この ? がページの新規作成画面へのリンクになります。これは、他の読者に、新しいページの作成を促すための工夫だったようです。

WikiWikiWeb にはこの CamelCase の記法(WikiName とも呼ばれる)しか無かったのですが、これでは不便だということで、後発の UseModWiki で、初めて [[タイトル]] 記法が発明されました。

UseModWiki は、MediaWiki が開発される前に、Wikipedia で使われていた Wiki ソフトウェアです。History of wikis によると、この記法が発明されたのは、Wikipedia のユーザビリティを改善するためだった、とのことです。

This CamelCase convention was used by most wiki software for the first few years of wikis' existence. In 2001, the software UseModWiki, which at the time was in use on Wikipedia, switched to allow internal links to be done using standard spelling and double square bracket instead, in order to improve Wikipedia’s usability. This square bracket syntax has since become more of a default convention for internal links within wiki software in general.

WikiName のルールは日本語では不便すぎるので、YukiWiki や PukiWiki といった国産のソフトウェアが早々に [[タイトル]] 記法を採用したのは納得できます。

[[タイトル]] からページを作れない Wiki が増えている

Markdown が普及して以降、Markdown やその拡張の GitHub Flavored Markdown(GFM)を採用した Wiki が増えています。昔から存在する Wiki があとから Markdown を採用したパターンもあります。上記の表では Backlog がそのパターンです。

Markdown は Wiki を想定せずに作られたので、Wiki ページにリンクするための文法がありません。そのため、Wiki ソフトウェアごとに、Wiki で一般的な [[タイトル]] 記法を導入したり、Markdown のリンク記法を Wiki のために拡張したりしています。

その一方で、Qiita:Team や esa などの新しいソフトウェアの一部は、「ページの作成前にリンクを張る機能は不要」と割り切っているのか、そのような文法を用意していません。

どういうことか? 例えば esa で新しいページを作ると、URL は https://muziyoshiz.esa.io/posts/5 のようになります。従来の Wiki は URL にタイトルの一部が入っていましたが、この種の Wiki では連番が入るので、事前に予想はできません。そのため、リンクを張りたければ、ページを作ったあとで、[タイトル](/posts/数字) のように、Markdown の文法でリンクを書く必要があります。これはめんどい。

ただ、esa の場合は、この面倒さを減らすためにリンクのサジェスト機能を提供しています。# からテキストを書き始めると、同じチーム内の投稿へのリンクがサジェストされます。

f:id:muziyoshiz:20170827214108p:plain

そして投稿を選ぶと、以下のように Markdown 形式のリンクに置き換えられます。

f:id:muziyoshiz:20170827214121p:plain

esa の場合、テンプレートを元に階層化されたページを作れるので、ページ名はだいたい「日報/2017/08/28/masahiro_yoshizawa」のようになります。これを手入力するのは現実的じゃないですよね……。それも、[[タイトル]] に相当する記法がない理由の一つかもしれません。

まとめ

[[タイトル]] という記法は昔からあって、さらにその大本には WikiWikiWeb が持っていた「ページの新規作成を促す機能」があった、という話をしました。だから、[[タイトル]] のリンクを踏んで新しいページを作る、というのは昔からの Wiki の使い方、と言えるでしょう。

しかし、これはインターネット上で誰もが参加できるような Wiki では必要でも、企業内などに閉じた Wiki では不要な機能なのかもしれません。企業内ならテンプレートに従ってページを作る方が一般的で、それなら

  • テンプレートに従って、いきなりページを作る
  • 必要なリンクはあとから書き足す

という使い方を助けるほうがいいのでしょうか? こういう使い方が今後一般的になっていくのか、気にしてみたいと思います。

2017年9月3日追記:アンケートへのご協力ありがとうございました

この記事の公開後の1週間、9月3日までアンケートを公開していました。ご協力ありがとうございました。

結果は52:48で、まさかここまで接戦になるとは予想してませんでした……。25名の方が投票してくれたので、13:12、1票差ですね。もう少し投票数を集められるなら、次はその人が普段使ってる Wiki ソフトウェアとセットでアンケートを取ってみたいです。

あわせて読みたい

この調査中に見つけた History of wikis はかなり読み応えがあって面白いので、Wiki に興味があったら是非一読をおすすめします。個人的に面白かったのはこのあたりです。

  • フローからスタックへ、という話題は、1996年に WikiWikiWeb へ ThreadMode が実装されたころにすでに存在していた
  • WikiWikiWeb にカテゴリとトピック(今で言うタグのようなもの)の機能が提案されたことがあったが、カテゴリのみが採用された
  • 「Wiki の機能をメール、IM、SNS と結合しようとした試み」として Google Wave の話が載っている

https://en.wikipedia.org/wiki/History_of_wikisen.wikipedia.org

このブログで過去に書いた Wiki 関連記事もあわせてどうぞ。

muziyoshiz.hatenablog.com

muziyoshiz.hatenablog.com

趣味で作っているサービスを Rails 5.0 から Rails 5.1 へアップグレードする

f:id:muziyoshiz:20170724152414p:plain

最近、趣味で作っているサービス(Admiral Stats)を Rails 5.0.0.1 から 5.1.2 にアップグレードしました。サービスが小さいので、それほど苦戦するポイントは無かったのですが、調べたこと、やったことをメモしておきます。

調べたこと

とりあえず、関連しそうな情報に一通り目を通しました。

アップグレード方針

上記のページを見る限り、今回は移行対象のアプリが小さいこともあり、特に問題もなくアップグレードできそうでした。

まず、「application.secretsですべてのキーをシンボルとして読み込むようになった」はコード中の参照箇所を確認して、問題なし。JWT のエンコード、デコード時に Rails.application.secrets.secret_key_base と参照していましたが、これは Rails 5.1 でも動作しました。

秘密情報の暗号化は、元々 MySQL のパスワードなどは Apache から環境変数(SetEnv)で渡していたので、この方針を踏襲することにして変更せず。config/environments/production.rb で config.read_encrypted_secrets = false と書いておいて、今まで通りに secrets.yml を使います。

Yarn のサポート、Webpack のサポート、デフォルトでのjQuery依存の廃止、については、引き続き jQuery を使うことにして今回は気にしないことに。

あと、主キーのデフォルト型が BIGINT に変更に変更される件については、テーブル作成時期によって主キーの型が変わるのは混乱しそうなので、INT に統一することにしました。アップグレード時に必要な作業は特にないですが、テーブル作成時に id: integer を付ければ OK(以下はその例)。ただ、これはうっかり忘れることが多そうなので、generate model 時に必ず自動で付くようにしたい……。

class CreateBlueprintStatuses < ActiveRecord::Migration[5.1]
  def change
    create_table :blueprint_statuses, id: :integer do |t|

やったこと

Rails 5.0 系の最新版へのアップグレード、および関連 gem のアップグレード

まずは Gemfileのバージョンを更新。

- gem 'rails', '~> 5.0.0', '>= 5.0.0.1'
+ gem 'rails', '~> 5.0.0', '>= 5.0.4'

そして bundle update を実行。参考にしたページには bundle update rails を実行して rails 関係だけをアップグレードし、関連 gem は後回しにすべき、というアドバイスがあったのですが、すっかり忘れてました……。今回はそのまま続行。

最後に、動作確認のためにテストがある部分は rails test で確認し、ない部分は手作業で軽くポチポチ確認。

Rails 関係では特に問題ありませんでしたが、rack-cors が 0.4.1 から 1.0.0 に上がった影響で動作が少し変わっていて rails test が失敗。その部分のテストコードを修正しました。

あとは、Capistrano が 3.6.1 から 3.8.2 に変わった影響で、動かない部分と、Deprecation Notice が出る部分があったのでそこを修正。

  • Capfile の修正
- lock '3.6.1'
+ lock '3.8.2'
  • Capfile で Git SCM plugin のロードを明示
# Include default deployment tasks
require "capistrano/deploy"

# Future versions of Capistrano will not load the Git SCM plugin by default.
+ require "capistrano/scm/git"
+ install_plugin Capistrano::SCM::Git

Rails 5.1.2 へのアップグレード

先ほどと同じく、まずは Gemfile のバージョンを更新。

- gem 'rails', '~> 5.0.0', '>= 5.0.4'
+ gem 'rails', '~> 5.1.0', '>= 5.1.2'

次は bundle update を実行。関連 gem はアップグレード済みなので、今回は rails 関連の gem のみがアップグレードされました。

そして rails app:update を実行。bin 以下と config 以下のファイルが、新規作成されたり上書きされたりします。git で差分を見て、既存の設定を上書きしている部分以外は、基本的に採用しました。

  • bin/setup
    • bin/yarn の読み込みがコメントアウトされた状態で追加された。参考のために残した
  # Install JavaScript dependencies if using Yarn
  # system('bin/yarn')
  • bin/yarn (新規作成)
    • 今回は使わないが、呼び出し自体は上記の通りコメントアウトされているので残した
#!/usr/bin/env ruby
VENDOR_PATH = File.expand_path('..', __dir__)
Dir.chdir(VENDOR_PATH) do
  begin
    exec "yarnpkg #{ARGV.join(" ")}"
  rescue Errno::ENOENT
    $stderr.puts "Yarn executable was not detected in the system."
    $stderr.puts "Download Yarn at https://yarnpkg.com/en/docs/install"
    exit 1
  end
end
  • config/application.rb
    • 以下の行が追加された。確認のうえで残した
+    config.load_defaults 5.1
  • config/cable.yml
    • Redis PubSub で使う prefix が追加された。設定しても、この自作サービス(Admiral Stats)では使わないが、自動生成されたまま残した
+  channel_prefix: admiral_stats_production
  • config/puma.rb
    • ビルトインサーバの設定。コメントが変わっただけ
  • config/routes.rb
    • 単純に空にされるだけなので、上書きされたものをもとに戻した
  • config/secrets.yml
    • 環境変数から読み込む運用にしているので、そのままにした
  • config/environments/development.rb
    • Cache-Control の表記が分かりやすい表記に変わった(max-age の長さは同じ)ため、そのまま残した
-      'Cache-Control' => 'public, max-age=172800'
+      'Cache-Control' => "public, max-age=#{2.days.seconds.to_i}"
  • config/environments/production.rb
    • config.read_encrypted_secrets = true という行が追加されるが、これを false に変更した
  • config/initializers/assets.rb
    • 以下の行が追加された。Yarn は使っていないが、そのままにした
Rails.application.config.assets.paths << Rails.root.join('node_modules')
  • config/initializers/cors.rb
    • 基本的な設定が作成されたが、このファイルは元々作成済みだったため、元に戻した
  • config/initializers/new_framework_defaults_5_1.rb
    • 以下の内容で作成された。そのままにした。
# Be sure to restart your server when you modify this file.
#
# This file contains migration options to ease your Rails 5.1 upgrade.
#
# Once upgraded flip defaults one by one to migrate to the new default.
#
# Read the Guide for Upgrading Ruby on Rails for more info on each option.

# Make `form_with` generate non-remote forms.
Rails.application.config.action_view.form_with_generates_remote_forms = false

# Unknown asset fallback will return the path passed in when the given
# asset is not present in the asset pipeline.
# Rails.application.config.assets.unknown_asset_fallback = false

最後に、動作確認のためにテストがある部分は rails test で確認し、ない部分は手作業で軽くポチポチ確認して、リリースしました。

まとめ

5.0 から 5.1 へのアップグレードは、それほど詰まるところはありませんでした。アップグレードが溜まってると辛くなるので、早いうちにやっておいてよかったです。

ただ、当たり前の話ですが、アップグレード前にはちゃんとテストを整備しておかないとダメですね。今回のアップグレード対象は趣味のサービスで、テストより機能追加を優先してしまっていたので、今回のアップグレードはおっかなびっくりでした。なにか僕の気付いていない問題が見つかったら、報告頂けたら緊急で対応します……。

艦これアーケード第2回イベント「南方海域強襲偵察!」 プレイデータ解析 〜甲種勲章の十分条件は何だったのか?

f:id:muziyoshiz:20170128164643p:plain

はじめに

2017年4月26日から5月31日まで、艦これアーケードの第2回イベント「南方海域強襲偵察!」が開催されていました。普通の人にこういう話をすると「アーケードゲームにイベントがあるの?」と言われるんですが、最近のアーケードゲームはネット接続してるので、期間限定イベントとか普通らしいです。

艦これアーケードの場合は、イベント期間だけ新キャラを入手できたり、凶悪なボスキャラと戦えたりします。一番難しい難易度は甲乙丙の「甲」で、これをクリアすると「甲種勲章」というアイテムを入手できました。

僕は艦これアーケードのプレイヤー(提督)向けに、プレイデータ管理ツール Admiral Stats というサービスを提供していて、ここに各プレイヤーのイベント攻略状況も集まっています。今回は、このデータをもとに、「甲種勲章」を入手できた提督に共通する特徴を探ってみました。

艦これアーケードと Admiral Stats については、以前スライドにまとめたので、興味のある方はこちらをどうぞ。

第2回イベント「南方海域強襲偵察!」について

今回のイベントは、前段作戦と後段作戦に分かれていて、それぞれの作戦に甲乙丙の難易度がありました。簡単な難易度をクリアすると、より難しい難易度に挑戦できるようになっていて、具体的には下図のような制限がありました。

f:id:muziyoshiz:20170629225150p:plain

(※1周クリア=1周目の掃討戦に出撃していること)

一番の目玉だった「大和」は後段作戦でしか入手できず、そのためには前段作戦に挑戦する必要がある……ということで、約1ヶ月間かなりの提督がゲーセンに詰めかけてました。

ちなみに、後段作戦の甲は出現までが面倒なうえに、とてもクリアさせる気があるとは思えない極悪難易度でした(※個人の感想です)(※褒め言葉です)。

集計対象のプレイデータ

今回は、前段作戦95名、後段作戦80名分のプレイデータが集まりました。

集計対象の詳しい情報は、以下の通りです。

  • 集計対象とした提督
    • 第2回イベントに参加して、Admiral Stats に1回以上プレイデータをアップロードした提督
  • 集計対象としたプレイデータ(イベント進捗情報、艦娘一覧など)
    • イベント攻略率と艦娘カード入手率は、2017年6月8日3:00時点のプレイデータを集計
    • レベルや経験値については、イベント終了時刻になるべく近いプレイデータを集計
      • 2017年6月8日3:00までにアップロードされたプレイデータのうち、イベント終了時刻(2017年5月31日23:59)に一番近い時刻にアップロードされたプレイデータ

SEGA の本家サイトから、イベント進捗情報をエクスポートできなくなったのは6月8日でした。Admiral Stats は毎日2時にデータをバックアップしているので、今回は6月8日 3:00のバックアップを使って解析しました。

プレイデータの解析結果

イベント攻略率

前段作戦

前段作戦の甲難易度をクリアしたのは全提督の 57.9 % でした。前段作戦は、まだ救いのある難易度だったので、この高い割合もわからなくはないです。

f:id:muziyoshiz:20170630003300p:plain

また、甲難易度をクリアした提督のうち 56.4 % が、レアカード(甲種勲章がプリントされた艦娘カード)を求めて、2周以上クリアしていました。10周以上クリアした提督は 10.9 % です。

f:id:muziyoshiz:20170630003334p:plain

詳細:イベント攻略率(南方海域強襲偵察! 前段作戦) - Admiral Stats

後段作戦

後段作戦の甲難易度をクリアしたのは全提督の 57.5 % でした。前段作戦よりもかなり難しくなっているのに、割合は全然変わってないのが不思議です。前段作戦しかアップロードしていない提督がいることによる影響を考えても、この割合はかなり高いような……。

f:id:muziyoshiz:20170630003356p:plain

また、甲難易度をクリアした提督のうち 60.9 % が、2周以上クリアしていました。10周以上クリアした提督は 17.4 % です。後段作戦は大和入手のチャンスがあったので、こちらのほうが前段作戦よりも周回されていたようです。

f:id:muziyoshiz:20170630003434p:plain

詳細:イベント攻略率(南方海域強襲偵察! 後段作戦) - Admiral Stats

艦娘カード入手率

以下は、このイベントでの新艦娘を入手できた提督の割合です。ちなみに、自分でドロップしたカードだけでなく、買ったり借りたりして読み込んだカードも「入手」に含みます。これは、公式プレイヤーズサイトの仕様による制限です。

目玉だけあって、大和の入手率が他より 10 % 以上低かったのがわかります。また、前段・後段の両方で入手できた阿賀野と能代は、5 〜 7 % 高くなっています。

図鑑 No. 艦種 艦名 N Nホロ N中破
131 戦艦 大和 43.3 % 6.7 % 2.2 %
137 軽巡洋艦 阿賀野 65.6 % 8.9 % 4.4 %
138 軽巡洋艦 能代 62.2 % 8.9 % 3.3 %
139 軽巡洋艦 矢矧 57.8 % 6.7 % 5.6 %
140 軽巡洋艦 酒匂 58.9 % 4.4 % 2.2 %

また、Admiral Stats の方ではまだ表示できていないのですが、その他の限定カードの入手率は以下のようになりました。実際にプレイした感覚からすると、意外と高いな、という印象です。

図鑑 No. 艦種 艦名 限定カード
102 航空戦艦 伊勢改 32.2 %
103 航空戦艦 日向改 40.0 %

詳細:艦これアーケードの艦娘カード入手率(南方海域強襲偵察!) - Admiral Stats

艦隊司令部レベル、および経験値

ここから先は、Admiral Stats 上で表示していない(自動集計機能がまだない)集計結果の紹介です。

Admiral Stats で上記のイベント攻略率を公開した際に、「こんなツールを欲しがるのはやりこんでるプレイヤーだけなんだから、実際のプレイヤー全体よりも攻略率が大幅に高いのでは?(意訳)」という指摘がありました。

その点を検証するために、まずは、ステージのクリア回数とステージの難易度によって増える「艦隊司令部レベル」の分布を出しました。この結果によると、レベル90以上の提督は 49.47 % です。

艦隊司令部レベル 提督数 割合
0 以上 10 未満 3 3.16 %
10 以上 20 未満 1 1.05 %
20 以上 30 未満 2 2.11 %
30 以上 40 未満 5 5.26 %
40 以上 50 未満 5 5.26 %
50 以上 60 未満 10 10.53 %
60 以上 70 未満 7 7.37 %
70 以上 80 未満 7 7.37 %
80 以上 90 未満 8 8.42 %
90 以上 100 未満 28 29.47 %
100 以上 110 未満 18 18.95 %
110 1 1.05 %
総計 95 100.00 %

また、艦隊司令部レベルを経験値に換算したものが以下の表です。レベル99になるのに経験値が 1,000,000 必要なので、イベント参加提督の 33.69 % がレベル99以上ということになります。

経験値 提督数 割合
0 以上 100000 未満 14 14.74 %
100000 以上 200000 未満 14 14.74 %
200000 以上 300000 未満 8 8.42 %
300000 以上 400000 未満 6 6.32 %
400000 以上 500000 未満 6 6.32 %
500000 以上 600000 未満 3 3.16 %
600000 以上 700000 未満 6 6.32 %
700000 以上 800000 未満 3 3.16 %
800000 以上 900000 未満 3 3.16 %
900000 以上 1000000 未満 0 0.00 %
1000000 以上 2000000 未満 23 24.21 %
2000000 以上 3000000 未満 5 5.26 %
3000000 以上 4000000 未満 2 2.11 %
4000000 以上 5000000 未満 0 0.00 %
5000000 以上 6000000 未満 2 2.11 %
総計 95 100.00 %

Admiral Stats のユーザにはやりこみ勢が多い、という主張は、まあ正しそうですね……。とはいえ、そうでないユーザも居るので、甲難易度をクリアした提督と、そうでない提督の差を調べることはできそうです。

ちなみに、艦これアーケードのレベルアップに必要な経験値は、艦これ本家と同じと言われています。Admiral Stats では 艦これ攻略 Wiki の「経験値」ページ を参考に経験値を計算しています。

攻略度と艦隊司令部レベル/経験値の比較

では、艦隊司令部レベルがどれくらい高ければ後段作戦の甲をクリアできたのか? それを調べるために、攻略度と、艦隊司令部レベル/経験値を比較したのが以下の表です。

この結果によると、後段作戦の甲をクリアできた提督は、最低でもレベル63、平均レベル96.3でした。艦これの経験値テーブルはレベル90前後から急上昇するので、経験値の平均を取ると1121310.2で、これはレベル100相当です。平均が高すぎる……。

甲クリア提督を見てもやりこみ度が高すぎるので、乙クリア提督を見たほうが参考になるかもしれません。後段作戦の乙をクリアできた提督は、最低でもレベル41、平均レベル79.2。経験値の平均は427060.0で、レベル83相当でした。この間のどこかに境界がありそうですね。

前段作戦の攻略度と、艦隊司令部レベル

攻略度 提督数 最大 最小 平均 標準偏差
甲攻略済 55 110 63 95.4 9.9
乙攻略済 15 97 30 66.8 19.4
丙攻略済 15 78 26 49.5 15.0
未攻略 10 65 6 32.5 21.6
総計 95 110 6 77.0 27.2

前段作戦の攻略度と、艦隊司令部経験値

攻略度 提督数 最大 最小 平均 標準偏差 平均(レベル換算)
甲攻略済 55 5900000 203400 1264850.9 1070768.8 99
乙攻略済 15 761500 43500 296233.3 200063.1 73
丙攻略済 15 356200 32500 138513.3 89758.1 53
未攻略 10 219500 1500 75690.0 73349.5 39
総計 95 5900000 1500 808893.7 980487.1 97

後段作戦の攻略度と、艦隊司令部レベル

攻略度 提督数 最大 最小 平均 標準偏差
甲攻略済 46 110 63 96.3 9.9
乙攻略済 15 97 41 79.2 16.0
丙攻略済 14 75 26 49.5 15.5
未攻略 5 52 6 29.4 19.1
総計 80 110 6 80.7 25.4

後段作戦の攻略度と、艦隊司令部経験値

攻略度 提督数 最大 最小 平均 標準偏差 平均(レベル換算)
甲攻略済 46 5900000 203400 1360919.6 1121310.2 100
乙攻略済 15 761500 82000 427060.0 191149.6 83
丙攻略済 14 319000 32500 138964.3 88616.0 53
未攻略 5 132700 1500 60000.0 52672.3 35
総計 80 5900000 1500 890671.3 1020211.4 98

攻略度と艦娘の練度の比較

艦隊司令部レベルが低くても、特定の艦娘だけレベルを上げていればクリアは可能だったはずです。そこで、攻略度と、一定レベル以上の艦娘の数も比較してみました。

艦隊司令部レベルよりも、こちらのほうが、甲提督と乙提督の差が激しいですね。イベント開始時の全艦娘110隻をレベル99にしているようなやりこみ勢(凄すぎる……)が平均を上げています。

レベル70以上の艦娘数0で甲攻略済みの提督もいたので、低レベルでも攻略は可能だったみたいです。ただ、「高レベル艦娘を揃えていて、乙攻略済み以下」という提督はほとんどいないので、「レベルを上げれば物理で殴れた」とも言えそうです。

前段作戦

Lv50以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 6 32.4 24.8
乙攻略済 25 0 9.0 6.9
丙攻略済 8 0 2.9 2.9
未攻略 2 0 0.6 0.8
総計 114 0 20.7 23.6

Lv70以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 0 19.1 20.8
乙攻略済 8 0 2.3 2.5
丙攻略済 3 0 0.3 0.8
未攻略 0 0 0.0 0.0
総計 114 0 11.4 18.2

Lv90以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 10.6 18.7
乙攻略済 1 0 0.2 0.4
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 6.1 15.2

Lv99の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 5.6 16.0
乙攻略済 0 0 0.0 0.0
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 3.2 12.5

後段作戦

Lv50以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 6 34.8 25.6
乙攻略済 25 0 11.8 5.9
丙攻略済 8 0 3.4 2.7
未攻略 2 0 0.6 0.8
総計 114 0 22.9 24.2

Lv70以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 114 1 21.0 21.8
乙攻略済 8 0 3.7 2.3
丙攻略済 1 0 0.1 0.3
未攻略 0 0 0.0 0.0
総計 114 0 12.8 19.1

Lv90以上の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 12.0 20.1
乙攻略済 2 0 0.5 0.6
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 7.0 16.3

Lv99の艦娘数

攻略度 最大 最小 平均 標準偏差
甲攻略済 110 0 6.5 17.4
乙攻略済 1 0 0.1 0.2
丙攻略済 0 0 0.0 0.0
未攻略 0 0 0.0 0.0
総計 110 0 3.8 13.6

攻略度と雷巡改二(大井改二・北上改二)の所有数の比較

今回、特に後段作戦E-6は、雷巡の改二を持っているかいないかで難易度が大きく変わる、と言われていました(参考:南方海域強襲偵察! E-6 - 艦らぼ)。

そこで攻略度と、雷巡改二の所有数も比較してみました。以下の表の読み方ですが、2は大井改二と北上改二を両方持っている、1は片方のみ持っている、0はどちらも持っていない、という意味です。

こうしてみると、雷巡改二が1隻の場合と2隻の場合では、甲難易度の攻略率が大きく違うのがわかります。

前段作戦

攻略度 0 1 2 総計
甲攻略済 11.58% 8.42% 37.89% 57.89%
乙攻略済 6.32% 4.21% 5.26% 15.79%
丙攻略済 12.63% 2.11% 1.05% 15.79%
未攻略 10.53% 0.00% 0.00% 10.53%
総計 41.05% 14.74% 44.21% 100.00%

後段作戦

攻略度 0 1 2 総計
甲攻略済 10.00% 7.50% 40.00% 57.50%
乙攻略済 5.00% 5.00% 8.75% 18.75%
丙攻略済 13.75% 2.50% 1.25% 17.50%
未攻略 6.25% 0.00% 0.00% 6.25%
総計 35.00% 15.00% 50.00% 100.00%

雷巡改二(大井改二・北上改二)の所有数と、艦隊司令部経験値の比較

しかし、レアカードを持っているのはやりこんでいるからで、攻略度に直接影響しているのはやりこみ度の方なのでは?とも考えられます。

そこで、雷巡改二の所有数と艦隊司令部経験値と比較した結果は以下の通りです。やりこみ勢は雷巡改二を両方とも持っていることが多いが、片方だけ持っている提督とどちらも持っていない提督の差はそれほど無いことがわかりました。

大北改二の所有数 提督数 最大 最小 平均 標準偏差
2 42 5900000 174700 1378459.5 1194011.3
1 14 1300000 43500 481650.0 362335.6
0 39 1600000 1500 312987.2 354371.6
総計 95 5900000 1500 808893.7 980487.1

うーん、このデータからは甲難易度クリアの十分条件はよくわからないですね。

雷巡改二の所有数、艦隊司令部レベル、攻略度の比較

これだと消化不良なので、最後に雷巡改二の所有数、艦隊司令部レベル、攻略度をすべて対比してみました。

表が大きくなったので、画像で貼り付けます。表中に「0+」とあるのは、0以上10未満と読んでください。レベル90台だけは詳細に表示しています。

こうやって眺めてみると、「艦隊司令部レベルが高ければ、雷巡改二がなくてもクリアできている」、従って「甲種勲章が欲しければとにかくやりこんでレベルを上げろ」というのが結論っぽいですね。

前段作戦

f:id:muziyoshiz:20170630004411p:plain

後段作戦

f:id:muziyoshiz:20170630004427p:plain

まとめ

今回は、Admiral Stats にアップロードされたプレイデータをもとに、後段作戦の甲難易度をクリアして甲種勲章をゲットするための十分条件を探ってみました。その結果、

  • 艦隊司令部レベルが一定以上になるくらい、やりこんでいれば甲クリアできた
  • 雷巡改二を2隻とも持っていると甲クリア率が上がるが、艦隊司令部レベルの方が寄与が大きかった
  • 逆に、雷巡改二を2隻持っているだけでは、甲クリアに十分ではなかった
  • 艦娘のレベルが低くても甲クリア可能だったが、艦娘のレベルが一定以上なら確実に甲クリアできた
  • Admiral Stats のユーザはやっぱりやりこみ勢が多かった

といったことがわかりました。

もう少し分析方法を工夫したり、プレイデータをアップロードしてくれる提督が多くなれば(やりこみ勢に偏っていなければ)、甲種勲章をゲットできる・できないの差がもっと正確にわかるかもしれません。

第3回イベント以降も同じようにプレイデータ解析してみるつもりなので、こういうデータを面白いと思う艦アケ提督はぜひ Admiral Stats を使ってみてください。

www.admiral-stats.com

職場ブログに書いた記事まとめ

2017年9月追記:
私は2017年7月末をもって GMO インターネットを退職しました。これは2017年5月31日当時の情報です。

2015年1月に現職についてから、職場のブログに色々と記事を書いてきました。四半期に1回のペースで、それなりにまとまった内容を書くことを心がけてます。

グループ会社のブログに寄稿することもあって、自分でもどこに何を書いたか思い出せなくなってきたので、自分のブログにまとめておきます。今後、記事が増えたらここに追記します。

DevOps

DevOps 関係の話題は継続的に追っていて、職場でも隙を窺ってツールを導入したりしています。新しいツールの話題に加えて、職場ブログでは(許可を得た上で)個人ブログではなかなか書けない泥臭い話題も書いています。

Embulk

recruit.gmo.jp

recruit.gmo.jp

recruit.gmo.jp

HashiCorp

recruit.gmo.jp

Habitat

recruit.gmo.jp

Ansible

recruit.gmo.jp

recruit.gmo.jp

プログラミング

関数型言語の苦手意識を克服したくて、Elixir を触って記事を書いたりしました。ブログのネタにはしていませんが、最近は Scala も勉強中(何度目かの勉強中)です。

Elixir

recruit.gmo.jp

recruit.gmo.jp

自社サービスの API

recruit.gmo.jp

recruit.gmo.jp

その他(API 設計、Hadoop)

グループ会社の Tech Blog に書いた記事です。Hadoop は業務でもかなり触っているのですが、職場にもっと詳しい Hadoop おじさんがいるので、記事にすることがあんまりなくて……。

techblog.gmo-ap.jp

techblog.gmo-ap.jp