個人ではタスク管理ツールを使うのやめてみた話
最近 Todoist にカンバン機能が追加されたと知った。
最近の Productivity Tool は ClickUp のような All in One が流行っている気がしていて(根拠はない) Todoist もその時流にのってきたのか...と思って使ってみようと思ったけど、そもそも最近、タスク管理ツールを使うのやめたんだよな、と思って、その経緯や意図をまとめてみた。
タスク管理ツールと私
Todoist にせよ Trello にせよなんにせよ、私にとってタスク管理ツールを使う理由は、そこにタスクを書いておけば安心して忘れていられるという点にある。
言い換えると「何をすべきか忘れている気がする...」という不安から解放されるために使っていた。
しかしタスクを忘れたくない、という気持ちからどんどん追加するので、常に 追加 > 消費 の状態となってしまう。定期的に整理をするというTODOを作って取り組んだこともあるが、整理が少しでも滞るとすぐに溜まるのでやがて嫌になってきて、最終的にすべてを忘れるためにサービスを乗り換えていく。
Evernote -> Google Keep -> Any.do -> Google タスク -> Trello -> ZenKit -> Todoist -> ClickUp
と乗り換えてきて、さすがに同じことの繰り返しすぎてアホでは...という気持ちになってきた。
タスクとアイデアを区別する
大量に積まれていくタスクを眺めて見ると、おおよそ3パターンに分類できた。
- 「新しく習慣にしたい定期的なタスク」
- 「仕事や約束といった実行しなければならないタスク」
- 「こういうのできたらいいな、という思いつきのタスク」
こうしてみると、タスクが増える一方なのは 3. の思いつきタスクのせいだ。 xxx というツールを使ってみる、とか、yyy ソースコードを読むとか、zzz の本を読むとかがこれで、たいてい、タスクを追加した時のモチベーションは失っているので、永遠に実行されない。
もはやタスクではなく、思いついたアイデアをメモしているだけである。もっといえば、実行しないアイデアというのは、それを思いついたことをどこかに残して「あ、これ前からしようと思ってたんだよ」と言うための証拠を作ることが目的のようなもので、私の自己満足でしかない。
ということで、3. のアイデア的なタスクは Twitter や Evernote を使うことで、タスク管理ツールに入力しなくて済むようになった。
定期的なタスクはいずれ、すでに完了したのに残ってしまう状態になる
残るは、
- 「新しく習慣にしたい定期的なタスク」
- 「仕事や約束といった実行しなければならないタスク」
を整理する。
まずは 1. の定期的なタスクについて考えてみると、これは習慣が身につくまで忘れずにいるために、タスク管理ツールを見れば必ず目に入る、という状況を作っておくことが目的だった。これは私にはとても有効で、毎日サーバーやアプリのモニタリングをチェックすることや、毎週個人用の週報をつけたり、毎月サーバーの費用を確認する習慣が身についた。今のところ、新しく習慣化したいものはないため、タスク管理ツールを頼る必要はない。
こうなってくると、タスク管理ツールを見るまでもなく「すでに完了した」状態になる。
ツール上では「未完了」のタスクが残ってしまい、整理を怠ると、タスクが溜まる要因の一つになる。
とはいえ、習慣を身につけるために有効であることに間違いはない。
仕事や約束といったタスクはそれを実行する環境上で管理するのが良いというポリシー
- の「仕事や約束」のタスクについて考えてみる。
また、タスク管理ツールを見れば必ず目に入るという状況を作るには、タスク管理ツールを見る習慣がある前提が必要になる。
そのためには、 2. の「仕事や約束」のタスクが全て同じタスク管理ツールに書かれているかどうか、が鍵になる。仕事上必ずそのタスク管理ツールを見る必要があれば、自然と習慣化したいタスクも目に入る。しかし、私はダブルメンテが嫌いなので、仕事のタスクとプライベートのタスクが、それぞれすでに適切な場所で記載されている場合は、それを自分のタスク管理ツールにコピーしたくない。
仕事のタスクは GitHub, esa.io, Slack で、それぞれの粒度で管理されている。GitHub でアサインされている Issue が私のタスクだし、 esa.io で進捗状況が報告されているのでそれを見て自分のタスクの優先度を調整し、Slack でたまにちょっとした作業を依頼されたりしている。それぞれのツールを使うことが業務の一部だし、それぞれのツールで自分のタスクを管理すればチームへ情報共有となり貢献となる。自分のタスクを自分だけのツールで管理することは別に悪いことではないが、そのタスクが個人に閉じてしまうことで、チームへの貢献チャンスを逃している可能性がある。
プライベートのタスクは、個人的なものはタスク管理ツールが使えるが、家族単位のタスクだと TimeTree を使っているし、書類や家計といったデータを残しておくことに価値のある場合は Evernote や SpreadSheet を使うこともある。プライベートにおいて、必ず実行が必要なタスクというのはほぼ家族が関係するものだし、それなら TimeTree でタスクにしておいた方が進捗や完了を共有するのも簡単で効率的だ。
何らかのグループが関係するタスクは、そのグループで使用しているツールや仕組みを使って管理するのが良い、というポリシーに則ると、残されるのは「個人的なタスク」のみである。
つまり、私がタスク管理ツールを活用できるのは「新しく習慣にしたい定期的なタスク」と「個人的なタスク」の 2つに絞られる。
忘れないために書き残すことで熱意を失う
「個人的なタスク」は私の場合、XX本を読むとか YYの記事を見るとか ZZリポジトリのソースコードを読む、などが多い。どれも、その時は「これは忘れずに読まねば!」と意気込んでタスク管理ツールに追加している。しかし「忘れずに読まねば」のうち「忘れずに」という問題は解決できるが「読まねば」という熱意が維持されるかどうかは本人依存となる。そして私はほとんどの場合、タスクを追加した当時の熱意を思い出すことができず、そのタスクを見なかったことになる。
見なかったことなる回数が多くなると、タスク管理ツール自体を見なかったことにする回数も増えてくる。
すると、「タスク管理ツールを見れば必ず目に入るという状況を作っておくこと」で習慣化させようとしていたタスクも、見なかったことになる。
必要なのはタスク管理ツールではないと気づいた
そもそも、私は自分が忘れっぽいからタスク管理ツールを使おうとしているが、忘れっぽいというのは気が変わりやすいということだ。
タスク管理ツールは、心変わりを止めるツールではない。
むしろ、これと決めたゴールに向けてまっすぐ取り組むための計画をサポートするためのものだ。
私に必要なものは、自分のタスクを管理するツールではなくて、何のためのタスクを管理したいのかを明確化させることだと気づいた。
て、思い切って何も使わないことにした。
使わなくなった結果
無限に増えていくタスクに飽き飽きしたり、何も終わらせられない自分に呆れたり、ツールの使い方や新機能の把握に時間を取られることがなくなり、思いのほか楽になった。 ツールに残さないことで逆に「忘れるから今やってしまおう」という気持ちになるので、なんだかんだタスクを忘れることも(ほぼ)ない。
一方で、自分が過去に追加したタスクを見るというのは、ある意味で自分との対話になっていたのだとも気づいた。
追加されたタスクから、その時に何に興味を持っていたか、何を課題に感じていたかを思い出すことができ、今と比べることで自分の変化や成長を感じることができる。
その時自分がすべきと思ったもの一覧、というのは Twitterや日報からではノイズが多くて見るのが難しいので、タスク管理ツールではなくとも何かしら形にできると面白いんじゃないかな、という気がした。
hub で Issue や PullRequest を修正できるようになった
↓がマージされてできるようになった。
個人的に、あればいいな(なかったら別の手段でやるけど...)と思っていた機能が hub
に入った。
hub issue update 16 --edit
などと実行すれば、id: 16 の Issue もしくは Pull Request の既存の title と body がエディターに展開される。
あとはそれを好きなように更新すればOK。
プルリクを見ると分かるけど、最初は hub issue edit
というサブコマンドだった。
だけど hub issue edit --edit
というのちょっと分かりづらいよね、という意見から hub issue update
という名前に変わった。
他にもラベルを付けたり消したりするオプションの仕様と名前をどうしようかー、という議論もされてて、こういうの普段自分たちが業務でやってることと同じなので、OSSだからって何かすごいやり方とか想像もつかないコミュニケーションがされているというわけではないんだなー、と勝手に親近感を持ったり安心したりした。
hub を install するだけの orb を作った
hub を CircleCI で使うための orb を作った。
こんな感じで使える。
version: 2.1 orbs: hub: yasuhiroki/hub@v0.0.1 jobs: install: docker: - image: circleci/node:latest steps: - hub/install - run: hub --version workflows: test: jobs: - install
当初は hub/release
とか hub/create-pr
とか作って、 hub を使った command をいくつか用意しようと思ったんだけど、私はシェルでゴリゴリした結果をもとに release を作ったり pull request を作ったりしたいのだと気づいて、ただ hub をインストールするだけの orb になった。
結果、 circleci/aws-cli orb と似たような感じになった。
ちなみに hub
を使いたい理由は、私がふだんから hub
を使っているから。
CircleCI で GitHub のあれこれを自動化するために GitHub の API を調べてスクリプトを書くのも手間だし 1 hub
の使い方を知っていればCIで何してるのかも分かる、という統一感があって嬉しい。
2019年を振り返って
2019年も振り返っていくぞ。
2019年の習慣
2019年はEvernoteに個人的な週報をつけてみた。
仕事のことも家庭のことも思いつきもイベント事もつらつらと書き続けた。
我ながらよく続いたなと思う。
毎週必ず書くのしんどいかなーと思ったけど、仕事では 1週間区切りの sprint なので weekly scrum で何かしら書くことあるし、育児ネタも湧いてくるのであまり苦労しなかった。もし毎日書いてたらしんどかっただろうけど。
あと自分のことをあまり書きすぎないようにしたのも良かった。
昔、4行日記を書いてたことがあるんだけど、ほぼ自分の失敗と反省ばかりで辛くなって続かなかった。まあ社会人2年目~3年目の頃なので、そういう時期だっただけかもしれない。
ちなみにペン字も始めたんだけど、こちらは続かなかった。
成果を実感しづらいと習慣化は難しいなーと思いましたまる。
では月別振り返り。
1月
家族全員インフルエンザ。きつかった。
朝活をしようと思って早起きしてたんだけど、私が早起きすると物音のせいか子どもも早起きするので結局時間が取れなくてやめた。
1/30の 第1回CircleCI ユーザーコミュニティミートアップ 後に CircleCI Japan User Group の Community Leader になった。
業務では OKR を試し始めた。タスクの優先順位が明確になって良い仕組みだと思う。
2月
背中の痛みに悩み始めた。後日病院にも行ったけど改善されず、今もたまにジリジリした痛みを感じる。
同僚に筋トレのせいではと言われて背筋の筋トレをやめて少し楽になったけど、根本的な痛みの原因だろう我が子は日に日に体重が増えるので、これはもうずっと付き合う痛みと思うことにした。
OKRの自信度を0~100%だと尺度が広すぎてこまかい数値の上下が気になっちゃうから5段階くらいで良いのでは〜という意見を持った。
3月
大きな新機能をリリースして、それなりに結果も出たのでホッとした月だった。
新機能にどれほどの効果があるのか未知数な上にかなり工数がかかっている状態だとストレスだった。個人的にもストレスだったけど、それ以上にチームとしてもストレスがある...ように感じてしまうのがしんどかった。
イチローの引退会見を何度も見てた。
4月
担当大臣制というものを試し始めた。
OKR で決めた KR 達成を目指して各施策を打つんだけど、その施策の取りまとめ役を担当大臣と呼んだ。仕様決め・施策内容の検討・優先度の決定などの実行権限を与えられて、自分がすべきことに集中できるのは良くて当初はいい仕組みだと思ったんだけど、自分の担当外への関心が下がってしまう弊害もあった。アイデア段階で意見しなくなったせいか、ほぼ実装が終わった後に「これで良いのかなー」という反応をしたりされたりして手戻り作業を増やしてしまう。
たぶん、チーム内の相互理解が相当進んでないと効率的に進まないシステムのような気がする。それこそ公安9課みたいな。
この時期はMTGが泥沼化する傾向があって頭痛の種だった。他の文章にしづらいイベントや育児ストレスも相まって、2019年で一番体調が優れない時期だったと思う。悪夢を見て叫びながら目が覚めるという初めての経験をした。
5月
文章にしづらいイベントをきっかけに MISSION / VISION / VALUE / CREDO / HABIT を決め直したり新しく決めたり。
とても時間がかかったけど、自社を自分の言葉で説明できるようになって良かった。自社サービスしか説明できなかったもんなー。
体調が回復した。今思うと、やっぱ私のストレスの原因はアレだったんじゃないかと思う。そう思うと、次また似たようなストレスを感じたり、その予兆があったらすぐに対処しようと思う。具体的には自分のストレスを言葉にすること。
あと副業の検討を始めた。
6月
育児サポートのためリモートワークが増え始めた。
ただ、リモートワークを前提とした開発フローではないので、リアルタイムにオフィス内で決まったことが伝わらずに効率がよくない。特に、何をするのか決まったことは書いてても、なぜそうなったかが分からなくて、すでに議論済みのことをコメントして聞き返したり、違う解釈をしてズレた実装をしたりして効率が悪い(という感覚を持っていた)。
とはいえリモートワーク前提の組織にするのもコストだし、今はあくまでもリモートワークはオプションだと思っているので、この辺はリモートワーク側が自分の作業効率のために努力する部分だと思っている。議論済みかもしれなくても自分の解釈が正しいか確認すべきだし、ツールは何でも良いので電話して直接会話することを積極的にすべき。
妻と子どもが1週間半帰省した結果、私の顔を忘れられてしまってめっちゃショックだった。
だからリモートワークを増やしたのは内緒。
7月
Androidの開発タスクが増えてきたんだけど、AACとかKotlinとかRetrofitとか自分の知らない技術への勉強時間が足りてなくて追いつかない。
同僚がどんどん新しいのを取り入れるのでプルリクベースで追いかけるのがやっとという感じ。業務中に勉強できないと時間が取れない生活をして片手間で開発してると、まー時間が確保できない。RubyやAWSのキャッチアップも続けたいので、結局、薄く広くな知識になっていく。本気で勉強したいなら絞ったほうが良いんだろうけど、どうするかはまだ悩み中。
もっと仕様を整理した開発をするにはどうしたらいいんだろ、と思ってエリック・エヴァンスのドメイン駆動設計を読み始める(まだ読み終わってない)
8月
体調が芳しくなく熱を出した。
2018年の8月も同じような感じだったらしい。周期的なものなのか...。
circleci.vim を作った。
9月
情報共有不足(する側もされる側も不足している)から手戻りが発生してかなりもやっとした気持ちになった。
計画的にそうしてるんだと思ってたので口を挟まなかったんだけど、蓋を開いてみたらただの認識違いだった。オフィス内で決まったことを共有しきれてないせいなんだけど、GitHubへの記述が間に合ってなかったり、そもそも当初から開発の進め方の足並みが揃ってなかったり、工数と実際の成果物が出る日数にズレがあったりと、マネージャーが存在しないことによるデメリットが噴出した月だった。
今でもマネジメントは必要だと思っているけど、デメリットが見えてるならある程度は仕組みで解決できるんじゃないかとも思っている。気をつけるとか注意するとか、そういうのは嫌いなので、自然と情報共有するしキャッチアップするような仕組みを考えたい。まだ考え中。というかこれ習慣の話なので、何とかできないと何のサービスやってんだという感じもする。
10月
テスト漏れの不具合があって、CIの仕組みにまだまだ改善の余地があると実感した。実装した箇所のカバレッジがなかったら怒られるような仕組みが欲しい。そういうのSaaSでありそうだけど。
実家に1週間くらい帰って完全に技術から遠のいて、いざ仕事に戻ると辛いのなんの。毎日少しでもエンジニアモードにはなった方がいいなーと思った。
11月
個々人の開発の進め方の違いに悶々とした出来事があった。後日この辺の話をすると、経験してきた開発フローが違いすぎるのがベースにあるようだった。この辺は整備しないと、いつまで経っても噛み合わないので考えたいところ。
私の作業ミスがチラホラ増えてしまって気を引き締め直した。ミスのうちいくつかはCIで自動検出できるようにしたり、レビュー漏れがないか確認するためのチェックリストを用意した。また、 # TODO: あとで直す
はあとで直さないので、わざと落ちる実装にしておいてエラーを起こすようなスタイルに変えた。
12月
入社後最大のビッグイベントを経験し、やはり私はデバッグ作業が好きなのだと改めて自覚した。
最終日に社員エンジニア飲み会が開かれて、かなり話し込んだ上にまだ話し足りないので、もっとこういう時間が必要なのではと思えた。
副業募集を公言した。
まとめ
2019年は、個人の課題というよりチームの課題を意識した年だった。
そのチームの課題の文言化と解決策の実施・振り返りができる 2020年にしたい。
個人の課題はたぶん副業の方でボロボロと出てくるので粛々とやっていく。
相変わらずアウトプットは少ないので(勉強会でLTしないとまずアウトプットしない)このブログをもうちょい使おう。
副業はじめます
TL;DR
- 副業を探しています
- ライフスタイルを崩したくはないので月10~20時間程度の副業を探しています
- Jenkins認定エンジニアを持っていたり CircleCI User Community Leader をしていたりと CI/CD に強いです
- 開発チームはビジネス要件に集中して開発効率化は誰かに任せたい、先人が残したCIが死んでて困っている、といったニッチでスポット的なお仕事が最適です
- AWS / Rails / Android の開発をお手伝いすることもできます
- 何かお手伝いできることがあればご連絡ください
あなたは誰?
@yasuhiroki (twitterは @duck_yasuhiroki) というアカウントで活動しているエンジニア歴8年目の男です。
現在は恵比寿にあるベンチャー企業で AWS : Rails : Android を 5 : 3 : 2 くらいの割合で触ってるエンジニアをしています。最近 Android 率が高まりつつあります。
Jenkins認定エンジニアという資格を持っていたり CircleCI User Community の運営に関わっていたりと CI/CD まわりが好きです。
前職では新規事業開発、現職はベンチャーということから 1人N役な開発経験が多く、0→1 や 1->10 くらいのフェーズに馴染み深いです。
できること
- CI / CD の構築・メンテナンス
- CI/CD の導入
- 初期設定, Test, Deploy, Release 一通り何度もやってきたので得意なところです
- Jenkinsに困っている(=使いこなせていない)という状況ならお力になれると思います
- 死にかけのJenkinsさんの介護に困っているならご相談ください
- とはいうものの、ここ2年は知識を更新していないので、たとえば Jenkins X についてのノウハウはないです
- CircleCI
- 現職では CircleCI をメインに使ってるのでノウハウが溜まっています
- GitHub Actions
- 趣味程度ですが enjoy しているので程度知見があります
- Google Apps Script
- CI/CD とは少し逸れますが、業務改善というくくりだと GAS は中々便利で優秀なツールだと感じています
- 現職では CS 対応の管理用ツールを GAS で作って GitHub と連携して自動化したりしています
- CI/CD の導入
- AWS 開発
- Rails 開発
- 2年ほどの開発経験があります
- Rails 4.2 から 5.0 へのアップグレードをしたり Fat Controller な実装を Model に移したりとリファクタしたり
- 最近は RuboCop のカスタム Cop を作ってコードレビュー効率化図ったりしています
- Android 開発
できないこと
- Windows / iOS アプリ開発の経験はありません
- JavaScript は GAS や AWS Lambda + Node.js の経験がほとんどなのでフロントエンドのお手伝いは難しいです
趣向や性質
ストレングスファインダー によると↓の性質を持っているようです。
- 最上思考
- 学習欲
- 達成欲
- 調和性
- 収集心
バグは絶好の学習材料という認識を持っているので楽しく調査します。
解決できた時は最高に嬉しいですが、時間の都合で取り急ぎワークアラウンドで回避する時もそれはそれで楽しいと感じます。
結局は、目の前に分かりやすい問題があると何かしら解決したくなる性分なのだと思います。
連絡先
TwitterのDMが一番繋がりやすいです。
何かお手伝いできることがあればご連絡いただけると嬉しいです。
Ebisu.rb #26 に参加しました
Ebisu.rb はこれで5回目くらいで、前回の参加が #23 の 5月なので 半年ぶりになる。
今回は参加者の層が Rubyガチ勢と ゆるふわRuby勢と 未経験者勢 とで何となく分かれていた気がする。Rubyガチ勢とゆるふわRuby勢の境界は自分でも良くわからない。少なくとも私はゆるふわRuby勢。
そんな中で GitHub Actions について喋ったんだけど、気になる層とそうでない層が真っ二つに分かれるのは予想していたので、もう少し広い範囲で興味を持ってもらえそうな git の alias を使ったライフハックも紹介した。懇親会では GitHub Actions の話もライフハックの話もできて楽しかった。
他の方の発表も多種多様で、そうそう Ebisu.rb ってこんなだったわー、という気持ちになった。GitHub Actinos の話をしてる私が浮いていないくらいなのですごい。
個人的には、書き捨てコードの話とRspec高速化の話が刺さった。
書き捨てコードを見たり解読するのが好きだということもあるけど、書き捨てコードがあるということはプログラムで何かを解決しようとしているわけで、それがプログラマーの仕事の仕方だよねーというのを実践してる人が目の前にいることが刺激になった。そういうの最近できてないなー。VimやIDE開いて愚直に手作業してた面倒な繰り返し作業も、もうちょっとスクリプト組んで効率的にできたんじゃないかと思えてやる気出てきた。
Rspec の高速化の話は、こりゃもう知ったからにはやらなきゃと思ってスライド見ながら手を動かしてたら、そもそもうちの factories たちが trait で余計な関連レコードたくさん作ってるのを整理しなきゃいけないと気付かされて、でもまあやるっきゃ無いかとふんばってる。そのやる気が出てきたのはあの LT のおかげなので、いやもーありがとうございます。
RSpecの実行時間を1/5にした話 - Speaker Deck
帰宅してからは reline の rvm の CI が落ちる問題を調べてた。目の前にバグがあったらちょっかいかけたくなるよね。
rvm がメソッド追加してる Bundler と実際に動いてる Bundler が別なので動かないというのが分かったものの、どう解決するのが適切なのか分からず寝たら、次の日に bundle exec
して直してるのを見て、その発想が出なかったのがちょっと悔しかった。bundle install してるんだからそりゃそうじゃんか...。でもスッキリしたので良かった。
Fix to failed CI. by osyo-manga · Pull Request #71 · ruby/reline · GitHub
今年もアドベントカレンダー書く予定なので、文章を書くリハビリがてら久々にブログ書いた。
2018年を振り返って
なんで振り返るのか
2017/09 に SIer から ベンチャー企業のエンジニアになり、2018年はそのベンチャー企業で過ごした1年だった。
大きくまとめると楽しくハッピーな1年だったが、なにかを成し遂げられたかというと、そうでもない1年でもあった。
また消化不良な感覚があって、その感覚を具体化したくてこの記事を書こうと思った。
1月
娘が生まれた。前日は大雪だった。里帰りしている妻と電話で、こんな雪の日に出産になったら大変だね、と話していた翌朝に娘が生まれた。フラグにも程がある。
あれこれと相談した結果、妻が娘を連れて戻るのはゴールデンウィーク前となった。
言い換えると、私が私のために時間を自由に使えるのは4月末までということだと思った。
2月
いずれ自分の時間が制限されるなら、限られた時間を最大限に活用する必要がある。なので生産性にこだわって仕事をすることにした。
当時、タスクはすべて見積もりポーカーでポイントをつけていたので、Sprintごとに消化できたポイント数を増やすことに拘った。
先に書くと、これは失敗だった。
消化したポイント数を意識すると、ポイント効率をどうしても考えてしまう。つまり、同じポイントなら(自分なら)短時間で完了できるものを優先してしまった。もちろん、Sprintごとにやるべきタスクと優先度は決まっているのだけど、そのタスクが終わって空き時間ができると、ポイントを効率よく稼げるタスクを進めてしまいがちになった。
結果、自分にとってチャレンジングなタスクには手を出さなかったので、何の勉強にもならなかった。経験を食いつぶしているだけなので、消化できたポイント数がいくら増えたところで、自分の成長を実感することはなかった。
この結論に気づいたのが4月で、以降は消化ポイント数を意識するのをやめた。
3月
作業効率性を上げるために hub コマンドを活用し始めた。具体的には プルリクエストの作成は hub コマンドで行うようになった。今でもそう。他の機能は使ってない。
社内勉強会を開催した。Ruby on Rails 製の OSS のソースコードを読んで「なんだコレ」する会。題材はGitLabにした。新規メンバーが増えたこともあり、コミュニケーションを取ることも兼ねて数回行った。
今では自然消滅したが、またきっかけがあれば開催しようと思っている。
この月はまだポイント消化数に拘っていたので、結果、ベストスコアを叩き出した。
4月
esa に日報をつけていたのだが、日に日に内容が薄れていることを自覚してもやもやしていた。
仕様の検討や実装で分かった点・気になった点などをメモしたいけど、いちいち esa を開いてまとめながら作業するのも面倒だし、後から思い出しながらまとめるのはもっと面倒だったので、Slackに times-yasuhiroki
チャンネルを作って分報を始めることにした。分報で雑にメモして、そのメモを日報にまとめるスタイルにした。
分報で悩みをボヤくとアドバイスをもらえたり、なんでもないような呟きにツッコミがもらえたりと有益だった。
分報は今でも、当時ほどの量はないが続けている。
4月末に妻と娘が戻ってきた。
生活が一変した。
5月
生産量が目に見えて減った。そもそも出社時間が短くなったし、自宅で仕事する時間も激減した。勉強する時間はほぼゼロになった。 ただ、自分の時間が減ったのは確かだが、それでも時間が全くないわけじゃなかった。平日は夜にアニメを観る時間はあったし、休日は昼寝をする時間があった。要するに時間の使い方の問題なのだけど、アニメも昼寝も削る気にはなれなかった。
この頃、システムの小規模なリアーキを行った。それまで Rails の SuckerPunch で行っていた非同期を AWS SQS で Message にして ElasticBeanstalk の Worker で処理するように変更した。非同期処理は SQS 経由で行うシステム構成へ変更する足がかりとなった。この実装は少々時間がかかったが楽しかった。
現状の問題を解決する新しい仕組みを検討・導入するのは楽しい。
また、サービスの使われ方の調査やKPI測定のために Jupyter を使い始めた。pandas
はすごく便利。
6月
AWS Summit の Startup 向けコーナーで 15分の発表をした。内容はAWSリソースの構成管理をテーマに、CloudFormation の CI/CD を考えるもの。 CIで使えるツールの例として cfn-lint
を紹介したのだけど、発表した後に聞いたセッションで cfn-python-lint
の存在を知り「マジかよ...」と悲しい思いをした。すぐにインストールして、やがて vim の ale.vim
で動くように対応して Qiitaに記事 も書いた。
この頃から、たまにリモートワークをするようになった。仕事に集中できるかどうかは、タスクと家庭状況によってまちまち。少なくとも仕事の方は、仕様が決まっていると作業が捗りやすく、一方で、相談が必要な作業は滞りがちだった。
もともと、口頭のやり取りで仕様を相談しその結論が文章化されるのはプルリクになってから、という傾向が強かったので、リモートに対応するには情報共有の文化の面で課題があった。
このリモートワークにおける情報共有の課題は少しずつ改善されている。特に GitHub で仕様を議論するルールになったことで情報共有漏れは解消された。
一方で、リモートワークしている人がどういう状況か見えない問題もあって、私はなるべくSlackで発言したりリアクションすることで「オンラインですよ」アピールをしているのだけど、そのせいで作業に集中できていない面もある。ビデオチャットを垂れ流すのが良いのかなーとは思うけど、自主的にならともかく、ルール化すると女性がノーメイクでラフにリモートワークしづらくなるのでは、などと余計なことを心配したりしている。余計なお世話な自覚はある。
7月
ebisu.rb に参加し、RubyやRailsのキャッチアップが全くできていないことを思い知り、週刊Railsウォッチを読むことにした。
Androidのタスクを少しずつ進めることにした。業務経験はあったがほとんど忘れているので、簡単な機能やバグ修正だけ手伝う感じ。今でも同じ距離感で開発に参加していて、GCMからFCMに乗り換えなど、サービスの機能とは少し離れた部分にコミットしている。
また、リモートワークにて情報共有漏れによる時間ロスが発生し、対策として毎朝 slack でその日の作業予定を報告する運用を始めた。これは今も続いているが、若干、形骸化しているので、有効活用する仕組みを考えるか、廃止を含めて考え直すかしたい。
8月
体調が芳しくなく、長期休暇もあって生産量が大きく減った。開発以外のタスクばかり進めて何も生み出していないような気分になっていたが、後半は持ち直したような気もする。
9月
8月と打って変わって生産的だった。CSの仕組みを変更して自動化したり、 go でごにょごにょしたり、Rubyの正規表現を調べてLTしたりした。
久々に飲みすぎて視界が真っ白になった。なんとか帰宅できたが、いろいろとギリギリだった。
10月
かなりレジェンドな感じだったある実装がいよいよ限界なのでリファクタを始めた。このリファクタは気に入っていて、リファクタの規模を抑えつつ、スケールしやすくエラー時の検知も分かりやすくリトライ可能な実装になったので嬉しい。ただし妥協点もあって、この妥協点がいずれ負債になる未来も見えている。
NHK筋肉体操を始めた。今も続けている。二期があるとのことで楽しみにしている。
11月
サービスの課題や新機能の効果測定のためにデータを調べる機会が増えた。別に依頼されたわけじゃなくて、自分が気になるから調べていたのだけど、もっと早くからこの習慣を身に着けておけば良かったと思っている。
Ebisu.rb で rb コマンドについて発表してきた。スライド無しで README に書いておいたコマンドを実行しながら説明する実演スタイルで発表したが、そこそこ良い反応が得られてよかった。個人的にも楽しかったので、実演スタイルの発表は今後も挑戦してみたい。
VimConf2018 に行ってきた。最高だった。最高に最高だった。
12月
AWSのキャッチアップがまるでできていないと気づいたので、 AWS Black Belt Online Seminar を聞くことにした。1時間でたっぷり情報が得られてとても良い。継続的に視聴していきたい。
CircleCI のハッカソンに参加して reviewdog 用の orb を作った。こういう成果物が残るのは良い。
年末に体調を崩した。もともと私は年に一度、冬の季節に高熱を出す習慣があるんだけど、今年は吐き気もして最悪だった。結局年明けまで回復しきらず、散々な年末年始だった。
まとめ
月ごとに振り返りながら思ったことをリスト化
- インプットが足りていない
- 年末に意識し始めたけど、インプットが足りてない
- 時間というよりインプットの質の問題な気もする
- アウトプットが足りていない
- せっかく読んだ本・スライドの内容をアウトプットしていないので自分の血肉なった感覚がない
- コンテンツのように消化しておしまいな傾向があるので改めたい
- 短い期間でふりかえりしたい
- 意外とやってたり、やってなかったりすることに気づける