TECH PLAY

株式会社カケハシ

株式会社カケハシ の技術ブログ

367

はじめに こんにちは!プロダクトマネージャーの高橋です。 こちらの記事はカケハシAdvent Calendar 2023 Part2の9日目の記事になります。 adventar.org Part1もあるのでぜひそちらもご覧ください! adventar.org カケハシに入社して4か月が経ちました。入社してからは新規事業で薬局向けの新規SaaSプロダクトを担当しています。 この記事では、前職まではECなどtoCプロダクトを中心に経験してきた僕がtoBプロダクトに挑戦してみてどうだったかを書いていこうと思います。 toCプロダクトとtoBプロダクトで感じた違いや学び直し 医療バックグラウンドがない…
アバター
本記事は カケハシ Advent Calendar 2023 9 日目の記事です。 adventar.org Musubi 開発チームの加藤です。1 年ぶり ですね。 皆様は 2023 年をいかがお過ごしでしょうか。 今年 Musubi 開発チームは多くのリソースを使って技術的負債の解消を行いました! 今回はその内容の一部を報告します。 バックエンドの完全サーバレス移行🎉 2022 年から、サービス開始時の AWS Elastic Beanstalk から、AWS Lambda + Amazon API Gateway のサーバレス構成へ移行を開始しており、今年ついに完了しました! 移行のモチ…
アバター
カケハシに興味を持ってくれた人と会話する中で働き方の部分でも多くの質問をいただきます。 そこで普段いただくような質問に対してこの記事で回答してみようかなと思います。 前提 チーム個別で異なる部分もあるので、全社共通な質問内容に対する回答を記載しています。 よくいただく質問 リモートワークについて リモートワークをしている人が多く、特にエンジニアはほとんどの人がリモートワークで、北は北海道、南は沖縄まで全国に散らばって仕事をしています。 かくいう自分も入社して3年経ちますが、出社した回数は片手で数えるくらいです。 リモートワークで働く人が多いので、リモートワークナレッジのようなものの高まりは感じ…
アバター
カケハシでデータサイエンティストとして働いている蓑田です。 こちらの記事は カケハシ Advent Calendar 2023 の8日目の記事になります。 今回はTensorFlow Probability(以降、TFPと呼ぶ)を使って独自の確率分布を定義するための方法について書いていこうと思います。 みなさんさまざまな領域でデータを活用されていると思いますが、得られたデータの背後には色々な事象が存在しています。たとえばカケハシでは薬局での処方データや採用している医薬品のデータが得られていますが、同じ効用でも複数のメーカーの医薬品を扱っていたり1、毎年メーカーが切り替わっていたりします。医薬品…
アバター
こちらの記事は カケハシ Part1 Advent Calendar 2023 の8日目の記事になります。 こんにちは! カケハシでMusubi Insightの開発を行っている高田です。 Musubi Insightは、立ち上げ当初よりフロントエンドフレームワークにAngularを採用していましたが、この度、React(Next.js)にリプレイスしました。 今回は振り返りも兼ねてその経緯やリプレイスまでの流れ、リプレイスを通して得られたメリットなどをまとめていきます。 ※技術的な内容はまた別記事にまとめたいと思います。 なぜリプレイスしたのか? Musubi Insightはカケハシの中で…
アバター
こちらの記事はカケハシ Advent Calendar 2023の7日目の記事になります。 adventar.org こんにちは、カケハシで Musubi 開発チームのバックエンドエンジニアをしている関です。 Musubi の開発工程でたまに発生するヒューマンエラーやルーチンワークを Semgrep を利用して削減することができたので記事を書かせていただきます。 Semgrepとは Semgrep は、コードのセキュリティやバグを見つけるための静的解析ツールで、パターンマッチングとプログラムの抽象構文木(AST)を使用して、検索パターンや条件に一致するコードを見つけます。これにより、コード内の…
アバター
はじめに こちらの記事は カケハシ Advent Calendar 2023 の 7日目の記事になります。 adventar.org カケハシの患者リスト開発チームでスクラムマスターをしている松本と申します 患者リスト開発チームでは、10月以降技術負債解消の取り組みを変更しました この記事では、チームで抱えていた技術負債の解消についての悩みとチームでどうやって解決したかについて、書きたいと思います 患者リスト開発チームでの技術負債の定義 患者リスト開発チームでは以下のような問題を技術負債と捉えております ソフトウェアの内部的な問題 設計上の問題点 自動化できるはずの箇所の手動処理など セキュリ…
アバター
この記事は カケハシ Advent Calendar 2023 の19日目の投稿になります。 東 浩稔(あずま ひろとし)と申します。 私は、カケハシでデータプロダクトのPdM(プロダクトマネージャー)を務めております。 2023年の7月に入社し、全社のデータ利活用を促進するため、データプロダクトの整備・強化に取り組んでいます。 今回は、9月にDatabricks AI World Tour Tokyo 2023で発表した「 データガバナンスの視点から見たデータメッシュアーキテクチャ 」を元に 当社のデータメッシュアーキテクチャの詳しく掘り下げて解説いたします。 本書を読むことで得られること データメッシュアーキテクチャを段階的に検討するための手法やヒントが得られます。 当社はなぜデータメッシュアーキテクチャか? 当社では、患者様や薬剤師様の医療体験を向上させるため、さまざまなプロダクトを活用し、目的に応じた最適なソリューションを提供しています。これらのプロダクトはそれぞれ専門チームが担当し、今後も新たなプロダクトの追加に伴い、担当チームが増加する見込みです。 このような状況から、中央組織であるデータ基盤チームが複数のプロダクトチームのETLを担当することはスケールしきれないことが予測できました。今後のプロダクトや組織の拡大に備え、データプロダクトを再構築する必要性が生じました。 その結果、各プロダクトチーム(ドメインチーム)が、自身のデータに責任を持つデータメッシュアーキテクチャを採用し、データ利活用もスケールすることを目指しました。 ※図:中央集権型(データレイク)と分散型(データメッシュ)の比較 データメッシュアーキテクチャを推進するヒント(全体像) 私が入社した時点で、すでにデータメッシュアーキテクチャが採用され、そのためのデータプラットフォームが稼働していました。(図1の原則3の箇所) ところが、実際の運用では、中央組織がETLを担当する体制が継続していました。この状況は、人員不足によりアーキテクチャを整備するためのリソースが不足していたことや、アーキテクチャのポリシーが不透明であり、ドメインチームが適切に利用できる状態にはないことが主な要因でした。(下図1の原則1と2の箇所) ※図1:データメッシュ4つの原則 そのため、まずはデータメッシュに適合するためのデータアーキテクチャのポリシーの整備から着手することにしました。 データメッシュアーキテクチャを含むアーキテクチャ設計には、複数の論点があり、これらの整理する際には前後関係を考慮しないと矛盾が生じたり、設計の破綻や整合性の欠如が起こる可能性があります。 したがって、データアーキテクチャをレイヤー別に整理することにしました。以下に、データメッシュアーキテクチャを整備するために検討が必要なレイヤーを示します。 ※図2:データアーキテクチャの検討レイヤー データアーキテクチャでは、下記のような検討すべきポイントがあります。それぞれを各レイヤーに分けて検討をします。 コンプライアンス 論理アーキテクチャ 接続方式 セキュリティ データ品質 物理アーキテクチャ レイヤー別の検討ポイント 以降に、各レイヤーでの検討の論点を整理します。これらは上から順に整理します。 1. コンプライアンス コンプライアンスレイヤーは、法的規制や業界の標準に準拠し、データのプライバシーとセキュリティを保護する基盤を提供します。 本章では、個人情報法および医療情報システムの安全管理に関するガイドラインを解釈し、実装すべき安全管理措置などをデータプロダクトとして検討します。 下記に、検討するポイントの例を記載します。 情報区分の定義 情報区分ごとの安全管理措置 仮名化/匿名化の加工方針 暗号化方針 冗長化方針 モニタリング方針 アクセス制御方針 ライフサイクルごと方針の定義 取得 利用 保存 削除方針 2. 論理アーキテクチャ 論理アーキテクチャは、データの流れや処理方法を体系的に組み立て、データアーキテクチャの全体像を整理する上での基盤となります。 本章では、上位のコンプライアンスの実装方針に基づき、データをどのステージに配置するか、それらのデータをどのようなフローで運用するかを検討します。 ※図:論理アーキテクチャの例 下記に、検討するポイントの例を記載します。 メダリオンアーキテクチャのステージにおけるデータの配置と、それに基づくインタフェースの検討 Bronze、Silver、Goldへのデータ配置 データ提供者が公開するインターフェイス Bronze、Silver、Goldをさらに細分化し、仮名加工情報、匿名加工情報を配置するステージの検討 3.接続方式 データ連携は、データソースとデータプロダクト間、データプロダクト内でのデータ提供者と利用者間での共有を可能にするプロセスです。 本章では、上位の論理アーキテクチャの方針に基づき、連携の方式、プロトコル、方向、起動タイミング等を検討します。 ※図:連携方式の例 下記に、検討するポイントの例を記載します。 連携方式 バッチ連携、ストリーム連携等 データ連携方向 Pull型、Push型等 データ形式 ファイル、メッセージ等 起動タイミング スケジューラー、イベントトリガー等 4.セキュリティ データセキュリティは、データの保護と管理の側面から検討します。 本章では、上位の論理アーキテクチャとデータ連携の方針に基づき、アクセス制御、暗号化、監視と検知等を検討します。 下記に、検討するポイントの例を記載します。 ロールの定義 データプロダクトを利用するロールおよび権限モデルの定義 アクセス制御 論理アーキテクチャで定義されたインターフェイス、データステージごとのアクセス制御方針等 暗号化 通信や保管時の暗号化 暗号化アルゴリズムの強度 サーバ、クライアントのどちらで暗号化を行うか 監視と検知 論理アーキテクチャで定義されたインターフェイス、データステージごとの監視と検知のレベルの定義 5.データ品質 データの価値を最大限に引き出すためには、品質が重要です。 本章では、上位のレイヤーに基づき、データ品質の重要性にフォーカスし、正確性、完全性、一貫性、信頼性等のデータ品質について検討します。 下記に、検討するポイントの例を記載します。 データ品質 データ品質の特性の中から採用する項目 データ品質の確認箇所 論理アーキテクチャで定義されたデータステージごとの品質を確認する箇所 役割分担 データ品質の特性ごとに、ドメインチームとガバナンスチームのそれぞれが実施する内容を定義 データ品質のレベル 確認範囲のレベル設定 必須項目と任意項目の定義 エラーレベルに基づいたアクション方針 6.物理アーキテクチャ 物理アーキテクチャは、データの処理とストレージの実装方法を考慮し、システム全体の効率性と信頼性を確保します。 本章では、上位のレイヤーに基づき、具体的なコンピュートリソース、データストレージ、ネットワーク構成などの物理アーキテクチャを検討します。 当社では、DatabricksとAWSを利用しています。これらの機能を使用して実際の設計を行います。 下記に、検討するポイントの例を記載します。 ワークスペースとアカウントの分離 Databricksのワークスペース AWSアカウント管理 ストレージ ストレージクラス データの保持期間 暗号化 コンピュートリソース Databricksのリソース SQL Warehouseのクラスタサイズ まとめ この記事では、データメッシュアーキテクチャの段階的な検討を通じて、物理アーキテクチャの設計プロセスについて解説しました。 今回は、詳細な解説はしていないため、今後も継続してデータプロダクトについて発信していく予定です。 この記事が皆様のお役に立てれば幸いです。 最後に 当社では、日本の医療体験をアップデートするため、薬局のDXに取り組んでいます。そのために、センシティブな個人情報を安全に保護しつつ、最大限活用するためにデータメッシュアーキテクチャを採用しています。 このようなチャレンジングな環境で成長し、当社のミッションやビジョンに共感いただける方は以下からのご応募をお待ちしております。また、カジュアルな面談も随時受け付けております! ランキング参加中 プログラミング
アバター
こんにちは! AI在庫管理で開発ディレクターをしている、兼平という名の🐷が好きなものです。 この記事はカケハシ アドベントカレンダー part2の6日目の記事です。 去年筋トレしたくてカケハシに転職した という話を書いてから1年が経ったので、これまでの筋トレの日々をふりかえりたいと思います。 一緒に筋トレしてくれる仲間が増えた! プロダクトのPMFを目指すフェーズの中、日々メンバーも増え、なかなか状況が追いきれずに1人で悩むことも多い日々を過ごしていました。 そんな中、2月に同じロールで自分よりツヨツヨでマッチョな同僚さんがjoinしてくださり、フィードバックをもらうことでトレーニングが加速し…
アバター
こちらの記事は カケハシ AdventCalendar 2023 の5日目の記事です。 はじめに こんにちは。カケハシのAI在庫管理チームに所属している梅田です。 私は2年程前に、カケハシのCS(カスタマーサクセス)チームに加わりました。 カスタマーサクセスとは、プロダクトを利用していただいているお客様に伴走し、お客様の業務がより良くなるようにサポートする役割を担う仕事です。 そしてタイトルの通り、今年の10月から新たな役割としてフロントエンジニアとしてのキャリアをスタートさせました。 このブログでは、これまで開発やプログラミングの経験がまったくなかった私が、CSの仕事からエンジニアへと進むこ…
アバター
こちらの記事は カケハシ Part1 Advent Calendar 2023 の5日目の記事になります。 こんにちは、カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。 Musubi Insight ではデータ集計バッチに AWS の GlueSparkJob を採用しているのですが、この GlueSparkJob のログレベルを設定することで CloudWatch へのログ収集(DataProcessing-Bytes)にかかっていたコストを98%も削減することができました!! GlueSparkJob を使われているエンジニアの方にぜひ知っておいていた…
アバター
こちらの記事は カケハシ Advent Calendar 2023 の 4日目の記事になります。 こんにちは。カケハシでエンジニアをしている今川です。 今回はこれからフロントエンドの技術選定をする方向けに、どんな技術・ツールを使えばいいかのヒントになるような記事を書いていきたいと思います。 ただし、本記事では個人的な好みというよりは、npm trendsやGitHub Star Historyなど客観的な指標からどんな技術が世間に受け入れられているかの比較にしていきたいです。 もちろん数値などの比較以外に、ドキュメントを読んだり使ってみたりすることも重要だということは言うまでもないと思います。…
アバター
カケハシでデータサイエンティストをしている島吉です。 こちらの記事は カケハシ Advent Calendar 2023 の4日目の記事になります。 A/Bテストなど、ある2つのグループ(2群)の特徴に差があるのか検証したい場面があります。このとき、t検定などの仮説検定の手法を用いることで、有意差があるかどうかを判定できます。しかし、有意差があると判定されたときの2群間の差が、検証したい差の大きさと一致しているかどうかは、直感的にはわかりにくいと感じることがあります。そこで、仮説検定に代わる方法を調べてみたところ、ベイジアンA/Bテストという方法が見つかったので、それについて紹介します。 ベイ…
アバター
こちらの記事は カケハシ Advent Calendar 2023 の3日目の記事になります。 こんにちは、カケハシで Musubi AI在庫管理 の開発をしているMLエンジニアの藤本です。 Musubi AI在庫管理 ではS3に出力している内容に関する分析用テーブルの管理にAWS Glue Crawlerを利用しています。 今回は、分析用テーブルを管理する際のAWS Glue Crawlerの使い方と注意点について紹介できればと思います。 Musubi AI在庫管理でのAWS Glue Crawlerの利用方法 Musubi AI在庫管理(以下、AI在庫)では適切な在庫管理を行う為、以下の予…
アバター
はじめに テックブログは技術広報において強力なツールです。その一方テックブログを始めてみたものの、なかなか記事を書いてくれる人がいなかったりView数も伸びなかったりで、続けることができないことがあります。 そのためテックブログの更新頻度が下がることで読者の減少や印象の低下することを懸念し、ちゃんと運用できないならやらない方がいいという判断になっているという話も見聞きします。 幸いカケハシのテックブログは立ち上げてから2年間継続して運用することができており、採用活動の場でもテックブログ経由で応募してくれる人も出てくるなど、自社を認知してもらうきっかけになっています。 この記事ではテックブログを…
アバター
こんにちは。 AI在庫管理というプロダクトでフロントエンドの開発を担当している大村です。 AI在庫管理開発チームでは、顧客に素早く価値を提供するためにフロー効率を重視した開発を行っています。 本記事では、なぜフロー効率を高めようとしているのかと、どのような取り組みによってフロー効率を高めているかについて紹介します。 リソース効率とフロー効率 生産性の効率の考え方として「リソース効率」と「フロー効率」があります。 複数人の開発者がチームでソフトウェアを開発するシーンを想定し、リソース効率とフロー効率それぞれを重視した場合の仕事の流れを単純なモデルとして表現してみました。(ここでは仕事の1つ1つを…
アバター
はじめに こちらの記事は カケハシ Advent Calendar 2023 の 2日目の記事になります。 https://adventar.org/calendars/8587 こんにちは。患者リストというサービスを開発している金です。 患者リストチームは1年以上Github Projectを使っていました。 メリットもありましたがチーム内ではデメリットの方を多く感じて、結局JIRAに移行することになりました。 JIRAに移行してからは弱3ヶ月ほど経ちました。 この記事では スクラム開発をしている患者リストチームがGithub ProjectからJIRAに移行を決めた背景と、 その変更によっ…
アバター
Musubi AI在庫管理の機械学習エンジニアをやっている中野です。 こちらの記事は カケハシ Advent Calendar 2023 の1日目の記事になります。 昨年はprophetについて書きましたが今年は勾配ブースティングにしました。 医薬品や食料品、アパレルなどの需要予測において平均値ではなく95%点や99%点を要求されるケースがままあります。 例えばコンビニおにぎりの在庫管理において需要予測の平均値だけ発注していれば2回に1回程度は欠品してしまうでしょう。こういった場合に予測の95%点を発注すれば欠品をおよそ20回に1回へと低減できます。 GBDTでもこのような確率点を返す予測が可…
アバター
はじめに こんにちは!ソフトウェアエンジニアの種岡です。 私たちのチームでは、TypeScriptを使用して開発を行っており、Prettierというコードフォーマッターを利用し、チーム内でコーディングスタイル統一に大変重宝しています。 そんなフォーマッター界隈で、Rust製で爆速で動作すると噂のdprintが良いということで試してみたところ、驚くべきことが起きました! Prettierでは、コードフォーマッティングに 7.69秒 かかっていたのですが dprintを使うことでわずか 0.47秒 で完了するようになりました🚀🚀🚀 なんと、 10倍以上速い とういう結果に! コードフォーマットは、…
アバター
こんにちは、カケハシで Musubi 開発チームのバックエンドエンジニアをしている関です。 Musubi 開発では、 Python の Linter と Formatter に Flake8、isort、Black を使用しておりました。しかし Rust で書かれた Ruff という高性能なツールが出たということで、置き換えてみたら爆速になった(15倍以上速くなった)ので、Ruff について記事を書かせていただきます。 今回は Ruff を導入した経緯や実運用に至るまでの工程を紹介したいと思いますので、最後まで読んでいただけると嬉しいです。 Ruffとは Ruff は、2022年8月にリリース…
アバター