RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

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

5月22日、Findy株式会社主催のイベント「アーキテクチャを突き詰める 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フォローもよろしくお願いします!

ラクスルでのエンジニアリングマネージャー半年を振り返る

こんにちは。ラクスルのプロダクト基盤部のEM兼PdMを担当している安尾(@yusuke_yasuo)です。

2023年8月にラクスルに入社して以来、ラクスルにおける決済基盤の構築を担当しています。 引用:2024年7月期第2四半期 決算説明会資料

EM候補として入社して10月に正式にEMとなり今月で半年になるため、一度振り返りをしてみようと思います。

目指すEM像

振り返る前に私が目指すEM像について簡単に紹介したいと思います。

一言で言うと、こちらの記事で書かれているような「強めのEM」が私が目指すEM像です。

引用:エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

会社によってはピープルマネージメントやテクノロジーマネージメントを行うのがEMというところもあるかもしれませんが、経験上チームとしての成果を最大化するためにはプロダクトマネージメントやプロジェクトマネージメントのスキルが重要になる場面も多いと感じており、その時々でチームの成果を最大化するために最も効果的なレバーを見つけてそれを引くことができるようなEMになれればと考えています。

ちなみに、ラクスルにおける理想のEM像もまさにこの「強めのEM」というイメージで、会社における理想のEM像と私の目指すEM像の一致度はとても高いと感じています。

ラクスルはマイクロサービスで動いており、異なる目的や特性を持ったシステムが存在し、所属エンジニアのスキルセットも当然チームによって様々なので、ラクスルのEMは各チームの状況にあわせてレバレッジが効くスキルを発揮することで成果を上げていると感じています。

半年間を振り返って

一言で言うと、とても充実した半年が過ごせたと思っています。

ちょうど大きなプロジェクトが始まるタイミングに入社した幸運もありますが、決済基盤構築プロジェクトの計画から実行まで、大きな裁量を持ってチャレンジできていることが一番の要因です。

プロジェクトを「なぜやるか」が明確になっている状態で参画し、「何をつくるか」「どうやってつくるか」「どういう体制でつくるか」などについては自分で主体的に考えられる環境だったため、これまで経験したことがないような多くのチャレンジをすることができました。

本記事では、印象に残っているチャレンジについていくつか紹介できればと思います。

基盤システムの要件定義

いま構築しているプロダクトは約10個のECから利用される決済基盤です。

過去にも色々なプロダクトの開発に関わってきましたが、ラクスルほど大規模なプロダクトははじめてで基盤システムの開発と言えば、過去に2つのシステムから利用されるID基盤の開発にエンジニアとして少し関わったことはあったもののほぼはじめての経験でした。

これまでプロダクトマネージメントをする際は、ユーザーインタビューやデータ分析を通してユーザーのニーズやペインを理解することでプロダクトの方向性や仕様を決めていましたが、基盤システムとなるとエンドユーザーだけでなく、基盤システムを利用する社内の各プロダクトへの深い理解が必要になるので勝手が違ってきます。

決済基盤を利用する各ECの決済周りの仕様を把握した上で慎重に仕様を決めないと、これまでできていたことができなくなったり使い勝手が下がりユーザーの離脱につながってしまいます。価値向上のために多くのリソースを投下しているにも関わらずそうなっては本末転倒です。

また決済はしたら終わりではなく、その後キャンセルになることやトラブルによって返金したり、追加請求が発生することもあります。さらには決済された金額と決済代行業者から入金された金額を突合したり、最終的には正しく経理処理が行われる必要があります。

結果的に、各ECの仕様やオペレーション把握のために入社して3ヶ月の間に30名程度の方からヒアリングをさせていただきながら要件を固めていったのですが、これほどステークホルダーが多いシステムの要件定義ははじめてで、考慮すべきことがとても多いのが印象的でした。

ラクスル全体の理想を意識した概要設計

