StartupAngular2資料 - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

約 6万店（コンビニの数：約5.3万店）約 7億回調剤薬局の数患者さんと薬剤師の1年間の会話数処方された薬を受け取るところ処方された薬について説明するところ薬について相談するところ自分の薬の重複や相互作用を確認するところ自分の薬や体質の情報を管理するところ薬を減らしたり、飲みやすくするところ薬以外のことについて相談するところ一般医薬品や介護用品を購入するところ自宅を訪問して薬の管理・指導をするところ患者さんがもつ薬局への印象薬局業界を取り巻く環境 5 5 出典：処方箋受取率の推計_https://www.nichiyaku.or.jp/assets/uploads/activities/bungyo/s/R2suikei.pdf

Slide 6

Slide 6 text

厚生労働省は、薬局に変革を促している 6 対物業務対人業務出所：厚生労働省患者のための薬局ビジョン（https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iyakuhin/yakkyoku_yakuzai/index.html） 6

Slide 7

Slide 7 text

7 患者さんへの提供価値を妨げている要因創業後、400人以上の薬剤師へのインタビューで見えてきた課題対人以外の業務が多く、心と時間の余裕がない処方箋だけでは患者さんのニーズがわからない（患者コミュニケーションへの不安）対物業務が多い各患者さんに対して何をどう話すべきか悩ましい（患者コミュニケーションへの不安）「効率化」の課題「患者関係性」の課題人によって業務の質にバラつきがある業務の標準化が出来ていない「標準化」の課題

Slide 8

Slide 8 text

8 　患者さんと薬剤師の“医療体験”を変革するため調剤薬局向けSaaS「Musubi」が誕生

Slide 9

Slide 9 text

9 対物から対人へ。門前からかかりつけへ。そして、地域医療を担う存在へ。薬局に求められる役割が大きくなるにつれ、負担も大きくなっている。

Slide 10

Slide 10 text

患者さんのための薬局づくりのパートナーとして、複合プロダクトで「薬局DX」をトータルサポート。医薬品発注管理最適化

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © KAKEHASHI Inc. All Rights Reserved.   なぜAngularを採用したのか ● 導入時はまだAngular2が出たばかりのころ ○ ReactとAngularのシェアは当時差がほとんどなかった ● 全部入り(routerだったりHttpClientだったり)のフレームワーク ● TypeScriptを使うこと前提(静的型による開発上のメリット) ○ TypeScript対応という観点で見た時に、当時のReactはまだ不安 ○ Angularは基本TypeScriptを使う ○ 型重要！型重要！

Slide 14

Slide 14 text

Copyright © KAKEHASHI Inc. All Rights Reserved.   なぜAngularを採用したのか ● 当時のReactはまだHooksがなかった ○ Vertual DOMをいい感じに使うためのかなり薄いフレームワーク ○ Flux的な議論やモジュール・コンポーネント切り分けのような開発規約において決定版と言えるようなものがなく「ぼくのかんがえたさいきょうの開発方法」の模索で界隈が疲弊していると観測していた ● AngularはAngular Wayが極めて明確 ○ 公式の開発ガイドラインがある ○ ソフトウェアエンジニアのスキルレベルによる実装手段のセグメンテーションが起きにくく価値創造のための実装に集中しやすい ○ 素早くリリースすることを重視！

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © KAKEHASHI Inc. All Rights Reserved.   Angularの良いところ ● ロジックはServiceに書いて、ComponentにDIさせれば良い ○ できる限りロジックはServiceに書く ○ テストはServiceでテストをやる ● Componentもテンプレートとスタイル(HTML/CSS)とロジック(TypeScript)が分離されている ○ デザイナーと協業しやすい(HTML/CSSを別で書いてもらえる)

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © KAKEHASHI Inc. All Rights Reserved.   RxJSでいかにがんばるかがポイント ● subscribeの中の関数にはできる限りロジックは書かない ○ streamをoperatorでできる限り操作する(if文が出てきたらfilterを使う、等) ● ネストはしない(switchMapやmergeMapを使おう) ○ subscribeの中でのsubscribeも注意 ● unsubscribeを忘れない ○ テンプレートで表示するだけだったらasync pipeを使う ● がんばりすぎて読みづらくなったら注意 ○ 他の人が理解できないと結果バグの温床になる ○ チームがRxJSに成熟する必要がある ○ ペアプロ・モブプロで知見の共有を！

Slide 20

Slide 20 text

Copyright © KAKEHASHI Inc. All Rights Reserved.   状態管理 ● プロダクトで状態管理は異なっている ● Musubiというプロダクトは内製reducer ○ 状態管理のライブラリのデファクトが当時なかった ○ といってもメンテナンスが大変 ● Pocket Musubiのフロントのような小規模だと状態管理のライブラリは使わず、 BehaviorSubjectでがんばるという選択もある ○ ngrxは too mach ○ ただ大きくなってくると状態管理のライブラリが欲しくなる ● 使う時はngrxを第1候補に