年末年始の自由研究として（？）、MFGStudioのオープンソース化の作業をしていた。

MFGのオープンソース化自体は元々すると言ってある事なので、仕事として普通にやる事も出来る作業なのだが、 年末年始なので、あまり進捗とかを考えずに前から直したかったコードの修正などもしていきながらやっていこうと思った。

オープンソース化のためには社内のライブラリを切り離して、似たような機能を持つ簡易版を作って差し替えるような事を考えていた。 ただ実際にどこをどうすればいいのかを全てちゃんと把握している訳では無いので、 実際に作業をしつつ調べていく必要がある。

年末年始の自由研究くらいの気持ちで取り組んでいるので、最後までやり切る、とかいう意志には欠ける。 そういう訳で途中で作業をやめても、そこまでの価値があるようなやり方で、 いつでも辞められるようにインクリメンタルに進めたい、と思った。

そこで、まずは今のコードのリファクタリングを進めて、社内ライブラリとの依存を局所化する作業から始める事にした。 これなら途中でやめても、そこまでで意味のある作業なので、冬休みの自由研究には良いだろう。 こういう他のタスクが無い時に時間をかけてコード整理をしていくのは冬休みっぽくていいんじゃないか。

年末年始は他の人が休みをとるため、他人がトリガーになる自分の作業というものが発生しないので、 何かを割り込みなく時間をかけて取り組むのに良い。 だからある程度まとまった期間をかけてやりたい事をやるのに良い。 ファイルの移動とかを伴うリファクタリングとかに向いている。

という事でこの作業を年末年始にやっていった所、当初思っていたよりも自分の把握していなかった所の作り直しの作業量が多く、 これでは簡易お絵描きアプリをもう一度作り直すのに近い大変さになってしまうでは無いか、 と気づいた。 まぁこの手のオープンソース化の作業ではありがちだ。

という事で方針を変えて、「こういう感じでやっていけば良さそう」という新たな方針を考える所まで行った所で、 周りも仕事はじめをしてほかの人待ちだった作業が進められるようになってきて、 冬休みの自由研究は時間切れかなぁ、となった。

結果としては、一週間くらいかけてコードを整理しただけで、なんの進捗も無い、という結果になった。なんの成果もあげられませんでした！という奴だ。

これは普段だったら失敗という事になるだろう。一週間程度なら「大きな失敗」という程では無いけれど、 ちょっとしたミスよりは大きい。 年末年始の自由研究ならまぁいいか、と思えるが、普段ならあちゃー、とは思っただろう。

コードの整理に結構な時間が掛かって当初やろうとした事が全然進まないというのは、いかにも下手な作業の進め方に思う。 特にやろうとしている事の作業量全体と比較しても結構な割合なくらいコード整理をして進捗が無い、 というのは、多分やり方に問題がある。 今回のコード整理も、実際に必要な程度よりもだいぶ大きなものになった。 これは後から振り返ったから分かる事なので、やっている時に不要だとは思っていなかったし、 結果論で失敗と言われるのも納得いかない部分もあるけれど。

一方で、仕事としての進捗を考えなければ、こういった作業は楽しさもある。 変更後のコードの方が明らかに「正しい」。 「なんかこの辺イマイチだな〜」と思う所が全てあるべき姿に変わって「そうそう、こういう感じであるべきだよな」というものになっていく。 やっつけなコードを全部突っ込んでおく場所になってしまっているファイルから、ちゃんとあるべき所にあるべきものを移動して、 見ると嫌な気分になっていたファイルを何度も見直して「よしよし」と思っていい気分になる。 自分が1から書いたものが言い訳したくなるものから自慢したくなるものへと変わる。 自分が書いた訳ではないが変更したものも、当初の意図をより深く理解した上でさらにそれを超えた正しいコードに出来て、 うんうん、さすがだな、俺、という気分になる。

進捗はなかったが、年末年始の自由研究なのでまぁこれでいいだろう、とか自己弁護していた所、 omo先生がこんなブログをポストしていた。

Outcome and Process - 2026-01-06 / Spinach Forest

このブログで以下のように言っている所がある。「上司の視線が冷たい」

実際に、上司の判断は適切な事が多い。 こうした作業は必要な範囲を超えてやられる事も多く、 実際自分の今回のやつは明らかに必要な範囲を超えていた。 その時間はまぁ浪費と言っても良い。 オーバーエンジニアリングみたいなものでは無いのでマイナスでは無いと思うが、 リファクタリングによくある、リファクタリングの収穫逓減で最後の方は改善しているかしていないのか微妙な感じになって終わる、 というくらいまで進めていた。 最後の数個は無駄といえば無駄だ。

また、コードの変更はトレードオフがある場合がある。構造Aから構造Bに変える時に、 全てがBのほうが優れている訳では無い。 その時はBの方がいいと思っていても、その後に何かあって実はAの方が良かった、という事も良くある話だ。 だから必要に導かれて構造を変えていく方が、 地に足ついた良いコードになることも多い。 そういう点でもやりたい事があって、それに向けてリファクタリングをしていく方が、 リファクタリングとしても意義のある良いものになりやすいと思う。

また、チームとしてやらなくてはいけない事がある中でメンバーの一人がそれを一人分になわずに時間を浪費していると、 他のメンバーとしては迷惑でもある。 コードの良し悪しは主観による所が大きいため、本人ほど他人はそのリファクタリングに価値を感じない場合も多い。 その場合は特にそうだろう。 自分の目から見て良くなっているのか微妙な変更ばかりに時間を使われると、良い気はしない。

先ほどのブログでも「本当にリファクタリングしかしない人」が良くないとして挙げられているし、 作業の進め方が下手な結果、延々とリファクタリングしている、という状態になる事もある。 こういう時に作業の進め方の方を正しいものにするために意識や労力を集中させるためには、 こうした「進まない」に対して敏感になって避けようとする姿勢が大切なのは間違いない。

一方で、これらが良くないのは進捗を気にするからであって、 進捗さえ気にしなければそんなに悪い事は無い。 やっている人は楽しみを得ていて、 酒とかギャンブルとかのようなデメリットがある訳でも無い。 どちらかといえば、正の外部性がある。あんまり無いかもしれないけれど、符号は正だろう。 ヘッドカウントを消費されているから上司やチームメンバから困った事だと思われるのであって、 ヘッドカウントを消費していないなら、 周りの印象も好意的か、そうでなくてもせいぜい無関心程度だろう。

自分の今回の作業を考えると、いっつもこういうことばっかやってたらダメだと思うが、 1年に一回だけというのはむしろ少ない気もする。 年に3回くらいはこういう1週間を過ごした方がいいかもしれない。