きんきょうほうこく

こんにちは、れれのーとです。 半年ぶりの更新なので近況報告をつらつらとやりたいと思います。

転職しました

今年の6月からBASE株式会社で働いています。前職の在籍期間が3年と私にしては長く、久しぶりの転職で入社したばかりの頃は挙動不審になっていましたが、3か月も過ぎてだいぶ慣れてきました。とても良い人良い環境に囲まれてのびのびとやらせていただいています。スロースターターっぷりを大いに発揮しており申し訳ないところもありますが、これから恩返しできれば。

今回はエンジニアリングマネージャーとして入社しました。会社によって求められるものが違うという説明しづらい性質を持つ職種ですが、なんかいい感じにするために必要だと思ったことをやるのが仕事というのはエンジニア時代からずっと変わらないのと、最初からエンジニアリングマネージャーとして入社するのも2回目なので通常運転でお送りできています。

2022年9月時点でサーバーサイドエンジニア大募集中なので興味のある方はぜひ話を聞きに来てね。全社的にエンジニア大募集中ですし、プロダクトマネージャーやデザイナー、ビジネス職も大募集中です。とにかく大募集中。

スピーカーを買い替えました

2年前の「リモートワークはじめてました」でBOSEのSoundLink Mini IIを使っていると書いたのですが、本体のケーブル接続部分が不安定になり、さらに充電クレードルが行方不明で充電することができなくなったのでMarshallのEMBERTONに買い替えました。良い音で非常に気に入っています。

marshall.kanjitsu.com

カンファレンススタッフやってます

ここ数年お休みしていた技術カンファレンスのスタッフ業を再開しました。

昨年は協賛企業側の担当者として複数のカンファレンスに関わっていました。今年はハイブリッド開催が増えスタッフ募集も増えたので再開。先日開催されたiOSDC Japan 2022、来週開催されるPHP Conference Japan 2022にスタッフ参加してますのでどうぞよろしくお願いします。

ご時勢の影響で必要な持ち物が少し増えたので持ち物リスト記事を更新しました。ご参考にどうぞ。 rerenote.hatenablog.com

最近プレイしているゲーム

スプラトゥーン3が話題ですが、腱鞘炎が心配なので、この記事を投稿した後に「アイドルマネージャー」を買って遊ぼうと思います。Switchでやります。 playism.com

以上、きんきょうほうこくでした。今後もよろしくおねがいします。

個人的炎上プロジェクト対応心得集

この記事は Ubiregi Advent Calendar 2021 10日目のエントリです。

qiita.com

こんにちは、れれのーとです。

今年もアドベントカレンダーの時期になりました。突然冬らしい気候になりましたが、みなさまいかがお過ごしでしょうか。わたしはいつも通りです。

さて、アドベントカレンダーといえばクリスマス。クリスマスといえば障害対応。と書いたのが2年前。 今年は過去の思い出から。プロジェクトが赤々と燃え盛るさなか、追加メンバーとして指名され急遽参加することになったり、突然プロジェクトリーダーを引き継ぐことになった時のことを思い出しながら、炎上プロジェクトの鎮火を命じられて途中参画した時の心得のようなものを綴ってみます。

取り急ぎプロジェクトのタイトルをなんとなくおぼえる

ものすごく当たり前のことを書きましたが、世の中には途中でプロジェクトのタイトルが変わるケースが存在します。過去のタイトルで呼ぶことに慣れてつい口が動いちゃう人もいます。過去を忘れるには時間が必要なのです。過去につけられていたタイトルも知っておくといろんな立場の人と話すときに役立ちます。

最初から全部完璧に理解しようとしない

相手は炎上プロジェクトです。すでになにかしら瓦解していますし全員迷子です。 プロジェクトに参画したばかりの時は覚えることがいっぱいですし、覚える順序が存在するものもあります。最初は全体像の輪郭を把握することに専念しましょう。

具体的には

