【前編】リファクタリングから読み解くサービス成長

【ご登壇者】
Sansan株式会社 執行役員/CTO 藤倉 成太 氏(モデレータ)
株式会社トラストバンク CTO/開発部長 山崎 賢 氏
ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長 雄川 賢一 氏

2021年2月18日に開催されたCTOmeetup。今回は「リファクタリングから読み解くサービス成長」をテーマにディスカッションを行いました。

注目される3社がどのように技術選定やソースコードのアップデートを行っているのかをはじめ、失敗しないリファクタリングの方法などさまざまなエッセンスをお届けします。

登壇者のご紹介

出会いからイノベーションを生み出す Sansan

藤倉 成太  氏
藤倉 成太 氏|Sansan株式会社 執行役員/CTO

“株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社。現在はCTOとして、全社の技術戦略を指揮する。”

Sansan株式会社 執行役員/CTO 藤倉 成太 氏(以下、藤倉):Sansan株式会社のCTOを務めている藤倉と申します。入社したのは12年ほど前です。当社は「出会いからイノベーションを生み出す」というミッションを掲げており、メイン事業であるクラウド名刺管理サービス「Sansan」や名刺アプリ「Eight」を通じて、人と人との出会いを可視化してきました。

また、最近は新たにクラウド請求書受領サービス「Bill One」という事業を立ち上げました。SansanやEightが個人同士の接点を記録していたのに対して、Bill Oneは会社同士の接点を記録することがコンセプトとなっています。「月次決算」や「請求書」といったワードが出てくるのでFintechと思われることもあるのですが、Bill Oneはあくまで会社同士がどんな取引をしていて、どんな関係性があるのかを管理するサービスとして育てていきたいと考えています。

さらに少し宣伝させていただきたいのが「Builders Box」という情報サブスクリプションの取り組みです。

Builders Box

藤倉:日本の素晴らしいエンジニアリングをよりグローバルに戦えるレベルへ発展させていきたいという私の個人の強い思いもあり立ち上げました。直近では、ロバートC.マーチン氏にクリーンアーキテクチャについて解説いただきました。

「Builders Box」へ登録いただいた方にはオンラインコンテンツの紹介やイベントへの招待などをさせていただきます。

ナンバーワン規模のふるさと納税の総合サイトを運営するトラストバンク

山崎 賢 氏氏
山崎 賢 氏|株式会社トラストバンク CTO/開発部長

“1976年生まれ。2020年5月からCTOとして株式会社トラストバンクに入社。それ以前においても他企業でCTOや開発マネジャーを努め、組織改革/アーキテクチャ刷新など多くのプロジェクトを遂行。常に事業課題と開発組織を紐付けて最適化していくスタイルで開発組織を牽引している。”

株式会社トラストバンク CTO/開発部長 山崎 賢 氏(以下、山崎):株式会社トラストバンクでCTOを務める山崎と申します。僕はSIerからキャリアをスタートし、ヤフーに入社してオークションやショッピングなどEC系のエンジニアとして活動しました。その後ベンチャー企業を経てリクルートに入社し、ホットペッパービューティやホットペッパーグルメ、じゃらんなどの開発責任者及びマネージャーを務めました。前職ではアソビューのCTOでした。トラストバンクには2020年5月にジョインしています。

トラストバンクには「自立した持続可能な地域を作る」という大きなビジョンがありふるさと納税が当社の事業の柱になっています。

トラストバンク

山崎:特に「ふるさとチョイス」というふるさと納税総合サイトは現状全国1570の自治体が掲載中で、お礼の品は30万点超にものぼります。ふるさと納税のサイトの中ではお礼の品掲載数・契約自治体数ナンバーワンの規模を維持しており、流通額は2017年時点でZOZOTOWNに次ぐ2100億円です。

このほか、例えばガバメントクラウドファンディングで首里城復興の寄付金を10億円以上集めるなど、地方の課題に対していろいろなチャレンジを行っています。

先進技術の研究開発を積極的に行うナレッジスイート

