リモートワークはじめてました
この記事は Ubiregi Advent Calendar 2020 1日目のエントリです。
こんにちは、れれのーとです。今年もAdvent Calendarの季節がやってまいりました。
前回の記事が昨年のAdvent Calendarの最終日ということで、このブログも1年ぶりに更新です（震え声）
さて、2020年はこれまでの環境が大きく変わり、今までの当たり前をアップデートする必要に迫られた年でした。仕事環境でいえば、オフィスに出社する頻度が減ってリモートでやることが増えたり、オンラインミーティングが普通になってきたり。
今までユビレジでは開発部署のみ週1回のリモートワークが許可されていたものの、タスクかんばんが紙だったり、社内ミーティングがオフラインのみだったりと「オフィスに出社していることが前提」で各種業務を想定していました。
そんなユビレジも今年2月後半の状況を鑑み「これから何が起こるかわからない」ということで、3月に2回、全社での在宅勤務訓練を経て3月末から全部署において在宅勤務を推奨、7月から恒久的に原則在宅勤務、10月からは勤務場所の制限を撤廃し原則フルリモートワークと制度を変更してきました。それに伴いオフィスの全座席をフリーアドレスに変更し、設備等の関係でオフィスで行う必要がある業務を担当する場合や、自宅よりオフィスの方が集中できる場合など、オフィスへの出勤も各自で決められるようになりました。正社員はもちろん、業務委託の方もリモートワークをしていただいています。
開発部署においても3月の在宅勤務訓練後から、全体デイリースタンドアップを在宅勤務者でも参加可能なようにオンライン対応したり、すべてのタスクかんばんを電子化したりと「全員が在宅勤務であることを想定」して習慣を変えていきました。最初のうちは慣れておらずわちゃわちゃすることもありましたが、今では通常業務に特段支障のない程度には慣れてきています。
昨年の今頃と比較するとかなり変わってきたように思いますが、今まで取り組んできた変更はあくまでオフィスでやっていたことをリモートワークでもできるようにしただけで、リモートワークに最適化できているとは言い難い状態だと個人的には捉えています。
来年からは「リモートワークに最適化」していくことを目標に、リモートワークのメリットを殺さず活かせるようなやり方を編み出していきたいなーと思っています。
さて、会社で取り組むリモートワーク環境についてはこんな感じですが、この半年強で個人でもリモートワーク環境を整えたりしました。今回は私の在宅勤務時の仕事環境をお見せしたいと思います。
春夏スタイル ver1.0
春～夏くらいの仕事環境です。ベランダ、ベランダはいいですよ。
打ち合わせの数が多くなるにつれてベランダに出なくなりましたが、また少なくなったらベランダに出ようと思っています。
時計がなくても時間がわかるところが最大のメリットですね。暗くなる前になんとかして仕事を終わらせようという気力が湧いてくる環境です。デメリットは打ち合わせの度に室内へ移動する必要があることです。オフィスにいた時も会議室へ移動していたことを考えるとデメリットというほどのものではなさそうです。
奥に見えるのは推しクッション。推しの姿を見るだけでメンタルをケアできます。
秋冬スタイル ver1.0
現在の仕事環境です。障子を破ったりしないよう保護として冷気ボードを机と障子の間に挟んでいます。
仕事をするときにずっと音楽を流しているのですが、そのためにスピーカーを置いています。左に見える穴が開いた木製のもの（YOKAのPANEL ACOUSTIC SPEAKER）と正面に見えるもの（BOSEのSoundLink Mini II）と2つ置いていますが、今はYOKAの方ばかり使っています。ドンシャリしたい時はBOSEで充電を忘れたときや面倒に思ったときはYOKAです。
「マイクONにして」のうちわは手作り。作ったばかりの頃は喜んで振っていましたが、あまり出番がなかったため今は使っていません。うちわの前にある〇×ピンポンブーは目でも見えるし音も出るしでなかなかおすすめです。鳴らしどころがハマると心の中でガッツポーズしています。
マイクはMPM-1000。ミーティングで長く話すことが多いので安いヘッドセットとはさよならしました。写真ではスタンドを使っていますが通常は手持ちです。手持ちするようなマイクじゃないけど手持ちしています。手持ちの方が落ち着くからです。オーディオインタフェースはRubix22を使っています。コンパクトだしお値段も比較的やさしめ。
写真では見えませんが椅子はツカモトエイムのエアリーシェイプ。姿勢が固まりそうでまずいと思ったら電源をONして骨盤を動かしています。
最後に
今回はユビレジでも恒久的にリモートワークになったよ！というお知らせと、わたしの仕事環境を紹介させていただきました。
秋冬スタイルについては、この先の寒さを乗り切れるかわからない、3時間くらい連続でミーティングが立て続けに入ったりすると前屈みの状態が続き腹痛が起きるなどの問題があるため近々バージョンアップ予定です。来年かな。オーディオミキサーを買ったのでそれを置くスペースも作らないといけません。来年だな。
リモートワークが主体になってから半年が過ぎましたが、まだまだ環境の課題は多いです。
できる範囲で改造したり場所を変えるなどして無理なく楽しく慣れていきたいです。
Ubiregi Advent Calendar 2019 のご紹介
この記事は Ubiregi Advent Calendar 2019 25日目のエントリです。
こんにちは、れれのーとです。
アドベントカレンダー最終日は「Ubiregi Advent Calendar 2019 のご紹介」と題して、私の感想を織り交ぜながら、Ubiregi Advent Calendar 2019 全記事を紹介したいと思います。※所属は2019年12月時点のものです
12月2日 react-routerとreact-router-domの違い
react-routerとreact-router-domの違い - Qiita
12月1日が日曜日だったので2日が最初のエントリとなりました。
フロントエンドエンジニアのコジャさんによるreact-routerとreact-router-domって何が違うの？という内容です。
使い方のコード比較などもあり、どっちがどっちなのよ？あんまり意識したことなかったなぁ、という方におすすめです。
12月3日 react-chaosでカオスエンジニアリングをやってみよう
react-chaosでカオスエンジニアリングをやってみよう - Qiita
前日に引き続きフロントエンドエンジニアのコジャさんの登場です。react-chaosでカオスエンジニアリングを試してみようという内容。
っていうか私こんなライブラリがあることを初めて知ったよ！現時点では貴重な日本語ドキュメントなので気になった方は要チェック。
12月4日 ラズパイとMESHで始めるお手軽IoT
サーバーグループ所属のエンジニア、d-ebiさんによるIoT記事。MESHのボタンをおすとSlackに通知される仕組みの実装レシピです。
来年からプログラミング教育が必修化されることもあり、MESHなどの電子ガジェットが手に入りやすくなりました。家電量販店でも売っているので、デザインがおしゃれで気になっている方もいるのではないでしょうか。「でも、どんなことできるんだろう？」という方はこの記事を読んで試してみるというのはいかがでしょう？
12月5日 葛飾北斎になりたい
またまたフロントエンドエンジニアのコジャさんの登場。ml5jsを使っていろんな画像を葛飾北斎っぽくしてみたという内容です。個人的に一番お気に入りのネタなのでぜひ見てください。
12月6日 プログラミングを始めて1年
部署の枠を超え、カスタマーサクセス部の原さんが登場。
ご自身がプログラミングを始めて感じたことや、どのようなことをやったのか、が書かれています。
本当にこつこつと取り組んでいるその姿勢に頭が下がる...。見習おう。
12月8日 ユビレジで働くエンジニアはランチに何を食べている？会社周辺には何がある？調べてみました！
ユビレジで働くエンジニアはランチに何を食べている？ 会社周辺には何がある？ 調べてみました！ - インドさんの甘口ポエムブログ
サーバーグループ所属のエンジニア、kitaindiaさんによる原宿事情の紹介です。
ちょっとしたものを買いに竹下通りに入るときは無心で前を見て目的地だけを目指すようにしています。隙を見てわき道に入る、が竹下通りを抜けるコツです。それはさておきタイトルw
12月9日 ユビレジとStockScanを使って蔵書管理をしてみた
ユビレジとStockScanを使って蔵書管理をしてみた - Qiita
サーバーグループ所属のエンジニア、_erikoyamauchiさんによるエントリです。
ユビレジのサービスである「ユビレジ」と「StockScan」、本来はPOSレジと在庫管理のアプリケーションなのですが、それを蔵書管理に応用した取り組みを紹介しています。物理的な意味での本棚整理もした方がいいよなぁ（きっとやります）。
12月10日 レガシーサーバ運用しかよく知らなかった自分がHerokuを使ってみて
レガシーサーバ運用しかよく知らなかった自分がHerokuを使ってみて - Qiita
iOSグループ所属のエンジニア、FlipFlopさんによるエントリです。
実際に自分が感じたHerokuの良さはもちろん、サーバ運用ってどんなことやってるの？ということについても書かれているので「サーバ運用ってどんなことやってるんだろう？」という方は読んでみると発見があるかもしれません。
12月11日 React/Redux + Firebase で結婚式二次会で使う余興用のクイズアプリを改造して使った時の話
React/Redux + Firebase で結婚式二次会で使う余興用のクイズアプリを改造して使った時の話 - Qiita
サーバーグループ所属のエンジニア、kitaindiaさんが2回目の登場。
React-Reduxの学習がてらクイズアプリを改造して実際に結婚式二次会で使ってみた！という内容です。
こういうの、ゼロからつくるぞーと最初は意気込むのですが、結婚式とかだと他にも膨大な量の準備が必要だったりしてなかなか手が回らなかったり妥協しちゃうかーとなったりしがち。そんな時に改造するという発想を選択肢にいれておくのは確かに良さそうです。ベースがあるので勉強としても取っ掛かりがつかめそう。ご結婚おめでとうございます。末永くお幸せに。
12月12日 p5jsとWeb Audio API でインタラクティブアート的なことをしてみる
p5jsとWeb Audio API でインタラクティブアート的なことをしてみる - Qiita
フロントエンドエンジニアのコジャさん、4回目の登場。
Processingのjs移植版なんてあったのか。Processingはだいぶ昔に興味があってちょこっとだけ手を出しました。Web Audio APIはまったくやったことないので年末年始で手持ち無沙汰になった時に試してみようかなー。
12月13日 個人的障害対応心得集
私のエントリです。不束ながらマネージャーを担当させていただいています。
長年サービスの開発運用をやってきた経験から身に着けたものを心得集としてまとめてみました。個人的には修羅場とか泥臭い仕事が多かったタイプではないかなと思います。実際にどんなやばい障害の対応をしたの？というのは全世界に公開できませんので、直接会った時にでもお話ししましょう。
12月15日 GitHub ActionsでPRのマージ時に自動的にGAE versionを削除する
GitHub ActionsでPRのマージ時に自動的にGAE versionを削除する - Qiita
CPOのpomu0325さんのエントリです。
放っておくとどんどん増えていくGoogleAppEngine(GAE)のバージョン数制限をGitHub Actionsでなんとかする、という内容になっています。GAEとGitHubをお使いで同じような悩みを抱えていて対応できていない方は試してみては。
12月16日 ノンプログラマーがGlideでアプリ作成を疑似体験したら楽しかったし勉強になったよというお話
ノンプログラマーがGlideでアプリ作成を疑似体験したら楽しかったし勉強になったよというお話 - Qiita
再び部署の枠を超え、今度はマーケティングチームのごんどうさんが登場。
今年話題になったGlideで社内向けに原宿周辺のキッチンカー情報を提供するアプリを作ったというお話です。
実際にどうやって作ったのかもそうですが、作る前にどのようなことを考えたかにも触れているので、アプリをつくってみたいけどどこから考えればいいんだろう？という方には参考になるのではないかと思います。
12月17日 iOS13とVision.frameworkで犬と猫に癒される
iOS13とVision.frameworkで犬と猫に癒される - Qiita
iOSグループ所属のエンジニア、isaragさんのエントリです。
iOS13は犬と猫を識別できる。まじですか。iOS13から犬猫の識別子が誕生したとのこと、まだまだ日本語情報が少ないので犬猫クラスタは要チェックです！サンプルコードも掲載されているので、ちょっと試してみたいな、という方はぜひ見てみてください。あー、犬も猫もよい。
12月18日 2019年買ってよかった本の話をします
2019年買ってよかった本の話｜Eriko Yamauchi｜note
サーバーグループ所属のエンジニア、_erikoyamauchiさん2回目の登場。
2019年に買って読んだ本を、ユビレジでどのように開発を行っているのかを紹介しつつ、読んでどんなことを感じたのか、感想などが書かれています。もしまだ読んだことがない本があれば、年末年始で読んでみてはいかがでしょう。
12月19日 個人開発アプリのシステム構成の話と今後の計画
個人開発アプリのシステム構成の話と今後の計画 - Qiita
iOSグループ所属のエンジニア、norihiko_obaさんのエントリです。
個人で開発しているゴミ収集日のカレンダーアプリについて、システム構成をはじめ、現在の問題点、今後対応しようと思っていることなどが書かれています。ゴミの収集日って覚えられる日と覚えられない日がありますよね。私は資源ごみの収集日を覚えるのが苦手な傾向にあります。
12月20日 会社で流しの使用状況を可視化しました
サーバーグループ所属のエンジニア、d-ebiさんによるIoT記事第2弾。
地味に社内で待望されていたネタでして、現在も記事の写真のままの状態で設置されています。Slackに加えてLEDと連動させてもよさげかも。まぶしいか。
12月21日「2Dのカメラの追尾と映したい範囲を映す」やってみた
「2Dのカメラの追尾と映したい範囲を映す」やってみた - Qiita
サーバーグループ所属のエンジニア、ruruanさんのエントリです。
Unityネタ。自機のカメラ追尾と壁のあちら側を見えないようにさせる処理をやってみた、という内容です。
このキャラアップで見てみたいですね、かわいい予感がする。
12月22日 プログラミング・フォロ for micro:bit を組み立てて動かすレポート
プログラミング・フォロ for micro:bit を組み立てて動かすレポート - れれのーと うるとら
再び私です。完全に仕事から逸脱したネタでお送りしました。
このフォロには赤外線センサーがついているんですよね。そう、赤外線センサーがついているんです。うん、だめだ、そこから先の展開がまったく浮かんでこない。（フォロの名誉のために補足しておくと、赤外線センサーを使って追従させる動作をさせたり、障害物を避けて移動させたり、といった応用ができます）
12月23日 New Relic Insights API を使って機能ごとに指標を出してみる
New Relic Insights API を使って機能ごとに指標を出してみる - Qiita
サーバーグループ所属のエンジニア、eramukさんのエントリです。
個人的にぐっときたエントリで、機能ごとの成功率を可視化したことについて書かれています。前職でも一時期New Relicを使っていたのですがApdexが下がったアラートがきても、どこでなにが起きたのか探していくのがなかなか時間がかかるので、本当に本気出してやるぞ！という決意が必要だったんですよね。このエントリみたいに可視化されていると探索範囲がすでに絞りこめているのですごく助かります。探索すること自体に本気出すのではなくてエラー解消するのに本気を使える。これ本当に良い。
12月24日 ユビレジでのgit、githubの使い方
iOSグループ所属のエンジニア、akuraruさんのエントリです。
ユビレジではGitHubを使っていますが、使う時のお作法について、例えばコミットの大きさやPull Requestをどう捉えているかについてわかりやすくまとめられています。チームで開発するときに、ここに書かれているようなことが意識できているかいないかで、開発のすすめやすさが段違いに変わってくると思います。ぜひ参考にしてみてください。
最後に
Ubiregi Advent Calendar 2019。今回が最後のエントリということで、全記事を（私のどうでもいい感想を織り交ぜつつ）あらためてご紹介させていただきました。気になったものがあればぜひ読んでみていただけるとうれしいです。 長々とお読みいただきありがとうございました。これからもどうぞよろしくお願いします。
それではみなさま、メリークリスマス！（25時台ということで、セーフということにしてくださいお願いします）
プログラミング・フォロ for micro:bit を組み立てて動かすレポート
この記事は Ubiregi Advent Calendar 2019 22日目のエントリです。
こんにちは、れれのーとです。
アドベントカレンダーといえばクリスマス。我が家はクリスマスだからといって特に何かすることはないのですが、せっかくなので前々から気になっていたものを自分へのプレゼントとして買ってみました。
今回は「プログラミング・フォロ for micro:bit」を組み立てて動かすところまでのレポートをお送りしたいと思います。
箱が届いた
今回はスイッチサイエンスのショップから購入しました。
在庫ありとのことで、すぐに荷が届いて受け取ってみると
組み立てが必要というのは商品ページにも書いてあったのでわかっていたのだが、思ったよりコンパクトな箱。箱を開いてみると
これは完全にプラモデルだ。プラモデルはだいぶ昔にやっていましたが、私が組んでいたのは寺とかの建造物がメインでロボはほとんど経験がないです。ひさしぶりで少しドキドキしますが組み立てにチャレンジすることにします。
組み立てる
箱の中にはパーツと組み立て説明書がはいっているので、説明書に従って組み立てます。パーツはこんな感じです。
必要な工具はニッパー、ドライバー（No.1）、ハサミ。これらは付属品に含まれていないので自分で用意します。
バリ取りにはカッターの方が個人的に慣れているのでカッターも用意しておきました。
説明書にも書いてありますが、似たような形状のパーツが多いため、組み立てるときに切り離した方がやりやすいです。
準備ができたら、説明書読む、パーツを切り離す、バリ取りする、組み立てる、を繰り返していきます。
説明書読む、パーツを切り離す、バリ取りする、組み立てる
胴体、足、腕、頭、と組み立てていって
できた
組み立ては大体2時間くらいかかるとのことでしたが、のんびりやっていたので3時間くらいかかっちゃいました。
モーターのコネクタにピニオンギアを入れるところが一番難関でしたが（ニッパーの持ち手部分などでたたくと入れやすいです）、説明書がとてもわかりやすいので難しいところはなかったです。
電源をいれる
電源をONにすると、Hello!とあいさつされたのちにスイッチの説明をしてくれます。
micro:bitにはスイッチボタンが2つあるのですが、ここを押せばそのボタンを押せますよって教えてくれるんですね、やさしいです。顔部分のLEDはmicro:bitのLEDがそのまま使用されます。
電源がONになることは確認できたので、フォロをプログラミングで動かすべく、プログラミングをしていきます。
動きをプログラミングする
実はmicro:bitを選んだのは環境構築をしたくないという理由。micro:bitはオンラインエディタが使えます。
足部分のモーターやセンサーの動作確認を兼ねて、スイッチサイエンス プログラミング・フォロ for micro:bit のページにサンプルプログラムがあるので、ダウンロードしてUSB経由でmicro:bitにインストールして実行。おー動く動く。ちゃんと組めていることが確認できました。
Scratchは初めてだったんですが、直感的で知識ゼロでもすぐに慣れることができる。JavaScriptモードもあるのでもうちょっと慣れたらJavaScriptでもやってみたいと思います。
あいさつさせてみる
こんなに簡単に動かせるプログラミング・フォロ for micro:bit。サンプルプログラムでお披露目というのもちょっと勿体ないのであいさつには見えないあいさつのような動きをつくりました。この動きに含まれている操作は「LED操作」「前進」「音を出す」の3つです。エディタだとこんな感じ。
実際に動くところはこちらの動画をご覧ください。
最後に
無事にプログラミング・フォロ for micro:bitを動かすことができました！
今回は触れませんでしたが、ちょっとしたメロディを奏でたり赤外線センサーも使えるので、何か思いついたらやってみようかと思います。特別な環境構築もいらないので、電子工作が初めてという方は最初の一歩にちょうどよいかもしれない。
私の手元にはmicro:bitがまだ複数枚あるので、今度は生活の役に立つなにかか、何の役にも立たない何か（現時点でノーアイディア）を作ってみる予定です。
個人的障害対応心得集
この記事は Ubiregi Advent Calendar 2019 13日目のエントリです。
こんにちは、れれのーとです。
気づけばブログを放置して2年強。某スタートアップからさらに転職しまして、ひさしぶりの記事がアドベントカレンダーのエントリです。 遅刻しちゃいましたごめんなさい。
さて、アドベントカレンダーといえばクリスマス。クリスマスといえば障害対応。
システムエンジニア時代、華やぐ街の雰囲気にのまれ「障害対応も終わったしケーキでも買っちゃおうかな」とホールケーキを買って帰った思い出がよみがえります。2日間かけて1人で1ホール食べました。
今回は9社経験するうちに培われてしまった障害対応時に意識している心得のようなものを綴ってみます。
違和感をつぶやく
「なんかここがおかしい気がするのでちょっと見てみるわ」とか「なんかここが気になるので見てみている」とチャットでぼそっとつぶやくようにしています。実は障害の予兆だったというときに「そういえばこいつがこんなこと言ってたな」という情報がある状態から障害調査にはいることができます。なにもなかった場合は「ごめん気のせいだった」とつぶやくことになりますが、障害がないということなのでそれはそれでよし。
作業内容を時間軸で記録、共有する
障害が発生したシステムを復旧するために、ここのデータがこうなっていれば辻褄が合うはずだけどーとデータを直接変更したりとか、以前にあった手順を再度行うことが度々発生します。それで復旧すれば問題ないのですが、復旧しない場合がたまーにあります。データでもプログラムでも設定でも、何か変更を行う場合はその変更をいつ行ったか、を記録しておくことで「どういう状態からどういう状態に変化したのか」「その結果どういう矛盾が発生し続けているのか」など解析するのに役立ちます。「こういう変更をするよ」ということを共有することで、周囲からのレビューを受けてもらえる効果もあります。
障害報告書を作成する必要がある場合、「経緯」として障害発生から対応が完了するまでにやったことを記す必要があり、作業記録はその時にも役立ちます。
復旧させてから原因調査をする
障害が発生した時に優先すべきは復旧のはずなのですが、つい原因調査に夢中になってしまうことがあります。 復旧に入る前に原因調査に必要そうなものをとりあえず保存して復旧を優先しましょう。 なお、これは私が新卒の時に先輩SEからよく言われていたことだったりします。（ホームトレーディングシステムの開発運用で、取引時間内に発生した場合は1秒でも早い復旧が求められるため、本当によく言われていました）
できるだけ一人で対応しない
大規模障害では「障害内容を調査する」「復旧する」「障害が発生した原因調査をする」という他に、他社・他部署からの問い合わせ対応も発生します。 一人で対応するのは至難の業ですので、障害対応班と連絡班に分かれて対応することで、障害対応班が復旧作業に集中しやすくなります。
ただし、深夜帯など一人で対応せざるをえない状況になってしまうことがあります。 そのような時は作業状況を逐次チャットに流しておくことで、翌朝の対応状況連絡や対応引継ぎの助けになります。 （深夜や寝起きのテンションで、うっかり作業ミスをしていないかのチェックを自分で後から行うこともできます）
長期間にわたる障害の場合はクライアントや他部署に一定間隔で連絡をいれる
長期間にわたる障害ではユーザー側も「サービスなしでのオペレーションをどうするか」「（さらにエンドユーザ―がいる場合）エンドユーザーへの対応をどうするか」を決定する必要があります。復旧見込みが立っている場合はそれを伝えればよいのですが、復旧見込みが立てられない場合は1時間ごとなど間隔を決めて（進捗がないとしても）定期連絡をいれるとユーザー側もどう対応するか決定をする手助けになります。また、一定間隔で連絡をいれることで、ユーザー側・システム側双方の問い合わせ対応時間を削減することもできます。
待ち時間がある場合は障害報告書を作成しはじめる
開発・運用会社が自社ではない場合、調査結果連絡までの時間は待ち時間になってしまいます。また、そのような体制で開発・運用を行っている場合、障害報告書の運用があることが多いこともあり、待ち時間中に経緯をまとめながら障害報告書を作成しはじめるようにしています。これをやっておくことで長期化した場合でも「障害報告書（第n報）」「障害報告書（最終報）」など、報告書を速やかに出すこともできるようになります。
監視グラフを毎日見ておく
「障害の兆候発見」に関する心得です。 いきなりどーんと障害が発生するケースもありますが、だいたいはちょっとした変化からはじまるケースが多いように感じます。 「あれこんなログ見たことあるっけ？」とか「CPUの使用率がなんかよくわからんとこで跳ねてるなー」とか「I/O待ちのキューがいやにたまってるなー」とか。 監視ツールが出してくれる各種グラフ、アクセス解析ツールが出してくれるグラフなど、普段の状態のグラフの波形を知っておくだけでも、ちょっとした違いに気づくことができます。
サービスの使われ方を普段から把握しておく
社内向けの障害報告書を作成する場合、ビジネスの損失額の算出を求められることがあります。webサービスの場合、障害発生期間中の想定ユーザー数、想定PV数や販売数などから算出を行うため復旧が完了してから算出します。「土日だからいつもより販売数は少ないはず」とか「昼の時間帯はアクセスのピーク」などの雰囲気を知っていると、おおよその見当をつけることができます。また、運営を担当する他部署などとも障害に対する温度感が合いやすくなるため、会話の波長が合い、協力してもらえるなーと感じることがあります。
障害対応が完了したら「お疲れさまでした」と互いの健闘を称えあって通常モードにもどる
心得ではなく前職のチームでやっていたことの紹介です。前職のチームでは人数が少なかったこともあり、障害発生時は開発の手を止めて全員で調査にあたることもありました。特に誰かがやろうと言って始めたわけではないのですが、障害対応が完了したら「お疲れさまでした」と頭を下げてあいさつをし、通常モードにもどるという流れがありました。切り替えがはっきりするのと、謎の団結感も出るのでおすすめです。
問い合わせ対応をした後で記録を必ず残す
これは今のチームで実施されていることです。どのような内容の問い合わせがあって、どのような手順を行って解決したのか、対応を行わなかったことも含めて、記録として残すところまでが問い合わせ対応として扱われています。これを続けていることで、過去に同様の障害があった時に、対応者以外でも過去の記録を参考にして対応を行うことができています。また、対応しなくて済んだものについても「なぜ対応の必要がないのか」ということが仕様理解につながるため、非常に貴重な情報源となっています。
最後に
障害をいち早く発見し、できるだけ早く復旧状態に持っていくには「システムの全体構成をなんとなくレベルでもよいので把握しておくこと」「普段のシステム状態を知っておくこと」「複数の視点からシステムを見つめること」が大切と実感することが多いです。 そもそも障害が発生しないシステムであることに越したことはないのですが、さまざまなシステムと連携することで成立するシステムが多くなっている現在の状況では、障害が発生するのは当然だという前提で開発運用を行っていく方が時代に合っているのではないでしょうか。
心得としてまとめたものを眺めてみると、当たり前のことしか書いていなかったことに気づきましたが、当たり前だからこそ心に留めて行動できればよいのかなと感じました。雀の涙ほどでも参考になったり助けになったことがあれば幸いです。
カンファレンススタッフの時に持っていったら安心だったものリスト
こんにちは、れれのーとです。
技術系カンファレンスが多くなってきた最近、みなさまいかがお過ごしでしょうか。4年か5年くらいスタッフとして参加した経験から「スタッフの時にこれを持って行ったら安心だったぞ！」と感じたものをつらつらと挙げてみます。 ※モバイルバッテリーを追加しました
担当ポジション
受付担当9割、セッション担当1割くらい。
持って行ってよかったもの
小さくて身につけていられるバッグ
カンファレンス会場内を上へ下へ左へ右へと移動することが多いです。
という条件を満たすバッグがあると貴重品の紛失・盗難の心配が少なくて済むのでおすすめです。ヒップバッグは狭い通路で人とすれ違う時など引っかかることがあるので大きさには少し注意が必要。
はおりもの
会場や季節によりますが室内の冷房が強いことがたまにあります。パーカーやカーディガンなどのはおりものが1枚あると安心です。また、おうちに帰れる時間は夜で冷え込むことがあるのでそういうときにも安心です。
服を2-3枚程度収納できるバッグ
スタッフTシャツを着用することがほとんどのため、家から着ていった服と、前述のはおりものを収納できるバッグが必要です。 余談ですが、カンファレンス帰りに東京駅で東京ばな奈買ったりとか、おみやげを買っていれるのにも便利です。
ペットボトルカバー
カンファレンス参加者の数に比例してスタッフの数も多くなります。多くなればなるほどペットボトル飲料のチョイスも被ります。ペットボトルカバーやホルダーなど、自分のペットボトルとわかる目印があると安心して水分補給ができます。とはいえ、服収納用バッグにいれる方法でもこの要件は満たせます。バッグに入れる場合、特に夏場は水滴で他のものが濡れないように薄手のタオルや手ぬぐいが1枚あるといいです。余談ですが、選ばれたのは～で有名なお茶飲料が私は大好きです。
ボールペン、紙
メモ用です。小さくて身に着けていられるバッグに収納できると最高です。万が一備品に紛れて紛失したときに後悔しないよう、高級ボールペンは避けた方が無難かと思います。特に受付だと配布資料やネームホルダーなど机上の物が多くて紛れやすいので放置すると危険です。
モバイルバッテリー
スマホを多く使うときはぜひ。
軍手（すべりどめつき）
会場設営をすることがある場合は軍手があるといいみたいです。
履き慣れた靴
- 立っている時間が長いときがある
- 机や椅子を移動したりすることがある
ということで、履き慣れた靴を履いていることが多いです。
（特に女性向け）Tシャツインナーの着用
スタッフTシャツですが透けやすいものに当たることがあります（色が薄い、布が薄いなど）。キャミソールやタンクトップ、その他シャツなどTシャツインナーの着用をおすすめします。ぽんぽん冷やしやすい方も着用をおすすめします。
チラリズムを誘発しないボトムス
かがんだときにチラリズムを誘発しないボトムスだと安心して配布物補充作業に集中できます。
ハンカチ・ティッシュ・ばんそうこう
ごはん食べるときに手を汚したりすることもありますし、鼻水がでるかもしれない。 絆創膏は（＞＜。ってなるから書かないけど）ちょっとやらかしたとき用。2枚以上あれば靴擦れにも対応可能。
（雨の場合）タオル・靴下・ビニール袋
濡れるので。ビニール袋は濡れたものをいれるときに必要。あと、突然吐き気を催した時にも使えるし普段から1枚バッグに忍ばせておくとグッジョブです。
あとがき
後半は完全にスタッフ関係ないですがこんなところでしょうか。 あくまで個人の経験によるものですが、あまり言及されることがないので書いてみました。
持ち物とはまったく関係ないですが、カンファレンス終了後やスタッフ打ち上げを終えて帰るときに「1年後にまた会いましょう」とスタッフ同士言い合って解散するのがとても好きです。1年待たずして再会することもありますが（笑）
今年も「1年後にまた会いましょう」と笑って言えるように、スタッフとして参加者の方が楽しめるカンファレンスになるようがんばります。
きんきょうほうこく
こんにちは、れれのーとです。
と、あいさつした方がやっぱり調子が出るなぁと思いました。こんにちは。 ひさしぶりの更新なので近況報告をつらつらとやりたいと思います。
転職しました
8月からスタートアップで働いています。 退職エントリを書こうかとも思ったのですが、ここ数回は特に書いていなかったのと前職について下手に触れると「こんぷらいあんすがー」となりそうなのでまあいいかーと。サービス志向のジェネラリストタイプなことを買っていただいたと思っているので、自分が役に立てる場所はどこかなーという感じで手探りしつつ日々お勤めしております。Ruby on Railsチュートリアルすすめながらgitのコマンド叩いたときはひさしぶりにエンジニアっぽいと思いました。
そうそう、Rubyを使う会社に入社しました。さよならPHP、さよならJava。
Macを使うことが多くなりました（ただし会社のみ）
転職を機に会社でMacを使うようになりました。また、入社前に自分でもMBPを買ってみました。最初の2週間くらいは少々戸惑いましたが、設定を変更したりしたこともあって、思ったよりすぐに慣れました。会社ではMac+Realforce+Logicoolのマウスで作業していますがそこまで苦戦することもなく快適です（たまにControlとOptionとCommandを間違えますが）。 自分で買った方は15インチで重く、ターミナルでコマンド叩きたい時以外はSurface Pro 4を開いていることが多いです。顔認証に慣れてしまうとパスワードや指紋は面倒になってしまいというのもあり。家にいる場合、MBPは気合が入っている時以外はあまり開いていないことに気づきました（汗
イカやってます
スプラトゥーン2は楽しいです。スプラトゥーン2は楽しいです。 大事なことなので2回言いました。なおWii Uは持っていないので今作からです。 ちなみに、うちのイカちゃんがいちばんかわいい。
定期健診の大切さを思い知る
先月の有給休暇中、半年ぶりに歯医者さんへ行ったところ今までポスターでしか見たことのないような、非常に大きな虫歯が見つかりました。 もうちょっと遅かったら手遅れだったそうです。これからは特に痛みや染みることがなくても3ヶ月ごとに歯医者さんへ行こうと心に固く決めました。
そろそろアレやります
4月にお流れにした時に「5月くらいでー」とか言っていたら秋近くになっていました。 9月か10月くらいにソフトドリンクエンジニアの集いをひさしぶりにやろうかともくろんでいます。 お知らせはtwitterで。
タイトルをもどしました
気まぐれで「れれろぐ」にしましたが、やはり気まぐれで「れれのーと」にもどしました。 前回は「はいぱー」だったので今回は「うるとら」をつけています。 れれのーとのれれのーとをこれからもどうぞよろしくお願いします。
2017年も宜しくお願い申し上げます
2016年の総まとめ記事を書こう書こうと思っていたら明けちゃった(๑´ڡ`๑)
2017年もどうぞよろしくお願いします。
Hello KUSANAGI! 初めてのKUSANAGIでWordPressを構築してみたレポート
この記事は KUSANAGI Advent Calendar 2016 17日目のエントリです。 kusanagi.tokyo
ちょっとしたツイートをきっかけに「書いてみませんか？」というオファーをいただいて参戦しました、れれのーとです。 今回はアドベントカレンダー駆動構築ということで、KUSANAGIさんとWordPressを構築するまでの様子をレポートします。
そもそもKUSANAGIとは
プライム・ストラテジー株式会社が開発している超高速なWordPressの仮想マシン。 なるほど仮想マシン？使ってみたいけどどうするの？なんか買うの？と思ったら、各種クラウドサービス、VPSサービスで使うことができるんですってよ奥さん。 kusanagi.tokyo
対応サービスが多かったので迷いましたが、今回は手元にさくらのクラウドのクーポンがあったのでそちらにお世話になります。
チャレンジ用環境の準備をする
だいたいこんな流れでさくらのクラウドの会員とクーポンの利用登録。
- クラウドサービスの利用者としての会員登録をする
- ユーザアカウントを作成する
- クレジットカードを登録する
- 使用するクーポンを設定する
これでクーポンを適用できたぞ。さくらさんありがとう。 ここまでが前準備で、次からはいよいよKUSANAGIさんとの対面準備へ。
KUSANAGI×WordPressのセットアップ
仮想マシンを作成する
サーバ追加するときのディスクイメージ選択で「パッケージ」を選択すると「KUSANAGI」がリストに出てくるので選択。 そこから先はKUSANAGIのサイトに手順が載っているので、手順に従ってサーバを作成。
作成が完了したらコンソールでサーバにログインすると「KUSANAGI」の文字が。 こんにちはKUSANAGIさん、よろしくお願いします。 ここまでの所要時間は2時間くらい。各サービスの料金表比較とアカウント名考えるのに9割ほど使いました。
KUSANAGIの初期設定をする
初期設定手順もKUSANAGIのサイトを見ながら。ここから先はKUSANAGIコマンドを使ってwebサーバの選択や各種パスワードなどの設定を対話式で行っていく。 今回は構築すること自体が目的なので、デフォルトのnginx/HHVMを選択。
ここの設定は5-10分くらいで完了。1時間くらい経過していたのは、部屋がぽかぽかしていて寝落ちしたせい。
KUSANAGIのプロビジョニング
ここもKUSANAGIコマンドで。ドメインなどの設定をしていく。とここで衝撃の事実が判明。
WordPressの印象が強すぎたけどconcreat5などにも対応しているんですね。 今度はWordPress以外でもやってみよう。この手順は数分で完了しました。
WordPressのインストール
設定したFQDNにブラウザでアクセスしたらWordPressのインストール画面がでたー！
ここからは通常のWordPressのインストール手順とほぼ同じなのでぽちぽちして終了。これも数分で完了。 管理画面にアクセスできたところで今回の構築ミッションは完了！お疲れさまでした。
感想
黒い画面で少々タイプすることは必要なものの、ほぼKUSANAGIのサイトに書いてある手順で構築完了。 入力項目が定まっているので、入力項目シートとか用意しておけば（あとサーバさえあれば）本当に短時間で環境構築できちゃいますね。
今回はテスト構築なのでパフォーマンス検証等は行いませんが、最初からもろもろ設定済みの状態でセットアップできるのはありがたい。 「なに？自社のコーポレートサイト作りたい？WordPressがいい？いいけどそれなりのアクセスくるの？チューニングとか必要なんじゃないの？他業務もあるしこっちでやるんだったら優先度低ね！」とか、超申し訳ないなぁと思いつつもそんな感じの対応を取らないといけない場面に遭遇したことが過去にある身としては「設定済みです！」と言い切ってくれているのは本当にありがたくてうれしいです。
業務でWordPressを運用している場合、プラグインを入れるときにセキュリティとか大丈夫かな、と心配したりしたこともある身としてはKUSANAGI Ready プロジェクトの今後の行方も気になるところです。
お付き合いいただきありがとうございました。
「消せる紙」でタスクかんばんはじめました（2011） を当時を思い出しつつあらためて書いてみた
2011年に「消せる紙でタスクかんばんはじめました」という記事を書いて、ちょっと反響があったことがありました。
「れれろぐ」に改名した際に過去記事はすべて削除してしまったのですが、5年経った今でもなお「消せる紙 タスクかんばん」で検索するとB!KUMAで登録された私の記事がトップにでてくる状態なので、探し訪ねてきた方のために当時を思い出しつつあらためて書いてみます。
事の発端
来月からチームタスクを表出させるためにタスクかんばんをやってみない？ってメンバーに言ってみた。
— れれのーと(@rerenote) 2011年7月29日
「タスクかんばんはじめました」
— れれのーと(@rerenote) 2011年8月1日
かんばん始めた宣言をした日の23:00に「ぼっちなう」とか「アラートメール多い」とか翌日2:00頃に「タクシー」とかツイートしていて複雑な気持ちになりましたが本題から逸れるのでさておいて、そもそも「タスクかんばん」を始めた理由について、当時の私は次のように書いております。
私がリーダーを務めているチームは全員メインプロジェクトがバラバラで、チーム？という状況なのです。 そのような状況のため、プロジェクトタスク優先になりがちでチームタスクを後回しにしがちなのですよね。 うちのチームの場合「チームタスクの後回し＝お互いがお互いにフォローできない」ということなので、 一応リーダーとしては「このままじゃちょいとまずい」と思って始めてみました。
当時は自分を含めて4名のチームのリーダーを務めていました。
担当するサービスの数が多く属人化がすすみかけていたこと、各メンバーが孤軍奮闘している状態だったので精神負荷が心配だったということもあり、なんとかしてメンバー同士がフォローできる体制をつくりたい、という気持ちが非常に強かったのではないかと思います（ここらへんはあまりよく覚えてないのですが、自分の傾向からこのように感じていた可能性が非常に高いです）。
それにはまず「誰が何と戦っているか」の情報を見えるようにしないと、それには「タスクかんばん」が有効だろうと思ったわけです。
メンバー全員が使ってくれないと意味がなくなってしまうため、導入前にメンバー1人1人に「タスクかんばんやってみない？」と問いかけました。1人でも渋ったら違う手を考えないとなぁと思いつつ。結果は全員から「やってみる」と回答がありました。こうなったらもうやらない理由はない。
「タスクかんばん」に必要なもの、付箋とそれを貼るスペースです。付箋を何度も剥がしたり貼ったりするので耐久性を考えるとホワイトボードが適任。 しかし、当時のオフィスには執務室内に余っているホワイトボードがなかった。 タスクかんばんがチームに合わない可能性もあるので「手軽にやめられる」ことも重視したい、かんばんのためにホワイトボードを買うことはしたくなかった。 そもそも自席近くにホワイトボードを置くスペースがなかった。
どうにかならないかと見渡したところ、マグネットは使えないけど壁はあった。 この壁を利用してできるだけお金をかけずに作れないかと考えた結果、目を付けたのが当時話題だった「消せる紙」だったわけです。
作ったかんばん
実物を見れば一目瞭然なので、まずはこの写真をどうぞ。
模造紙サイズの消せる紙をマスキングテープで壁に貼り付ける。これだけ。 マスキングテープだから壁をあまり傷めずに済みます。 レイアウト枠もマスキングテープなので、貼り直しOK（少し慎重に剥がす必要はあるけど）。レイアウト変更もどんとこい。
かんばんのレイアウトについてですが、チームに合わせたアレンジを加えています。
導入結果
当時のツイートから（誤字は修正しています）。
そういや、最初に説明してやってみただけだけど、促さなくてもみんなタスクかんばんの前に行くようになってるな…今気づいた。 いやまだ始めて3日しか経ってないんだけど。
タスクかんばんは「Doing」の欄だけちょっとアレンジして、各メンバーの欄を設けた。 チームメンバーが同じプロジェクトに属さないのでここだけアレンジしたのです。 で、やってみてまだ3日目だけど、今までと違うなと思ったのが「1つのタスクに集中すること」が自然とできるなということ。
席を立ってかんばんの前へ移動 →ToDoの中からタスクをえらぶ →Doingの自分の欄に貼る →席に戻る →選んだタスクをやる →終わったら席を立ってかんばんの前へ →Done/Waiting(レビュー待ち)/Pendingに貼る →次のタスクを選ぶ→（くりかえし）というリズムができる。
タスクをやっている途中にちょいちょい割り込みは入る。 でもメインのタスクはこれだよってかんばんが教えてくれるから、メインのタスクを見失わない。 割り込みから新たな作業が生まれたらその作業を付箋に書いてDoingに貼る。 Doing2つになる。でもどちらか1つが終わればDoingは減る。
おそらく大分アレンジした状態での導入ではあるんだが、 割り込み入りまくってDoingにいっぱい付箋が貼られていると、 あれ○○さん、何が起こってるの？って見た人が気付ける。 今まではこんなの気付けなかったんだ。
この他に、かんばんの前で短時間のスタンディングミーティングをして、全員がかんばん全体を見るタイミングを作るようにしたりしました。
最終的にはかんばんの他にA4サイズの消せる紙を追加して、このような形に進化。
後日談（当時の記事には書かれなかったこと）
タスクかんばんを導入したことで誰が何をやっているか、自分が今何に集中しているのかわかるようになったという他に、他部署の人からチームとチームメンバーが何をやっているか（そして、自分が依頼した作業の状況がどうなっているのか）わかるようになった、という感想をいただいたりしました。
導入からしばらくして、チームの仕事内容やスタイルが変わり、私のチームは自然とタスクかんばんから卒業しました。 チームに変化があったからこそ自然に卒業という流れになった、と思っています。だからやってよかった。
最後に
タスクかんばんを始めたいけどエリア確保に困っている方や、タスクかんばんのレイアウト（5年前と比べると今では探せば多く出てきますが）を見てみたい方など、何かのきっかけでこの記事にたどり着いた方に、この記事が少しでもお役に立てばよいなぁと願いつつ。 自分としても振り返りとして、たまにはこういう記事を書いてみました。