リファクタリングの理想と現実と泥臭さと / SEEDS COMPANY
この記事は、イベント 【PERSOL（パーソル）グループ Tech Talk #3 - 技術負債との向き合い方 - 】を開催しました。 の発表内容です。
桑田です。よろしくお願いします。
改めまして、パーソルプロセス&テクノロジーという会社のSEEDS COMPANYという部署の桑田と申します。
リファクタリングの理想と現実と泥臭さということで、今までの方々は割と現場寄りのお話が多かったと思うんですけど、私はちょっと経路を変えてプロジェクトマネジメント寄りというか政治寄りの話をしようかなと思ってます。
自己紹介です。私は2018年にSEEDS COMPANYにジョインしまして、エンジニアリング兼、スクラムマスター兼バックエンドアーキテクト兼みたいな感じでやってました。
最近はSEEDS COMPANY全体の技術責任者として会議漬けの人生を送っております。
好きな技術領域はGoを中心にみたいなところですね。民俗学が好きなんでアイコンに豆腐小僧をいつも使ってます。息子もこんな顔をしてるので、愛着があります。
改めまして、SEEDS COMANYという私どもの部署について説明させていただければと思います。
ビジョンとしては、世の中に新しい価値を提供し続け、毎日のライフにワクワクとドキドキを与え、まず有期雇用の採用マーケットにワクワクドキドキを提供したいというのを掲げております。ここで言うところの有期雇用の採用マーケットっていうのは、要するにアルバイト採用のマーケットです。
その中でもアルバイトを採用したい人事部の方とか、店長さんに向けた自社プロダクトを展開しています。
1つ目がヒトマネージャーという10年ぐらい歴史のある採用支援管理システムATSというプロダクトです。もう一つがエクシーというここ3年ぐらい前にリリースしたスマート採用支援ツールです。
私は元々、このエクシーの方の技術責任者としてジョインしましたが、いつの間にか両方見るみたいな感じになってます。
SEEDS COMPANYが目指す世界は、寝てても採用できる世界を作るということで、この絵はSEEDS COMPANYのカンパニー長であるジェンという男が書いた絵です。
この絵を持ってうちの社長にプレゼンしに行って、めっちゃ怒られるみたいなことをするような男なんですけれども（笑）
これが何を表してるのかというと、普段業務でとても忙しい店長さんみたいな方が寝ていたとしても、ドアからアルバイトさせてくださいという人がドタドタとやってくる。そんな世界を目指して日々頑張っている次第です。
他にSEEDS COMPANYの特徴として、独立した自社プロダクトを扱う社内ベンチャーの組織として、開発者だけでなくデザイナーセールス企画みたいな人間がいるということです。自分達で責任と権限を持って素早く動くというまさしく大企業。会社としては大企業なのですが、文化としてはまるっきりベンチャーみたいな感じの雰囲気で日々仕事をやっています。
技術としては、HITO ManagerがRuby on Railsで作られていて、エクシーはReact + Goで作られています。インフラは全てAWSに乗ってます。
その他、技術領域でいうとTerraform、 GitHub、 Jira Confluenceを使っています。ほぼフルリモートで過ごしていて、普段はSlackでコミュニケーションを取り、ちょっと話した方が早いねという場合はZoomで会話をしています。
また、開発者にはMackbook Pro支給と言う感じで、割と現代的なITプロダクトを作ってる会社としては標準的な環境をご用意できてるのかなと思っています。
文化としては、少なくともSEEDS COMPANYのマネージャー級以上（私を含めて4名居てもちろん営業出身者のマネージャーとかも居ます）の者に、この「エンジニアリング組織論の正体」みたいな書籍を必ず読んでいただくようにしていて。
営業が一番偉いみたいな、そういうのはなくて。職種ごとの権力勾配は本当になく、そういった意味でもフラットな組織なのかなと思っています。
ここからは事例の紹介をさせていただきます。10年ぐらい続いたHITO Managerというプロダクトの事例についてです。10年続いたプロダクトの新規開発を2年止めてリファクタ大作戦ということをやろうとしていました。
HITO Managerについて改めて商品説明をすると、大手企業アルバイト向けの採用管理システムです。この下に使っていただいている企業様のロゴを書かせていただいているんですけれども、割とどなたでも見たことがあるような大手企業様に使われているようなプロダクトです。
保守開発しているものは時期にもよりますが、合計で大体4〜5名ぐらいのチームでプロダクトの保守や開発をやっています。そのチームの課題として、開発速度の低下というのがずっと挙げられていました。
開発チームとしては、RailsのActive Scaffoldという機能で作られているのが原因だということでした。このActive Scaffoldっていうのは、PHPをご存知だったらCake PHPのベイクの機能みたいな感じで。コマンドを叩くと、それに関連するクラウド機能が編集画面など一覧画面が1発でできるみたいなものです。その拡張機能でHITO Managerの初期開発した機能とかが作られています。この機能が技術的に困難なので開発スピードが上がらない状態になっていたようで。そういったロジックの元、2年新規開発止めてこれをリファクタしたいよみたいな話がチームから上がりました。
当時の私含めたマネージャー陣の認知としては、Active Scaffoldのせいで、開発速度が上がらないのは理解しました。とはいえ、10年続いてるプロダクトなので「機能と機能の絡みつきみたいなところの仕様の部分の複雑性が結構上がってるところが、開発スピードが上がらない理由なのでは？」と言う議論もありました。
本当にActive Scaffoldをなくしたところで、上手くいくのかどうかが正直疑問でした。結局、着手した半年後に優先度の高い開発案件が発生してリファクタの優先度が下がってしまい現実的な帰結となりました。
とは言え、開発速度の課題というのは継続して何とかしなければいけない課題なので、本当の原因は何だろうということで改めてチームの皆さんと話を聞きながら検討しました。現状はこういうプロセスというか因果関係を持って、開発速度が上がらないと言う結論に至っています。
つまり「開発速度が足りなければ、開発リソースを増やせばいい」と言う銀の弾丸じゃないんですけども、そのような対応は一定以上は効果あると思っています。
しかし、新しい人を入れてもなかなか戦力化できない、思ったように開発速度が上がらないところがありました。学習コストを積めない構造になっているチームの動きが原因になっていたのです。
さらに原因を突き詰めると膨大な顧客対応をエンジニアがしなければいけなくて、実装も学習コストが積めない状況だったり、複雑な仕様が原因でもあります。
また自動テストがないこともあって、仕様の知見者にどうしても他のメンバーが依存してしまう。それは技術的な依存もそうですけれども、心理的な依存が大きい状態でした。
つまり「ここ本当に直して大丈夫なんですかね。でも知ってるあの人が大丈夫って言ってるから大丈夫なんだろう。」といった状況が起きていました。
逆にいうと、自分仕様を調べぬくみたいなカルチャーが作れない構造になっているところが原因だったのかなと思っています。
その依存度を減らすために、一定程度の不具合は許容することをセールス交えてネゴシエーションしました。これにより、「まずは学習コストを積めるような関係を作りましょう。」「開発リソースを増やせるような状況を持っていきましょう。」と、現在の短期的な目標として掲げてやっているような状況です。
次は事例の2個目です。マイクロサービスアンチパターンですね。
こちらはエクシーという小規模事業者様向けのアルバイト採用プラットフォームで、3年ぐらい前に正式にローンチしたプロダクトのお話をさせていただければと思います。
フロントエンドとバックエンドでメインの担当が分かれていて、フロントが大体1〜3名くらい、バックエンドが3〜4名ぐらいのチーム体制でやっています。
SEEDS COMPANYは、元々HITO Managerをやっていて、技術的にもビジネス的にも知識を使って新しくエクシーというプロダクトを作ったんです。
その時、HITO Managerの開発経験からNVCのアーキテクチャでモノリスのシステムだと複雑な仕様になりがちだと言う話に当時のメンバーがなったらしくて。マイクロサービスで行こうみたいな話になったと聞いています。
この時、私はジョインしてなかったので、伝聞なんですけれども。
2018年10月に桑田がジョインしました。エクシーというプロダクトはマイクロサービスでやっているらしいぞというのを聞き、私は当時マイクロサービスの経験がなかったので、マイクロサービスの現場ってどんななんだろうとワクワクしながらジョインしたんです。
実際、私達のマイクロサービスは多すぎみたいです。そんな現実にぶち当たりました。
当時、誰も数えてなかったので私が改めて数えてみると、マイクロサービスが20個ぐらいあったんです。よく見てみたら、MVCのコントローラーのレイヤーでサービスを分けているみたいな話でした。しかも1サービスをデプロイしたいだけなのに、わざわざ全部デプロイしなきゃいけないみたいな。そんな感じになっていました。
ということで、開発者体験がモノリス以下でものすごい開発スピードも上がらないし、MVC当時のメンバーからしたらクリーンアーキテクチャという話だったんです。
クリーンアーキテクチャは私は経験があったんですけれども、そこから見るとMVCですらない、オレオレアーキテクチャだなみたいな感じでしたね。
あとは先ほども申しましたデプロイが遅い問題であったり。テストをせっかく書いているのにCIがないみたいな感じになっていました。
そんな中、ジョインして数カ月後にいきなりリリース期限付きのエグい改修プロジェクトが発生することが確定しました。
現状の生産性では間に合わないというのが分かりきっている状況にありました。そこで私は言いました。
「アーキテクチャを直せば間に合わせられる」と。もうこれは90%虚勢でした。でもとはいえ、アーキテクチャを変更しないと開発速度ができないできないのはわかりきっていたので、その改修プロジェクトにかこつけてあるべきアーキテクチャについて今でも動いてますね。
2018年12月28日に他の人がもう年末で有休取ってる中、私が一人で会社に出社してホワイトボードにガーッと色々書いて草案を策定しました。そして、週明け1発目にもバックエンドエンジニアをみんな集めて新しい方針について熱く議論しました。
結果、20個ほどあったマイクロサービスを5サービスに統合しました。そのうち3マイクロサービスがほぼ改修しなくていいだろうものたちです。
バックエンドのエンジニアは実質2サービスだけ見ればいいというところまで持っていきました。後はCI/CDを導入しました。circleciですね。
サービスごとにデプロイ可能なように諸々変更をしました。というのとアーキテクチャについても、DDD+Clean Architectureが最強だよみたいな話になりまして、そちらを導入しました。
当時のメンバーもDDD+Clean Architectureが実際どうなるかをよく分かってなかったので、もう私がガーッとコードを書いて浸透させに行ったり、プルリクエストでこの辺はちょっと違いますよね、みたいな話をもう地道にやり続けました。結果、無事に何とか期日にリリースすることができました。
というわけでまとめです。リファクタの現実として、ビジネスで止めても、リファクタみたいなことをやらなくてはいけない話になります。しかし、そのハードルはエンジニアが思っているよりも3倍は高いのです。高いだろうなと思っていても、その3倍高いのです。なので、新機能開発のついでにリファクタをするのが最強というのが私の持論です。
一つはそもそも触らない場所をリファクタしても、コストパフォーマンスが悪いので新機能を追加するついでに行うこと。それに関連する場所なので、そこをリファクタする方がコスパ絶対いいよねっていう話です。
あともう一つは、工数交渉がとても楽です。定期的にリファクタしましょうみたいな話が世の中に溢れてるとは思うんですけれども、これは緊急性の高いプロジェクトとかが発生するとこうないがしろになってそのままそのカルチャーが消滅していくみたいなの私も人生で過去何度も見てきた話です。
やっぱりその定期的なリファクタって強い意志と交渉力が必要だなと感じていて。
それだったら新規の開発の時にリファクタ分もスケジュールにもう一緒に混ぜ込んで積んでおくみたいなことができれば一番交渉楽ですよという話です。
あともう一つですね。泥臭さが重要ということで、上流面で言うと安易な解放。
つまりコードを書き直せばいいじゃんみたいな話に飛び付かずに、調べぬくことを考え抜くことが重要です。あとはビジネスサイドや経営者経営陣への説明力ですね。こちらも重要かなと思っています。実装とか現場面でいうと、やっぱりチームへの説得とか浸透ですね。
これをやり抜くっていうのは、とても重要です。
つまり、理想論だけ語っても意味がなくて、実際にやってみせないと分かってもらえないというところですね。あとは、文化面へのアプローチも視野に入れるべきということですね。これは解法の中に手を動かす以外にも、効果のあることは絶対にあるので、そういったことも射程に入れながら物事を考えましょうということですね。
というわけで、SEEDS COMPANYは引き続きエンジニアの方々を採用しておりますので、是非ご興味ある方は桑田のツイッターまでご一報をお願いいたしますってことで以上です。ありがとうございました。
イベント 【PERSOL（パーソル）グループ Tech Talk #3 - 技術負債との向き合い方 - 】を開催しました。 の発表より
– - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
桑田 詠士 / パーソルプロセス＆テクノロジー株式会社 SEEDS COMPANY
多様な職種を経て、2011年にWeb広告代理店のエンジニアとしてエンジニアのキャリアをスタート。広告管理システムの開発やSFA導入、新規事業開発に携わる。2018年にSEEDS COMPANYにジョイン。 エンジニアリングマネージャー兼スクラムマスター兼バックエンドアーキテクトとして、x:eeeを中心とした開発の責任者となる。現在はSEEDS COMPANY全体の技術責任者として、マネジメント中心の（≒会議漬けの）人生を送る。
好きな技術領域はgolang, Goa, Amazon CloudFront, Google App Engine.
Twitter
パーソルプロセス＆テクノロジー株式会社 SEEDS COMPANY
SEEDS COMPANYは、アルバイト・パート採用の業界に眠る問題に変革を起こすために生まれたテクノロジー組織です。 アルバイト、パート、派遣など、いわゆる非正規雇用の領域を対象にしてプロダクトを作っています。 10,000店舗以上を経営する小売チェーン店をはじめ、多種多様な業界の大手企業に活用されているATS「HITO-Manager」と、スマホ特化型の採用支援ツール「x:eee」の開発・運営を行っています。
– - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ミイダス Techについて
ミイダスでは、様々な技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスグループのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。
イベントページ：https://miidas-tech.connpass.com/
Twitter：https://twitter.com/miidas_tech
この記事が気に入ったらサポートをしてみませんか？