こんにちは。カケハシの Musubi AI在庫管理 チームで業務委託のエンジニアとして開発を行っております山田です。こちらの記事は カケハシ Advent Calendar 2021 の17日目の記事になります。 本記事では、AWS Systems Manager Session ManagerとAWS FargateでプライベートネットワークのRDSにアクセスするための踏み台サーバーを構築した際に、AI在庫チームが遭遇した問題の解決策や便利な設定をTipsとして紹介します。 上記技術スタックの選択を行うそもそものメリットや、実際の構築手順等の基本的な部分の情報に関してはネット上に多くの記事が…

「株式会社カケハシ x TypeScript Advent Calendar 2021」18日目の記事です。 https://qiita.com/advent-calendar/2021/kkhs-ts プラットフォームチームのエンジニアさだです。 私たちの環境ではテストコードもTypeScriptで書いていて、jest + ts-jestを利用しています。 色々な事情があって、プロダクトコード用のtsconfigとは別にテスト用のtsconfigを作らなきゃいけない場合ってありますよね。 そんな方にお伝えしたいのがこちら💁 https://kulshekhar.github.io/ts-je…

こんにちは🎄 プラットフォームチームの石黒です。 こちらは株式会社カケハシ x TypeScriptアドベントカレンダー2021 17日目の記事です。 今回はajvによるJSON Schemaを用いた入力値のバリデーションについてご紹介します。 ajvとは？ APIなどから渡された入力値のバリデーションツールとして、ajvを採用しています。 これは、JSON Schemaを指定するだけでコードを書かずともバリデーションを行ってくれるもので、JSON SchemaのほかにはJSON Type Definitionにも対応しているとのことです。 例えば、以下のようにUser型を定義します。 typ…

こんにちは、カケハシでMusubi Insightのバックエンドエンジニアをしている末松です。 こちらの記事はカケハシ Advent Calendar 2021の 14 日目の記事になります。 半年ほど前の話にはなりますが、Musubi Insight チームにおいてローコードテスト自動化の SaaS であるmablを導入することで、リリースにかかっていた工数を半減させることに成功しました。 今回は、その mabl を導入した背景や実運用に至るまでの工程、そして学びを紹介したいと思います。 mabl の向き不向きなテストやつまづきポイントなども記載してますので、最後まで読んでいただけると嬉しい…

こんにちは☃️ プラットフォームチームの石黒です。 こちらは株式会社カケハシ x TypeScriptアドベントカレンダー2021 13日目の記事です。 今回は、Typescriptでの直列リクエストと並列リクエストを組み合わせた実装についてお話しします。 要件 データの一括処理をしたい データ量はリクエストごとに異なる 処理するシステムは1件ずつしか受け付けられない 処理するシステムのクォータは50件/秒とする 実装方針 データ量が一定でないので、クォータの50件を超過しても問題ないように実装したいところです。 処理システムは1件ずつしか受け付けられないですが、1秒の間隔を空ければ最大50件…

前置き こちらの記事はカケハシ Advent Calendar 2021の12日目の記事になります。 新規事業の開発を担当している木村です。 本来であれば新規事業で利用している技術を紹介したいのですが、まだリリースに至っていないので汎用的なテーマになっております。 カケハシでは何人かの有志が集まって定期的な社内勉強会が開かれております。 私が参加している「データ基盤のトレンド勉強会」では社内横断でデータエンジニアリングにまつわる課題を解決するための様々な視点からの洞察を得るために、最新の技術をキャッチアップしています。 私の個人は、トレンドを無策に追うよりも背景となる概念を理解した方が効果的に…

こんにちは、Musubi開発チームで開発ディレクターを担当している門垣です。 この記事はカケハシアドベントカレンダー2021の11日目の記事になります。 カケハシではコロナ前からリモートワーク環境が整っており、私の所属するMusubi開発チームは全員がフルリモート環境で働いています。長野県や三重県といった遠隔地のメンバーも所属しているため、出社日も設けておりません。 本日は「フルリモートワークのチームがオンライン雑談を6ヶ月続けてみて感じたこと」を共有したいと思います。 フルリモートの会社に転職したいけど少し不安がある 今のリモートワーク環境をもっと楽しくしたい と考えている方の参考になると嬉…

こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubi というサービスを開発している南光(@stnamco)です。 この記事では、Amazon Connectの音声問い合わせを実運用していく過程で遭遇した問題とそのデバッグで得られた知見などを紹介します。 そもそもAmazon Connectとは Amazon Connect とは、AWSが提供しているクラウドのコンタクトセンターを利用するためのサービスで、雑な言い方をするとAWSを利用して電話をかけることができます。 また電話以外にも、インタラクティブなチャット機能や、人工知能 (AI) /機械学習 (ML) を利用したインタラクションの自動化などの機能を低コストで利用することができるそうです。 AWSマンガ第 12 話：短期間でコンタクトセンターを立ち上げろ！ 発生した問題 前述のおくすり連絡帳サービスには処方箋画像を薬局側に送信する機能が提供されているのですが、処方箋画像が薬局に送られた際に薬局へ電話で通知するという機能を実装するためにAmazon Connectを利用していました。 業務フロー ※pockebiはおくすり連絡帳サービスの略称です。 上記機能に対して、特定の薬局から電話をとっても無音で電話が切れてしまうという調査依頼がありました。 その問題解決のために以下のような方法で検証を進めました。 問い合わせ検索から指定のContactTraceRecordを確認。 Cloud Watchのログを確認。 問い合わせ検索から指定のContactTraceRecordを確認 まずは 問い合わせ検索 から、指定の問い合わせのデータを確認しました。 電話番号がわかっていたので、電話番号から対象の問い合わせを見つけました。 余談ですがContact Lensという音声分析を利用した検索Filterもあるそうで、機会があれば触ってみたいなと思いました。 指定の問い合わせを見つけたので、Disconnect reasonを確認したところ、CONTACT_FLOW_DISCONNECTという理由が入っていました。これはフローで通話が切断されたときに入る値です。 対象の問い合わせフロー以外にもDisconnect reasonがCONTACT_FLOW_DISCONNECTになっている問い合わせがありましたが、薬局ユーザに確認したところ問題なく機能が使えていたので、これが原因ではなさそうでした。 ちなみに他の接続解除理由には以下のようなものがあります。 ※ContactTraceRecordのデータモデル CUSTOMER_DISCONNECT: お客様から切断されました。 AGENT_DISCONNECT: 問い合わせがまだ通話中に、エージェントから切断しました。 THIRD_PARTY_DISCONNECT: サードパーティーとの通話では、エージェントが離れた後、問い合わせがまだ通話中にサードパーティーが通話を切断しました。 TELECOM_PROBLEM: 通信事業者、ネットワークの輻輳、ネットワークエラーなどに起因する、通話の接続の問題により切断されました。 CONTACT_FLOW_DISCONNECT: フローで通話が切断されました。 OTHER: これには、前のコードで明示的にカバーされていない理由がすべて含まれます。問い合わせがAPIによって切断された場合などです。 Cloud Watchのログを確認 次にCloud Watchにあげられている問い合わせフローのログから調査を行いました。 ログの有効化をしていれば、新しいAmazon Connectインスタンスを作成した際、Amazon CloudWatchロググループに自動的に収集されます。 ※Amazon CloudWatch ロググループに保存される問い合わせフローログ 問い合わせフローのログには、ログに関連付けられているブロック、問い合わせID、およびブロック内のステップが完了した後に取られたアクションに関する詳細が含まれています。 こんな感じ { "ContactId": "11111111-2222-3333-4444-555555555555", "ContactFlowId": "arn:aws:connect:us-west-2:0123456789012:instance/nnnnnnnnnnn-3333-4444-5555-111111111111/contact-flow/123456789000-aaaa-bbbbbbbbb-cccccccccccc", "ContactFlowModuleType": "SetQueue", "Timestamp": "2021-04-13T00:14:31.581Z", "Parameters": { "Queue": "arn:aws:connect:us-west-2:0123456789012:instance/nnnnnnnnnnn-3333-4444-5555-111111111111/queue/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" } } こちらも有効な処理ができているログとの差分を確認しましたが、特に問題となるような点が見受けられませんでした。以上のような調査結果から、ログからだけでは原因を辿っていくのは難しそうだなと判断しました。 調査結果を含めAWSのサポートに問い合わせしたところ、ユーザの電話側の設定確認をして欲しい旨を共有されました。 ユーザに電話の設定確認を依頼したところ、電話通知を受ける側のユーザで電話の転送サービスを利用されていることがわかりました。Amazon Connectはエンドカスタマー側で転送の設定がされている場合、エンドカスタマーに転送された時点でコンタクトフローが終了となるようです。 これで無事原因の把握をすることができました。Amazon Connectの音声問い合わせは、システムログからだけでは追えない部分が多いので、電話の受け手であるユーザともうまく連携してデバッグしていくのが良さそうです。 Tips 通話内容の録音 AWSからの返答の中で電話の設定だけでなく、通話内容の録音をすると良いとのアドバイスをもらいました。 というのも今回はユーザからの無音で電話が切れるという問い合わせから調査を開始しましたが、実際ユーザがどういった振る舞いをもとにそのように判断したのかを、言葉のやりとりからだけでは正確に事象を把握することができないからです。 録音はAmazon Connectのインスタンスが作成された際に作られたAmazon S3バケットに保存されていきます。 ※録音とトランスクリプトはどこに保存されますか？ ただ今回のユースケースで言うと、電話を利用した通知のみでありエンドユーザとの通話が発生するわけではありません。そのため前述のような方法は使えないとのことです。 このような場合には、発話内容を録音できるライブメディアストリーミングを利用する必要があります。 ※インスタンスでのライブメディアストリーミングの有効化 AWSサポートへの問い合わせテンプレート AWSサポートに問い合わせをした際、いくつかの情報提供を求められて複数回メールのやりとりが発生しました。次回サポート依頼することになった際にはそのようなラリーは避けたいので、 技術的なお問い合わせに関するガイドライン を参考にしながら、Amazon Connect用の問い合わせTemplateを作ったので書き残しておきます。 上記ガイドラインに記載のあるいくつかの項目は、サポートの作成時点でGUIから設定する必要があります。特に緊急度の部分は件名や本文に「緊急」等と記載されても、緊急度は上がらないので注意が必要です。 また個人情報などの秘匿情報が含まれる場合は、当該箇所をマスクする、または記述を省略する等の処理を行ってください。 1) 想定動作 Amazonc Connectは振る舞いの幅が広いので、円滑なコミュニケーションを取るためにも事前にしっかり説明しておくと良いです。 2) 事象の発生日時 下記データモデルの`ConnectedToSystemTimestamp`。タイムゾーンの記載も必要です。 例：11月 12, 2021, 12:34:56 午前 (日本時間) https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ctr-data-model.html#ctr-ContactTraceRecord 3) コンタクト ID 下記データモデルの`ContactId` https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ctr-data-model.html#ctr-ContactTraceRecord 4) 問い合わせフロー 下記を参考にExportできます。 https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-flow-import-export.html#how-to-import-export-contact-flows 5) 問い合わせフローのログ Amazon CloudWatchで問い合わせフローのログが確認できます。 ログが見当たらない場合は、有効化の設定を確認してみてください。 https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-flow-logs.html Amazon Connectの見積もり 今回の記事との関わりは薄いのですが、機能実装にあたり概算の見積もりをした際に便利だったツールも記載しておきます。 https://connect-mitsumori.serverworks.co.jp/ まとめ この記事では、Amazon Connectの音声問い合わせのデバッグとその過程で得られた知見を共有しました。 Amazon Connectはできることの幅が広くデバッグの方法もその分多彩なので、用途に合わせてしっかりドキュメントを読んで事前の準備をしておきましょう。

こんにちは、この秋リリースしたMusubi AI在庫管理の開発チームでデータサイエンティスト・エンジニアをしている保坂です。 こちらの記事はカケハシ Advent Calendar 2021の10日目の記事になります。 今日はAI在庫管理における需要予測・発注レコメンド機能で使用している技術スタックを紹介したいと思います。 これまでAI在庫管理チーム、とくにその需要予測・発注レコメンド機能の開発についてはあまり技術発信を行うことができておらず、今回がはじめての記事投稿ということで、技術スタックのご紹介を選択しました。 需要予測・発注レコメンド コスト、スケーラビリティの観点から、マネージドサー…

ご挨拶 こんにちは。カケハシで「Musubi Insight」のフロントエンド開発を行っている米山と申します！ Musubi Insight 経営データを即座に見える化 この記事はカケハシアドベントカレンダー2021 の9日目の記事になります✨ 概要 最近よく耳にする Blender。入門してみたいと思っている人は、多いのではないでしょうか🤔 Blender は3Dモデリングや3Dアニメーションを作成することができるツールであり、オープンソースで提供されています。 blender.org - Home of the Blender project - Free and Open 3D Crea…

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

こんにちは。カケハシの主力プロダクトである「Musubi（電子薬歴 ムスビ）」開発チームでUI/UXデザインを担当している木村です。 この記事はカケハシアドベントカレンダー2021の7日目の記事になります。 Musubiは、カケハシ創業以降、薬局の基幹システムとして成長してきたプロダクトです。 特に機能面では日々追加開発が行われ、便利になってきています。もちろんまだ十分ではない部分はありますが、とにかく絶え間なく成長を続けています。 一方、デザインの面では、機能開発の成長スピードに追いついていない状態となっていました。 この状態を改善すべく、開発チームでは2021年下半期から始めた試みがありま…

