2017年8月24日木曜日

「ぶたもり2D」アプリサポートページ

icon

概要

このページは「ぶたもり2D」アプリのサポートページです
機能改善、バグ報告、各種問い合わせはこちらのコメントまたは Twitter にてご連絡お願いします

アプリ

iOS 版・・・http://apple.co/2wGgBl5
Android 版・・・提供なし

攻略動画

Youtube で攻略動画を公開しました

他のステージの攻略動画もあります
ぶたもり2D 攻略動画

リリースノート

v1.7

初級、中級、上級ステージを 9 つまで増やしました
コイン制度を導入しました
コインで交換できるアイテムを 3 つ (タイトルレインボー、ログイン、称号) を解放しました
またリファクタリングしました

v1.6

超上級を解放しました
初級、中級のステージを追加しました
コイン制度を導入しました
リファクタリングしました (xcode9 対応)

v1.5

iOS8 以上の端末で動作するように対応しました
タップ時のぶたを落下させる挙動を調整しました

v1.4

ボーナス一覧画面で回数が正しく表示されないバグを修正しました
遊び方からプライのお手本動画を表示できるようにしました
インタースティシャル広告をぶっこみました

v1.3

上級ステージを追加しました
ログインボーナスの要素を追加しました (ストック機能)
※ボーナス一覧で「ストック機能」の達成回数が 7 日になっていますが正しくは「14」の間違いです
実際は 14 回ログイン後に解放されます
次バージョンにて修正予定です

v1.2

データの保存方法を UserDefaults から Realm を使うように変更しました
これでアプリをバージョンアップした際にデータがクリアされないようになりました
タイトルにログインボーナス一覧へのツールチップを配置しました

v1.1

ログインボーナス機能を追加しました
物理エンジンのチューニングを行いました
App プレビューを更新しました
Firebase/Analytics を導入させていただきました

がこのバージョンにアップデートするとスコアが 0 にクリアされてしまうバグが確認されています
現在修正中で次のバージョンからデータがクリアされなくなるため、現在のバージョンでプレイしたデータも次のバージョンにアップデートしたときにクリアされてしまいます
申し訳ございません

v1.0

リリースしました
ステージは中級まで遊べます

2017年8月10日木曜日

Firebase のリアルタイムデータベース + iOS で「could not cast value of type __NSArrayM」が発生した

P.S 2017/08/15

公式に質問したところ回答をいただいたので記載します
日本語で質問したんですが、日本語で丁寧に回答いただきました (ありがとうがございます)
一応回答をブログで公開して良いという了承も得ています
結論としてどうやら今回の現象は仕様のようです

開発ご担当者様

お世話になっております。

> リアルタイムデータベースで json 情報を登録する際にキーが数字の json を登録しました 
> コンソール上では問題なく数値のキーとして登録されているのですが、コンソールから json をエクスポートすると null の配列としてエクスポートされてしまいました 
> この現象がバグなのか仕様なのかを知りたいです 

こちらの現象は仕様となります。
キーに文字列が含まれている場合、JSONで返却されます。
数字キーの半分以下に対して、数値が有る場合、ArrayではなくJSONで返却されます。
数字キーの半分以上に対して、数値が有る場合、Arrayで返却さます。

以下に例を記載致します。
例:(screen1.png)
Rand5の中に、登録されているキーは 1,2,5 となっています。最大の数字は 5 であり、すべてのキーは0,1,2,3,4,5(6個)になります。半分のキー(3/6)が登録されているため、Arrayで返却されます。
Rand6の中に、登録されているキーは 1,2,6 となっています。最大の数字は 6 であり、すべてのキーは0,1,2,3,4,5,6(7個)になります。しかし、半分のキー(3/7)が登録されていないため、JSONで返却されます。

詳細資料は https://firebase.googleblog.com/2014/04/best-practices-arrays-in-firebase.html にご参照くださいますようお願い致します。

> In particular, if all of the keys are integers, and more than half of the keys between 0 and the maximum key in the object have non-empty values, then Fire> base will render it as an array. This latter part is important to keep in mind.

また、他にご質問ございますたらご連絡くださいますようお願い致します。
以上、よろしくお願い致します。

公式のブログで紹介していたんですね、、、
さすがにたどり着けませんでした

概要

Firebase のリアルタイムデータベースからデータを取得して Swift 上で処理しようとしたらタイトルのエラーが発生しました
結果的にプログラム側ではなく Firebase 側の挙動 (仕様?) がおかしいということが判明したので紹介します

環境

  • Firebase (2017/08/10 時点)
  • Xcode 8.3.3 (8E3004b)

Firebase の挙動がおかしい、、、

どういう挙動かというと本来インポートしたい json データが Firebase にインポートされると null として扱われてしまうという現象になります

実際に確認してみました
まず 2 つの json ファイルを用意します

  • cat success.json
{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "9" : [ "i" ],
        "20" : [ "" ]
}
  • cat fail.json
{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "9" : [ "i" ]
}

数字をキーに持つ単純な json ファイルです
値には配列で文字列を持っています

これを Firebase のコンソールからインポートしてみます

  • success.json

success.png

  • fail.json

fail.png

はい、コレだけ見るとどちらも予期したとおりにデータが入っています
ちゃんと数字のキーがありその中に配列情報が格納されています
Firebase では配列情報に自動でインデックスが振られるのは仕様です

で、ここからが問題なのですが、そのままコンソールでそれぞれの json をエクスポートしてみましょう
ここでエクスポートできる json は API で取得できる json のフォーマットと同じデータになります

するとなんと

  • cat success-export.json
{
  "5" : [ "a" ],
  "6" : [ "b", "c", "d" ],
  "7" : [ "e", "f", "g" ],
  "8" : [ "h" ],
  "9" : [ "i" ],
  "20" : [ "" ]
}
  • cat fail-export.json
[ null, null, null, null, null, [ "a" ], [ "b", "c", "d" ], [ "e", "f", "g" ], [ "h" ], [ "i" ] ]

fail-export.json になぞの null 文字が連なっています!
本当は success-export.json みたいにハッシュでキーが数値で値が配列でエクスポートしてほしいのですが、なぜか配列でかつ null が並んでいて、その後に値の配列が並んだ状態でエクスポートされてしまいます

当然 Swift で取得できる json も上記の null が並んだ json になってしまうのでタイトルの could not cast value of type __NSArrayM が発生していました
本来は NSDictionary で来ることを想定した書き方をしているため該当のエラーが発生します

これは仕様なのかバグなのか

success.json はキーの数字が 5 から 9 と並んだあとに 20 が来ています
fail.json はキーの数字が 5 から 9 と連番で並んでいます
おそらく連番で並んでいるというのが原因 (仕様 or バグ) だと思います

試しに 5 から 8 のあとに 10 を記載したら問題なく json のハッシュ形式でエクスポートできました

  • cat revised_fail.json
{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "10" : [ "i" ]
}

また、10 ではなく ab などの文字列でも問題なくエクスポートできました
Firebase ではインポートする際の json をリアルタイムデータベースに格納するために自動でフォーマットして格納します
おそらくその際のアルゴリズムで連番の場合には null 埋めするという謎の仕様がありそれに引っかかったんだと思います

