ID:33932さん

## プロジェクト概要 今までは医療機関向けのサービスを提供していましたが、toC向け(患者むけ)に価値を届けるアプリとして企画・開発を担当しました。 患者様に薬局から薬の副作用に関して自動的に質問を送る、患者様は質問の答えとともに気になることを書くことによって、厚生労働省から薬局に対して義務化された継続的服薬指導に簡単に対応できるとともに、患者様が薬局をきちんと医療機関として利用できるように促すことが目的となるプロダクトです。 SQLのテーブルは30個ほどあり、画面数はモバイル側が20個ほど、管理画面も9個ほどの大きめのプロダクトです。 ## 技術スタック - Django/ Django Rest Framework/ Zappa(APIサーバー) - AWS:Aurora (DBサーバー) - Angular v12 (管理画面) - Angular v12/ LIFF(LINE FrontEnd Framework) (モバイルアプリ) - ZXingC++ (QRコードライブラリ) ## 技術スタック選定理由とその効果 Djangoは他言語のフレームワーク経験者(特にRuby on Rails)での利用者もキャッチアップしやすいため、採用しました。 Zappaはスケーリングなどで悩まないようにサーバーレスを用いたいために採用しました。 Angularはセキュリティに問題がないこと、負債を残さないことを念頭に常にバージョンアップしていました。 患者様の端末は、当初iOSのアプリとして開発しましたが、患者様の年齢やリテラシーを考え、 LINE上でのLIFFアプリ(LINEで動くWebView)で実現することにしました。 認証等もLINE IDを使い、LINE メッセージングAPIを使って開発をしました。 LINEを使うことによりユーザー層も増え、現場でも導入しやすさの声が聞けました。 またQRコードリーダーをWebViewで行う必要があり、 ZXingのC++ライブラリを Web Assemblerで動かすことまでやりました。 C++ライブラリを使ったのは、既存のJSで使ったライブラリではパフォーマンスの面や読み取り制度に問題があるため、C++でチューニングできるものを使用しました。 管理画面ではデザイナーがデザインしたHTMLを元にコンポーネント化する作業を主に行いました。 GuardはRxJSがバグを生みやすいため、ここを最大限に生かすためにAngularの仕組みを学び できるだけGuardやServiceを使い機能実装をして行くようにしました。 管理画面はダイアログが多用されることから、そこの共通化も行い、拡張する部分だけを実装するような仕組みにしました。 DevOpsとして障害対応にもあたり、DataDogで障害を分析し、実際に修正や対応をすることもあります。 実際に障害にあたることにより、カスタマーサポートやカスタマーサクセスの温度感、現場で業務フローで何が問題になるか把握し、次の計画にフィードバックすることが可能となり、チームでプロダクトの価値を高める議論をすることが可能になりました。 ## 具体的に開発した機能 - 管理画面全体 - APIをPythonで作って、画面をAngularで書くのを1人で行い、メッセージ送信や設定画面を中心に実装を行う - 処方箋送信機能・特にLIFFから処方されたらWebNotificationやWebAudioで管理画面で音を流す実装を行う 処方箋送信は、事前にLIFFアプリで処方箋をカメラで撮影して連絡先と一緒に送信し、処方箋を受け取った薬局で薬剤師が調剤の準備をしておいて、患者の待ち時間を減らす機能です。 ここで薬剤師が送られた処方箋に気がつくのがポイントなので、定期的に管理画面でポーリングでAPIを呼び出し追加された処方箋をチェックし、対応する必要があれば音で知らせる機能があります。 ここで「処方箋がX件あります」という通知を音で知らせるためWebAudio機能を使いました。 カメラも送信できる容量にしなければならないので、HTMLのCanvasでLamdaで処理できるサイズに縮小して送信するようにしました。 ## スクラムマスターの経験による効果 開発当初はスクラムマスターも兼務していました。 スクラムイベント計画と主催、他スクラムチーム連携、組織開発面でのアクションを行いました。 チーム内では1on1を行い、必要ならば他のスクラムマスターを連携し、問題解決をして開発者体験向上に尽力しました。 特に心理面でのケアは力を入れました。感情面の整理は理屈ではうまくいかないので、相手に配慮する発言をしてもらう、不満を出して問題に昇華してもらうように、話を聴きながらチケットとして課題に登録するようにしました。 振り返りも重視し、KPTもしくはYWTで必ず振り返りをし、ネクストアクションを必ず設定していました。 途中でアウトプットを優先させるため、スクラムマスターを採用し、自分は開発に専念することにしました。 ただスクラムマスターの経験は無駄にはならず、エンジニアだけのミーティングのファシリテーションを積極的に行う、振り返り手法を行うようにしました。 普段のミーティングでの会話・問題解決のための会話の接着剤の役割をするため、MTGでは必ず発言するよう、フォローに徹するなど縁の下の力持ちの役割を果たせるようになりました。 普段の開発では現在ではSlackのhuddleには常に入るようにし、いつでも相談を受けられるようにしてます。