• 何を成すプロジェクトなのか（タイトルからある程度予想はできる）
• 何をもってプロジェクトが完了したことになるのか
• 自分はなぜこのプロジェクトに呼ばれたのか

を最初に把握しておくとその後の理解の助けになります。 プロジェクトリーダー、プロジェクトマネージャーとして召喚された場合は内容を聞きながら5W2Hを整理していきます。

• When（プロジェクトを完成させますと言っちゃった日付、時期）
• Where（このプロジェクトのゴールはどこですか？）
• Who（プロジェクト責任者と関係者）
• What（これはやるねって言っちゃった項目）
• Why（このプロジェクトは誰得なんですか？）
• How（Whatの実現方法、どれくらい見えてます？）
• How match（予算はおいくらですか？、どこまで金積めますか？）

大事なことなので2回言いますが、相手は炎上プロジェクトです。すでになにかしら瓦解していますし全員迷子です。上記が全部きれいに決まっているわけがありません。きれいに決まってたら火なんかでません。 むしろ何も決まっていないケースすらあります。何が決まっていないのかを把握すること、決まっていないことを決めていくことが鎮火への大きな一歩になります。

ここらへんは決めの問題なので、実際に起きていることは責任者が「決める気がない」「決められるだけの材料がない」です。ただ待ってても何も決まることはないので、「決めるのに必要な材料を責任者が理解できるように渡す」「責任者の了承を得て自分で主導権を取ってしまう」「強く訴え続けて決めてもらう」の選択になることが多いです。後者は精神力勝負です。

知らないことは知らないとはっきり伝えて教えてもらう、言葉の意味を推測しない

我々は完全に迷子になっています。できる限り正確な情報を入手する必要があります。 知らない単語、知らない情報が出てきたときは見栄を張ったり知ったかぶりをせず、知らないので教えてくださいとはっきり言いましょう。「わたしはこの情報を持っていません、理解できていません」を相手に伝えることで、炎上プロジェクト中に起きやすい無茶振りミッションから自分の身を守ることに繋がります。

うっかりやり過ごしちゃった場合、すみませんわかった気になっていたのでもう一度教えてくださいと正直に申告してリカバリーしましょう。後になればなるほどわからないピースの上にピースが積み重なってしまい、動かすピースの数が多くなってしまいます。勇気を出して正直に申告しましょう。ただし訊くタイミングについて、特にお客様が同席している場所で訊くことは意図せず信用低下に繋がってしまうこともあるので考慮します。

「わたしはここにいます」を自ら発信する

共同作業なので。一番手っ取り早いのは「自分の現在地（完了、未完了の項目報告、どんぶり勘定でも構わないので完了予定、ブロッカー）」を定期的に発信することです。タスクをやり終わったときに発信じゃなくて定期的に発信するのがコツです。我々は全員迷子です。「わたしはここにいます」という信号を出し続けることが大事です。

眠くなったら寝る

相手は炎上プロジェクトです。すでになにかしら瓦解していますし全員迷子です（n回目）。 そのような過酷な状況で生き延びるのに体力はとても重要です。 体力ゲージがなくなってきたときに真っ先に故障するのは判断力です。致命的な判断ミスを犯してしまうとやり直しの量が増えてしまいます。とてもつらい。

あと1時間耐えればすべて鎮火することが明らかな場合、寝ないで頑張るは検討の余地がなくはないです。が、最後の最後でやらかすというリスクも潜んでいるので慎重に判断しましょう。寝ましょう、寝てください。

わたしの場合、寝る前にビタミンC飲料を飲んで寝ていました。回復量がちょっと多くなる気がします（あくまで個人の感想です）。昼仮眠をとる場合はホットアイマスクを使うと身体が温まるのでおすすめです。

常にゴール地点までの距離を明確にする

炎上プロジェクト終盤で意識していることです。「これだけやったらゴールですよ」を常にメンバー全員で共有しましょう。終盤で絶対やってはいけないことは「ゴールまでの道のりを遠くすること」です。なんでかというと純粋に心が折れるからです。よっぽどのことがない限りは避けるのが無難かと思います。

