はいさい！カケハシの新米メンバー、オースティンと申します。 沖縄から参上しております！ 概要 RxJS のmergeMapとswitchMapの違いと使い方について解説します。 背景 Observableを使っていると、必ず直面する問題があります。それは、複数のObservableをどうやって一緒に実行できるか、という問題です。 とあるObservableの処理が終わった後に、そのデータを元に、別のObservableでさらに非同期処理をすることは開発者として多々あります。 Promiseのthenでまた別のPromiseを返してチェーンしていくのと同じことです。 しかし、RxJS では、Promiseと違ってObservableを直列にチェーンするのに使うpipeのOperatorFunctionが複数存在します。代表的なのは、mergeMap、mergeWith、およびswitchMa

こんにちは！カケハシにて薬局と患者の関係性を向上させるためのツールである 患者リスト というWEB業務アプリケーションを開発している小室と申します。 本プロダクトのフロントエンドの開発環境としては、React + esbuildを採用しており、採用の経緯や実践している環境構築方法などは以下の通り、TechPlayやQiitaなどに記事を投稿してきました。 TechPlay: 新規事業プロダクト開発時の技術選定どうやった？ スライド Qiita: esbuild + React(TS) で実現する超軽量な開発環境 しかしながら、esbuildは標準でsassに対応しておらず、今までの環境ではCSSを利用していたのですが、プロダクトの成長と共にCSSで書き続けることが苦痛になってきました。 そこで、本記事では React + esbuildの爆速開発環境に、さらに sass を導入していく方法

こんにちは、株式会社カケハシでおくすり連絡帳 Pocket Musubiの開発を担当している渡辺です。 プランニングポーカーをご存知でしょうか？ アジャイル開発における規模の見積もり手法の1つです。やり方は、それぞれメンバーが数字のカードを持ち、対象のタスク（もしくはユーザーストーリー）に対して、自分が考えた規模の数字カードを出し合います。一致すればその数字、一致しない場合は、なぜその差分が生じたのかを議論します。 弊社では、見積もりするタスクのゴールを定義し、知見のある人や担当する予定の人にHowの部分を説明いただきます。そこで議論をした後、自分が思うタスクのポイントを出します。ポイントはフィボナッチ数列を用いています。 弊チームでは、タスクの分割もエンジニアが行なっています。担当するエンジニアがタスク分割してから見積もりに臨みます。エンジニアがタスク分割することでリスクを下げています。

こんにちは。 カケハシでMusibi Insightのバックエンドエンジニアをしている高田です。 Musubi Insightとは、薬局の経営改善に役立つさまざまなデータを可視化しているプロダクトであり、そのデータはAirflowとAWS Glueを利用した日次の夜間バッチ処理によって生成されています。 バッチ処理に使っている技術や仕組み等は、以下の記事で紹介させていただいています。 そんなバッチ処理を、パフォーマンス改善や新たな機能追加のための準備としてリファクタリング行なうことがあります。 ただ、バッチ処理のリファクタリングはテストがしづらかったり、思いもよらぬ形で後続の処理に影響を与えてしまう可能性があったりと、なかなか神経をすり減らす作業となっていました... そこで、この度リファクタリング後の検証を効率よく確実に行う処理を構築したので、本記事にて紹介できればと思います！ Musu

こんにちは、株式会社カケハシでおくすり連絡帳 Pocket Musubiの開発を担当している渡辺です。 RxJS RxJSはリアクティブプログラミングのライブラリです。 リアクティブプログラミングって何かと言いますと、 データを受け取るたびに反応(リアクション)をするプログラムです。 たとえば、 of(1, 2, 3).subscribe({ next: (value) => console.log(value), }); とすると、1, 2, 3の順番にデータを受け取り、受け取ったデータごとにnextが反応します。 このデータの流れをStreamと呼びます。 Streamを購読（subscribe）して、データやイベントが流れてくるたびに反応します。 そして、Angularでの基本技術になります。 そのため、RxJSを理解しないとAngularで良いコードを書くのは難しいのです。 私たち

