エンジニア(技術2課)のタムラです。
突然ですが今回のテーマは「Wi-Fi」です。
今では世間もすっかり「Wi-Fi=無線LAN+インターネット接続の事を指す」みたいな風潮となり、国内でも海外でも様々なお店で「Free Wi-Fi」みたいな表現で無料のインターネット接続を提供するサービスが溢れ返っています。東京の電話BOXではオリンピックに向けてかはわかりませんが「TOKYO Free Wi-Fi」なんてステッカーが貼られ、海外旅行者向けに運用されていると思われる東京都運営のサービスなんかも見かけます。
今はもう見慣れてしまいましたが、私は初めて「Free Wi-Fi」という表現を街で見かけた時には 「これでいいのか.......？」とかなり戸惑ったのを覚えています。
そもそも「Wi-Fi」ってなんでしたっけ？
無線LANの歴史は1970年にハワイ諸島の島間をつなぐためにハワイ大学が開発したALOHAnetから始まり…
とか書き出すと大変なので端折りますが
今のWi-Fiの大元となっているIEEE802.11という規格の無線LANの機器が普及したての頃、同じIEEE802.11準拠で作られたはずの異なるメーカーの製品同士が接続出来ない等、購入先でトラブルが多く大きな問題となっていました。(IEEE802.11の規格が少し曖昧だったからという経緯があるようです)
その相互接続性を保証するべく、IEEE802.11を担いでいたWECA(現:Wi-Fi Alliance)という団体にて標準化を取り組み、指定のテスト項目等を整備し、それをクリアした製品に対して認証(ライセンス)を付与する制度を作りました。そこで生まれた認証取得製品のブランド名が「Wi-Fi」です。
オーディオ(&ヴィジュアル)業界で長年使われてきた「原音や原画に忠実な再現」の意味を持ち 高品質な機器やらシステムを指す用語でお馴染みの「Hi-Fi」がありますが
それをもじってつけられたとか言われています。(アメリカンっぽいノリが素敵です
Hi-Fi (High Fidelity)
Wi-Fi (Wireless Fidelity)
IEEE802.11に準拠しているだけでなく、品質(相互接続性、セキュリティ等)を保証する為のテストをクリアしている製品のみ製品パッケージに例の白黒の「Wi-Fi」というCERTIFIEDロゴマークを付けて販売する事が出来たのです。なので当時の消費者も「Wi-Fiロゴマークがある製品同士であれば安心」といった心理で無線のネットワーク機器を購入出来たのですね。
(ご家庭向けとして急速に普及したのは、1999年に正式規格となったIEEE802.11bからで その頃にはお店で見かける製品はどれもWi-Fiロゴはついてて当たり前みたいな状態になっていましたが...)
なので元々「Wi-Fi」という用語は、現在のように無線LAN+インターネット接続そのものを指して使われるようなものではなく、無線LAN接続の機能を備える製品の「品質の証」みたいなところがありました(今も実際にそうではあるのですが...)
まさか今のような形で世界中で使われる事になろうとはWi-Fiの名付け親も思わなかったのではないでしょうか？
そんな感じでWi-Fiの過去の歴史を少し掘ってみるのもたまには面白いですよね。当然のように知っているおじさん達も当時を懐かしみながら...。
はい。(前置きなげーよって思った人ごめんなさい)
今回は、社内のWi-Fiに関するとある問題に立ち向かって仕組みで解決してくれたサーバーワークスの今年の新人のお話です。
過去に以下Blogでも書いたのですが、サーバーワークスでは「毎年、新人達が何らかのbotを作る」という風習があるようで、今年も何やら面白い事をやってくれたようです。
サーバーワークスでは、同じ課や同じチームでもメンバーが当たり前のように違う場所に散っています。 東京オフィスに勤務しているメンバーでも「クラウドワークスタイル」という社内制度を活用し、自宅、カフェ、時にはAWS Lofとか好きな場所で仕事するエンジニアもいます。
そういった事情もあり、リモートMTGがとても活発なので自由に借りられる社内の共用モバイルルーター(ポケットWi-Fi)も一定数用意されており、カレンダーで予約するだけで常識の範囲内で借りる事ができます。
こちらが東京オフィスの一角にあるモバイルルーター(ポケットWi-Fi)の置き場です。 写真にも映っていますが、リモートMTG用のセットとしてJabraのスピーカーフォン等も借りる事が出来ます。(撮影していたら丁度良いタイミングで、しまむー[島村]が5号機を返却しにきたのでポーズして貰いました)
置き場ではUSB-MicroBの充電用ケーブルが伸びており、返却時には次に利用する人の事を考えて充電用ケーブルを挿してから戻して貰う運用をしています。
しかし、その運用で一点問題がありました。
それはたまに「電源を切り忘れた状態で返却されてしまうケースがある」という事です。
何故に問題になるかというと、周辺の席で仕事をしている方のPCが気がつかないうちに社内Wi-Fiではなく、電源を切り忘れたモバイルルーター(ポケットWi-Fi)の方に接続してしまい知らぬ間にプランの上限まで使ってしまったりして後に困るような事が過去に何回か起きたのです。
(電源Offでの返却やクライアントのOS側の設定で当該Wi-Fiアクセスポイントの優先度を下げる等の対策の呼びかけもしていますが、人間ですしなかなか徹底は難しいという事情もあり...)
そこで立ち上がったのが今年の新人のお二人、菅谷さん(左)と孔さん(右)です！(写真では座っていますけど)
入社して2ヶ月ちょっとという時期だったのですが、先輩社員(寺田)からアドバイスを貰いながらbotを作り見事に問題を仕組みで解決してくれました。
とりあえず話を聞かせてよって感じでOJTの合間に集まってもらったので早速インタビューしてみたいと思います。事前に質問を用意してこういう形式で人と会話するのは人生初なのですが、まるでライターにでもなったような気分に浸れますね。
ぽけっとWi-Fi検知bot製作者インタビュー
2019/07/10 @サーバーワークス東京オフィス 江戸紫
菅：菅谷
孔：孔(こん)
寺：寺田
田：田村(聞き手)
Q1.bot制作に取り掛かったきっかけは何だったん？
寺：まずは、社内Slackの東京オフィスチャンネルでWi-Fi電源切り忘れのやり取りを見た時に、人を介さず仕組みで解決出来たら良いなと思いこの書き込みをした事がきっかけ。
寺：昔からSSID比較とかで簡単に実現出来るであろう事は知っていて、どうせやるならシンプルでみんなが簡単に運用出来るようなもので〜とか考えて最終的にRaspberry Pi(以後ラズパイ)を使うのが良いかなと思った。
そのスレッド内ですぐに千葉さん(部長)がラズパイの購入をOK(稟議を通して)くれたので、自分でちょちょいと作ってもよかったけど、「折角だし今年の新人の研修課題に良いかな？」と思い、社内SlackのBeginnerチャンネル(新人とトレーナーが参加している新人の為のチャンネル)にて声をかけたところこの二人が手を挙げてくれたのがスタートですね。
田：手を挙げた側としてはその時はどんな感じだったのですか？
菅：その頃はちょうどAWSインフラとPythonの研修の合間にあたる時期でして、研修では本を読んでいる時間が長く実際に手を動かしてみたかった時期でもありました。「いつかは社内で必要とされるシステムを自分で作りたい」という思いもあるなか、そのようなお誘いの声が入社して2ヶ月ちょいの自分なんかにかかるんだと驚きながら興味本位に手を挙げてみました。
孔：私は社内Slackを眺めていて東京オフィスでの一例のモバイルルーター電源切り忘れの問題のやりとりを見た時からずっと気になっていました。そして「自分の力で何か解決できたらいいな」とも思っていました。そしたら思いが届いたかのように寺田さんの方からBeginnerチャンネルで誰かやってみない？と声がかかってきたので即座に手を挙げた感じですね。
Q2.構成の詳細を教えて？
孔：現時点での構成はこんな感じです。まだ図的に色々見直さないといけない点があると思いますし、機能のアップデート予定もありますが。
菅：ざっくり流れとしてはラズパイがWi-FiのSSIDを検知したら、予め用意した社内で利用されているポケットWi-FiのSSIDのリストと比較し、一致しているものを変数に入れSlack APIに向けて(Webhookして)投げるって感じになっています。
田：このCacooの構成図はどのように描かれたのですか？ 寺田さんの支援もあったのかな？ 孔：構成図は私が書きました。自分なりにWeb調査しラズパイとかPython とか APIとかそういうのを理解しながら組み立てていった感じです。現時点ではこのような図になりましたけど、初期の図はそれはもうめちゃくちゃでした。
寺：「とにかくミニマルにスタートできて余分な機能を入れなくてプログラム一つぐらいでできそうだったらそれで、もし追加機能が必要なら拡張しやすく、とにかくシンプルに検知してSlackに投げる」というのをざっくり提案しただけで構成図には関わっていないですね。 孔：最初は、色々調べてイベントドリブンな方向(AWS LambdaやらAPIGatewayを利用)での実装とかも考えとしてはあったのですが、スモールスタートとは言えず最終的にLinuxのCronを利用したシンプルな構成となりました。
田：事前にSSIDのリストを保有して、値(SSID)を取得したらそのリストと比較して、もし一致していたらSlackに飛ばすみたいなのって結構アルゴリズムっぽい考え方だけど、その辺りはPython研修前だったタイミングでもすんなりでした？
孔：その考え方自体は自然とすんなりでした。でも最初は変数をうまく活用出来なかったり、テキストファイル同士で比べるようなイケてないロジックにしてしまったりして比較処理とかで苦労しました。
Q3.どんな感じでプロジェクトを進めたの？
田：プロジェクトという表現はちょっと大げさかもですが、どのような段取りを踏んで役割分担とかはどんな感じに割り当てて進めたのですか？ 寺田さんからざっくりな要件で落ちてきたと思うのだけど、その先について詳しく聞きたいです。
菅：まずは二人で江戸紫(という名前の和室の畳会議室があります) でどんな感じで進めようかと相談する目的の打合せをしたのですが、孔くんが構成イメージをCacooで既に作っていていきなり出してきたのでめっちゃ驚きました！驚きすぎて思わず「さばチップ」送っちゃいましたよ（笑）
田：そりゃあ、前のめりでいいね。
当時の「さばチップ*1」を見つけました
孔：でもその構成図のクオリティはそりゃあもう酷かった...。(すごかったと菅谷くんに褒められているが)
田：でもそんな「たたき台」があったからこそ議論も前に進んだんでしょ？ そこから構成図を見ながら役割を分担したのですか？
菅：はい。役割分担としては社内のモバイルルーターのSSIDを検知するまでのプログラムを前半、受け取ったSSIDの情報をSlackに表示させるところまでが後半として役割を分けました。ちなみに前半は孔が、後半は菅谷が担当しました。
田：そこからはboxnoteとかで前半後半のタスク整理を進めたような感じなのでしょうか？
菅：いえ、そのような事はせずにやった事だけを各自メモしていくみたいな感じでした。
田：それだとタスクリストがなく、やった事のメモだけが残っているような感じ？
菅：はい...。今思うとタスクを事前に整理して書き出して共有すべきだったと感じます。後で重要なタスクが漏れている事に気がついたりもしましたし、完成したときも「完成しました！」って寺田さんに報告したら「で、Readmeは無いの？」って笑顔で指摘されたり...。
孔：あの時は「え、Readmeって何ですか？」って二人で聞き返しちゃいましたもんね（笑
田：前半後半ってのは少し斬新というか思い切った分け方にも感じるけどチームとしてうまくいったのかな？
菅：色々と分け方に問題がある事に後で気づいて後悔した感じです...。ほんと色々ありました。
田：具体的にどんな問題があって後悔をしたの？
菅：私のなかだと大きく2点あったと思っていて
1点目が、構成図ベースでの役割分担だったのでその範囲外の全体タスクとか色々とお互いに漏れていた事。
2点目が、構成図ベースの前半後半という分け方だと、蓋を空けたらタスクのウェイトが偏っていた(孔くんに寄ってた) 事。当然、自分の方が先にタスク完了したのですけど、その後に孔くんをどのようにサポートすれば良いのかわからなかった。
孔：あとは前半後半で分けたけど Pythonのコーディングのパートがかぶってしまったりもあった。1つのPythonのコードのなかで前半後半で役割が分かれていたので最終的にコピー&ペーストでマージみたいな事をしたのですけど、お互い変数の付け方とか違っていたりしてマージ後に動くまでが結構大変だった。エラーが出た時にどっちが担当した内容のエラーなのか混乱しながら二人で確認したりもしていました。
田：Git 使ってやってねみたいな指示はなかったんだ？
菅：お互いその時はGitの使い方を知らなくて、完成後に格納先として初めて使ったんです。
孔：今やるならちょっと違った...とは思う。
田：それを踏まえて今思うとどう役割分担すべきだった？
孔：それは今でも疑問がかなりある...。
菅：自分はお互いが不慣れだっただけで、そんなに悪くはなかったんじゃないかなって思っています。逆にどうすべきだったとかありますか？
田：私の個人的な意見を言っちゃうと、最初にたたき台をベースに全体タスクの洗い出しというプロセスを踏んで「洗い出したタスク毎に役割分担」をしたほうが良いように感じました。そしてboxnoteやらbacklogやらTrelloやらなんでも良いけど活用して情報共有しておけばお互いの進捗も可視化出来るし、仮にウェイトが寄っていた時とかも他の人のタスクが前半後半の分け方よりは細分化されているのでサポートにも入りやすいですよね？
前半後半って分け方は例えばだけどインフラ、アプリ、運用みたいなプロジェクトのステークホルダのスコープの分け方みたいな印象を受けたので、今回はチームとしてうまくいったの？というのがすごく気になって深掘りしたのです。
菅：そう言われると凄くそんな気がしてきました...。
田：二人のコラボレーションはどのように行ったのですか？
菅：同じ東京オフィスですし、近くに座っている事も多かったので会話ベースがほとんどでした。
孔：すれ違ったり、研修とかで同席した時に「今日はどう？進んでる？」みたいなラフな会話が多かったですね。でも少人数のこの規模だったから出来ていたところがあるので大人数だったら考えないとなと思う...。
田：期限(納期)についてはどうでした？ 寺田さんもそこだけはふんわりせずに明確な線を引いてきたと思いますが。
菅：その通りです。色々な部署を巡るOJTの開始が7月からだったので「6月末が納期」と線が引かれていました。まぁ結局少し間に合わなかったんですけど...。
田：具体的に何が原因で遅延したの？
菅：全体タスクで色々漏れがある事に後半になって気がついてその対応が主な原因です。
孔：いざ機器設置を進めようとした際に、情シスとしては本番稼働して運用が必要なハードウェアを無駄に増やしたくないので既存のラズパイ(オフィス温度センサー等で利用されているもの) に機能を移植する方向にして欲しいとの意向があり、環境の移植が必要になった事も大きかったです。
菅：最初はその環境移植もコピー&ペーストと動作確認で30minぐらいで済むでしょぐらいに思っていたので...。
田：それはシステム移行を舐めすぎちゃったね。痛い目あったでしょ？(笑 (うなずく二人)
田：でもこんな小さなプロジェクトでも他部門の介入(段取り不足が原因ですが...)やら環境依存やらシステム移行の大変さも経験出来るだなんてほんと色々なドラマがあったんだなーってちょっと感動しちゃいますね。
田：ちなみに定例会みたいなのはやっていたのですか？
孔：週に一度30分ぐらい寺田さんからアドバイスをもらうようなリモートの定例会があって、ほんとに脱線しそうなヤバイ時は誘導してくれたのでなんとかたどり着けた感じです。
寺：実際の案件なら別ですけど研修ですし、価値ある遠回りならしてもらったほうが良いので好きにやってよってスタンスで生暖かい目で見ていました。なので今回も方針(何を作るか)だけは伝えて、どう実装するかは任せて、まずは一回やってみて？って感じで進めて貰いましたね。
田：(かっけぇ...)
菅：「20%ぐらい進んだ段階で一度方針を相談するんだよ」って寺田さんに言われた時はすげぇ胸に刺さりましたね。タスク整理や概要設計が固まらない状態でとにかく目の前の見えている問題だけを片付けながら前に進めようとしてしまって、無駄な手戻りとかを経験した後だったので。
Q4.ここがスゲェんだよってところを自慢して？
菅：う〜ん...。構成がシンプルすぎてなかなか思いつかない...。ので、代わりに「孔くんのスゲェところ」を自慢したいんですけど、細かいところに気づいて指摘するだけでなく率先的に動いて形にしてくれるところがスゲェって思いましたっ！
田：(お、おう...)
孔：う〜ん...。シンプルに設計したので誰でも使いやすいところとかでしょうか...？
田：使いやすいとは？
孔：SSIDとかが増えたりしてもリストファイルを更新するだけなので...。
田：なるほど、モバイルルーター(SSID)の登録改廃とかの運用がしやすいって事ですね。ちなみに寺田さんの視点だとどうですか？
寺：「きちんと要件を満たしつつ、ものすごくシンプルに実装して、余計な機能がないところ」そこが一番すごいし、それが肝。
孔：私もそれが言いたかったんです。
菅：私もそれが言いたかったんです。
田：(ほんとかよ...)
Q5.苦労話を聞かせて？
田：一番苦労したところは何処でそれはどのように解決したの？
孔：もう色々ありすぎて何が一番苦労したのか覚えていない...。(苦笑
菅：一番だったらCrontabで動かすところじゃない？Pythonのコードを5min周期で実行するのがうまく実行できなくてだいぶハマりました。結果的にPythonファイルの中身が絶対Pathではなく相対Pathで書いてあったりとかそういうのが原因だったんですけど。
孔：あとはPythonのPath指定自体に問題があったり...。 原因はたったの3行だったけどすごい時間をかけて調べて悩んでを繰り返して大変だった。
寺：私はなかなか聞きにこねーなーって思っていました（笑 こういう時はtech(社内のSlackチャンネル)で気軽に相談して良いんだよって思いつつ
田：Cronは実行ユーザやら環境変数やら色々考慮するところがありますもんね。Cronだとダメだけど手動実行では動くか？とかそういう「切り分け」みたいな調査アプローチも学べたのかな？
菅：いえ、そこまでは出来てなかったんですけど、ログ調査のおかげで解決出来たので「ログを見る事はめちゃくちゃ大切だ」という事は学べました！いやぁ、本当にログ確認って大事ですよね。
孔：詳細なログ確認をやり始めてから一気に解決へ進んだもんね！
田：素晴らしい...。入社2ヶ月ちょいでここまで「ログ確認の大切さ」を身をもって知るだなんて...。 (マジに感動してちょっと鳥肌が立ちました)
寺：今回の課題で「ログ確認の大切さ」を学んで貰えただけで私はもう満足ですね。
Q6.今後のアップデート構想があれば聞かせて？
菅：「消しに行くボタン」の追加を考えています。
田：それはどういう機能？
菅：消し忘れのbot通知の際に「消しに行く」というボタンも同時に表示され、それを押すとだれだれさんが消しにいきますという表示がされるような機能です。オフィスには人がたくさんいますし、botの通知に気がついた人が複数人消す為に動いてしまうのは非効率かなと思ったので、自分がやりますという意思表示をSlack上でも簡単にすぐ出来たほうが良いかなと思って考えました。
この機能は私が担当していて、AWSのLambda + API Gateway の組みわせで絶賛開発中です。
田：完成したらエンジニアblogとかでもなんでも良いですが成果発表の方も楽しみにしていますね。
菅：書きますっ！書きますっ！
孔：私は、先輩の丸山(礼)さんから「折角なので社外でも汎用的に利用できるような形にコードを見直したりして公開するような取り組みもしてみたら？」とアドバイスをもらったのでOJT中に時間をみつけながら取り組んでいきたい思っています。
田：それも素晴らしい活動になりそうですね。
Q7.面白かった？
菅：めちゃめちゃ面白かった！悩みながらも解決したときのスッキリ感とかアドレナリンが出る感じ！
孔：私もです。解決したときの快感がすごく達成感もすごかったですね。
Q8.最後にBlogを読んでくれた人に向けて何か一言ちょうだい？
菅：挑戦大事っ！！
孔：文系からIT業界に入って分からない事だらけだろうと思っていたけど、その分からない事を理解しながら形にして何かを作れる事ってすごい良いものだなと感じました。既にわかっている事をやってより高度な事をするのも良いけど...。研修中でプログラムも初めてだったけど挑戦してみてとても有意義だった。やらせてくれた会社にもすごく感謝しています！
田：まじめか。
Wi-Fiの歴史を少し掘ってみるのも良いですが、今時の「Wi-Fiに関する1シーン」を少し掘ってみるのもたまには面白いですね。
*1:さばチップとはUniposを使ったサーバーワークスのピアボーナス制度。詳しくは以下URIを参照ください。 https://sabawaku.serverworks.co.jp/entry/saba-tip-5selects
