sora_ichigo のブログ

呟きたい時に呟きます

2025年の振り返り

昨年の振り返りはこちら。

振り返り内容が形式的になりつつあったので今年は自由に書き殴るスタイルでいこうと思う。

昨年の目標

昨年の振り返りの最後に抱負として挙げた項目がどうなったのか振り返る。

長期的なキャリアビジョンを語れるようになる

これはおおよそクリアになったと思う。1年前は解像度が高くなかったけど要するに仕事のやりたいことの軸を見つけたいという話だった。「いつまでにこれになりたい」という野望はないけれど、「自分の仕事のやりがいはこれだ」という軸なら整理することができた。詳しくは 自分のやりたい仕事をして、結果を出して貢献する - sora_ichigo のブログ に書いたのでこちらには書かないが、面白い問題に取り組み続け、解ける問題のサイズを大きくしていきたい。

年内に新居に引っ越す

これは達成済み。実は 1月時点ですぐに引っ越していた。賃貸更新料のハガキを見て翌日内見、その場で決定した。引越しといっても向かいのマンションに移動しただけなので気楽だった。部屋が広くなってオートロックがつき、線路から離れて静かになったので満足している。家賃が1.5倍になってしまったが、家計が改善したので以前よりも余裕を持って支払いができている。

友人と定期的に会う

これも変わらず達成できたと思う。6月には自身の結婚式を挙げたのでそこで学生時代の友達にたくさん会えたのも嬉しい。来年以降も関係性を大切にしていきたい。

継続する (読書、柔軟、Duolingo、日報、運動)

運動以外は継続できた。特に読書は自分の中で1番の趣味になっている。もともと本が好きだったが、今年は数だけでなく、今まで自分が手に取っていなかったような日本文学や翻訳小説にも挑戦できた。一度読んだだけでは理解できない本も多かったので、繰り返し読んでじっくり楽しみたい。

運動は全然達成できなかった。体重、健康はギリギリ維持か若干悪化。特にこのブログを書いている正月時点では正月太りをしてしまって情けない。Switch のリングフィットアドベンチャーを買ったのでこれを習慣化したい。

仕事の振り返り

2025年は忍耐の年になったと思う。昨年の振り返りに書いたが、自分は勉強にしてもスポーツにしても同じ場所に3年以上止まって努力し続けられなかったので、今の仕事も3年目で挫折してしまうかと危惧していたが、無事に乗り越えることができた。

「うまく行かずとも、長い目で見て欲張りすぎず忍耐する」という意識があったからこそ3年目を乗り越えられたと思う。また、じっと忍耐する中で自分の人生や仕事観について深く考える時間をとれたことで来年以降飛躍するための地盤が整ったようにも感じる。これは学生のころに済ませておくべき整理だったかもしれないが、学生の頃は何も考えず学び遊んでいたので仕方がない。

忍耐、と言いつつも実際には色々と仕事は進捗したし、昨年よりも任せられる仕事の責任範囲は1段階上がったのでこれは意外だった。特にプロジェクトリードからチームリードへの役割変化、自身の弱みであった課題発見に対する苦手意識が払拭できたことは今年の印象として大きい。課題発見の苦手意識を払拭したついでにプロジェクトマネジメントロールも担うようになり、これも自分で面白い問題を見出せる楽しみがあって良い。来年以降はより大きなインパクトを出せるように頑張ろう。

プライベートの振り返り

プライベートと一口に言っても色々な要素があるので切り分けて考えていきたい。

家庭については、おおよそ円満に言ったと思う。今年で結婚して1年、付き合って3年が経ったが出会った当初に比べたら非常に平和な生活が実現できていると思う。お互いがお互いに対する接し方を学んだことで喧嘩が本当に少なくなったと思う。家計も安定しているので良い。

個人としては (今に始まったことではないが) 短気の嫌いがあるのが良くない。表に出さないので指摘されることは少ないが、気に食わないことがあったり、疲れたりするだけで自分の内側では信じられないくらい感情が動いてしまう。これを人にぶつけてはいけないので、プライベートな分報に気持ちや考えを書き殴ったりして消化するようにしている。しかし、妻は一緒にいる時間が長い分、どうしても自分の気分の浮き沈みを感じさせてしまっていると思う。2人で外出している時に顕著で、家にいるときは幾分落ち着く性分なので外出する際は気をつけなくてはいけない。

趣味については、良い年になったと思う。特に本を読むのは楽しい。今年、最も印象に残ったのは三浦綾子の『氷点』という小説だった。実は5年前にも読んでおり、印象深かったので改めて読んでみたのだが、以前とは全く違う感じ方をしたので驚いた。以前はなんとなく「面白いな、好きだな」と思っていたのだが、今年読んでみると「これは (自分にとって) 恐ろしい小説だ」と感じるようになった。というのも、この小説の主人公である啓造がまるで自分の分身のように感じられたためである。この小説を読んだ人なら分かると思うが、啓造が自分であるというのは不名誉なことである。

小説の本質は代理経験なので、第三者視点で俯瞰して読むより、登場人物の誰か (多くの場合は主人公) の視点に自分を重ねて読める方が良い。その点『氷点』ほど登場人物に自分を重ねる小説はないと思った。三浦綾子に興味を持って、他にも数冊読んでみて、どれも面白かったが、登場人物が聖人君子ばかりだったのは馴染めなかった。それでも物語として読み応えがあって、意識が高まる感じが好きなので今後も三浦作品は読み続けると思う。三浦作品以外にも、今年は太宰や漱石などの有名どころを読んだ。綾辻行人の館シリーズも読んだ。今は司馬遼太郎の『坂の上の雲』を読んでいる。これは自分の中の歴史ブームによる影響で、他にも映画では『オッペンハイマー』を見たりしている。

学習については、今年は基礎を重んじる傾向が強まった思う。流行りの技術書やビジネス書よりも古くから読み継がれてきた名著を手に取るようになった。これは仕事の役割変化が大きいと思っていて、ここまでは要領の良さで成果を出してきたが、この先さらに成長するためには地盤を固めなければいけないと直感しているためである。今はコンピュータサイエンスの学び直しをしているが、純粋に学ぶことが楽しいのでこれも趣味の一つに数えたい。

今年の反省 / 来年の抱負

後悔はない。あるとすれば、運動の習慣化に失敗したなというくらい。これは2026年に頑張りたい。

