2025年の振り返りと今年の抱負

長女が転園した

近況 - 何でも屋エンジニアのブログ で書いたように長女が転園した。最初は不安こともあったが、今ではとてもみんなと仲良くなり先生のことも大好きでとても楽しそうだ。 早く馴染めるといいなぁという気持ちや、気晴らしになればと思い転園してから冬になるまでほぼ毎日公園遊びをしていた。妻が育休で17時お迎え必須なので、出産後は仕事早上がりさせてもらい18時から18時半くらいまでほぼ毎日遊んだ。家が保育園から近く、かつ家の前に公園があるため早めに上がるクラスメイトが同様に公園に来るため、かなり公園で一緒に遊ぶことができた。 帰り際に一緒に今日も公園行こうね！と子供同士で約束するようになっててとても良かった。 休日も保育園の子と会うことが多かったので、土日もだいたい公園にいた。保育園だけでなく交流をできるようになると良いかなというのもあり、僕と長女で遊んでるのに入りたそうな子や近くで同じ遊具を遊ぶ子たちとも積極的に交流するようにした。すごいときには保育園問わず7人くらいの子と僕が鬼ごっこ(もちろん僕が鬼)したこともあり、とても面白かった。 そんな甲斐あってか、引っ込み思案だった長女はかなり社交的になった。以前有料の遊び場でお友達が長女の遊んでるおもちゃで遊びたいらしく癇癪起こしてしまった時があったのだが、遊び終わったあとにあの子にどうぞしなきゃっておもちゃ渡しに行ったのを見たときは本当に感動した。

次女の誕生

2人目の娘が誕生した。最初は結構大変で、育休(個人事業主なので当然ただの自腹)を一ヶ月くらい取ったが、完全母乳のためごはんをくれない僕にはまったく懐かず、基本抱っこすると泣くみたいな状態が結構続いた。また、契約期間の影響で産まれてから育休までに少しラグがあり、そのときは大変だった記憶がある。体調崩し休んでしまうことが何回かあったのだが、当時のお客様に優しくして頂き本当にありがたかった。(同時に大変心苦しく申し訳ない気持ちでいっぱいだった。)

苦労話を書いたが赤ちゃんがいる生活はめちゃくちゃ良いものだ。日々どんどん大きくなり目まぐるしく成長していく様子は赤ん坊特有だと感じる。長女と仲良くしているのは本当に微笑ましいし、六ヶ月ともなると最近は身の回りの色々なものに興味が出てきて、握ったり、引っかいたり、バンバン叩いたり、口に入れたりしながら世界を楽しんでいる。離乳食が始まり、みんなとテーブルを囲むのも嬉しそうだし、母乳以外の食事も新鮮でいつも嬉しそうでかわいい。いっぱい食べて大きくなってほしい。

子供関連でいえば他には、一番公園で遊び家族ぐるみで仲良くしていた子が引っ越ししてしまい家族全員お友達家族ロスに悲しんだり、でもこの前新居にお邪魔させて頂き再開を果たしすごく楽しかったこと、また遊ぶ約束ができて家族で喜んだこと、園でインフルエンザが猛威をふるい次女に移したくなす自主休園をしたこと(妻が頑張ってくれた)、しかしその後すぐの第二次流行タイミングで罹患してしまい僕以外みんなうつってしまったこと、長女がそのとき熱痙攣で救急搬送されるも意識レベルがすぐには戻らず肝を冷やしたこと、初めての家族4人でのディズニー、クリスマス、各種イベントなど書き出したらキリがないのでこの辺にしておく。

お客様が変わった

次女が産まれたくらいのタイミングで、お世話になったお客様との契約を解除させて頂き、育休のあと新たなお客様のもとで稼働させて頂けることになった。

次どうしようかと考えていたタイミングで元々知り合いの方に声をかけて頂きご縁をもらえたのだが、今のところ大した営業もしないで生きていられるのは本当にありがたいことだ。

新しいお客様には次女との生活がまだままならない頃に稼働面で大きく融通を利かせて頂き、本当に感謝している。

法人化

