「HackWeek2024」イベントレポート

こんにちは、ラクスル技術広報の和田です。
RAKSULの夏と言えば、、そう、、HackWeek！！

今年も、社内ハッカソンイベント「HackWeek2024」を開催しました。本記事では、HackWeek開催期間中の様子や最終日の成果発表会・表彰式に至るまで、イベントの裏側をご紹介します。

今年のテーマは　”Back to the Venture”
RAKSULはベンチャー企業として創業以来、スピード感と挑戦を武器に成長してきました。
しかし、組織が拡大するにつれ、当初のベンチャー感が薄れつつあるという側面も感じられるようになりました。
今年のHackWeekのテーマ「Back to the Venture」には、創業時の原点に立ち返り、リスクを恐れずに挑戦するベンチャー精神を再活性化させるという強い想いが込められています。HackWeek2024は、RAKSULが次のステージに向けて踏み出す重要な一歩として、我々のDNAを再び活性化し、イノベーションを生み出す数日間にしようという熱意に満ちたイベントとなりました。

※昨年度の様子はコチラ

HackWeekとは

「HackWeek」とは、RAKSULのエンジニア、デザイナー、PdMが、その年のテーマに沿って一定期間集中的に開発を行う社内ハッカソンイベントです。 このイベントは、通常の業務とは異なる視点でアイデアを具現化する場として機能しています。また、私たちが掲げるEngineering Culture「Go Beyond」を体現する場でもあり、参加者たちが失敗を恐れず挑戦し、従来の枠組みを超えて新たな可能性を仲間とともに切り拓く機会となっています。

今年は「ラクスル」のみならず、ラクスルグループに所属する「ノバセル」「ハンコヤドットコム」「ペライチ」「エーリンク」も参加し、グループ全体で一体感を持ちながら取り組みました。
※ラクスルのエンジニアリングカルチャーについては会社紹介資料を参照ください

HackWeek開催まで

ロゴデザイン

今年のHackWeekロゴデザインは社内コンペで決定しました！なんと、14案もの素敵なデザインが集まり、どれも個性的で、HackWeekのテーマやエネルギーを表現するアイデアが盛り込まれていました。デザインの詳細やコンセプトもそれぞれ用意されていて、全社員が投票形式で選びました。単なるデザイン選びではなく、RAKSULの未来を創る取り組みの一環として、デザインチームも大いにHackWeekを盛り上げてくれました！

今年採用されたロゴデザインは、24新卒デザイナーが手掛けました👏

自己紹介

グループメンバー間の相互理解のため、自己紹介と意気込みを共有しました。

カウントダウン

今年もイベント開催の数日前から、全社横断のカウントダウンリレーを実施しました。毎日異なるメンバーがリレー形式でHackWeekの開始を待ち望む気持ちを共有しました。

会場装飾

HackWeekの雰囲気を盛り上げるため、今年は会場の装飾もより一層こだわりました。テーマである「Back to the Venture」を象徴する大胆なデザインが、参加者たちの熱気を視覚的にサポートし、まさにHackWeekならではの演出となりました。特に、HackWeek用に制作した自社サービスの、「のぼり」が会場内の目立つ場所に設置され、今年のテーマを強調し、会場全体に活気とエネルギーをもたらしました。

開発メンバーへエール

事務局から開発メンバーへ、さまざまな差し入れを用意しました。

差し入れを楽しんでいる様子😁

成果発表会

HackWeekのクライマックスとなる成果発表会では、全13チームがハイブリッド形式で集結し、5日間の開発の成果を披露しました。開発テーマは、最新技術を駆使した革新的な取り組みが目立ち、AIを活用したツールから業務効率化を目指すプロジェクトまで、あらゆるアイデアが飛び交うプレゼンが繰り広げられました。各チームの発表内容は想像を超えるほど高い完成度で、会場は終始歓声に包まれていました。

表彰式

今年は、特に優れた成果を称えるために5つの賞が設けられ、それぞれの賞の趣旨に沿って全社員による投票形式で受賞チームを決定しました。

グループCTOからは、我々のEngineering Cultureである「Go Beyond」「Think Architecturally」「Make it Scalable」を参加者全員が体現する素晴らしいハッカソンイベントになりました。グループ会社の垣根を越えたチームも編成され、開発組織全体のシナジーをまじまじと感じました。 また、AIを駆使し、新たな価値提供につながるアイデアが多数見られたことは、純粋にとても嬉しいですし、我々の今後の展望に、大きな可能性を感じざるを得ませんでした。 今回の成果をアイデアでは終わらせず、プロダクトとして世の中に出していくことで、社会や業界に新しい風を吹き込み、これまでに見たことがないようなビジネスモデルの創出に繋がることを期待しています。と、メッセージが贈られました。

ここからは、HackWeek2024で各賞に輝いた受賞チームをご紹介します。

Back to the venture AWARD

AIの能力を最大限に活用し、HackWeekのテーマ決定から実装、発表まで最小限の人の介入で実行する大胆な挑戦。 リスクを恐れず、時代の先端を行く開発に果敢にトライし、その挑戦心が際立った「AIにHack Weekさせてみた」チームに贈られました。

ー称賛コメントー

多くのプロセスをAIで完結させたことで、その可能性が大いに示され、特にプレゼンテーションまでAIで行った点が非常に面白かったです。どのような成果が生まれるか予測できない中で、未来の技術に対する期待が高まりました。今後もこのような革新的な試みを続け、AIの進展によるさらなるクオリティ向上を楽しみにしています。

Go Beyond AWARD

生成AIを活用して印鑑の印影を自動生成し、製造効率と顧客体験を大幅に向上。 他社との差別化を実現し、オペレーションとの統合によってさらなる価値を生み出した「ハンコ印影のAI生成」チームに贈られました。

ー称賛コメントー

業界の構造を変える可能性がある新しいチャレンジとして、発想は基本に立ち戻りつつも革新的で感動的でした。高いクオリティと解像度で、課題設定も優れており、顧客体験の飛躍的向上に寄与する要素が見受けられました。特に画像生成AIによる自動化が業務の未来を変える予感を抱かせ、現場の学びと実用性を兼ね備えた施策として、他社には真似できない内容が素晴らしかったです。

Think Architecturally AWARD

コードとドキュメントの整合性を自動的に最新状態に保ち、作業手順を案内することで、情報の欠落や古さを解消するツールを開発。 現場のニーズを深く理解し、それに基づいた実装で、すぐにでも使用可能な成果を出した「〇〇(マルマル)タスカル」チームに贈られました。

ー称賛コメントー

拡張機能を活用し、コードとドキュメントの相互メンテナンスを実現した仕組みは、ドキュメントの属人化を解決し、開発者全員にとって非常に便利で実務に即活用できるものでした。技術的な実装の完成度も高く、明日からでも使用可能な点も素晴らしかったです。今後の基盤系システム構築や他分野への展開も大いに期待しています。

Make It Scalable AWARD

チラシの入稿データを基に顧客のビジネス状況を把握し、それに合った他の商品を提案するクロスセル機能を開発。 社内の資産を効率よく再利用し、拡張性のあるシステムを構築した「チラシ画像からのぼりの入稿データを作ってみた」チームに贈られました。

ー称賛コメントー

再利用アイデアが素晴らしく、データを商品間でやり取りする戦略は、商品数が多いラクスルならではの利点であり、クロスセルやサービス拡張にシナジーを生む可能性があります。特に、中小企業にとっては、デザインデータの汎用化やノウハウの再利用が大変有益で、実用化に期待が持てます。さまざまな技術を駆使したのぼり生成のチャレンジも、多くの企業で必要とされるサービスであり、素晴らしい取り組みでした。

CTO AWARD

生成AIと分析したデータを活用し、広告の効果を最大化するクリエイティブ自動生成システムを開発。 テックカンパニーの精神を体現し、革新的なアイデアを実現した「クリエイティブ超DX」チームに贈られました。

ー称賛コメントー

ノバセルのアセットを活用し、分析によって見えない領域が明らかになるとともに、高品質な成果物が期待できるこのプロジェクトは、シナジーを生む可能性が高く、チラシなどの印刷物にも転用できる実用性があり、今後のビジネス拡張に大いに貢献する未来が感じられました。課題設定が適切で、実行可能な解決策が見えている点も非常に良かったです。