反省というより来年はもっと上手くやりたいこととしては次が挙げられる。

  • もっと上手くリフレッシュできると思う
    • ある作業や行動、時間は、捉えようによってはリフレッシュになりうる
    • 気の持ちよう次第で幸福を感じられる時に自分の解釈でそれを潰してはならない
  • もっと仕事に情熱を持てると思う
    • 色々と上手くなってしまったせいでこなしている感が強まっているのは良くない
    • 自分が満足できる仕事をすることに手を抜かない
  • もっと理解を深めることができると思う
    • 以前から自分の思慮や理解が浅く感じることにコンプレックスがあるが、これが最近は特に強まっているように感じる
    • 適当な読書や学習で自分を誤魔化さず、理解を求めて考えることを諦めない
    • また思考のツールとして文章力を改めて身に付けたい

2024年末に自分の中にあったのは悩みだったが、2025年末にはこれが不満足になった。これは視界がクリアになり自己成長のモチベーションが出現した結果なので悪いことではないと思っている。2026年は手を緩めず、自分の速度で成長していきたい。ただし燃え尽きてしまわないように妻や友人、趣味と過ごす時間は大切に。

2024年の振り返り

2024年の振り返りをします。昨年の振り返りはこちら。

個人ブログに投稿していましたが、そちらをクローズしたのではてなブログに再投稿します。

総括

仕事での成長や結婚などによりライフステージが変化した一年でした。体感ですが昨年までより人生の難易度が上がったような気がします。

上手くいかないこともありましたが、自分にとって転換期となる一年になったと思います。

スピードよりも深みの重要度が増してきた

年始から8月まではプロダクト開発のグロースに携わっており、プロジェクトリード的な役割をしていました。そして、9月からは一旦プロダクト開発を離れて以前より関心のあった開発生産性向上の取り組みに注力し始めました。しかし、開発生産性という抽象的なテーマで具体的な実現可能性や会社にとっての価値を十分に示す計画が立てられなかったこと、同時期にリリースが予定されていた新規プロダクトで人手が必要だったことなどの要因が重なり、10月中旬から開発生産性の取り組みは一度解体され、新規プロダクト側のプロジェクトリード、エンジニアとしての役割に再び戻ってきました。

また、メインの業務以外だと、バックエンドエンジニア採用に選考官として関わるようになったり、メンターとして部下を持つようになりました。

今年は仕事面では出来ること・出来ないことがはっきりとしてきた一年でした。自分の認識は以下の通りです。

  • 出来ること
    • 事前にゴール設定された課題を解くこと
      • 設計・コーディング
      • プロジェクトマネジメント
  • 出来ないこと
    • 課題定義
      • ゼロベースで解く価値のある課題を定義し、周囲に受け入れられること（チームリーダーとしての役割をイメージ）
      • 既にあるいくつかの課題の優先順位や取捨選択の調整を行うこと（POとのコミュニケーションをイメージ）

現在、自分は上達曲線におけるプラトー（停滞期）にいると認識しています。良く言えばコンフォートゾーンに留まらず挑戦を続けられている、悪く言えば成長スピードが鈍化してきたといったところです。

少し脱線しますが、自分は早熟タイプの人間です。人生を振り返ってみると（学生時代の部活や勉学、仕事において）周囲と平均して特定の成長段階に達するスピードが早いことが多かったです。しかし、一方で特定の成長段階に達した後の停滞期を乗り越えた経験はほとんどありません。部活にしろ勉学にしろ、スランプと誤解して挫折してしまうか単純に飽きて他のことを始めてしまうことが多かったです。特に後者に関しては、他のことを始めればまた早熟にとってのボーナスタイム（周囲より早く成長して成果を出せる）に酔うことができるので厄介です。事実、18歳の時に勉学からエンジニアリング（≒仕事）にシフトチェンジしたときは勉学の停滞期に飽きてしまっていた節があります。

しかし今年に入って、ここから先はもう少し長期スパンで自分の人生を考えないといけないなと思う機会が増えました。学生時代は3年単位で環境がリセットされるので早熟タイプの美味しいところだけが目立っていましたが、仕事は何十年と続いていきます。それを考えると早熟タイプのボーナスタイムばかり繰り返してもジョブホッパーにしかなれないと思ってしまったのです。これは別にジョブホッパーが悪いことだというより単純に自分の生き方としてそれは望まないという感覚です。

自分はインターン期間を含めると今の職場に入ってもうすぐ4年が経とうとしています。自分の場合、早熟タイプのボーナスタイムが切れるのが大体3~4年目あたりなので、まさに今が正念場といったところです。今の仕事を諦めたくはないという気持ちはあるので、ここはスピードよりも深みの重要度が増してきたという捉え方で新しいチャレンジをしていければと思っています。

結婚

2024年10月1日に入籍しました。既に1年以上同棲していたので何かが大きく変わった訳ではありませんが、1つの節目にはなったかなと思います。結婚を祝ってくれた方々、ありがとうございました！

昨年の生活も悪くはありませんでしたが、今年はもっと上手くやれた感触があります。昨年は家計が崩壊していたり、生活リズムが定まりきらなかったりと反省点もありましたが、今年になって大きく改善が進んでいます。

また、昨年からの大きな変化として周囲に交際を隠す必要がなくなったことが挙げられます。周囲に隠しながら生活するのは正直大変だったのでその必要がなくなって気が楽になりました。

ストレスなく、楽しく毎日を過ごせているので来年以降もこの生活が続くと良いなと思います。

習慣化

思いがけず、今年は習慣化に成功した年になりました。

  • 日報
    • その時の感情や思考をすぐに Obsidian のデイリーノートに記録する癖がついた
  • 風呂後の読書・柔軟
  • Duolingo
    • 2024年元旦から始めた
  • お金の管理
    • 個人の収支管理はマネーフォワードで行う
      • 月初は毎月予算設定する
    • 家庭の収支管理はB/43で行う
      • 入金だけして運用は妻に任せる
    • 貯金は短期的なものはネット銀行に、長期的なものは積立NISAで行う

その甲斐あって、昨年の振り返りで反省として挙げていたお金・健康・睡眠はどれもこの一年で大きく改善し目標達成することができました。

この調子で来年は運動や勉強にも手を伸ばしていきたいです。

細かな色々