あとがき

綴っていくにつれて昔の炎上プロジェクトの記憶が徐々に鮮明に蘇り、わたしの心が耐えられなくなってきたのでこのへんで止めておきます。世界のあらゆる炎上しちゃったプロジェクトが少しでも早く鎮まることを祈りつつ、これから少しでも炎上プロジェクトが発生しないことを心から祈りつつ、また、この記事が炎上しないことを切に願いながらおしまいとします。

長々とお読みいただきありがとうございました。

リモートワークはじめてました

この記事は Ubiregi Advent Calendar 2020 1日目のエントリです。

qiita.com

こんにちは、れれのーとです。今年もAdvent Calendarの季節がやってまいりました。
前回の記事が昨年のAdvent Calendarの最終日ということで、このブログも1年ぶりに更新です（震え声）

さて、2020年はこれまでの環境が大きく変わり、今までの当たり前をアップデートする必要に迫られた年でした。仕事環境でいえば、オフィスに出社する頻度が減ってリモートでやることが増えたり、オンラインミーティングが普通になってきたり。

今までユビレジでは開発部署のみ週1回のリモートワークが許可されていたものの、タスクかんばんが紙だったり、社内ミーティングがオフラインのみだったりと「オフィスに出社していることが前提」で各種業務を想定していました。

そんなユビレジも今年2月後半の状況を鑑み「これから何が起こるかわからない」ということで、3月に2回、全社での在宅勤務訓練を経て3月末から全部署において在宅勤務を推奨、7月から恒久的に原則在宅勤務、10月からは勤務場所の制限を撤廃し原則フルリモートワークと制度を変更してきました。それに伴いオフィスの全座席をフリーアドレスに変更し、設備等の関係でオフィスで行う必要がある業務を担当する場合や、自宅よりオフィスの方が集中できる場合など、オフィスへの出勤も各自で決められるようになりました。正社員はもちろん、業務委託の方もリモートワークをしていただいています。※2021年秋以降はさらに状況が変わっています

開発部署においても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日目のエントリです。

qiita.com

こんにちは、れれのーとです。
アドベントカレンダー最終日は「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

ラズパイとMESHで始めるお手軽IoT - Qiita

サーバーグループ所属のエンジニア、d-ebiさんによるIoT記事。MESHのボタンをおすとSlackに通知される仕組みの実装レシピです。
来年からプログラミング教育が必修化されることもあり、MESHなどの電子ガジェットが手に入りやすくなりました。家電量販店でも売っているので、デザインがおしゃれで気になっている方もいるのではないでしょうか。「でも、どんなことできるんだろう？」という方はこの記事を読んで試してみるというのはいかがでしょう？

12月5日 葛飾北斎になりたい

葛飾北斎になりたい - Qiita

またまたフロントエンドエンジニアのコジャさんの登場。ml5jsを使っていろんな画像を葛飾北斎っぽくしてみたという内容です。個人的に一番お気に入りのネタなのでぜひ見てください。

12月6日 プログラミングを始めて1年

プログラミングを始めて1年 - Qiita

部署の枠を超え、カスタマーサクセス部の原さんが登場。
ご自身がプログラミングを始めて感じたことや、どのようなことをやったのか、が書かれています。 本当にこつこつと取り組んでいるその姿勢に頭が下がる...。見習おう。

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日 会社で流しの使用状況を可視化しました

会社で流しの使用状況を可視化しました - Qiita

サーバーグループ所属のエンジニア、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の使い方

ユビレジでのgit、githubの使い方 · GitHub

iOSグループ所属のエンジニア、akuraruさんのエントリです。
ユビレジではGitHubを使っていますが、使う時のお作法について、例えばコミットの大きさやPull Requestをどう捉えているかについてわかりやすくまとめられています。チームで開発するときに、ここに書かれているようなことが意識できているかいないかで、開発のすすめやすさが段違いに変わってくると思います。ぜひ参考にしてみてください。