事務局へ届いた、喜びの声

「受賞できて嬉しいです！ラクスルで働くメンバーにとっても使いやすいものとなっていると思います！HackWeekに留まらず、今後もみんなで利用・拡張していけるプロダクトになれば良いなと思います！」
「多くの方から『使いたい』と言っていただけて、とても嬉しいです！自分も欲しいと思えるものの開発に1週間丸々集中できたのも、本当に楽しい時間でした。ありがとうございました！」
「非常に光栄です！この賞に恥じないよう、今回のOUTPUTをブラッシュアップし、実際にユーザー価値をデリバーするところまでコミットします！」
「事前に大阪出張に行ったり、技術検証したりと熱量高く取り組んだ成果が出て嬉しいです！運営の皆様や毎日頑張ったチームメンバーに感謝です！ありがとうございました！」
「とてもわくわくする1週間でした！運営の皆さん、ご対応ありがとうございました！」
「今回の取り組みでは、日常の業務ではなかなか試せないアイデアを形にする機会を得られましたし、何よりもチームでの情熱と協力があってこそだと思いました。HackWeekの賞を受賞できてよかったです！」
「初のハックウィーク参加でしたが、受賞できて大変嬉しいです。今後のモデルの発展次第では多岐にわたるプロジェクトで活用できる未来が見えました。」
「他事業の業務解像度が爆上がりした1週間でした！テーマの直接的なHowだけでなく、色々と改善できそうなところを、チームメンバーとディスカッションできて得るものが多かったです！」
「チームで勝ち取りました！HackWeek最高！受賞できて嬉しいです！」
「チャレンジングなテーマでしたが1つの結果を提示するところにたどり着くことができ、面白さと今後の可能性を共有できたことが大変嬉しいです！受賞させていただきありがとうございます。」
「全力で走った1週間でした。結果も残せて大満足です！」

さいごに

今年のHackWeekはRAKSULグループが新しい段階へと進んでいることを肌で感じる、そんな素晴らしいイベントでした。このイベントを通じてチーム間のシナジーは一層高まり、未来を共創する強い意志が育まれました。
やっぱり楽しいな、HackWeek・・・（笑） 参加者の皆さん、お疲れ様でした！サポートいただいた皆さん、いつもありがとうございます。
来年もさらに成長したHackWeekをお楽しみに！またお会いしましょう！

【イベントレポート】Findy主催「開発生産性Conference2024 」に登壇しました

6月28日、ファインディ株式会社主催のイベント「開発生産性Conference 2024」が開催されました。
本パネルディスカッションでは、エムスリー株式会社 取締役CTO/VPoP山崎氏と、ラクスル株式会社 上級執行役員CTO SVP of Technology竹内が「エンジニアは事業KPIにどのように向き合うか？」や、両社のROI最大化の秘訣や実践例についても深く掘り下げました。明日から活かせる実践知となれば幸いです。

ROI（Return on Investment）の「R（リターン）」と「I（投資）」どちらが大切か？

ーーまずは、エムスリーとRAKSULの現状について教えてください。

山崎：
エムスリーは、「インターネットを活用し、健康で楽しく長生きする人を１人でも増やし、不必要な医療コストを１円でも減らすこと」を目指す医療IT企業です。2000年に創業し、現在東京証券取引所プライム市場に上場しています。

事業は医療ニュースサイトや医師向け転職サイト、電子カルテシステムの開発など多岐にわたります。2024年4月にはエムスリーテクノロジーズを設立し、グループ内でのエンジニアサポートやCTO派遣のようなサービスを展開しています。エムスリーはギークカルチャーが根付き、生成AIを活用した小規模チームでの意思決定と成果を重視し、生産性の高い組織を目指しています。

竹内：
RAKSULは、テレビCMの影響で印刷業のイメージが強いかもしれませんが、印刷事業を中核に、内製での立ち上げとM&Aを通じてさまざまな領域で事業・サービスを展開しています。2009年に設立され、東証プライムに上場し、今年で15周年を迎えます。

エンジニアリングカルチャーはエンジニアだけでなく、事業責任者や担当者にも広がり、問題解決に向けた高い「解像度」を重視しています。このカルチャーにより、複雑な業界ドメインに挑戦し、効率的で革新的な解決策を提供しています。特に非効率な部分を見つけ出し、ディスラプションを通じて成長を遂げています。

ーープロダクト開発におけるROIについて質問させてください。両社では、「R（リターン）」と「I（投資）」どちらの優先度が高いですか？

山崎：
エムスリーでは、ROIを考える上でR（リターン）の最大化に重点を置いています。プロダクトの開発効率を評価する際、最終的な売上の規模が非常に重要ですしリターンが大きければ、その他の要素も補うことが可能です。このため、私たちは常に高いリターンを目指すことに注力しています。

医療業界は非常に多くの、優先順位が明確でない課題を抱えておりますが、エムスリーはその中で、多くの人が”お金を払ってでも”早期の解決が望まれる課題にフォーカスしています。したがって、投資のリターンが十分に大きいかを最初に確認するようにしています。

また、利益を最優先する当社の方針において、ROIは売上高からコストを差し引いた利益として計算されます。コストが固定されている場合、売上が増加すればそれに比例して利益も増大します。


竹内：
R（リターン）に関して、山崎さんと共通の見解がある中で、エンジニア組織の人手不足について触れたいと思います。
私自身、この業界で20年以上の経験がありますが「人手が余っている」という状況に遭遇したことはありません。限られたエンジニアリソースや経営資源の適切な配分が極めて重要です。

つまり、I（投資）をどれだけ小さく抑えるかが鍵となります。投資を抑えることで、より多くのプロジェクトに取り組む機会を増やすことができます。たとえば、10人のチームで1つのプロダクトを立ち上げる場合と比較して、5人で立ち上げた場合、同じ人員で2つのプロダクトを立ち上げることが可能ですよね。

山崎さんがお話されたリターンの重視と同様に、投資を最小限に抑えることで、プロジェクトの数を増やし、成功の機会を広げることができます。打率が100%ではない以上、打席に立つ機会を増やすことが、結果的に大きなレバレッジを生み出すと考えています。

山崎：
なるほど。仰る通りですね。エムスリーでは、現在110人のエンジニアが20チームに分かれており、約50のプロダクトを抱えています。このため、すでに人手が限られており、さらに増員する余地がありませんので……竹内さんのお話に非常に共感しました。

ーー竹内さんは山崎さんのリターンに対する考え方についてどう思いますか？

竹内：
結局、私たちは営利企業なので、利益を出すことが最終目的です。開発の効率も、それが最終的に収益につながらなければ意味がない。営利企業としては、利益がなければ従業員に適切な報酬を支払うこともできません。ですから、リターンが高いプロジェクトを優先する必要があります。

難しいのは「どれくらいのプロジェクトを選択するか？」です。リターン上位5つだけを取るのか、それとも上位10まで広げるのか。また、長期的な視点と短期的な視点の両方が必要です。そんな中、RAKSULでは8月から新たな会計年度が始まりましたが、人手不足の中でリターンの高いプロジェクトから資源を割り当てています。

新規事業と既存事業で「R」と「I」の優先度は変わるのか

ーー新しい事業を立ち上げる際のマネジメントや開発担当の視点から、ROIについてどのようなアプローチを取るか教えてください。また、新規事業と既存事業で異なる視点がある場合、その違いについても詳しく教えていただけますか？

竹内：
新規事業と既存事業では目線が異なります。特にソフトウェアそのものが価値であるSaaS事業には、開発投資を惜しむべきではないと考えています。一方、トランザクションベースの事業やカスタマイズECプラットフォームでは、古くなればなるほど技術的負債が蓄積しやすいため生産性はどうなのか、という疑問が湧きますよね。そこには徹底的な計測と可視化が必要になってきます。実際、今年2月にRAKSULに私が参画した際、古いコードベースの改善が必要だと感じました。

山崎：
R（リターン）の優先度が高い点に加え、I（投資）も重要な議題ですよね。私は、新規事業の立ち上げ時の、理想的なチーム構成は、プロダクトマネージャー1人、プロダクトデザイナー1人、QA（Quality Assurance）1人、エンジニア4人の“マジックナンバー７”が最適だと考えています。調整するとしても7±2。SI業界などで過去には大規模チームでプロジェクトが進行していましたが、現代のモダンなプロダクト開発の現場では、基本的にはこの小規模チームで抑えます。