冒頭でも触れましたがラクスルはマイクロサービスで動いており、約10個のECに加え、特定の役割に特化した基盤的なシステムも複数存在します。今回はそこに決済基盤を新たに追加することになるのですが、システム間のAPIの設計を失敗すると密結合・低凝集なマイクロサービスができあがってしまい中長期にわたって大きな負債となり、事業の成長速度の悪化やエンジニアの開発体験の悪化を引き起こす懸念がありました。

とは言っても、私はラクスルに入りたてでしたので、既存システムや事業に関する解像度が浅く、1人で適切な設計をするのは現実的ではありませんでした。

そこで、CTOや社内のシニアエンジニアなど既存システムに詳しい方々の協力を得て、数ヶ月にわたって毎週設計レビュー会を実施させていただきました。最初に決済基盤で実現したいビジョンや要件を共有した上で論点の洗い出しを行い、その後はひとつひとつの論点に対する議論を行いました。

その際に意識したのが、現状からの積み上げで考えるのではなく、できる限り理想からの逆算で設計を行うということでした。現状からの積み上げで考える方が短期的には圧倒的に楽で速いのですが、それでは全体の理想からは遠ざかってしまう可能性があります。遠回りでもまずは目指すべき理想について関係者間で認識をあわせた上で、プロジェクトにかけられる期限や予算を考慮した落とし所を決めるというステップを意識することで、長期で見ると最短距離を進んでいるということを目指しました。

チーム一丸を目指した目標共有会

EMの仕事と言えば、チームメンバーの目標設定や評価をイメージする方も多いのではないでしょうか?ラクスルのEMもそのイメージに違わずチームメンバーの目標設定や評価を行います。

チームにおけるテクノロジーマネージメントやプロダクトマネージメントについては各EMの強みやチームメンバーの構成によって能力発揮の必要性は大きく異なっているように感じますが、ピープルマネージメントについてはもれなく一定レベルの能力発揮が必要とされていると感じます。

私が各チームメンバーの目標を設定して評価までには大まかに以下のようなことを行いました。

  1. 上長や共働するBizメンバーとチームのOKRを決める
  2. チームメンバーのWill(中長期の目指す姿やそのために獲得したい能力)を1on1でヒアリングする
  3. チームのOKR達成のためにやるべきことを分解する
  4. 分解したOKRの担当メンバーを現時点での適性とWillを考慮しながら割り当てる
  5. 4で割り当てた担当について各チームメンバーと1on1をしながら認識合わせをする
  6. チーム全員で目標共有会を開催して、全員が目標を達成するための作戦を立てる
  7. 6で立てた作戦がうまくいっているか月次で全員で振り返りを行い、作戦を調整する
  8. 週次で各チームメンバーと1on1を行い、目標達成への進捗や課題の確認をする
  9. 半期の終わりに振り返って評価を行う

色々とやっていますが、特に6の目標共有会と7の月次の振り返りが効果的だったと感じています。

過去のチームでは、これをやらなかったことで、お互いチャレンジしたいことが被ってしまったり、誰もやらずに放置されてしまうタスクが発生したりというような問題が発生することがあったのですが、これを実施することでチャレンジが被りそうな部分や放置されそうなタスクについて事前に調整を行うことができました。それ以外にも一人ひとりの目標達成に向けて他のメンバーにはどのような協力ができるかということも論点として議論をすることで、全員が自分の目標達成だけでなくチーム全員の目標達成を意識して一丸となって業務に取り組むことができていたと感じます。

今後のチャレンジ

今後チャレンジしたいことはたくさんあるのですが、1つだけピックアップしたいと思います。

ベトナムの開発チームとのコラボレーション強化

私のチームはこれまで日本語での会話や読み書きが可能なメンバーのみで開発を行っていました。今後さらに開発速度を上げたり、多くのことにチャレンジしていくには国内のエンジニアだけでは難しい状況のため、近々ベトナムの開発チームと共に開発していくことが決まっています。

