こちらは、フィードフォースエンジニアAdvent Calendar 2015 6日目の記事です。

昨日の記事はRaspberryPi - サイバーサングラスの調整でハマったファイルシステムのお話 - Qiitaという記事でした。アイエエエエ! ニンジャ!? ニンジャナンデ!?

いかがお過ごしでしょうか。tjinjinです。
クリスマスの予定はモンハン大会の予定です。

さて、先日弊社は事業拡大に伴うオフィスの移転をしたのですが、その際にオフィス移転PJチームでインフラ周りを担当しましたので、その知見を共有できたらと思います！

ちなみに新オフィスのロゴはこんな感じです。

こちらは引っ越しの様子の一場面です。無線APの設定を行うK氏S氏、サンドイッチを食べに来たM氏の写真です。

それでは本論に入ります。

記事の目的

事業拡大に伴い新オフィスに引っ越したいと考えている方にむけて、今回にやったこと、やればよかったことをまとめて今後オフィス移転を行うインフラエンジニアの心労を軽くしたい。

オフィス移転に当たってのインフラエンジニアの責任範囲

大前提として、一部の契約やデザイン周りを除きほぼすべてと思っておきましょう。電化製品はすべてと思っておけば漏れがなくなるかと思います。とにかく業務を止めないことを第一目的として考えられること全て検証しましょう。時期に合わせてやったこと、やればよかったことを書いていきます。

移転前

新オフィスで達成したいことを確認する

新しいオフィスに移転するに当たって何らかの目的があって移転するはずです。何を達成したくて移転するのか、要件をきっちりまとめておきましょう。弊社では事前にgoogleフォームを使ってアンケートを取ったり、社長の思い描く要件、人員的な問題を加味して内装会社にデザインコンペを行いました。内装会社さんに全てまかせておけばいいということはないので、利用する場合は密に連絡をとりあうとお互い幸せになれる気がします。

既存の契約状況の洗い出し

検討できるかぎりの契約状況を洗い出しましょう。光回線・ISP・電話・プリンタなどの社内インフラから、AWS・さくらなどのSaaS、ひいては契約しているデータセンターからドメインについても住所変更の対応が必要になります。この時点でやることはないと思いますが全体像を把握し、ことの重大さを理解してもらうためにも重要です。私は入社歴が浅く非常に苦労しました。可能ならこの部分は長く在籍している人間に任せるべきです。

スケジュールを決めよう

ある程度の大枠のスケジュールはあると思いますが、まずはスケジュールをインフラエンジニアが主体的に握る状況を作りましょう。契約周りや資材の準備など最低でも1ヶ月、可能なら2ヶ月くらい余裕を持ったほうがいいでしょう。

Todoリストをまとめよう

後からいろいろなゴタゴタがある可能性があるので、わかりきっていることは可能なかぎりTodoに落としましょう。あと何が残っているか、いつまでにやるべきなのかをまとめておきましょう。後で対応可能なものは後回しにし、優先順位を決めて取り組みましょう。

インターネット回線の契約

どの回線にするのか。可能なら現在の回線プランと利用状況を確認し選択する。今回は選択の余裕がなかったため、えいやで決めてしまったが、業務用の回線であれば帯域保証があるサービスなども検討するとよいでしょう。また固定IPを利用している場合は契約種別の変更などにより固定IPが変更される可能性があります。事前にISPに確認しておくとよいでしょう。光回線の移転手続き時に工事の事前確認があると思いますが、その際にMDF室を開けたいという話が出ると思うので、ビルの管理会社に確認しておきましょう。

ネットワーク設定