上記で書ききれなかった細かいトピックを書きます。

仕事

  • 1月から3月までは新規プロダクトの開発に従事していました
  • 4月から8月までは既存プロダクトの開発に従事していました
    • 前半はとあるプロジェクトのリードを、後半は5人の小規模なチームのリードをしていました
  • 9月はプロダクト開発を離れ、基盤チームに異動しました
    • 実際には2人だけの少人数チームで、大きめのライブラリアップデートのプロジェクトを担当していたので特に何かができた訳ではありませんでした
    • 前述しましたが、チームのリードという観点では反省点の残る期間です
  • 10月からは既にあったプロジェクトと並行して新規プロダクトの開発に加わりました
    • 年単位で開発が進んできた新規プロダクトのリリースなのでかなりてんやわんやしていました
    • プライベートでの忙しさも相まって、少々無理をしながら働いていた時期でもあります
  • 11月、12月
    • 状況変わらず新規プロダクトの開発に従事していますが、あと数ヶ月したら別のプロダクトに異動することが決まっています
    • これから何をしようね、を考えているステータスです

プライベート

  • 2024年10月1日に結婚しました
  • 旅行にたくさん行きました。昨年より家計に余裕が持てたので、旅行をより楽しめました。
    • 2024年1月
      • 愛知旅行（帰省）
      • 箱根旅行
    • 2024年4月
      • 福岡旅行
    • 2024年6月
      • 宇都宮旅行
      • 箱根旅行
    • 2024年8月
      • 札幌旅行
    • 2024年9月
      • 伊豆旅行
    • 2024年10月
      • 茨城旅行（グランピング）
    • 2024年12月
      • 山形旅行
  • 2024年5月から副業をはじめました
    • 2人だけの小さな会社に1人目エンジニアとして参画し、ゼロからモバイルアプリを開発しています
    • まだリリースできていませんが、かなり形になってきています
    • 本業では積めない経験を積むことができており始めてよかったなと思います
      • モバイルアプリの開発
      • プロダクトマネジメント
        • リーンスタートアップ本を参考に実際に知り合いに声をかけて課題インタビューやソリューションインタビューをしながらアプリのコンセプトを固めていく経験をしました
      • PO（代表）とのコミュニケーション
        • 開発がわかる人ではないので「いつリリースできるの？」とか「これ作れないの？」みたいな質問をもらうことが多いです
        • 本業でプロジェクトリード的なことをしているとチームの内側を向いたマネジメントに終始しがちで、こういったチームの外側を向いたマネジメントの経験はなかったので良いトレーニングになっています
        • 思ったより難しいな、、というのが今の気持ちです
    • 一方で、稼働時間を増やしすぎて体調を崩すこともあったので来年は稼働時間の上限を決めて本業やプライベートに支障が出ないように気をつけます
  • 上京して2年が経とうとしていますが、変わらず仲の良い友人とは交流を続けることができています

外部発信

反省

忙しくしすぎてしまった

11月、12月に本業と副業でちょうどプロジェクトの佳境が重なってしまい、かなり辛かったです。 この振り返りを書いている時点では解消していますが、これが繰り返し発生してしまうとおそらく燃え尽きてしまうので対策が必要です。

今回に関しては副業で開発工数を楽観的に見積りすぎてその皺寄せが忙しさにつながってしまったことが要因です。そもそも副業はあくまで時間に余裕があった上でやるべきことだと思う（本業に支障が出るなどもってのほか）ので、来年からは月当たりの自分のキャパシティをしっかり把握した上でそのキャパシティに収まるような開発計画を立てるよう気をつけます。

長期的なキャリアビジョンが曖昧

自分が何年後にどんな状態になっていたいのか、そのために何をすべきかが曖昧でこのままだと自分の成長の頭打ちが来てしまうのではないかという不安があります。

対策として最近は古典や偉人の自伝を読み始めました。「この人のようになりたい」を発見できれば道が開ける気がするのでより他人に関心を持つように心がけていきたいです。

来年の抱負

焦らず、長い目で成長していけたら良いなと思います。公私共に楽しんでいきたいです。

目標

  • 長期的なキャリアビジョンを語れるようになる
  • 年内に新居に引っ越す
  • 友人と定期的に会う
  • 継続する
    • 読書
    • 柔軟
    • Duolingo
    • 日報
    • 運動（いまは出来ていない）

自分のやりたい仕事をして、結果を出して貢献する

私が好きな言葉に「自分のやりたい仕事をして、結果を出して貢献する」という言葉がある。この言葉は僕が仕事で迷った時に思い出す言葉であり、チームリードとしてメンバー1人1人の役割を考える時に大切にする言葉でもある。

この考え方では自分の「やりたい仕事」がまず先にあって、その上で結果を最大化することを考える。もちろん組織としては「やるべき仕事」から「やりたい仕事」を見出す動きが求められる。しかしそのような場合でも自分の根元にあるモチベーションが「やるべき仕事」ではなく「やりたい仕事」にあることには違いない。

つまり「やりたい仕事」が分からなければ、自分の満足する結果を出すことができない。一方で私自身、今年はやりたいことを忘れてやるべきことしか考えられなかった時期もあったので、2025年最後に改めて自分のやりたい仕事を言語化しようと思う。

私の仕事について

私はソフトウェアエンジニアとして、 Wantedly Visit という Web サービスの開発をしている。Wantedly Visit は人と企業をつなぐ採用マッチングプラットフォームである。2012年に始まったサービスで、今では400万人が登録している。私はその中で数人規模の小チームをリードしながら、個人でもプレイヤーとして手を動かす立場にいる。

少し抽象的な言い方になってしまうが、私は自分の仕事を「プロダクト開発を通じてユーザーの課題を解決する仕事」だと思っている。言葉にするとシンプルだが、複数人でのプロダクト開発を成立させ、ユーザーの手元まで価値を届けるために、ソフトウェアの設計・実装以外にも、プロダクトの企画・要件定義やチームマネジメント、ピープルマネジメント (評価、育成、採用) など様々な業務に携わっている。

私にとって、やりたい仕事

私にとっての「やりたい仕事」は「そこでしか関われない面白い問題に取り組める仕事」だと思う。自分の解ける問題のサイズを大きくしていきたいという気持ちが成長のモチベーションになっているし、面白い問題であればお金がもらえなくても働きたいと思っている（実際、楽しくて休日までコードを書いてしまうこともある）。