最後に

Ubiregi Advent Calendar 2019。今回が最後のエントリということで、全記事を（私のどうでもいい感想を織り交ぜつつ）あらためてご紹介させていただきました。気になったものがあればぜひ読んでみていただけるとうれしいです。 長々とお読みいただきありがとうございました。これからもどうぞよろしくお願いします。

それではみなさま、メリークリスマス！（25時台ということで、セーフということにしてくださいお願いします）

プログラミング・フォロ for micro:bit を組み立てて動かすレポート

この記事は Ubiregi Advent Calendar 2019 22日目のエントリです。

qiita.com

こんにちは、れれのーとです。
アドベントカレンダーといえばクリスマス。我が家はクリスマスだからといって特に何かすることはないのですが、せっかくなので前々から気になっていたものを自分へのプレゼントとして買ってみました。 今回は「プログラミング・フォロ for micro:bit」を組み立てて動かすところまでのレポートをお送りしたいと思います。

箱が届いた

今回はスイッチサイエンスのショップから購入しました。 在庫ありとのことで、すぐに荷が届いて受け取ってみると

箱は平たい。プラモデルの箱より長い。

組み立てが必要というのは商品ページにも書いてあったのでわかっていたのだが、思ったよりコンパクトな箱。箱を開いてみると

これは完全にプラモデルだ。プラモデルはだいぶ昔にやっていましたが、私が組んでいたのは寺とかの建造物がメインでロボはほとんど経験がないです。ひさしぶりで少しドキドキしますが組み立てにチャレンジすることにします。

組み立てる

箱の中にはパーツと組み立て説明書がはいっているので、説明書に従って組み立てます。パーツはこんな感じです。 必要な工具はニッパー、ドライバー（No.1）、ハサミ。これらは付属品に含まれていないので自分で用意します。 バリ取りにはカッターの方が個人的に慣れているのでカッターも用意しておきました。 説明書にも書いてありますが、似たような形状のパーツが多いため、組み立てるときに切り離した方がやりやすいです。

準備ができたら、説明書読む、パーツを切り離す、バリ取りする、組み立てる、を繰り返していきます。 説明書読む、パーツを切り離す、バリ取りする、組み立てる 胴体、足、腕、頭、と組み立てていって

できた

組み立ては大体2時間くらいかかるとのことでしたが、のんびりやっていたので3時間くらいかかっちゃいました。 モーターのコネクタにピニオンギアを入れるところが一番難関でしたが（ニッパーの持ち手部分などでたたくと入れやすいです）、説明書がとてもわかりやすいので難しいところはなかったです。

電源をいれる

電源をONにすると、Hello!とあいさつされたのちにスイッチの説明をしてくれます。

スイッチの位置を矢印で教えてくれるフォロ

micro:bitにはスイッチボタンが2つあるのですが、ここを押せばそのボタンを押せますよって教えてくれるんですね、やさしいです。顔部分のLEDはmicro:bitのLEDがそのまま使用されます。

micro:bit。中央にLED、左右にスイッチがある。

電源がONになることは確認できたので、フォロをプログラミングで動かすべく、プログラミングをしていきます。

動きをプログラミングする

実はmicro:bitを選んだのは環境構築をしたくないという理由。micro:bitはオンラインエディタが使えます。
足部分のモーターやセンサーの動作確認を兼ねて、スイッチサイエンス プログラミング・フォロ for micro:bit のページにサンプルプログラムがあるので、ダウンロードしてUSB経由でmicro:bitにインストールして実行。おー動く動く。ちゃんと組めていることが確認できました。 Scratchは初めてだったんですが、直感的で知識ゼロでもすぐに慣れることができる。JavaScriptモードもあるのでもうちょっと慣れたらJavaScriptでもやってみたいと思います。

あいさつさせてみる

こんなに簡単に動かせるプログラミング・フォロ for micro:bit。サンプルプログラムでお披露目というのもちょっと勿体ないのであいさつには見えないあいさつのような動きをつくりました。この動きに含まれている操作は「LED操作」「前進」「音を出す」の3つです。エディタだとこんな感じ。

