リモートワークをするにあたって購入したもの

最近、日本中でコロナウィルスが猛威を振るっています。わたしが勤めている会社では、基本的には育児などの理由でしかリモートワークは許可されていませんでしたが、「可能な限りリモートで仕事してくれ」という形で期間限定で解禁されている状態です。

今まで、趣味のプログラミングは近所の図書館でやればいいやと割り切って物置みたいな部屋に住んでいたのですが、これを機にそれなりに整えました。もし、他の方にもなにか参考になれば嬉しいです。

椅子

実際に腰が痛くなってきたため、いい椅子を買うことにしました。以前、社内で話題になっていたエンボディチェアを購入しました。

[正規品] ハーマンミラー エンボディチェア ベース:グラファイトカラー/フレーム:グラファイトカラー/キャスター:カーペット用/ファブリック(バランス):ブラック CN122AWAAG1G1BB3513

最近メルカリがきっかけで中古商品を買うのにハマっているので、いろいろ探した結果楽天のショップで購入しました。多少ねじがゆるくなっているのと、肘置きがボロかったのですが、まあ実用では気になりません。

item.rakuten.co.jp

裏面がカエルっぽくてかわいいです。

いい椅子買った🐸 pic.twitter.com/8UCM3oTzDV

— 黒めだか (@takeshi0406) 2020年3月15日

送料込みで65000円弱でした。

デスク

サンワダイレクト ゲーミングデスク 幅120×奥行60cm 鏡面天板 モニターアーム取付対応 ブラック 100-DESK039BK

これはAmazonで買いました。こちらの記事を読んだ覚えがあります。

arma-search.jp

こちらは新品で購入し、9980円でした。

加湿器

喉が痛くなることが多いのと、家にいる時間が増えそうなので買いました。私が購入したのはこちらのモデルです。

www.biccamera.com

こちらはメルカリで11000円でした。

デスクライト

実際にプログラミングしていると、少し暗く感じたのでデスクライトも買いました。

Koncept AR1000-W-SIL-DSK Z-Bar Solo LED Desk Lamp, Warm Light, Silver by Koncept

こちらはメルカリで2800円でした。

Traybo2.0

たまにあぐらかいてプログラミングしたい時用です。もともと無印の通称「人をダメにするソファ」を持っているので、それと組み合わせて使っています。

Traybo2.0 (トレイボー2.0) ラップトップデスク 膝上テーブル (ライムグリーン)

ただ、店頭で試したところ、yogiboのほうが座り心地が良く、用途が広いように感じました。機会があれば欲しいです。

ホワイトボード

一人カンバンボード用です。基本的に私は忘れっぽいし、実物を使ったほうがやりやすい気がするので買いました。会社でも使いたい。

コクヨ ホワイトボード A3サイズ ポジティ 吊り下げタイプ 縦横両用 P3FB-A3W

こちらと組み合わせて使ってます。

ヤマト 付箋 メモック ロールテープ カッター付き 25mm×10m NORK-25CH-6A

まとめと課題

今の所、リモートワークはけっこう快適です。通勤時間が無くなるだけで、思っていた以上に自分の時間が増えたような気がします。また、家の環境も整えたおかげで（最近サボりがちだった）余暇のプログラミングもはかどりそうです。

また、メルカリや楽天を駆使して中古で購入することで、思っていたよりは安く済ませることができました。いい椅子だけで10万以上かかると思っていたので、全体でそれくらいに収められたのは良かったと思います。

また、ネット通話で適切にコミュニケーションを取る必要があり、それは今の環境だと厳しいかなと思っています。本格的にリモートワークを行うなら、ネット回線がしょぼいのをなんとかするのと、WEBカメラやマイクセットを用意したほうがいいかもしれません。

【本】『みずほ銀行システム統合、苦闘の19年史』を読みました

のんびり読もうとしたのですが、ちょっと高めに設定していたにも関わらずメルカリで売れてしまったので急いで読んでました。

みずほ銀行システム統合、苦闘の19年史　史上最大のITプロジェクト「3度目の正直」

きちんと経営レイヤーで意思決定できていなかったことが原因で、やや雑ですがまとめてしまうと『失敗の本質』にあるような「戦略のミスは戦術でカバーできない」ということだと思えました。また、特に私に刺さった箇所はここです。同じ箇所をツイートしている人がいました。

