はじめに こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubiというサービスを開発している種岡です。 この記事では、Serverless Stackとapollo-server-lambdaを使って、AWS Lambda上でApollo Serverを動かしてみたのでご紹介します。 対象読者 以下に興味がある方は読んで頂ければ幸いです。 CDKのラッパーであるServerless Stackについて AWS Lambda上でApollo GraphQLサーバーの起動について とくに、Serveless StackのLive Lambda Development機能がオススメで…

AWS Lambdaを使えば開発者がビジネス価値に集中できる一方、それでも今までの開発と異なるポイントに気をつける必要があります。この記事では注意したい計30個のチェックポイントを紹介します。 まずは比較的簡単で効果が出やすい部分から見ていきましょう。 🚀時間がないあなたに！すぐできるポイント10選 レビューしていてよく出てくる、比較的修正しやすい事項です。 (1) メモリサイズを設定する LambdaはメモリサイズによってCPU含めたリソースパワーが決まり、1792MBで1CPUちょうどとされています。利用言語やマルチスレッド処理の状況に合わせ増減させましょう。 デフォルトはCloudFor…

こんにちは、LINE上で動くおくすり連絡帳Pocket Musubiというサービスを開発している南光(@stnamco)です。 Qiitaのググって解決しづらかったこと Advent Calendar 2021向けに書いた記事です。 この記事では、ググれなかった時に個人的にやっている手法について紹介します。 ググれない状態とは 手法を紹介する前に、前提の課題感を合わせるために自分がググれなかった時がどういう時なのか整理してみました。 正式な名称がわからない。 まさに下記のような時ですね。そもそも検索に利用すべきワードが分からないので、欲しい回答を見つけるのは難しいです。 ん？なんやこの??って…

KAKEHASHI の、Musubi Insight チームのエンジニアの横田です。 KAKEHASHI では BI ツールの Musubi Insight という Web アプリケーションを提供しています。 BI ツールでは薬剤師さんの業務データを可視化しておりますが、そのデータの集計処理には AWS Glue を使っています。 今年 AWS Glue 3.0が使えるようになり、できることが増えました。 チームのデータ基盤の概要と、AWS Glue 3.0 になって新たに使えるようになった PySpark の関数をいくつか紹介していきます。 Musubi Insight チームでの AWS …

こんにちは、LINE上で動くおくすり連絡帳Pocket Musubiというサービスを開発している南光(@stnamco)です。 この記事では、PRレビューを利用して自分の学びをチームの学びに繋げた取り組みについて紹介します。 背景 カケハシではDXCriteriaを利用した開発組織の状態の可視化にトライしており、自分のチームでも確認する機会がありました。 確認項目の中には、継続的な学習機会を設けているか？という質問もあり、個人としてはPRレビューなどで学習機会がある実感はあったのですが、チームとして学習機会を作れているか？と問われると、たまに気になる書籍があれば輪読会を開くくらいで、継続的な機…

こちらは株式会社カケハシ x TypeScriptアドベントカレンダー2021 20日目の記事です。 タイトルの通り、TypeScript ファイルに Yaml データを読み込んで型付けをする方法です。 TypeScript 環境のセットアップ まずは TypeScript 環境をつくります。 mkdir typed-yaml-demo cd typed-yaml-demo npm init -y 今回は ts-node を利用。 TypeStrong/ts-node: TypeScript execution and REPL for node.js npm install -D types…

処方箋情報基盤開発チームエンジニアの加藤です。 この記事は カケハシアドベントカレンダー2021 の18日目の記事になります。 まえがき 今年はとくにアウトプットの速度を求められる局面が多い年でした。 そのため、社内の仕事の速いエンジニア（速い人はビビるぐらい速い）から知恵を借りたり、自身で工夫して開発効率を改善する必要がありました。 その中でも、導入が簡単かつテクノロジースタックに依存しないものを紹介します。 なお以下の説明はすべてmacOS Big Sur環境の前提です。 あらかじめご了承ください。 ターミナル ＆ シェル macOS Catalina からデフォルトのログインシェルがzs…

こんにちは。カケハシの 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在庫管理）は共通の認証基盤を利用しており、全プロダクト横断のお客様向けアカウント管理機能の開発・運用を我々プラットフォームチームが行っています。 プラットフォームチームにつきまして、プロダクトマネージャーの金田…