今年、初めて自分でゼロから企画した機能がある。AIエージェントモードという、企業の候補者探しを AI で自動化する機能だ。企業の採用担当者は日々、膨大な候補者の中から自社に合いそうな人を探し出し、一人ひとりにメッセージを送る。この作業には相当な時間がかかる。そこをAIに任せられないか、というのがこの機能の出発点だった。

企画の段階では、チームとして何をやるべきか、を自分で見出して提案する必要があった。これは正直に言えば、それまで私がずっと苦手としてきたことだった。「これをやるべきだ」という直感はあっても、それを次の四半期、一年の取り組みとして承認してもらえない。そういう経験を何度もしてきた。

それまでの失敗の経験を振り返り、今回はまず全体像を描くことから始めた。自分の良いと思ったアイデア以外にも、どんな選択肢があって、それぞれ何が論点になるのか。大きな論点から順番に比較軸を整理していくことで、自分の直感を論理的に説明できるようになった。その甲斐あって、提案が通り、6ヶ月というプロジェクト期間とチームを任された。

そこからは没頭する日々だった。どうすればインパクトを出せるか機能の形を考える時間、それを実際に手を動かして形にしていく時間、チームメンバーが書いたコードをレビューしながら想定外の気づきを得る瞬間、どれも楽しかった。

現在地とこれから

AIエージェントモードの企画から半年が経ち、無事、自分が企画した機能は先月リリースされた。それ以外にもチームとしては並行していくつかのプロジェクトを完了することが出来て、現在も新たな機能の開発が進行している。

ただ、正直なところ、今はまだ「まだ機能をリリースできた」という成果しか出せていない。「やりたい仕事をして、結果を出して貢献する」という言葉でいうところの結果が追いついていない状況である。実際に使ってもらえるユーザーを増やし続けること、機能を作るだけじゃなくて長期的に改善していける仕組みを内部から作り上げることが今後のやるべきことで、ではどうやってそれらを実現するのかはまだ分かっていない。

しかし、そういった答えの見えない問題に取り組んでいる時間こそが、私にとってのやりたい仕事なのだと思う。

自分のパフォーマンスを最大化し続ける方法

こんにちは。個人パフォーマンスを安定させることが得意な @sora_ichigo です。

最近何人かに何か工夫してることあるの？と聞かれたのでブログとして書き出してみようと思います。

はじめに

業務に慣れてくると、求められるアウトプットのレベルや量は上がっていきます。

しかし業務知識をいくら習得しても、働き方が非効率だとパフォーマンスは安定せず、上昇する期待値についていけません。 仕事の成果を増やしたり、残業を減らしてプライベート時間を充実させるためには自分のパフォーマンスを最大化し続ける必要があります。

4つの意識を持つ

自分のパフォーマンスを最大化し続けるためには、4つの意識を持ちましょう。

  1. 決して「余裕」を失わない
  2. 「よし、やるぞ！」と脳が勝手に思える習慣を持つ
  3. 仕事に「モヤモヤ」を持ちこまない
  4. 健康でなければ全ての工夫は無意味

重要なのはプロジェクトが佳境の時など、普段より忙しい時こそ4つの意識を忘れないことです。ダラダラ仕事をしても満足な品質は得られないので、決して稼働時間を増やして解決しようなどと思ってはいけません。

自分の場合

以下は自分が最近忙しかった週のカレンダーです。

※ 19時以降の予定は仕事とは関係ない予定です。予定名は塗りつぶしています。

先週の自分のカレンダー

この週はメインプロジェクトが佳境でタスクが無限にある状態で、サブプロジェクトの進行と長期インターン生のメンター業務を進めつつ、午後は大体 MTG で埋まっていて（マネージャーではありません）、しかも月曜は祝日というハードな週でした。

しかし前述の4つの意識を実践したところ、予定通りのスケジュールかつ満足のいく品質で全タスクを完了させることが出来ました。

実行方法

4つの意識をどう実行するかは人による部分があると思います。 ここでは自分が日常的に実践している方法を紹介します。

決して「余裕」を失わない

余裕を持つことで、仕事の質が上がったり、空いた時間を有効活用できたり、突然のアクシデントにも強くなったりします。余裕を持つために自分は以下の工夫を行なっています。

  • ロケットスタートで行う
    • その週のタスクは月曜に8割終わらせる
    • その日のタスクは午前に8割終わらせる
  • 計画的に行う
    • デイリーのタスク管理、今後リスクになりそうな問題の先回りなど
    • 午前中にロケットスタートを決めるため、前日までに計画を済ませておくと良い
  • 集中したい時間帯に MTG を入れない
    • ~12:00

「よし、やるぞ！」と脳が勝手に思える習慣を持つ

フロー状態に簡単に入るスイッチを持っておくと良いです。自分の場合は以下の条件がスイッチです。

  • 午前中
  • イヤホン・ディスプレイ・椅子と机を用意する
  • iPhone を集中モードにする
  • 私服に着替える

逆にどうしてもやる気が出ない時はこれらの行動は避けています。これは「条件達成 = フロー状態に入る」の信用が崩れないようにするためです。

仕事に「モヤモヤ」を持ちこまない

頭の中のモヤモヤは集中を妨げる原因になります。モヤモヤしながら仕事をしても上手くいかず、さらにモヤモヤする悪循環に陥ります。

しかしモヤモヤを完全に消すことは出来ないので、自分は以下の方法でモヤモヤとうまく付き合っています。

  • いつでも開ける日記を持つ
    • モヤモヤや考え事は思いついたタイミングで書くことで頭から一度追い出す
  • 気分がノらない時は何もしない
    • 気分がノらない時の3時間は気分がノっている時の30分

健康でなければ全ての工夫は無意味

例えば風邪をひいてしまったり、夜更かしして日中眠くなってしまうとどうしても集中力は生まれません。 逆に体が健康であれば、それだけで集中力が大きく向上するので働く上ではなるべく健康が良いです。

自分は健康のために以下のような方法をとっています。

  • 睡眠を整える
    • 寝つきと寝起きを良くする
    • 睡眠途中で目が覚めないようにする
  • 週3でランニングする
    • 定期的に汗を流すことで幸せホルモン的なやつが溢れ出る（気がする）
  • 17時退勤を目指す
    • ダラダラと残業すると疲れが取れにくい