このようにI（投資）を固定して、これらのチームがどれだけ大きなリターンを総和として生み出せるかが鍵となります。 これはあくまでプロジェクトの立ち上げフェーズ。成長フェーズでは戦略が異なります。MVPが完成し、PMF（プロダクトマーケットフィット）を達成した後のスケールフェーズでは、営業スタッフの投入や売上の増加により、さらなる開発が必要になります。

この時に、アクセルを全開にする際、I（投資）をどれだけ投入するかは、開発組織のリーダーやCTO、CEOによって決定されます。PMF達成まではマジックナンバー7が適切ですが、その後の成長段階での資源管理が肝心になります。

竹内：
PMFは非常に重要で、その地点に到達するまでの過程は困難が伴います。初期の想定から外れたり、市場で受け入れられないことも。それによって何度も戦略を変更する必要があると思います。
そんなグロースフェーズにおいては、I（投資）とR（リターン）をどうコントロールしていくかを議論したいです。私は、極論、短期は殺してでも技術的な負債をできるだけ少なくし、中長期的にスループットの最大化を目指すべきだと考えています。エムスリーでは、この点をどのようにコントロールしていますか？

山崎：
これは非常に難しい問題ですよね。グロースフェーズにはエンジニアのリソースを多く割り当てたい、というのが現場からの意見も含め、理想ではあります。ですが、他の事業との並行が必要なため、すべてにリソースを割り当てるわけにはいきません。PMFを達成した後も次の事業が待っており、会社として全力を尽くす環境が整っていればそうするのですが、次の事業が全体的に利益を生む可能性もあります。そのような判断は本当に難しいなと感じています。

スモールチームでグロースフェーズを乗り切る方法

竹内：
私自身、プロダクト開発には特別な才能があるわけではないので、事業計画に基づくリターンを信じ、タイムトゥマーケット（製品化するまでの時間）を適切に管理することが重要だと考えています。

山崎：
実際のところ、投資のタイミングが非常に難しいですね。特に、PMFを達成する前に過剰なI（投資）をしてしまうという課題があります。多くの企業が、PMFを達成する前にMVPの開発と同時に人員を増やし始めます。これは、PMF達成に多くの人員が必要だという誤解から生じることが多いですが、実際にはPMFが達成できなかった場合、投入したコストが無駄になり、結果的にR（リターン）が小さく、費用が膨大＝I（投資）が大きいという状況に陥ります。これが、生産性が悪い状態です。

要するに、I（投資）を行うタイミングが早すぎることです。ただし、これを遅らせすぎるという問題もあります。投資の増減をどのタイミングで行うかが鍵となります。このジレンマを解決するためには、無闇に投資を増やさないことが重要です。そのために私たちは、先ほどお伝えしたマジックナンバー7から9の範囲でチームを管理し、グロースフェーズを乗り切る方法を確立しています。

竹内：
実際、最初から最後までスモールチームで進んでいくことは可能なのでしょうか？

山崎：
PMFの質が高ければ、可能です。例えば、エムスリーデジカルは、クラウド電子カルテによって、オンプレミスとクラウドを含む電子カルテ業界で日本一の地位を確立しました。この成果を達成するまで、最大で8人のエンジニアという小規模なチームで取り組んできました。

I（投資）の導入に関しても、過剰に早期にリソースを増やすことは避けるべきであり、そのタイミングは非常に繊細な問題です。場合によっては、新しいプロジェクトについても考慮する必要があります。

そう考えて、エムスリーではスモールチームでのアプローチを採用しています。全体で110人のエンジニアが20チームに分かれ、平均して5～6人のチームでプロジェクトを運営しているような状況です。正直、足したいですが（笑）。

竹内：
率直な疑問として、もしフィーチャー（機能追加）リクエストが大量に来た場合、どのように対応しますか？

山崎：
PMFの質を高く保つことができれば、後続のステップもスムーズに進みます。PMFも段階的に進行しますよね。最初のアクセルを踏み始める頃のプロダクトがよくできており、ユーザーの心を掴んでいると、その後のプロダクト開発は比較的楽に進むことが多いです。特に医療業界では、小さいイノベーションでも大きな影響を与えるため、初期段階での成功が重要です。

エンジニアは事業KPIにどのように向き合うか？

ーーいよいよ本題に移ります。エンジニアが事業KPIにどう向き合うかについて、RAKSULさんの考えをお聞かせください。

竹内：
まず、私たちの「解像度」を大切にする文化について説明しますね。たとえば、印刷EC「ラクスル」では、印刷業界の複雑なビジネスプロセスを解像度高く理解することを重視しています。単純なECプラットフォームと異なり、私たちは非カスタマイズ状態からカスタマイズを行い、ラベル印刷から配送に至るまでの一連のプロセスを管理しています。

このプロセスを深く理解することで、ペインポイントを特定し、どのような改善がR（リターン）を生むか、構造変革や非連続的成長をどう引き出すかを見極めます。

この理解を基に、エンジニアの目標設定にOKR（目標と主要結果）を導入し、その遂行の度合いをエンジニアの評価に反映しています。これにより、エンジニアがビジネスの成長において、事業部メンバーと同等の責任を持つようになります。

このアプローチがRAKSULの強みであり、私たちの業務が面白い理由の一つです。しかし、この方法を過度に推進すると、近視眼的になってしまい、プロジェクトを急ぎ足で進めるという弊害も生じることがあります。このバランスを保つために、OKRを設定し、それを評価プロセスにも組み込むようにしています。

山崎：
我々も竹内さんのお話と似た取り組みをしていますが、エンジニアが事業KPIにどう向き合うかという点では、より積極的に関与しています。エムスリーでは、エンジニアの生産性や社内での評価は、その事業への貢献度に直結しています。エンジニアがいることで事業が成り立っており、その重要性を全員が認識する必要があります。エンジニアの主な目標は、明確に事業の達成です。

しかし、エンジニアが事業成果だけに直結すると、エンジニアリングに集中できず、開発に向き合えなくなるのではないかという声も、エンジニアからはあがっていたりします。エムスリーでは、エンジニアの評価と役割設定において2つの工夫を行っています。

一つ目は、個人個人のエンジニアの評価の工夫です。エンジニアの評価の約20%を直接的な事業成果で行っています。例えば、電子カルテチームでは、年間の電子カルテの販売数を評価指標にしています。残りの80%は、その事業目標を達成するための、新機能の開発、リリース作業、技術負債の返済、セキュリティの強化などが含まれるエンジニアリング活動などに基づいて行います。

二つ目は、事業ごとにいるチームリーダーの責任を設定することです。これらのリーダーは事業の成果に直接責任を持つCTOのような役割を果たし、我々中間層の介入を最小限に抑えることで、事業と密接に連携しています。このアプローチにより、社内には複数のCTOが存在しているような形になり、エラスティックな組織が自己組織化を促進していると思います。

竹内：
私たちのエンジニアリングカルチャーと非常に似た価値観ですね。事業が広範囲にわたると、その深い理解や「解像度」は現場のエンジニアでなければ把握できないことが多く、マネージャーにはその詳細を理解することが難しいです。

RAKSULでは、各事業部に独自のCTOを設置しています。例えば、印刷事業や広告事業など、それぞれの事業に特化したCTOがおり、このアプローチによって役割が明確にされています。事業部ごとのCTO配置は、各事業のKPIを管理し、それを目標にOKRやその他の事業KPIを組み込むことで、事業の成功が直接的に反映されるよう努めています。

ーー目標やOKRの中で事業KPIを持つようにされていますが、現場のエンジニアが「とはいえ、直接的に事業KPIに貢献するのが難しい」と感じる瞬間があった場合、どのようにコミュニケーションをとりますか？

山崎：
各事業部にCTOを設置し責任を持たせることで、エンジニアの中でも事業に関する会話が生まれるため、うまくコミュニケーションがとれているとは思います。現在のエンジニア組織において、マルチプロダクトの概念が普及する中で、各チームにCTOを配置する流れが強まっていると思います。

