こんにちわ。シックス・アパートのIT担当の草野です。

去る6月23日に弊社シックス・アパートは約8年お世話になった「円通寺ガデリウスビル」から、装いも新たに「赤坂中川ビルディング」へ引っ越しをしました。

ドッタンバッタンしているうちに、もう1ヶ月とちょっと経過してしまったのですが、ITチームがどんな事を考えながら引っ越しの準備をして、実際の引っ越しにこぎ着けたのか、お話ししてみましょう。

引っ越しにあたって、ITチームは以下のミッションを掲げました。

1 引っ越し先でも前日の仕事の続きがすぐ出来るように

2 サーバールームは廃止

3 ネットワークは極力シンプルに

4 （おまけ）妥協も必要

１．引っ越し先でも前日の仕事の続きがすぐ出来るように

新オフィスに出社してから、あれやこれや準備をしないと仕事ができないという事はなるべく避けたいです。新オフィスに出社したら、ダンボールから自分のPCを出して、そのままいつもどおりに仕事ができるようにする。この実現のために、何をいつ、どの段階まで準備ができていればよいか。ここから色々なスケジュールや要件、タスクが定まっていきました。

引っ越しは多くの人との協力しあっての仕事です。しかも自分達もやるのは初めて。考えねばならないことは山のようにあるし、気になることもキリがないし、ドコから手を付けるべきか？

みんなが新しいオフィスで仕事をしているころをイメージしながら取り組みました。何かに迷ったら、「イメージのようなるためにどうしたらいいか」から再出発するようにしていました。

ネットワークにしろ、配線にしろ、業者にまかせっぱなしにしないで自分たちでやりました。そもそも、オフィスの引っ越しを自分たちで担当するのが初めてなので、普通というものがあまりわからなかったです。手探りながら、あくまでも自分たちで出来ることで考えていくという感じでした。過去に社内ネットワークを構築し直した時の経験は参考になりました。

ただ、家具（物理）、そしてネットワーク・サービス（論理）を2日でバチッとを持って行って、切り替えるのは大変でした。しかも3日目にはちゃんと動いてないといけないというのはプレッシャーでしたね。

２．サーバールームを無くす

実は引っ越し先の物件が決まるずっと前から、サーバールームを置かない事は決まっていました。CTO の平田、代表取締役の古賀からも「引っ越したらもうサーバールームは無くそう」と言われており、我々も乗り気でした。

理由としては、物理的な災害リスク（BCP 対策）面、そしてAWSに限らずクラウドが成熟してきていたことから、手元にものを置いて動かすことがデメリットになってきたからです。

以前のオフィスにあった立派なサーバールームでは社内向けのシステムや開発環境、検証環境などが毎日元気に稼働していましたが、これらはほぼ Amazon Web Service へ移行しています。

そして、引越前からバックエンドの一部サービスはひっそり AWS 上のシステムに切り替わっていました。なにも忙しい引っ越し日の前後でサービス切り替えをする必要はなく、予めクラウド上に構築したシステムへ切り替えておけば、引越し先で皆が作業を行うことはほとんどありません。

引っ越し前から引っ越しておく。これも「引っ越し先で昨日の続きの仕事が出来るように」するための仕掛けのひとつです。AWS などクラウドの良さは色々な人が語っていますので、AWS を使い始めて感じた利点を2つご紹介します。

"物理故障に悩まされなくなった"

"ポータビリティの向上"

サーバーを自前でもっていると、どうしても物理故障と付き合わないといけません。壊れたら交換があり、交換して復旧まで「物理」なので相応の時間と手間がかかるのです。そして、形あるものいつかは壊れるというモヤモヤっとした心配。もちろん自前での対策もありますが、AWS より高度な実装ができるかというと...素直に認めましょう。もう AWS には敵いません。

AWS をはじめとしたクラウドには色々な利点がありますが「物理環境」から開放されることは思っていた以上のメリットとなりました。また、ポータビリティの向上も実際にやってみて感じていることです。「え。そんなものまで AWS に？」と言われそうなものも置いてみたらしっかり動いています。BCP 対策としても、東京の赤阪のビルにあるよりもはるかに安全、安心。また AWS と場所をつなげばそこはもうオフィスです。

