合同会社DMM.comの大規模なエンジニア組織で、技術的負債解消に取り組んでいるミノ駆動さん。『改訂新版 良いコード／悪いコードで学ぶ設計入門』（いわゆるミノ駆動本）の著者としても知られています。
当然ながら、エンジニアになったときから、それらの領域に精通していたわけではありません。では、どのようなキャリアをへて専門的なスキルを身につけていったのでしょうか。今回は「技術愛好家の履歴書」と題し、ミノ駆動さんが、設計・リファクタリング分野のスペシャリストになるまでの道のりをインタビューしました。
2社目：『リファクタリング』との出会い
― 設計やリファクタリングに関心を持ったきっかけは？
2社目にいたころ、ある炎上プロジェクトにアサインされたことがきっかけです。私が入ったときには、すでに大変なことになっていました。
顧客から言われた要望を即座に実装し、ひたすら手動テストをするという開発体制。当時としては当たり前なのですが、単体テストを書いたり、品質を上げていくための仕組みを作ったりということはありませんでした。
バージョンアップ開発のたびにすさまじい量のバグが出て、100や200の障害はザラ。バグを1つ直すと、別の箇所で複数のバグが出るということもありました。そして、なぜそのバグが出たのかという分析も大してなされず、付け焼き刃的な修正が横行していました。
そんな状態でも納期はあるので、数十人規模のチーム全員で長時間残業してバグがリリース可能な数に収まるまで一生懸命つぶす、ということをやっていました。みんな、「これが普通でしょ？」みたいな感じで。今になって振り返ると、チームメンバーが若くて体力があったのだと思います。
あのころは私も若かったのですが、他の人よりも早くへばってしまいました。たぶん周囲と比べて体力に恵まれていなくて、ストレスや痛みを強く感じていたのだと思います。「こんなにバグが出るなんて、さすがにおかしいのでは？」「技術的に何か問題があるに違いない」と違和感を覚えました。
自主的にソフトウェア開発の勉強をしはじめ、いろいろな本を読んでいくうちに職場の誰も普段触れないような本棚から、『リファクタリング』（著：マーティン・ファウラー）を見つけました。
冒頭に「バグを低減する設計」という風な記述があって「これだ！」と思い、本の通りにリファクタリングしてみたら、何を実行しているのか分からない複雑なコードがすっきり整理されて意図がすっと理解できるようになりました。
それが感動を覚えるレベルの体験で、あまりにも面白くて、それからさまざまな設計関係の本を読むようになりました。
― 設計やリファクタリングを“組織として”取り組んだ最初の経験は？
その炎上プロジェクトで開発していたソフトウェアが事業レベルで問題になってしまい、調査チームが入って「ソースコードが非常に混乱していて、不具合が起こりやすいのでリファクタリングが必要だ」ということになりました。
私は、リファクタリングプロジェクトに参画させてください、と手を上げ、計画策定・設計ガイドライン策定などをしました。
しかし、結論を言うと、うまくいきませんでした。現場から大反発を受けたんです。
リファクタリングプロジェクトにはソースコードを熟知してる人が必要で、たしか開発メンバーのうち3分の1くらいがアサインされたかと思います。その結果、リファクタリングしたくない人までアサインされることになり、さらには人員が減ってしまった開発チームから「開発が送れる」「競合他社に負けてしまう」という声があがりました。
チームリーダーすらリファクタリングプロジェクトに反対していて、私はみんなから目の敵にされてしまいました。何かひとつするにしても理論武装して説得しなければならず、話が全くまとまりません。結局、ほとんどリファクタリングが進まないまま、頓挫してしまいました。
― つらい経験ですが、このころを振り返ってみてどう思いますか？
のちに活きたと思う学びが、2つあります。
1つは技術面。リファクタリングプロジェクト反対派の人たちに「こう設計をしたら、何が、どんな風に良くなるのか」を理解してもらうためには、私自身が設計という技術の本質を理解していなければならず、いろいろと調べたり言語化したりしていました。
これが自分のスキルを高めることにつながりました。例えば、私の著書『良いコード／悪いコードで学ぶ設計入門』には「とても分かりやすい」という感想をいただいているのですが、その背景には当時の学びがあると思います。
もう1つは組織面。当時の私は「動いているシステム全体をリファクタリングしよう」と考えていたのですが、あれは良くなかったと思います。そのような大規模なリファクタリングには工数的な課題や、動いているシステムが壊れてしまうリスクがあります。そして心理的には、不安が湧いてしまうものです。
― 「そんなことできるの？ 本当に大丈夫なの？」と不信感を抱いてしまうかもしれませんね。
あのとき、どうすればよかったのか。本当に小さい規模から、スモールステップで進めていくべきだったんです。実際に手を動かしてみて、コードが整理され読みやすくなる実感を得ながら「やっていけるぞ」という信頼感を高めていくことが必要でした。
また、目線合わせの重要性も感じています。当時の自分は「リファクタリングは絶対正しい」「絶対にやるべきだ」という態度で、反対する人たちの考えを無視する提案をしていたと思います。
でも、チームとして進めていくにはみんなから信頼を得て、それぞれの実情も踏まえながらソフトランディングできるやり方を模索しなくてはいけないんですよね。
3社目：リファクタリング専門チーム立ち上げ
― その後はどうやってスキルを磨いていったのでしょうか？
Twitter（現X）で「リファクタリングはこうすべき」「こう設計するとうまくいく」というツイートばかりしていたら、株式会社クラウドワークスの役員の方から「技術的負債のために、ぜひうちに来てくれないか」という連絡が来て、転職しました。
入社後、どうやって設計やリファクタリングを進めていくかという話し合いがあり、私を含め数人規模の“リファクタリング専門チーム”を創設することになりました。
リファクタリングの優先度は、機能開発よりも下げられがち。ですが、「いま開発で忙しくて手が回らない」というような動きをしていると、どんどんコード品質が落ちていってしまいます。だから、開発チームと並行したチームを設けることで、リファクタリングの優先度が保てるようにしようという考えです。
― そのチームでは、どんな取り組みをしていましたか？
大きく3つあります。
1つ目は、自分で手を動かしてリファクタリングすること。2つ目は、チーム内のメンバーにリファクタリングの手法などを教えること。3つ目は、社内に20人以上いるエンジニアたちに、設計スキルを身につけてもらうための支援をすることです。
― 1つ目、2つ目は、リファクタリングチーム内の動きですよね。しかし3つ目、どうしてチーム外のエンジニアのスキルアップ支援をしていたのでしょうか？
リファクタリングは「とにかくコードを書き換えれば整理できる」というものではなく、かえってコードが混乱してしまうこともあります。なるべくバグを埋め込まず、素早く正確に変更できるようにするための“変更容易性の設計”が重要なんですね。
この変更容易性という品質特性を実現することが、リファクタリングのゴール。そして、そのためには「変更容易性の高い、理想的な構造とはどんなものなのか」という知識が欠かせません。
それで、20人以上いたエンジニアたちにも設計スキルを身につけてもらう必要があり、実際に手を動かしてコードを書くワークショップ形式の勉強会を開催していました。
― このころに得た学びには、どんなものがありますか？
一つ一つあげるのは難しいですね。毎日が学びだらけだったので。
前職の2社目では「なぜリファクタリングをしなければならないのか」と説明することに追われてしまい、うまく身動きが取れませんでした。ですが、3社目ではみんなが技術的負債のつらさを知っていて、リファクタリングの必要性が共通認識になっていたので、進めたいことをどんどん進めていけました。
今までやれなかったことをやるたびに学びがあって、その経験を次に活かせる。毎日がその繰り返しです。まさに水を得た魚のような感じでした。ああ、やっと泳げるところが見つかったぞ、という。
4社目: 「アーキテクト」の仕事をしていたことに気付く
― Xのプロフィールによると、ミノ駆動さんは「DDDとリファクタリング大好きなアプリアーキテクト」。「アーキテクト」を自認するようになったのはいつからでしょうか？
4社目に所属していたころでしょうか。
アーキテクトの定義を調べたら「ビジネスに合わせてソフトウェアの品質特性を調整・促進する責務を持った人」というようなことが書かれていて、自分の仕事がまさにそうだったんです。それから自ら名乗るようになりました。
― では、4社目ではどんな活動をしていたのでしょうか？
3社目までに経験してきた今ある技術的負債解消の取り組み、設計スキルの勉強会といった取り組みに加えて、「事業構造を熟知したうえで、事業を適切に拡大させるためのアーキテクチャ構造を再設計する」という仕事もしていました。
現職: 100人超の大規模組織での設計・リファクタリング
― 『リファクタリング』との出会いで始まり、自分で手を動かすところから組織との関わりまで仕事が広がっていき、「アーキテクト」を自認するに至るまでの流れをお伺いしました。6社目となる現職のDMMでは、どんな役割を担っているのでしょうか？
横断チームのエンジニアとして、「DMMプラットフォーム」の設計品質の向上に取り組んでいます。
私が所属するDMMではさまざまなサービスを展開していますが、どのサービスにもアカウント管理や決済、不正対策といった共通機能があります。それらを提供する共通基盤が、社内ではDMMプラットフォームと呼ばれています。
問題が発生しているわけではありませんが、より開発生産性を高めるためには技術負債の解消が必要で、負債解消には設計が必要。そのために設計品質の向上に取り組んでいる、という感じです。
― 具体的には、どんな取り組みをしているのでしょうか？
自分の手でリファクタリングする、ということは基本的になくなりました。
先ほど言ったようにDMMプラットフォーム上ではアカウント管理や決済、不正対策……といったさまざまなサービスが動いていて、自分一人ではとても手が回りません。
現場にいる120人以上のエンジニアたち一人一人が設計スキルを身につけ、日常的にリファクタリングに取り組めるように、チーム持ち回りの勉強会やガイドライン策定などをしています。あとは大規模なチームでの開発をうまくまわすための調整などもしていて、一言でいうと“技術組織改善”みたいな感じですね。
ところで、ミノ駆動さんと言えば……
― 最後の質問になります。ミノ駆動さんは「バグハンター」シリーズのゲーム制作、また、いわゆるミノ駆動本（『良いコード／悪いコードで学ぶ設計入門』）の執筆もしています。こちらは、いかがでしょうか？
スキルアップにとても役立ちました。
本の執筆は「書きたいことがうまく書けない」「調べてみて技術理解が深まって書けるようになる」ということの連続で、書くたびに分からないこと、理解が曖昧な部分が出てきました。自分の技術理解の浅さを認識するきっかけになりましたし、1冊書きあげるまでの過程でどんどん理解が深まっていったと思います。
しかし、本の出版に関して周囲に話を聞いてみると、技術書を書ききるというのはとても大変なことなんですよね。
私の『良いコード／悪いコードで学ぶ設計入門』は2年未満で完成しましたが、それでも他の技術書著者の方から「よくそんなに早く書けたな」と驚かれました。
― 年単位で頑張ってようやく完成するものなんですね。
私が1冊書きあげることができたのは、ゲーム制作を通じて、本業以外で何かを作りあげるための持久力がついたからだと思っています。
ゲームづくりではたった1分のシーンのために10時間、本当に小規模なゲームを仕上げるだけで数か月～半年かかることも珍しくありません。私の開発したフリーゲーム「バグハンター2 REBOOT」は、毎日少しずつ制作を進めていって完成までに4年間かかりました。
結果として、マラソン的にコツコツと何かをやりつづけることが当たり前になり、それが1冊の技術書を書きあげるための基礎体力につながったんじゃないかと。
