現在、モノリシックなアーキテクチャからマイクロサービスアーキテクチャへの移行に取り組む企業が増加しています。

一方で、従来型のモノリシックなアーキテクチャを導入し続けていた企業にとって、マイクロサービス アーキテクチャは新しい挑戦となります。特にBtoBプロダクトについては文献も少なく、どのように着手すればいいのか？という点から考えなくてはなりません。

そんな中、「楽楽精算」「メールディーラー」など複数のBtoBクラウドサービスを提供している株式会社ラクスは「かみせんプロジェクト（開発の未来に先手を打つプロジェクト）」という活動を2017年からスタートさせています。

今回、「かみせんプロジェクト」の取り組みについて、同社のクラウド事業本部の鈴木勇さんと大平直宏さんに話を伺いました。

インタビュアーを務めるのは、マイクロサービスアーキテクチャに関しての投稿がQiita上でも注目を集めている川島義隆さんです。

BtoBプロダクトがマイクロサービスアーキテクチャに着手するために必要な考え方とは何か。また、陳腐化する技術に対して、エンジニア組織はどう向き合い解決すべきなのか。更に話は最近のエンジニア事情にまで波及しました。

現在は、“流しのアーキテクト”として活躍する川島義隆さんがマイクロサービスアーキテクチャ、そして、今あるべきエンジニア組織について迫ります。

・利益が出ているサービスが技術的負債を返すタイミング
・BtoBプロダクトがマイクロサービスアーキテクチャを導入するメリット
・ボトムアップとトップダウンのバランス
・中堅層が躍動する組織は健全である
・今、BtoBプロダクトに取り組む意義
・チャレンジできる土壌とコーチングができるエンジニアのバランス

プロフィール

 

 

利益が出ているサービスが技術的負債を返すタイミング

川島：ラクスさんのブログを拝見したのですが、「かみせんプロジェクト」は素敵なお取り組みですね。

鈴木：ありがとうございます。ラクスは複数のWebサービスの利益化を実現していますが、10年以上運用しているサービスもあって、コードベースが陳腐化していたり、フレームワークが古かったりという課題があったんです。

また、一つのサービスが巨大化しているため、分担作業がしにくいという問題もありました。BtoBのSaaS領域は次々と競合が誕生しています。そうした状況の中、我々も新しい手を打たなければならないという危機感から「かみせんプロジェクト」の取り組みははじまりました。

川島：利益が出ている状況で大きく手を入れるのは難しい点もありますよね。BtoBですと、お客様への影響も大きいですし。

鈴木：そうですね。実際のサービスに反映させるのは簡単ではありません。ただ、必ずどこかで一手を打たなければならないという課題がエンジニアチームにはありました。そこで、今後のサービス展開を意識しつつ、実験、実証するということを目的に定めたんです。

川島：実際、どんなところから着手されたんですか？

鈴木：実際に動いている自社内システムの改善、改修からスタートしました。ここでの着眼点は2つです。まずは、ラクスのサービスは現時点でインフラ部分をオンプレミスで構築しているので、クラウドインフラを取り入れること。次にサービスの分割です。

クラウドインフラの導入とマイクロサービス化に対する見識を深めることで、将来的にラクスが展開する複数のサービスに導入するテストを行ったイメージですね。

大平：マイクロサービス化だけではなく、ラクスのサービスが今後発展するために必要な知見を広めることも目的に活動してきました。

鈴木：マイクロサービスアーキテクチャの特性の一つとしてあげられる技術異質性を検証してみるために、Ruby、Go、Haskellなど複数の言語でバックエンドを構築してみたり。ただ実際に言語をバラバラにしてみると、特に理由がない限りは言語は統一しておいたほうがいいな、と改めて思いました。

大平：それはありましたね（笑）。

川島：それこそ書籍や勉強会、文献など学ぶチャンスはたくさんありますけど、試してみないと分からないことってありますよね。