こんにちは、カケハシでデータ基盤チームの開発ディレクターをしている松田です。 2022年に、「カケハシはデータについて本気で取り組んでいくぞ！」と意気込み、 全社横断的な組織としてデータ基盤チームを組成しました。 今回はそのデータ基盤チームについてと今後の取り組む重点的課題について紹介して、 本気度を感じてもらえればと思っています。 全社横断的なデータ基盤チームfumidonoの誕生 今までのデータ基盤チームは、Musubi Insightを開発するプロダクトチームと同じチームに属しており、Musubi Insightにデータ提供をすることがメイン業務でした。その傍らで全社的なデータ利活用の支援観点でRedashの運用をしていました。 当初は、顧客にBIツールを提供しているチームのもとでデータ処理に責務を持ちバリューを発揮していたのですが、全社的なデータ利活用推進にほとんど力を避けていない

概要 こんにちは。PocketMusubiチームの南光です。 今回は、ローコードツールを利用してアプリを開発した際に工夫した内容を記事としてまとめました。 ローコードツールの開発知見記事はあまりみない気がするので、興味を持っている方やこれから利用を検討している方の参考になれば幸いです。 ローコードツールとは ローコードツールの定義が曖昧な方も少なくないのではと思うので、一応wikiの抜粋を記載しておきます。 ローコード開発プラットフォーム (英: low-code development platform, LCDP) (ローコード(英: LowCode)とも言う)は、従来の手書きのコンピュータ・プログラミングの代わりに、グラフィカル・ユーザ・インタフェースと設定を通じてアプリケーション・ソフトウェアを作成するために使用される開発環境を提供するソフトウェアである。ローコードモデルにより、様

こんにちは、あるいはこんばんは(アーニャ声)。 突然ですが認証認可周りの設計・実装は毎回全然違った要件に沿って違った感じでやっていく感じになるのでおもしろいですよね。 この記事では、先日Musubi Insightチームが社内向けに作成したコンソールの設計・実装について認証認可周りに絞ってまとめたいと思います。 認証認可はCognito User Groupベースで実装したのですが、意外とネットの情報が少なかったので参考になれば幸いです！ なおブログ中に登場する画面のスクショについてなのですが、普段フロントエンドをほぼ触らない筆者がサクッと作ったものですので、デザインなどあれな部分もあるかと思います。ご容赦くださいませ(アーニャ声でごまかす) 背景 この社内コンソール(以下、Kizuki Consoleとよびます。Kizukiはチームの名前です。)が作られた理由は、Musubi Insig

概要 薬局運営のデータ分析サービスである Musubi Insight のフロントエンド開発をしております米山と申します。 Musubi Insight のフロントエンドは Angular で開発されており、テストフレームワークには jasmine/karma を利用していました。 この度、jasmine/karma から Jest に移行しましたので、移行の記録を書いていきます。 移行理由 jasmine/karma は Angular のデフォルトのテストフレームワークです。 しかし、JavaScript のテストフレームワークとして、jasmine/karma の利用人口が減少傾向にあることが気になっていました。 (state of js 2021 より) という理由が1点。 さらに、データ分析サービスである Musubi Insight では、巨大な JSON データを扱うことがよ

はじめに こんにちは、KAKEHASHIのMusubiInsightチームでエンジニアをしている高田です。 MusubiInsightとは、薬剤師さんの業務データを可視化するBIツールになります。 そんなMusubiInsightにおいて、表示の高速化を狙いにServiceWorkerという技術を導入したので、紹介したいと思います。 MusubiInsightの課題 ServiceWorkerが何か、という話をする前に、MusubiInsightの課題について触れておきます。 ありがたいことに、MusubiInsightのユーザー数は堅調に増加していますが、それに伴いパフォーマンス低下の課題が浮き彫りになってきました。 特に、薬局数や薬剤師数の多い法人様では1リクエストでのAPIの計算量が大きく、なかなかレスポンスが返ってこないために、ユーザー体験を損なってしまっていました。 そこで、チー