ただ、これまで日本語を前提とした開発プロセスやドキュメンテーションを行っていたためベトナムメンバーが持っている能力を発揮できるようになるためには様々な改善が必要になることは明らかです。

私をはじめ、今いるチームメンバーは英語でのリアルタイムのコミュニケーションは難しいため、スクラムイベントを透明性を持って開催するにはどうすれば良いかというのも大きな課題です。

これらはぶつかるであろう課題のほんの一部で実際やってみるともっと色々と躓くのだと思います。一朝一夕で解決できない課題も多いため、目指す姿を明らかにしつつ時間をかけて一歩一歩根気強く取り組んでいくしかないと考えています。

ハードルは決して低くないですが、実現できた後の姿を想像するとワクワクするため、実現に向けて頑張っていきたいと思います!

最後に

今回は私がラクスルのEMになってからの半年を振り返ってみました。

ラクスルには良い意味で多くの取り組むべき課題があり、Willがあれば様々な機会提供が受けることができると強く感じています。

今後も定期的に振り返りをしつつ、初心を忘れずにチャレンジを続けていきたいと思います。

シェル起動時にGitHub CLIでPATを生成して開発を効率化!

こんにちは!ラクスル事業本部でエンジニアをやっています、灰原です!

皆さんは普段の開発でGitHubのPersonal Access Token (PAT) を使うことはありますか? ラクスルではいくつかの社内パッケージをGitHub Packagesで管理しており、それらのインストールのためにPATが使われています。 例えばRubyのgemであればbundle configコマンドでPATを指定したり、npmパッケージであれば.npmrcファイルにPATを書いたりします。この対応自体はGitHub Packagesのドキュメントにも書かれているものですが、言わずもがなPATの扱いには注意が必要です。不必要な権限 (scope) を付与しない、有効期限を設定するなど基本的な対策を取るべきでしょう。

しかしPATの有効期限が切れるたびに、GitHubの画面から適切なscopeと有効期限を指定したPATを再生成して、bundlerやnpmなどそれぞれの設定をやり直すという、この一連の作業はそれなりに面倒なものです。

この記事では、そんな面倒な作業をGitHub CLIとちょっとしたスクリプトで効率化する方法について紹介します。

GitHub CLIでPATを取得

まずはPATの作成作業の効率化です。これには GitHub CLI を使います。コマンドラインからプルリクエストを作ったりラベルを付けたりできて便利なGitHub CLIですが、実はGitHubのPATを取得することもできます。

まずは gh auth login コマンドで認証情報を獲得します。これを実行するとワンタイムパスワードが表示され、それをブラウザで開いたGitHubの画面に入力すると、認証が完了します。その後、gh auth token コマンドを実行すると、先の認証時に取得したPATが表示されます。

$ gh auth login # ログイン
$ gh auth token # PAT取得

gh auth token で取得したPATを使って、curlでGitHub APIにアクセスしてみます。

$ curl --request GET \
       --url "https://api.github.com/octocat" \
       --header "Authorization: Bearer $(gh auth token)"

curlでGitHub APIにアクセスする

無事にOctocatが表示されました。

(上記の例では検証のためにcurlを使っていますが、GitHub CLIにはGitHub APIにアクセスする機能があります。)

追加のscopeを設定する

ところでGitHubのPATはscopeが設定されています。 gh auth statusコマンドを使えば、GitHub CLIが提供するPATのscopeを確認することができます。 単にgh auth loginした後の状態のscopeは、admin:public_key / gist / read:org / repo となっていました。

gh auth status

しかしGitHub Packagesからパッケージをインストールする際には、read:packages scopeが必要です。 このような追加のscopeを設定するには、gh auth login コマンドの -s ( --scopes ) オプションを使います。

例えば下記のように、read:packages scopeを追加で要求することができます。

$ gh auth login -s 'read:packages' 