ちょっと調べた感じだとその旨が記載されたドキュメントは見つかりませんでした
仕様ということであれば仕方ないので連番を使わないようにするか 05, 06 のように先頭を 0 埋めして登録するしかありません
バグということであれば是非改善してほしいなと思っています

そもそも数値をキーにするなという問題もありますが、、、

最後に

Firebase のリアルタイムデータベースの謎の挙動を追ってみました
おそらく仕様だと思います
が、知らないと完全にハマリます

問い合わせ窓口的なのがあれば問い合わせてみようかなと思っています
結果わからばコメントなどで追記しようかなと思っています

2017年6月27日火曜日

AWS SDK Ruby を使ってニフティクラウド DNS を操作してみた

概要

久しぶりの連投です
前回ニフティクラウド DNS に A レコードを追加してみました
アプリケーションで使う場合、手動で毎回 A レコードを登録するのは現実的ではありません
ニフティクラウド DNS の API は AWS の Route53 に互換してるらしいので AWS の Ruby SDK を使ってニフティクラウド DNS が制御できるか試してみました

環境

  • CentOS 7.3.1611
  • Ruby 2.3.3p222
  • aws-sdk-v1 1.67.0

事前作業

ニフティクラウド API のアクセスキーとシークレットキーを事前に取得しておいてください
あとはニフティクラウド DNS に適当にゾーン登録しておくと今回紹介する Ruby のサンプルも動くの良いかと思います

ライブラリインストール

執筆時現在 AWS の Ruby SDK には v1 と v2 があります
今回は v1 を使います
ちなみに v1 は duplicated になっているので、普通に AWS を使う場合は v2 を使ってください
また今回のコードは v2 との互換がないので v2 だと動作しないのでご注意ください

  • bundle init
  • vim Gemfile
gem "aws-sdk-v1"
  • bundle install –path vendor/bundle

グローバルにインストールしても良いですが今回はカレントにインストールします

書き換え

実はそのままでは使えません
ニフティクラウド DNS の API バージョンは 2012-12-12N2013-12-16 となっています
AWS の Route53 のバージョンは 2012-12-12 と 2013-04-01 がありますが、どちらもニフティクラウド DNS のバージョンとは異なります
当然 SDK も 2012-12-12N2013-12-16 のバージョンを受けることができないので、このバージョンを受けれるように修正する必要があります

  • vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/route_53/client.rb
class Client::V20121212N20131216 < Client
  define_client_methods('2012-12-12N2013-12-16')
end

で新しいバージョン用の class を作成します
このコードは行数が少ないので書き換えやすいと思います

  • cp vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12.yml vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12N2013-12-16.yml

次にバージョン用の API 定義ファイルを作成します
まず既存のファイルからコピーします
そしてファイルを開いて「2012-12-12」の部分を「2012-12-12N2013-12-16」にすべて置換します

  • vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12N2013-12-16.yml
    • %s/2012-12-12/2012-12-12N2013-12-16/

エンドポイントの部分もありますが、これも変更しておきましょう

route53.amazonaws.com -> dns.api.cloud.nifty.com

そして最後に Core のコードを書き換えます
名前からしてかなり行数が長いです
606 行目あたりにある operations メソッドを書き換えます

  • vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/core/client.rb
def operations(options = {})
  if name.match(/V\d{8}$/)
  then
    @operations ||= []
  elsif name.match(/V\d{8}N\d{8}$/)
  then
    @operations ||= []
  else
    client_class(options).operations
  end
end

elsif が追加されています
要するに「2012-12-12N2013-12-16」のフォーマットを受け付けるようにします
これを追加しないと無限ループが起き「stack level too deep (SystemStackError)」が発生します

これで書き換えは完了です
実際に使ってみます

サンプルスクリプト

  • vim dns.rb
require 'aws-sdk-v1'

AWS.config(
           :route_53 => {
             :endpoint => 'dns.api.cloud.nifty.com',
             :api_version => '2012-12-12N2013-12-16'
           },
           :access_key_id => 'your-niftycloud-access-key-id',
           :secret_access_key => 'your-niftycloud-secret-access-key'
)

r53 = AWS::Route53.new

hosted_zone = r53.hosted_zones.find {|z|
  p z.name
}

ゾーンの一覧を取得するスクリプトです

動作確認

  • bundle exec ruby dns.rb –path vendor/bundle/

で実行できます
成功すると登録してあるゾーンの一覧を取得することができます

あとは AWS の Ruby SDK のリファレンスを参考にレコードを登録する関数などを呼び出せば動作すると思います
http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/Route53.html
(と思ったんですが、hosted_zone.rrsets.create を実行してみたら Inappropriate XML でエラーになってしまいました、、、)

最後に

AWS SDK Ruby の v1 を使ってニフティクラウド DNS をコールしてみました
ゾーンの一覧の取得はできたんですが、レコードの登録でつまづきました
たぶん同じように SDK を修正すれば動くようになるとは思いますが、ちょっと辛そうな感じがするのでこれくらいにしておこうと思います

2017年6月26日月曜日

ニフティクラウド DNS にゾーン登録して A レコードで名前解決してみる

概要

適当なドメインを取得してそのドメインをニフティクラウド DNS のゾーンとして登録してみます
その後登録したゾーンに対して A レコードを登録してドメインから IP が引けるか試してみます
今回使用するドメインは無料で取得できるドメインにしました

環境

  • ニフティクラウド (2016/12/25 時点)
    • Region: east-1 (Zone: east-12)

ドメインの取得

ニフティクラウド DNS ではゾーンを登録をする際に認証処理があります
要するにそのドメインがちゃんと自分のものであるかどうかを判断します

今回は whois 認証という方式を使うのですがニフティクラウド DNS の whois 認証で使えるドメインは以下の通りとなっています
http://cloud.nifty.com/spec/dns/dns_zone.htm

ここに記載のドメイン以外で認証することはおそらくできないのでここに記載のドメインを取得してください
今回は無料で取得できる「.tk」ドメインを取得しました

もちろん無料のドメインではなく「お名前.com」などのドメインサービスで取得しても OK です

ネームサーバの登録

取得したドメインのネームサーバを設定します
大抵の場合は取得したドメインサービスの機能でネームサーバを設定することができます
ニフティクラウド DNS の場合認証用のネームサーバ 1 台とリゾルバの 2 台のネームサーバを登録します

niftycloud_dns1.png
※画面は自分が使っているドメインサービスのネームサーバの設定画面です

ここで入力しているネームサーバは次のゾーン登録の手順で表示されるので、それを入力します

ニフティクラウド DNS で認証を行いゾーン登録する

ニフクラコンパネにログインして DNS の画面に進みます

DNS ゾーン管理 -> DNS ゾーン登録

でゾーン名に今回取得したドメインを入力します
niftycloud_dns2.png

すると認証画面になります
ここでネームサーバ 3 台の情報が表示されるのでドメインサービス側の設定でネームサーバを設定してください
niftycloud_dns3.png

