ID:50021さん

### プロジェクト概要 社の主力製品である生産機械が顧客先にて故障した際に、出張修理を行うエンジニアをサポートするシステムを開発しました。 具体的には、故障した機械の機種及び故障の状況（修理エンジニアがテキストで入力）を元に、過去の故障事例から類似しているものを抽出し、修理エンジニアに提示するものです。 ### した工夫 ユーザーにとっての価値を見極め、それを提供出来る方向にプロジェクトを切り替えました。 プロジェクト参画当初は、「機械学習を活用し、事前に分類した故障原因から最も妥当だと思われるものをユーザーに提示する」という方向性でプロジェクトが進んでいました。しかしシステムの解答は情報が乏しく、ユーザーにとって役に立たない物になっていました。ユーザーへのヒアリングからこの事を知り、プロジェクトの方向性を切り替えました。具体的には、システム開発前からユーザーが行っていた、"過去の類似の事例を検索する業務"を、自動かつ検索スキルの乏しいエンジニアでも使用出来る形に置き換えました。結果として、主に入社5年以内の若いエンジニアから、非常に参考になった、再出張せずに済んだ等の評価をいただく事が出来ました。 ### 技術概要 故障機械の機種及び故障の状況をメールで送ると、過去の類似事例をメールで返送するシステムの構築を行いました。 使用した技術は、AWS SES, AWS S3, AWS Lambda, AWS SQS, AWS ECSです。コードは全て Python で書きました。類似事例を抽出する際の指標としては、文章の類似度を用いました。文章の類似度の算出には、word2vec という技術を用いました。具体的には、事前に word2vec を用いてベクトル化しておいた過去事例と、メールに記載された故障状況を word2vec でベクトル化したものをそれぞれ比較し、類似度が上位のものをメールで返送しました。 ### 技術的に解決した課題 #### サービス精度の向上と、それに伴うシステムレスポンスの向上 サービスの精度及び、システムレスポンスの向上を実現しました。 初期のシステムでは、到着した故障状況と過去の全ての事例を比較していました。これにより、メール到着から返送までに3〜5分かかっていました。また、文章としては似ているが機種が全く異なり役に立たない情報が届いてしまうという問題がありました。検討する過去事例は多い方が良いだろう、という判断でこのようにしていましたが、ユーザーへのヒアリングにより全ての過去事例を検討する必要が無い事を突き止め、過去事例の事前絞り込みを行いました。具体的には、修理エンジニアが修理しているのと同一の機種及びシリーズの事例のみを返送候補としました。絞り込みの区分としては、根本的な機械構造、機種、シリーズ、制作年次がありましたが、こちらもユーザーへのヒアリングを元に、最も適切な区分を突き止めました。これにより、より状況の類似した過去事例のユーザーへの返送を実現しました。また、全事例との比較を排した事により、1分以内でのメール返送を実現しました。 #### UI・UX の向上 顧客目線での UI・UX 設計とユーザーへのヒアリングにより、UI・UX の向上を実現しました。 具体的には、返送メールのレイアウトを入念に検討・修正し、PCからでもスマートフォンからでも見やすいものにしました。また、表示する情報について、ユーザーの修理作業の役に立つものに絞り、ユーザーが最短で必要な情報を入手出来るようにしました。基本的に、マニュアルは読まれない前提でサービスを開発しました。具体的には、ユーザーが間違った使い方をした場合には、返送メールで修正点を具体的に明示しました。また、入力は極力平易にしました。具体的には、メール1行目に機種、2行目以降に故障状況を記載、もしくは、件名に機種、本文に故障状況という形式の両方に対応出来るシステムにしました。これらより、多くても3回のメール送信でシステムを正しく利用いただく事ができ、新しいシステムに抵抗感の高い現場のユーザーにシステムを普及させる事が出来ました。

