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 側は特に何も設定しませんでしたが、ルータによってはもしかすると何か設定が必要になるかもしれません

参考サイト

ニフティクラウドのルータの NAT 機能を使ってインターネットにアクセスしてみた

概要

ニフティクラウドのルータ機能に NAT 機能があります
今回はこの NAT 機能を使用してグローバルネットワークを持たないサーバをインターネットに接続してみたいと思います

環境

  • ニフティクラウド (2016/12/24 時点)
    • Region: east-1 (Zone: east-12)
  • ゲスト OS: CentOS6, 7

構成

構成は前回までに作成したルータ環境をそのまま使用します
そのままだとサーバがグルーバルに直接通信できてしまう状況なので今回はそれをルータ経由でアクセスできるようにしてみます
全体の構成図としては以下の通りです
niftycloud_router_nat_usage1.png

グローバル IP の削除

まず c7 サーバからグローバルインタフェースを取り外します
サーバを選択し「ネットワーク設定変更」を選択します
ダイアログで「グローバル」の IP アドレスを「利用しない」に変更します
niftycloud_router_nat_usage2.png

設定が完了してコンパネ上の表示からグローバル IP が見えなくなることを確認します

念のため

グローバル IP を削除するとサーバが再起動します
サーバが再起動すると c6, c7 のルーティングがなくなってしまうのでファイルに書いてルーティング情報を保存しておきましょう

  • c6
    • cat /etc/sysconfig/network-scripts/route-eth1
172.10.0.0/16 via 192.168.0.1
  • c7
    • cat /etc/sysconfig/network-scripts/route-ens192
192.168.0.0/16 via 172.10.0.1

これでグローバルネットワークが削除されてサーバが再起動しても c6, c7 間はプライベート IP を使って通信することができます

ルータをグローバルネットワークに接続する

サーバが接続しなくなったので、代わりにルータをグローバルネットワークに接続します
左メニューの「ネットワーク」からルータを選択し「ルータの操作」から「ネットワーク設定変更」を選択します
そして「ネットワーク追加」から「共通グローバル」を選択し追加します
niftycloud_router_nat_usage3.png

設定が完了するとネットワークの構成図でルータが共通グローバルに接続されると思います

NAT テーブルの作成

次にインターネットに接続するための NAT 設定を行います
左メニューの「ネットワーク」から「NAT テーブル」を選択します
そして新規作成から以下のように入力します
niftycloud_router_nat_usage4.png

c7 の IP アドレス (172.10.0.10) を共通グローバルに NAT する設定を追加します
これは Source NAT (SNAT) になるので SNAT 側に追加します

ルータへの NAT テーブル追加

追加した NAT テーブルをルータに反映させます
ルータを選択し再度「ルータの操作」からネ「NAT テーブル設定変更」を選択します
先ほど作成した NAT テーブルを選択し「変更する」を選択します
niftycloud_router_nat_usage5.png

問題なくルータに反映されれば OK です
これでニフティクラウド上での操作は完了なのであとは OS 上で動作確認します

OS 上での設定と動作確認

c7 サーバへは c6 サーバからルーティングが通っているので、そこから SSH すると良いです
グローバルからはインタフェースを外しているのでできなくなっているためです
とりあえず ping 8.8.8.8 などして接続できないことを確認します

では c7 サーバに default gateway を設定します
以下のコマンドを実行してください

  • ip r add default via 172.10.0.1 dev ens192

これを実行した段階で先ほどの ping が通るようになっていると思います
更に curl www.google.co.jp などを実行すると HTML が取得できると思います
yum update もできます

default gateway の情報は恒久的に保存したい場合は以下のファイルに追記しましょう

  • vim etc/sysconfig/network-scripts/ifcfg-ens192
GATEWAY=172.10.0.2

で再起動しても default gateway の設定が消えません

最後に

ニフティクラウドのルータを使って SNAT 機能を実現してみました
これでルータ配下にいるサーバはグローバルネットワークを持たなくてもインターネット通信できるようになりました

ニフティクラウドの場合、グローバルネットワークを取り外すと少しお値段が安くなるのでインターネットには接続したいがグローバル IP を使わない場合にはお得かもしれません (ルータの料金はかかりますが)

2016年12月18日日曜日

ニフティクラウドのルータの DHCP 機能を使ってみた

概要

前回、ルータ機能を使って VLAN 同士を接続させてみました
このままだとサーバを VLAN に追加したときに毎回 IP を手動で設定しなければなりません
面倒でなければそれでも問題ないですが、IP を振るのが面倒な場合にルータの DHCP 機能を使うと設定の手間を省くことができます