gh auth status コマンドで確認してみると、確かに read:packages scopeが追加されていることがわかります。

gh auth status (read:packages scope付きでログインした後)

これでGitHub Packagesも扱えるようになりました。

envsubstで設定ファイルにPATを埋め込む

envsubstというコマンドを使うと、テンプレートエンジンのように環境変数をテキストに埋め込むことができます。

In normal operation mode, standard input is copied to standard output, with references to environment variables of the form $VARIABLE or ${VARIABLE} being replaced with the corresponding values.

envsubst Invocation (GNU gettext utilities)

これを使うと、gh auth tokenで生成したPATを簡単に設定ファイルに埋め込むことができます。 例えば、.npmrc.templateとして以下のようなファイルを用意しておきます。

@NAMESPACE:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${GH_TOKEN}

そのうえで、次のワンライナーを実行すると、PATを含んだ .npmrc ファイルが生成されます。

$ cat .npmrc.template | GH_TOKEN=$(gh auth token) envsubst > .npmrc

このようなテンプレートファイルと、envsubstを実行するMakefileなどをレポジトリごとに用意するのも1つのアプローチでしょう。

シェル起動時にまとめて設定する

もう1つのアプローチとして、bundlerの設定したり、ホームディレクトリ直下に.npmrcを置いたりするシェルスクリプトを作り、それをシェル起動時に読み込ませる方法もあります。

例えば以下のようのシェルスクリプトです。

#!/bin/bash

set -eu

function login() {
    if gh auth status; [ $? -ne 0 ] ; then
        gh auth login -s 'read:packages'
    fi
}

function substitute() {
    token=$1
    template=$2
    file=$(echo ${template} | sed -e "s/\.template$//")

    cat ${template} | GH_TOKEN=${token} envsubst > ${file}
    echo substitute: ${file}
}

function main() {
    login
    token=$(gh auth token)

    # bundle
    bundle config --global https://rubygems.pkg.github.com/raksul w-haibara:$(gh auth token) 

    # npm
    substitute ${token} ~/.npmrc.template
}

main

おわりに

GitHub CLIを使ってPATを生成し、それを各種設定ファイルに埋め込む方法を紹介しました。 小さなところから日常の手間を減らしていきたいものですね。

ノバセルでデータエンジニアへのジョブチェンジをした話

こんにちは。ノバセルのデータプロダクトチームでデータエンジニアとして働いている森田です。 現在は業務として Snowflake や dbt を用いたデータ基盤周辺システムの開発や運用に携わっています。

ノバセル以前の会社ではバックエンドエンジニアとしてソフトウェア開発に携わっていましたが、転職を機にデータエンジニアへジョブチェンジをしました。 入社してから6ヶ月間ノバセルでデータエンジニアとして働いてみて、一般的なソフトウェアエンジニアとの違いなどいろいろな気づきがありましたので紹介します。 データエンジニアに興味がある方にとってなにか参考になるものがあれば幸いです。

データエンジニアのきっかけ

データエンジニア以前は普通のソフトウェアエンジニアとして、Webサービスやモバイルアプリの開発などに携わっていました。 当時はデータエンジニアという職種を意識したことはなく、ご縁があってノバセルの選考を受けさせていただいたときにデータエンジニアとして選考を受けてみないかという話をいただいたことが最初のきっかけです。

ただ、今振り返ってみると前職でデータエンジニアに近いことをしていました。

アプリケーション開発として、Scala を用いてデータを保存・加工し、検索エンジンに Feed していくバッチ処理システムや、 Apache Flink と Amazon EMR を用いてストリーミングデータ処理を開発していました。 その一方で、BIツールの Redash を使ってデータ分析を行いビジネスサイドの方と議論したりといった活動も行っていました。

こういった業務内容がデータエンジニアとしてのキャリアチェンジにつながったのだと思います。

データエンジニアとして働いてみて