### プロジェクト概要 社の主力製品である生産機械について、顧客先での故障を未然に検知・通知するサービスを開発しました。 具体的には、生産機械に設置した組み込み PC で収集・転送したデータを用いて定期的な診断を行い、異常が見られた場合は機械の管理者に通知するものです。定期的な診断は、事前に学習させた機械学習エンジンで行いました。 ### した工夫 常にプロジェクト全体について考え、都度必要な事に取り組みました。 プロジェクト参画当初は、機械学習エンジンの開発やインストーラ作成の自動化が進められていましたが、まず最低限のシステムを完成させ、必要事項を炙り出した上で開発を進めるべきだと考え、自社工場での実地テストを行いました。結果として、組み込み PC でのデータ収集・安定稼働の実現が大きな課題である事を早期に発見し、優先的に取り組む事が出来ました。またプロジェクト内外の方と積極的に関わり、都度必要な情報・協力を得てプロジェクトを円滑に進めました。結果として、自社工場での実地テストを完了し、顧客先でのPoC開始に結びつける事が出来ました。 ### 技術概要 機械からのデータ収集・転送を行う組み込みPCの開発と、到着データを元に診断を実行して結果をメール返送するシステムの構築を行いました。 使用した技術は、AWS IoT, AWS S3, AWS Lambda, AWS SQS, AWS ECS, AWS DDB, FFT, カルマンフィルタ, PCA, オートエンコーダです。コードは全て Python で書きました。診断の手法としては、事前に収集した大量のデータから「正常領域」という領域を定義し、ここからのデータの外れ具合を異常度として表示しました。（滅多に故障が発生しない機械に対する異常検知を実現するために、正常データのみでモデルの作成が可能なこの手法を選択しました。）組み込み PC からシステムへのデータの転送には、AWS IoTを用いました。MQTT 通信で一時的なトークンを取得する事で、セキュアなデータ転送を実現しました。また、デバイスの管理は AWS IoT を用いて行いました。AWS IoT 上でデバイスをグルーピングした事により、組み込み PC のソフトウェアアップデートのグループごとの実行を実現しました。これにより、自社工場でのテスト → パートナー企業の工場でのテスト → 本番環境へのデプロイ というデプロイフローの容易かつ安全な実行を実現しました。 ### 技術的に解決した課題 #### 組み込み PC の安定稼働の実現 組み込み PC について、工場の劣悪な環境での安定動作を実現しました。 アース揺動によるバッテリーの故障、電波が悪い時のみ発生するメモリリーク等、課題が多くありましたが、問題発生ごとに詳細に条件を比較・検討して原因を特定・解決し、安定稼働を実現しました。 #### 組み込み PC セットアップの自動化による開発速度向上 組み込み PC セットアップの自動化による、開発速度の向上を実現しました。 組み込み PC の管理は AWS IoT を使用して行っていましたが、AWS IoT への登録作業と、組み込み PC のインストーラ作成、実行に非常に時間がかかるという問題がありました。（インストーラには組み込み PC ごとの認証情報を組み込む必要があり、毎回作成する必要がありました）この AWS IoT への登録及びインストーラの作成を行う Lambda 関数を作成した事で、組み込み PC のセットアップを大幅に自動化しました。これにより、故障が頻発する組み込み PC の開発速度を向上させ、組み込み PC の安定稼働を実現しました。 #### サービスの最適化 ユーザーにとって最も価値が高くなるようなサービスの最適化を実現しました。 本システムには、誤検知が少なく、かつ確実に異常を検知出来る事が求められます。これはトレードオフですが、最も妥当に診断を行うシステムを実現しました。具体的には、正常領域を作成するために使用するデータの範囲を調整しました。特定の機械 A を診断する為の正常領域を作成する際に用いるデータの候補としては、 1. 同じシリーズの機械のデータ 2. 同じ種類の機械のデータ 3. 同じ種類かつ、構成タイプという区分が同一の機械のデータ 4. 特定の機械 A のデータ などがあります。 1.だと、データの収集は楽な反面、正常領域が不当に広がり、異常の見逃しが発生します。4. だと、機械ごとにデータ収集を行う必要がある為に煩雑であり、またデータが不十分である為に正常領域が小さく、誤検知が発生します。 これらを両立する、3. を特定し、サービスの最適化を実現しました。 最終的には、このスコープは機種ごとに異なる事が判明した為、機種ごとに使用するデータのスコープを変えて正常領域の作成を行いました。