まとめ

自分のパフォーマンスを最大化し続けるためには、4つの意識を持ちましょう。

  1. 決して「余裕」を失わない
  2. 「よし、やるぞ！」と脳が勝手に思える習慣を持つ
  3. 仕事に「モヤモヤ」を持ちこまない
  4. 健康でなければ全ての工夫は無意味

重要なのはプロジェクトが佳境の時など、普段より忙しい時こそ4つの意識を忘れないことです。ダラダラ仕事をしても満足な品質は得られないので、決して稼働時間を増やして解決しようなどと思ってはいけません。

GitHub Projects (v2) で個人の Issue/PR 管理をエンジニアリングする

先日、GitHub Projects (v2) を利用して個人の Issue/PR 管理を良い感じに自動化したのでその時の話をします。

ことのきっかけ

一般的なプラクティスかどうかは分かりませんがこの世の中には、個人専用の GitHub Projects を作り、そこで自身の Issue や PR を追加して管理している人たちがいます。

進行中のプロジェクト、突如発生するサブタスクなどに付随して、関わる Issue/PR の数はどんどん肥大化していきます。そんな問題に対して GitHub Projects による Issue/PR 管理はは人間の認知負荷を下げることに役立ちます。また筆者も 1 年ほど前から GitHub Projects で Issue/PR を管理しています。

しかしながら、実際に 1 年ほど運用してみると、今度は GitHub Projects 運用の複雑化が目立つようになってしまいました。例えば GitHub Projects への Issue/PR の追加漏れやステータス更新の手間、フィールド数の肥大化などの問題が度々見られていました。散乱する Issue/PR たちの辛みに比べればまだマシですが、やはり微妙感は漂います。

そこで「このまま GitHub Projects を腐らせておくのは勿体無い！」という気持ちのもと、個人用 GitHub Projects のリファクタリングを実施することにしました。

前提: Projects で管理したい Issue/PR

次の章に進む前に、自分が GitHub Projects で管理したいと思っている Issue/PR の種別を示します。Why には踏み込みませんが、今回の取り組みではこれらの Issue/PR 管理が生産性高く行える形を目指します。

  • 作業中の Issue
  • 作業中の PR
    • 実装中の PR
    • レビュー待ちの PR
    • Approve された PR
  • レビュー中の PR
    • 未レビューの PR
    • レビューを返した PR
    • Approve 済みの PR
  • 完了済みの Issue/PR

やったこと

ある程度の問題整理をしたのち、今回の取り組みでは以下の問題の解決にあたることにしました。

  1. 運用の認知負荷を下げるために、不要なステータスやカスタムフィールドを整理したい
  2. レビュー漏れ等のリスクを防ぐために、Projects への追加漏れ・ステータス更新漏れの発生を防ぎたい
  3. 継続的な運用のために、限りなく Projects の操作 (mutation) を自動化したい
  4. 継続的な運用のために、この先アイテム上限数 (1200) に達しないようする

それぞれ具体的にやることは以下の通りです。

No. やること
1 フィールド設計
2, 3 Projects 操作の自動化
4 Archiving items の利用

フィールド設計

まずは「前提: Projects で管理したい Issue/PR」たちをどのように分類するかを考えます。

  • 作業中の Issue
  • 作業中の PR
    • 実装中の PR
    • レビュー待ちの PR
    • Approve された PR
  • レビュー中の PR
    • 未レビューの PR
    • レビューを返した PR
    • Approve 済みの PR
  • 完了済みの Issue/PR

つまりフィールド設計ですが、アイテムの状態 8 個をそのままフラットに扱うメリットはなかったので、今回は "カテゴリー" と "ステータス" という二つの概念を導入してその積でアイテムの状態を決定することとします。

用語 定義
カテゴリー アイテム（Issue/PR）が属する大まかな分類。作業の性質に基づいて分けられる。
ステータス アイテム（Issue/PR）の進行状況を示す。
  • カテゴリー
    • Issues： 作業中の Issue
    • PRs: 作業中の PR
    • Review PRs：レビューリクエストを受けた PR
  • ステータス
    • In Progress： 何かしらの作業中 (未着手を含む)
    • In Pending： 何かしらの待ち状態
    • Complete： 完了可能になった状態

これらのフィールドを用いて、アイテムの状態は以下のように考えます。

カテゴリー(下) x ステータス(上) Issues PRs Review PRs
In Progress 作業中の Issue 作業中の PR 未レビューの PR
In Pending ※ レビュー待ちの PR 未レビューの PR
Complete ※ Approve 済みの PR Approve 済みの PR

※ は今回は利用しない状態をさします。なお「完了済みの Issue/PR」については問題 4 (アイテム上限数) の考慮を行うために別対応を行うのでここでは除外しています。

完了済みアイテムについて

GitHub Projects には追加できるアイテム数に上限があります (2023/10 時点で 1200 個)。業務で普段使いしていると大体半年~1 年で上限に達してしまうので継続的に Projects を利用していくためには不要になったアイテムから棚卸をしないといけません。

とはいえ完全に GitHub Projects から削除してしまうと後に掘り起こす際に不便なので、今回は Delete ではなく Archive を利用することで対応しました。Archive にしておけば専用の Archive Item ページから Issue/PR を検索することも出来るので便利です。

参考: Archiving items automatically - GitHub Docs

自動化

状態遷移図

自動化にあたり、まずはフィールド設計で導いた "カテゴリー" × "ステータス" の 8 状態 +α の状態遷移を整理しました。以下がその結果です。 ここでは前章で挙げた 8 状態に加えて「Projects 未追加」「Archive 予定 (1 日後に Archive されるアイテム)」の 2 状態を考慮しています。

Issues/PR の状態遷移図

こうして見ると全ての状態遷移は何かしらの機械判定が可能なものになっています。機械判定可能ということは自動化も可能であると推測出来るので、ひとまずはこの状態遷移図を主軸として自動化を試ることにします。

実装

GitHub Projects には公式が用意するワークフロー制御の機構が存在しますが、残念ながら今回実現したい自動化の要件を満たす機能は Auto Archiving を除くと他に 1 つもありません。さらに次点で有力そうな Webhook を活用する方法もまた、自身が管理ユーザーではない Organization に対する Webhook URL 登録が出来なかったため見送っています。