環境

  • ニフティクラウド (2016/12/18 時点)
    • Region: east-1 (Zone: east-12)
  • ゲスト OS: CentOS6, 7

DHCP コンフィグの作成

環境は前回のものをそのまま使います
まずは DHCP コンフィグを作成します
「ネットワーク」->「DHCP コンフィグ」から「DHCP コンフィグ作成」を選択します

「自動割り当て IP アドレス」の右端にある「追加」ボタンを押します
DHCP コンフィグの作成では VLAN で指定した CIDR の範囲で DHCP として割り当てる IP の範囲を指定することができます
今回は 192.168.0.100 から 192.168.0.254 の範囲の IP を使用するようにしました
try_niftycloud_roter_dhcp1.png

これで作成すれば OK です

ルータへの DHCP コンフィグの設定

作成した DHCP コンフィグをルータに割り当てます
「ネットワーク」から構成図を表示します
そして、ルータを表示し「ルーターの操作」から「ネットワーク設定変更」を選択します

ネットワークの設定変更画面で今回作成した DHCP コンフィグの CIDR の範囲に該当する VLAN 側の DHCP コンフィグを変更します
今回は vlan1 側に DHCP コンフィグを割り当てるので以下のようになります
try_niftycloud_roter_dhcp2.png

設定を反映させれば完了です
コンパネの注意書きにもありますが、この操作はルータの再起動が必要になるのでサーバ同士での通信断が発生するため本番環境などの場合には注意して操作してください

若干反映に時間がかかるので待ちます
ルータの設定を確認して以下のようになれば設定完了です
try_niftycloud_roter_dhcp3.png

try_niftycloud_roter_dhcp4.png

既存のサーバで動作確認

ルータへの反映が完了したら早速 DHCP で IP アドレスが振られるかどうか確認してみましょう
vlan1 に所属していた c6 サーバは固定 IP に設定していたので、以下のように /etc/sysconfig/network-scripts/ifcfg-eth1 を書き換えてインタフェースを再起動してみます

DEVICE=eth1
BOOTPROTO=dhcp
ONBOOT=yes
PEERDNS=no
  • ifdown eth1
  • ifup eth1

これで IP がどうなるか確認してみましょう
前回までだと 192.168.0.10 を固定 IP にしていましたが、DHCP コンフィグで指定した範囲の IP が割り当てられていることがコンパネ上で確認できると思います
try_niftycloud_roter_dhcp5.png

新規にサーバを作成して動作確認

新規でサーバを作成した場合の IP の割り当てについても動作確認してみます
サーバを作成する際にプライベート側のネットワークの指定で vlan1 を指定しかつ IP アドレスの欄を「自動割り当て」にします
try_niftycloud_roter_dhcp6.png

これで新規 + VLAN 環境の場合でもプライベート側の IP アドレスを自動で付与することができます
サーバを作成してコンパネ上で IP がどうなっているか確認しましょう

!?
try_niftycloud_roter_dhcp7.png

が、付与することは付与できたのですが IP アドレスが DHCP コンフィグで指定した start からの値ではなく単純に若い方から順番に振られる感じでした
もしかしたら新規で作成した場合は DHCP コンフィグの値が無視されているのかもしれません
ちなみにこの状態になって ifdown -> ifup を繰り返しても再度同じ IP が振られてしまいました

また、試しに更にサーバを追加で作成してみましたがやはり若いほうから IP が振られてしまいました
今回は CentOS6, 7 で挙動を確認しましたがどちらも同じ感じでした
もしかすると他の OS だと挙動が違うかも、、、たぶんないと思いますが

サーバ側での追加作業

前回も実施しましたが、実際に別の VLAN のサーバと通信させるためにはルーティングの追加作業は必要です
以下の

最後に

ニフティクラウドのルータの DHCP 機能を使ってみました
これで VLAN 内のサーバに対しても動的に IP を振ることができるので設定の手間が省けます

2016年12月17日土曜日

ニフティクラウドのルーター機能を使って VLAN 同士を接続してみた

概要

ニフティクラウドのネットワークの機能にルータという機能があります
http://cloud.nifty.com/service/router.htm

異なる VLAN 同士を相互に接続することができる機能のようです
実際に動作試してみたので紹介します

環境

  • ニフティクラウド (2016/12/17 時点)
    • Region: east-1 (Zone: east-12)
  • ゲスト OS: CentOS6, 7

プライベート LAN の作成

今回は 2 つのプライベート LAN (vlan1 と vlan2) をルータを使って相互に接続してみます
ニフティクラウドのコントロールパネル (以下、コンパネ) から「ネットワーク」と進み「プライベート LAN の作成」から作成します