実際にノバセルのデータエンジニアとして働いてみて従来のソフトウェアエンジニアリングと違いや新鮮さを感じた点がいくつかありました。 大きくわけて以下の 3 つです。

  • Modern Data Stack
  • メンタルモデル
  • エンジニアリング以外

Modern Data Stack

データエンジニアとして働いてまず驚いたのが、Modern Data Stack とよばれるデータ活用・管理のためのサービス・ツール群です。

以下の記事でカオスマップが紹介されてますが、データエンジニアリングのさまざまなカテゴリーで活用できるツールや SaaS が大量にあります。 lakefs.io

正直、最初はどれ使ったら良いかわからずかなり混乱しました。 しかし裏を返せば、発展していることの証明であり非常にホットな領域だと改めて実感します。

ツール選定の機会が非常に多くなったため、調査 => 意思決定の精度の重要さを日々感じています。 以下の記事でも紹介されていますが、ノバセルでは ADR (Architecture Decision Record) を用いた運用を通してその精度を上げる取り組みも行っています。 techblog.raksul.com

個人的に技術選定について以下のスライドがとても好きなのでこちらも貼っておきます。

技術選定の審美眼(2023年版) / Understanding the Spiral of Technologies 2023 edition - Speaker Deck

メンタルモデル

ソフトウェアを開発しているとプログラミングという行為を通してアプリケーションが実現したい、もっというとユーザーが望んでいる振る舞いを開発するのがメイン業務になります。データは振る舞いにより得られる副産物といったメンタルモデルでした。

しかし、データエンジニアリング領域ではデータが主でありかつ、データがプロダクトであるといった考えが浸透していると感じました。 ロジックはデータを加工するためにあり、データはプロダクトなので信頼性を確認するためにテストの実施も行うといったメンタルモデルです。

もちろんデータとソフトウェアは切り離せるものでないですが、メンタルモデルとしてデータ側に重心をおいた考えに自然となりました。

ノバセルではまさにデータがプロダクトとなる事業を行っているため、こういった組織の中でデータエンジニアというポジションでデータに向き合うことは重要であり、とても面白いと感じています。

エンジニアリング以外

データをどう活用するかという点について、エンジニアリング以外の知識も非常に重要だと感じています。

データエンジニアについて調べている中で出会ったのが、DMBOK というデータを資産として活用するために必要なナレッジが集まっている書籍です。

DMBOK : データマネジメント知識体系ガイド | Metafindコンサルティング

データを扱うということが、それ自体学ぶべき内容がある重要なテーマという点が面白いなと思いました。

社内 Slack でも DMBOK という単語がちらほら見受けられ、以前は輪読会も開かれていたようです。自分も一部しか読めてないので読んでいこうと思っています。

ソフトウェアエンジニアが貢献できること

データエンジニアリングはソフトウェアエンジニアリングと異なる点もありますが共通点も多くあります。

まず、ソースコードの読み書きはデータエンジニアリングでも変わらず重要なことです。 とくに dbt などを触っているとその周辺ツールに触れる機会が多く、それらは主に Python で書かれていること多いため Python に精通しているとこれらの周辺コードが何をしているかという点を深く理解できます。

直近だと、data-diff というテーブル間のデータ比較をするデータ品質のためのツールのソースコードを精読する機会がありました。

GitHub - datafold/data-diff: Compare tables within or across databases

また、データエンジニアリング領域でソフトウェアエンジニアリングから移植されてきた概念が多くあります。

例えば以下のような分野です。

  • Data Observability
  • DataOps
  • Data Mesh

これらの分野は、それぞれデータ領域で課題となることに対してソフトウェアエンジニアリングの領域から移植されているものです。

Data Observability は Observability、DataOps は DevOps、Data Mesh は Microservices や Platform Engineering 周りから影響を受けているものという認識です。

これらはまだまだ日本語の書籍がすくないですが色々と書籍がでていて、まさにいま Hot なトピックということが感じられます。