雄川賢一  氏
雄川 賢一 氏|ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長 

“ゼネコンの設計部で社会人をスタート。IT業界に転身後、システム開発の上流工程から下流工程まで規模や分野を問わず様々な案件を担当。PG、SE、アーキテクト、ITコンサルティング、PM等幅広い経験を有する。2013年にナレッジスイート株式会社に入社、現在は技術部門を統括する取締役としてエンジニア組織のマネージメント及び技術戦略の立案等を担当する。”

ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長 雄川 賢一 氏(以下、雄川):ナレッジスイート株式会社の雄川と申します。僕は2013年に同社に入社し、2018年に技術部門を統括する立場として取締役に就任。現在は2020年10月に発足した先進技術部門の部長職も兼任しております。

当社は「脳力をフル活用できる世界へ。」というコンセプトで事業展開しており、SFAやCRMなどのクラウドサービスを提供しています。創業は2006年10月、現在の従業員数は連結で178名です。

社名と同じ「Knowledge Suite」という当社の主力製品はグループウェアとSFAが一体となったサービスで、中小企業をターゲットに低価格で提供させていただいてます。

今、売り出しているのは「VCRM」というWeb商談ツールです。リモートワークが増えている昨今の情勢でリモート商談を支援できるサービスだと考えており、会社として初めてCMも放映しました。現在無償キャンペーン中ですので、この機会に是非使ってみてください。

先進技術開発部

雄川:また、最近発足した先進技術開発部はリアルタイム系の技術をはじめ、コンテナオーケストレーションやフロントエンド、IoTデバイスなどさまざまな技術の研究開発を行っている部門です。絶賛採用募集中なので、興味のある方はHPからご応募いただければと思います。

なぜ技術の選定やリファクタリングが重要なのか

各社の技術責任者が定義する「リファクタリング」

藤倉:では早速ディスカッションをスタートします。まず、テーマを考えたときにリファクタリングといってもいろいろな意味合いがあると思ったんですよね。前提部分をすり合わせるために、みなさんにとっての「リファクタリングとは何か」をお伺いできますか?

山崎:ビッグワードですよね。ちょっとしたソフトウェアの改修からドラスティックな技術の変更まで広い範囲がリファクタリングに含まれると思います。もちろんエンジニア視点で見たときに単純に「このソースコードを書き換えたい」と思うのもリファクタリングの一部です。

ただ、僕にとっては「中長期的にビジネスにどう貢献するか」をベースとしながら、ソフトウェアのあるべき姿を探る未来志向の考えがリファクタリングであるという理解です。

藤倉:雄川さんはいかがですか?

雄川:技術視点と経営視点でかなり異なってくると思いますね。技術者から見た場合はとにかくきれいなソースコードや仕組みにしたいという部分が強く出てくると思うのですが、経営者から見たリファクタリングは「リスクの解消」だと考えています。

リスクというのは、例えばソフトウェアが人に依存した作りになっていたり、いわゆるスパゲティコードになっていて保守に対する工数が膨れ上がり、費用がかさんだりするといったことです。

藤倉:ありがとうございます。お二人が言及されているようにコードをきれいに書き換えるのもリファクタリングの一つです。あとは例えばAWSの新しいサービスが出てきたからアーキテクチャを変更したい、ドメインモデルを変更するために大規模に手を入れていかなければならない、基盤をオンプレからクラウドに変える、プログラミング言語を書き換えるといった話もリファクタリングに含まれるかもしれません。

ですが、我々の立場としては「事業を運営する上でどういう意味があるのか」というのがリファクタリングにおける非常に重要な要素ですよね。

リスクを取りに行く技術選定ができるシーンは限られている

藤倉:そもそも新規でプロダクトを作る際、技術選定を間違えるとリファクタリングしなければならないタイミングがかなり前倒しになってしまうと思います。みなさんが技術選定で気を付けていることはありますか?

雄川:技術選定とリファクタリングの方針はセットだと思っているので、技術選定についても基本的に「リスクをどう解消するか」という視点で選びますね。