そして「認証処理を実行する」をクリックするのですが、DNS の伝搬に少し時間がかかるので待ちましょう
ボタンを押しても伝搬できていない場合は失敗するだけなので、何度もトライすれば OK です
自分の場合 5 分ほどかかりました

で認証が完了するとランダムの文字列が付与されたネームサーバは削除してくださいという旨が表示されるので削除してください
問題なくゾーン登録が出来ると一覧画面に表示されます
niftycloud_dns4.png

A レコードを登録してみる

試しにて自分のサーバをドメインで引けるようにしてみましょう
サーバは何でも OK ですがグローバル IP を持っているサーバが良いかなと思います
登録したドメインを選択し「レコード新規作成」を選択します
タイプを A にし必要な情報を入力していきます
niftycloud_dns5.png

ポリシーには「重み付け」と「フェイルオーバー」の機能がありますがとりあえず今回は 1 台なので特に設定しません
問題なければ確認してレコードを登録します

ニフティクラウド DNS の場合、ゾーン登録は無料です
が、レコード登録は有料で 500円/10レコードになっていました
そして 11 レコード目からの 10 レコードは更に料金が発生します
また、先ほど紹介したレコードのポリシー機能は各レコードを追加する毎に料金が発生するようです
http://cloud.nifty.com/price/ep.htm#dns

とりあえずレコードが登録できれば完成です

動作確認

登録したレコードで IP が引けるか確認してみましょう
かつ、ネームサーバがニフティクラウド DNS のものになっているか確認します
確認は Mac 上の dig コマンドを使っています
また、IP の部分は一部情報をマスクしています

  • dig test.free-registry.tk
; <<>> DiG 9.8.3-P1 <<>> test.free-registry.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;test.free-registry.tk.         IN      A

;; ANSWER SECTION:
test.free-registry.tk.  86400   IN      A       111.xxx.xxx.xxx

;; Query time: 182 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Mon Jun 26 12:15:19 2017
;; MSG SIZE  rcvd: 55

ANSWER SECTION の部分で登録した IP が引けているのがわかると思います

  • dig free-registry.tk NS
; <<>> DiG 9.8.3-P1 <<>> free-registry.tk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51457
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;free-registry.tk.              IN      NS

;; ANSWER SECTION:
free-registry.tk.       3600    IN      NS      cdns1.nifty.ad.jp.
free-registry.tk.       3600    IN      NS      cdns0.nifty.ad.jp.

;; Query time: 194 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Mon Jun 26 12:16:50 2017
;; MSG SIZE  rcvd: 85

ANSWER SECTION の部分でニフティクラウド DNS のネームサーバが表示されていることがわかると思います

最後に

ニフティクラウド DNS を使ってドメインから IP が引けるところまでやってみました
ゾーン登録をするのに認証処理が必要なのでハマるとしたらそこかなと思います

スペック表を見る限りレコード数に上限はないので、料金さえ払えば無限にレコードは登録できそうです
一応 API もあるのでこれを使えばプログラムからでもゾーンやレコード登録ができると思います

2017年5月5日金曜日

IT の現場における「カスタマイズ厨とデフォルティスト」について考えてみる

GW 何もやらないとまずいのでブログをポストしようかなと
タイトルのことを考えてみました
あくまでも個人的な意見なので異論、反論はあるかと思いますが、、

はじめに

(かなり長文なので読んでいただける場合はご注意ください)

まず一般的にこれらの言葉 (カスタマイズ厨とデフォルティスト) が普段から使われているとは思っていない
(というかこんな言葉は聞いたことがない)
なので、この記事内で定義することにする

まず「カスタマイズ厨」だが

カスタマイズ厨

  • 何でも自分が好きなようにカスタマイズする
  • 代表的なカスタマイズ対象にはキーボードやエディタ、キーバインドがある
  • カスタマイズすることで効率性を上げる

という感じとする
一方デフォルティストだが

デフォルティスト

  • 何もカスタマイズしない
  • 基本デフォルトの設定を頑張って使う
  • 「慣れ」を武器に効率性を上げる

とする

この記事ではこの 2 つのタイプについての長所と短所を様々なユースケースで考えてみる

そして初めに言っておきたいのはどちらも「正解」だということ
十人十色、それぞれの人にはそれぞれの考え方や、やり方が存在するものである

とは言えいろいろと考えさせられることがあったのでこの機会に考えをまとめて見ようと思った次第です

ユースケース

以下のケースでそれぞれの長所と短所を考えてみる

  • オフィス
  • 自宅 (プライベート空間)
  • リモートワーク
  • コスト

ちょっとコンテキストがバラバラだがいろいろな観点で見つめてみようという感じ

「オフィス」はオフィスです、所謂仕事中の状態
またもう少し具体化するとオフィスでは自席もありかつオープンスペース的な場所で仕事も可能とする

「自宅」はまさに自宅、普段家にいるときを想定している
仕事中とかではなく休日を過ごす空間にいるときを考える

「リモートワーク」はオフィス以外の場所で仕事をしているケースを想定している
例えば自宅で仕事をしたりコワーキングスペースで仕事をしたりカフェで仕事をしたりなど

「コスト」はちょっと観点を変えてお金や時間について考えてみようと思う

他にもユースケースや観点はあると思うが今回はこれらを対象にする

オフィス

基本的に毎日行くオフィスである
自席があることを想定しているので自分の机があり自分のイスもあるものとする
朝来たらまず直行する自席である

おそらく王道と思われるこのケース
正直このケースのみにしか該当しない場合には「カスタマイズ厨」一択だと思う
一択というかカスタマイズしまくっても何ら問題ないという感じだろうか
(ここで「問題」という表現をしているが自分は少なからずカスタマイズしすぎることに問題を感じている、そのあたりは別のユースケースも踏まえて後述しようと思う)

例えば自分がもっともタイプしやすいキーボードを持ってきてそれで作業してみよう
会社で支給された謎の PC よりかは数段作業効率があがると思う
また、マウスやモニタもそうだ
モニタは追加してデュアルモニタにすれば更に便利になるだろう

自分もかつて HHK を使っていた
静電キーボードはタイプ時に力もいらず押している感がすごいので、気持ちよくタイプできる
これらは所謂周辺機器のカスタマイズ

更にマシンがオフィスで 1 台だけであるならば好きなエディタやアプリをインストールしてカスタマイズしても良いと思う (というか当然すると思う)
設定ファイルをいじってゴリゴリにカスタマイズして自分しか操作できないような環境を作ることもできると思う
もちろん専用機なのだからそうしても問題ない

こんな感じでオフィス固定の場合は何ら問題なくカスタマイズすると思う (自分もそうするだろう、たぶん)

一方、デフォルティストだが、このユースケースでは正直カスタマイズ厨に勝てる点はないと思う
勝てる点がないというかメリットを得るチャンスを放棄しているという感じだろうか
(そもそもカスタマイズしないので放棄も何もないが)

ただ、一つカスタマイズ厨が効果を発揮できないシーンが会議や打ち合わせである
つまり PC を持ち運ばなければいけないシーンである