鈴木：僕自身、マイクロサービスについては勉強会にも参加してみたり、色々なところから知識は取り入れていたのですが、実際にやってみるとやはり簡単じゃないな、と。

川島：ですよね。実際には泥臭いところもたくさんありますし。

鈴木：知識としては、多数のコンテナを連携して構築するからツールを活用しないと実現が難しい、という理解はあったんです。ただ、今まで使っていなかったツールをいくつも導入するとなると学習コストが高すぎました。やろうと思えばもちろん出来ないことはないけど、思っていた以上に大変だなということが実際にやってみて分かりました。

大平：ラクスは東京と大阪の二拠点で開発をしているプロダクトもあり、どうしても仕様のすり合わせなどコミュニケーションコストが発生しています。

うまくマイクロサービスを導入できれば、拠点単位などの複数チームで独立して開発しやすくなり、チームやメンバーを増やしながらスケールできる体制が作れるとイメージできるようになりました。

川島：それはいい発見でしたね。マイクロサービス化の最初のつまずきポイントって、「マイクロ」という言葉の捉え方になると思うんです。小さくなくてはならない。ここに囚われると、過剰に分割することにつながります。

巷でマイクロサービスアーキテクチャの事例として公表されているものは、巨大なシステム群で、マイクロなイメージとは異なります。まずは、そこから意識を離すことが大切だと私は思っています。

そもそものメリットを見つめ直すこと。マイクロサービスアーキテクチャが行き着くところは組織論なんです。組織に合わせたそれぞれの分割方法があります。そこで得られるメリットはデプロイが早くなったり、技術要素が違っても対応できることだったりがあります。どういったメリットを選ぶのかという観点を忘れないようにしつつ、色々試してみることがいいと思いますね。

「かみせんプロジェクト」の具体的な取り組みはこちらから>>

BtoBプロダクトがマイクロサービスアーキテクチャを導入するメリット

鈴木：マイクロサービスアーキテクチャでよく見る分割例って、BtoCのサービスで機能が比較的に少ないものが多いですよね。一方でBtoBのシステムは機能やロジックが多い。マイクロサービスアーキテクチャを扱う文献で挙げられている例の大半は細かく分割しすぎている気がしているんです。

川島さんがおっしゃる通り「マイクロ」のとらえ方が重要だと僕も思っています。ドメインや機能提供単位など、分割する基準の考え方が大切なのかなと。

ミニサービスアーキテクチャでハードモードな現実を乗り越え……たい（鈴木さんが公開しているスライド）

大平：BtoBの場合、本当にクライアントが求めていることなのか？という見方もありますよね。例えば、「楽楽精算」というサービスでは、弊社のマニュアルとは別に企業様が自社の運用に合わせたマニュアルを用意していることがあります。そのような場合には、あまり頻繁にリリースしすぎると、かえって混乱させてしまうという面もあります。

チーム毎に開発するメリットがこちら側にはあるとしても、リリースのタイミングを意識しなければ、本当の意味で価値があるとは言えないですよね。

トライをたくさんしたいフェーズのプロダクトの場合はいいとしても、そのフェーズを過ぎて利益が出ている、かつBtoBのサービスを運用していると、ただ世に出せばいいという考え方は違うと思うんです。

川島：おっしゃるとおりですね。ちなみに、教科書的な考え方では、DDD(ドメイン駆動開発)でいうところの境界づけられたコンテキストでサービス分割するのがよい、とされています。ここを外してしまうと逆にコストが増えてしまいます。

BtoBサービスの文脈でお話しすると、運用年数の長い基幹システムのデータを使いたいというケースが多いですよね。そうなると、長年運用しているシステムが開発の足かせになりがちです。

そこで、基盤システムにAPI連携を付け足して、いろんなアプリから使うのがマイクロサービス化にもつながる話だと思っています。ここからレガシーなシステムを刷新する足がかりにしてもいいわけですし。

ドメインに合ったそれぞれのAPIを用意すること。これをマイクロサービスアーキテクチャと呼んでいいのか疑問ではありますが、BtoB領域での開発をモダナイズするという意味では最適だと感じています。

