2020年の振り返り
こんちは、じぬ です。 人のを見てると自分も書きたくなったので振り返ります。（アドベントカレンダーもこんなノリで書いた）
と言っても仕事とその他自分にとって大きかった変化はこっちですでに書いてます。なのでそれ以外のことを。
ゲームの時間が増えた
特に4月から6月あたりはこれが顕著でした。仕事もフルリモート、それ以外の趣味も基本停止になっていて家で過ごすしかできなかったので。 18時半で業務を終えてそのまま PS4 を起動する日々でした。（当時はひたすら荷物を運んでました）
読書の時間が減った
電車の時間が減ったので。なので取り急ぎ目を通したいものは土日で読むようになりました。学生時代に本を読みすぎた反動から家では読まないようにしていたのを解禁です。 また仕事にからむことは、仕事中に30分ほどで目を通す、というのも悪くなかったです。
携帯通信の消費量が減った
今まで 5GB/月くらいだったのが 1GB 未満になりました。まぁ外出が劇的に減ったのでそれはそう。 たまたまその直前に通信量に応じて支払うタイプに変えたので、だいぶ安くなりました。
料理することが増えた
せっかくリモートで家にいるのに、仕事後に食事で外出するのがめちゃくちゃ億劫でした。 そのため家での食事を考えるようになり、コンビニ弁当→ご飯炊いて冷凍おかず→自炊、という風に変化していきました。
自炊はもっぱら鍋を作ってます。同僚に勧められたのですが、お鍋の素とそれっぽい素材を放り込めばできる、というのが想像以上に楽です。 やってみると面白くなって、色々アレンジしたくなります。お気に入りはトマトペーストとチーズです。 そろそろ魚介類も試そうかと思ってます。正直、いろいろ買いすぎて冷凍おかずより食費は上がってきています。
料理を気楽にやれているのは食器洗い乾燥機の存在が大きいです。たかが5分短縮できるだけなんですが、自分にとっては体感がかなり向上してます。 サブスクでレンタルしてるんですが、そろそろミニマム期間を過ぎるので自分で購入しようと思ってます。
生ゴミを家に置く状態が起きるようになったのでスマートゴミ箱を買いました。 料理やおやつのたびにビニール袋を縛り直す手間が減ったので地味に QOL が上がりました。ただちょっと小さかったです。
ほかにも家の環境が整った
アドベントカレンダーにあるように電動昇降机、ゲーミングチェア、食器洗い乾燥機が導入されました。
運動不足の対策にリングフィットアドベンチャーを始め、空間を用意するために片付けをしつつヨガマットなど買いました。 1日 50kcal を基準に続けています。楽しいんですが、運動負荷マックスだとそれなりにしんどくもあります。あとリアル友人のガチ勢から毎日のプレイ量を聞いて戦慄しています。
布団のマットを買いました。 実家で古びていたやつを持ち出して8年感使ってました。薄いのでずーっとフローリングの固さを感じながら眠ってました。 新しく買ったのは高さが 10cm 近くあり、まったく床を感じません。最高です。
リモート会議用にマイクを買いました。が、これはすぐに返品しました。 自分のベストとしてはイヤホン無しで過ごせるのがベストなんですが、スピーカーとマイクを分けるとどうしてもハウリングして上手くいきませんでした。 自分にとってはマイク付きイヤホンで充分です。ただこの辺は自分がちゃんと理解できてないので、もうちょっといいやり方があるかもしれません。
Alexa を購入しました。友人から激推しされ、不要になった LiveSmart というスマートリモコンを譲ってもらいました。 電灯とエアコンの ON/OFF に使ってます。あととりあえず音楽をかけたいときに便利です。まだそこまで劇的な感動は無いかな。 どちらかというと、実家に買って贈りたいなという感じです。
次に欲しいもの
不思議なもので、何かを買うと次の何かを買いたくなります（アカンのでは？）。 いま興味があるのは分割キーボードです。PC 操作で若干ですが手首に負荷がかかっている気がするので、それの解消を試みます。 あとはコーヒーかなぁ。ただ自分は水分量をとりたいので、ミネラルウォーターをがぶ飲みでそれなりに満足しています。
エンジニア的な振り返り
せっかくなのでこういう観点も。 振り返ってみると充電の年というか、将来のために色々と貯めていった1年かなと思います。
そもそもは Unity をガツガツやりたくて今のチームに入りましたが、そういう観点では満たされないところはありました。 が、その一方で関わりが薄かった技術（Web API とか Rails とか DB とか）に触れることができましたし、新規開発に初期から携わるという貴重な経験もできています。
あとは正式に部下を持つことになり、人やプロジェクトのマネジメントについて改めて考えることが増えました。 ちゃんと考えてみると 1on1 って難しいです。結構準備に気を遣ったりしてます。 あと自分なりにプロマネを考えてから向き合うと、改めてスクラムはよくできているなと感じました。この辺は真面目に勉強してみようと思います。
とは言えクライアント技術をやりたいこともあり、自然と業務以外でいかに力をつけるか考えたりもしました（せっかく自宅の作業環境整ったし）。 この辺は楽しく習慣に組み込んでいこうと思ってます。
まとめ
飲み会が減った分のお金を自宅に投資してみましたが、色々と楽しくやれたと思います。 とは言え今年の前半は遊び、後半は残業（地味に忙しかった）に時間を使った感はあるので、次はインプットの2021年にしていきたいです。
【書評】OKR、1on1 関連
@reximology です。 私事ですが中間管理職というやつになりました。と言うわけでマネジメント系のフレームワークについて本を読んだ所感をまとめます。要点を絞りたいので知っている内容は端折っています。
読んだ本はこちら。
OKR
- OKR は日々見返すことで進む方向を見失わないためのフレームワーク
- 評価の時期にだけ見直す、は間違い。今月、今週、今日行う作業が目標に対して進むものか確認するために使う
- 自分を目標に対して縛ってくれる
- 自信度レベルを可視化することでムーンショットの実現に OKR を活かす
- OKR に対して真剣さを求めるため、途中で変更することはしない。結果が失敗ならそれを次に反映すれば良い
シリコンバレー式 最強の育て方
- まずは信頼関係の構築、そのうえで成長支援につなげる
- 言語化できていない問題を見つけるためにあえて時間を取る、ということが大事
- 問題解決ではなく問題発見の場
- 特に希望されていないなら、細かい業務の話はしない。解像度は高くする
- とにかく話を聴ききることで話者のモヤモヤを晴らす
- 会話にゴールを定めなくていい。ただしどんな内容でどこを話しているか、というのは把握する（地図を持っておく、という考え方）
- 毎回褒める。そのための情報収集を常に行う。他者が実際に褒めていることを伝えるのも有効。
- アドバイスはしない。答えを伝えることもしない。あくまで本人の思考を促す
- 部下に上司（自分）を使ってもらう、という感覚でいてもらう
- 質問例：今の仕事の要点、懸念や悩み、今のチームに感じる課題
ヤフーの１ｏｎ１
- まずは承認でいい。話を聴いてくれる、というだけでも信頼関係につながる
- 1on1 の構成要素
- コーチングの質問も技術、試行錯誤と慣れで向上できる
- 分かっていても聴くことに徹するのは難しい。もはやガマンと言ってもいい
感想
OKR については以前も読んでいたので特に違和感なし。OKR の強みを改めてチームの人にも伝えていく必要はある。
1on1 については自分の意識を色々と変える必要がありそう。アイスブレイクはあるにしても、基本的には相手から喋ってもらえるように準備する。 正直まだ雑談と進捗確認がメインになってるので、時間管理や会話の案内を組み立てる。話を促せるようになることで、相手の話す割合をもっと増やしていく。
【書評】DevRel エンジニアフレンドリーになるための3C
読書感想文です。いつもより流し読みです。（本を速く読む実験です）
DevRel とは、自分たちのプロダクトをサービス利用者である開発者に使ってもらう、浸透させるための取り組み全般と理解しています。
グッときたところ
- DevRel に必要な 3C (code: 技術力, contents: 技術以外も含めた発信, community: ユーザコミュニティ) の言語化
- デベロッパージャーニー（ユーザが自分たちのプロダクトを通してどのような経験をしていくのか）の重要性
- そもそも DevRel という仕事に求められる能力（技術力、発信力、信頼性、速さ、アクティブさ）、プロとしての手腕の定義
雑感
自分は SDK 開発の中で DevRel と言われるような取り組みをしてきましたが、その中での曖昧とした部分を言語化してくれている本でした。書かれているとおりですが、発信には技術への理解が必要になります。技術と発信を両立するには、作業の速さやユーザに対するアクティブさも必要になる仕事です。
個人的には、3C の中でも contents が特に重要と思っています。 技術に限らず、ユーザ目線でどんなものが必要かを自分たちが理解し、それに応えられる発信を続けていくことが重要だからです。
2019年の振り返り
まとめている人が多いので、自分も今年を振り返ってみる。
お仕事
今のチームに入ったのが2019年1月なので、ちょうど1年になる。 以前と比べると、次の点は自分にとって新鮮だった。
- Unity
- 非ゲーム
- 新規開発（検証 & 実装）
活動として大きかったのは、社外へのアウトプットを強く意識して動いたこと。（このブログもそう） 自分としてもやりたかったことだし、チームからもそういう動きを期待されていたのでちょうど良かったと思う。
具体的な内容と振り返りは会社のブログに書いている。
下期に入って Unity 以外の技術に触れることも増えてきた。 自分はどちらかというと「とりあえず作ってみる」というフットワークが良くない方だと思うので、新しい技術でもさっと調べてサクッと作る、みたいなふるまいをもっと身につけていければと思っている。
まぁまたゲームにも関わりたいので Unity は引き続きやっていくつもり。
マネージメント
以前は30歳くらいになったらマネージャーやるんだろうなぁとか思っていて、まぁ現状やってはいるのだが、思ったほど振り切ってはいない。 少人数チームなので全員実装が必要なこともあるし、やはり自分で手を動かしてものを作るのは楽しい。 会社的にもプレイングマネージャーが多い印象なので、参考にできる人も多い。
とは言え、社外カンファレンスでマネージャーについて学んだことは非常に良かったと思う。 業界全体で様々な課題、それに対する挑戦が存在していると認識できたことや、これまでの知見がどんどん言語化、フレーム化されていっているということも興味深かった。
実装がやりたくない、上手くいかないから仕方なく、などのネガティブな動機ではなく、チームの力を最大化したい、プロダクトを成功させたい、というポジティブなモチベーションを知ることができて本当に良かったと思う。
とは言え言語化が進んでいるというのはマネージメントに関して学ぶことが多いという話でもあるので、ここは技術面とバランス良くやっていきたい。
それ以外
CEDEC などの発表を通して、新しく AI 技術に興味を持った。 以前よりも AI を手段として活用している事例も増えており、社内で使われた言葉だが「AI の民主化」が進んでいると思う。
まだ本を読んでみただけなので、年始はそのあたりでなにか実装を試してみたいと思う。（と宣言してやる気を出す）
技術以外
あんまり人に言っていないが（隠してもいないが）アルトサックスをやっている。 最近はアドリブ（曲に合わせて自由に吹く）がどうにかできるようになってきたので楽しい。 基礎練が終わり、もっと自由に吹くために改めて基礎を学ぶというフェーズになってきた。 元々ゲーム曲がやりたいという理由で始めた楽器だが、実際どうにか吹けているので非常に良い。
来年
1番は趣味と勉強のバランスをとる、というか勉強をもっと趣味に寄せたいと思う。 勉強と思っていると捗らないし身につかないので、何が楽しいのか、何ならより自然に取り組めるのか、を見極めて面白くやれればいいなと思う。
csc で Unity 用 DLL を作る
表題の通り、csc で DLL を作成するにあたって調べた内容を備忘録として残します。
以前書いた記事の続編的な内容です。
検証した環境は次の通りです。
はじまりはじまり
事の起こりは、mcs による DLL 作成時に下記のエラーが起きたことです。
error CS1644: Feature `default literal' cannot be used because it is not part of the C# 7.0 language specification
原因になったのは次のような書き方です。
public void Hoge(Vector3 position = default)
原因はエラーで指摘されているように、default リテラルが C# 7.1 以降でないと利用できないことです。
どうやら、mcs はデフォルトだと C# 7.0 以前のものを利用しているようです。
エラーの解消
この現象の解決策は二つあります。 一つは型推論に頼らず、スクリプトで型を記述することです。
public void Hoge(Vector3 position = default(Vector3))
もう一つは、mcs 実行時に言語バージョンをオプションで指定することです。
csc への乗り換え
前記事で検証したとおり、Unity 2018 ではコンパイラとして csc が利用されています。
せっかく DLL 作成コマンドを修正するのであれば、そのまま Unity と挙動を合わせたいと考えました。
まず、Unity 内部で利用されている csc は次のものです。（ファイルをリネームするとエラーになります）
/Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/Tools/Roslyn/csc
試しに現在使っている mcs と入れ替えると、次のエラーが大量に発生します。
error CS0518: 定義済みの型 'System.Void' は定義、またはインポートされていません error CS0518: 定義済みの型 'System.ValueType' は定義、またはインポートされていません error CS0518: 定義済みの型 'System.Object' は定義、またはインポートされていません
Visual Studio のオプションを流用
対処としては、必要な DLL を参照するオプションをつける必要があります。 具体的な内容は、前回の記事で Visual Studio を用いて DLL を作成した際の処理を参考にします。
- mscorlib.dll
- System.dll
- SystemCore.dll
これら三つを参照することで先ほどのエラーは起きなくなります。
その他の気になるオプション
そのほかの参照に関連するオプションとして次のものがあります。
結論から言うと、今回の検証の中ではこれらがあってもなくても挙動は変わりませんでした。
まず、noconfig は csc.rsp という参照を記述するファイルの設定を無視するものです。
ただし、利用している csc と同じディレクトリには同ファイルは存在していませんでした。
nostdlib+ は mscorlib を参照しなくなるオプションです。
Visual Studiio の例では mscorlib を明示的に指定しているため、いずれにせよ参照は必要だと思われます。
今回の場合、意図せぬ参照が発生するよりは必要最低限に絞った方が良いと判断し、これらも付与したコマンドにしていきました。
参照するべき DLL の見極め
Unity 内部で System.dll を検索すると、複数のファイルが存在します。
./Tools/Roslyn/System.dll ./NetStandard/compat/2.0.0/shims/netfx/System.dll ./MonoBleedingEdge/lib/mono/4.5.2-api/System.dll ./MonoBleedingEdge/lib/mono/unity/System.dll ./MonoBleedingEdge/lib/mono/4.7.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5-api/System.dll ./MonoBleedingEdge/lib/mono/4.6.2-api/System.dll ./MonoBleedingEdge/lib/mono/2.0-api/System.dll ./MonoBleedingEdge/lib/mono/4.6-api/System.dll ./MonoBleedingEdge/lib/mono/4.6.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5/System.dll ./MonoBleedingEdge/lib/mono/4.0-api/System.dll ./MonoBleedingEdge/lib/mono/unityjit/System.dll ./MonoBleedingEdge/lib/mono/unity_web/System.dll ./MonoBleedingEdge/lib/mono/unityaot/System.dll ./Mono/lib/mono/unity/System.dll ./Mono/lib/mono/2.0/System.dll ./Mono/lib/mono/unity_web/System.dll
いくつかそれっぽい DLL で検証したところ、次のような結果となりました。
| DLL | 成否 | メモ |
|---|---|---|
| ./MonoBleedingEdge/lib/mono/4.7.1-api/System.dll | 成功 | Visual Studio が使っていたものに近いバージョン |
| ./Tools/Roslyn/System.dll | 失敗 | System 関連でエラーのまま |
| ./MonoBleedingEdge/lib/mono/unity/System.dll | 失敗 | Task 関連のエラー、C# 7.0 未満？ |
Roslyn のものなら上手くいくのではと思っていたので、ここは少し予想外でした。 ただし、上手くいったファイルと比べてみると Roslyn のものはファイルサイズがかなり小さいです。（結果は一部割愛です）
$ ls -a /Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/MonoBleedingEdge/lib/mono/4.7.1-api/System.dll admin 500224 $ ls /Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/Tools/Roslyn/System.dll admin 41472
どちらのファイルも、リネームして参照できない状態にすると Unity でエラーが発生します。 また、Roslyn の System.dll をリネームする（参照できない状態にする）と、4.7.1-api/System.dll を使おうとした時でもエラーが発生します。
このことから、標準的な System の実装は 4.7.1-api/System.dll に定義されており、Roslyn 用の実装が Roslyn/System.dll に定義されていると推測されます。
（これらを示すドキュメントを確認できた訳ではないので、あくまで推測です）
結論
ここまでの検証結果を考慮し、次のようなコマンドを用意しました。
Mono := $(UnityDirectory)/Contents/MonoBleedingEdge/lib/mono/4.7.1-api Csc := $(UnityDirectory)/Contents/Tools/Roslyn/csc LangVersion := 7.3 make_dll: $(Csc) \ -r:$(UnityDirectory)/Contents/Managed/UnityEngine.dll \ -r:$(Mono)/mscorlib.dll \ -r:$(Mono)/System.Core.dll \ -r:$(Mono)/System.dll \ -noconfig \ -nostdlib+ \ -target:library \ -recurse:'Assets/Scripts/*.cs' \ -out:AROW.dll \ -langversion:$(LangVersion)
このコマンドで DLL を作成できること、普段行っているテストに関して不備がないこと、は一通り確認できました。 もし何か不備が見つかれば対応と合わせて追記します。
ポエム
Unity で行われているコンパイル部分が公開されればありがたいなと思いつつ、一般的に Unity で扱うアセットは Asset Store かオープンソースでの公開が主流な印象があるため、DLL 作成はそこまで強く想定されていないのかなと感じた年末です。
【書評】レガシーコード改善ガイド
読書感想文です。
概要
導入は既存のコードを修正するにはどうするかという流れですが、内容の8割近くはテストの話です。 斬新な内容という感じではありませんが、普段何気なくやっている様々なリファクタリング手法を定義し、名前付けてくれる本です。 例えば大きめな既存メソッドに新規処理を追加する場合、既存メソッドには新規メソッドだけを追加し、新規メソッドの内部に新しい処理をまとめる。こうすることで変更箇所を一つにまとめてしまう、このやり方をスプラウトメソッドと呼ぶ、などです。
グッときたところ
- 処理同士がつながる「接合部」を意識することでテストのための構造が見えてくる
- private メソッドをテストしたいのなら、そもそも public であるべきものかもしれない
- リフレクションは便利だが、テスタビリティを考慮した実装を保つという観点は満たされない
- sealed や final は控えることを推奨する、テスト用に継承クラスを作れなくなる
- 状態を変更するコマンド、状態を変更せず値を返すクエリ、この二つの役割分担を意識する
- システムのストーリーを話す：アーキテクチャや相互作用を誰かに話しながら整理することで、設計の本質部分を見いだしていく
- メソッド抽出においては int → double のような型変換は特に気をつける
- あまりにも巨大なメソッドなら、それだけで一つのクラスに抽出するという手段がある
雑感
自分が private メソッドをテストするときはよくリフレクションを使っているため、テストのためのリファクタリングを通して構造を見直すべきという話は耳が痛いところです。 とは言え、例えば sealed によって不用意な継承クラスを作って欲しくないという意図を宣言し、長期で見て実装が複雑にならないようにするという運用も当然あり得るわけで、どの程度テストのためのアーキテクチャにすべきかは常に考えていきたいところです。
【書評】INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
読書感想文です。
前書き
先日参加したイベントで紹介されていた本です。 ryu-rand.hatenablog.com
自分はいま少人数チームでリードエンジニアを務めているので、実装以外にもいろいろとやります。 その中でも、自分たちの製品はどんな課題を解決するのか、自分たちはチームとしてどこを目指していくのか、などの見定めや定義づけはまだまだ試行錯誤中です。 そのあたりの参考になればと思ったのがこの本を読んだきっかけです。
雑感
プロダクトマネージャーの考え方、やるべきことがやや抽象的に書かれています。 技術的な視点では書かれていないので、非エンジニアでも問題なく読めると思います。 ポイントポイントで参考になる点がありましたが、同じ内容の繰り返しもあり、記述はやや冗長かなという印象です。 チャプター名が具体的に書かれているので、気になる箇所をピックアップして読むのがおすすめです。