お客様とやれることを増やしたり、お客様の信頼をより得るために個人事業主から法人化しAnoka Partners(アノカ パートナーズ)株式会社を設立した。

Anoka は子供たちの名前から二文字ずつ取ったもので、妻が考えてくれた。さらにお客様と伴走していくパートナーでありたいという気持ちが強くそのために法人化したのが一番の動機であったため社名に含めた。ちなみに、アノカはアメリカに同名の地名があり、ハロウィンで有名らしくそれも良いなと思い気に入っている。

法人化した個人的なキャリア面での二次的な動機を書くと、現在生成AIの隆盛によりソフトウェアエンジニアの守備範囲が広がっていると言われている。この流れに乗っていこうと思ったとき、一応EMやCTOを始めエンジニアとして様々なポジションの経験をしてきており、より見識を広げるためには経験のない社長をやるのも良さそうだなと思った。プロダクトマネジメントも同様に経験はないが、自社で何か作れば初期はプロダクトマネジメントをすることになるだろうし、未経験なことをやれる余地がたくさんありそうというのがある。

予定より早く登記が終わったため、ホームページが間に合っていない。他にもたくさんまだまだやることがあり、法人運営というのは本当に色々なことが必要なのだなと日々勉強になっている。ホームページ、早く作らねば…。

ジムを変えた

IT 健保で優待？のあるコナミスポーツジムへ回数券で通っていたが、法人化に伴い健康保険組合を変える必要もあったため、家近の24h/365日やっている系のジムに変えた。他には健康のため1回の練習時間を少なくして日数を増やしたく、さらにその方が今の生活スタイルにあってるのではという理由もあった。これが大当たりで行く回数も増え、インターバルが少ないことで健康面精神面でとても良い効果がでている。さらに、練習頻度が上がったことでいつか達成できたらいいなと思っていた重量も一部換算ではあるが全て達成することができた。こうなると、ベンチも100を目標にする？となるものの自分の中では逆に健康に悪影響な負荷な気もしているので、様子を見ながら計画を練りたい。

2026年の目標

関わってくださる全ての方にAnoka Partners株式会社やebihara99999で良かったなと思って頂けるよう全力を尽くしていきたい。その中でもお客様には特にそう思って頂けるよう引き続き頑張っていく。その中で売上もついてくるとなおよし。 たぶん初めてのことだらけで色々なことが起きると思うけど、前向きに笑っていれば何とかなるはず。

プライベートでは自分含め家族が健康で仲良く楽しく過ごせることが一番で、それ以外は次女が少し大きくなったので旅行に1回くらいいきたいな。

会社、個人ともども本年もよろしくお願い致します。

近況

子どもが転園した

4月より保育園を転園した。新しい園はすごく近く、徒歩1分くらいで着く。さらに体制もしっかりしているし外部講師を招いた体操教室などの習い事も保育中にやってくれるとのことで、とても魅力的に見えていた。当時在籍していた園が新規園を積極的に開園するせいで慢性的な人員不足に陥っており先生が短期間で入れ替わることも多く、通わせ続けることに不安を感じていたものの、慣らし保育もあるし新しい環境に馴染めるのかとても不安だったのでとても迷っていた。しかし、第二子が産まれる予定もありその子も不安を抱えたまま当該園に通うのか？と考え、そして2人を自転車必須の距離の園に通わせる負担を考慮し、転園を申し込んだ。長女も長期的には安定下体制の園で色々な教育を受けられた方が良い影響があるのではないかという希望的観測もある。

慣らし保育は僕がメインで担当したこともありキツかったが、お客様が柔軟に対応してくださってなんとかクリアした。長女は早々に慣れて新しい園に通えているが、引っ込み思案な性格のためお友達と気軽に遊ぶとこまでは行けていないようでつまんないとのこと。お友達は歓迎してくれている様子なので親としてはもどかしいが、ちょっとずつ慣れていってもらわねばならない。

とはいえそう感じながらも嫌がりつつちゃんと通ってくれて感謝している。せめて家にいるときはたくさん遊んであげようと思っている。