まず vlan1 は以下の通り
CIDR は 192.168.0.0/16 にしました
800

vlan2 は以下の通り
こちらは同じ CIDR だと疎通できた感がないので別の CIDR (172.10.0.0/16) にしました
try_niftycloud_router2.png

とりあえず作成できれば OK です

サーバの作成

作成した 2 つのプライベート LAN 上にサーバをそれぞれ 1 台ずつ作成します
特に理由はないですが、vlan1 には CentOS6 (c6) を vlan2 には CentOS7 (c7) をそれぞれ作成します
サーバを作成するときにプライベート側のネットワークは作成した VLAN をそれぞれ指定してください
IP アドレスはサーバが起動したあとに手動で設定します

サーバのスペックは好きなものに設定してください
ファイアウォールも自環境からアクセスできるように適宜設定してください
ただし、ファイアウォールは後々面倒になりそうなので各サーバには同じファイアウォールを設定してください

c6 -> vlan1
try_niftycloud_router3.png

c7 -> vlan2
try_niftycloud_router4.png

こんな感じで作成すれば OK です

サーバに IP アドレスを付与

eth0 側にはグローバル IP が振られているので eth1 側にプライベート IP を付与します
CentOS6 と CentOS7 で若干設定ファイルが異なるので注意してください
IP は「1」を振らなければ何番でも OK です
「1」は後で作成するルータが使用します

c6

  • vim /etc/sysconfig/network-scripts/ifcfg-eth1
  • ifup eth1
DEVICE=eth1
BOOTPROTO=static
IPADDR=192.168.0.10
NETWORK=192.168.0.0
NETMASK=255.255.0.0
ONBOOT=yes
PEERDNS=no

c7

  • vim /etc/sysconfig/network-scripts/ifcfg-ens192
  • ifup ens192
EVICE=ens192
BOOTPROTO=static
IPADDR=172.10.0.10
NETWORK=172.10.0.0
NETMASK=255.255.0.0
ONBOOT=yes
PEERDNS=no

設定したら NIC を up してください
コンパネから確認すると以下のような感じになっていれば OK です
try_niftycloud_router5.png

ルータの作成

ではルータを作成していきます
左メニューから「ネットワーク」で「ルーター作成」を選択します
作成時のポイントは以下の通り

  • ネットワーク設定で作成した VLAN をそれぞれ設定します

追加ボタンからそれぞれ追加すれば OK です
ルータの IP は特に指定しないようにします
そうすることで「1」を勝手に降ってくれるようです
try_niftycloud_router6.png

  • ファイアウォールはサーバに設定したものと同じものを設定してください

別のファイアウォールを設定しても特に問題はないです
VLAN 同士で特にアクセス制限を設けない場合は同じファイアウォールにすればファイアウォール内のアクセスはすべて許可となります

ルータが作成できたら詳細を確認しましょう
以下のような感じなっていれば OK です

基本情報
try_niftycloud_router8

ネットワーク
try_niftycloud_router9.png

今回の構成が完成するとネットワーク構成図的には以下のようになります
( 関係ないサーバが 1 台いますが気にしないでください )
try_niftycloud_router7.png

ルーティングの追加と動作確認

あとは OS 上での設定となります
実施前に以下の ping を実行しておくと実際に疎通が通ったことがわかるので良いと思います

  • c6 # ping 172.10.0.10
  • c7 # ping 192.168.0.10

ルーティングを追加していない状態だと通信することができないと思います
ではまず c6 に以下の設定を実施します

route add -net 172.10.0.0/16 gw 192.168.0.1 eth1

次に c7 に以下の設定を実施します

route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.10.0.1 ens192

すると ping が通るようになるのが確認できると思います
通った状態でルーティングを削除してみてください
例えば c6 だと route del -net 172.10.0.0/16 gw 192.168.0.1 eth1 という感じです
削除するとお互いが通信できなくなることがわかると思います

ちなみに再起動するとルーティングが削除されてしまうので /etc/sysconfig/network-scripts/route-eth1 とかに設定を書いておくと再起動しても消えません

最後に

ニフティクラウドのルータ機能を使って異なる VLAN を通信できるようにしてみました
VLAN が複数ある環境では便利な機能かもしれません
ルータには DHCP の機能もあるので VLAN 内のサーバに動的に IP を振ることもできると思います (今回紹介はしません)

また、別の機会で他の機能も紹介できればと思います

ハマりポイント

今回の作業でハマった点は以下の通り

  1. OS 上にルーティングの設定が必要なことに気づかなかった
  2. ドキュメントが少ない