実際に動くところはこちらの動画をご覧ください。

この投稿をInstagramで見る

プログラミング フォロ for micro:bit を動かしてみました。 #microbit #プログラミングフォロ

れれのーと(@rerenote_jp)がシェアした投稿 - 2019年12月月22日午前3時54分PST

最後に

無事にプログラミング・フォロ for micro:bitを動かすことができました！
今回は触れませんでしたが、ちょっとしたメロディを奏でたり赤外線センサーも使えるので、何か思いついたらやってみようかと思います。特別な環境構築もいらないので、電子工作が初めてという方は最初の一歩にちょうどよいかもしれない。
私の手元にはmicro:bitがまだ複数枚あるので、今度は生活の役に立つなにかか、何の役にも立たない何か（現時点でノーアイディア）を作ってみる予定です。

個人的障害対応心得集

この記事は Ubiregi Advent Calendar 2019 13日目のエントリです。

qiita.com

こんにちは、れれのーとです。

気づけばブログを放置して2年強。某スタートアップからさらに転職しまして、ひさしぶりの記事がアドベントカレンダーのエントリです。 遅刻しちゃいましたごめんなさい。

さて、アドベントカレンダーといえばクリスマス。クリスマスといえば障害対応。

システムエンジニア時代、華やぐ街の雰囲気にのまれ「障害対応も終わったしケーキでも買っちゃおうかな」とホールケーキを買って帰った思い出がよみがえります。2日間かけて1人で1ホール食べました。

今回は9社経験するうちに培われてしまった障害対応時に意識している心得のようなものを綴ってみます。

違和感をつぶやく

「なんかここがおかしい気がするのでちょっと見てみるわ」とか「なんかここが気になるので見てみている」とチャットでぼそっとつぶやくようにしています。実は障害の予兆だったというときに「そういえばこいつがこんなこと言ってたな」という情報がある状態から障害調査にはいることができます。なにもなかった場合は「ごめん気のせいだった」とつぶやくことになりますが、障害がないということなのでそれはそれでよし。

作業内容を時間軸で記録、共有する

障害が発生したシステムを復旧するために、ここのデータがこうなっていれば辻褄が合うはずだけどーとデータを直接変更したりとか、以前にあった手順を再度行うことが度々発生します。それで復旧すれば問題ないのですが、復旧しない場合がたまーにあります。データでもプログラムでも設定でも、何か変更を行う場合はその変更をいつ行ったか、を記録しておくことで「どういう状態からどういう状態に変化したのか」「その結果どういう矛盾が発生し続けているのか」など解析するのに役立ちます。「こういう変更をするよ」ということを共有することで、周囲からのレビューを受けてもらえる効果もあります。

障害報告書を作成する必要がある場合、「経緯」として障害発生から対応が完了するまでにやったことを記す必要があり、作業記録はその時にも役立ちます。

復旧させてから原因調査をする

障害が発生した時に優先すべきは復旧のはずなのですが、つい原因調査に夢中になってしまうことがあります。 復旧に入る前に原因調査に必要そうなものをとりあえず保存して復旧を優先しましょう。 なお、これは私が新卒の時に先輩SEからよく言われていたことだったりします。（ホームトレーディングシステムの開発運用で、取引時間内に発生した場合は1秒でも早い復旧が求められるため、本当によく言われていました）

できるだけ一人で対応しない

大規模障害では「障害内容を調査する」「復旧する」「障害が発生した原因調査をする」という他に、他社・他部署からの問い合わせ対応も発生します。 一人で対応するのは至難の業ですので、障害対応班と連絡班に分かれて対応することで、障害対応班が復旧作業に集中しやすくなります。

ただし、深夜帯など一人で対応せざるをえない状況になってしまうことがあります。 そのような時は作業状況を逐次チャットに流しておくことで、翌朝の対応状況連絡や対応引継ぎの助けになります。 （深夜や寝起きのテンションで、うっかり作業ミスをしていないかのチェックを自分で後から行うこともできます）