ここまで来ると、もはや残された道は GitHub API を利用して 0 から自分で状態遷移を実装を作ることくらいしかありません。こればかりは現状だとどうしようもないので、今回は自身で今回の要件を満たす Golang アプリケーションを実装することにしました。

ソースコードについては https://github.com/igsr5/github-project-automation-prototype で公開しています。

作ってみて

執筆時点では PoC 段階が終わったフェーズでまだ本実装には進んでいませんが、PoC の成果物もそれなりに活用可能な出来にはなったので実際に業務で利用することにしました。実際に使用してみると全ての Issue/PR が自動で管理される世界はとても快適でした。

また、今回の取り組みによって今まで増え続けていたいくつものフィールドが消えて、"カテゴリー" と "ステータス" のみシンプルな構造になりました。フィールド設計がシンプルに保てているのでボードを作成する際にも条件の構築が行いやすく体験がよかったです。

さらに、これは考えていなかったのですが、いざ自動化実装を動かしてみると、自分が放置していた大量の過去 Issue/PR たちが掘り起こされました。これらを特別に非表示にするオプションは導入していない (導入する予定もない) ので、プロジェクトの利便性を上げるためには必然的に不要になった Issue/PR を close することになりましたが、これがめちゃくちゃ良かったです。軽く棚卸しただけでも 50 個弱の Issue/PR が close 出来たので驚いています (反省)。

おまけ

  • 自動化は Cloud Run と Cloud Scheduler を使っています
    • 平日の9時-18時のあいだ、3分毎に GitHub API V3 を叩いて GitHub Projects の状態を更新しています
    • ロジック自体は Golang で記述
    • GitHub Api V3 の search api の rate limit に引っかからないように頻度を調整しています
  • 節約 月2,000円 → 月750円
    • 初めは時間帯制限を設けず平日の24時間フルで Cloud Scheduler を回していましたが、Cloud Run の CPU Allocation Time が増えすぎて月 2,000 円ほどかかっていたので実行タイミングを減らして節約しました。

2023年の振り返り

2023年の振り返りをします。昨年の振り返りはこちら。

igsr5.hatenablog.com

大忙しで楽しい一年でした

一瞬で過ぎたように感じつつ、振り返ればたった365日とは思えない重厚な一年になりました。

仕事・成長

2021年8月から長期インターンシップとして働いていたウォンテッドリー株式会社に正社員として入社しました。入社時点で既に在籍期間が2年弱になっていたので正直何も変わらないかな？と思っていましたが、予想に反して自分の考え方や動き方が変わったことに驚きました。

その後4月から11月までは基盤開発チームとしてプロダクト仕様の大幅変更に伴うリファクタリング及び新機能開発に従事しました。私は主にバックエンド開発とプロジェクトマネジメントを担当していました。 これが中々に高難易度なプロジェクトだったので、この半年で自身のバックエンドスキルやプロジェクトマネジメントスキルの成長に大きく繋がったと感じています。また結果的にスケジュール通りかつ高品質にプロジェクトを終えることができたのですが、これほどにレベルの高いチーム開発は今まで味わったことがなかったのでとても良い経験になりました。当時のチームメンバーと後に「あの時楽しかったねー」といった会話をすることがあるくらい良いプロジェクトだったなと思います。

12月からはチームを異動し、全く別の新規プロダクト開発にバックエンドエンジニアとして参画していました。このブログを書いている時点ではまだ何も公開できる情報がないので詳細は伏せますが、少人数のチームなこともありバックエンド領域の設計や実装は完全に自分が責任を持ってリードしています。今までよりも高いレイヤー*1でのバックエンド設計や意思決定が求められる立場で楽しく仕事ができています。

またメインタスクの側、8月には DevOps 専門チームの立ち上げを行ないました。立ち上げといってもそんなに大したことはしておらず自分の考えていた「こういうチーム作りたい！」を社内プレゼンを通して主張したり草の根的に分科会を立ち上げたりしていたらいつの間にか正式なチームになっていました。まだまだ走り出したばかりのチームで、しかも未熟な自分がリードしているチームなので伸び代だらけですが、入社前からずっとやりたかったことなのでとても楽しく活動できています。何より協力してくれているメンバーに感謝です。チームの立ち上げ話は12月の外部登壇で詳しく話したのでその際の Speaker Deck を置いておきます。

speakerdeck.com

引っ越し・同棲

就職を機に実家のある愛知県から東京都に引っ越しました。現在は目黒駅すぐ近くに住んでいるのですが、好立地かつオフィスも近いのでかなり便利です。

また東京に来てしばらくした後、付き合っている彼女と同棲を始めました。計画していた同棲ではなくある日突然スタートした同棲 (!?) だったのですが、そんな始まりにも関わらず限りなく安定した生活を送れています。

生活スタイルとしては基本的に一人の時間は少なく常に2人で何かしらするというスタイルです。自分の性格的にたまに独りの時間も欲しくなるのですが、それは仕事の時間でいい塩梅に調整できているので特に不満はなく楽しく暮らしています。彼女が非常に活発な性格なので休日や仕事後はよく旅行や飲みに連れて行ってもらいました。私自身は怠惰な性格なので家を出る前は軽くゴネながらソファにしがみついているのですが、半強制的に外に連れ出してもらえているので良い息抜きになっています。また非常に陽気な彼女なので家でも常に変なことを言って叫んだり踊ったりしています。今も執筆しながら隣でよく分からないことを言っていますが楽しいです。

来年もこの生活が続くと良いなと願っています。感謝*2です。

下北沢のきれいな道

卒業・成人

今年の1月~3月は人生において学生最後の時間となりました。私は学業よりも仕事の方が何倍も楽しく感じる性格なので実はずっと早く就職したいと考えていたのですが、いざ就職してみると学生だった頃に戻りたくなる瞬間もあります。

特に学生最後の年は時間が有り余っていたので平日の深夜や休日はよく友人とプチ旅行に出掛けていました。滝を見に行こうと出掛けてみたり、昼過ぎまで友人宅で寝た後に大阪へ思いつきの弾丸旅行をしてみたり、平日ど真ん中の深夜にドライブをして謎に琵琶湖に到着してしまったりと思い返すととてつもなく楽しい時間だったなと思います。

