こんにちは、リファクタリング大好きなミノ駆動です。
2021年4月にREADYFOR株式会社にジョインしました。
概要
本記事は、なぜ私がREADYFORへのジョインを決断したのか、背景理由を記したエントリ記事です。
READYFORはサービス開始から約10年が経過。システムに相当な技術的負債が蓄積しているため、今後スピーディーにサービス拡大するためには負債解消が目下取り組むべき重要課題となっております。その課題解決のために私は誘われたわけですが、リファクタリングが十分に効果を発揮するには、設計技術面以外の様々なハードルを乗り越えなければなりません。
READYFORの組織ビジョン「乳化」が、ハードルを解消し、リファクタリング効果の大きな促進に貢献すると考えたため、ジョインを決断しました。
本記事では、技術的負債やリファクタリングにまつわる一般的な問題構造を解説した上で、READYFORが掲げる「乳化」という概念がそれらの解決にどう寄与できると考えて私がREADYFORへのジョインに至ったか、を記していきます。
開発コスト増大を招く技術的負債
技術的負債とは、ロジックの複雑化によりメンテナンスや変更が困難な状況やシステムを指します。また、技術的負債となっているコードをレガシーコードと呼びます。ソフトウェア品質特性の観点では、保守性や変更容易性が低いものを指します。
変更容易性の低いコードは、以下に挙げる要因により開発コストを著しく増大させます。
- 可読性が悪く、読み解くのに時間がかかる
- 仕様変更に関係のあるロジックを探すのに時間がかかる
- 変更時にバグになりやすい（ロジック理解不十分なため）
- 副次的効果として、なんとか動作させるために付け焼き刃的なコードが追加されやすく、さらに複雑化する
開発コストが増大すると、サービスが折角収益を上げても利益が薄くなってしまいます。それだけでなく、開発スピードが低下してしまうため、新しい機能をリリースしづらくなり、陳腐化して顧客が離れてしまう可能性もあります。
開発コスト低減に貢献するリファクタリング
この技術的負債の解消に有効なのがリファクタリングです。リファクタリングとは、外から見た挙動を変えず、内部構造を整理することです。リファクタリングにより変更容易性が向上し、将来の開発コストを低下する効果が期待できます。
私自身、レガシーコードに幾度も苦しめられてきた経験があります。レガシーコードと戦うために、設計の道を志しました。そしてどうすれば良き設計に改善できるか様々な技術を吸収してきました。今となっては、リファクタリングによるロジック整理は、私にとってはパズルを解くような感覚であり、楽しさを覚えるものとなっています。
利益を上げるためのリファクタリング戦略
しかし一方で個人の嗜好とビジネスは分けて考えなければなりません。趣味のリファクタリングとは違い、ビジネスは利益を上げなければなりません。闇雲にやるのではなく、利益が上がるようにリファクタリングの効果を最大化する戦略が必要になってきます。
リファクタリングのリソースは有限
リファクタリングは無限にはできません。なぜなら開発リソースは有限だからです。ソースコードの大半がレガシーコードであっても、ターゲットを一部分に絞らなければならない現実があります。ではどこをリファクタリングのターゲットにすれば良いのでしょうか。
変更されない箇所をリファクタしてもムダ
例えばあるレガシーコードがあるとします。そのコードはずっと安定的に動いており、仕様変更がほぼ全く発生しません。このようなコードを一生懸命リファクタして効果があるものでしょうか？
リファクタリングの効果は、変更容易性を向上させ、将来の開発コストを低下させます。将来仕様変更がほぼ発生しないようなコードをリファクタしても、開発コスト低下効果をほとんど期待できず、リファクタしただけリソースが無駄になってしまいます。
コミット頻度が高い箇所？
これとは逆に、頻繁に変更される箇所ほど、リファクタリングによる開発コスト低下効果が得られることになります。
CodeClimateなどの一部のリポジトリ解析ツールには、ファイルごとのコミット頻度を分析できるものがあります。
コミット頻度が高いものを優先的にリファクタすれば良いと考えられますが、ここに罠があります。コミット頻度が高いファイルはあくまで過去の頻度です。昔の頻度は高くとも、現在安定していてほとんど変更されないものがあったりします。
では直近でコミット頻度が高いものはどうかというと、一時的な施策や流行りでたまたまコミット頻度が高いだけのものがあったりします。この手の高頻度変更は短期的であることが多く、その後も長期的に頻繁に変更される保証はありません。
リファクタリングのターゲット条件
つまり、リファクタリングのターゲットは、今後将来にわたって長期的に、かつ頻繁に変更される箇所です。
しかし未来へ行けるタイムマシンはありませんから、該当箇所を予測しなければなりません。加えて、ITビジネスは常に流動的で、不確実性の高いものです。不確実性が高い中でリファクタリング有効性の仮説を立てていかなければならないという、大きな戦略的課題があります。
あるべき設計構造
また、リファクタリングはただロジックをイジれば良いというわけではありません。何の目標もなくいじり回すと、さらに複雑化して扱いにくいロジックになってしまう懸念があります。
変更容易性の高い、あるべき設計構造をリファクタリング目標としてまず打ち立てる必要があります。
例えばレガシーシステムでは、数千、数万行単位の巨大クラスが大抵鎮座しています。そうした巨大クラスに対しては、ロジック整理するだけのリファクタリングでは焼け石に水です。
クラス粒度が不適切であるため、適切な粒度に分割する必要があります。ではどの粒度で分割すれば良いか？分割の境界線をどこに引けばいいか？分割後のクラスにどう命名するのか？その責務は？などなど...変更容易性が最大化するようにこれらの最適解を見出し、あるべき設計構造すなわちリファクタリング目標として定める必要があります。
しかし、それは一体何を基準にすれば良いのでしょうか。
リファクタリングにはビジネス理解が必須
これら2つの大きな課題を解く鍵は、結論から申し上げますと、サービスが対象とするビジネスを理解することです。
ターゲット絞り込みに貢献する中長期事業計画
何をビジネスの中心軸として、サービスを今後どう成長させていくかを定義した中長期事業計画があれば、どこをリファクタリングのターゲットにすれば良いかが決まります。
事業計画とは将来像ですから、「将来長期的に、かつ高頻度な変更が発生する」というターゲット条件に一致する箇所を絞り込みやすくなります。
あるべき設計構造を決めるビジネス概念
あるべき設計構造にしてもそうです。
ECサイトを例にすると、サービスに登場する概念は単純な「商品」などではなく、「おすすめ商品」「シーズン割引」「キャンペーン対象品」「優待会員限定価格」など、多くの概念が登場します。
これはまだ分かりやすい例であって、実際のビジネスではもっともっと複雑な概念を数多く取り扱います。ビジネスを理解し、登場概念や背景の意図を詳細に把握することで、モデリングの正確性が向上し、リファクタリングのゴールとなる、あるべき構造を設計できるようになります。
情報システムとはビジネス課題を高効率で解決する仕組みなので、そもそもの話としてシステム設計にはビジネス理解が必須なのです。
互いの理解を阻む組織構造
じゃあさっさとビジネスを理解すればいいのでは？となればいいのですが、ここでもまた大きな課題が立ちはだかります。
ビジネスから最も遠いエンジニア部門
広木大地氏著「エンジニアリング組織論への招待」に詳しい記述がありますが、エンジニア部門は、組織力学上ビジネスから最も遠い位置付けになりがちです。
エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- 作者:広木 大地
- 発売日: 2018/02/22
- メディア: Kindle版
経営層が市場動向を判断し、それに基づきビジネス部門が戦略や企画を策定し、最後にエンジニア部門が要件定義してシステムへ落とし込む、というコミュニケーション構造になるからです。
この構造はもはや伝言ゲームです。情報劣化が起こるために、鮮度や正確性の高いビジネス情報がエンジニア部門に届きにくくなってしまいます。これでは良い設計へ落とし込めません。
認知困難な技術的負債
さらに深刻なのが、エンジニア部門が抱える技術課題が経営層に伝わりにくい、理解されない、という問題です。
技術的負債は、あるべき設計構造とのギャップです。従って、あるべき設計構造がどんな構造であるかを知らないと、負債を認知することすらできないのです。いくらシステムの内部構造を知っていても、設計知識が希薄なエンジニアにとっては負債を認知できません。まして、非エンジニアリングの経営層やビジネス部門はさらに認知困難です。
こうした無理解が原因で、リファクタリングしようにもリファクタリングするための開発リソースを割いてもらえず、設計品質が悪化の一途を辿るという事象に、多くのシステム開発企業が苦しめられているのではないでしょうか。
リファクタリングを阻む課題
ここまでの話を一旦整理します。
- リファクタリング効果の最大化にはビジネス理解が必須である。
- 伝言ゲーム的な組織構造は、エンジニア部門のビジネス理解を困難にさせる。
- 非エンジニア部門にとって技術的負債の理解が困難なために、リファクタリングを推進できない懸念がある。
特に後半の2つは、コミュニケーション構造の課題です。
私自身、リファクタリングに長年携わってきましたが、リファクタリングしようにも関係者との目線がなかなか揃わず、お互いに期待が合意されず、技術だけではどうにもならないもどかしさに苦しんできました。
DXを促進する組織ビジョン「乳化」
このコミュニケーション構造の課題を解決するのが、READYFORが掲げる組織ビジョン「乳化」です。
この記事に詳しい記述がありますが、乳化とは「組織の中にエンジニアリングが自然に溶け込んでいる状態」を指します。「エンジニアリング 対 非エンジニアリング」という対立概念として考えるのではなく、イノベーションやパフォーマンスを促進するために互いが混じり合うことを主眼とする考えです。
エンジニアリングとビジネスを近接させる組織体制「Squad」
乳化を体現したもののひとつに、Squadという組織体制があります。
Squadとは、あるミッションの達成を目標に、職能横断で編成された組織体制です。これによりエンジニアリングと非エンジニアリングがコミュニケーション的に近接した状態を維持でき、エンジニアにビジネス情報が伝達しない、技術課題が非エンジニアリングに理解されないといった問題の解消を期待できます。
あるべき設計構造の長期的模索に有効な設計方法のひとつに、ドメイン駆動設計(DDD)があります。
- 作者:Eric Evans
- 発売日: 2013/11/20
- メディア: Kindle版
DDDはビジネス概念を表現し解決する、ドメインモデルを中心とした設計手法です。
ドメインエキスパートと呼ばれる、ビジネス課題に熟知したメンバーとともにドメインモデルを設計し、目線を合わせていくことが大事、という教えがDDDにはあります。SquadはこのDDDの教えとも合致するわけです。
私はVPoEのいとひろさんからTwitter上でお誘いを受けました。お誘いの話の中で、この乳化のコンセプトによって自分のリファクタリングのパフォーマンスをより発揮できると考え、READYFORにジョインする決断に至ったのです。
リファクタリングのさらに先へ…「深いモデル」の探求
話はリファクタリングだけにとどまりません。リファクタリングのさらに先にある「深いモデル」の探求に、乳化のコンセプトが役立つと考えたからです。
「深いモデル」とはドメイン駆動設計に登場する概念で、ビジネスの本質的かつ核心的問題に貢献するドメインモデルであり、サービスの競争優位性向上に深く関係します。
「深いモデル」の例
代表例としては、Twitterのリツイートが深いモデルに相当するのでは、というのが私の解釈です。
リツイートはご存知の通り、リツイートしたツイートをフォロワーのタイムラインに表示する機能です。リツイート数はどれだけ話題性があるかを表すバロメータであり、良くも悪くも話題性の高いツイートが爆発的に拡散する仕組みになっています。
リツイートの仕様変更があるとユーザー同士で侃々諤々の議論が巻き起こるほど注目度が高く、Twitterの価値、魅力を大きく支えるものとなっています。
「深いモデル」を見出すには
深いモデルは、リファクタリングとビジネスの本質的探求の繰り返しにより見出されるものとされています。私はまだ深いモデルを見出したことがないので、是非発見してみたいというエンジニアとしての矜持があります。
未知の領域に眠る「深いモデル」
ところでREADYFORはクラウドファンディングのサービスです。弊社米良の記事にあるように、資本主義では解決困難なセグメントにお金を流し、解決へ導く寄付市場の形成、拡大が弊社の目指すところです。
資本主義で解決可能なセグメントは、多くの企業が参画し、市場研究がなされ、ある種飽和しきっている、レッドオーシャンの様相を呈しています。
一方で、資本主義で解決困難なセグメントでは未だ市場が熟達しておらず、そのビジネスセグメントの核心にどんな課題が眠っていて、本質的にどのような解決を目指すべきなのかはっきりしていない側面があると考えられます。即ち、ドメイン駆動設計の観点で見ると、本質を突く「深いモデル」が眠っている可能性が十二分にあると私は見ます。
「深いモデル」の探求をも促進する「乳化」
「乳化」のコンセプトは、サービス価値向上へ導く「深いモデル」を探求するための、リファクタリングと本質追求のサイクルを効率的に回していける考え方だと私は解釈しました。「深いモデル」探求のための組織的下地がある、自分の挑戦を加速できる。これもREADYFORへのジョインを決断した大きな理由のひとつであります。
最後に
READYFORでの仕事はまだ始まったばかりですが、自分の力がエンジニアリングのDX向上、そしてひいてはサービス価値向上による社会問題の解決に結びつけばと思います。