引っ越したばかりですが、次に引っ越しがあったり、新しいオフィス開設があった際に仕事場を展開する敷居はグッと下がりました。

「枕を高くして寝れるようになった」は半分冗談ですが、バックアップとか冗長化、監視などのやり始めるとキリが無く、物理的な環境ではどうにも解決できない故障などを引き受けてくれるのが心の平穏をもたらしてくれています。

ただ、物理的なものを扱う技術は全て AWS が引き受けてくれるので、本質的な原理や抽象的な概念の理解を深める必要が出てきたので、割と大変です。

具体的には、ハードウェア選定とかラッキングとかの肉体的なものや過去の経験による勘が不要になって、代わりにサービスの粒度やネットワークの論理設計などの概念的な思考が求められるようになっている印象です。

３．ネットワークは極力シンプルにする

シックス・アパートはネットワークがないと仕事にならない会社ですから、安定性、耐障害性など色々と実現したい高度な目標がありました。

旧オフィスでネットワークの障害が発生した時には、みんな「仕事にならん」といってラウンジスペースに集まってゲームをしたり、お菓子をたべたりしていました。呑み始めた人は...いなかったかな（笑）。我々ITチームはそれどころではありませんでしたけど...。

なので、まずは「シンプルで堅牢なもの」から始めました。

機器の選定から設定まで、出来る限り自分たちでインテグレーションをしています。専門の会社に全部お任せして「お金をかけないと設定変更すらできない」、「仕様はわかるが、どう実装されているのかわからない」といった事態を避けたかったのです。

とはいえ、物理配線のL1レイヤーや、セキュリティ上重要なところは外部の力も借りて、しっかりプロによる敷設、設定のレビューなどをしてもらっています。

自分たちが把握し、コントロールできることにこだわっているのは、夏の水曜自宅作業に代表されるような「シックス・アパートらしい柔軟な仕事の仕方」を今後もあれこれ実現するため。

会社のみんながが最大限パフォーマンスを発揮できるよう、限界はあれどもできるだけ自由に、楽しく仕事ができるようにサポートをするのもITチームの大事な大事な仕事です。

４．妥協も必要

いろいろな理想を掲げていましたが、全部キレイに実現できたわけではありません。AWS へ持っていけない物もありました。時間が足りず、引っ越し日に間に合わなかった社内サービスだってあります。

そんな時はバッサリと諦めたり、妥協しました。「新しい環境で新しい試みを実現」することと、「引っ越し先でも前日の仕事の続きがすぐ出来るように」することが衝突した場合は、迷わず後者を優先しました。

こうやって振り返ると、「引っ越し先でも前日の仕事の続きがすぐ出来るように」がずいぶん気持ちの支えと判断の基準になっていたんだなぁと驚いています。

以上、ITチームの現場から、引越し前後のアレコレをお伝えしました。

最後に

ITチームに求められるのは、ちゃんと機能するインフラです。シンプルにしたので速いし、トラブルが出ても解決のためのタスク出しが容易になりました。今後海外にオフィスが増えても柔軟に拡張できるでしょうね。

あと、社員の能力やリテラシーの高さに助けられました。要件的には単純に「ネットワークがつながっていること」こそが重要で、ITはそこを守れば社員の人たちはいかようにも動いてくれます。自分のやるべきことは、きっちりこなす人達ばかりなので。

シンプルなのは方法論な気がしていて、自分たちで掌握して、コントロールできることを重視したのではないでしょうか。自分たちがわからないことが無いという意味で、レガシーフリーであることがなにより長所で、その上で、専門家の人たちによく助言をもらって、身の丈にあったものを構築するということを達成できたと思います。それらをふまえた上で、冗長性やセキュリティにも必要十分に配慮されていて、拡張性もあるというのが良いところかな。「必要十分」というのがポイントです。

今回のミッションを自分たちのやり方で達成できたので、ポータビリティが出たというか、オフィスという物理空間への依存が薄く出来たのではないかと思います。もちろん、「じゃあ、オフィスがいらないか」ということではなく、その分、物理施設のオフィスの意味合いが強調されることになると思います。