kd

## NAONAとは コミュニケーション可視化のプラットフォームです。オンライン/オフラインのどちらのコミュニケーションにも対応していて、コミュニケーションデータの解析・蓄積やアプリケーションを作成するための要素を提供しています。NAONAプラットフォーム上で、1on1やグループディスカッションなどのアプリケーションを開発しています。 ## プラットフォーム拡張(管理画面とREST API開発) 【課題】 - (プロダクト) プラットフォームの管理画面でCRUD操作できないデータがあり運用負荷が高かった - (プロダクト) アプリケーションが使う機能として利用所許諾機能を追加開発する必要があった - (プロジェクト)入社直後の既存システムの理解度が低い状態で協業先の業務委託メンバーと開発を推進する 【解決策】 - スクラムに入る前のオンボーディング期間でプロトタイピングをしながら構成をキャッチアップし、これまでの工数見積もりよりも精度が高く、スピードのある開発サイクルを実現することができた。 - 実際には、オンボーディングとしてAPIを実行したりゆっくりと検証することをする期間として与えられていたが、プロトタイピングの提案を行い、スクラムに想定よりも早く入ることを提案した。 【成果】 - 予定工数の2/3程でリリースまで完了することができた。 - オペレーションの運用コストを1/3程に短縮 ## PoCアプリ: 面接練習アプリの開発 NAONAを面接練習に使えないか検証するためのWebアプリケーションを実装。Nuxt.js/TypeScript, Amplifyで構築。アプリケーションの機能としては、面接練習を開始すると、問題が表示され、マイクを使って回答すると回答内容についてのフィードバックが得られるもの。言い淀みや話速などの指標で回答が上手く行えているか練習生が振り返りに使うことができる。PoCアプリのフィードバックを得るため、転職時に親交を深めたエージェントの方にフィードバックをもらえるようにアポイントを取ることや営業に同行しながらヒアリング・機能検討を進めた。 ## PubSubAPIの構築 【課題】 - アプリケーションのユーザーが操作したことを他のユーザーの画面に反映させたい機能要望 - 必要な機能ではあるが実装コストが高い場合を危惧してなかなか優先度が上がらなかった 【解決策】 - AWSのAppSyncをキャッチアップしGraphQL Subscription機能を使えば実現できることを自力で調査 - AWS SAとの打ち合わせを設定し他の実現方法も含めてチームメンバーおよびAWS SAと議論の場を設けた - API GatewayのWebSocket方式をAWS SAからは勧められたが自分の検証結果を鑑みると開発工数などは低いためAppSyncを採用することを提案 - プロトタイプを作り社内で採用実績のなかったGraphQLとAppSyncの勉強会を実施 - 新技術の提案・導入だけで終わらないように、フロントエンドの実装例などもドキュメント化 【成果】 - 短期間でGraphQL Subscription機能を使えるAPIを構築することができた - 要望の上がった背景の機能以外の機能でも使われる汎用的なAPIとなった - フロントエンドで機能実装する際に低い工数で問題なく導入することができた →こちらをテーマにJAWS DAYS 2022 PREEVENTで登壇 ## ブラットフォーム(CI/CDパイプラインの刷新) 【課題】 - 外部ベンダーが構築したJenkins製CI/CDパイプラインを内製化・エンハンスできない - 社内外にJenkinsに対する知見を持ったエンジニアがいない - 既存のリリースフロー、パイプライン構成ではリリースに時間がかかる 【解決策】 - AWS CodePipelineをベースにしたGitHub Flowベースのパイプラインに刷新を提案 - 継続デリバリーやThe Twelve-Factor Appのベストプラクティスに則ったCI/CDを設計 - 移行用の検証環境を用意して移行のリハーサルまで実行することでパイプライン移行実施時に起こり得るトラブルを洗い出してから移行本番に臨むようにプロジェクトを推進 【成果】 - 目立ったトラブルが発生することなくCI/CDパイプラインの移行に成功 - リリースにかかる工数が大きく短縮 - リリース頻度が上がり、リリースへの安心感が向上 - 別モジュールのCI/CDパイプラインでも同じ構成を採用することに繋がり社内にノウハウが溜まった ### プラットフォーム(監視の仕組み刷新) CloudPackに依存していた監視の仕組みをCloudWatch MetricsやSNSなどのAWSサービスをベースとしたSlack/Backlog通知をする監視基盤に刷新 ## 内製Web会議開発 【課題】 - 既製品のWeb会議アプリで内蔵スピーカーを使うユーザーの音声をNAONAアプリケーションで音声を解析しようとすると他者音声と区別がつかないため、精度が著しく低下する課題があり、その影響でディスカッションの評価制度に影響を与えていた 【解決策】 - 粘り強くWebRTC関連のSDKの調査や技術調査を行い、同じブラウザ内であればWebRTCを使ったWeb会議の音声と内蔵スピーカーが拾う音声を分離して解析できることを突き止めた - ブラウザ版Web会議アプリを内製化する開発工数とライセンス費用がネックになっていたが、Amazon Chime SDKを使うことで簡単にデモアプリを作成し初期費用なく利用できることを調査で明らかにして社内で共有した - Amazon Chime SDKを有効に活用するためには社内で利用実績のなかったReactを使う必要があったがチャレンジすることを提案した - チームメンバーのマネジメントとReact/ChimeSDKのノウハウ伝授をしながら開発を進める 【成果】 - 音声解析精度が上がり、サービスを展開する上で重要な顧客との提携が大幅に前進した - ChimeSDK、React、API(APIGateway+Lambda+DynamoDB)、EventBridgeなどのスキルを高めることができた ## その他 ### Slackでのオープンコミュニティ促進 チームにジョインした当初、Slackは導入されていたがDMやプライベートチャンネルがメインで使用されていた。自分自身も新しく参画した立場で少しやりにくさを感じたのと、今後、より深い議論をオープンにしていくことが必要だと感じたため、パブリックチャンネルをメインにした運用へ変更を決定した。協力的な姿勢で取り組んでいただけ、リモートワークがしやすくなったという声などをいただけた。 ### 開発勉強会としてのセキュリティ勉強会を開催 セキュリティ対策を全くできていないわけではなかったが、開発、チームとしてここまで出来てるからOK、あとはここはやらなければいけない、のような具体的なものを自分、チームが持てていなかったのを課題に感じ、企画、提案、実施中。 ### EM役割 開発マネージャーが異動となり、明確なマネージャーが不在となり、自分が開発マネージャーとしてやるべき動きをやることが増えるようになった。例えば、メンバーとの1on1(明確なポジションではないので完全な定期開催というより個々人と話す機会を増やしながら進めた)や、開発全体でのKPTなどを開催し、タスクとして落とし込みなどを行なった。