いくつか刺さる言葉があったが、これが一番刺さった。
「エンジニアは少しの問題が起きても、善意から『自分のところで頑張れば取り返せるはず』と思いがちです。それが結果として大きなトラブルに発展してきました」
くぅ～、深いです。本当にあるあるで深いです。#情シスあるある#読書100冊 15冊目

— 社内情シス奮闘記 & 読書100冊 (@start20204) 2020年2月21日

jbpress.ismedia.jp

【雑記】メルカリに本を60冊くらい出品しました

https://www.mercari.com/jp/u/252084402/

知り合いから「古書店に売るより高く売れるから、メルカリにしばらく出品した後に残ったものを引き取ってもらってる」って聞いたので、私もそうしてみます。私と趣味が合いそうな方は、是非チェックしてみてください。

【雑記】今年は英語をちゃんと勉強します

この間、海外に住んでる友達と久しぶりに会ってその一味と映画を見に行きました。ただ共通の友達が英語ネイティブが多く、ふとした話に全然ついていけずに悔しい思いをしました。あとLINEでの略語表現が全然わからん。

（雑談なので文脈がわかりづらく、例えば「ICカード乗車券付きのクレジットカードを使ってるんだけど、設定の問題でオートチャージ機能が使えてなかったんだ」みたいな話だったそうなので特に難しかった気はするんですが）

なので今年は英語を毎日勉強しようと思います（完）。

【Python】バリデーションを行うライブラリのpydanticが便利だった

同僚からFastAPIを薦めてもらって、バリデーションの機構が便利（そして早い）ということを教えてもらいました。

その中でjsonリクエストのアノテーションに使われているライブラリがpydanticで、FastAPI以外でも、辞書オブジェクトのバリデーションやキャスト、またSQLAlchemyのORMとの組み合わせなどもできるようです。

pydantic-docs.helpmanual.io

これについて記事にまとめようと思ったのですが、今の所特に詰まりどころもなく、日本語の記事ならこちらに素晴らしいものがありました。ですのでこちらを読んでください。

qiita.com

まあ良いライブラリを教えてもらったってことでｗ

【参加レポート】Data Platform Meetup vol.2に参加しました

Data Platform Meetup Vol.2に参加したので、その参加レポートを書きます。

実は既に @ikedaosushi さんが記事を書いているのでそちらを読んでください。よくまとまった記事なので「私は書く必要ないんじゃないか」とも思ってしまったのですが、私が感じたこと + 質疑応答の内容を追記していきます。

blog.ikedaosushi.com

個人的に三行でまとめると↓のような感想でした。

• 社内コミュニティやドキュメントなどの啓蒙活動でスキルやナレッジの伝達を各社努力している
• Redshiftはマジで大変そう(自分はBig Queryにかなり救われている)
• 縦持ち、横持ちはコンテキストによって必要性が変わるので使い分ける(snowflake schema)

私も似た感想でした。

啓蒙活動について

特にpixivの長部さんの発表でよく触れられていました。「分析・データ加工の代行を期待されてしまう」というのは自分たちの会社でも起こっていて、「（悪く言うと）便利屋からどう脱却して専門性を発揮していくか」という話はデータ組織に普遍的なテーマなのかもしれません。

そのためにナレッジ共有の場や教材作成を作ったそうなのですが、個人的にはそこのモチベーションや目標の置き方をどうやっているのか気になりました。実際そういう質問もあり、それには「元々問題意識を持った人の寄り合いが部署になった経緯があるのでメンバーのモチベーションが高く、問題になってない」というような趣旨の回答されていました。

RedShift VS BigQueryについて

CookpadのInuzukaさんの発表。RedShiftの同時接続数などの制約をどう回避して便利に使うかという発表もありました。技術的な話としては面白かったのですが、自分たちのチームでGCPのBigQueryを利用しているところではあまり問題になったことがない箇所（課金額の見積もりちゃんとしてないと困る程度）ではありました（一応同時実行数などの制限もあるのですが、自分たちのユースケースだと全然余裕です）。

ただ自分たちのチームでは、DWHがBigQueryで、（機械学習も含めた）システムの開発や運用をAWSで行っているので、データやモデルをどうやり取りするかといった別の問題はあるように思います。実際にはそこまで考えて技術選定する必要があると思います。

各発表のQ & A