今回移転に辺り、ルータ以外の機器を新しいものに刷新し、同時にネットワークの設計変更をしようと試みました。結果的に失敗してしまい切り戻しました。ネットワークの設計変更に当たっては事前に実機を触る検証環境がなかったため机上の空論になり、機器間の接続設計などの考慮が漏れていたためのようでした。移転前に検証環境がない場合は、大きな設定変更は諦め、後日休日出勤で対応したほうがよいでしょう。可能ならば事前に新オフィスで新しい機器を買い、その場で設定できる状況が理想です。ただ、小さな会社だとそんな費用もかけられない場面もあると思いますので、あくまで理想としました。ただ、ネットワーク等のインフラでケチるのは良い選択ではないと思うので、可能なかぎり説得しましょう。後日知ったのですが、yamahaのSNSサイトがあり、そこでオンラインで検証することができるサービスがあるようです。利用したことはないのですが、試しているとよいかもしれません。ネットワークの設計については…うまくいったら後日共有しようかなと思います。

移転に当たっての稼働中サーバの取り扱いについて

引っ越しのスケジュールにもよりますが、金曜日に梱包して土日に引っ越しすることが多いでしょう。弊社の場合、金曜日に梱包して月曜日（祝日のため非営業日）に引っ越し、火曜日に業務開始というスケジュールでした。ただ、社内で動かし続けなかければいけないサーバがあったため、下記のようなプランを事前に工事業者と打ち合わせました。

• 旧オフィス側の止めてはいけないサーバは梱包しない
• 引っ越し当日インフラチームが旧オフィスに出社し、サーバのシャットダウンする
• タクシーで移送
• 新オフィスですぐに稼働させる

実際には新オフィス側のネットワークの配線が完了しておらず、すぐに作業できなかったのですが、大きな問題もなくサーバ稼働しました。L2以下は工事業者に任せた方がよいと思うので、早々に打ち合わせするとよいでしょう。

電話の契約

こちらも余裕がなかったため、既存プランの移設を選択しました。電話機の設定内容を把握している人間がいないと右往左往することが間違いないので、以前に業者に頼んだのであれば業者に確認が必要です。電話周りの基本的な仕組みも理解しておかないと契約周りで困ると思います（代表組の設定など）。電話は住所変更によって番号が変わる可能性があるので（同じ区内であっても）、1ヶ月前を目処に連絡しておくとよいでしょう。また、この機会に電話をクラウドPBXに変更やPHSを使うなどを検討するのであれば2〜3ヶ月前から検討すべきで、別途担当者を立てたほうがよいと思いました。そもそも業務で電話することあまりないので、使い方とかわからないのですよね。

受付電話の導入について

弊社ではこれまでベルを利用した受付だったのですが、負担軽減のため受付に電話を置くことにしました。ただ置くだけではなくもろもろの設定が必要です。例えば、受付からかかって来た電話を誰が受けられるようにするのかなど。今回リプレースした機械によるものなのか、設定を利用者側で変更することができないと言われており、確認の時間も取れなかったためノンエンジニア側の通路側の席を受付電話からの音を鳴らす席にしました。

電話機のリプレースにあたっての案内

既存のPBXでは台数に限界があり、今回リプレースを依頼しました。業者にまかせてしまっていたのですが、最低限操作マニュアルを取り寄せ事前に案内しておきましょう。今回導入した機器は実はかんたんマニュアルと操作マニュアルが別で、かんたんマニュアルしかもらえなかった罠にハマりました。後日情報をいただきましたが注意が必要です。

電話の設計について

こちら直前に決めることになり大変苦労しました。先述の通り電話の設定変更は利用者側で変更できないとのことなので、最初の設計が肝心です。人員の増加具合によって電話の必要台数も変わるので、人事チームに確認しましょう。ビジネスホンを利用する場合には外線の同時接続数の検討も必要です。アナログ回線では１本、ISDNでは２本、IP電話は…（把握してないです）と決まっているようです。営業などで電話を利用すると思うので、人員増加を考える場合は既存の外線数で足りるかの検証が必要です。google先生に聞いたところ、電話利用者の10％くらいの外線数があればいいという噂を耳にしましたが、業務事情によって違う部分かと思いますので柔軟に対応しましょう。