以前はこの役割をテックリードやエンジニアリングマネージャーと呼んでいましたが、CTOという肩書タイトルを与えることで、よりトータルな成果に対する責任を持たせることが可能になると思っています。これが組織全体の生産性向上に寄与する重要な要素になっています。さらに、チーム内でもコミュニケーションが起こることにより、エンジニアの意識が高まり、リターンの意識も促がされます。

エンジニアの事業視点を深めるための工夫

ーーより具体的に、エンジニアが事業視点を深めるための工夫を教えてください。

竹内：
「事業視点を深めるには、責任を持たせることが非常に重要」という点、私も同意します。さらに、事業の構造を正確に理解し、何がその事業を持続可能なものにするのかを明確に彼らに把握してもらうことも必要です。私たちは、開発責任者がこれらの点をしっかりと理解しているかどうかを確認するため、事業責任者とのコミュニケーションの質を常にチェックしています。

山崎：
私はプロダクトマネージャーの役割を非常に重要だと考えています。この理由は、ビジネスサイドとエンジニアリングサイドの間の潜在的な対立を解消するためです。単にビジネスサイドの指示に従って行動するだけでは、事業は成功しません。ビジネスサイドの意見が常に正しいとは限らないからです。

そのため、プロダクトマネージャーには重要な中間者として機能してもらいます。彼らはビジネスサイドの要求をエンジニアリングの観点から解釈し直し、より実行可能で効果的な解決策を提案することで、生産性を向上させます。エンジニアに直接ビジネスの目標を押し付けるのではなく、プロダクトマネージャーが橋渡しとして機能することが、プロジェクトの成功にとって非常に重要です。 ROIのI（投資）を小さくするには数値にこだわる

ーーROIのI（投資）を小さくするために工夫していることはありますか？

竹内：
ROIの「I（投資）」を効率的に管理するためには、非常にシンプルなのですが「計測すること」です。例えば、エンジニアがオペレーションに40%の時間を費やしているとします。これを20%削減することができれば、その分の時間を新機能の開発に再分配できますね、と、効率化の努力を数字で示すことが、投資の最適化には極めて重要です。

山崎：
私は「採用基準を高めること」が非常に重要だと考えています。採用基準を上げることによって、エンジニアの全体的な能力が向上し、それに伴い、チームに新たなメンバーを加える際にもより慎重になります。エムスリーでは、設立から24年間でエンジニアの数が110人に留まっているのも、この厳しい採用基準が理由です。そもそもI（投資）がないのなら、I（投資）をうまく使うしかなくなるので。

最後に

最後までお読みいただきありがとうございました。
RAKSULは、テックカンパニーとして様々なイベントを開催・登壇しています。ぜひ今後のイベントにもご参加ください！
connpassグループのメンバー登録、Xフォローもよろしくお願いします！

新卒1年目だけどRubyKaigi2024に飛び込んできたレポート

こんにちは！24新卒の久冨(@tomi_t0mmy)です。ラクスル事業本部でサーバーサイドエンジニアをしています。

写真の1番左の、風で前髪が吹っ飛んでいるのが私です。テックブログ用の大事な写真に限ってネタみたいな写真になってしまった……

今回参加したRaksulメンバー。左端の私を見た先輩に「頭から木が生えてる」と言われました

さて、5/15〜5/17に沖縄でRubyKaigi2024が開催されました！私は学生時代からRubyをメインで使っていて以前から参加してみたいと思っていたので、入社してまだ1ヶ月半ですが思い切って行ってきました！今回はそのレポートと感想をお伝えできればと思います。

RubyKaigiについて

RubyKaigiとは、年に一度、世界中のRubyistが集まりRubyについて語り合う国際カンファレンスです！今年は世界各地から約1400人のRubyistが参加していたようです。めちゃくちゃ多い！

RubyKaigiの大きな特徴として、Rubyを使っている人ではなくRubyを作っている人によるセッションが多い、ということが挙げられます。Rubyのコアな部分を知り尽くしている人たちが、この1年での成果やRubyの未来について熱量高く語ってくれます。そのため、内容を理解するためにはある程度の前提知識を必要とするセッションが多いです。
事前に各セッションの概要を確認したところ、全く聞いたことのなかった概念がたくさんありました……！先輩方と予習はしましたが、それでも理解できるか不安な気持ちを抱えたまま当日を迎えました。

また、たくさんのRubyistと交流できることもRubyKaigiの魅力の一つです。オフィシャルパーティーだけでなく、スポンサーブースやイベント、「知り合いの知り合い」繋がりなど、普段話せない人と話せる機会が本当に多くあります。
私はRubyKaigi初心者であり、オフラインイベント初心者でもあるので、「うまく話せるかな……」と緊張していました。

実際に参加したコンテンツ

期待と不安の入り混じった気持ちで迎えたRubyKaigiですが、開催期間中はコンテンツ盛りだくさんで忙しい3日間になりました！ここからは期間中に参加したコンテンツについて紹介していきます。

セッション

メインイベントである、Ruby開発者の方々によるセッションです！ここでは私が面白いと感じたセッションを3つ紹介させていただきます。

Writing Weird Code

rubykaigi.org

TRICK2022（超絶技巧Ruby意味不明コンテスト for RubyKaigi）において金賞を受賞されたぺん！さん(@tompng)によるKeynoteセッションです。タイトル通り、”変なコード”がたくさん紹介された面白いセッションでした。

序盤では比較的短い”変なコード”が多く紹介されました。例えば、このコードはただ%を適当に並べただけのように見えますが、ちゃんと実行できます！

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%という記号にはいろんな意味があります。まず文字列リテラルの%記法では以下のように記述することができます。

%!string! == "string"

この!部分には任意の非英数字を使うことができるため、以下のようになります。

%!s! == "s"  %%s% == "s"  %%% == "" 

また、Stringクラスには%メソッドがあり、以下のようになります。

"RubyKaigi %d" % 2024 #=> "RubyKaigi 2024"
"" % "" #=> ""

よって、

%%%%%%% == "" % "" 
%%%%%%%%%%% == "" % "" % ""

となり、4n+3個の%を並べたものはsyntax validとなります。

他にも、いろんな記号を繰り返したコードやヒアドキュメントや正規表現の記法を用いたコードなど、一見しただけでは分からないテクニックが本当にたくさんあることを知りました。

このセッションで、いかにRubyが自由で奥深い言語なのかを少し感じられた気がします。また、このようなコードを書けるようになって初めて見つけられるバグがあったりして、仕事で役に立つこともあるというお話を聞くこともできました。

そして後半では、ぺん！さんがRubyKaigi2024のために作ったTRICKyなコード6作品（多い！凄い！！）を紹介していただきました。どれも本当に面白い作品でしたが、個人的にはMost Floralが「画像って実行できるんだ……」と感動しました。作品のコードは以下のレポジトリで公開されているので、ぜひ手元で動かしてみてください！

github.com

Unlocking Potential of Property Based Testing with Ractor

rubykaigi.org

こちらはMasato Ohbaさん(@ohbarye)によるRactorを用いたproperty based テストについてのセッションでした。Ractorとは、Ruby3.0で導入された並行処理のための機能です。現時点ではユースケースが少ないと考えている人が多そうなRactorですが、このセッションでは「property based テストがいいユースケースになるのではないか」と考え、その仮説を検証した結果が説明されています。
私はproperty based テストとRactorの両方ともそれほど詳しくありませんでしたが、登壇者の方の説明が分かりやすく非常に勉強になったセッションでした。

まずproperty based テストについての説明がありました。例として、Ohbaさんが作成したPBTというツールのReadmeのコードを元に説明します。以下のsort関数がテスト対象であるとします。

def sort(array)
  return array if array.size <= 1
  pivot, *rest = array
  left, right = rest.partition { |n| n <= pivot }
  sort(left) + [pivot] + sort(right)
end

よく用いられるのはexample based テストで、これは入力値とそれに対して期待する出力値(example)を設定し、実際の出力値が期待する値と一致するかを確認するものです。RSpecで書くと以下のようになります。各it句内でそれぞれのexampleが記述されています。