できるだけメモを取ったつもりですが、抜け漏れや要旨が間違っている点があればご指摘ください🙏

プロダクト中心のデータ駆動を推進していくために大事なこと

Q. 学習教材はエンジニア向け以外にもあるか？

A. ビジネス職向けのSQLのチュートリアルもある。もちろんエンジニア向けも用意している。

Q. BigQueryは従量課金なので、自由に使わせるのは課金額の点で怖くないか？

A. 裁量にまかせているものの、監視はしている。特に前日のクエリの課金額順の通知はしていて、問題のあるクエリを書いた人に指摘はしている。

Q. 教材のモチベーション維持ってどうやってる？直接ビジネスに影響しない箇所なので、KPIの設定など苦戦するのでは？

A. 元々、組織の発端が問題意識を持った人の寄り合い状態から始まっていて、メンバーのモチベーションも高いので大きな問題になってない。

Q. 民主化のためにLOOKERを利用しているとのことだが、LOOKMLは誰が定義してる？

A. リポジトリは統一していて、そこに各部署のエンジニアがコミットしてる。また規約の定義やコードレビューはデータ駆動推進室が行っている。

データを用意しただけだと使われないので、使ってもらえるようにした努力

Q. 事業部制を取っている会社でデータを集約してるのすごい。ガバナンスを効かせるのって工夫したのでは？

A.\ データの追加はこちら側がやってる。プロダクトのDBのコピーと、個人情報のマスキングして入れるのが大変だった。ただ要望を定型フォーマットで出してくれるように工夫してる。

Q. （クックパッドのコミッタの方から）dmemoの要望ってありますか？

A. Redshiftに直接繋いでいて、ActiveRecordのinteger型がRedshiftと互換性がないので独自に潰す必要があった点が大変だった。

Q. 具体的に「こういうことをしたら喜ばれた」って話はありますか？

A. データの使い方といってもいろいろあって、分析・機械学習などの応用がいくらの価値を創出したか出しづらいんですけど…。ただ、インプレッションログの表示順位を工夫した（受注確率が高い顧客を上にもってくるなど）。

DWHを活用したクックパッドの機械学習プロジェクト

時間が取れなかったため質疑応答の時間なし。他の発表も短い時間だったので、もう少し一つ一つの発表をじっくり聞きたかった気がします…。

アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由

Q. クライアントサイドの時刻ってイベント発生時刻と送信時刻のどちらか？クライアント側で時刻が狂ってる場合はどう扱ってる？

A. 時刻は基本的にイベント発生時刻で、タイムゾーンはすべてUTC。イベント発生時にオフラインだった場合のデータが後でバルク送信された場合に過去のデータが変わることはあるので、3日さかのぼってデータマートを作ってる。

DWH デザインパターン 〜 テーブル設計編 〜

Q. テーブルの設計で、ディメンションとファクトを分けるのが習慣としてある人とない人がいて、「なぜこう持たないの？」って衝突があるはず。そこは乗り越えた？

A. レビューや「規約に乗るとこういうメリットがある」と説明することで乗り越えている。また規約に則って作ると便利になるように補助するツールを実装している。

Q. 「指標」部分はどうしてるのか？（ここの質問の意図がメモできませんでした…）

A. 具体的な指標の話は（業務の話になるので）外で話しづらいが、再利用しやすい形にはしてる。指標のカタログを作っているイメージ。

【プログラミング】mix-inやtraitより継承のほうが優れているケースは存在するのか？（が分からなかった）

kiito.hatenablog.com

↑最近こちらに悩んでいます。感覚的には積極的にmix-in（と委譲）を使ったほうがモデリングしやすいのですが、もしかすると継承のほうが便利なケースがあるかも分かりません。それで以下の2つを調べていました。

• 「inheritance is not subtyping」問題
• Rustのtraitが導入されるまでの議論を追う（端的に言うとRustでなぜクラスの継承の機能が実装されなかったのか追う）

ところが、前者はきちんと追おうとすると型理論の話が分からないし、後者もGitHubのissueなどにあるんじゃないかと思ったのですが見つけられていません。一応それっぽい議論はあったのですが、こちらも「継承がないとGUIプログラミングきつくない？」「いやいやそんなことないよ」程度の内容に見えて、もう少し具体的じゃないときつい感じします。

internals.rust-lang.org

一旦諦めて他のことやろうと思います。