2017年12月16日土曜日

LINE スタンプを家族 Slack でも使えるようにしたお話

概要

先日「むすめちゃんスタンプス」という LINE スタンプを公開しました



せっかくスタンプを作成したのですが、前回の記事で紹介したように家族の連絡に LINE を使うのをやめてしまいました
これはもったいないと思い Slack でもスタンプが使えないかなと調べたところ微妙なやり方ですができそうだったのでそのやり方を紹介したいと思います

仕組み

やり方は正直たくさんあると思います
ググってみると同じような内容の記事がいろいろと出てくると思います

今回紹介するのはボットを使う方法です
と言っても大元の機能は Slack にある画像の URL を投稿するとその画像を取得してチャネルに流してくれるという機能を使います
察しの言い方はもうだいたい仕組みがわかると思います

今回の構成は以下の通りです
line_stickers_to_slack1.png

ボットをコマンド形式にする場合 @bot help みたいな感じでボットを呼び出しますが、それだとスタンプを呼ぶのに少し面倒なのである特定の自然言語でコメントするとそのコメントにあった画像のスタンプを投稿する感じにしています
Slack の API はイベント API を使いメッセージの受信のイベントをハンドリングします

ボットは今回 Ruby で作成しました
Slack には Hubot Apps があるので Hubot を使って簡単に作成することもできますが、Ruby が好きなので Ruby で作成しました
あとはそれを Heroku 上で動かします

スタンプ画像をどうやって公開するか

これが一番悩んだかもしれません
Slack に画像の URL を投稿する場合はその URL はパブリックな URL でなければなりません
なので認証がかかっていたり、アクセスできないネットワーク上にある画像では Slack 上に表示することができません

とは言えば自分でサーバを立ててスタンプ画像だけを配信するのも大げさかな、、、
ボットを Heroku 上で動かすのでそのボット上で画像の配信を行ってもよかったのですがボットと画像配信用の Web アプリを同居させるのが面倒くさそうでやめました

で、最終的な結論は imgur にしました
無料で使えて画像への直リンクも取得可能です
また、URL が短いのも魅力でした
Slack に画像の URL をボットが投稿したときに異様に長いとスタンプっぽさがなくなってしまいます

imgur にはアルバムレベルで限定公開できる機能もあるの今回はそれを使って画像をホスティングしてます

ボットを作成する

あとは imgur でホスティングした画像の URL を Slack にポストするボットを作成すれば OK です
今回はコマンドベースではなく自然言語を特定してマッチした場合に imgur の画像 URL を Slack 上にポストします
なので、イベント API を使って message イベントに反応するボットを作成します

一から API をコールしても良いですが Ruby で Slack ボットを作成するための slack-ruby-bot というライブラリがあるのでこれを素直に使います

コードは以下の通りです

  • vim bot.rb
require 'slack-ruby-bot'
require 'json'
SlackRubyBot::Client.logger.level = Logger::WARN

class Bot
  def initialize
    @answer = JSON.parse(File.read('./answer.json'))
  end
  def call(client, data)
    client.say(text: @answer.keys.join(", "), channel: data.channel) if data.text == "へるぷ"
    client.say(text: @answer[data.text], channel: data.channel) if @answer.has_key?(data.text)
  end
end

server = SlackRubyBot::Server.new(
  token: ENV["TOKEN"],
  hook_handlers: {
    message: Bot.new
  }
)
server.run

非常にシンプルに書けるのがうれしいです
別途 answer.json という自然言語と画像の URL を紐付ける設定ファイルを用意しましょう

  • vim answer.json
{
  "えっへん": "https://i.imgur.com/I5OjXAn.png"
}

こんな感じです
これをスタンプ 40 個分追加していきます
エイリアス的なの張りたいのであれば同じ URL に対して別のキーワードを紐付けてあげれば OK です
今回はおまけで「へるぷ」という文字列が来たときには json に記載されているキーワードの一覧を表示するようにしてみました

あとは Procfile なり、Dockerfile なりを準備して Heroku への push or container:push をすれば OK です
Procfile の場合は Web アプリではないので push 後に heroku ps:scale bot=1 的なことをしてあげましょう