せっかく接続した接続機器をすべてはずして PC を持ち運ばなければならなくなる
最近だと Bluetooth を使った無線の周辺機器は増えているのでそれを使うことで物理的に外すという行為はショートカットできるが問題はそこではない
周辺機器がなくなることでデフォルトのキーボードを叩かなければならないことである

要するに今まで快適に作業できていた環境がなくなってしまうのである
これは痛い、急に生産効率が下がるのである
とは言え数十分の会議中だけなので、そこまで問題にはならないと思うが
もちろんベストなのはデフォルトのキーボードでもパシパシタイプできることだと思う

このままだとオフィスのところですべて書ききってしまいそうなので次にいく

自宅 (プライベート空間)

これも正直カスタマイズ厨のほうがいいと思う
いやむしろオフィスよりもカスタマイズ厨であることが良いと思う
オフィスの自席に比べてプライベート空間だと更に移動する機会が少ないためである

現に自分も自宅では Mac Book Pro をクラムシェルにして Bluetooth の Magic Keybord と適当なマウスを使って使っていたことがある
ディスプレイも 32 inch の大きいのを使えてかつ、周辺機器は全部無線なのでどこでもカスタマイズした環境で作業できるようにした
ただ、当初は喜んで使っていたが結局 Mac Book Pro 1 台を使いまわす生活に戻った

というのも他の周辺機器や HDD をマシンにつないだり、モニタを別のものマシンやデバイスで使いたい場合に差し替えたりするのが面倒になったからだ
Mac Book Pro にはモニタもキーボードもトラックパッドもデフォルトですべて付いているのである
新型 Magic keyboard のタイプ感が結構好きだったんだが、結局それもデフォルトのキーボードに慣れてしまえば全く不自由はなかった

ということで自分は自宅でもデフォルトの状態で Mac Book Pro を使っている
リビング以外の場所で作業したい場合は、それ 1 台を持ち運べばいいだけなので簡単だ
Mac Book Pro の場合はバッテリーも結構持つのでバッテリーも持ち運ぶ必要はないと思っている (なくなりそうな場合はバッテリーのあるリビングに戻ってきている)

リモートワーク

さて、少し視点を変えて考えてみたい
次はリモートワークという視点で考えてみる

先に言っておこう、もしあなたがリモートワークをしている、もしくはこれからリモートワークをするのであれば少しづつでもいいからデフォルトの環境に慣れておくことをオススメする

リモートワークの定義は様々だが簡単に説明すると「いつでもどこでも好きな場所で働くことができるワーキングスタイル」である
最近日本の企業でも Web 系を中心に取り組んでいる企業が多いと勝手に想像している

前提としてリモートワークを 100%、365 日やっているわけではなく 1 ヶ月に 4 回、週に 1, 2 回ほど出社することを前提に話を進める
もしくは週に 1, 2 度は自宅ではなくコワーキングスペースやカフェなどで働くことを前提に進める

個人的にリモートワークの良い点は「どこでも」かなと思っている
要するにインターネット環境とマシンが 1 台あれば「どこでも」仕事ができるのである
そんな素晴らしくシンプルな条件でありながらもしカスタマイズしまくっていたらどうなるだろうか
キーボード 1 つくらいなら問題ないかもしれないがそのうち移動するのが嫌になってくるだろう
せっかく「どこでも」仕事ができるのにそれを有効活用できなくなってくる

デフォルティストの場合はどうだろうか、基本的に周辺機器はなく PC を基本的に 1 台持ち運ぶだけなので、リモートワークのスタイルには適していると思う
また、(リモートワークとは少し関係ないかもしれないが) 環境が変わった時によくあるケースとしてマシンの配給があると思う
その際に自分なりのキッティングを必ず行う必要があると思うがその点についても触れておきたい

キッティング

環境によっては、オフィスで使用していたマシンをそのままリモートワークで使用できるケースもあると思うが、大抵の場合は専用のマシンを配給されると勝手に想像している
これはもしかしたらリモートワークに限った話ではないが要は新しいマシンを配給され、それをキッティング (セットアップ) する必要が出てくる
その場合に使い慣れていたマシンと同じ設定をまたやらないといけなくなる

最近だと Mac であれば Homebrew、Windows であれば Chocolatey などがあるのである程度簡単にはセットアップできるようにはなった
またそれらでカバーできない範囲や config 系のファイル (.emacs や .vimrc など) は git で管理しているのでそれを wget するだけというようにしている人もいると思う
が、それでも限界はある、ブラウザの設定や GUI 上で行う設定はどうしても手動でやる必要が出て来る

これは正直デフォルティストであってもある程度設定する作業は出てくると思う
大事なのはその時間をいかに短くするかだと思う
ほぼデフォルト設定でいい場合には設定やインストール作業も最小限で済むのですぐに別のマシンに移行できるのである
それがどうだろういろいろとカスタマイズしなければ全く作業にならない人だと中々マシンの移行ができず 1 ヶ月 -> 2 ヶ月 と過ぎ結局挫折してしまわないだろうか
これは非常によくない「習慣」だと自分は思っている

移行できず古い環境を使い続けると OS などのバージョンも古いバージョンを使い続けることになる
バージョンアップの大抵の目的は機能追加とセキュリティ強化だろう
macOS も半年から一年に一回はバージョンアップがある
そういったケースでバージョンアップできないほどカスタマイズしているとどんどん新しいバージョンを導入できなくなりセキュリティ的なリスクも高まったくるのである
もちろんセキュリティ以外の問題もあるとは思うが、要するにバージョンアップできない環境やマシンを移行できない環境を作るのは問題だと思う
(ただ、新しいマシンを積極的に導入することが一概に正しいということではないと補足しておく)

コスト

最後にコストについて考える
ここまでいろいろ話す中でコストについても話をしたのでほぼ話すことはないが要するに

  • デフォルティスト・・・セットアップ作業などにかかる時間は少なくかつ周辺機器なども必要としないため金銭的なコストもかからない
  • カスタマイズ厨・・・移行時のセットアップが大変、かつお気に入りのキーボードなど環境に数だけ必要になるため金銭的コストが大きい

となることがわかると思う
これについては想像通りだと思う

最後に

そろそろ疲れてきたので終わりとしたい

冒頭にも述べたが結局どちらが勝ち負けという話ではない
結局コーディングをする上ではタイプしやすい、ストレスなく長時間コーディングできる環境が必要だし、オペレーションではミスしない環境が必要になってくる
事務作業でもタイプが速いほうが仕事が早く終わるのでそれに越したことはない

結局どちらにしても安全かつ丁寧に、疲れず作業できる環境が整うのであればどちらでも良いということになると思う
リモートワークにしてもオフィスにしても結局仕事をする上でのゴールは同じである
なので、どこで仕事をしても最も効率的に仕事ができるのであれば、好きなところで働けば良いと思う
それがデフォルティストとカスタマイズ厨の話にもそのまま当てはまるのである