今の保育園は園の中まで親が送り荷物の準備をするのだが、初日から子どもたちが僕のとこにきてわいわいしていた。その後も行くたびに色々な子が話しかけに来るのでとても楽しい。どんな子たちか分かるのは親としても安心感がある。

という感じで良い面不安なあるけど、ネガティブな方は時間が解決してくれるだろう。

キックボクシングをやめた

正確にはずっと通っていたジムをやめた。18歳から通っていたので、18年ほど通っていたことになる。数年前にジムが引っ越し車で45分くらいのところになったのもあり、少し通いづらくなっていた。僕が独立したことと第二子が産まれることもあり、この距離で通い続けるのは難しいなと感じすごく迷ったが一度退会した。落ち着いたらまた通いたい。

会長は事あるごと色々相談に乗ってもらっていたので会う機会が減るのはさみしいが、半年に一度くらいは諸用で会えるし縁がなくなるわけではないので、今に集中しようと思う。

とはいえ格闘技をやめるつもりはあまりなく、来週家から近いボクシングジムに体験に行くつもり。柔道とかレスリングとか空手とかもやりたいなと思っているが最寄り駅にないので、どうなるかな。

Ruby のソースコードの proc\.c を読んだ

Ruby の朝刊 ruby trunk changes より github.com

を発見したので proc.c を読んでみる。大枠では Proc や lambda、Binding に関する実装がしていることが分かった。たしかに実行コンテキストを保持する必要があるので、同じソースで実装するのもわかる気がするという感じだったが、デバッガー動かしながら詳細を見ないときちんと理解できなさそうだったので、Ruby をソースコードから build した。

$ sudo apt install -y build-essential libssl-dev libreadline-dev zlib1g-dev bison automake
$  autoreconf --install
$  ./configure --enable-debug-env CFLAGS="-O0 -g" 
$ make
$ echo 'p = Proc.new { |x| x + 1 }; p.call(1)' > test.rb
$  gdb --args ./ruby test.rb

としデバッグを始めることができた（WSL2 Ubuntu）。Mac だと make が LDFLAG のせいで失敗していたので、この辺ちゃんと設定しないといけないのだろう。

時間が来てしまったので、いったんこの辺で今日は終わり。

Ruby YJIT の `invariants.rs` を読んだ

少し古いバージョンの Ruby のとある不具合調査を行い Ruby の C コード読んで、たまたまかもしれないけど割と読め楽しくて興味がでてきた

— ebi (@ebihara99999) 2025年2月28日

ということで Ruby のソースコードも読んでみようと思い、Ruby の朝刊

ruby-trunk-changes.hatenablog.com

を読み始めた。その中で yjit の invariants.rs が挙がっていたので読んでみた。

github.com

雰囲気でしかわからないが、いくつかの assumptions を置き、それらの assumptions が有効なのか無効なのかを追跡し、assumptions が無効だったら生成されたコードを無効化するという処理をしている。

assumptions はについては

• Ruby の基本的な演算子はオーバーライドされない
• 定数が再代入されていない
• callable method entry に関するもの（おそらくあるメソッドが再定義されているか）
• klass object が singleton class を持たない

などがある。

ということがわかった。

楽しいし、続ければ何か視野が広がることもあるだろうから朝刊読んで気になったところ調べてみるというのは Ruby の方でもやってみようと思う。

Rails の `ActiveSupport::JSON.encode` を読んだ

Rails のソースコードリーディング。今日の朝刊から ActiveSupport::JSON.encode を読む。

y-yagi.hatenablog.com

よく使う to_json のメソッドの中身で、JSON エンコードを責務として持つ。

• エスケープ処理
• use_standard_json_time_format など設定の管理
• Encoder に JSON Gem を使うかなどの設定

などを行っている。

合わせて activesupport/lib/active_support/core_ext/object/json.rb を読んだが、こちらは様々なクラスに as_json を拡張しているようだった。

ところで、メモ程度だしソースコードリーディングの内容を書くのは cosense で良いかなと思ったものの、知識としての記録ではなくどちらかというと「やった」ことを記録したい意図が強いのでブログに書いていこう。

2024年の振り返り

