人が入れ替わるサイクルがソフトウェアの寿命よりずっと短いというバグ

はじめに

リファクタリングという営みは、10年くらい前と比べてずいぶん取り組みやすくなったように思う。

技術的側面ではテストフレームワークやCI・CDの普及が、
ビジネス的側面ではスマホへの移行・短期間でアップデートされるOSへの対応の必要性が、
それぞれ「作り直し」へのハードルを下げ必要性を高めたように思う。

2020年に出版された「Engineers in VOYAGE」は象徴的な本で、ここでは大々的にシステムを作り直す過程が生々しく描かれている。VOYAGE GROUPが非常にオープンな会社だ、というのはもちろんあるが、「リファクタリングしたよ！」ということを大々的に発信できるような時代になったのだ。

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

単体テストを導入しようと提案して「そんなにやりたいならやれば?」と上司に突っぱねられたあの日。「あまりにも複雑度が高いのでリファクタリングしたほうがいいですよ」と進言したら「リファクタリングしたいならしていいよ」と突然アサインされたあの日。それでいて「成果がわかりにくい」と言われたあの日。

「どうしてわかってくれないんだ！」

大音量の紅でモヤモヤを飲み込んでいたそんな日々を思うと、夢のような時代だ。けれども、そんな時代であっても、やはりリファクタリングが難しいものであることに変わりはない。

インビジブル負債

ソフトウェアの健全性を測るためには、いくつか定量的な指標が存在している。テストカバレッジ、サイクロマティック複雑度ーー。たとえばカバレッジ10%、最大複雑度80というモジュールは「ヤバい」と即座に判断できる。

しかし、カバレッジが高く複雑度は低い、という状態なのになぜか扱い辛いコードというものが存在する。コードや設計の意図が汲み取りづらいコードだ。そして、この「意図の汲み取りづらさ」はリファクタリングの妨げにもなる。意図が汲み取れないので、目の前に存在するオーパーツを抹消してよいか判断できないのだ。そしてそれが積み重なっていくと、いつしか複雑度は増してゆく。

書いた人？いません。

意図がわからないコードとの向き合い方。正攻法としては「意図を知っている人に聞く」だろう。だが、得てして「意図がわからないコード」を書いた人は既に組織にいなかったりする。

IT業界は他の業界と比べて人の入れ替わりが激しいと言われている。肌感覚としてはそのペースは年々速まっている。それに対して、ソフトウェアの寿命は伸びている。これは業界が成熟していっているという観点では望ましいことだが、「人が入れ替わるサイクルがソフトウェアの寿命よりずっと短いというバグ」を抱え込むことでもある。

あなたの組織に語り部はいるか

以前、「コア技術の段階的発展とチームの代謝」という資料を作成した。（本来はエンジニアコミュニティDevLOVEで話す予定だったが、コロナが急拡大しているタイミングでお流れになってしまったものなのでご覧になったことがある方はほとんどいないと思う）

この資料で触れているように、私は動きが激しいIT業界において、例外的に長い期間同じ組織にいる。それも、ほぼ同じ部門に。
そのため「なんでここはこんなコードになってるんだ」「これはなんのためにある？」のような疑問に対して、ある程度コンテクストを含めて解説することができる。

この「語り部」という役割は地味に重要で、「なんだかよくわからないけれども普通に考えたらこういう書き方にはならないから、きっと大事なものなのだろう」と改修を諦めるメンバーに対して「ああ、それはC言語からC++に書き換えるとき突貫でやった部分だからC++の皮を被ったC言語だよ。」と経緯を伝え、改修への背中を押したりしている。

語り部がいなくてもいい組織を作ろう

この語り部という仕事は、折々の意思決定や試行錯誤が明文化されていない組織では重要なものになる。そして重要なので、語り部となる側としては悪い気がしない。

でもこれって、健全なのだろうか。

「過去の経緯」という名のドメイン知識を専有してしまっている、つまりバキバキに属人化しているのだ。これは以下の観点から好ましくない。

・経緯を知っている人に聞かないと物事が進まないのでスピードが出ない
・記憶ベースなので語り部の証言が正確とは限らない
・語り部は「語り部」をしているだけで仕事が成り立ってしまいスキルが伸びない

個人的には、3つ目がまずいなと思っている。だって仕事として成り立っちゃうし、周りに感謝されるとそれなりに気持ちいいので、そこから抜け出そうという気持ちが起きづらくなる。長期的には自分のキャリアを狭めているというのに。

なので、基本的には語り部がいなくてもまわる組織をつくることが好ましい。構造化されたドキュメントがあればベストだが、コミットログに記録されていたりGoogleDocsに書き散らしているだけでもないよりマシだ。（GoogleDocsの検索性能に何度助けられたことか）

語り部は自分がいらなくなるよう組織を舵取りしよう

語り部になってしまった/なりえてしまう人はどうするか。これは、自分で自分の居場所をなくすように働きかけてゆくのがよいと考えている。
自分しか知らないことを周囲に伝える、ドキュメントとして整備する、もっというと自分の知識をベースに今いるメンバーたちに「作り直し」をしてもらうのだ。

リファクタリングを妨げる「汲み取れない意図」。裏を返せば、意図を知っているあなたならばその障壁を取り除ける。知識のサイロを抱えて暮らすより、知識を広めてよりよい方向へ導くほうがずっと建設的だ。

過去、何人か自分のサイロを手放したくないベテランを見てきた。そうするとモジュールは淀み、生産性が低下し、価値が色あせてゆく。誰かが一念発起し新規に作り直しをしようものなら、「貴重な知識を持ったベテラン」は「古いモジュールにやたらと詳しい人」になっていく。自分自身の価値は低下するし、知識が抱え込まれていた期間の停滞は組織にとっての損失だ。Lose-Loseの関係となってしまう。

だから、語り部たるベテラン諸氏。どこかのタイミングで一時的に語り部になるのはよいだろう。だが、中長期的には「語り部」がいらなくなる組織づくりへと、自らの力点を移していってほしい。

さいごに

結局のところ、リファクタリングの本質はこれだ。

「みたことのない回路がいっぱいつまってる。」
「みたことのある回路になおしゃいいんだよ！」
ー「大長編ドラえもん　のび太と鉄人兵団」より

みたことのない回路をみたことのある回路に作り変えられるドラえもん、さすがは22世紀からきた猫型ロボットだ。しかし僕らはドラえもんではない。見たことがないものを見たことがあるものに作り変えるのは至難の業だ。

人が入れ替わるサイクルがソフトウェアの寿命よりずっと短い時代。仕様は明文化しよう。その仕様に至ったコンテクストも残して置こう。それが将来、誰かの意思決定を助ける。それができなくてもあきらめない、語り部を探そう。自分が当事者なら、語り部になろう。そしてじっくりと語り部がいらない組織を作っていこう。

自戒を込めて。