年: 2020年

「生活していくうえで毎日の健康管理は大事である。」

というのは言わずもがな理解しているだろう。

今年3月に大きく拡大した新型コロナウィルスの影響を受け、人々の健康管理に対する考え方は大きく様変わりし、厚生省が公表している身体的距離の確保や3密の回避といった『新しい生活様式』も 今では当たり前のように行われている。

そして、企業における従業員の健康管理にも変化が起きている。

「大きなお世話だ」という声が聞こえてきそうだが、企業にとって“働き手”である従業員は資産であり、その資産の管理をすることは企業にとって当然の義務なのである。

さて今回は、従業員の健康管理を目的とした体調管理システム開発を手掛けた山川氏へインタビュー。

『体調管理SaaS』で出来ることや今後の展望を語ってくれた。

山川 宗大　sota yamakawa
2013年入社。ソリューション開発部 沖縄 System6 DataLineチーム。
プログラマーとして中古車販売システム開発を担当し、2019年には自動車流通のセールスエンジニアとして営業支援に携わる。現在はプロジェクトマネージャーとして従事。開発から企画、プロジェクトの推進と幅広く活躍している。

体調管理システム開発のきっかけを教えてください

元々のきっかけは新型コロナウィルスが始まりでした。

社員の安全確保と更なる感染拡大防止を目的として毎日の体調管理を実施していたんです。

ここで言う体調管理とは、体温、勤務状況（シフト）、体調や症状を言い、出社・休みを含めて毎日報告することになっています。

始めはGoogleフォーム＋Googleスプレッドシートで運用していましたが、社員数が多いので、毎日の体調報告をフォームから送っていくうちに、集約される管理表が段々と重くなってきていました。最終的には体調管理表を確認する際のローディングをひたすら待つ、というのがストレスになり非効率になったんです。

そういった背景から、「体調管理をシステム化しよう」ということになりました。 システム化をしてからのデータ管理スピードや見やすさといったUI/UXは各段に上がったと思います。

今回使用した技術（開発言語やツールなど）は何ですか？

AWSのECSを使用して構築し、フロント側はReactというライブラリを使っています。
ログイン認証は社員が持っているGoogleアカウントでログインできるように、Cogniteを使用しました。
当社の社員投票制度である「Shine Star（シャインスター）制度」と同じ仕組みだと思います。

苦労した点を教えてください。

一番苦労したのは要件定義ですね。正直最初は軽く見ていました（笑）

当社には子会社やニアショア事業、外部常駐といった拠点で従事している社員がいたり、直接出社をしない営業や在宅勤務といった様々な働き方があるので、思ったよりも管理方法が単純ではなかったです。

例えば、時差出勤した場合のシフトと管理表との連携や、今日は会社出社なのか？在宅なのか？出張なのか？といったロケーションの部分も考慮する必要が出てきました。

体調管理をするということは、単に報告をしてもらうだけではなく、報告が漏れている社員に対しての追いかけをしなくてはなりませんし、発熱といった体調不良者がでたときに、そこから感染疑いのある接触者を洗い出すことも必要になってきますので、誰がどこにいるのか？は非常に重要になってきます。

コロナ禍において、体調管理はスタッフの状況を把握できるようになっていなければならないんです。

最終的には上がってきた社員のデータを可視化して、各責任者から役員へ報告する流れなので、役員が全社員の状況をすぐに把握できる前提で作っています。

役員報告用のサマリについては、コミュニケーションツールのslackを使って通知が飛ぶようにしています。「可能な限りすべてのフローを自動で」というところを意識しました。未入力者の通知もslackで飛ぶようになっています。

体調管理のシステム化をするにあたり、要件定義の段階では想定していなかったものが、開発段階で追加追加の実装をすることが多かったように思います。

新型コロナウィルスという予測不能の事態に対応していくためには、コロナと並行しながら要件を決めていくといった柔軟な対応も必要ということを改めて痛感しました。

そんななかでも得たものは大きいんですよね？

沢山ありました！