長期間にわたる障害の場合はクライアントや他部署に一定間隔で連絡をいれる

長期間にわたる障害ではユーザー側も「サービスなしでのオペレーションをどうするか」「（さらにエンドユーザ―がいる場合）エンドユーザーへの対応をどうするか」を決定する必要があります。復旧見込みが立っている場合はそれを伝えればよいのですが、復旧見込みが立てられない場合は1時間ごとなど間隔を決めて（進捗がないとしても）定期連絡をいれるとユーザー側もどう対応するか決定をする手助けになります。また、一定間隔で連絡をいれることで、ユーザー側・システム側双方の問い合わせ対応時間を削減することもできます。

待ち時間がある場合は障害報告書を作成しはじめる

開発・運用会社が自社ではない場合、調査結果連絡までの時間は待ち時間になってしまいます。また、そのような体制で開発・運用を行っている場合、障害報告書の運用があることが多いこともあり、待ち時間中に経緯をまとめながら障害報告書を作成しはじめるようにしています。これをやっておくことで長期化した場合でも「障害報告書（第n報）」「障害報告書（最終報）」など、報告書を速やかに出すこともできるようになります。

監視グラフを毎日見ておく

「障害の兆候発見」に関する心得です。 いきなりどーんと障害が発生するケースもありますが、だいたいはちょっとした変化からはじまるケースが多いように感じます。 「あれこんなログ見たことあるっけ？」とか「CPUの使用率がなんかよくわからんとこで跳ねてるなー」とか「I/O待ちのキューがいやにたまってるなー」とか。 監視ツールが出してくれる各種グラフ、アクセス解析ツールが出してくれるグラフなど、普段の状態のグラフの波形を知っておくだけでも、ちょっとした違いに気づくことができます。

サービスの使われ方を普段から把握しておく

社内向けの障害報告書を作成する場合、ビジネスの損失額の算出を求められることがあります。webサービスの場合、障害発生期間中の想定ユーザー数、想定PV数や販売数などから算出を行うため復旧が完了してから算出します。「土日だからいつもより販売数は少ないはず」とか「昼の時間帯はアクセスのピーク」などの雰囲気を知っていると、おおよその見当をつけることができます。また、運営を担当する他部署などとも障害に対する温度感が合いやすくなるため、会話の波長が合い、協力してもらえるなーと感じることがあります。

障害対応が完了したら「お疲れさまでした」と互いの健闘を称えあって通常モードにもどる

心得ではなく前職のチームでやっていたことの紹介です。前職のチームでは人数が少なかったこともあり、障害発生時は開発の手を止めて全員で調査にあたることもありました。特に誰かがやろうと言って始めたわけではないのですが、障害対応が完了したら「お疲れさまでした」と頭を下げてあいさつをし、通常モードにもどるという流れがありました。切り替えがはっきりするのと、謎の団結感も出るのでおすすめです。

問い合わせ対応をした後で記録を必ず残す

これは今のチームで実施されていることです。どのような内容の問い合わせがあって、どのような手順を行って解決したのか、対応を行わなかったことも含めて、記録として残すところまでが問い合わせ対応として扱われています。これを続けていることで、過去に同様の障害があった時に、対応者以外でも過去の記録を参考にして対応を行うことができています。また、対応しなくて済んだものについても「なぜ対応の必要がないのか」ということが仕様理解につながるため、非常に貴重な情報源となっています。

最後に

障害をいち早く発見し、できるだけ早く復旧状態に持っていくには「システムの全体構成をなんとなくレベルでもよいので把握しておくこと」「普段のシステム状態を知っておくこと」「複数の視点からシステムを見つめること」が大切と実感することが多いです。 そもそも障害が発生しないシステムであることに越したことはないのですが、さまざまなシステムと連携することで成立するシステムが多くなっている現在の状況では、障害が発生するのは当然だという前提で開発運用を行っていく方が時代に合っているのではないでしょうか。