ただ、個人的な意見としてはデフォルティストのほうが良いと思っていて、その要因として実体験も踏まえると以下がデフォルティストのほうが良いと判断しているポイントである

  • PC 1 台あればどこでもベストなパフォーマンスが発揮できる
  • 移動が楽
  • 設定が楽
  • 最新マシンに交換できるチャンスがあれば真っ先に手を挙げることができる

かなと思う
自分はこれらに魅力を感じたがそうでない場合には別にデフォルティストになる必要はないと思う

そして、ちなみに自分は完全なデフォルトティストではなく「デフォルティストになりたいカスタマイズ厨」という感じかなと
最低限のエディタの設定はしたいし最低限のソフトウェアのインストールは絶対したい
が、その作業を限りなく最小限にしているので、どんなマシンに移行してもとりあえず短時間でセットアップできる
必要なソフトウェアだけインストール、設定されてできればすぐにベストなパフォーマンスで作業ができることを心掛けている

「断捨離」ではないが極力使わないものや無駄なもの・ことを排除する的な考えが個人的に好きなので、そういう意味でもデフォルティストよりなのかもしれない

2017年2月11日土曜日

DHH 先生の「強いチームはオフィスを捨てる」を今更ながら読みました

概要

2014 年ごろ出版された「強いチームはオフィスを捨てる」という本を読んだので、その感想を書いてみました
思うところをダラダラ書いただけなので、ストーリー順にまとまっているとかはありません

この記事では本のストーリーやあらすじについては触れません
あくまで本に記載されていたトピックや内容に対して自分の考えを言及するだけになっています
また、全てに対して言及しているわけではないです

なお自分が読んだのは日本語翻訳された以下の著書になります

環境

  • Kindle App on iPhone

コンテキストについて

まず大前提として以下のコンテキストがある

  • 海外の会社 (主にシリコンバレー) での話、日本の企業はおそらく対象に入っていない
  • 37signals という会社が行った経験談になっている

なので日本の企業を前提として読んでいると「おっ?」と思うところがあると思うがそれはコンテキストが違うので気にせず読むようにしてください

では以下から著書の内容について触れていきます
いきなり内容に触れているため基本的には著書を読んでいることが前提になります

会社が邪魔ということについて

会社にいると仕事ができない効率的ではないという表現が各所で使われているが、本質的には会社がいらないわけではない
別に会社で仕事しても問題ないと本書内でも言及している
結局、仕事をする上で場所は問題ないというのが答えだと思う
好きな場所で好きな環境で仕事したほうが誘惑もなく効率的であるということだろう
この考えに関しては自分も大賛成である

通勤が無駄ということについて

会社絡みでもう一つ言及しているのが「通勤が無駄」ということである
確かに無駄だと思う
お金もかかるし通勤ラッシュで無題に体力は使うし良いことはほぼないと思う
ずっと座って通勤できる人はその 1, 2 時間の通勤時間で本を読みたいとか何か作業したいみたいなのもあるとは思うが、それもわざわざ通勤でやる必要はないと思う

お金の面でもう一つあるのがオフィスを縮退させるなどしてオフィスの維持にかけるお金を少なるすることができるとある
これはいきなりは難しいと思う、いろいろ手続きなどもかかると思う
自社ビルなど買ってしまった場合には「もったいないので」オフィスに来させるという考えで通勤させる会社もあると記載してあったが、そういった場合には別の会社にレントすれば良いと思う (これもいろいろ手続きは大変だと思うが)

オフィスの維持費の話は何とも言えないが通勤が無駄という考えについては大賛成である
実際、通勤ラッシュとかを目の当たりにすると辛いというか「大丈夫だろうか」と心配になる

会社に行かざるを得ない状況について

ただ、あえて歴史ある日本の企業の立場になって考えると (歴史ある日本の企業の立場の人間ではないが) 以下のような考え (縛り) もある

  • 会社のネットワークに接続しないとアクセスできないサーバや環境があり作業できない

さすがに VPN でオフィスのネットワークに接続できないという会社はないと思うが、大抵の場合 VPN での接続は緊急時用で常時接続することができない (ルールなどで)
なので、会社に行かざるを得ないという縛りがある人がほとんどだと思う
たぶんこの辺りのリモートをするための VPN 環境を整える費用や時間がないというのもリモートを導入できない理由の一つなのかもしれない

ちなみに著書内では VPN という言葉は (確か) 出てこず、すべてインターネット上のサービスを使っている
閲覧の権限やアクセスする IP などを絞ることで秘匿性を担保しているのだと思う
この辺りのセキュリティ問題も導入の障壁になっているのではと思う (セキュリティについては後述でも考察する)

対社外や緊急時のリモートについて上記

上記以外で会社に行かざるを得ない状況がある人は例えば「社外との打ち合わせが多い」「社内での他部署との打ち合わせが多い」「緊急時に顔を直接合わせて行う作業が多い」とかだろうか (これ以外にもあるかもしれないが)

著書内では社外の打ち合わせも基本リモートで行うとあった (メールと電話ベースだったかな)
とは言え対社外だと相手側の環境も考える必要があるので、そうなると会社の応接室で合わざるを得ない状況が発生すると思われる
もちろんそれも頑張れば解決できるが、頑張るコストを取るよりも直接あったほうが効率的だと思う
なので「社外との打ち合わせが多い」人はリモートするには難しいかもしれない (それでも毎日対社外の人に会うということはないので数日はできると思う)

それ以外の「社内での他部署との打ち合わせが多い」「緊急時に顔を直接合わせて行う作業が多い」に関しては正直会社に行かざるを得ない状況と言うには乏しい気がする
どちらも社内の人に対する情報共有ややり取りになるので、フランクに出来るしチャットがあれば正直事足りる
よく運用・サービス障害時に 1 つの画面をみんなで後ろから覗く光景を見るが、それは無駄だと思う
みんなでキーボード叩いて作業して解決し、共有はチャットでやったほうが効率が良いに決まっている

あえて、それだとまずい状況になりそうなのは作業の排他性かなと思う
リモートだと作業中の画面を共有するのが中々難しい
ツールはあるが、各人が各人の画面を作業しながら追うというのは非常に大変だと思う
なので、そういった場合に実は他の人がすでに作業していたことをまた別の人がやってしまい更に状況が悪化するということも起こる可能性がある
これもリモート時のコミュニケーションの仕方やうまさでどうにでもなるとは思うが組織の文化や風習によっては、例外もあるということである

リモートの向き不向き

上記に補足する流れでこの内容にも触れておきます
著書内で基本リモートはどんな職種のどんな人でもできるというニュアンスで述べられていますが自分はそれについては半分賛成、半分反対でした

究極的にはどんな人でもできると思いますが、そこに至るまでのプロセスは職種や業務によって様々だと思います
そのプロセスにかかるコストが多ければ大きいほど自分は向いてない職種だと思います
もちろんどんな職種でもリモートをするまでにコストはかかると思いますが、超頑張らなければリモートできないのであればやらないほうが良いと思います
というのもそういう職種や業務、組織にいる人は、そもそもリモートに積極的ではないと思います
現状に満足しているとか面倒とかいろいろと理由はありますが、そういうリモートにマイナスな考えを持っている人たちが頑張っても結局途中で挫折してしまうだけだと思います
挫折しちゃうと結局それが無駄になるので、であればやらないほうが良いかなと思います

