今年のおしごと2020
来年はもう少しこまめにブログを書きたい。
今年のおしごとを四半期刻みで振り返ります。もちろん外に向けて書けるものだけ。
1月~3月
今年は昨年3月から引き続き、オンプレ向け自社製品デプロイツール開発として働いていました。
1~3月のお仕事は大きく2つ。
Amazon Corretto JRE のデプロイ機能開発
自社製品は Java で動いており、サーバにランタイムとして JRE を配置する必要がある。
そこで、デプロイ時に JRE の更新も自動で行いたいという需要が生まれたので、
ツールに対して新規機能として実装。
製品や環境ごとに JRE の配置先が違ったりするため、それらを吸収するためデプロイ先を任意に変更できるよう開発した。
Google Form と Slack の連携スクリプト作成
これは主務とは異なるタスクのため、合間を縫って*1*2実装していた。
お客様との窓口となるコンサルの、顧客訪問時の記録を Google Form で行うという施策において、
Slack に自動的に連携され、Slack 上で様々なやりとりをできるようにしたいという需要が生まれた。
Google Apps Script(GAS) をつかって、Form 送信時に Slack に自動通知される仕組みを作成した。
・・・というとあっという間に作れそうに思えるが、つらみポイントがいくつかあったので書いておこう。
Slack 通知の対象となるフォームが20以上ある
GAS には、Spreadsheet や Form などの Google Apps と紐付くスクリプト（Container-bound script）がある。
これをつかうと、Spreadsheet であれば編集時やシートを開いた時、Form であれば回答の送信時など、Apps 固有のイベントを手軽にスクリプトのトリガーとして利用できる。
そのため、フォーム送信時にスクリプトを発火させる場合は Container-bound script を使うのが都合がよいのだが、
20以上あるフォームそれぞれにこれを設定するのは実装コストも保守コストも爆上がりしてしまう。
そこで、Google Apps と紐付かないスクリプト（Standalone script）に実装し、
外からイベントトリガーを定義することで、単一のスクリプトで複数のフォームのイベントを管理することとした。
具体的には、TriggerBuilderを使って各フォームごとにスクリプトからトリガーを定義した。
これによって、ひとつの関数を実行するだけですべてのフォーム送信イベントをトリガーとして定義できるようになったのだが、 ここでもう一つの問題が生じた。
1ユーザあたり、スクリプトに設定できるトリガーが20個までという制限
題通りなのだが、GAS にはあるスクリプトに設定できるトリガーの数に制限がある。
具体的には、20 トリガー/ユーザ の制限となる。ref: https://developers.google.com/apps-script/guides/services/quotas#current_limitations
そのため、20以上あるフォームに対してトリガーを1人で設定することが不可能なのである。
こればかりはどうひっくり返っても回避不可能なので、トリガーの設定を行う人を複数立て、
Google Spreadsheet にトリガー設定履歴を記録することとした。
この制限結構きついなあ。
そして
まあ、いくつかの面倒くさいポイントはあったものの、今でも元気にスクリプトは動いている。 どうもコンサル組織においてわりと重要な仕組みになっているようで、噂によると今年の秋時点で1万件以上の記録が Slack に連携されているみたいです。
4月~6月
この辺から在宅勤務が本格化。
実家には小さな折りたたみテーブルと MacBookPro しかないので、会社に比べて画面が小さく辟易した。
4~6月にやったことは以下の通り。
- オンプレサーバーヘルスチェック機能開発
- Qiita Organization に入った
- 部内で LT? をした
オンプレサーバーヘルスチェック機能開発
オンプレサーバの物理マシンはデータセンターにあったりお客様先にあったりと、日頃のメンテナンスがおろそかになっていることがある。
その場合、ディスク等の枯渇が突然発生してシステムが正常に動かないトラブルが発生することがある。
そこで、開発しているツールにディスクと表領域のチェック機能を実装した。
ツールはWebアプリケーションとして動くため、チェック方法のわからない（スキルを持たない）人でも使えるよう、
ボタンをポチポチするだけでチェックできるよう実装した。
UI/UX には結構気を遣ったつもり。
Qiita Organization に入った
ついに弊社も Qiita に Organization を作ったらしいので参加した。
昔取った杵柄で、Contribution 数がちょっとあったので、参加したての頃は Organization の Contribution 数の大半をぼくが占めるということに。
今はあの記事とかあるので、全然たいしたことない。
部内で LT? をした
月次の全体ミーティングでは、持ち回りで LT をすることになっている*3。
6月は私が担当だったので、これまでの1年ちょっとの経験から得られたサポートエンジニアとしての心構えを紹介した。
スライドは Internal な内容が多いので公開できないが、ざっくり以下のような内容を話した。
- 問い合わせは回答スピードが命。
- スピードは大事だが、回答の質も大事。
- つまり、質とスピード*4を両立する必要がある。
- そのために必要なことは以下の3つ
- 事実と推測を区別する
- ゴールを明確にイメージし、そこから逆算する
- いち早く事実だけを積み重ねる
概ね好評だったようなので、いつか再放送できるといいなーと思っている。
7月~9月
先述の在宅勤務環境が耐えられなくなったことと、Stay Home によって少しお金が貯まったので、
これを機に一人暮らしを始めた。
この時期はあまり特筆すべきことがない。というか外に向けて書けることがない。
- インターンのメンターをした
インターンのメンターをした
いわゆる「夏インターン」のメンターをした。
Withコロナということで、完全オンラインのインターンシップとなり、在宅にてZoomやSlackを活用したインターンであった*5。
ぼく自身は学生時代にインターンに参加したことはなく、自社も通常の新卒採用での採用だったため、
そもそもインターン自体はじめてであった。
インターンは3日間行われ、その間学生のアウトプットのレビューをしたり、
Zoomのブレイクアウトセッションを使って行われているグループワークを見回ったりしていた。
初日のアウトプットを見たときは「大丈夫かこれ...というか3日でどうにかなるものなのか...???」と不安になったものだが、
終わってみるとどのグループもとてもよくできていて、なんというか感動した。
というか、（就職活動とはいえ）学生が真摯に課題に取り組む姿や、3日間を通して明らかに成長している姿を見て、
むしろ自分が学ぶことが多かったなという印象。
社会人も3年目に突入し、ある程度"惰性で"働くことができるようになってしまっているので、
この時の学生の取り組み方を折に触れて思い出し、自らの働き方を修正していきたいと思っている。
10月~12月
さて、記憶にも新しい最後の四半期。
10~12月にやったことは以下の通り。
- Webマニュアルをリニューアルした
- 副業を始めた
- 引き継ぎをした
Webマニュアルをリニューアルした
開発しているツールのマニュアルは Web から参照できる Web マニュアルとして提供している。
このWebマニュアル、現在は Asciidoc を用いて作成されており、ここから HTML ドキュメントを生成している*6。
Asciidoc はあまり利用することがなく、実際このマニュアルの作成以外では利用しない。
そのため、できれば Markdown でマニュアルを作りたいと思っており、合間を縫って*7マニュアルのリニューアルに取り組み始めた。
せっかくなので頑張ったポイントについて書いていこう。
MkDocs をつかった
マニュアルのベースとなるフォーマットを Asciidoc から Markdown に変更するにあたりもっとも大きな問題は、
Asciidoc に比べて Markdown は表現力に乏しいこと。
特に、Asciidoc における「ブロック」が一般的な Markdown では利用できないため、
警告や Tips などの情報の表現が難しい。
そこで、Markdown ベースの静的サイトジェネレータである MkDocs を利用した。
これは、Python-Markdown 拡張を利用でき、これによって通常の Markdown 以上の表現が可能となる。
また、サードパーティーテーマも豊富にあり、きれいなドキュメントを簡単に作成できる。
作成した Web マニュアルでは Material for MkDocs を利用した。
Remote - Containers をつかってマニュアル編集用の環境を整備した
MkDocs ドキュメントを編集する際は、ローカルに Python と MkDocs 関連の各種ライブラリといったものをインストールしなくてはならない。
これらの環境構築は往々にして社内ドキュメントに手順がまとめられるが、だいたいメンテナンスが漏れたり、環境依存のトラブルが発生する。
そのため、VSCode の拡張機能 Remote - Containers をつかって、環境をコンテナ化することにした。
Remote - Containers は VSCode 自体もコンテナ上で動くため、VSCode 拡張機能も含めてパッケージ化できることが魅力。
MkDocs 編集環境をパッケージ化するため、Markdown や YAML 用の拡張機能も併せてパッケージ化した。
詳細はアドベントカレンダーとして Qiita にも書いたので、リンクを貼っておく。
副業を始めた
12月から副業を始めた。
副業はもともとする気がなかったのだが、会社の先輩が副業3つやってる話を聞いたこと、友人から副業の誘いを受けたことから、「1つくらいならできるかな？」と思い、開始。
内容としては Kubernetes を扱ってなんかしています（まだよくわかっていない）。
Kubernetes 自体、知ってはいたが利用するのははじめてなので、『Kubernetes 完全ガイド』 を写経しながら読み進めている。
来年は CKA, CKAD の取得を目指したい。
引き継ぎをした
さて、昨年3月からやってきたオンプレ向けデプロイツール開発であるが、2021年1月から別部署に異動が決定した。
そのため、12月後半は各種業務の引き継ぎを行っていた。
異動する身としては、仕事を新たに自分でやっても意味が無いと思い、なるべく自分から仕事をとらないようにしていた。
その結果として12月後半はめちゃくちゃ暇だった。
おわりに
というわけで、来年からは新しい部署で働くことになりました。
副業もどうなっていくのかわからないし、2021年は今のところまったく予測不可能です。
とりあえずフルリモートワークになることはほぼ確定だそうなので、いろいろアウトプットを増やしていけるといいなー。