# Example Based Test with RSpec
RSpec.describe 'sort method' do
    it 'sorts an empty array correctly' do
        expect(sort([])).to eq([])
    end
    
    it 'sorts an array with a single element correctly' do
        expect(sort([1])).to eq([1])
    end
    
    it 'sorts an already sorted array correctly' do
        expect(sort([1, 2])).to eq([1, 2])
    end
    
    it 'sorts a reverse sorted array correctly' do
        expect(sort([2, 1])).to eq([1, 2])
    end
    
    it 'sorts a randomly ordered array correctly' do
        expect(sort([2, 3, 1])).to eq([1, 2, 3])
    end
    
    it 'sorts an array with negative numbers correctly' do
        expect(sort([0, -1, 2, -3, 3, 1, -2])).to eq([-3, -2, -1, 0, 1, 2, 3])
    end
end

example based テストは、理解や記述は比較的容易であり、期待通りに動いているかを確認しやすいという長所がありますが、エンジニアが予測しているバグしか見つけられないという短所があります。

これに対して、property based テストはexampleではなくテスト対象が満たすべき性質(property)を記述し、それに基づいて膨大な量のランダムな入力値を生成して行うテストです。result.each_con(2) 以下でpropertyが記述されています。

# Property Based Test with PBT
Pbt.assert do
  Pbt.property(Pbt.array(Pbt.integer)) do |numbers|
    result = sort(numbers)
    result.each_cons(2) do |x, y| 
      raise "Sort algorithm is wrong." unless x <= y
    end
  end
end

property based テストはより多様な入力値を試せるので想定外のバグも見つけやすいですが、学習コストの高さとテスト実行にかかる時間の長さが欠点となります。

example based テストとproperty based テスト、どちらも一長一短があるので、ケースによって使い分けるのが良いとされています。

さて、このproperty based テストですが、生成されるそれぞれの入力値に対するテストは互いに独立しているので、Ractorのユースケースの候補として良いのではないかとOhbaさんは考えたそうです。Ractorで上手く並行に処理出来れば、property based テストの欠点である「実行に時間がかかる」という欠点を改善することが出来ます。

PBTはこの仮説検証のために実装されました。このツールは、property based テストを簡単に実装したり、property based テストの並行処理を可能にするものです。セッションの中では、このツールの設計の詳細や特徴について詳しく説明されていました。

このツールを用いた検証では、テスト対象のタスクがCPU-boundかつRactorで動かせるという条件を満たしていればRactorを用いた方が実行時間は速くなるが、それ以外の場合ではsequentialに実行した時の方が早い、という結果が出たそうです。

property based テストにおける有用性としてはまだ限定的なところがありそうですが、Ractorのユースケースを広げるための知見となる面白いセッションだったと感じています！

Namespace, What and Why

rubykaigi.org

こちらはNamespace on readという機能をRubyに提案・開発しているTagomoriさん(@tagomoris)による、Namespace on readの解説セッションでした。まだRubyに取り込まれていない機能ということで、未来のRubyがどうなるのかを想像させるワクワクしたセッションでした。

Namespaceとは、アプリケーションやライブラリを閉じ込めた、独立した”空間”のことです。スペース内での変更を隠し、スペース外から見えないようにする機能を持ちます。

Namespaceはコードの名前や定義、バージョンの衝突を避けるために必要な概念です。

名前の衝突

開発現場では名前の衝突を避けるためにFoo::Bar::Bazのように構造化した名前がよく使われます。しかし、Topレベルの名前として使いたい名前が被っている場合も多く、衝突を避けるのが大変になります。

定義の衝突

オプションの設定やグローバル変数の中身が意図せず書き換えられてしまい、挙動が変わってしまうことがあります。また、モンキーパッチが全体に影響してしまうことも考えられます。

バージョンの衝突

ライブラリの依存関係において、同じライブラリの別バージョンを使いたい場合が考えられますが、Namespaceのない現状では困難です。

Namespace on readの機能が導入されればこのような課題が解決されるため、期待されている機能の一つだと言えるでしょう。

また、まだjust ideaの段階とのことですが、tagomoriさんの想像しているNamespaceの未来についても語ってくださっていました。
例えば、各アプリケーションをNamespaceに入れれば、複数のアプリケーションを一つのプロセスで動かしてモジュラーモノリスっぽいことができるかもしれません。また、バージョンの衝突が起きた場合も片方をNamespaceに閉じ込めることで解決できそうです。その他、究極的には、全てのライブラリをNamespaceで管理できるのではといったアイデアもありました。

他にも、なぜ”on read”なのかという話や実際にNamespaceをどう実装するかという話など、詳しく説明されていました。私にとっては難しい話もあり全てを理解するのは困難でしたが、未来の機能についての話はとても面白く、想像膨らむ楽しいセッションでした！

スポンサーブース

セッション以外の大きなコンテンツとしてスポンサーブースがあります。たくさんの企業さんがRubyにまつわるクイズやコード課題、コードレビュー企画などをやっており、エンジニアなら思わず足を止めてしまうようなコンテンツがたくさんありました！

こちらはMoney Forwardさんのコードレビュー企画です。

#rubykaigi
皆さんからいっぱいレビューコメントいただきました。
ありがとうございます！ https://t.co/AUQ4xUiFHt pic.twitter.com/h8pCImUk8g

— Money Forward Developers (@moneyforwardDev) 2024年5月15日

こちらはFindyさんのブースの様子で、私もRubyクイズに挑戦させていただきました。

Findyブース完成！
1F奥のかなり暗いところにあるんですが、みんな見つけて遊びにきてください🥺Rubyクイズとアンケートとってます！
そしてしおりが新しくリニューアル！みんなもらいにきてね✨
#rubykaigi pic.twitter.com/UevXDGRHAl

— まっきーㅣFindy DevRel (@ayamakkie) 2024年5月15日

その他にも、オリジナルグッズが当たるガチャガチャやタイピングゲームなど、どのブースも力を入れて運営されていました。いろんな会社の事業や取り組みについて楽しく勉強できましたし、「ラクスルでも工夫を凝らしたブースコンテンツを作りたい！」とワクワクしました。

イベント

rubykaigi.org

RubyKaigi開催期間は各社によるイベントも盛んに行われています。今回私は、オフィシャルパーティーと3つのイベントに参加してきました。

RubyKaigi 2024 Official Party

こちらはオフィシャルのパーティーでたくさんの人で賑わっていました。会場は海の近くで景色が最高でした！

オフィシャルパーティー会場から見える海

BBQを楽しみつつ、同じテーブルの方々と各々が開発しているプロダクトや使われている技術についてざっくばらんにお話ししました。参加人数が多い分、本当に様々な企業の方とお話しできてとても面白かったです！

Timee Drinkup at RubyKaigi 2024

timeedev.connpass.com

会社の先輩が参加するとのことで、その方に着いていく形で参加しました！Drinkupイベントも初参加な私は、「ずっとRubyについて語っている会なのかな…」と少しビビっていましたが、社外の方との交流の場として楽しむことが出来ました！Rubyの話に限らず、コミュニティ活動についてのアドバイスをいただいたり、Timeeさんの取り組みについて色々お話を伺うことができて、とても有意義な会でした！

Findy Drinkup at RubyKaigi 2024

findy.connpass.com

前日のDrinkupイベントがかなり楽しく、「他のイベントも参加したい！」と思って急遽参加を決めました。当日急に決めたのでぼっち参戦になり、話し相手を見つけられるか心配していましたが、ベテランの方も含めて皆さん優しく話しかけてくださいました。他の人をどんどん紹介してくださったりして、繋がりが増えてとても嬉しかったです！

また、自分のキャリアについての相談に乗っていただいたりRubyの楽しさを語っていただいたりと、前日のイベントとはまた違った良い話をたくさん聞くことができて、思い切って参加して良かったと思いました！

RubyKaigi 2024 After Party sponsored by mov

connpass.com

こちらは国際のれん街の1Fと2Fを貸し切っての大規模なアフターパーティーでした！参加人数がかなり多かったこともあり、基本的には一緒に参加した先輩方とRubyKaigiを振り返っていましたが、途中から他の会社の方とも交流できました！
そして、なぜか初めましての人とラーメンを食べにいくイベントが発生し、「これがRubyKaigiか〜〜（褒めてる）」となりました。こちらもとっても楽しかったです！