これらのような歴史的にソフトウェアエンジニアリングが解決してきた問題をデータエンジニアリング領域にも適用させる試みは規模の大きさはあれど無数にあると思っています。 これらの点で、ソフトウェアエンジニアとしての経験を活かして貢献していくことができると信じています。

さいごに

ソフトウェアエンジニアリングからデータエンジニアにジョブチェンジしてみた際の気づき等を書きました。 幸いにもノバセルにはデータエンジニアリング領域にとても明るい方が多数在籍しているため、ここでデータエンジニアに入門できたのは非常に幸運でした。

データエンジニアリング領域にはまだまだ学ぶべきことが大量にありますが、データ周辺のエンジニアリング全般を行うために色々なスキルを磨いていこうと思います。

この記事がデータエンジニアへの挑戦を考えている方の一助になっていれば幸いです。

ノバセルにおいて意思決定ドキュメントの運用を3ヶ月してみて分かったこと

こんにちは。ノバセルのデータプロダクトチームにて開発エンジニアをやっている山中(yamnaku_)です。 現在は、ノバセルの各種分析システムのバックエンド開発を行なっています。 特に、データウェアハウス製品Snowflakeを利用したデータ基盤の開発・運用に取り組んでいます。

私の所属するチームでは、意思決定を記録するドキュメントとして、Architectural Decision Record(ADR)の運用を始めて3ヶ月ほどが経ちました。 今回は、感じることが出来た効果についてご紹介したいと思います。

背景と課題

ひとつ目のプロダクトである「ノバセルアナリティクス」のローンチから3年が経ち、ノバセルでは様々なシステムが現在稼働しています。 ノバセルはお客様のデータや、検索量といったサードパーティデータをTVCM放映データと掛け合わせて分析を行っています。 そのようなサービスの特性上、モノリシックなシステムが鎮座する形ではなく、小規模なシステムやバッチが多く運用される状況になっています。 特に、以下のような3つのカテゴリに分類されるシステムが多く存在します。

  • データを収集するバッチシステム
  • データを統合し、分析するバッチシステム
  • 分析結果をユーザーが参照・検索できるアプリケーションシステム

そうした中で、各システムのアーキテクチャ意思決定の過程については、ドキュメンテーションが不足していたり、ドキュメントの置き場所が指定されていないことにより散在していました。 特に、以下のようなコードを読んでも分からない点については、ドキュメントによって補う必要がありました。

  • どういった選択肢を検討し、なぜそのアーキテクチャを選択したのか
  • 意思決定の背景にあったビジネス上の事情や顧客の要求

また、メンバーからは「(チームや組織としての)意思決定の流れが見えにくい」という意見ももらっていました。 こうした項目について、共通のドキュメントフォーマットを定め、置き場所を明示することにより、以下のような効果を期待しました。

  • アーキテクチャ選定の意思決定プロセスをフォーマット化し、より早くより良い意思決定を助けること
  • チーム体制の変更や、新メンバーが加入した際に、スムーズにシステムの理解が進むこと
  • 意思決定のフローを透明化し、状況の把握をしやすくしたり、納得感を醸成すること

採用したフォーマット

ドキュメントの運用方法や、フォーマットの策定にあたっては、『Googleのソフトウェアエンジニアリング』の第10章「ドキュメンテーション」を参考にしました。 初期はDesign Documentを参考にしながら以下のような項目を最終的に採用しました。

ドキュメントオーナーと変更履歴

ドキュメントはメンテナンスや維持のため、ドキュメントオーナーを明記すると良いとされています。 そのためドキュメントの冒頭にドキュメントのオーナーを明記するようにしています。 また、オーナーが交代したり、内容が途中で変わってしまうこともあるため、変更履歴も合わせて記述するようにしています。

NotionのTableを使っています。

ドキュメントの目的