ボットが起動したら忘れずに環境変数でトークンを設定してあげましょう

  • heroku config set TOKEN=xoxb-222222222222-xxxxxxxxxxxxxxxxxxxxxxxx

動作確認

Heroku 上にデプロイできたらボットと会話してみましょう
こんな感じで画像 (スタンプ) が表示されれば OK です
line_stickers_to_slack2.gif

問題点

実は今回の方法には大きな欠点があります
それは同じ画像 URL が連投されると Slack さんがその画像を展開してくれないという点です

今回、画像のホスティングに imgur を使ったので URL を変更するのは結構大変なので回避する方法はありません
適当に文字をコメントしてから再度ボットから画像を取得するようにしてください

うーん、やってしまった、、、ごめんなさい

最後に

自作 LINE スタンプを作ったので Slack 上でも使えるようにしてみました
欠点ありですが、個人で使う分にはこのレベルで十分かなと思います
無料ですし簡単な技術しか使っていないので

ついでに宣伝ですが LINE スタンプ出してるのでよろしくお願いします


2017年12月4日月曜日

プライベートの連絡に LINE ではなく Slack に移行した話

概要

家族の連絡にずっと LINE を使っていたのですが、Slack に移行したのでそのメリットやデメリットを紹介したいと思います
ちなみに移行してまだ 2 週間ほどなので、今後更にメリット、デメリットが分かる可能性はあります (その際は追記でもしようかなと)

この手の記事は他の方もいろいろと紹介しているのでこの記事も参考程度に見てもらえればと思います

環境

  • LINE アプリ iOS 版 (iPhone5 + mineo Aプラン)
  • Slack アプリ iOS 版 (iPhone5 + mineo Aプラン)
  • Slack クライアント macOS 版 (10.13.1)

なぜ移行したか

まず初めにそもそも移行が必須というわけではありませんでした
が、日頃 LINE を使う上で少し問題があり「LINE よりも Slack の方が良さそうなんじゃないか」と思い Slack に移行してみました

移行したと言っても完全に移行したわけではなく、あくまでも家族のやり取りを Slack に移行しただけでそれ以外の友人などとはこれまで通り LINE を使っています

移行する上で問題だったことや逆に Slack になって問題になったことや導入するにあたって問題だったことを紹介したいと思います

LINE を使う上で問題だったこと

まず日頃から使っていた LINE の問題ですがざっくり以下の通りです
(環境によって発生しないケースもあるらしいのであくまで自分の環境での問題です)

  • 新着メッセージ到着時にプッシュ通知が届かないケースがあった (これが一番)
  • スマホアプリへのログインは 1 アカウント 1 端末しかできない制約がある

それぞれ詳細に説明します

まず 1 つ目のプッシュ通知が届かない問題ですが移行理由としてはこれが一番大きかったかなと思います
いろいろと症状や原因を調べてみると他の人も同じようにプッシュ通知が届かないケースがあり自分だけではないということがわかりました
原因の 1 つに回線や端末、またその組み合わせ等の問題があるようで、もしかすると自分の環境 (iPhone5 + mineo、この環境は家族も同様) が悪かったのかもしれません
アプリを再インストールしたり再ログインをし直したりしてみましたが症状は解消されませんでした

プッシュ通知は届かないわけではないのですが、アプリを開かないと届かないというケースがかなり多かったです
誰かにメッセージを送らないとと思い LINE アプリを起動すると「ブー」と言ってプッシュ通知が届きメッセージを見ると昨日や一昨日のメッセージだったなんてことが結構ありました

リアルタイムで受け取りたいのに、プッシュ通知が届かないとそもそも LINE を使っている意味がないかなーと思った感じです

そして 2 つ目の 1 アカウントでログイン可能なスマホ端末は 1 台までという制約ですがこれも大きな理由の 1 つです
そもそもこの問題がなければ別のスマホに LINE アプリをインストールしてそっちでプッシュ通知を受け取ることができたかもしれません

ご存知の通り Slack アプリではこの制約はありません
いろんな端末に Slack アプリをインストールして 1 つのログインアカウントでそれぞれの端末にログインすることができます
もちろんメンションやチャネルに新規メッセージが来た場合は Slack アプリをインストールしたすべての端末にプッシュ通知が届いてくれます

という感じで LINE で起きていた大きな 2 つの問題は Slack さんを使えば解決できるということが分かり移行した感じです

移行するのにポジティブな理由

上記はネガティブな理由ですがポジティブな理由もあります

  • 作業端末の Mac に Slack クライアントが常駐している
  • 「xx is Typing」の機能が便利
  • Bot やスラッシュコマンド、拡張絵文字が使える

簡単に詳細を説明します
1 つ目の Mac のクライアントが常駐しているというやつですが自分の場合、普段から Slack をプライベートで使っています
そこに家族チャネルを作ってやり取りするようにしました
なので、家族用のチームを新規で作成するということはしていません
メッセージのプッシュ通知はスマホにも届きますが、Mac のクライアント側にも届きます
作業中は主には Mac とにらめっこしているので返信もそのまま Mac でできます
返信のためにわざわざスマホでアプリを起動する必要がないので楽です
クライアントアプリって話であれば LINE にも Mac 用のクライアントアプリがあるのでそれを常駐させれば良いだけという話ではあるのですが、それだと自分しか解決に至らないのでダメでした

2 つ目の「xx is Typing」は LINE にはない機能で普段家族とメッセージをやりとりするのに必須だとは思っていませんが、あると意外と便利だということに気が付きました
LINE の場合たまーに返信が早すぎて話が前後することがあったのでそれを回避することができます
これは心理的な問題でもあるので必須ではないですが個人的にはあったほうがやりやすいなと思いました

3 つ目の Bot やスラッシュコマンド、カスタム絵文字ですがこれも Slack にしかない機能かなと思います
今のところ家族 Slack で Bot やスラッシュコマンドが必要なケースはほとんどありませんが、今後使っていこうかなと思います (後述)

ポジティブな理由はそんな感じです

Slack に移行して問題になったこと

では逆に Slack に移行して問題になったことを紹介します

  • スタンプがない
  • Slack のアカウント取得からアプリの設定をやってあげないと導入は厳しい

それぞれ詳細に説明します
1 つ目のスタンプ問題は言わずもがなかと思います
Slack には絵文字の機能があるのでそれで代用することは可能です
可能ではあるのですが完全に代用というわけにはいきません
絵文字がない場合、普段スタンプのみの会話で済んでいたのが、スタンプがないために文字の会話にせざるを得ません

また、例えば家族用に自分で頑張ったスタンプがある場合にも使うことができません
どうしても使いたい購入したスタンプがある場合も同様です

ただー Slack には Bot やスラッシュコマンドの機能がありこれらを使えば「スタンプっぽいこと」を実現することは可能です
ご存知の通り Slack には画像の URL を投稿するとそこから画像を取得してポストしてくれるという機能があります
これを使って画像をスタンプを配信するサーバなり Bot を構築してあとはそれらを GET するスラッシュコマンド or Bot のコマンドを作成すれば OK です
自分も今試し中なのでやり方や使い勝手が分かれば別記事で紹介したいと思います

そして 2 つ目のアカウント取得ですが、これはやって上げることをオススメします
家族のみんながネットリテラルがある程度あり「Slack アカウント取得したら教えて」というレベルのお願いでやってくれるのであれば何ら問題はないですが「Slack?は?」「アカウント取得?は?」という感じなのであれば正直全部やってあげるのが最善だと思います
もちろん言葉でやり方を説明してやらせることは可能ですが、それでも難しいと思います
いずれやってくれるかもしれませんが導入障壁を上げるだけなので素直にやってあげましょう
メールアドレスの認証はさすがにやってもらうしかないので「自分のアドレスに確認の URL が届いてるからちょっとタップしてもらえる」と言って一緒に画面を見ながらやってもらいました
あとは好きなチームに invite して家族チャネルに invite してあげれば OK かなと思います

たぶん家族 Slack を導入するにあたっての一番の障壁はここだと思うので頑張ってやってあげましょう

最後に

家族の連絡を LINE をやめて Slack に移行したので、そのメリット、デメリットを紹介しました
今のところ問題なく使えているので今後も Slack でやっていこうと思っています
たぶんフリープランだけで事足りると思います
過去のメッセージを全部辿りたい場合やたくさん Bot を入れたいなどあれば別ですが、まぁないと思います