行ってみての感想

分からなかったけど楽しい！

予習してから参加したとはいえ、すべての参加セッションの内容をその場でしっかり理解することはできませんでした。

が、それでもRubyKaigiは楽しい！！！

内容がわからなくても登壇者の方々のRubyへの愛が伝わってくるし、Rubyが好きな人同士で盛り上がっている雰囲気を感じるだけでも本当に楽しかったです。

また、スポンサーブースや他のRubyistとの交流など、セッション以外のコンテンツも想像していた以上に豊富でかなり楽しめました。

新卒1年目でも、Ruby初心者でも楽しめます！！

Rubyがもっと好きになった

私がRubyを使い始めたきっかけは、学生時代にインターンでお世話になった会社で使われていたことです。つまり、たまたま使うことになったというだけでした。そのため、「書きやすいな〜」と思ったり、他の言語との違いを考えることはあっても、「Rubyが好き！」というほどの強い気持ちがあるわけではありませんでした。

しかし、Rubyの良さをたくさんのRubyistに語っていただき、「Rubyって楽しい言語だな」と感じるようになりました。そして「私も輪に入って語れるようになりたい！」と心から思えるようになり、今後の勉強のモチベーションアップにも繋がりました。（ひとまずあなたの知らない超絶技巧プログラミングの世界を購入しました）

またRubyだけではなく、Rubyistのコミュニティもより好きになりました。イベントの参加経験があまりなかったため、初対面の方との交流に緊張していたのですが、とにかく皆さんあたたかい！！初心者の私にも優しく話しかけてくださってありがたい限りでした。

他社さんとの交流がいい刺激になった

スポンサーブースやアフターイベントでは様々な企業のエンジニアの方と交流でき、各社の事業や技術的な取り組みについても話すことができました。
いつもは会社の同僚や先輩方と話すことがほとんどなので、他社での取り組みを聞けたことはとても良い刺激になり、「ラクスルでもこんな取り組みをやってみたい！」とアイデアが膨らみました。

これまで社外の方との交流の機会はあまり作ってこなかったのですが、今後は定期的にオフラインイベントに出たり、情報発信やSNS活動を通じて交流していきたいと思います。

最後に

初参加でしたが、参加前に抱いていた不安な気持ちが全て吹っ飛ぶような、とても刺激的で楽しい3日間になりました！RubyKaigiの運営の方々、スポンサー各社の方々、話して下さった方々、色々教えてくださった会社の先輩方などなど、皆様のおかげです。本当にありがとうございました！！

まだまだひよっこエンジニアではありますが、これからRubyをもっと楽しんで勉強し、今よりもさらにパワーアップした上で、来年も必ずや参加しようと思います！

【イベントレポート】Findy主催「リアーキテクチャにおけるアンチパターンへの向き合い方と次なる挑戦」に登壇しました

6月18日、ファインディ株式会社主催のオフラインイベント「リアーキテクチャにおけるアンチパターンへの向き合い方と次なる挑戦」が開催されました。ラクスル株式会社が協賛し、ラクスル事業本部CTO岸野・ソフトウェアエンジニア吉原が登壇しました。
本記事では、その内容をレポートします！

登壇者

ラクスル株式会社　ラクスル事業本部CTO　岸野 友輔
ラクスル株式会社　ラクスル事業本部ソフトウェアエンジニア　吉原 哲

オープニング

RAKSULについて

会の冒頭、ご挨拶を兼ねて、RAKSULグループCTO竹内より会社紹介をいたしました。

竹内：
RAKSULは印刷事業から出発し、現在はECマーケットプレイス、SaaS、BPO（ビジネスプロセスオペレーション）など、さまざまなサービスを展開する、「産業構造の変革者」です。今後は主にBtoB受発注のプラットフォーマーとして、さらなる事業領域の拡大を計画しています。

RAKSULの技術文化は、「Go Beyond」「Think Architecturally」「Make it Scalable」の3つの理念に基づいています。
これらの理念のもと、ベトナムにも開発拠点を持ち、グローバル展開も進めています。各事業の自由な発展を重視しつつ、スケーラブルな仕組みを作ることを目指しています。また、毎年社内でハッカソンイベントを開催するなど、テクノロジーを重視する文化も根付いています。

今後もテックの側面から、「テクノロジーでどのように会社・ビジネスをドライブしていくのか」を考え、事業成長を続けていく文化を大切にしながら、さらなる発展を目指していきます。

LT

ラクスルからは2名が登壇し、リアーキテクチャの取り組みについて発表しました。

LT1 岸野

「リアーキテクチャのアンチパターンとその対策〜ラクスルの場合〜」

自己紹介

岸野：
私は新卒でラクスル株式会社に入社し、長らく印刷事業の開発に携わってきました。M&Aでグループインした事業「ダンボールワン」の開発組織の立ち上げも経験し、昨年の8月頃からは、ラクスル事業本部CTOとして、共通基盤プロダクトの構築を推進しています。


岸野：
本日は、前回5月22日に開催されたオンラインイベントで話しきれなかった「ラクスルが踏んでしまったアンチパターン」についてお話します。
（前回の内容はこちらのイベントレポートをご覧ください）

ラクスル事業について

岸野：
ラクスルは、印刷EC事業からスタートしました。現在は印刷にとどまらず、ノベルティ、ダンボール、アパレルなど多角的にサービスを展開しています。

アーキテクチャの変遷について

岸野：
2013年に印刷EC「ラクスル」をリリースしました。当初はPHPで作られたモノリシックなシステムとデータベースがあるだけといった、シンプルなアーキテクチャでした。

2015年に既存の印刷ECサイトを拡張する形で、集客支援サービスを開始しました。コンテキストが大きく異なる商品を、既存のシステム・同一のオペレーションシステムで無理矢理寄せて進めていくことで、開発の限界が露呈し始めたのはこの頃になります。そこで、将来的なシステムの拡張性を見越して機能の切り出しとして一部マイクロサービス化を開始しました。

この状況に加えて、「ノベルティ」や「アパレル」など、既存の印刷サービスのコンテクストから離れたサービスやシステム開発の要望が上がってきました。しかし、ラクスルの商品は商品特有のカスタマイズ性が高く、これ以上は、印刷ECの基盤ではシステム拡張は難しい状況でした。そのため、新しいサービスを別プロダクトとして構築していくことを決めました。 結果、新規プロダクトの立ち上げ速度や改善速度の向上に寄与したことから、現在はこの進め方がスタンダードになっています。

さらに、「ダンボールワン」「ハンコヤドットコム」のグループインが続きます。当初、M&Aを想定した設計にはなっていなかったため、各事業間のシナジー創出の土台として、基盤システムをしっかり独立させていくことが重要でした。

まだ道半ばですが、共通基盤として決済機能や認証機能を共通化する開発を進めることで、結果として、高いレベルでシステムの拡張性を保つことができています。

モノリスからマイクロサービス化への落とし穴

岸野：
マイクロサービス化の過程で経験した、データベース共有というアンチパターンについてお話しします。 前提として、モノリシックなシステムからマイクロサービス化を進める際には、アプリケーションを先に分けるパターンやデータベースを先に分けるパターンなどがあります。

ラクスルは、アプリケーションを先に分けるパターンを選択しました。この方法は、短期的には効率的でマイクロサービス化の恩恵を受けやすい一方、データベースを共有したままにすると、テーブルスキーマを変更する際に、すべてのアプリケーションで同期的にリリースする必要があるなどのデメリットがあります。


岸野：
ラクスルは、初期段階において、PHPで作られた旧システムを、Rubyで作られた新システムに切り出して、マイクロサービス化を進めてきました。この過程で、EC機能本体は新旧システムが混在する状態になりました。また、印刷発注APIや印刷コスト計算システムをそれぞれ本体から切り出してはいたものの、それらも同じデータベースを共有していました。

これらの複数のシステムが同じテーブルを参照してしまうなど、システムの切り出し方が不完全であることによる課題が生じました。

課題への向き合い方

岸野：
課題克服への取り組みとして、責務分割を再考し、各マイクロサービスが担うべき機能を明確に定義しました。具体的には、印刷発注に関わる機能を基盤システムとして切り出すリアーキテクチャを進めました。これにより、本体の印刷ECサイトだけでなく、集客支援など他のサービスでも、共通の印刷発注機能を利用できるようになりました。