東京に引っ越した後も何人かの友人とは定期的にご飯に行くのですが、それでも当時に比べると顔を合わせる頻度が減っており寂しく思います。仕事が忙しかったり同棲していたりするので必然ではあるものの、せめて来年以降も定期的な交流が途絶えることなく過ごしていきたいです。

1月には成人式がありました。正直そんなに感慨深くはなかったのですが単純に久しぶりの友人に会えて楽しかったです。何人と喋ったか覚えていませんが中学当時そこまで交友のなかった人ともなぜか話が盛り上がる不思議な空間でした。また同窓会とかで集まれると良いなと思います。

3月初めに行った神戸旅行

細かないろいろ

上で書ききれなかった細かいトピックを書いていきます。

仕事

プライベート

  • 彼女がシーシャが好きなので自宅用にシーシャの道具1式を揃えました。
    • それまでは週に2, 3回お店に通っていたので月60,000円ほどお金がかかっていたのですが、自宅で済ませられるようになってからは毎日シーシャを作ってもせいぜい1万円ほどで収まっているので幸せです。
  • 旅行にたくさんいきました
    • 夏に宮古島に1週間ほど滞在しました。海がきれいでたくさんの魚と泳ぎました。日焼けで動けなくなったのはいい思い出です。
  • 勉強もそれなりにしました。
  • 個人開発はあまり出来ていません。その代わり生産性への関心が強い年だったので休日に自身の開発環境やPC環境の整理を行ったりして業務スタイルのベストプラクティスを探索することが多かったです。

宮古島で泊まった部屋のベランダ

宮古島で泊まったホテルから見えた花火。この後向こう岸で火事になってた。

反省

楽しい一年だった反面、反省もあります。主な反省は以下の3つです。

  • お金
  • 健康診断
  • 睡眠不足

お金

毎月赤字でした。当然貯金もなく毎月の家賃の支払いが危ういレベルです。 また一緒にご飯に行った方にご迷惑をおかけしてしまうこともありました*3。本当に申し訳ないです、、

原因は単に使いすぎです。お金がないのに旅行に行ってしまったり外食してしまったりするからいけません。またそれらの支払いをクレカで済ませてしまうので毎月の支払額がどんどん上がっていきます。本質的には家計を管理する役割の不在が根本原因なので最近は自分が家計の管理をしていたりします。

最近は改善の兆しが見えてきているので来年は黒字を目指して計画的にいきたいです。

健康診断

9月の健康診断で少し怒られました。 お酒の飲み過ぎでコレステロール値が引っかかったのと1年前から体重が10キロ増えていました。

1年前までは健康など気にしたこともありませんでした。しかし最近は気づけば太る、体調を崩す、で恐ろしいです。 完全に運動不足とお酒の飲み過ぎが原因なので来年は善処します。

睡眠

2023年、というよりここ1、2ヶ月の話ですが、夜眠れません。また睡眠が満足に摂れていないので日中のパフォーマンスにも悪影響が出ています。

また原因がまだはっきり分かっておらず、よく分からないまま毎日 3, 4時まで寝れない日々が続いているので何とかしないとまずいです。ここでは特に何も書けませんが、来年はまずは睡眠の質を向上させようと思います。

来年の抱負

今年の良かったところを継続しつつ、来年はもっと楽しかったと言えるような一年にしたいです。

目標

  • 1月中に睡眠の問題を解決する
  • 2月までに家計を黒字にする
  • 9月の健康診断でコレステロール値・体重を前年より下げる
  • それ以外
    • 仕事で圧倒的成長する
    • 友人と定期的に会う
    • 同棲仲良く
    • プライベートで開発する・本読む

*1:1つのプロダクトを既存プロダクトとの整合を保ちながら全く新しくデザインするという意味

*2:しかも私は1回もキッチンに立ったことがありません。いつも美味しいご飯をありがとう。

*3:先輩に意図せず多く支払いをお願いしてしまったり、名古屋のゲイ日本酒バーで現金が用意できず店主の松子ちゃんにこっそり逃してもらったりしました、、

Shopify/ruby-lsp の内部実装を読み解く (3) v0.0.2 の変更箇所を途中まで

概要

個人的に最近アツい https://github.com/Shopify/ruby-lsp の内部実装を読み解いて追加機能の提案・実装が出来るレベルを目指す。

なおこの回以外のブログは https://d.hatena.ne.jp/keyword/reading-shopify-ruby-lsp#related-blog で見ることができる。

前提

筆者に LSP (Language Server Protocol) の知識はほとんどない。クライアントとして利用しているのでどういったものかは知っているが、その内部実装には明るくない。なのでこの記事を読んでいる人で内容の誤りに気がついたらコメントして頂けるとありがたい。

やること

https://github.com/Shopify/ruby-lsp のコミットを古い方から読んでいく。こういったコードリーディングはやったことないが、単に最新のソースコードを読むよりも Shopify の優秀なエンジニアの手癖を見ることが出来て学びが多そうなので実践してみる。

追記）分量が多くなってきたので第3回からはコミット単位ではなく、気になるPR単位で読む。

今回の内容

前回は https://github.com/mtsmfm/language_server-protocol-ruby のコードリーディングを実施していた。今回は Shopify/ruby-lsp に戻ってコードリーディングを進めていく。

ここまでで v0.0.1 は見終わったので次は v0.0.2。

github.com

本編

Re-organize code to VSCode standards by mutecipher · Pull Request #2 · Shopify/ruby-lsp · GitHub

Ruby::Lsp::Handler クラスの実装が追加されている。このクラスは https://github.com/mtsmfm/language_server-protocol-ruby のサンプルコードをリファクタリングしたものになっている。変わらず JSON RPC のIOには標準入出力が利用されていて一瞬「あれ？」となったがどうやらこれが一般的らしい。

通信は基本的に標準入出力を介して行われます。なので、両者のプロセスは完全に独立している訳ではなく、サーバーはクライアントの子プロセスとして起動されるのが普通です[1]。

実際のところ、LSPには通信方式についての規定はありません。標準入出力の代わりにTCPを使う例もあります。従ってサーバーが子プロセスにならないこともあり得ますが、実例に乏しいためこのように記述しています。

Remove VSCode client logic by mutecipher · Pull Request #6 · Shopify/ruby-lsp · GitHub