現職の創業メンバーとしてプロダクト開発を行いました。 フロントエンドとバックエンド両方開発しました。 ## 技術スタック - ビジネスロジックはフロントに寄せて、バックエンドでAPIサーバーはデータを返すという構成 - バックエンドはAWS上のEC2にpythonのpyramidというフレームワーク - DBはDynamoDB+MySQL(主にお薬マスター) ## 技術スタック選定理由とその効果 Pythonの経験はデータ分析などに使いやすくとても役立ちました。 バックエンド、特にDB周りは経験が浅かったため、PythonとともにDB周りをキャッチアップをして解決しました。キャッチアップはUdemyでの動画で知識を得るとともに、積極的にタスクをこなして感覚を掴みました。 薬剤師さんが使う薬歴システムなので、MySQLは薬剤といったマスタを使用し、それ以外の読み書きをするデータは可用性を重視してDynamoDBで処理しています。 DynamoDBはNoSQLではよくできており、この経験はとても役立っています。 DynamoDBの設計のベストプラクティスも学ぶことができました。 フロントエンドはモダンなAngularを採用しました。 当時はReactとAngularのどちらも勢いがあったのですが、 AngularはTypeScriptが前提になっているところ、コンポーネントごとにHTML/SCSS/TypeScriptが書ける点が良いと思い採用しました。 ロジックはフロントに寄せたことから、非同期処理が多くなるために積極的にRxJSを使ってリアクティブプログラミングを行いました。 RxJSでAPI通信することにより、フロントエンドはとてもスムーズな描画が実現できています。 ## どのように開発に携わったのか APIと画面を同時に開発することにより、どちらかがボトルネックにならないように開発ができました。 問診票のようなユーザーが記載する項目の実装を主に行なったので、 AngularではReactive Formを使ってValidationやアラート表示をわかりやすく実装しました。サーバー側でもValidationを行うようにしました。 待ち時間はインジケーターを導入し、認知的にユーザー体験をよくするようにしました。 特に、画面で連携する部分（問診票でお薬手帳なしとするならば薬歴もなしにする）が多かったので、RxJSでStreamを流して解決するようにしました。

グリーSNSのAndroidを国際化対応したアプリにリニューアルすべく、一からアプリ開発とそれに必要なSDKの開発を行いました。 ## 技術スタック - サーバーサイドはPHP(Ethna) - フロントエンドのBFFとしてNode.js (CoffeeScript) - アプリ側はJavaとWebViewのハイブリット ## 詳細 ### WebViewベースアプリ WebViewベースのハイブリットアプリでしたが、スライドメニューやPull To Refreshといった部分はネイティブで自前の実装を行いました。 フロント部分のサーバーはNode.jsで、そのサーバーからフロント画面に必要な情報を取得する形式でした。 スライドメニューは当時はNavigationDrawerなどのWidgetがなかったので、自前の実装しました。 スライドメニューはWebViewの2枚重になってしまうため、メモリを大量に消費するため、リソースを削ったりキャッシュを有効活用してメモリを消費しないように工夫しました。 Pull to Refreshもライブラリが当時はなかったので、自前実装しました。自前実装だったため、引っ張る部分にViewを入れてタッチが外れたら元に戻す等の実装をいくつか試作し、一番パフォーマンスが上がる実装を選択しました。 当初はWebViewを重ねてキャッシュしておくことでページ遷移してもすぐにバックできる仕様でしたが、 WebViewを重ねると重くなることがわかり、(スライドメニューを覗き)WebView一枚にするという決断をしました。 AndroidのネイティブとWebの知識の両方が生きたプロジェクトでした。 現在は、cordovaといった仕組みがあり、Widgetにも色々追加されたので自前実装は不要になりましたが、この当時は自分たちで行わなければならなかったので、実装力が試される部分でしたが期待に応えることができました。 社内でも評価されたプロジェクトでした。