この取り組みは、ラクスルが過去に行った「印刷発注API」や「印刷原価計算機能」などを切り出した経験を踏まえ、より効率的で効果的な方法を検討したものです。こういったマイクロサービス化で得られた知見を活かし、システム全体の理解と運用効率の向上を目指しています。

まとめ

岸野：
当時、拡張が難しいレガシーコードではなく、新しいコードベースでマイクロサービス化を進めた判断は正しかったと考えています。短期的なリリースを可能にし、特にベンチャー企業にとって重要なスピード感を担保できたことは大きな成果です。

しかし、データベースを共有したままにしてしまったことは、マイクロサービス化の落とし穴となりました。これにより、多重メンテナンスの発生など多くの問題を引き起こすことになりました。これは、マイクロサービス化のゴールを明確に設定せず、段階的なステップを踏まずに進めてしまったことが原因です。

したがって、マイクロサービス化を進める際には、ゴール設定が重要であり、あるべき姿を描いてステップを明確にすることが必要だという教訓を得ました。

これはほんの一例ではありますが、マイクロサービス化を検討している企業の皆さまにとって、私たちの取り組みが参考になれば幸いです。

LT2 吉原

「ラクスルのマイクロサービス移行：アンチパターンとその対策」

自己紹介

吉原：
私は、18年間にわたりアプリケーション開発やプラットフォーム開発に携わってきました。2024年1月にラクスル株式会社に入社し、現在は開発基盤部のプラットフォーム開発・SREを担当しています。

事業環境の変化について

吉原：
ラクスルは、印刷事業を中核に、内製での立ち上げとM&Aを通じてさまざまな領域で事業・サービスを展開しています。近年はそれらに加え、PoCでの新サービス検証、海外展開など、事業の多角化が加速しています。

そうした事業環境の変化に対応するため、システムの繋ぎこみやすさや既存プラットフォームの再利用性が求められています。

システムが抱える課題について

吉原：
現在、システムが抱える課題は大きく二つあります。
一つ目は、技術的負債です。システムが完全にモノリシックな構造から移行できておらず、旧技術スタックであるPHPやその他のレガシーな技術で構築されたコアシステムが多数残存していることです。さらに、複数のアプリケーションが同じデータベースを共有しているため、同じ処理が重複して実装されています。これらの問題が複合的に作用し、印刷ECシステムへの依存が、分散モノリス状態に陥っています。

二つ目は、メンテナンスの不足です。例えば、Kafkaのメンテナーが不在であるため、システムの維持管理や問題発生時の迅速な対応が難しくなっています。Kafkaの必要性について再評価し、もし必要がなければよりシンプルなRPCなどに移行を検討することが求められます。また、特定のエンドポイントのパフォーマンス不足も課題であり、アクセスが集中した際に全体的な影響を及ぼす可能性があります。

課題へのアプローチ

吉原：
それらの課題に対する私たちのアプローチは次の4つです。

まず第一に、コア部分のリファクタリングです。技術的負債を解消するために、負債解消の計画を立て、コアシステムの移行をPJ化し、徹底的に進めています。次に、開発基盤チームによる足回りの整備です。オブザーバビリティを向上させるため、開発基盤の整備に力を入れています。

さらに、プラットフォーム化とマイクロサービス化を進めています。決済や認証などの共通機能を切り出し、各サービスでの重複を排除することで、システム全体の効率性を高めています。最後に、アーキテクチャレビューです。全体最適の観点からシステム設計を見直し、将来の拡張性と持続可能性を確保しています。


吉原：
リアーキテクチャは「だるま落とし」のようなものだと考えています。最初から完璧なレイヤー構造でシステムが構築されていることは稀であり、多くの場合、段階的にレイヤーを構築し、抽象化していくことで、必要なロジックを切り出していく必要があります。

最初はシンプルな構造から始め、徐々に複雑なレイヤーを追加していくことで、システム全体を理解しやすくなり、必要な機能を効率的に実装できるようになります。

そして、各レイヤーが完成したら、リファクタリングを行い、不要な部分や非効率な部分を削ぎ落としていきます。これは、まさにだるま落としを倒していく過程に例えられます。不要な部分を的確に除去することで、システム全体のバランスが整い、より安定した構造へと進化していくのです。

個々のサービスを独立して改善するだけでなく、システム全体のアーキテクチャを俯瞰的に捉え、各サービス間の連携や依存関係を整理することで、より効率的で安定したシステム基盤構築を目指しています。

システムの繋ぎこみやすさ

吉原：
マイクロサービス化は重要な取り組みです。システムの密結合・モノリシックな実装の分解は、リアーキテクチャを進める中で、実装が難しい特徴を持っています。しかし、その実行によるメリットは大きいです。一番のメリットは、各コンポーネントが独立して、並行して開発ができることです。これにより、お互いが疎結合となり、チームがリニアにスケールしていく可能性が生まれます。

正しく切り出すことができれば、同じコンポーネントを他のサービスでも再利用でき、重複した開発を排除できます。例えば、素早く新しいサービスを立ち上げたり、M&A時に他のシステムとの統合を迅速化し、既存のシステムとのシームレスな連携をしたりすることが可能となります。

既存プラットフォームの再利用性

吉原：
各サービスはそれぞれ独立した状態で、再利用が可能です。それが、マイクロサービスとプログラミングのクラスが似ている点です。

正しく設計されたマイクロサービスは、そのサービス専用のデータベースを持ち、他のサービスへの依存性が少なくなります。これにより、汎用的にさまざまな場面で再利用できるという利点があります。また、インターフェースの定義も重要で、適切に設計されたインターフェースを通じて、他のサービスやシステムと効果的に連携することができます。
このようにして、マイクロサービスは中長期の運用で大きなコスト差を生む可能性があります。正しい設計により、運用コストを抑えつつ、柔軟性と再利用性を高めることができるのです。

最後に

吉原：
最後に、アーキテクチャレビューではどのような点を見ているかについてお話しします。
まず、システム全体をよく理解することが重要です。そのドメイン境界と切り方が適切か、各コンポーネントやサービスの責務が明確に分かれているかどうか、依存関係が適切に管理されているかを確認します。また、データが分離されているか、データの一貫性と整合性が保たれているかも確認します。

スパゲッティ建築の防止という点では、依存関係が複雑になりすぎていないか、保守性が高い状態を維持できるかを確認します。これらの確認を通じて得られた知見は、システム設計のナレッジとしてチーム全体でシェアしています。分散トランザクションの管理は複雑で難しいですが、そこをしっかりとサポートし、アーキテクチャ全体の設計に責任を持つことが重要です。

このようなアプローチにより、技術的な柔軟性とビジネスの成長を両立させるシステムを構築しています。

おわりに

最後までお読みいただきありがとうございました。
ラクスルは、テックカンパニーとして様々なイベントを開催しています。ぜひ今後のイベントにもご参加ください！
connpassグループのメンバー登録、Xフォローもよろしくお願いします！

【イベントレポート】Findy主催「アーキテクチャを突き詰める Online Conference」に登壇しました

5月22日、ファインディ株式会社主催のイベント「アーキテクチャを突き詰める Online Conference」に、ラクスル株式会社CTO竹内とラクスル事業本部CTO岸野がスピーカーとして登壇しました。 お話ししたテーマは「RAKSULに見るアーキテクチャの変遷〜複数サービス展開への道〜」。印刷EC「ラクスル」のアーキテクチャ変遷や、複数サービスを展開する中での全体像、そして事業戦略とのアラインについてご紹介しました。 本記事では、その内容をレポートします！

登壇者

ラクスル株式会社　CTO　竹内 俊治
ラクスル株式会社　ラクスル事業本部CTO　岸野 友輔

RAKSULについて

竹内： 「RAKSUL」と聞くと“印刷”のイメージが非常に強いと思いますが、私たちは「産業構造の変革者」であると自己定義をしています。印刷事業を主軸にしつつ、ノバセルや、ハコベル、ジョーシスなど他産業の関係会社も含め、グループ全体として様々な産業を変革していくための多様な事業を展開しているからです。 IR資料にも成長ドライバーとして記載がありますが、RAKSULでは下記の方針を打ち出しており、CTOとしてこれらを技術的に実現していく所存です。

