2時に寝て7時に起きた。タスクが全然消化できなくてしんどい。ただ燃え尽き症候群は落ち着いて次に向けての気力が出てきた。

神戸お土産探し

3年ぶりに出張が増えそうなので神戸のお土産探しも始めようと思う。今回は リッチフィールド さんのバウムクーヘンと丹波みるく黒豆萬をもっていく。オンラインで注文すると取り寄せに1週間かかる。ちょうど発注するときのタイミングが悪くて間に合わない。店頭受け取りだとそのリードタイムが4日になる。明石駅に店舗があったので電車に乗って朝9時から受け取りに行ってきた。電車の待ち時間を含めて往復で約1時間で受け取れる。もっていくお土産は自分がおいしいと思うものをもっていきたいという考えもあって単品でも購入して食べてみた。バウムクーヘンはしっとりした食感で普通においしい。プレーンよりも黒糖の方が風味の自己主張が強いという特徴があって私は好きかな。丹波みるく黒豆萬は濃厚なミルク餡で丁寧で上品なお菓子という印象を受けた。甘いのが苦手な人はややしつこいかもしれないけど、普通においしいと思う。黒豆がちょこんとのっているのが他の乳菓子との差別化かな。(なんの認定にもならないが) 私の審査は軽く通るお土産だとわかった。

開発者として効果的に伝える方法

関心のあるタイトルをタイムラインでみかけたので読んでみた。

• How to communicate effectively as a developer

期待したほど私にとって参考になることが書いてあったわけではないけれど、読んでみて参考になることはいくつかあった。著者は「効果的に伝えることを共感的に文章の解像度を高めること」と定義している。私の周りでもエンジニアリングの文脈で解像度の高低というキーワードをよく聞く。一方で共感というキーワードを私は意識していなかったのでこれは素直に参考になった。読み手を想像してその人が共感できるように書くことの重要性に言及している。empathically=「共感して、親身になって」という意味だから日本語らしく訳すと相手の気持ちに寄り添って書くとか、相手のために親身になって書くとか、それ自体はよいことのように思える。高解像度、且つ共感性の高い文章を書くことは労力を要するものの、次のことから win-win-win だと著者は表現している。

• 読者はより深く理解し、レベルアップする
• 組織は知識の共有が進み生産性が向上する
• 自分の考えを伝えるのが上手になり、キャリアアップにつながる

いまとなっては後の祭りではあるが、私がいまの3倍速く巧く文章を書ければたしかにもっとキャリアップできていた気がする。書こうと思いながら筆が進まずに断念した文章はいくつもある。最後の結びの言葉も気に入った。

自分が相手の立場なら喜んで読んでくれるような文章を書きましょう。

課題管理の勉強会の資料作り

来週の出張で使うかもしれない課題管理の勉強会向けの資料の叩き台を作った。過去の資料を見返しながらスライドを作り直していた。過去に資料を作ったときは納得して作ったものを、いま見返すと誤解している箇所があったり、あまり重要とは思えなかったり、当たり前の話しだけど、スライドやドキュメントも時間が経って見返すと粗が目立つようになる。こういうとき私は自分を信じないと再確認できて慢心せずにすむ。常に課題管理システムに日々の学んだこと、考えたことを書き続け、チケットの構成を整理し直したり、チケットとチケットの関連を結びつけたりしているうちに過ちや無知に気付くきっかけになる。この暗黙知をいつか形式知として言語化できるようになりたい。

0時に寝て7時に起きた。台風がやってきそうでなかなか来ない。2日前から警戒して備えているのに今朝時点ではまったく平気。朝起きて雨だったら休もうと思っていたものの、雨がやんでたからオフィスきて一仕事してきた。

ドキュメントを書き終えた

5日以上に及んだ 非開発者向けのインフラドキュメント を書き終えた。他にもいくつかインフラのドキュメントの加筆や推敲もしていた。叩き台としてそれなりに伝えたいことは書けた。あとは勉強会をしながら出てきた話題や質問などを参考にしながら推敲していくだけ。

0時に寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も調子がよい。やはり涼しくなって日々の生活の快適度があがって体調もよくなっている気がする。ストレッチを受けていてもあちこち調子よくていい感じにストレッチできているように思う。これで少しジョギングや運動をするといいんだろなという気持ちになってくる。これまでも暑い夏はあったと思うが、今年ほど夏の暑さにまいって集中力を欠いた年はなかったと思う。というのは、日記を1年近くも毎日書いたことがなかったからその変化に気付けたことも過去になかった。日記を書く過程で環境や状況の変化に敏感に気付けるようになったという背景もある。他の要因としては歳をとって体力が落ちているのだろうと推測する。落ちた体力をカバーするだけの取り組み (運動するとか摂生するとか) が必要なのだろうけれど、私は昔と比べて生活の姿勢をとくに変えていない。もうそろそろ不摂生がダメなんだろうなという自覚は出てきた。昨年からストレッチを始めたのは本当に僥倖で健康度はいくらか上がっていると思う。