ボトムアップとトップダウンのバランス

川島：「かみせんプロジェクト」は1年半ほど行われたんですよね？

鈴木：3人からスタートして、入れ替わりもありつつ6人に増えました。

川島：実際、こうした取り組みって業務時間外となると進まないですし、鈴木さんや大平さんのようなエンジニア組織の要を担っている方を専任においてしまっては、そもそも本業の開発スピードにも影響が出ます。ラクスさんの場合はどのような仕組みで取り組んだのですか？

鈴木：専任でフルタイムというのはさすがに厳しいので、週に最低15%の業務時間を「かみせんプロジェクト」に投資するというルールを設定しました。

大平：川島さんのおっしゃる通り、サイドプロジェクトは後回しになりがちですよね。活動を行っていく中で、安定して時間を確保できるようになった気がしています。ただ、これも改善の余地があると思っていて。集中的に実施する期間を設けて、ガツっと開発の時間を作ったほうがよかったんじゃないかという意見も出たりとか。

鈴木：出ましたね。定期的に活動するよりも缶詰にして集中した方が良かったかも、とか。でも、なかなか難しいですよね。

川島：鈴木さんと大平さんが関わっていることから、東京、大阪の二拠点で取り組まれているのもいいですよね。拠点間の距離はありつつも、同じ文脈で会話ができる機会も増えると言うか。

これはあるあるの話だと思うんですけど、こうしたサイドプロジェクトってセールスサイドとエンジニアサイドで意見が衝突する機会もあると思うんです。未来のための投資も大切なことは分かるけど、直近の新機能を開発してほしい、みたいな。ラクスさんの場合はいかがでしたか？

大平：そういった対立構造はありませんでしたね。

鈴木：「かみせんプロジェクト」の発足は、経営層からの発信がきっかけなんです。

大平：エンジニアサイドから、今後の開発スピードを考えると技術的負債をいつ返すのか？という話はずっと上がっていました。一方で、経営層も新しいことに取り組んだ方がいいという思いがありました。

利益は出ている。サービスとしても今後、5年、10年それ以上お客様の近くにあるサービスでありたいという思いもある。ただ、コードベースは古くなってきている。これからのスケールを踏まえると、そろそろ着手する時期に差し掛かっている、と。双方の意見がピッタリあった結果はじめられたのは良かったと思います。

川島：それは素晴らしいですね。

鈴木：経営層にエンジニア出身者が多いことも大きかったと思いますよ。

川島：私の知見でお話すると、こうしたサイドプロジェクトが発足するケースって2つあると思うんです。ボトムアップでスタートするケースと、トップダウンではじまるケース。後者は大企業で資産が豊富にある企業でよくある話だと思います。

ここがつながっているのが、ラクスさんのいいところだと思いました。これからのことを考えて、ボトムアップの意見は挙がるわけですが、なかなかトップ層に届かないという声も聞きますし。

セールスとエンジニアの対立構造が発生しなかったのも、比較的利益が安定している背景があったからこそだと思います。まさにいいタイミングでしたね。

大平：スタートアップ企業がサービスをローンチした後に売れるか売れないか？という時期ではないですからね。ラクスの場合は未来のスケールが着眼点になっていました。これまでは利益を出すためのスピードを重視してきたので、技術的負債や陳腐化という課題が生まれた。

そのため、「かみせんプロジェクト」は未来のための投資という経営判断に至ったんだと思います。

ただ、今回みたいに上手くいくばかりではなく、僕たちも数年前は悶々とした時期はありましたよ（笑）。

中堅層が躍動する組織は健全である

川島：確かに上手くいくことばかりではないですよね。ちなみに、「かみせんプロジェクト」の今後についてはどのようにお考えなんですか？

大平：「かみせんプロジェクト」の裏目標として、新しい技術に取り組む活動を開発組織のほかのメンバーにも広げていくことがありました。僕たち中堅層だけが取り組んでいるだけでは意味がありません。