• 新規事業の立ち上げを継続
• M&Aの推進
• 諸事業間でシナジーを生む

事業戦略とシステムとのアラインの難しさ

竹内： とは言え事業戦略の実現となると、簡単ではないのが現実です。

例えば、M&Aを行うとすると、完全に異なるソフトウェアスタックをグループ内に取り込むことになります。そのためには取り込む側に柔軟性が必要です。しかし「その柔軟性はシステムの中にあるか？」という現実との戦いが発生します。また他にも、既存案件で余裕がなく新規対応の時間が取れない状況や、財務全体の統合について、テック側のガバナンス問題...など多くの不安や疑問符が発生することになります。

RAKSULもこれまで何度も頭を抱えてきました。そこで、まずは創業から今までにどのようなアーキテクチャ変遷をたどってきたのか、印刷EC「ラクスル」を事例にお伝えしたいと思います。

ラクスル事業のサービス・アーキテクチャの変遷

1サービス・1プロダクト

岸野： ラクスル事業の主軸である印刷EC「ラクスル」は、2013年にリリースしました。10年以上にわたる運営の中で、少しずつアーキテクチャの形を変えながら稼働している根幹のシステムです。

複数サービス・1プロダクト

岸野： 印刷EC「ラクスル」を作った当時は単一サービスだったこともあり、簡単でシンプルなシステムでした。その後、2015年には既存の印刷ECサイトを拡張する形で、集客支援サービスを開始しました。

コンテキストが大きく異なる商品を既存のシステム・同一のオペレーションシステムで無理矢理寄せて進めていくことで、徐々に開発が苦しくなっていったというのが実態でした。

マイクロサービス化へ

岸野： そこで、マイクロサービス化を2つのレギュレーションで推進しました。

まず1つ目は、将来的なシステム拡張性を見越した機能の切り出しです。例えば認証機能や決済機能など、将来的に複数のサービスで展開されていく見込みがある機能から切り出しを行いました。そして2つ目は、既存システムの課題を解決するために、新しい設備の構築・移行です。

この時の反省点は、2つを十分な検討や準備をせずに進めてしまったことです。移行が完全ではない状態で進んでしまったことで、結果としてシステムの切り出しがスムーズでなかったり、データベースの一部が共有されてしまう事象が起こりました。

複数サービス・複数プロダクト

岸野： この状況に加えて、事業サイドから「ノベルティ」や「アパレル」など、既存の印刷サービスのコンテクストから離れたサービスやシステム開発の要望が上がってきました。

ラクスルの商品は、非常にカスタマイズ性が高い商品が多いのです。例えば印刷サービスで考えると、紙の厚さ・サイズ、質感...というように複数のパラメーターの中から商材を選んでいきます。ノベルティも同様に複数のグッズがあり、その中に各カスタマイズをご用意しています。

そのため、当初はこれまで同様、既存システムを拡張していく方針でしたが拡張の限界を迎えていたため、新しいサービスを別プロダクトとして構築していくことを決めました。

この判断は功を奏し、新規プロダクトの立ち上げ速度や改善速度が大きく向上する結果になったことから、現在はこの進め方をスタンダードとしています。

M＆A時のシステム側の難しさ

岸野： さらに、「ダンボールワン」・「ハンコヤドットコム」のグループインが続きます。

もともとM&Aを想定したシステムにはなっていない中で、顧客IDや決済の連携が求められることになり、ここでも多くの不安がよぎることになりました。

アーキテクチャの目指す姿

岸野： M&Aや新規事業の立ち上げはこれからも続いていくため、各事業間のシナジー創出の土台として、基盤システムをしっかり独立させていくことが重要です。まだ道半ばですが、今後も様々な事業戦略に耐えうる強固な基盤づくりを進めていきます。

事業戦略と足並みを揃えたアーキテクチャ

竹内： ここからは、後追いでアーキテクチャを考えていくのではなく、事業戦略と歩調を合わせて進めていくことについてお話しします。

複数サービスに関わったり、単一事業を複数事業に展開していくフェーズを経験したりしたことがある方は身に染みて感じていることだと思いますが、往々にして大きなシステム投資や時間がかかる移行は「実施すべき」ものの「今やるべきことなのか？」と押し戻されることが多いことが実情です。RAKSULもそのような議論を繰り返し行ってきました。

事業戦略と矛盾はしていないが、結局システム設計が後追いになってしまう……そのような状況は変えていく必要があります。そんな中で、我々は「経営との繋ぎ合わせ」を最初に考えるようにしています。

経営会議や取締役会で「技術戦略や技術競争力は何か？」という話はよく出てくると思いますが、まさに「経営とテックのつなぎ合わせ」が重要です。その1つとして、技術戦略を考える際にRAKSULに必要な技術競争力をきちんと定義することから始めました。

技術競争力の定義

竹内：定義の1つ目は、バーティカルな競争力です。複数の事業一つひとつが成長し続けていく環境をどのように整備できるか。例えば、先ほどの話で言うと、基盤を切り出すことによってどういう成長・効率化を期待するかですね。

2つ目はホリゾンタルな競争力です。ラクスルは顧客基盤・決済基盤を切り出すことによって、他サービスの立ち上げを大きく加速させました。このように「共有アセットを使うことによってプロダクト開発を加速する」というのが、ホリゾンタルな技術競争力だと因数分解しています。

既存の印刷事業や広告事業は共通した基盤にどう乗っていくか、そして新規事業領域も、決済基盤・顧客基盤を共通できるようなドメインで考えていこうとしています。

このように設定していくと、自ずと責任分界点も明確になります。 例えば共通アセットとのインターフェースはしっかりと切り、その乗っている事業側は、技術スタックの選定含め、開発チームの主体性に任せたいという考えに至ります。

そして基盤部分は、各サービスがしっかりと事業展開でき、IRにあるM&Aや新規事業などの大きな事業戦略を確実に遂行できるようなプラットフォームを作っていくというところが責任分界点です。

ただ、これは整理をし終わった後の姿で、最終的に基盤を切り出すというのはまだ途上です。さらに、M&Aによって全く異なる考え方・ソフトウェアスタックが混ざることによって、意図しない技術負債の発生もあるだろうと思います。

技術的負債の定義

竹内： 先の技術競争力を因数分解したのと同様に「RAKSULにとっての技術的負債とは何か」を因数分解しましたので、その考え方をフレームとして展開いたします。

開発生産性が悪い、メンテナンス性が低い、古いソフトウェアスタックを使っていてセキュリティーに問題がある、スケーラビリティに問題がある...などよくあるわかりやすい技術的な負債です。この部分は“確かな負債”としてきちんとコントロールしていく必要があります。 そしてそれと同時に、複数事業展開をしていく中で、プラットフォームのコントロールや価値提供も重要です。

すでに顧客基盤を持っている会社をM&Aする場合もあります。その際は、シナジーを出すためには、顧客基盤の統合や効果的な活用を進めM&Aの効率を上げていくことなど、技術負債のコントロールと絡めて経営層の中で話をしています。

現在RAKSULでは、M&Aで新たにジョインした会社が独自の顧客基盤や決済基盤を持っている場合、「まずこの部分の統合を図り、その上で技術負債はグループテックとしてきちんとサポートしていきましょう」といった考えを持って、プラットフォーム・組織・サポートの三方面からアプローチしていく体制を鋭意構築中です！

おわりに

6月18日（火）に、本イベントの続編（オフラインLT形式）が決定しました！ 続編では「リアーキテクチャにおけるアンチパターンへの向き合い方と次なる挑戦」をテーマにラクスル目黒オフィスで開催。

6名の登壇者が取り組まれてきたリアーキテクチャ全般について、そして次に向けてどうしていくか？を学べるLTイベントです。

ぜひお気軽にお越しください！

開催日：2024年6月18日（火）19:00-21:30
場所　：RAKSULオフィス（目黒駅 徒歩5分）
東京都品川区上大崎2-24-9 アイケイビル1F
参加費：無料
内容　：LTイベント（6名登壇）・懇親会
詳細・申込：https://findy.connpass.com/event/319637/

connpassグループのメンバー登録、Xフォローもよろしくお願いします！