まだドキュメントを書いている

非開発者向けのインフラドキュメント がなかなか完成に至らない。厳密に書くわけでもなく、嘘を書くわけでもなく、重要なことのみを専門用語を使わずに技術知識がない人たち向けに書くドキュメントは相当に難しい。どういう構成にするかも何度も試行錯誤しているし、説明のための文章量も増えてしまうところがある。インフラを知らない開発者向けに引き継ぎのドキュメントを書くよりもずっと大変だと3日も書いているのに書き終わらない (自分で納得がいかない) 事実から認識できた。書いて読まれるのかどうかもわからないけど、それは読み手の自由であって書き手は自分が伝えたいことを自分の言葉で書くことに意味があるだろうと考えて、いまの自分ができる精一杯のドキュメントを書こうと思う。

葬送のフリーレン

夕方から 葬送のフリーレン を7巻ぐらいまで読んだ。これまで1巻を無料キャンペーンで読んだことはあったし、人気があることも知ってはいたけどいつか読もうぐらいの感覚だった。毎日 LINE マンガで 神之塔 を読んでいて、たまたま2巻も無料化されたのを見かけて読んでみたらおもしろかったので、いつかはいまだと認識して電子版を購入して読み進めた。

葬送 という言葉も私は知らなかった。「死者と最後の別れをし、火葬場、墓地に送り出すこと。」を指す言葉らしい。マンガのタイトルから「葬送のフリーレン」という物語だよというのは、内容から妥当だと思うものの、これは物語の世界の中でもフリーレンの異名として魔族が呼んでいる。私はてっきり勇者ヒンメルとの思い出を辿る旅全体を葬送に見立てているのだと思って読み進めていたのに、途中で魔族からそう呼ばれていて、魔族を殺しまくる忌み名的なものだったの？！というところで、それまで読み進めていた自分の中の世界観とバグが生じた。もしかしたら今後の物語の展開によってまた違った意味になってくるのかもしれないけど。

歴史上で最も多くの魔族を葬り去った魔法使いとして「葬送のフリーレン」の異名を持ち、魔族から忌み恐れられている。

ja.wikipedia.org/wiki/葬送のフリーレン

あと思い出を辿るという物語は、ほのぼのしている話しもあれば、魔族との戦いを話しもあり、資格を取るための競技会の話しもある。話しの展開を何とでも創生できる想像力の源になっている。このマンガは旅の終わりが来なくてもよいし、強い敵を倒さなくてもよいし、思い出さえあれば物語を展開できるのでその幅の広さに感心した。内容はまったく違うけれど、蟲師 を読んだときと同じような感銘を受けた。葬送のフリーレンもアニメ化が決定しているらしい。

0時に寝て5時に起きて7時に起きた。

インフラのドキュメント作成の続き

昨日はインフラ構成図を主に書いていたが、今日は引き継ぎのために wiki に概要を書いて補足事項なども肉付けしながら、私がやったことや今後運用していく上で知っておくべきことなどをまとめていた。それと同時に backlog の wiki の階層構造なども見直していた。backlog の wiki はタイトルに / を含めることで階層構造を表す。実際の url はエイリアスリンクが使われていて、タイトルとは無関係なので wiki のタイトルを変更することで階層構造が変わる。これはこれでお手軽とも言えるけれど、この階層以下のドキュメントをすべて移動したいといったときは1つずつタイトルを変えないといけないので面倒になる。デイリースクラムのときに来週のインフラ勉強会の時間もスケジュールを抑えてもらった。おそらく1回では終わらないのではないかと推測するが、説明してみて開発者の反応もみながら2回目の有無を決める。

さらに「プロダクトオーナーのためのインフラ入門」というタイトルで別のドキュメントも書き始めた。他の重要な業務がなくて暇だと言ってしまえばそうなのだけど、非開発者向けにクラウドのインフラや自分たちの web システムをどう理解してもらうのがよいか、私自身、試行錯誤で答えをもっているわけではないが、難しいからプロダクトオーナーはインフラを理解しなくてよいというつもりもない。以前からプロダクトオーナーが「自分たちもインフラがどうなっているのかを理解したい」というコメントを何度か聞いていたので筆を取った次第だ。技術的な詳細は理解できないだろうが、いまどきのインフラにおいてどういった概念や考え方が重要なのか、なぜこのような複雑なインフラになってしまっているのか、そうした背景を理解してもらおうと考えている。初めての試みなので、後日やってみて反応をみてふりかえりしようと思う。

0時に寝て6時に起きた。

インフラのドキュメント作成

契約終了まであと1ヶ月半。私が唯一引き継ぎしないといけないものにインフラがある。