### プロジェクト概要 システムのサーバについて、運用・保守を行うためのリモート接続を行うためのサービスを開発しました。 具体的には、ssh, telnet, RDP での接続について、事前に登録したサーバにリモート接続を行えるサービスを実現しました。運用者ごとに接続権限を管理し、また証跡を記録する事が可能です。 ### した工夫 プロジェクトの状況を鑑み、進捗管理業務を当時のプロジェクト管理者から引き継ぎました。 当時のプロジェクト管理者は多数のプロダクトを任されており、本プロジェクトに十分なリソースが避けていない状態でした。結果としてプロジェクトが適切に進捗管理されていなかったため、これを私が引き取りました。結果としてプロジェクトの途中でプロジェクトマネージャに任命され、開発プロジェクトの管理及び、リリースのために必要な調整作業を行いました。 調整作業としては、それまで連携が不十分であった各部門（マーケティングチーム、セールスチーム、QA チーム）と密にやり取りし、リリースまでに必要な作業の洗い出し及び、開発の円滑化、必要な情報の周知を行いました。 ### 技術概要 顧客先で動作する中継プログラムの開発と、顧客からのリクエストを受けてサーバとの接続を行うシステムの構築を行いました。顧客には Web サービスとして提供しています。 使用した技術は、Azure, Kubernetes, Rust, Golang, TypeScript, Vue です。 ### 技術的に解決した課題 技術的に解決した課題はありません。このプロジェクトではむしろ、技術以外の部分で活躍しました。 多くのバックエンド開発と少しのフロントエンド開発を行いましたが、システムのコアな部分はより経験年数の多いエンジニアにより実装されています。先輩方から学んで技術力を向上させつつ、彼らと、その他の部門の橋渡しを行い、それぞれが十分にパフォーマンスを発揮出来るようにしました。具体的には下記を行いました。 #### エンジニアチームとマーケティングチームの連携強化 エンジニアチームとマーケティングチームで十分な意思疎通が取れていないと感じたため、 開発状況及び顧客ヒアリングの状況について、定期的に口頭で共有し合う場を設けました。 結果として、下記を実現しました。 - 顧客目線でのより必要な機能の特定 使用感及び顧客からの反応について共有する場を設けた事で、より求められる機能を特定する事に成功しました。具体的には、マーケティングチームは当たり前に出来ると思っていた操作が実際には出来ず、リリースまでに実装が必要である事を特定しました。また、修正が容易であるにも関わらずさほど重要ではないとされて放置されていた箇所について、修正により大幅に使用感が向上する事を特定し、使用感の向上に繋げました。 - 開発コンセプト及びニーズのエンジニアへの共有 マーケティングチームから作りたいサービス像を共有してもらう場を設けた事で、エンジニアが「本当にこのサービス・機能は必要なのだろうか？」と思いながら開発を進めていた状況から、顧客のニーズを理解して開発を進める状況へと改善しました。これによりエンジニアが、顧客の要求、使用ケースをより加味した設計を行える状態にしました。 #### エンジニアチームとセールスチームの連携強化 エンジニアチームとセールスチームで十分な意思疎通が取れていないと感じたため、 セールスチームへの開発状況の定期的な共有と、新規機能リリース時の口頭での説明会を行いました。 これを行う以前はセールスチームに対する情報の開示が不十分であり、不信感を持たれていました。これを行う事でセールスチームからの信用を獲得し、セールス的にあるとより便利なもの（具体的には開発の大まかな予定、デモ環境、新規機能リリース時の口頭での説明）の要求と、顧客ニーズのフィードバックを得ることが出来ました。 #### エンジニアチームと QA チームの連携強化 エンジニアチームと QA チームで十分な意思疎通が取れていないと感じたため、 QA チームと定期的に口頭で話し、開発チームに求められている事を特定し、実行しました。 これを行うまでは QA 側からの要望がわかっておらず、開発チームに不満を持たれていました。 これを行う事で QA 側からの要望を正確に特定し、実行に移せました。 具体的には下記を行い、製品の安定化に繋げました。 - 機能開発前の仕様共有・スケジュール調整 - 機能開発時の開発チームでのテストの強化 - 機能開発後の詳細仕様及び開発チームで行ったテストの共有