これまで使ったことがないサービスやツールに触れることができたので、凄く勉強になりましたし、何よりも自身の成長に繋がったなと感じています。

もともと自分が担当している業務に活かすといった、知識の横展開ができているので、そういった点では担当して良かったなと思っています。

体調管理システムですが、今後どういう展開があるのでしょう？

「ストレスチェック」や「働きがいアンケート」「打刻ログ」など、さまざまな情報を組み合わせて、AIに学習させてみる。その結果、データの可視化、気にかけるべき社員の自動抽出など、データを使って効率的且つ合理的に管理できるのではないでしょうか。

今まで、直接顔を合わせていたので、気づくことができたことも、在宅ワークやワーケーションなど、顔を直接合わせる機会が減るとなかなか気づき辛いところもあると思いますので、その課題を解決できればと思います。

残る課題としては、スマホでの体調入力を可能にするUIの実装と、シフト表との連動ですね。
今だと、未入力者へのアラートが表示されますが、実はその方が午後へシフト変更していた場合、「未入力」として判断されるということがあるので。。
最新情報が反映されたシフト表と体調管理システムを連携させていくことで、より精度を上げていきたいですね。

体調管理システムはあくまでも“仕組み”であり、一番はやはり会社の資産である社員の健康を守っていくことだと考えています。

今後は社員へのアンケートをとって要望なども取り入れながらアップデートしていきます！

まとめ

企業側が健康経営を推進していくことは、働く従業員の健康への意識啓発に繋がり、従業員自らがコンディションに配慮することで、従業員の活力や生産性の向上にも貢献できる。

今後は、山川氏の言うように『体調管理SaaS』を、ストレスチェック、働きがいといったメンタル面のデータと組み合わせることで健康管理のバージョンが上がり、健康管理のライフログの新常態として浸透していくかもしれない。

今回は、AI鑑定を用いて、クルマ鑑定に費やす工数を改善するプロジェクトを推進しているセバスチャン氏へインタビュー。

これまで、様々な研究開発に携わり実績を残してきた彼の研究開発に迫ってみたい。

AI鑑定システムの研究から出てくる課題と、それに対する彼の挑戦、そしてAI鑑定がもたらす未来を、インタビューの中から感じ取れると思う。

レッティグ セバスチャン ペーター　Rettig Sebastian Peter
2015年入社。AIテクノロジー推進室 沖縄に所属。
自社内の課題解決にAIを使って効率化を目指しながら研究開発を行う。
アプリ開発、承認チェックAIシステムの構築、フロントエンド・バックエンド開発など、プロジェクトの内容よって担当を変えられる守備範囲の広さと、すべての開発を一人で行うマルチエンジニアとして従事している。

クルマの傷、凹みを自動で検知する「AI鑑定」の開発目的は？

目的としては、クルマ鑑定物件数の向上です。

現状はクルマ1台あたりの鑑定所要時間が約20～30分かかってしまうことと、鑑定者の不足が課題として上がっていました。

鑑定後のレポートもデータとして手動で入力しないといけないので時間と手間が発生していました。

そこで、機械学習を使ってクルマを自動鑑定し、鑑定後のデータもそのまま蓄積されていくシステムを作ることで、鑑定にかかるコストを削減できるのではないのか？

そういった思いから、AI鑑定システムをプロトタイプとして開発することに至りました。

クルマ業界で「AI鑑定」を導入しているところは多いのでしょうか？

AI鑑定というよりは「AI査定」になりますが、最近ニュースに出てきたのは保険会社向けのスマホアプリです。
事故があった時に、自分のスマホでクルマの障害を撮影して保険会社に送ります。障害レベルや修理コスト予算はAIで判断するそうです。事故障害は画像でわかりやすくて、判断しやすいと考えます。

一方で、「AI鑑定」だと、事故直後ではなく修理済みのクルマに対しておこなうことが多いです。
傷や凹みなどを検知して、修理のあったクルマなのか？ そうでないクルマなのか？ の判断をします。
難易度としては上記の保険会社がおこなう事故車分析より高いです。