はじめに こんにちは、Pocket Musubi エンジニアの関(@sekikazu01)と申します。 「あ〜アイコン大量に増えた時逐一画像を書き出して Icon コンポーネントに反映させるのめんどくせ〜〜〜」 そんな風に思った事はないでしょうか。私は思いました。 ので Figma のアイコンコンポーネントからコードに反映するまでのパイプラインを作りましたので、そのコードを公開していきます。 この記事はアイコンの生成の話ですが、一回作っておくと他にも画像だったりコンポーネントだったり諸々の生成パイプラインを作る時にも役立つと思います。 また、敬意を表すべくこのパイプラインを作るにあたって参考にさせていただいた先人の記事を紹介しておきます。 やっていることは 9 割方同じなのですが、デザイナーがアップデートした時に Figma から変更通知できるような Widget を作ってみたのが、この記

はじめに こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubi というサービスを開発している種岡です。 弊社では、ソフトウェアエンジニアそれぞれが得意分野をリードしながらも、フロントエンド、バックエンド、インフラを横断的に見ているケースが多いです。 プロダクトデリバリーに対して裁量が多く、やりがいが大きい一方で、安定運用に対しても責任が伴います。 とくに、薬局の薬剤師さんや患者さんが利用するというプロダクトの性質上、個人情報や機微な情報を取り扱うため、セキュリティに関しては開発時から意識せざるを得ません。 この課題に対して、チームでは開発中の段階から OWASP ZAP という脆弱性診断ツールを利用しています。 そこで、本記事ではOWASP ZAPツールの操作方法を紹介します。 OWASP ZAPについて OWASP ZAPは脆弱性診断ツールで、以下のような特長があります

概要 こんにちは！私はカケハシにて薬局と患者様の関係を向上させるためのオペレーションツールである 患者リスト の開発を担当している小室と申します。患者リストの立ち上げから担当させて頂いており、技術選定などのお話は先日はTechPlayでも登壇させて頂きました。( 登壇資料 ) 本記事ではそんな 患者リスト から、弊社のメインプロダクトとなる Musubi へDeepLinkで連携した際の知見をまとめたいと思います。 背景 そもそもなぜDeepLinkが必要になったかというと、患者リスト では患者様をリストアップする機能があるのですが、その患者様が薬局に来局された際の処方内容や服薬指導内容等の詳細なログは薬歴業務システムである Musubi で閲覧する事ができます。Musubiは、Electronで作成されたDesktopアプリケーションになりますので、Musubiの患者詳細ページにDeep

はじめに こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubi というサービスを開発している種岡です。 日頃もくもくと開発作業に勤しむ傍ら、ときどきユーザーからの生の声（良くも悪くも）が届くのは嬉しいものです。 サービスが成長している1つの証である一方で、ふと「サーバーへの負荷大丈夫なんだろうか？」と頭をよぎり心配になります。 この記事では、AWSが提案している負荷テストソリューションの使い方を紹介し、ボトルネックを早期発見および、安定的な運用につながればと思い筆を取りました。 AWSの分散負荷テストソリューションとは AWSの公式より全体構成を抜粋しています。 AWSが用意するCloudFormationを利用すると上記のソリューションが数分でデプロイされ、すぐにテストを実施できる環境が用意できるという代物です。 ざっくりとまとめると以下のようになります。 負荷テストの

こんにちは、カケハシでMusubi Insight のバックエンドエンジニアをしている高田です。 私はカケハシへの入社と同時に兵庫県移住し、現在フルリモートで勤務しています。 そのため自室=職場であり、より生産性が上がり、気持ちよく働けるよう環境を改善したいと前々から考えていました。 そこで、冬休み使って職場（自室）の環境改善を行なったので、その内容をご紹介できればと思います。 解決したい課題 とくに冬場になり、仕事開始時の室温が低く、集中し始めるまでに時間がかかるという点を課題に感じていました。 実際に快適な室温を保つことで、タイピングミスが減ったり、一定時間内のタイプ量が増えるなど、生産性が上がるという調査結果 も報告されています。 もともと寒がりな体質ということもあり、こちらを重要課題として取り組むことにしました。 解決策 今回課題を解決するにあたり、以下のような要件を設けました。