座席配置

ここの部分が今回は後手にまわってしまいました。座席はまず先に決めるべきです。座席に依存するものがLAN・電話・電話機の設定・電気の配線などなどたくさんあります。エンジニアとノンエンジニアで分かれていて、エンジニアは電話を受けないなどがある場合に電話をどこに置くべきか決める必要があります。PHSや無線LANなどを導入しておけばそういった配線周りを考える必要が減るのですが、なかなか難しいです。また、エンジニアだと普通の横並びの席よりもコミュニケーション取りやすい空間を作ったり、スタンディングデスクが欲しいなどの要望があると思います。

移転当日のスケジュールを決める

基本的に当日は何も考えずに書いてあることを粛々と行うことが理想です。急なトラブルの可能性もあるので、事前にやるべきことは洗い出しましょう。

サーバ等のインフラ資材の梱包

サーバ等の梱包には時間がかかります。このタイミングでサーバ廃棄などすることも視野に入れ、早い段階で整理・梱包作業に入りましょう。

オフィスのセキュリティ周りについて

ここは別の担当者がいたのですが、うまく連携が取れず一部ネットワーク設計とズレが生じてしまいました。ここはインフラエンジニアをサポートに入れて相談しながらやってもらった方がよかったかなと思いました。

プロジェクト移転チームについて

弊社では今回メインで4人という体制だったのですが、エンジニアが私だけでした。情報共有の粒度等でうまく連携できない部分があったので、担当に選ばれた際には複数人エンジニアがいたほうが幸せになれる気がしました。

移転当日

必ず複数人のインフラがわかる人間を呼ぶこと

何かしら問題が出ます。一人では対応しきれないです。インフラエンジニアでなくてもよいのですが、実は新しい設備にIP必要だとか、この機器をLANに繋ぎたいのですがといった話が出てきます。人事・総務の担当者では対応が難しい部分もあるので、必ずいるべきです。複数人といったのは、一人がネットワーク・社内サーバを確認し、もう一人がその他の対応をするためです。

サーバの配線

最初に失敗すると徐々にごちゃごちゃします。ここは頑張りましょう！

移転後

情報を拾いに行く

弊社は全社員がslackを使っていますが、移転後の疑問などがいろいろなところで浮き彫りになります。インフラエンジニアがすべて拾うことはできないですが、一番移転をわかっているはずなので可能なかぎりボールを拾いましょう。

光回線の撤去作業

旧オフィスでの撤去作業が必要になります。調整して対応しましょう。

移転に当たって変更されたことの整理

まだできていないのですが、今回のタイミングで契約情報を移転に当たって取りまとめたはずなので、しっかりドキュメントに残しておきましょう。次の人が苦しまないために、次自分が担当しなくても済むように。。。

反省点

後で振り返ればいろいろ反省点は出てくるのですが、ここには書くことが阻まれるような事態が何度もあり、やってる最中はいっぱいいっぱいでした。この記事では移転後の運用について書いていないですが、自転車通勤や清掃契約、オフィスコンビニなど考えることはいろいろあるので、そこについても事前に検討する余裕が欲しかったなというのが正直な所です。

また、この移転で私一人で数十人の方とやりとりもしており、とても大変でした。複数人でインフラ周りを担当したほうがよいかと思います。

まとめ

移転PJチームの努力の結果、業務は概ね問題なく再開することができました。若干トラブルなども残っていますが、徐々に落ち着いて来たかなというところです。まだ、移転後の社内運用の部分で課題は残っていますが、そこは他の方に任せて（弊社では社内改善チームが発足しました）有給を取ってこころと体をリフレッシュさせるとよいと思います。できるなら1ヶ月、いやせめて1週間くらいリフレッシュしたい…移転後のオフィスの様子など気になると思いますが、きっと誰かが公開してくださると思うでお楽しみに！

明日はアウトドア派のLorentzca氏が担当します！