こんちはー、リファクタリング大好きな ミノ駆動 です。 書籍『良いコード／悪いコードで学ぶ設計入門』 の著者です。 READYFORでアプリケーションアーキテクトとして務めています。
この記事は、8/20(土)に開催された オープンセミナー岡山2022 の登壇レポートと、そこで発表した 設計とチームビルディングの関係 について、弊社での活動を解説するものです。
登壇発表の概要
この登壇では、 私が昔勤めていた会社での失敗経験と反省 が、現職READYFORでの設計業務に活かされている旨を発表しました。
発表にあるように、チームの合意やリソース戦略が不十分なまま大規模な設計変更を無理に進めると、反発や軋轢が生まれます。 そして組織全体での設計改善が困難になります。
そうした失敗経験を反省し、その後様々な技術書での学びから、課題と解決への道筋を認識できるようになりました。 私の昔の会社で失敗原因は、 チームビルディングをないがしろにしたまま設計を推し進めたこと だったのです。
アーキテクトの仕事は単に設計だけではなく、チームビルディングも必要であることに気付きました。 そしてこの失敗経験と気付きを、現職READYFORの設計業務に活かせるようになったのです。
嬉しいご感想
この発表をしたところ、次のようなご感想をいただきました。
失敗談：「全部リファクタリングするんだ」
— 聖(ひじり)＠オレでなきゃ見逃しちゃうね◆ (@hijili2) 2022年8月20日
- ガチガチの設計ガイドラインを策定
- 「全部この通りに設計し直せ」
- トレードオフを考えずに
分かる。。。やりたいけど、実際無理なんですよねえ。。。#oso2022
「なにか上手く行かないときは、課題や解決方法が認識できていないことが多い。今ある知識だけでなんとかしようとすると上手くいかない」
— 近藤佑子 (@kondoyuko) 2022年8月20日
ミノ駆動さんはそう感じて学び直しを始めたそう
…今の自分の課題でもあって刺さった#oso2022
ミノ駆動さんの話、失敗から学ぶ知識獲得の正しい歩き方って感じで最高だった。 #oso2022
— そーだい@初代ALF (@soudai1025) 2022年8月20日
自分の失敗経験を赤裸々に語るのはちょっと恥ずかしかったですが、 不幸を再生産しないためには失敗の共有も必要 、そうした手応えが得られた発表でした。
弊社READYFORでどう活かしたか
「READYFORの巨大Railsレガシーシステムの技術的負債をなんとか解消してほしい」との依頼のもと、昨年4月に私はREADYFORに入社しました。
（入社のイキサツはこちら） tech.readyfor.jp
巨大な技術的負債の解消は、私一人でなんとかなるような規模ではありません。 負債の解消（つまりリファクタリング）も然ることながら、組織全体で負債を作り込まない体制へ移行する必要があります。 つまり組織全体の協力が必要となります。
私は入社してすぐにリファクタリングの実装に取り掛かったわけではありません。 次に挙げる、設計を推進するためのチームビルディングを私は実施しました。
- エンジニアへのヒアリング
- ロジック変更の際、どの辺が辛いかなど
- 設計改善の認識共有するための各種資料作り
- 設計説明会
- 説明をベースに、意見共有や相談の場としました。
- 設計勉強会
- 書籍『現場で役立つシステム設計の原則』 を用いた、ハンズオン形式の勉強会です。
これらの活動の実施には、概ね2ヶ月ほど要したと記憶しています。 認識共有のためのチームビルディングにはコストがかかり、なかなか骨が折れます。 しかし、このチームビルディングを序盤でしっかりやってきたからこそ、設計改善が進んでおります。
活動の成果
弊社サービスの技術的負債は、 Code Climate Quality で継続的に計測しています。 青の縦棒が技術的負債の絶対量で、緑の実線が相対量です。
設計が不十分なままコードが増加し続けると、ロジックは指数関数的に複雑化し、技術的負債は増大していきます。 しかし弊社サービスの技術的負債の量は、このグラフに示すように、低減または現状維持の傾向を継続しています。実際の成果となって現れています。
また、大規模なリファクタリングとしては、次に示す事例を最近実施しました。
チームビルディングを下支えする組織ビジョン「乳化」
そしてこのチームビルディングには、 弊社READYFORが掲げる組織ビジョン「乳化」が下支えになっていると考えます。
上記記事に詳しい記述がありますが、 乳化とは「組織の中にエンジニアリングが自然に溶け込んでいる状態」を指します。 イノベーションやパフォーマンスを促進するために互いが混じり合うことを主眼とする考えです。
セクショナリズムに陥っては、包括的課題の解決は困難です。 チームを巻き込むことが当たり前の文化があるからこそ、チームビルディングが容易になり、システム全体に影響するアーキテクチャの改善や、組織的な技術的負債解消の取り組みに繋がると考えます。
最後に
コミュニケーションに問題があると、同じ開発チームのメンバー同士が同じコード（つまり重複コード）を書いてしまったり、お互いの実装が噛み合わなかったり、問題のあるコードやバグが増える傾向にあるそうです。 コロナ禍においてはオンライン業務が当たり前の流れになる一方で、Slackやビデオチャットでのやり取りはハイコンテクストを要するケースもあり、どう意思疎通するかにおいて難儀する局面があります。
だからこそ、チームをより活性化し、プロダクトの質を高めるコミュニケーションのあり方を設計したいものです。