そんな環境でもあなたはどうしてもリモートをやりたいのであれば、その職種や業務、組織ではなく別のところに転職するほうがずっと簡単だと思います
(これは確か著書内でも述べられていたような気がします)

時間的制約について

著書の中でリモートをやる上でコアタイムは決めたほうが良いという指摘があります
ただ、一方で自由な時間に働こうという指摘もあります
両者は矛盾しているように思えますが、自分的に理解したのは最低限のコアタイムを設けてそれ以外は自由な時間で働こうという意味なのかなと思います
これに関しては半分賛成、半分反対です

コアタイム自体は悪いことではないですが、厳しく設けてしまうとそこでリモートの良さというか自由に働くことの良さが失われてしまう気がします
なので極力設けないほうが自分は良いかなと思います
これはリモートする人の職種と業種によると思います
コアタイムのメリットはその時間に必ず全員が仕事をしているという保証があるためリアルタイムにやり取りすることができるということです
単純に言えば質問や相談、レビューの回答がリアルタイムに返ってくるということです
もちろんそれに越したことはないと思いますが、著書内でも述べていますがそういうケースの業務はそう多くないはずです
多くないというか実はリアルタイム性はそれほど必要ではなく実は 1 日あとでも 1 週間あとでも特に問題ない質問が多いはずということです
というのを考えると必ずコアタイムを設ける必要はなく必要な人たちだけが設ければ良いかなと自分は思います

逆にいうとワールドワイドにサービス展開している会社では世界各地にリモートワーカーを雇いタイムゾーンの違いを設けることで 365 日誰かが対応できる環境にしています
わざわざ夜中に起きて障害対応する必要がなくなるというメリットはサービス運用者やサポート窓口業務の人に取ってはかなり嬉しいことだと思います
タイムゾーンが一緒でも病院等では夜勤というシステムがあるように、そういうシステムとリモートを組み合わせればいつでも誰かが対応することは実現できると思います (ちょっと無理矢理な感もしますが極論可能だと思います)

場所について

著書内では「まずは近場から」-> 「慣れたらどこでも OK」という感じで紹介していますが基本は自宅で良いと思います
旅をしたい人は海外で。とかありますが、そこまでやりたい人は少ないと思います
また大前提としてどこのネットワークから接続しても仕事ができるという前提があるため、そうなっていない場合にはそもそも海外にはいけません (そうなっていない場合にはそもそもリモートワークではないと思いますが)
モバイルネットワーク (例えば WiMAX2) とかを使っている人は自宅以外のカフェやコワーキングスペースであれば特に問題なく仕事できると思いますが電波が届かない山奥や海沿いでは厳しいかもしれません
もちろんそういった場所に備え付けのネットワークがあればそれを代用できますが、ない場合には結局自分で準備しなければならないので大変です

ただ、この「場所」については実はリモートをする上では結構重要な要素だと思っています
本当にネットワークと PC さえあれば仕事ができる環境ができていれば例えば大災害が起きたとき出社できないような状態になったときでも仕事をすることができます
そんな緊急時に仕事かよ!と思う人もいるかと思いますが、例えば携帯の回線事業者やインフラ事業者はむしろそういうときにこそ安定したネットワークを提供する必要が出てきます
また、連絡を行う LINE や Facebook のインフラエンジニアもそういったときに問題なく動作させる必要が出てきます
そういった状況になったときに「出社しないと仕事できません」となってしまうと、そういった連絡手段が途絶えてしまいます
これはあくまでも一例ですが、いつでもどこでもネットワークさえあれば仕事ができるようになっていると、いざときに非常に役に立つと思っています

リモートワークの欠点について

この本の 95% はリモートワークを encourage する内容で残りの 5% が discourage する内容かなと思っています
その 5% の部分で以下の 2 つを指摘しています

  • 仲間と顔を合わせる機会がなくなる
  • 仕事モードの切り替えが難しい

1 つ目は正直どうでもいいかなと思います
著書内では人に会うことが重要だと述べている点がありますが自分はそこまで重要だとは思っていません
リモートワークしてわざわざ周りにいた会社の人がない環境を作ったのに意識的に会ったら意味がないと思うからです
ただ、意識的に会う必要がないだけで普通にしゃべったりするのは息抜きの観点から必要だと思っています

で、問題は 2 つ目で確かにこれはあると思います
所謂「やる気スイッチ」をちゃんと自分でコントロールできないとダメかなと思います
著書内でも言及しているのですが例えば服装を変えるとか、場所を変えるとかでやる気スイッチの ON/OFF をするのが良いという紹介がありました
まずは、そんな感じ仕事モードに入れるようにしても全然良いと思います

ただ、それだけだとちょっと微妙だと思っていて自分的には「その日にやるタスク、issue を洗い出して必ずそれを達成する」と決めるのが良いかなと思います
そうすることで使命感ではないですが必ずやらなければいけない状況になるので嫌でもスイッチが ON になります
もちろんそんなことしないでも ON にできるのが良いですが難しい人は試してみると良いかと思います

あとこれのメリットとしてはやることが明確になることです
人間何かするときにちゃんとゴールが決まっている方が動きやすいという心理があると思います
また、業務の進捗や共有をやりやすくなります
「この issue 終わりました」とペタった issue の URL を貼るだけでいいので楽チンです
この方法はリモート時だけでなく普通に会社にいるときも使えるので、やっておくとリモートになってもスムーズに業務に入ることができるかもしれません

ひらめきは会議室で生まれる?について

これは著書通りで賛成です
会議は本当に必要最低限だけで十分で、定例等の会議ではひらめきは生まれないと思います

オフィスにいないと、上司の監視下でないと仕事をサボるのではについて

これも著書通りで賛成です
オフィスにいても監視下であっても (自分の場合) 休むときは休むので関係ないと思います
極論どんだけ休んでもサボっても自分は良いと思っています
結局、その人に与えられたタスクをちゃんと消化してくれるのであれば何の問題もないと思います
もちろん、そういうのを悪く思う組織の文化や風習はあると思います

リモート時のセキュリティについて

「セキュリティを守るにはオフィスが必要?」の章になります
これに関しては反対ではないですが、動機づけとしては少し弱いかなという印象です
PC の暗号化はしておけば OK、あとはクラウドのセキュリティだ!という感じですが本当に暗号化しておくだけで OK なのか、クラウド側のサービスが漏洩したらどうするかという問題があります
イタチごっこのような気もするのでサービスを信頼するという性善説に基いていればそれで良いような気もしますが、この点においては確かにオフィスに PC があって外部に物理的に盗まれない仕組みがあったほうが確かにセキュアな気はします

著書の場合そもそも PC の暗号化とかしていないのにオフィスで守ってても仕方ないよね、盗まれたら終わりだよねという言及をしていますが、このご時世 PC の暗号化をしていないところはないと思うので、、、
会社によっては PC を持ち帰れないところも多いのでそういった意味ではそっちのほうがセキュアだと思います