今年は自分の中で色々あった年だったなぁ。

まず念願の家を購入した。マンションの人みんな感じが良く必ず挨拶してくれるし、子どもにもとても優しく接してくれる点がとても気に入っている。引っ越して一ヶ月くらいで壁にクレヨンで落書きされたが、ピリピリしないで済むしなんなら良い思い出としてもう少し大きくなったときに話すことを楽しみにしている。

今年一番の変化は会社をやめて独立したことだろう。辞めて言うのも変だが全然辞めるつもりなんかなく、やりたいこともたくさんあったので勤め続け10年の永年勤続の賞をもらうのだろうと考えていた。とてもチャレンジングな環境で過ごさせて頂いたことを今でもとても感謝している。

しかしタイミングというのは恐ろしいもので、色々なタイミングが重なり独立してしまった。独立についてはずっと夢だったこともあり、やるならもう今しかないだろうと思い切ってみた。今のところ楽しくやれているので決断してよかったと思っている。迷ったときに安牌を選ばないのが自分の性格で今回もそのような判断をしたのだけど、今のところ楽しくやれているのでとても良い判断だったと思う。

独立してから家族との時間をより取れるようになった。それについて家族みんなとても嬉しそうにしていて、特に子どもとの距離がとても縮まった。子どもの成長を目に焼き付けながら、毎日を過ごせることがすごく幸せに感じている。いちプログラマに戻ったこともあり、技術力の向上にもプライベートの時間が割けているし、良いバランスで進められているように感じる。

独立して初めての現場では、久しぶりの IC プラス業務委託という立場もありどう振る舞うのが良いのか迷いつつ参画したが、結局普段通りに振る舞うことにした。年末の挨拶をした際、海老原さんがいなかったらプロジェクトがもっと大変だったはずととても嬉しい言葉をかけて頂けたので、心配だったがお役に立てたんだなとほっとした。チーム内外みなさんとても良い人で、個人的にわいわいやりたいタイプなのでこの辺もとても助かっている。出社してランチするのが楽しみという生活ができているのでとてもありがたい。

ところで、今年の夏から秋にかけては個人的に色々あったけど、家族と友人たちが気にかけてくれたおかげで、なんとかやってこられた。特に気にかけてくれた友人は今でも高頻度でやり取りして悩みを相談したり何でもない話をさせてくれるのでとても助かっている。世話になったお礼を先日の長電話のときに言えたのでよかった。今年はお互い色々あったけど、来年の戦略も見えてきたことだしお互いぼちぼちやっていきましょ。

ウェイト始めたいの夢は、前職の同僚が会社にあるジムに同行し色々レクチャーしてくれたのをきっかけに始めることができた。今は IT 健保の割引を使ってジムに通っている。キックボクシングも走るのもウェイトの効果が出ているし、体調も良いのでもっと早く始めればよかったなと思っている。

来年はまた色々忙しくなりそうなことが分かっているので、日々を楽しみつつやっていくつもりだ。

Ruby コードの内部品質に関するメトリクスを取得する

はじめに

この記事は Ruby Advent Calender 2024 の25日目の記事です。

qiita.com

内部品質に関するメトリクスとは

ソフトウェアの内部品質に関するメトリクスとは、大まかに言うと読みやすさに関するメトリクスのことを指します。プログラムの長さ、呼び出しの回数、条件分岐の多さ・深さ、代入の回数等を計測し、これらが悪化すると読みづらいプログラムになってくる、というものです。

メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013) ではプロダクトの分野として6つのメトリクスが定義されています。

ソフトウェアメトリクスのうち主なメトリクスに関する表

Ruby を書く方であれば Rubocop の MetricsCop に指摘をもらったことのある方もいらっしゃるのではないでしょうか。まさに当該 Cop の内容が内部品質に関するメトリクスで、2024年12月22日現在10個の内部品質に関するメトリクスの Cop が定義されています。 詳しく知りたい方は以下の公式ドキュメントをお読みください。

docs.rubocop.org

CodeKeeper について