## 技術スタック - cordovaによるマルチプラットフォーム(Android/iOS) - AndroidはJava、iOSはObjective-Cを利用しPlug-in実装 - C言語によりドライバとのやりとり、レンダリング処理の実装 ## 詳細 お客様が、クロスプラットフォームでアプリを書ける仕組みが欲しいと要求があり、 HTMLベースにしたいとのことだったので、cordovaを提案しました。 私がエンジニアとしてjoinする前はTitaniumが候補に上がっていたので、HTMLでアプリ書くのはcordovaという提案をし、 採用していただきました。 社内アプリでSDKを使うというユースケースでした。 cordovaをベースにマルチプラットフォームでアプリを作るためのSDKであるため、 C言語やJava/Objective-Cで機器との通信やSVGのレンダリング等を行う開発を行い、 これをcordovaのプラグインとして提供するという構成でした。 アプリ実装者はHTML/CSSを書いて JavaScriptでやりたい処理を呼び出すだけになりました。 この案件は1stアプリの開発も担当したので、HTML/CSSも書いてアプリを開発し、横展開可能にしました。 レンダリング部分はSVGを利用し、それを分割してJPEG変換、プリンタのドライバに渡すという処理を書きましたが、 この部分はC言語で実装しました。 最初のアプリケーションはCD/DVDのラベル開発でしたが、 オーサリング部分でユーザーが作成した背景や文字をSVGで保存し、 メモリを消費しないようにSVGを分割してJPEG変換し、プリンタへ送信する実装でした。 (具体的にはSVGの一部分をCANVASに描画し、JPEGで書き出してC言語の実装に渡してバイナリを送信するという実装でした。) このメモリを消費しないようにどの程度まで分割するかと、 元に戻すときに境目がずれないようにするといった工夫をしました。

組込み向けにHTML5に対応させたブラウザの開発を一から行いました。 # 使用技術 - C言語 - Linux/Windows - HTML/CSS/JavaScript (主にテスト用) # 概要 HTML/DOM/画像処理を担当する5人ぐらいのチームリーダーとして、サポートする仕様の調整やチーム間のコミュニケーション、チームメンバーの技術的サポートを行いました。 また、自らは画像表示やDOMメソッドの設計とコーディングを行いました。 ## 画像表示について 画像はJPEGやPNGをデコードし、表示させる部分です。 img要素で指定した画像を取得し、IJGJPEGでパースし、ピクセル値に展開します。 ピクセルは基本的にRGBそれぞれ32バイトずつでしたが、環境によって16バイトや8バイトの場合もあるので、そこを計算して補正しました。 ## DOM関連について ブラウザエンジンはとても複雑で、HTMLをパースして文書のツリーをつくり、それをCSS辞書とともにレンダリングのためのツリーをつくり、そこから描画するというものです。 DOMはHTMLのパースからDOMを機構造で表現し、JavaScriptエンジンと結び付けてそれを操作する必要があります。その部分を主に実装しました。 ブラウザの動作の全体像が理解できたのはWeb系にいってもとても役に立っています。 C言語でメモリを気にしてコーディングする経験は今も生きています。 ## メモリ管理について C言語のため、メモリの管理は慎重に行いました。 メモリリークをしないようにmallocした領域は必ずfreeをする、長いループをしないで定期的に処理を返してWatch Doc timeでプロセスを落とされないようにするような工夫が必要でした。 ループはtimeを取得し、ループの1回の処理でtimeを取って差分を取得し、指定時間を超えないようにループを抜けるようにいました。