鑑定対応サービスは現在プロトタイプな状態ですので、導入している企業はほとんど無いですね。

そのAI鑑定ですが、どういった人たちに利用してもらいますか？

「アジャスター」と呼ばれる鑑定者が、クルマを鑑定する時のツールとして利用してもらうことを想定しています。事故車などを鑑定するプロフェッショナルの方々ですね。

開発でフォーカスしているのは「外装部分」。
外装のキズや凹みを画像認識AIへ学習させます。 クルマの撮影画像を傷・凹みのセグメントに分析し、障害レベルを評価していくという流れをAI化することで、鑑定にかかる所要時間を削減させることが可能になります。

開発に使用した言語やツールなどは何になりますか？

開発については機械学習基盤から実開発まで、使う言語やツールは多岐に渡ります。

機械学習開発
　→python, Pytorch, fastai, Tensorflow, 機械学習基盤（ML-Template, ML-Core）
API開発
　→python, javascript, HTML, CSS
APIディプロイ
　→docker
Androidプロトタイプ開発
　→Java, C, Tensorflow-lite

ちなみに今回のプロジェクトで使っている機械学習基盤は私が作ったもので、社内にある単純作業などを自動化するための基盤として少し前にリリースしたものになります。
これに関してはbacklogへアップロードして他部署でも使ってもらっているんですよ。

会社で一緒に働く仲間たちにも、私が作ったツールボックスを使っていい環境になるように、社内スタンダードにできたらと考えています。

学習基盤は自作なんですね。既に横展開ができているとは驚きです！では、開発で直面した課題について聞かせてください。

まず、AI学習には大量の教師データが必要になります。その教師データを作り出す作業を「アノテーション（意味付け）」と言って、高い精度を追及するほど沢山のアノテーションが必要となります。

傷や凹みの形はどれも全く同じものはなく、小さい、大きい、長いなど様々です。そういった傷や凹みをマーキングするツールが足りなかったため、自分でアノテートツールを開発しました。

あと、私自身が鑑定者ではないので、アノテート後の判定結果のジャッジが難しく、専門家の確認が必要なこともありましたね。

また、今回のプロトタイプを簡単に作成できる基盤がないため、環境実装が必要でした。こちらは先ほど話した学習基盤（ML-Template, ML-Core）のことです。 学習基盤もそうですが、ツールがなければ自分で作ることはあります。

色々ありますが、チャレンジポイントとして捉え、ひとつずつ課題を潰していくことが研究開発には大事なことです。好きじゃないとできませんね（笑）

さて、気になるAI鑑定システムのリリース予定はいつ頃でしょうか？

リリース予定はまだ決めていないです。

と言うのも、クルマ鑑定物件数の向上という目的はあるものの、鑑定業務の効率化ができるか？の研究開発になりますので、まずはフィジビリでやってみて上手くいけばプロダクト化する。という感じですね。

あくまでも研究開発をするのが私のミッションですので。

ただ、鑑定者に便利なシステムになることは間違いないです。 このAI鑑定が上手くいけば、「ヒトが足りない、時間が無い」の両方が改善されるわけですから。

今後の展開について聞かせてください。

まだ研究開発中なので何とも言えないですが、今掲げているチャレンジ点を解決できれば、プロトタイプシステムを実装するつもりです。

その後、クライアントのテストフェーズを行い、将来的には鑑定サービスとして展開したいと考えています。 遠い未来には、誰でもスマホで鑑定できるようになるかも知れないですね。

あとがき

画像認識技術を駆使し、AI鑑定システムの開発を進めるセバスチャン氏。

単身、幾度となく繰り返すテストと実装の中には、数えきれないほどの課題に直面する。

それを「チャレンジポイント」と称し孤高に研究を重ねる姿に、エンジニアとしての気高さを感じた。

AI鑑定システムが彼の手からリリースされる日が来れば、クルマ業界が大きく変わるかも知れない。