藤倉:我々の立場からすると経営上のリスクは可能な限り少なくする、あるいはどうヘッジするかをあらかじめ考えることが必要ですよね。

とはいえリスクを取りに行くケースももちろんあると思いますが、このあたりについてどのように考えていますか?

山崎:ビジネスの中心部に関してはやはりリスクを取らない選択をすると思います。例えば新しいアーキテクチャを選んだら楽しそうでも、まだ利用者が少なく人柱になってしまうような技術であれば選択しません。ある程度ナレッジが蓄積されており、今いるメンバーが対応可能かどうか判断します。

一方で、ある程度切り離された小さな部分であれば、チャレンジとして新しい技術を選定することもあり得ます。ビジネスに対するインパクト次第で考え方を変えるかもしれませんね。

藤倉:雄川さんはリスクの取り方についていかがですか?

雄川:ほぼ山崎さんと同意見です。どうしても新しい技術を採用したいケースも出てくると思いますが、そのときはどこに適用すれば一番リスクが少ないかを考えながら導入することになるでしょうね。あとは、リスクを取りに行くときは対応できる人がいるかどうかや、リスクを取れる環境かどうかが大きな判断基準になります。

SIと事業会社ではリスクの取り方が異なる

藤倉:僕は前職がSIerでいわゆる受託開発をしていましたが、SIと事業会社ではリスクの取り方が違うと思うことが多いです。例えば自分がSIを運営するなら、複数のプロジェクトを同時並行で走らせますよね。もし一つのプロジェクトで何か想定外のことが発生すれば横から人を持ってきて、トラブルが解消したらまた戻す。こうした取り組みで成功率を上げていくことになるので、「この人にしか解決できない」という問題はあってはいけません。

一方で我々のような事業会社の場合、複数のプロジェクトで人を行ったり来たりさせるようなリソースマネジメントはSIに比べて少ないので、2~3人しか扱えないような技術領域でも多少は手を伸ばせる余地があると思っています。

SIの方は「会社から認められていないから技術的なチャレンジができない」というフラストレーションを抱えていることが多いのですが、そこはやはり業態や会社の経営方針に依存してしまうなと感じます。

山崎:おっしゃる通りですね。リファクタリングによってビジネスに貢献しなければいけないのはもちろんなのですが、我々は事業会社なので、「働いているエンジニアがきちんとスキルアップできるか」という視点もあります。リスクを取った新しいチャレンジを継続的に外部に発信し、組織で働いているメンバーの市場価値を高めるという側面でもリファクタリングには意味があると思っています。

リファクタリングを行うタイミング

藤倉:今回視聴者の中にはどんなタイミングでリファクタリングをするのがいいか悩まれている方も多いと思うのですが、何か基本的な考え方や方針はありますか?

山崎:企業規模にもよりますが、リファクタリングは例えるなら数年に1回行う車検のような、義務的なイベントであってほしいですね。ビジネスを継続している限りソフトウェアは必ず劣化するものなので、最初から決め事としてリファクタリングの工数を確保しておくんです。工数を常に薄く設定しておくのか、3年に1度大きなターンにするのかは考え方次第ですが、こういったことを経営とネゴシエーションするとやりやすいのかなと思います。

雄川:僕の場合はエンジニアからリスクに関する報告を受けて、それにどう対処するかを決める感じです。リスクを放置した結果損害が出そうならなるべく早く片付けなければいけませんが、財務状況的に厳しいケースもあります。ですから最終的にリファクタリングするかどうかは、報告を受けた後にリスクと予算のバランスを見ながら判断することになりますね。

ただ、ある部分を共通モジュールに変えるといった小さなリファクタリングは、機能改修のついでにやれたりします。

リファクタリングをすべきかどうか、正しく判断するには?

山崎:リファクタリングで難しいなと思うのが、個人のエッセンスが含まれてしまうことです。基本的にエンジニアはきれいなソースコードでソフトウェアを書きたいと思うのですが、Aさんの作ったソフトウェアがBさんにとってもきれいだとは限らない。「このソフトウェアは複雑だから直したい」と言われたときにそういう要素を踏まえて正しい判断をしなければならないので、非常に苦労しています。藤倉さんや雄川さんは現場からそういった案件が上がってきたらどう判断していますか?