このセクションには、何を決めるためのドキュメントなのか、ということを記述します。

優れたドキュメントを作るコツは、ドキュメントにおける目的を一つに限定することです。 そのため、すべての意思決定ドキュメントは、単一の意思決定を出すための目的に限定します。 もし論点が複数存在する場合には、論点ごとにドキュメントを分割しています。

背景

このセクションには、目的に記載した、意思決定の検討事項や論点に至るまでの背景や経緯について記載します。 すでに他のドキュメントでまとめられていることも多いため、他ドキュメントのリンクを貼ることもあります。 もしくは、Notionの「Copy&Sync」機能を使って他のドキュメントの一部を切り出して添付したりして、簡潔に背景を理解できるようにしています。

あまり長く書きすぎると読み手の理解も低下するため、シンプルに記述することを心がけています。 また後述するように、ビジュアルなどを活用することも効果的に思われます。

概要

このセクションには、良い意思決定をするために必要な情報について簡潔にまとめています。 主な情報は以下の通りです。

  • 現状システムの整理
  • 検討した選択肢・代替案
  • 意思決定の軸
  • 最終的な決定事項・結論

選択肢とそれらから一つを選び出す基準作りは、意思決定の質を決める重要な要因になるため、十分に検討しきれているか注意します。 また、意思決定の軸が先に決まっていることにより、選択肢の早期な枝刈りも可能になります。

例です。各ポイントに重みをつけることも重要です。

これらの情報をまとめた上で、最終的な結論も記載します。

詳細

概要に記載した項目について、実際の調査結果や緻密なシミュレーションを行い、その結果を記載します。 あらゆる情報を集めたり、厳密な意思決定を行おうとして時間をかけすぎないように注意します。

やってみないと分からないことも多く、一定のリスクを許容しないと先に進めない状況があります。 Notionの「Callout」を利用して、受け入れたリスクなどの注意事項については明示しています。

また、概要のセクションで決めた意思決定の軸に照らし合わせ、あまり重要でない項目は調査を簡略化するなどして効率化を図っています。

3ヶ月の運用の結果

私の所属するデータプロダクトチームでは、2023年12月に上記のドキュメントフォーマットを決定しました。 それ以降、全ての意思決定ドキュメントをNotionの一つのデータベースに集約しました。 また、開発における設計フェーズにおいては、このドキュメントを作成した上でチームレビューを行うプロセスを導入しました。 これにより、開発フローの中で、本ドキュメントが自然と運用できることを目指しました。

呼び方の問題

このドキュメントを決める際にはDesign Documentを参考にしていたため、当初DesignDocと読んでいました。しかし、実際の運用としては、各検討タイミングにおける意思決定を整理するドキュメントとなっていました。DesignDocのように中長期にわたってメンテナンスされるものを運用することは現実的でありませんでした。のちのち、Architectural Decision Record(ADR)について知りました。こちらの方が実態と近かったため、現在はADRと呼ぶよう変更しています。

また、DesignDocと呼んでいた時期には、実態からずれていることでメンバーが混乱してしまう、といった事象も生じました。実態に沿った形へ名称を統一するなどの取り組みは、混乱を防ぎ意図を正しく伝えることができるため、ドキュメントを浸透させるために注力すべきことだと改めて感じました。

より良い目的設定や、多くの選択肢が出てくるようになった

このドキュメントでは、目的や背景を最初にまとめていきます。その過程で、目的について立ち返るプロセスが発生します。この時、より本質的な目的や問題設定を行えることがあります。実際に、事前の検討段階で工数大と予測して省かれてしまっていた要件がありました。しかし、目的を整理し直してみると、それが営業観点で重要な要件であり、かつ実際には工数もそれほど変わらないと分かったこともありました。

また、選択肢を検討している場合にも、目的を意識しながら進めることができます。例えば、より工数を少なくするためにはどのような手段が取りうれるのだろうか、というように考えることで、新しいツールや技術の採用を検討することにもなります。また、なんとなくやらないといけないと思っていた作業が、目的に照らし合わせると不要であると気づいたこともありました。