もう少し言うとそもそも会社の PC に漏洩したらまずいデータを入れて置かなければ良いのだと思います(難しいかもしれませんが)
基本的には会社のファイルサーバやクラウド環境、コード管理システムにデータをアップロードしておき PC のローカルには使うときにだけそれのコピーを置いておきます
そして業務終了時コピーしたファイルを削除すれば重要なデータは PC 上に残らなくなります
例えばそういったものを実現した仕組みにシンクライアントという仕組みがあります
とは言え、毎日開発中のソースコードがローカルから消えるとなると、それはそれで効率的には良くないのでこれが完全な解決策ではないと思っています

社内に不公平が生まれるかについて

どちらとも言えないかなと思います
ただ、少なくとも不公正や不満が生まれないように、チームや組織単位で agree を取ってリモートスタートしたほうが良いと思います
特にリモートをやらない人からの agree は必ず取ったほうがいいと思います
チームや組織の中でリモートに反対する人が一人でもいる状態でスタートと、リモートしている人が悪者扱いされてしまう雰囲気になりがちです
なので、反対する人がリモートする人のことを agree した状態でスタートさせないと結果的に失敗することがありそうです

あとこれに関連して「誰が先陣を切って始めるか」となったときは勤続年数の長い人から始めるというのが著書にある
これは自分も賛成で、入社したばかりの若い人にいきなりリモートワークさせても、いろんな意味で辛いし仕事が回らないのでやめたほうが良いと思う

人に関していうと採用の話も著書で触れているが、どんな人がリモートに向いているかなど書かれているが個人的にはまずは普通に採用して業務してもらって、その後リモートにも参加してもらうスタンスでやったほうが良いと思う
いきなりリモート基準で採用するのもおかしな話だと思うので

進み具合を共有するについて

これはリモートでは確かに難しい要素の一つだと思います
特に進捗を可視化して見えるようにするのが難しいと思います
やることを完全に issue やチケット化しておりかつその issue やチケットの粒度が全く同じなのであれば、進捗を可視化し共有するのはそれほど難しくないと思います
そうなっていない場合に思いつくのが日報や週報といった文章で進捗を伝えることですが、これだと実はあまりよくありません
というのも結局文章だと文章力のある人が進捗があるように見せることができてしまうためです
もちろんやったことを正直に文章にするのは良いことですが、逆に文章力のない人は進捗があるように「見えない」のです
この「見えない」というのが非常に問題で、前述したように issue の数やチケット数のように数値を見える化していると簡単に見えるのですが文章だとそれが難しいのです

著書内では「話のわかる仲間に進み具合を披露するのは、けっこう気分のいいものじゃないか?」と書いてあるだけでその披露の具体的な方法が書かれていませんでした

ただ、結局は成果物がちゃんと出ていなければいくら進捗が良いように見えても意味がありません
というのを考えると実は進捗共有はそれほど重要ではないのかもしれません
とは言えチームビルディングをしているのであれば進捗を知りたくなるのは当然のことで、そうなると文章で進捗を伝えるのがとりあえずは一番良い手段になるのかもしれません

マネージメントについて

著書内ではリモートワークでのマネージメントの話にも触れている
正直読み流したので興味あれば見る程度で良いと思う

組織の文化や風習について

書いていく中でちょくちょく出てきている「文化と風習」について少し自分の考えを記載しておきます
どんな会社や組織にもルールはあると思います
そしてそのルールとは別に暗黙の了解的な位置づけとして「文化や風習」というものがあると思っています

言葉では表しにくいのですが例えば「攻めのスタイルではなく守りのスタイルでいく」みたいな雰囲気のようなものです

で、これはリモートを導入するにあったても重要な要素だと思っており文化や風習が根強い会社ほどリモートワークの導入が難しいと思っています
もう少し単純にいうと、ほとんどの社員が出社して仕事することに不満を持っていないのにリモートを導入しようとするのは難しいことだということです
この問題は非常に解決が難しく一筋縄ではいきません
これを無視してリモートワークを始めるとたぶん失敗すると思います

他には例えば、文化的に決められた休み時間内できっちり休むような会社だと例えリモートをしていても、その時間に休まなくてはという使命感に狩られます
(これは文化ではなくルールなのかもしれませんが、、、)

とかそういったものが、せっかくリモートワークで働きやすい環境を手に入れたのに縛りを設けてしまうので返って効率が上がらなくなる可能性があります
また、そういった文化や風習から外れる人間がいると組織というものはそういう人間を嫌う可能性があり挙句、見捨てられてしまうかもしれません
(かなり極論なのでそう起きることではないと思いますが)

とかとか、それが問題となって中々うまくいかないこともあるので注意が必要です
とは言えそういった問題をどう注意すればいいのかというのは正直自分もわかっていません
所謂空気を読んでリモートワークで仕事する感じになると思います
(周りの人のことを考えて、みんなが幸せになるようにことをしていけば基本は問題ないと思います)

運動不足について

これは大賛成です
というか本当に運動不足になりがちになります
一歩も家から出ないことが頻繁に起きるので意識的に運動する必要はあると思います
気分転換に運動するようにするといいと思います

そしてもう一つ体のことで言うとパンデミックの回避になります
たまーに会社にいるのがインフルエンザやノロウイルスなど空気で感染する病気をオフィスに持ってきてしまう人です
リモートワークであれば基本的に自宅で仕事してるのであれば、そういったリスクの回避にもなります
(コワーキングスペースやカフェに行く人は対策が必要ですが、、、)

その他

ちょくちょく自社のサービス「Basecamp」についての紹介がある

文章の前半と後半で矛盾するような点が出てくるが気がする

  • 会社は邪魔、行く必要ない -> 2 日くらいは出社しても良いだろう
  • 会議をなくそう、人から質問される邪魔をなくそう -> 直接あって交流しよう

など
どちらも正論を述べているので、解釈の問題だと思うのでそれほど気にしなくていいと思うがそういう記述が出てくる

後半はリモートが良いというよりかは働き方をこうした方が良いという内容が多い

最後に

「強いチームはオフィスを捨てる」を読んだので個人的な考えも含めてまとめておきました
総じて言えばリモートしたほうが良いですよということに関しては全面的に賛成です

国内の企業でも積極的に取り入れている会社はあるようなので今後いろいろな企業でリモートワークできる未来が来るかもしれません

2016年12月25日日曜日

ニフティクラウド上に VyOS を構築して L2TP/IPsec を使って Mac から VPN 接続してみた

概要

ニフティクラウド上に VyOS を構築して自宅の Mac から L2TP/IPSec を使って VPN 接続してみました
VPN 接続することでニフティクラウド上のマシンが自宅の Mac からローカル IP 接続できるようになります

環境

  • ニフティクラウド (2016/12/25 時点)
    • Region: east-1 (Zone: east-12)
  • ゲスト OS: VyOS 1.1.7 (Public イメージを使用)
  • Mac Book Pro (OS X 10.10.5)
  • Wifi Walker NAD11

完成図