こんにちは、株式会社カケハシでおくすり連絡帳 Pocket Musubiの開発を担当している渡辺です。 カケハシのエンジニアはフロントエンドもバックエンドのAPIサーバーも開発を担当しています。どちらかといえばフロントエンドの方が知識・経験ともに自信があるという背景から、今回はカケハシのフロントエンドエンジニアについて書きます。 カケハシでのフロントエンドエンジニア カケハシであまりフロントエンドエンジニアという表現は用いず、アプリケーションエンジニアという表現を用いています。 アプリケーションとして価値を生み出すことが主眼であって、それがフロントエンドの領域であろうがバックエンドの領域であろうが問わず、価値を出せるかが大事なのです。 フロントエンドエンジニアとしての価値向上 とはいえ、フロントエンドエンジニアとしてスキルを積み上げてきた人は、なかなかやってきたこと以外にまで手を広げるのは

カケハシで開発ディレクター／スクラムマスターをやっている三浦です。 この記事では、スクラムのプラクティスを通じてより優れたチーム・組織を作っていくためにはスクラムだけでは不十分であり、その効果をさらに引き出すための工夫を組織学習の側面からどのように考えたらよいかを大雑把に書いていきます。 以下のような方に読んでいただけたら嬉しいです。 開発組織・チームとしての学習機会について悩んでいる方 業務と学習の住みわけ・バランスについて悩んでいる方 「学習」というと個人のお勉強というイメージを持ちやすいかもしれませんが、ここでは組織・チームとしての知識の変化、行動の変化、認知（モノの見方・捉え方）の変化、習慣の変化なども「学習」とみなして考えていきます。 なぜ組織学習が大切なのか 私たちは、自分たちがより優れたチームとなって成果を出していくためには継続的な改善活動が重要だと考えています。そして、より

こんにちは、プラットフォームチームの石黒です。あっという間に今年が終わりますね🎄 この記事は、カケハシアドベントカレンダー2021の6日目の記事です。 本日はアカウント管理機能というサービスで使用している技術スタックを紹介します！ アカウント管理機能について カケハシで提供している4つのプロダクト（Musubi、Musubi Insight、Pocket Musubi、Musubi AI在庫管理）は共通の認証基盤を利用しており、全プロダクト横断のお客様向けアカウント管理機能の開発・運用を我々プラットフォームチームが行っています。 プラットフォームチームにつきまして、プロダクトマネージャーの金田が書いたブログがありますので、是非そちらも御覧ください✨ システム構成 フロントエンド アカウント管理は少人数で開発を始めたこともあり、フロントエンドは特に開発スピードを重視した技術選定がされていま

この記事は、カケハシアドベントカレンダー2021の5日目の記事です。 SREチームとCorporate Engineeringチームのディレクター兼スクラムマスターをやっています、尾形です。今回はカケハシのSREチームが、今どのようなことに取り組んでいるのか、そして今後どうしていこうと考えているのかについて書いていこうと思います。 そもそもSREとは Site Reliability Engineeringの略で、もともとはGoogle社が提唱したものです。Site Reliability Engineeringというそのままの題名の書籍が、英語版・日本語版それぞれあり、英語版は無償で読むことができます。SREという言葉の提案者によれば、「SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがる」と述べています。では運用とはなんでしょうか。サーバーやネットワークの構築・設

こちらの記事はカケハシ Advent Calendar 2021の3日目の記事になります。 こんにちは。 この秋リリースしたMusubi AI在庫管理の開発を担当している平松です。 上記プロダクトのインフラ構成管理にTerraformを用いています。 今回は採用しているTerraformのディレクトリ構成について紹介したいと思います。 背景 カケハシではインフラ構成管理ツールとして何を採用するかは、各チームの判断に委ねられています。 現在では、TerraformとAWS CDKを採用しているチームが多く、おおよそ半々くらいです。 今回開発を行ったMusubi AI在庫管理は、 新規プロダクトでより早く立ち上げる必要があった チームメンバーにTerraform経験者がいた といった状況であったので、Terraformを採用しました。 今回はAWS CDKを採用しませんでしたが、インフラをTy