2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
田中晋太朗氏:はじめまして、ワンキャリアの田中です。私からは「モジュラモノリス構想」と題して、我々ワンキャリアが抱えている課題感であったり、これまでに試してきたこと、それからこれから試していこうと思っていること、構想の話をしていきます。
本題に入る前に軽く自己紹介させてください。株式会社ワンキャリア・CTOの田中と申します。過去、テック系のスタートアップを起業したり売却したりとかという経験をしつつも、2018年にワンキャリアの1人目のエンジニアとしてジョインして、以降CTOを務めています。
それからちょっと余談ですが、最近ハマっている趣味というか……。なぜかこのタイミングでアマチュア無線の免許を取って、最近ハマっているようなところです。
本題に戻ります。本日の流れは、ワンキャリアの事業の紹介のあと、ワンキャリアの開発が抱えている課題を話して、それに対して今までどういうことを試してきたのか、それからこれからどういうことをやっていきたいのかを話していきます。
一言お断りしておくと、モジュラモノリスというところで考えた時に、ワンキャリアの状況は前に発表されてた2社さん(株式会社タイミー、株式会社hacomono)と比べても一番遅れている状況というか。これからやっていくところも非常に多いし、検証しながらやっていく中で、構想は軌道修正とかしていくべきところも多々含まれると思っています。
なので、半分実話でありつつ、半分構想というか私の空想みたいなところが含まれると思って理解いただければ幸いだと思っています。
では、最初にワンキャリアのことを少し説明させてください。ワンキャリアは「人の数だけ、キャリアをつくる。」というコーポレートミッションの下、ユーザーの方の就職活動、転職活動、採用活動を支援する各種事業をやっています。
「じゃあどんなサービスなの?」というところで、大きく分けて3つあります。採用活動をしている人事向けの「ONE CAREER CLOUD」と新卒の就活生向けの「ONE CAREER」、中途の転職者向けの「ONE CAREER PLUS」というところで。
どのサービスもUser Generated Contents(UGC)とかクチコミ、体験談を求職者の方から集めて、いろいろ就職活動をやっている方々、求人している会社の採用設計とかを改善していくようなサービスになっています。
この3つのサービスの中で最初にリリースしたのが、社名と同じですが「ONE CAREER」です。2013年にサービスを立ち上げて以来……。私が入社する前からあったサービスなんですけど、がんばって開発してコンテンツ数も増やしてきて、その結果として、最近だとHR総研さんの調査結果で「学生が1年で最も使うサイト」で2位になっている。1位ではありませんが、2位になっているといったかたちで、ユーザー数を伸ばしています。
この裏には、先ほども少し触れたクチコミとか体験談とかのデータをたくさん集めてきて、その後のキャリア選びのために役立てるというところで、キャリアデータをたくさん集めて価値提供しているというところがワンキャリアの特徴になっています。
このデータを集めるというのはなにも就活生からだけではなくて、中途の方からもデータはたくさん、多角的に集めていこうとしています。「ONE CAREER CLOUD」を使っている人事の方からもどんどんデータを集めていこうというところで、「ONE CAREER CLOUD」もまた、機能的にもどんどん最近増えていって、いろいろな機能を提供するようになってきています。
もうちょっと具体的に言うと、最初は「ONE CAREER」に求人情報を載せる管理画面的な意味合いが強いサービスだったんですが、スカウトの機能であったり、応募者管理をできるような機能であったり、どんどんと機能が追加されていっているというところです。
こういったかたちで機能がどんどん拡充される中で、全面的にキャリアデータを集めていくようなサイクルを回しながら、ワンキャリアのデータを事業に活かしていくというようなことをしています。
ここで本題に関わるところに話を戻すと、データ活用をどんどん活性化させていけばさせていくほど、ワンキャリアのサービス、今時点で「ONE CAREER CLOUD」と「ONE CAREER」と「ONE CAREER PLUS」ありますが、各サービスが同じデータソースにどんどんアクセスするような状況が生まれます。
こういった状況って、やはりデータを上手にモデリングしてあげて、アーキテクチャ的にも上手にアーキテクチャ設計してあげないと苦しいことになりそうだなみたいなところを察することができる部分かなと思っています。
しかも、今後もサービスは増えていく予定もあるので、ますますアーキテクチャの部分は大事になってくるなというところです。
ということで「アーキテクチャの部分は大事ですよ」という話につなげたところで、「実際にじゃあワンキャリア、何に困っているんでしたっけ?」というところを説明させてもらえればと思っています。
今日の会議のテーマとこれまでのお話の中で大部分お察しなのかなと思っていますが、開発がちょっとずつ大変になってきました。実際蓋を開けてみると、UGC、ユーザーの投稿データはたくさん集めてきましたが、昔集めたデータと新しいデータで仕様が変わっていたりして。互換性のためのコードがたくさん入っていたりとかもしますし。
そのデータに触る人は、学生だったりすることもあれば、人事、企業の人事だったりすることもあれば、弊社の社内のサービス管理者だったりすることもあるんですけど、それぞれ違うアクターのユースケースが、1つのクラスの中に全部書かれていたりとかもしていました。
同じデータベースを複数のサービスから参照していたりするので、データベースのマイグレーションもけっこう大変だというところで、いわゆる“大きな泥だんご”と言われているような状態であると理解いただければと思っています。
つまるところ、何か変更するにも変更影響に恐怖しながらやってきたというところですね。
というところが3年前までの状況ですでにあったんですが、それから何をしてきたかというと、実はマイクロサービスとかモジュラモノリスとか、そういう垂直分割をするアプローチをちょっと避けていた期間があります。
じゃあどんな取り組みをしてきたのかというところを、少し紹介させてください。例えば、今回の趣旨からは大きく外れますが、「スキルが高ければなんとかなるんじゃないか?」みたいな話も出て、スキルアップのための施策をいろいろ打ったりもしてきました。
アーキテクチャの部分で言えば、レイヤードアーキテクチャというか、オニオンアーキテクチャをベースとした考え方を取り入れてるようなこともしてきましたし、「データベース分割できないかな?」みたいな取り組みもしてきました。
今回の趣旨に照らして、レイヤードアーキテクチャの導入をがんばってみたみたいなところを、モジュラモノリスの話に入る前に少しお話しします。
3年ぐらい前のワンキャリアのコードを……。ちょっと色が薄くてもしかしたら見にくいかもしれないですね。すみません。今も完全に解消したわけじゃないんですが、非常にファットなモデルだったんですね。まあ、よくある話だと思います。
先ほども言ったように、いろいろな立場の人が使う、いろいろな関心ごとに基づくユースケースがModelの中にごちゃまぜで書かれていたりしました。
Modelの本来の性質、何が本来の性質で、何がアプリケーション要件の実装なのかがパッと見わからないようなところもあったし、かといってユースケース全部をちゃんと寄せられているのかというと、Controllerに書かれている部分もあるというような、けっこうごちゃまぜの状態でした。
今日参加されている方だと、具体的な、例で説明するようなところはもしかしたら必要ないのかもしれないですが。
(スライドを示して)じゃあ弊社の当時のモデルどんなふうになってたのかみたいなところを少し例をもって説明すると、例えば(仮にECサイトのモデリングを考えると)こんな商品モデルがありました。
とある商品の税込価格を計算するロジックを含むようなモデルがあるんですが、なぜかそこにお得意さま割引の計算をするコードも含まれていたりするような、そんな状態です。実例ではないので、例えばこういう話ということです。
そうすると、この商品モデルって、お得意さまの話って商品じゃなくて顧客の話ですよね。そのモデルで取り扱う関心ごとではないことも、知らないと処理できないようなモデルになっていて。つまり、依存性の方向が逆転しているというところで、変更に弱いし、単純にわかりにくいみたいな状態が起こっていました。
なので、「いや、そもそもマイクロサービスとかモジュラモノリスとかあるけれど、そもそも水平分割うまくしていったほうがいいんじゃないの?」というところで、まず水平分割をやりました。
オニオンアーキテクチャとかを参考にしながら、ModelとかControllerからユースケースを切り出していくことをやってみました。
(スライドを示して)「Controller」「Application Service」「Domain Service」「Model」と一応置いています。このあたりの各レイヤーの責務はググったりして出てくる一般的なものから大きくは外れていませんが、ワンキャリアにおいてはこういう整理になっているというのが、Controllerはクライアントから、ブラウザからのリクエストを受け取って認証・認可しつつ、パラメータを解いて取り出してくる。それをApplication Serviceに渡します。
Application Serviceはアプリケーションのユースケースの実装ですね。手続き的な処理を担当して、必要に応じてDomain ServiceであったりModelにアクセスします。Domain Serviceはドメイン固有の手続き的な処理を書いていたりもします。ModelはRailsのActive Recordを扱うモデルというような整理になっています。
これをやってコードの見通しは多少良くなったなと思いますが、今日の会の趣旨に戻って、これでやはりすべて解決したわけではなかったというところで、まだ苦しい部分がありました。
(スライドを示して)結局、水平分割しても解決しないことというのがこれなんですね。弊社でいうと、「ONE CAREER CLOUD」「ONE CAREER」「ONE CAREER PLUS」、それから社内の管理サービスが「Admins」って書いてあるものなんですが、それらって、別のサービスとして実装されていてサーバーも別ですが、みんな同じデータソースを見にいっているというところが実際のところです。
水平分割はしたものの、例えば採用イベントのデータを格納しているテーブルにアクセスするモジュールというかサービスは、みんなこのモデルのことをよく理解しておかないとなかなか変更しづらいというのは、やはり変わらなかったというところです。まあ、当然といえば当然なんですけれども。
なので、例えば「ONE CAREER CLOUD」の開発者は、「ONE CAREER CLOUD」のロジックだけじゃなくて、「ONE CAREER」がこのモデルに対してどういうことをやっているのかとか、そういったところもある程度理解しておかないと扱えないような状態になっていました。
それでもサービスを壊さないようにしないといけなかったので、何か変更しようと思った時に、とても慎重にほかのサービスのこととかを調べるということをやりながら開発してきたわけですね。
怠ると障害が発生してしまうし、回避するために、自分の担当サービスじゃないところのコードを読みにいって変更影響の調査をしたり。それからそのドメインに詳しい人に話を聞きにいって変更影響を調査したりとか。
あとは、実際にリリースする前に、小さいリリースでもこのあたりを触る変更が含まれる場合は、CTOの私とかVPoEにレビューをもらおうというので、けっこうボトルネックになったりする瞬間とかもあったりして。調整工数がなかなかかかるというところで苦しんでいる状況になっています。
(次回に続く)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには