この記事は Timee Product Advent Calendar 2024 の15日目の記事です。

タイミーでエンジニアをしている甲斐です。

会社の看板の力というものはよいもので、私が転職して以降特に自分がすごくなったわけでもないのに弊社の力で外にアウトプットを出す機会をいただき、そのたびになんとかネタを捻り出していくつか登壇をこなしたりしました。

そしてさらなる機会としてアドベントカレンダーに声がかかり、社内からも「以前登壇したオブジェクト指向設計の話の続き書いてよ」と言ってくれる人がいたのですが、「最近自分技術的に大したことしてなくて書く事がねぇ〜」と頭を抱えるばかりの日々。ここで私は閃いた。
じゃあそれをネタにしよう。

というわけでジャンプが合併号に時々お出しする作者4コマではもはやお約束の領域になる「ネタがないネタ」で今回はお送りします。

今回一番言いたいこと

何を言うか。下策をもって上首尾に至ったなら、上策から始めるよりも数段勝る偉業ではないか。

〜Fate/Zero 征服王イスカンダル〜

もはや到底持たざるものには見えなくなったロード・エルメロイⅡ世の若かりし頃、ウェイバーに発破をかけた超有名なセリフですね。

生存バイアスと似たような形で、対外的なアウトプットって必然的にキラキラバイアスがあると思います。
当たり前の話で、会社組織なのですから大してオチもつかないような成功とも失敗ともつかないような話よりも輝かしい成功をお出ししたいものです。
そしてそのようなエピソードは耳目を集めるが故に羨望の眼差しで見つめられる宿命にあります。

しかし、世の中を支える仕事と言うのは輝かしく自慢できるようなものばかりではなく、めちゃくちゃ大事なのにすごく地味でアウトプット映えしなかったり、様々な事情でまだ世に出せなかったり、私のチームではMVPで価値を届けることが多く、1週のスプリントで実装する社内の人が扱うものともなれば必然的に設計も実装もシンプルになります。

結果、今のプロジェクトに一番必要なのはBooleanの判定クラスと多少のアソシエーションといくらかの文字列カラムがついたようなごくごく簡素なクラスでした、なんてことは日常茶飯事です。

小さく出すか最初に練るか

せっかくなので字数稼ぎに組織の話をして弊社の立ち位置について目線合わせをします。
例えばなんらかの機能を開発する際に、最初はシンプルに作ってから後から改善するか、時間をかけてみっちりと設計するか、2つの軸があります。

弊社の、特に私が所属するチームは前者に大きく傾いているのですが、これは1週間単位のスクラムを実施している点もそうですが、チームトポロジーで言うところのストリームアラインドチームであるために、自分たちの関心領域に関しては自分たちが一番の専門家であり、他チームの顔色を伺う必要がない、という組織的な構造があるため、ありふれた言葉でいうと縦割りが進んでいます。そのため、一度出したクラスの設計を変えることに関してもあまり影響がなく行うことができるのですが、私は転職の多い人間なので、そのような事情を適用できない組織についても経験があります。

例えば、社内が数人規模の開発チームで、一度開発した機能がそのまま独り歩きしてあれこれ使われてしまうような事情がある場合には、動き出してからの設計変更が難しくなります。そういう場合は最速のMVPに拘らず、一旦腰を据えて周りを巻き込んで設計を握っておいたほうがよいケースもありました。

未熟な作りは自分に跳ね返ってくる

そうはいっても、設計は二の次でいいや、と考えていると障害を起こしたり、つらいつらい運用オペレーションを担わされたりして報いを受けることになります。この重荷から逃れるために自分のやることに責任を持つ、というのがエンジニア自身がオーナーシップを持つということなのではないかと思います。

昔の百姓が重い年貢にブチ切れて一揆を起こしたように、「こんな運用作業やってられるか！」というつらみこそが設計や運用がどうあるべきかに思いを馳せる最大の動機づけとなります。ちなみにこの原稿は現在進行系でつらい運用作業の影響で執筆が遅延しています。

YAGNIに従うことで作りをシンプルに動きを身軽にしているわけなので、逆に言うと「いらないと思っていたものが必要になったらすぐに見直す」というアジリティが求められます。予想していなかった気付きに適応しながらも、予定にはしっかり間に合わせるということができるか、という修正の動きがどれだけできるかにアジャイルチームの完成度が問われている気がします。

なんだかアジャイルソフトウェアの開発論みたいになってきました。
つまり、私にとって直近の業務はアジャイルチームの一員としてプロジェクトに大してどれだけバリューを出せるかに注力してきたんだなと書いててわかってきました。

「自己組織化」なんて大仰で私にはまったく相応しくありませんが、「破綻した計画や運用につきあわされるのはまっぴらごめんだ」という最悪のケースに備えてプロジェクトに必要だと思ったことをやってるだけの行動をもしかしたらそう呼べるのかもしれませんね。