心得としてまとめたものを眺めてみると、当たり前のことしか書いていなかったことに気づきましたが、当たり前だからこそ心に留めて行動できればよいのかなと感じました。雀の涙ほどでも参考になったり助けになったことがあれば幸いです。

カンファレンススタッフの時に持っていったら安心だったものリスト

こんにちは、れれのーとです。

技術系カンファレンスが多くなってきた最近、みなさまいかがお過ごしでしょうか。4年か5年くらいスタッフとして参加した経験から「スタッフの時にこれを持って行ったら安心だったぞ！」と感じたものをつらつらと挙げてみます。

※ ご時勢にあわせて2022年9月にアイテムを追加しました。また、必須級/あれば便利で分類して記事を再構成しました

わたしがよく担当するポジション

受付担当8割、セッション担当2割くらい。

必須級

小さくて身につけていられるバッグ

カンファレンス会場内を上へ下へ左へ右へと移動することが多いです。

• お財布とスマホと鍵（貴重品類）を収納できる大きさである
• 自分の身体から離さずにつけていられる(サコッシュ、ウエストポーチやヒップバッグなど)
• フリーハンドでいられる

という条件を満たすバッグがあると貴重品の紛失・盗難の心配が少なくて済むのでおすすめです。ヒップバッグは狭い通路で人とすれ違う時など引っかかることがあるので大きさには少し注意が必要。

服を2-3枚程度収納できるバッグ

スタッフTシャツを着用することがほとんどのため、家から着ていった服と後述のはおりものを収納できるバッグが必要です。余談ですが、カンファレンス帰りに東京駅で東京ばな奈買ったりとか、おみやげを買っていれるのにも便利です。貴重品は前述の身に着けていられるバッグに入れておきましょう。

はおりもの

会場や季節によりますが室内の冷房が強いことがたまにあります。パーカーやカーディガン、ストールなどのはおりものが1枚あると安心です。また、夜になると冷え込むことがあるのでそういうときにも。

モバイルバッテリー

SlackやDiscordなどを連絡手段として使います（無線を使うケースもありますがコアスタッフのみなど限定していることもあるので運営によります）。充電スポットは用意されていても人数と比べて少ないか、ないことがほとんどですので不安であれば持っていきましょう。事前のバッテリー充電とケーブルも忘れずに。

履き慣れた靴

荷物を運ぶ作業があり、立っている時間も長いので歩きやすく履き慣れた靴がおすすめです。

Tシャツインナーの着用

色が薄い、布が薄いなど透けやすい場合があります。キャミソールやタンクトップ、その他シャツなどTシャツインナーの着用をおすすめします。

かがんでも大丈夫なボトムス

かがんだときに肌が見えないボトムスだと安心して作業に集中できます。

ハンカチ・ティッシュ・ばんそうこう

ごはんを食べるときに手を汚したりすることもありますし、鼻水がでるかもしれない。 絆創膏はちょっとやらかしたときや靴擦れに。

マスクの替え・ゴミ袋

午前/午後で取り替えたら快適だったので追加しました。 使った後のマスクは衛生の観点からご自身で用意したゴミ袋へ。

（雨の場合）タオル・靴下・ビニール袋

ビニール袋は濡れたものをいれる用。突然吐き気を催した時にも使えるし普段から1枚バッグに忍ばせておくのがおすすめです。

あれば便利

軍手・滑り止め手袋

机や椅子、段ボールに入れた機材類などとにかく物を運ぶことが多いです。なくても大丈夫ですがあると手を保護できてよいでしょう。

スマートウォッチ

あると通知に気付けて便利です。充電を忘れずに。

ボールペン、紙

メモ用です。備品に紛れて紛失したときに後悔しないよう、高級ボールペンは避けた方が無難かと思います。特に受付だと配布資料やネームホルダーなど机上の物が多くて紛れやすいので放置すると危険です。ここ最近はスマホでメモを取ることが多いので必要度を下げました。