引き継ぐ前のインフラは本当にひどい状態だった。手抜き工事のまま放置されたような状態だった。cdk のコードから実際のインフラを構築することはできなくて、コード化されていないところを aws のマネジメントコンソールから手作業で設定していた上、どこを手作業で設定していたかの情報は一切残されていなかった。新しいインフラが追加されるときに cdk のコードと乖離があるからデプロイできなくて、それを前任者は直せなくて私が引き継いだという経緯がある。私が1ヶ月ほどかけて30以上の pr を作ってコードと実際のインフラをほぼ完全に同期させた。その過程で3回ほど (テスト環境ではあるが) 障害も発生させている。デプロイしたら手動設定が消えて壊れてしまう。何が手動設定で何がコード管理なのかの情報が何もないのだからデプロイしてみないと動くかどうかわからないという状況だった。そのため、現在のインフラは私が作り直したと言っても過言ではない。cdk のバージョンも v1 から v2 にアップグレードした。半分以上の cdk のコードは私が書いたと思う。その引き継ぎならびにドキュメント化の作業にようやく着手した。これまで書いてなかったのはインフラを管理しているのは私だけだったのでドキュメントなくても運用上の問題はなく、ドキュメントタスクの優先順位が低かったから。今日は draw.io で aws のシステム構成図を書き上げて、wiki のインフラドキュメントの再構築に着手したところ。

今週中に引き継ぎのドキュメントを書いて、来週ぐらいからインフラ勉強会やって引き継ぎを完了させる予定。

3時に寝て7時に起きた。眠れない。

github リポジトリとシステム間連携

社員さんが運用対応に忙しくてスプリントタスクがなくなって暇なのでドキュメントを書いてた。github に新規リポジトリを作成したときに行う初期設定の作業が増えてきた。大半は私が導入した仕組みや機能のための初期設定になるが、私はリポジトリの管理権限をもっていないので、社員さんにお願いして、この設定して、あの設定してとお願いして対応してきた。もうすぐ辞めるので引き継ぎできるようにやっていることのドキュメントを整理した。

• slack 連携
• backlog 連携
• github
  • pull requests テンプレート
  • github actions
    • github apps
    • github environments

リポジトリと他システムとの連携を効率化しようとすればするほど設定や背景が煩雑になる。とくに認証や権限周りのセキュリティを考慮した仕組みはサービスとのトレードオフになるので設定が面倒になりがちではある。とくに github actions のワークフローは 【登壇報告】JJUG CCC 2022 Spring で語りきれなかった技術的なお話 にあるように、世の中のプラクティスに依らず、私が設計して整備したものなので他メンバーにとって身近ではない。

backlog の wiki にプロジェクトのドキュメントを書いている。開発メンバーでドキュメントを定期的に書くのはほぼ私だけで、他メンバーはほとんど書かない。なぜそうなるのかな？と考えたときに思いつくことの1つとして、開発全般の業務としてやることを、誰でもできる汎用的な仕組みに落とし込むことを考慮して設計していないからではないかと思う。あるアプリケーションが内製／外部システム／外部ライブラリに関わらず、こういう機能や仕組みを使って、こんな課題を解決して、こんな機能を実現していますという構成にはなっていない。発生している問題に対して動けばいいといったレベルでしか開発していないから、本来どう在るべきなのか、どういった設計思想なのか、今後はどうやって保守していけばいいのかの指針を提供できない。これは私の言葉だと設計ができないということと同義だと思う。他に思いつくこととしては、既存アプリケーションにない新規の仕組みを定期的に設計しているのは私しかいないのかもしれない。言い換えれば、言われたことしかやらない人しかいない。

20時に寝て22時に起きて、それから作業して3時に寝て6時に起きた。

インフラのドキュメント作成

今日からインフラのドキュメント作成に着手した。4月から1ヶ月以上に渡って インフラエンジニア のようなお仕事をしていた。具体的には新しい環境のインフラ構築、ならびに既存インフラのリファクタリングというよりは再構築といった作業をしていた。約1ヶ月で大きなインフラのタスクは完了して、その後もこれまで cdk 管理していなかったインフラリソースの管理なども含め、より再現可能な管理されたインフラとなるように改善してきた。それもだいたい終えてきたので、そろそろ他の開発者にも引き継げるようにドキュメントを書くことにした。私以外は若い開発者が多いせいか、cdk/cf の知識というよりもインフラそのもののやネットワークの知識が少ないメンバーが多い。そういった運用経験の浅い開発者にも適切な教育が行えるよう、ドキュメントやチュートリアルなどを書いていく。数日ぐらいかけてしっかり書いてから勉強会を開催する。それをもって引き継ぎしていくかなぁ。

私が前任者から引き継いだ README に helm の説明が次のように書かれてた。

まず helm がわかってない人はググってくること。

こんな README を私はみたことなくて書いている人が訳分からず作業しているんだなという印象を受けた。私が書くドキュメントには cdk とは何か？から説明している。もちろん aws のドキュメントをすべて読めばよいのだが、それはコストがかかる。私の経験と私が理解した cdk の概念を簡潔に、なるべく自分たちの業務にとって大事なことを要約して書くことに意義があると私は考えている。README にググれみたいなことを書いて誰もなにも言わない開発文化を改善していきたい。