1 つ目はネットワークの機能に「ルートテーブル」という機能がありこれで代用できるのかなとずっと勘違いしていました
ルートテーブルにいろいろとルートの追加をしてはルータにルートテーブルを設定して、外しては再度設定してと何度も試したのですが疎通できず素直に OS レベルでルーティングを設定してみたところすんなり通った感じです

2 つ目はそのまんまですが、Web 上に参考になるドキュメントが少なかったです
VPN 接続系の記事はちょくちょくあるのですが、ルータの記事が少ない感じでした

2016年12月4日日曜日

トイレまきまきくんその後

概要

昔トイレの IoT 化ということでトイレットペーパーホルダーを IoT 化しました
http://www.slideshare.net/kakakikikeke/ss-64768171

ちょろっとエンハンスしたので紹介します

環境

  • RaspberryPi Zero ( Jessie 8.0 )

7 セグ LED をシールド化しました

元々ブレッドボード上に配線しており見た目が非常に悪かったのでユニバーサル基板上に実装することでスッキリさせました
作成した基板がこちら


makimaki_board1.jpg

合体後裏
makimaki_board2.jpg

合体後表
makimaki_board3.jpg

まず一番苦労したというかポイントだったのは片面のユニバーサル基板にどうやってシールドを実装するかでした
RaspberryPi の場合ピンがオスピンになっているためシールド側はメスソケットにしなければなりません
そしてユニバーサル基板が片面のため 7 セグの LED やフルカラーの LED もメスソケットの方に実装しなければなりません
そうすると RaspberryPi に指したときに向きが逆になってしまいます
本来なら 7 セグはメスソケットを逆の面に実装して実装面は 7 セグだけが見えるようにしたかったのですが、片面だとそれができませんでした

なので、写真にあるように 7 セグ部分が RaspberryPi Zero の頭の部分からちょうど飛び出すように作ることでとりあえず解決させました

本当は写真でいうところの白い面が RaspberryPi Zero の表の部分になるので、そっちに 7 セグを出したかったのですが片面だとそれが厳しかったということです

回路図

一応回路図を作成したので掲載しておきます
makimaki_circuit.png

フルカラーの LED の全ピンに 470kΩ の抵抗があるのは実は不要です
赤色 LED を制御するピンは入力電圧が確か低かったのでそこは抵抗を入れる必要があると思います
参考 : http://kakakikikeke.blogspot.jp/2016/01/raspberrypi-full-color-led.html
特に GND ピンは完全に不要です
他のピンで抵抗を挟んでいるのは LED の明るさをちょっと暗くしたかったので LED にかかる電圧を下げるために入れました
なので、LED が「ピカーッ!」と光っても問題ない場合は抵抗は不要です

7 セグを制御しているピンは過去の記事で使用したピンをそのまま使用しているだけなので、別に他のピンでも OK です
もう少し違うピンを使って余裕を持ってハンダできるようにすればハンダ付けももっと楽だったかもしれません
参考 : http://kakakikikeke.blogspot.jp/2016/01/raspberrypi-7-seg-led.html

長さを計測するホイールの土台を自作しました

トイレの長さを計測する部分にフォトインタラプタ+スリット付きのホイールを使っています
これは元々ジャンクのホイールマウスの部分を再利用しています

土台もマウスの土台を適当に加工したものを使っていたのですが、見た目が悪かったので 3D プリンタを使って土台の作成まで行ってみました

自作するときに土台の長さを長くすることでペーパーが少なくなってもホイールがペーパーに当たるようになったので最後まで長さを計測できるようになりました


makimaki_base1.jpg

基板とドッキング
makimaki_base2.jpg

ペーパーホルダーとドッキング
makimaki_base3.jpg

難しかったのはホイールを支える柱のところで中に溝を作らなければいけないのですが、この溝のサイズがホイールと中々合わずに苦労しました
また、基板と土台を固定化するのに小さいな穴があるのですが、その穴にちょうど入るようにピンみたいなのも作りました (写真 2 枚目)
これは見事寸法どおりに作成できました

最後に

以上まきまきくんのエンハンスでした

実はここには掲載してないですが、最近まきまきくん用の RaspberryPi Zero に HDD を挿して自宅 NAS としても使っています
もはやトイレを IoT 化するための RaspberryPi 感がゼロになってしまっていますが、別の RaspberryPi を自宅に設置するのも面倒だったので兼用にしています

USB のバスパワーもフルで供給して基板側のピン制御もして、内部でいろいろとプログラムが動いても問題なく動作している RaspberryPi Zero のポテンシャルは改めてすごいなと感じました