意思決定に関する自信の醸成と型化

この3ヶ月で、チーム内で9つのドキュメントが作成され、3人がドキュメントを作成しました。 ドキュメントのレビューはチームメンバーがお互いに行いあい、曖昧な点や検討が不足している部分などについては事前にコメントし合いました。 アーキテクチャ選定に関する意思決定が透明化され、事前にトレードオフなどを認識した上で次に進むようになったため、自分たちの意思決定に自信を持てるようになったのではないかと思います。

また、ドキュメントを作成した3人のうちの1人はチームに来てくれているインターン生でした。 ドキュメントのフォーマットに従うことで、検討した選択肢などを列挙した上で、実装詳細を詰めていく、という意思決定プロセスを体験してもらうことができました。 複雑な検討が必要な開発内容だったものの、良い実装案の提案・実装を行なっていただきました。

加えて、初めてドキュメントを書く際には、書き方に戸惑うことも多いことがわかったため、今後はドキュメントの意図や書き方についてより丁寧に説明していきたいと思っています。 ちなみに、フォーマットを細かく規定することは避け、一般的な意思決定のやり方や思考の仕方について整理することで、自然と書くべき内容を決めてもらうことが出来るようになればと考えています。

ビジュアルの活用

入社以来、これまで多くのドキュメントを書いてきましたが、ひとつ課題に感じていたのが、ビジュアルが不足しがちという問題でした。アーキテクチャ図もそうですが、業務フロー・シーケンス・意思決定ツリーといった様々な情報を文章で表現してしまうことが多く、直感的に理解しにくいドキュメントを作成してしまっていました。

意思決定ドキュメントを正しく機能してチームで運用できるようにするためには、なるべくビジュアルを活用しドキュメントの理解を容易にすることが重要だと考えています。

そこで、Figjamをノバセルの全開発者分のライセンス分購入することにしました。すでに社内でFigmaが導入されていたことや、豊富な機能を持ちつつ利用料もリーズナブルだったことが決め手です。

また、Notion上のビジュアルとしてはMermaid記法を利用することもあります。 自然言語で図の内容をLLMに伝え、Mermaid記法のコードを書き起こしてもらうこともあります。

Figjamは、ドキュメンテーションの他に、以下のようなシーンでも利用されています。

  • チームの振り返りでのホワイトボードとして
  • ブレインストーミングの場として
  • 意思決定ツリー・マッピングなど、ディスカッションの補助資料として

フローチャートもこの通り。

Figjamの導入は、ドキュメンテーションのみならず、コミュニケーションにおいても大きな助けとなるツールになりました。

まとめ

本記事では、エンジニアのためのより良い意思決定のために、ドキュメンテーションを頑張っていますという話についてご紹介しました。 State of DevOps Report 2023 でもドキュメンテーションの重要性は強調されています。 今回3ヶ月という短い期間での取り組みではありましたが、実感できる効果もあり、今後も改良を重ねつつ続けていきたいと考えています。

一方で、このようなドキュメントが、後々振り返った時のチームや個人への糾弾の材料となるのではないかと危惧したこともありました。 しかし、この3ヶ月の運用の中でその懸念は杞憂だと思うようになりました。 透明性の高いドキュメントに情報がまとめられ、チームのレビューフローにも組み込まれるようになったことで、誰かひとりの責任になることはありません。 そして、このプロセスを踏むことにより、意思決定の質を担保することが出来るようになりました。 また、必要な情報がしっかりとまとめられていることにより、振り返りの際にも建設的な議論が出来るように思います。

エンジニアリングとは問題解決の手段であり、よりシャープな問題設定・解決策を提示することも重要なスキルの一つです。ドキュメンテーションがその助けとなることを感じることが出来た3ヶ月でした。