Shopify/ruby-lsp の内部実装を読み解く (1) v0.0.1 の変更箇所、LSP の基本動作、LSIF (Language Server Index Format) - igsr5 のブログ で「この時はまだ VSCode Extension （のちの Shopify/vscode-ruby-lsp）も同じリポジトリに同封されているのかー」と言っていたが #6 の PR でリポジトリを分けることが決まっていた。意外と早かった。

Add support for folding defs by RyanBrushett · Pull Request #10 · Shopify/ruby-lsp · GitHub

この PR では以下の 4 つの method の実装が行われている。

handler.config do
  on("initialize") do
    store.clear
    respond_with_capabilities
  end

  on("textDocument/didChange") do |request|
    uri = request.dig(:params, :textDocument, :uri)
    text = request.dig(:params, :contentChanges, 0, :text)
    store[uri] = text

    nil
  end

  on("textDocument/didOpen") do |request|
    uri = request.dig(:params, :textDocument, :uri)
    text = request.dig(:params, :textDocument, :text)
    store[uri] = text

    nil
  end

  on("textDocument/didClose") do |request|
    uri = request.dig(:params, :textDocument, :uri)
    store.delete(uri)

    nil
  end

  on("textDocument/foldingRange") do |request|
    respond_with_folding_ranges(request.dig(:params, :textDocument, :uri))
  end

  on("shutdown") { shutdown }
end

textDocument/didOpen, textDocument/didChange, textDocument/didClose では対象のファイルの uri - contents 対をハッシュとしてインメモリに保存・更新・削除する処理を行なっている。これは大多数の method のリクエストを行う際に uri のみの params で良くするのが狙い。

Add support for document opened, changed and closed events. We need those for every request. We basically keep a hash as storage where the key is the file URI and the value is the content of that file. Most other requests will only send us the URI and so we just access the hash to get the file contents

textDocument/foldingRange に関してはここで Ruby::Lsp::Requests::FoldingRanges クラスという Ruby プログラムのパース、FoldingRange[] の抽出などを行う実装が追加されている。なお textDocument/foldingRange とはその名の通りエディタ内でコード折り畳みをしてくれるあれである。この method にリクエストすることで対象 textDocument 内のどこが折り畳み可能か？それぞれどう折り畳むか？をエディタに知らせることができる。

これはコードを読むのが早いので以下に一部実装を抜粋している。

def initialize(source)
  @parser = SyntaxTree.new(source)
  @queue = [@parser.parse]
  @ranges = []
end

def run
  until @queue.empty?
    node = @queue.shift

    case node
    when SyntaxTree::Def
      location = node.location

      @ranges << LanguageServer::Protocol::Interface::FoldingRange.new(
    start_line: location.start_line - 1,
    end_line: location.end_line - 1,
    kind: "region"
      )
    else
      @queue.unshift(*node.child_nodes.compact)
    end
  end

  @ranges
end

ここではまず syntaxTree (CRubyで利用されている Ripper を wrap したライブラリ) を用いて受け取った Ruby プログラムの文字列をパースしている。その後 SyntaxTree::Def Node を走査して、見つかった各メソッドを折り畳み対象としている。

Store the parsed tree to avoid unnecessary re-parsing by vinistock · Pull Request #13 · Shopify/ruby-lsp · GitHub

10番のPRで追加された Store クラス (uri - contents 対ハッシュをインメモリに保持しているクラス) が contents の代わりに syntax_tree でパース済みの AST を保持するようになった。これで大部分の method でいちいち syntax_tree でパースする必要がなくなった。

Introduce a generic visitor pattern for requests handling by Morriar · Pull Request #19 · Shopify/ruby-lsp · GitHub

AST Node の走査に Visitor パターンが導入された。 このPRではまだ LSP の実装に使われていないが、 https://shopify.engineering/improving-the-developer-experience-with-ruby-lsp を読んでいるなかでも Visitor パターンの言及はあって、例えば以下のような書き方ができるようになっている。

class FoldingRange < SyntaxTree::Visitor
  def initialize(ast)
    @ast = ast
    @ranges = []
  end
  
  def run
    visit(@ast)
    @ranges
  end
  
  def visit_class(node)
    location = node.location
    
    @ranges << {
      startLine: location.start_line - 1,
      endLine: location.end_line - 1,
      kind: "region",
    }
  
    super
  end
  
  def visit_def(node)
    location = node.location
    
    @ranges << {
      startLine: location.start_line - 1,
      endLine: location.end_line - 1,
      kind: "region",
    }
  
    super
  end
end

Enhance code folding by vinistock · Pull Request #20 · Shopify/ruby-lsp · GitHub

FoldingRange が強化された。今まではシンプルに def のみ折り畳み可能だったが、ここでは class や if、elsif など計 17 ケースが新たにサポートされた。 ここからも少しづつサポート範囲が広がっていくが FoldingRange については個人的にあまり関心がないので積極的に拾わないことにする。

Implement DocumentSymbol requests handler by Morriar · Pull Request #21 · Shopify/ruby-lsp · GitHub

textDocument/documentSymbol の実装が追加された。 textDocument/documentSymbol とは与えられた textDocument の中にある symbol の種類や階層関係を取得するためのメソッド。

https://user-images.githubusercontent.com/583144/160193413-5d55a95e-45e2-4f89-97ad-6d72e28ab621.png

例えば symbol の種類は 3.17 時点で以下の種類が存在する。

// https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_documentSymbol



/**
 * A symbol kind.
 */
export namespace SymbolKind {
    export const File = 1;
    export const Module = 2;
    export const Namespace = 3;
    export const Package = 4;
    export const Class = 5;
    export const Method = 6;
    export const Property = 7;
    export const Field = 8;
    export const Constructor = 9;
    export const Enum = 10;
    export const Interface = 11;
    export const Function = 12;
    export const Variable = 13;
    export const Constant = 14;
    export const String = 15;
    export const Number = 16;
    export const Boolean = 17;
    export const Array = 18;
    export const Object = 19;
    export const Key = 20;
    export const Null = 21;
    export const EnumMember = 22;
    export const Struct = 23;
    export const Event = 24;
    export const Operator = 25;
    export const TypeParameter = 26;
}

export type SymbolKind = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26;

基本的に syntax_tree がパースした AST Node のクラスと Kind が一致するので前述の Visitor パターンがとても刺さっていた。

長くなってしまったので今回はここまで。次回は https://github.com/Shopify/ruby-lsp/pull/32 から見ていく。

参考資料