こんにちは、プラットフォームチームの石黒です。あっという間に今年が終わりますね🎄 この記事は、カケハシアドベントカレンダー2021の6日目の記事です。 本日はアカウント管理機能というサービスで使用している技術スタックを紹介します！ アカウント管理機能について カケハシで提供している4つのプロダクト（Musubi、Musubi Insight、Pocket Musubi、Musubi AI在庫管理）は共通の認証基盤を利用しており、全プロダクト横断のお客様向けアカウント管理機能の開発・運用を我々プラットフォームチームが行っています。 プラットフォームチームにつきまして、プロダクトマネージャーの金田…

この記事は、カケハシアドベントカレンダー2021の5日目の記事です。 SREチームとCorporate Engineeringチームのディレクター兼スクラムマスターをやっています、尾形です。今回はカケハシのSREチームが、今どのようなことに取り組んでいるのか、そして今後どうしていこうと考えているのかについて書いていこうと思います。 そもそもSREとは Site Reliability Engineeringの略で、もともとはGoogle社が提唱したものです。Site Reliability Engineeringというそのままの題名の書籍が、英語版・日本語版それぞれあり、英語版は無償で読むこと…

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

再発防止策が全然思いつかない...とお悩みの方へ。再発防止策は様々な視点から検討しない限り、納得のいくものにすることは困難です。そこで、複数の角度から120項目準備しました。再発防止策を起こすときに参考にしたり、すでに作成した再発防止策に追加できないか見返したりしてもらえれば幸いです。 再発防止策検討の基本方針 多層防御アプローチが検討しやすく基本です。レイヤーや人、プロセスごとに分解し、どんどん考えていきましょう。 分類の例: チームごと 各々のチームで、なにかできることはないでしょうか？後工程はお客様。前段の工程側に一見誤りがなくても、前段の工程のほうを改善したほうが成果が圧倒的にでること…

すっかり秋めいてきましたね🍁 プラットフォームチームの石黒です。 我々プラットフォームチームでは、顧客向けのアカウント管理機能を提供しています。その中にはユーザーの新規登録機能もあるのですが、薬局の規模が大きくなるにつれ所属する薬剤師の数も増えるということで、ユーザー管理にかかるお客様の時間を少しでも減らすべく、CSVでユーザーを大量登録できる「ユーザー一括登録機能」を提供しています✨ CSVでのデータ取り込みは業務用システムでは馴染みのある機能かと思いますが、サーバーレスで実現しようとするとなかなか難しく、躓きポイントがたくさんありました。。 その中でも、大容量データを扱うためのアーキテクチ…

2021-10-05（火）にカケハシ主催での初の勉強会イベント「AI在庫管理（新規事業）の設計勘所」を行いました。 本エントリーでは、当日ご参加いただいた方だけでなく、いらっしゃることのできなかった方にもご覧いただくために、各登壇者の発表資料をご紹介します。 https://connpass.com/event/223220/ 勉強会の冒頭でCTOの海老原がカケハシの変化について話しました。 カケハシは社員数が非常に増えており、社員は200人近くなっています。 薬局窓口のシステムを作るのに200人は必要あるのか？というと違います。 去年くらいからカケハシはシフトチェンジをしてきており、 「薬局…

こんにちは。 BIツール等担当のチームでエンジニアをしている小室です。 先日新規プロダクトのPoC立ち上げの為の設計を行った際、クライアント証明書の検証方法に関して検討した内容をまとめて行きたいと思います！ 弊社ではセンシティブな個人情報を取り扱う為に、クライアント証明書を活用してセキュリティの強化を行っております。しかし、従来はAWSにクライアント証明書を扱うマネージ機能がなかった為、nginxなどのweb serverで検証する必要がありました。 今回のPoCも個人情報を扱う為クライアント証明書の導入を決定しましたが、PoCというスピード感の中では、なるべくサーバレスで完結させたいと考え検…

こんにちは、株式会社カケハシでおくすり連絡帳 Pocket Musubiの開発を担当している渡辺です。 先日、Pocket Musubi で処方せん送信機能をリリースいたしました。 処方せん送信は手元の Pocket Musubi から処方せんの画像を撮影して事前にアップロードすることにより、スムーズに薬局で服薬指導を受けて薬を受け取ることができます。 この処方せん送信機能において、薬局内で処方せんを受け取ったことを薬剤師の先生が気づくように、ブラウザの通知を利用しました。 今回は、ここで利用した Web の標準技術である Web Notification と Web Audio について記述…