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 日くらいは出社しても良いだろう
  • 会議をなくそう、人から質問される邪魔をなくそう -> 直接あって交流しよう

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

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

最後に

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

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