今回の完成図は以下の通りです
自宅側の Mac は WiMAX を使ってインターネットに接続します
WiMAX のグローバル側の IP は固定 IP が理想ですが、動的 IP でも問題ありません
その場合は確認くんなどで事前にグローバル側の IP を調査しておいてください
l2tp_ipsec_vyos_with_mac1.png

プライベート LAN の作成

まずはニフティクラウド側でリソースを作成します
左メニューから「ネットワーク」を選択し「プライベート LAN 作成」から作成します
CIDR は今回完成図にあるように「192.168.0.0/24」にしておきます
ここで設定した CIDR の範囲の IP が自宅の Mac 側にも振られることでクラウド側のサーバと通信できるようになります
l2tp_ipsec_vyos_with_mac2.png

VyOS の作成

次に VyOS をニフティクラウド上に構築します
「サーバー作成」から作成します
ニフティクラウドでは Public イメージとして VyOS の 1.1.7 が公開されているのでこれを使いましょう
l2tp_ipsec_vyos_with_mac3.png

サーバのスペックは small2 くらいあれば OK です
料金プラン、SSH キー、ファイアウォールは適当に割り当ててください
ネットワークの設定でプライベート側は先程作成したプライベート LAN を設定してください
l2tp_ipsec_vyos_with_mac4.png

作成が完了するとプライベート側の IP がまだ設定されていないため警告マークになりますが、手動で設定するので問題ないです

VyOS 上で L2TP/IPSec の設定

では VyOS に SSH ログインして VPN の設定を行います
ログイン用のユーザは vyos になるので注意してください

プライベート IP の設定

まずはプライベート側の IP を設定します

  • configure

で編集モードになり

  • del interfaces ethernet eth1 address dhcp
  • set interfaces ethernet eth1 address ‘192.168.0.1/24’
  • set interfaces ethernet eth1 description ‘vlan’
  • commit
  • save

で静的 IP を付与します
commit ip a show で IP が振られていることを確認してください
コンパネでも警告マークが消え正常になっていると思います

L2TP/IPSec の設定

次に VPN の設定を行います

  • configure

で編集モードになります

IPSec の設定は以下の通りです

  • set vpn ipsec ipsec-interfaces interface eth0
  • set vpn ipsec nat-traversal enable
  • set vpn ipsec nat-networks allowed-network 0.0.0.0/0
  • commit
  • save

L2TP の設定は以下の通りです
xxx.xxx.xxx.xxx の部分はニフティクラウド上に作成した VyOS のグローバル側の IP を記載してください
pre-shared-secret で設定した「TESTSECRET」はどんな文字列でも OK です
あとで Mac から使用するのでメモしておいてください
あと local-users usernamepassword で設定したユーザ名とパスワードも Mac から VPN 接続するときに使うのでメモしておいてください
もちろん好きなユーザ名とパスワードに変更してもらって OK です

  • set vpn l2tp remote-access client-ip-pool start 192.168.0.100
  • set vpn l2tp remote-access client-ip-pool stop 192.168.0.200
  • set vpn l2tp remote-access outside-address xxx.xxx.xxx.xxx
  • set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret
  • set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret TESTSECRET
  • set vpn l2tp remote-access authentication mode local
  • set vpn l2tp remote-access authentication local-users username TESTUSER password TESTPASS
  • commit
  • save

start 192.168.0.100stop 192.168.0.200 で指定した範囲から IP を 1 つ VyOS が払い出し VPN 接続に成功したマシンにプライベート IP を付与してくれます

VyOS 用のファイアウォールの設定

ここで WiMAX のグローバル IP からの接続許可をします
固定 IP であればそれを、動的 IP であれば事前に調べておいて IP をファイアウォールに設定します
アクセスプロトコルは今回は Any で実施します
要するに自宅の WiMAX からのアクセスは全許可になれば OK です

また、VPN 接続後にプライベート IP でクラウド上のサーバにアクセスします
ニフティクラウドの場合同一ファイアウォール内にいる場合はプライベート間はアクセスし放題なのですが、今回の場合自宅のマシンからのアクセスなのでファイアウォールにプライベート間の通信の許可ルールを追加する必要があります
なので、プライベート IP からのアクセスも許可しておきます

  • ANY CIDR 192.168.0.0/24
  • ANY IP WiMAX のグローバルIP

上記を IN ルールに許可してください
OUT ルールは特に設定する必要はありません

試しに自宅環境から VyOS のグローバル IP に SSH ログインできるかどうか確認すると良いかと思います

動作確認用のサーバを準備する

これは何でも OK です
適当にサーバを作成してください
一つ条件としては事前に作成したプライベート LAN (vlan) に接続するようにしてください
そしてプライベート IP を手動で設定してください
今回の完成図では「192.168.0.10/24」を設定しました
動作確認用に Apache をインストールして起動しておきます

ここまでできればニフティクラウド上での作業は完了です

Mac を使って VPN 接続して動作確認する

では自宅の Mac から接続してみます
「システム環境設定」から「ネットワーク」を選択します
l2tp_ipsec_vyos_with_mac5.png

ネットワークの一覧の下にある「+」ボタンから新規でネットワークを追加します
作成時にプルダウンでインタフェースの種類を選択できますが「VPN」を選択します
VPN タイプには「L2TP over IPSec」を選択します
l2tp_ipsec_vyos_with_mac6.png

l2tp_ipsec_vyos_with_mac8.png

サーバアドレスにはニフティクラウド上に作成した VyOS のグローバル IP を入力します
アカウント名には VyOS に設定した認証用のユーザ名を入力します

そしてその下にある認証設定を選択します
「ユーザ認証」のパスワードと「コンピュータ認証」の共有シークレットを入力します
どちらも VyOS の設定時に決めたものにすれば OK です
l2tp_ipsec_vyos_with_mac7.png

サーバ情報と認証情報が入力できたら「接続」を選択します
接続に成功すると VyOS に設定した払い出すプライベート IP の範囲から 1 つ Mac に IP が振られます
今回であれば「192.168.0.100」が振られると思います

Mac 上でインタフェースを確認すると VPN 用に 1 つ追加されていることも確認できます

  • ifconfig ppp0
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet 192.168.0.100 --> 10.255.255.0 netmask 0xffffff00

この状態になればニフティクラウド上の vlan 内にあるサーバにプライベート IP でアクセスできるようになります
ブラウザに 192.168.0.10 を入力して Apache のスタート画面が表示されることを確認すると良いと思います
ping や SSH もプライベート IP を指定してできると思います

最後に

VyOS をクラウド上に構築して L2TP/IPSec で VPN 接続してみました
VyOS を使えば簡単に実現できるので簡易な VPN を構築したい場合には便利かなと思います
ただ、現状の構成だと VyOS が完全に SOPF になっているので実際のサービス運用をする場合には DR などを考えなければいけないかなと思います
実際自分が試したいたときにもちょくちょく切断する現象が発生しましました (WiMAX が関係している可能性もありますが)

また、今回はクライアント側の WiMAX 側は特に何も設定しませんでしたが、ルータによってはもしかすると何か設定が必要になるかもしれません

参考サイト