傾聴力・協調性・実行力を活かして、誰もが前向きに人生を満喫出来る社会に近づけたい。
・私の人生のビジョンである、「誰もが前向きに人生を満喫出来る社会にする」を実現したい為
・自分の長所を発揮してビジョンの実現に向けて活躍する事で、自分自身の人生も充実させたい為
プロジェクトマネージャ（将来的にはプロダクトマネージャを希望）
人生を満喫出来ている人もいる一方で、肉体的・精神的な疾患や経済的困窮、仕事・キャリア上の悩みなど様々な理由から前に進めずにいる人も多い。こういった方々を支援する事で、誰もが自分の目標に向かって努力し、趣味を楽しみ、人生を満喫する事に集中出来る社会に近づけたい。
私の長所である下記を活かして活躍したい。
・傾聴力：じっくり話を聴き、気持ちに寄り添い、興味を持って質問する事で本音を引き出す
・協調性：関係者と協力関係を築き、専門家を巻き込んでプロジェクトを前に進める
・実行力：プロジェクトを俯瞰し、今何が必要かを考え、着実に実行する
顧客と関係者の生の声を聞き、プロダクトの為に何が必要かを真剣に検討したい。その上で、プロダクトに必要な事であれば何でもしたい。
社の主力製品である生産機械が顧客先にて故障した際に、出張修理を行うエンジニアをサポートするシステムを開発しました。
具体的には、故障した機械の機種及び故障の状況（修理エンジニアがテキストで入力）を元に、過去の故障事例から類似しているものを抽出し、修理エンジニアに提示するものです。
ユーザーにとっての価値を見極め、それを提供出来る方向にプロジェクトを切り替えました。
プロジェクト参画当初は、「機械学習を活用し、事前に分類した故障原因から最も妥当だと思われるものをユーザーに提示する」という方向性でプロジェクトが進んでいました。しかしシステムの解答は情報が乏しく、ユーザーにとって役に立たない物になっていました。ユーザーへのヒアリングからこの事を知り、プロジェクトの方向性を切り替えました。具体的には、システム開発前からユーザーが行っていた、"過去の類似の事例を検索する業務"を、自動かつ検索スキルの乏しいエンジニアでも使用出来る形に置き換えました。結果として、主に入社5年以内の若いエンジニアから、非常に参考になった、再出張せずに済んだ等の評価をいただく事が出来ました。
故障機械の機種及び故障の状況をメールで送ると、過去の類似事例をメールで返送するシステムの構築を行いました。
使用した技術は、AWS SES, AWS S3, AWS Lambda, AWS SQS, AWS ECSです。コードは全て Python で書きました。類似事例を抽出する際の指標としては、文章の類似度を用いました。文章の類似度の算出には、word2vec という技術を用いました。具体的には、事前に word2vec を用いてベクトル化しておいた過去事例と、メールに記載された故障状況を word2vec でベクトル化したものをそれぞれ比較し、類似度が上位のものをメールで返送しました。
サービスの精度及び、システムレスポンスの向上を実現しました。
初期のシステムでは、到着した故障状況と過去の全ての事例を比較していました。これにより、メール到着から返送までに3〜5分かかっていました。また、文章としては似ているが機種が全く異なり役に立たない情報が届いてしまうという問題がありました。検討する過去事例は多い方が良いだろう、という判断でこのようにしていましたが、ユーザーへのヒアリングにより全ての過去事例を検討する必要が無い事を突き止め、過去事例の事前絞り込みを行いました。具体的には、修理エンジニアが修理しているのと同一の機種及びシリーズの事例のみを返送候補としました。絞り込みの区分としては、根本的な機械構造、機種、シリーズ、制作年次がありましたが、こちらもユーザーへのヒアリングを元に、最も適切な区分を突き止めました。これにより、より状況の類似した過去事例のユーザーへの返送を実現しました。また、全事例との比較を排した事により、1分以内でのメール返送を実現しました。
顧客目線での 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 の管理は AWS IoT を使用して行っていましたが、AWS IoT への登録作業と、組み込み PC のインストーラ作成、実行に非常に時間がかかるという問題がありました。（インストーラには組み込み PC ごとの認証情報を組み込む必要があり、毎回作成する必要がありました）この AWS IoT への登録及びインストーラの作成を行う Lambda 関数を作成した事で、組み込み PC のセットアップを大幅に自動化しました。これにより、故障が頻発する組み込み PC の開発速度を向上させ、組み込み PC の安定稼働を実現しました。
ユーザーにとって最も価値が高くなるようなサービスの最適化を実現しました。
本システムには、誤検知が少なく、かつ確実に異常を検知出来る事が求められます。これはトレードオフですが、最も妥当に診断を行うシステムを実現しました。具体的には、正常領域を作成するために使用するデータの範囲を調整しました。特定の機械 A を診断する為の正常領域を作成する際に用いるデータの候補としては、
などがあります。
1.だと、データの収集は楽な反面、正常領域が不当に広がり、異常の見逃しが発生します。4. だと、機械ごとにデータ収集を行う必要がある為に煩雑であり、またデータが不十分である為に正常領域が小さく、誤検知が発生します。
これらを両立する、3. を特定し、サービスの最適化を実現しました。
最終的には、このスコープは機種ごとに異なる事が判明した為、機種ごとに使用するデータのスコープを変えて正常領域の作成を行いました。
システムのサーバについて、運用・保守を行うためのリモート接続を行うためのサービスを開発しました。
具体的には、ssh, telnet, RDP での接続について、事前に登録したサーバにリモート接続を行えるサービスを実現しました。運用者ごとに接続権限を管理し、また証跡を記録する事が可能です。
プロジェクトの状況を鑑み、進捗管理業務を当時のプロジェクト管理者から引き継ぎました。
当時のプロジェクト管理者は多数のプロダクトを任されており、本プロジェクトに十分なリソースが避けていない状態でした。結果としてプロジェクトが適切に進捗管理されていなかったため、これを私が引き取りました。結果としてプロジェクトの途中でプロジェクトマネージャに任命され、開発プロジェクトの管理及び、リリースのために必要な調整作業を行いました。
調整作業としては、それまで連携が不十分であった各部門（マーケティングチーム、セールスチーム、QA チーム）と密にやり取りし、リリースまでに必要な作業の洗い出し及び、開発の円滑化、必要な情報の周知を行いました。
顧客先で動作する中継プログラムの開発と、顧客からのリクエストを受けてサーバとの接続を行うシステムの構築を行いました。顧客には Web サービスとして提供しています。
使用した技術は、Azure, Kubernetes, Rust, Golang, TypeScript, Vue です。
技術的に解決した課題はありません。このプロジェクトではむしろ、技術以外の部分で活躍しました。
多くのバックエンド開発と少しのフロントエンド開発を行いましたが、システムのコアな部分はより経験年数の多いエンジニアにより実装されています。先輩方から学んで技術力を向上させつつ、彼らと、その他の部門の橋渡しを行い、それぞれが十分にパフォーマンスを発揮出来るようにしました。具体的には下記を行いました。
エンジニアチームとマーケティングチームで十分な意思疎通が取れていないと感じたため、
開発状況及び顧客ヒアリングの状況について、定期的に口頭で共有し合う場を設けました。
結果として、下記を実現しました。
顧客目線でのより必要な機能の特定
使用感及び顧客からの反応について共有する場を設けた事で、より求められる機能を特定する事に成功しました。具体的には、マーケティングチームは当たり前に出来ると思っていた操作が実際には出来ず、リリースまでに実装が必要である事を特定しました。また、修正が容易であるにも関わらずさほど重要ではないとされて放置されていた箇所について、修正により大幅に使用感が向上する事を特定し、使用感の向上に繋げました。
開発コンセプト及びニーズのエンジニアへの共有
マーケティングチームから作りたいサービス像を共有してもらう場を設けた事で、エンジニアが「本当にこのサービス・機能は必要なのだろうか？」と思いながら開発を進めていた状況から、顧客のニーズを理解して開発を進める状況へと改善しました。これによりエンジニアが、顧客の要求、使用ケースをより加味した設計を行える状態にしました。
エンジニアチームとセールスチームで十分な意思疎通が取れていないと感じたため、
セールスチームへの開発状況の定期的な共有と、新規機能リリース時の口頭での説明会を行いました。
これを行う以前はセールスチームに対する情報の開示が不十分であり、不信感を持たれていました。これを行う事でセールスチームからの信用を獲得し、セールス的にあるとより便利なもの（具体的には開発の大まかな予定、デモ環境、新規機能リリース時の口頭での説明）の要求と、顧客ニーズのフィードバックを得ることが出来ました。
エンジニアチームと QA チームで十分な意思疎通が取れていないと感じたため、
QA チームと定期的に口頭で話し、開発チームに求められている事を特定し、実行しました。
これを行うまでは QA 側からの要望がわかっておらず、開発チームに不満を持たれていました。
これを行う事で QA 側からの要望を正確に特定し、実行に移せました。
具体的には下記を行い、製品の安定化に繋げました。
開発プロジェクト
サービスの正式リリースまでに、正式リリースに必要な全ての準備が完了している状態にする責務
（正常に動作する製品、仕様書、マニュアル、関係各位への連絡・合意形成など）
まず、正式リリースの時点で必要なものを洗い出す必要があると考えました。
正式リリースの時点で必要なものの一覧が社内に無かったため、定期的に「今すぐに正式リリース出来るか？」をシミュレートし、必要なものを洗い出しました。また、洗い出したものの一覧をドキュメントにし、新規サービスの開発時にはそれを参照すれば済むようにしました。
開発中は、常に進捗と予定を比較し、状況に応じた対応を取る必要があると考えました。
この状況に応じた対応について、進捗と予定が乖離すればするほど難しくなると考えました。これを回避するため、週次で進捗と予定を比較し、乖離が少ない段階で調整を行いました。
また、見積もりの精度を向上させ続ける必要があると考えました。
これを実現するため、見積もりに対する実際にかかった工数を測定し、イテレーションごとの見積りにフィードバックしました。
・各々が各々を尊重した結果として、忌憚のない意見を言い合える環境
・質問や提案が推奨される環境