上述のように、Rubocop では内部品質に関するメトリクスについて違反を指摘してくれます。しかし必ずしも推奨の閾値を守れるとは限らず、閾値を緩めるもしくは指摘を無視するという対応をしてしまう現場もあるのでないでしょうか。一方で、改善活動の結果、コードの品質が向上するケースも存在します。このような日々のアクションの結果を継続的に取得し、観察できるようにしておくことは意義があると考え、CodeKeeper という Gem を開発しました。

github.com

使い方

メトリクス・出力形式

対応している内部品質に関するメトリクスは

• 循環的複雑度（ファイル）
• ABC ソフトウェアメトリクス（ファイル）
• クラスの行数

です。

前者2つは、実装の簡便さを鑑みファイル単位とし、出力については取得したメトリクスを S3 や BigQuery などに取り込み解析できるように、csv もしくは json にて標準出力に吐き出す形としました。

設定

以下のような設定で、

• 取得するメトリクス
• 実行スレッド数
• 出力フォーマット

を選択できます。

CodeKeeper.configure do |config|
  # If you choose metrics, specify as follows:
  config.metrics = %i(cyclomatic_complexity abc_metric class_length)
  # The number of threads. The default is 2. Executed sequentially if you set 1.
  config.number_of_threads = 4
  # The default is json
  config.format = :csv
end

以下は例として Gitlab の適当なファイルに実行した結果です。

$ bundle exec code_keeper app/models/user.rb app/models/ability.rb > metrics.json
$  cat metrics.json                                                                                             
{"cyclomatic_complexity":{"app/models/ability.rb":10,"app/models/user.rb":28},"class_length":{"Ability":100,"User":2033},"abc_metric":{"app/models/ability.rb":95.5092,"app/models/user.rb":2047.3842}}

用途

どのケースも S3 や BigQuery などのデータストアに内部品質に関するメトリクスの数値を貯め、活用することを想定しています。

• リファクタリング・技術負債の返済・カイゼン活動の結果として眺める

  現状を改善していく何らかの活動の結果としての指標の一つとして、活用します。

• Four Keys などの生産性指標と同時に観察する

  現在開発生産性の指標の一つとして Four Keys があります。

  • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
  • 変更のリードタイム - commit から本番環境稼働までの所要時間
  • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
  • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

  引用: エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ という4つの指標を測り、チームの開発のパフォーマンスを測定するというものです。 （詳しく知りたい方や興味のある方は「LeanとDevOpsの科学」や「State of DevOps Report」などをお読みください。） cloud.google.com book.impress.co.jp

  Four Keys と内部品質に関するメトリクスを観察することにより、生産性と内部品質に相関がある場合に改善活動を始めるという手段が取れます。

• 閾値を定めアラートをあげる（ Slack などに通知する）

  上述の通り Rubocop の指摘を必ずしも守り続けられるとは限りません。その場合、徐々に当該メトリクスの品質が悪化し続けることが想定できるので、暫定で新たな閾値を設け Slack にアラートを通知する等の手法をとり、Rubocop の指摘以外の強制力を働かせます。

今後について

まず、メトリクスについて増やしていきたいと考えています。Groovy でメトリクスを取得するライブラリの GMetrics を目指していきたいです。

dx42.github.io

Ruby の表現力を網羅できるよう仕上げるのは利用者の FB がないとかなり難しいので、Rubocop の private API を積極的に利用するのはありな気がしています。自身で実装するのは楽しいので、とても迷うのですが...。

また、上記の用途で上げたように基本データストアに保存したいはずなので、S3 などにアップロードする機能は早めにサポートしたいなとおもっています。

これは Gem でサポートする話ではないですが、解析してグラフを表示するような Web サービスを作りたい気持ちでいます。

最後に

CodeKeeper は、自身が携わっていたプロダクトでのソフトウェアマネジメントに活用しようと思い作ったものです。しかしより優先順位の高い事項が多く活用ができないまま、私自身が独立しフリーランスになってしまいました。趣味プロジェクト等で使おうとは思っていますが、より本格的に活用した事例など聞けるととても嬉しいです。荒削りですが、FB や要望等お待ちしています。