ペットボトルカバー

カンファレンス参加者の数に比例してスタッフの数も多くなります。多くなればなるほどペットボトル飲料のチョイスも被ります。ペットボトルカバーやホルダーなど、自分のペットボトルとわかる目印があると安心して水分補給ができます。服収納用バッグにいれる方法でもこの要件は満たせるため「あれば便利」に分類しています。バッグに入れる場合、特に夏場は水滴で他のものが濡れないように薄手のタオルや手ぬぐいが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

対応サービスが多かったので迷いましたが、今回は手元にさくらのクラウドのクーポンがあったのでそちらにお世話になります。

チャレンジ用環境の準備をする

だいたいこんな流れでさくらのクラウドの会員とクーポンの利用登録。

1. クラウドサービスの利用者としての会員登録をする
2. ユーザアカウントを作成する
3. クレジットカードを登録する
4. 使用するクーポンを設定する

これでクーポンを適用できたぞ。さくらさんありがとう。 ここまでが前準備で、次からはいよいよKUSANAGIさんとの対面準備へ。

KUSANAGI×WordPressのセットアップ

仮想マシンを作成する

サーバ追加するときのディスクイメージ選択で「パッケージ」を選択すると「KUSANAGI」がリストに出てくるので選択。 そこから先はKUSANAGIのサイトに手順が載っているので、手順に従ってサーバを作成。

作成が完了したらコンソールでサーバにログインすると「KUSANAGI」の文字が。 こんにちはKUSANAGIさん、よろしくお願いします。 ここまでの所要時間は2時間くらい。各サービスの料金表比較とアカウント名考えるのに9割ほど使いました。

KUSANAGIの初期設定をする

初期設定手順もKUSANAGIのサイトを見ながら。ここから先はKUSANAGIコマンドを使ってwebサーバの選択や各種パスワードなどの設定を対話式で行っていく。 今回は構築すること自体が目的なので、デフォルトのnginx/HHVMを選択。

ここの設定は5-10分くらいで完了。1時間くらい経過していたのは、部屋がぽかぽかしていて寝落ちしたせい。

KUSANAGIのプロビジョニング

ここもKUSANAGIコマンドで。ドメインなどの設定をしていく。とここで衝撃の事実が判明。

KUSANAGI、WordPress以外にも対応していた

WordPressの印象が強すぎたけどconcreat5などにも対応しているんですね。 今度はWordPress以外でもやってみよう。この手順は数分で完了しました。

WordPressのインストール

設定したFQDNにブラウザでアクセスしたらWordPressのインストール画面がでたー！

ここからは通常のWordPressのインストール手順とほぼ同じなのでぽちぽちして終了。これも数分で完了。 管理画面にアクセスできたところで今回の構築ミッションは完了！お疲れさまでした。

感想

黒い画面で少々タイプすることは必要なものの、ほぼKUSANAGIのサイトに書いてある手順で構築完了。 入力項目が定まっているので、入力項目シートとか用意しておけば（あとサーバさえあれば）本当に短時間で環境構築できちゃいますね。

今回はテスト構築なのでパフォーマンス検証等は行いませんが、最初からもろもろ設定済みの状態でセットアップできるのはありがたい。 「なに？自社のコーポレートサイト作りたい？WordPressがいい？いいけどそれなりのアクセスくるの？チューニングとか必要なんじゃないの？他業務もあるしこっちでやるんだったら優先度低ね！」とか、超申し訳ないなぁと思いつつもそんな感じの対応を取らないといけない場面に遭遇したことが過去にある身としては「設定済みです！」と言い切ってくれているのは本当にありがたくてうれしいです。

業務でWordPressを運用している場合、プラグインを入れるときにセキュリティとか大丈夫かな、と心配したりしたこともある身としてはKUSANAGI Ready プロジェクトの今後の行方も気になるところです。

WordPress！って聞いたらKUSANAGIも一緒！

お付き合いいただきありがとうございました。