今後も使い続けて更に何か分かればまた紹介したいと思います

2017年11月18日土曜日

「ぶた忍者」アプリサポートページ

「ぶた忍者」アプリサポートページ

butaninja_icon.png

概要

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

アプリ

iOS 版・・・https://apple.co/2yShowP
Android 版・・・提供なし

プライバシーポリシー

広告 ID の利用について

ぶたスラッシュ (以下本アプリ) では Admob を使った広告配信をしております。そのため広告 ID と呼ばれる識別情報が使われております。本アプリでは広告 ID は主に広告の配信と Firebase を使った Analytics での情報収集に利用しております。本アプリの主な機能としては使っておりません。収集データはクラウドに収集され厳密に管理されます。個人で管理するデータベースやサーバでは収集しておりません。各クラウドサービスのプライバシーポリシーは以下を御覧ください。

Admob のプライバシーポリシーについてはこちらを御覧ください。
Firebase Analytics のプライバシーポリシーについてはこちらを御覧ください。

リリースノート

v1.11

細かい修正を行いました

v1.10

スプラッシュスクリーンの表示を廃止しました

v1.9

インターステイシャル広告を廃止しました
ゲーム終了時にバナー広告を表示します

v1.8

スプラッシュスクリーンを修正しました

v1.7

手裏剣の調整をしました

v1.6

iPhoneX 系のデバイスでのバグを修正しました

v1.5

iPhoneX, Xs, XsMax, XR に最適化しました
iOS10 以上のみサポートするように変更しました

v1.4

レート機能を追加しました
これでだいたい完成です

v1.3

ステージ 5 から 8 まで追加しました
遊び方の説明ページを追加しました
登場する敵、アイテムの一覧を確認できるページを追加しました

v1.2

新ステージを追加しました
ステージ 2, 3, 4 で新たに Level16 まで遊べます
ステージ 5, 6, 7, 8 も今後追加予定です

v1.1

Exp が正常に表示されないバグを修正しました

v1.0

リリースしました

2017年8月24日木曜日

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

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

butamori_icon.png

ぶたもり2D の LINE スタンプが登場しました!

概要

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

アプリ

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

攻略動画

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

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

リリースノート

v1.22

細かい修正を行いました

v1.21

スプラッシュスクリーンの表示を廃止しました

v1.20

インターステイシャル広告を廃止しました
ゲーム終了時にバナー広告を表示します

v1.19

土台の当たり判定のバグを修正しました

v1.18

コインボーナスの交換に必要なコインの枚数を大幅に減らしました
黄色のぶたが結合できる条件を修正しました

v1.17

ぶたの当たり判定を修正しました
青ぶたが重なるバグを修正しました

v1.16

お手本の動画を表示する際のバグを修正しました

v.1.15

UI の修正をしました

v1.14

ゴールドの条件の文言追加

v1.13

iPhoneX, Xs, XsMax, XR に最適化しました
iOS10 以上のみサポートするように変更しました

v1.12

スコアの計算方法にバグがあったので修正しました
タイトルロゴに文字枠を付与しました

v1.11

スプラッシュ画面を追加しました

v1.10

タイトルのロゴをポップな感じに変更しました
効果音を追加しました

v1.9

iPhoneX に対応しました

v1.8

すべてのログインボーナスを実装しました
すべてのコインボーナスを実装しました
次のバージョンで iPhoneX 対応します、すいません

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

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

プライバシーポリシー

広告 ID の利用について

ぶたスラッシュ (以下本アプリ) では Admob を使った広告配信をしております。そのため広告 ID と呼ばれる識別情報が使われております。本アプリでは広告 ID は主に広告の配信と Firebase を使った Analytics での情報収集に利用しております。本アプリの主な機能としては使っておりません。収集データはクラウドに収集され厳密に管理されます。個人で管理するデータベースやサーバでは収集しておりません。各クラウドサービスのプライバシーポリシーは以下を御覧ください。

Admob のプライバシーポリシーについてはこちらを御覧ください。
Firebase Analytics のプライバシーポリシーについてはこちらを御覧ください。

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

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

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

最後に

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

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