若手にもこういった取り組みを行うことが当たり前と考えてもらいたいので、彼らも加えて2019年春から再スタートさせる予定なんです。これまでにプロジェクトに参加してくれた若手メンバーからも取り組みが刺激になったという声がありましたし。

技術本を渡したり、自社の業務システムの開発を依頼してみたりするのとは違った反応があるのは嬉しかったですね。

今後もマイクロサービスアーキテクチャに限らず、会社としての技術課題にいち早く取り組むプロジェクトとして運営したいと考えています。

川島：私が今のお話を聞いて思ったことなんですけど。若手社員の意見だけでこうしたサイドプロジェクトがスタートしても、長続きしないケースって多いですよね。キーマンがどこかに行っちゃったりとかもあるあるですし。

また、若手の活きのいいエンジニアから「ちゃんと教えてもらってない」という声を耳にすることがあります。いい意味でも悪い意味でも“優秀”というレッテルが貼られて、良く分からないまま開発させられたりとか。

新しいことをやりたがるベテランがいることで、そういった若手もよりよく育っていくと思うんですよね。実際、ラクスさんってどんなエンジニア文化なんですか？

鈴木：弊社ですか？すごい平和なんですよ。マサカリ持って振り回す人全然いないですし（笑）。

大平：（鈴木さんを横目に見る）そうかな？

鈴木：僕のマサカリは刃を潰していますから（笑）。逆に平和すぎてやいのやいの言う人がもう少し増えてもいいくらいじゃないですか？

大平：プロジェクトが炎上しないからですかね。自社サービスなのでコントロールもしやすいですし。

鈴木：それはあるかも。あとは慎重なところもあると思います。取り組みに対して、事前に「価値はあるのか？成功するのか？」と、何度も打ち合わせをしてから着手しますし。転職してきた人には「細かい！」って言われることもありますけど（笑）。

大平：計画が成功することは必ずしも求められないんですけど、計画性がないことは嫌う文化ですよね。

川島：そうなんですね。失敗しても特に言及されたりとかはないんですか？

大平：発案者の仮説や計画が重視される一方で、やってみた結果として上手くいかなくても詰められたり、島流しにあったりすることはないですね（笑）。失敗したらそれを次に生かしてねというスタンスです。それは僕たちが入社した段階からそういった文化でしたね。

鈴木：僕が中途入社して1年経たないくらいのときに先輩社員と企画したビアバッシュは現在も続いていますし、「かみせんプロジェクト」には試用期間中のメンバーもいましたよね。

大平：アジャイルの取り組みが始まってからは、さらに寛容になったんじゃないですか？計画性も大切ですけど、その場その場で最適なものが見つかったら方向転換しようみたいな。

川島：ベンチャーが成長した時に大切なのは、ベテラン社員のリーダーシップなんです。そうした声を取り入れようという度量の大きさというか。

エンジニアの人数が増えたタイミングになってくると、そう簡単に若手や社歴の短い方は意見できないものです。だって、経験知が全然違いますから。ただ、そういった声がサービスや文化を作る上でとても重要だったりもします。

平和な社風だからこそ、これからのリーダーシップで、より優れた文化形成ができると思いますよ。

※エンジニアを中心としたラクスのQiita2018年のAdvent Calendarも。日々の開発で得たノウハウや興味のある技術などについて書いていく予定です。

今、BtoBプロダクトに取り組む意義

鈴木：ちなみになんですが、僕は学生時代からBtoBのサービスの開発がしたいと思っていたんですけど、川島さんはいかがですか？

川島：私はBtoBサービスが好きですね。それは“スリル”があるからなんですけど（笑）。

鈴木・大平：（笑）

川島：自分はトラブった時のインパクトや社会的責任が大きいところにいる。だからこそ、絶対に本番でミスはできないし、トラブルが起きてはならない。そうした領域でトラブルを未然に防いだり、システムが安定稼働するように務める。そういった醍醐味がたまらなく好きなんです。