藤倉:「書き換える意味を理解できるか」「筋が通っているか」という判断基準があるかなと思います。「今回の改修でついでに同じファイルにある別のメソッドを書き換えました」と言われたら「なんで?」ですよね。でもこれが例えば「チームの方針として次のプロジェクトでここを共通モジュールにしておきたいので、一旦ワンクッション置くためにこの書き方にそろえています」と言われれば是とされると考えます。

雄川:僕も基本的には同じ考え方です。やはりリファクタリングをすることで何が解決されるのかが基準になりますね。山崎さんもおっしゃった通り誰かが「きれいに作りたい」と言ってもそれが他の人にとってもきれいかどうかはわかりませんが、誰がやっても問題が解消されるのであれば、リファクタリングは成功です。そもそもリファクタリングはソースコードを書き換える時点でリスクがありますから、慎重に考えますね。

山崎:ありがとうございます。成長しているビジネスのソフトウェアは基本的にどうあがいても複雑なのだろうと思うんです。単純にソフトウェアのクラス設計を見直すなら現場でやればいいのですが、大きなリファクタリングをするなら社内全体を巻き込んだ上で、その仕様が本当に必要なのかどうかから紐解いていく必要があります。そうでなければ、本当にきれいなソフトウェアにはできません。そこが悩みどころですね。

雄川:大規模な場合は仕様も含め、サービス自体を見直すレベルですよね。

山崎:とある論文では「ソフトウェアで表現しているものの8割は動かないコードだ」と言われているのですが、これは誰かが入れた仕様を削ぎ落としていないから、ずっと存在してしまうということですよね。リファクタリングで必要な仕様だけに落とすことができたらいいなと思います。

雄川:既に提供されているサービスの仕様を削ぎ落とすのは難しくないですか?

山崎:おっしゃる通りです。そこがリファクタリングの課題なのかなと思います。

Youtubeライブでリアルタイムに質疑応答

大規模なリファクタリングは薄皮を剥がすように少しずつ取り組むべし

質問者:共通モジュールが入り組んでおり大規模な改修が必要な場合に、手を入れて失敗してしまった例はありますか?


山崎:山を登りきれなかったことはありますね。誰もが知るような巨大なサービスだったのですが、共通モジュールが全てのモジュールに依存しており、複雑な仕様を全て抱え込んでいました。そこが常にボトルネックになっていることは全エンジニアがわかっていたのですが、そこにメスを入れるのが非常に難しかった。最終的に本当に重要な機能だけは切り離したものの、共通モジュール本体をなくすことはできませんでした。やるなら全部作り直しになるレベルでしたし、今も違う方法を考えられるかどうかは悩むような失敗談ですね。

雄川:僕は前職でそれなりに大きなシステムを見ていて、やはり山崎さんのような状況でした。そのときは少しずつ改善してやりきりはしたのですが、6年程かかりました。

藤倉:やはり我々が扱うシステムは常に新陳代謝していかなければいけませんよね。そうでないと、いつかどこかで完全に書き換える必要が出てきます。

山崎さんのケースも、本当に少しずつ薄皮を剥がすように改善を繰り返す方法しか無いのだと思います。それができるかできないかという話ですね。

 
1/2 ページ



この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問、エンジニアやデザイナーと企業を繋いでいます。

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内 / フルリモート
リモート 週1日のオンラインMTG・リモート

外部CTO、技術顧問案件

テーマ 技術アドバイザリーとして知見と経験を生かす(FLEXY登録後に詳細のご紹介)
勤務日数 1日/週
報酬 5〜10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京都内 / フルリモート
リモート フルリモート

インフラエンジニア(業務委託契約)

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 週2日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

技術アドバイザリー案件

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週1日
報酬 5万以上/日
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週2〜3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)