鈴木：僕も以前は金融系のSIerにいたので、その気持ちすごく分かります。エンジニアって技術の興味関心が偏りがちなんですけど、その領域外で知識が深まっていくのがBtoB開発をしていて楽しいところだと思うんです。お金の流れ方や商取引の知識を自分が吸収することで新機能のアイデアにつながりますし。

大平：他にも、同じ経費精算のシステムを作っていてもA社さんとB社さんで求めている要望が全然違うことがありますよね。仕訳の起こし方が違ったり、申請フローが違ったり。そうした制約がある中で、いかに個別カスタマイズなしで機能を実現するか考えるのもBtoBならではの魅力ですよね。

C社さんが現れた時に破綻する恐れもあるので、常に課題に向き合い続けられるという点もありますし。“本当の意味でのサービス”を作っている実感はBtoBならではなのかな。

川島：ラクスさんって企画の方ではなく、エンジニアの方も機能開発の企画に携わられているんですか？

鈴木：半々くらいですね。運用上の機能開発についてはエンジニアサイドからの意見が多いと思います。

大平：要望ベースの議題を受け取って、こちらで提案するケースも多いですよ。新機能と一言で言っても、以前からある機能とバッティングしたり、実装すると他のお客様に不都合が起こる可能性もあったりなど、様々な可能性を考えながら開発を行っていますので。

例えるなら、すごく複雑なパズルを解いている感覚に近いかもしれませんね。

川島：分かります（笑）。では、最後にこれはマイクロサービスアーキテクチャ導入に限らずですが、お二人の今後の目標などをお聞かせいただいてもいいですか？

大平：10年前と今では、世の中で当たり前とされる開発技術やプロセスが全然違いますよね。マイクロサービスアーキテクチャやCI、テスト自動化、クラウドインフラ、全てが当たり前になるくらい変化しました。ラクスでは、採用が進んでいるものもあれば、残念ながら途中のものもあります。エンジニア組織として、この流れにどう追いつき、追い抜くのか。ここにやりがいを感じています。

また、チームが大きくなるとそれぞれの責任者が生まれて動きにくくなるケースもありますよね。ちょうどラクスはそのフェーズに差し掛かっているので、これからもエンジニアが意見を言いやすい、通りやすい環境でいられるように文化を作っていきたいです。

鈴木：僕は新卒採用にも携わっているので、その立場からも思うことなのですが、新卒で入社した人たちが成長する機会を増やすためにも、小さく試せる環境を作っていきたいですね。あとは、ラクス出身のエンジニアと名乗った時に、ちゃんとブランドが通っているような世界を作りたいと思っています。「○○出身ってすごいね」と言われるのは、リスクがある事柄に挑戦して知見を広め、業界に共有していくことに対して敬意が払われるからだと思うんです。そういった良い環境を作っていきたいですね。

川島：本日はありがとうございました。「かみせんプロジェクト」を通じて、ラクスさんが成長し、世の中の仕事がより効率化することを祈っています。何かあればご相談くださいね。

チャレンジできる土壌とコーチングができるエンジニアのバランス

川島様から、今回のインタビュー内容の総括をいただきました。

今回、「かみせんプロジェクト」のお話を伺った時に、若手社員が取り組んでいるのかな？と思っていました。ただ、実際は中堅層が取り組んでいると知り、嬉しくなりましたね。ボトムアップとトップダウンの両面からこうしたサイドプロジェクトが誕生することも素晴らしいと思います。取材の途中でもお話ししましたが、「教えてもらっていない」若手エンジニアが不満を抱えているケースは多くあります。これは1on1に取り組んでいても表面化しにくい課題でもあるのです。
チャレンジできる土壌が整っている会社は多くありますが、正しくコーチングできるエンジニアが揃っている企業はそう多くありません。こうした中堅が牽引している組織であれば新卒、中途に限らずエンジニアが活躍できるのではないでしょうか。

ラクス エンジニアブログでもっとチェックしてみる>>

〈編集・ライター：川野優希〉