ID:74717さん

# プロジェクト概要 電話の発信者が声で発した呼び出し相手の名前を音声認識AIが聞き取り、取り次ぎ先を判別し該当者に電話を転送するサービス # チーム情報 - プロジェクト全体の規模: 50人 - チーム構成:６人 - 担当した役割:メンバー # どのような機能の開発・実装か 管理コンソールのバックエンド部分、ユーザーに関する下記API実装 - ユーザー新規作成 - ユーザー情報個別取得 - ユーザー情報編集 - ユーザー情報リスト取得 - ユーザー情報削除 - 認証トークン生成 - 認証トークン再生成 - 認証トークン削除 ### 自身の担当フェーズ - 英語ドキュメント読解 - 仕様書レビュー - デイリーミーティング - ユースケース作成 - 詳細設計書作成 - OpenAPI定義 - API実装 - ユーザー新規作成 - ユーザー情報個別取得 - ユーザー情報編集 - 認証トークン削除 - 単体テスト設計作成 - ユーザー新規作成 - ユーザー情報個別取得 - ユーザー情報編集 - ユーザー情報リスト取得 - ユーザー情報削除 - 認証トークン再生成 - 認証トークン削除 - 自動テストコード実装 - ユーザー新規作成 - ユーザー情報個別取得 - ユーザー情報編集 - ユーザー情報リスト取得 - ユーザー情報削除 - 認証トークン再生成 - 認証トークン削除 - リファクタリング - 使用技術 - 言語: Go - フレームワーク: Echo - DB: PostgreSQL - 開発環境: - VScode - Docker - Backlog - Github - Slack - AWS(Cognito, EC2,CloudWatch,CloudFront,) ### 課題 1. 完全未経験からの案件だったため、知識に欠けてる部分が多かった 2. チーム結成初期の段階で二名の欠員が出て、チームの雰囲気が良くない時期があった。 3. ユーザーの新規作成APIを実装するにあたり、cognitoを利用する事になった。 ### 工夫 1. 毎日帰宅後業務の復習と、必要な技術の調査をしていた。また、些細な事でもなるべくNotionで手順書を作成し、絶対にミスが無いようにした。 1. 例：Githubにプッシュする際の操作手順のマニュアル作成 2. 例2：cognitoでユーザープールを作成する際の操作手順 3. 例3：プロジェクトの仕様書に書いてる細かい事柄をピックアップしてメモ 4. 例4：顧客とのデイリーミーティングの内容を全て個人的にメモ 5. 例5：個人学習。自宅でユーザーCRUDのバックエンド作成。 2. 一番経験の浅い自分が積極的に質問したり、メンバーがミスしても笑い飛ばしたり、サポートしたり、チームのフォローアップに専念した。 1. なるべく時間は取らないように、自分で調査できる部分は調査し、質問の内容をまとめて質問した 2. メンバーがミスしてもすぐにサポート出来るように、なるべく他の人のタスクにも気を配るようにした 3. 実際に自宅でAWSにハンズオン形式で触れてみて、認証機能についての理解を深めて実装出来ることを確認。 ### 取組の成果 1. メンバーが「あれって仕様書じゃどうなってたっけ？」「あのmakeコマンドってどうやってたっけ」「あの時のミーティングって結局結論はどっちになってたっけ？」等、たまに困っているとき自分のメモに記載されている事が度々あり、力になることができた。 1. 一度メモした事や取り組んだ実装は、なるべく理解するようにしていたので、後から参画したメンバーにも説明が出来るようになった 2. チーム参画後、４ヶ月経過する頃には「タスクの消化がかなり早くなってきて驚いている。仕事降るのを悩むとは思わなかった」とリーダーに褒められた 1. メンバーからは真面目、優しい等、勤務態度や性格に関することを褒められていた。チーム全体で積極的に質問を飛ばしあう雰囲気が出来た。 3. cognitoについて、他のメンバーに教えられる程度の知識がついた。

# プロジェクト概要 大手携帯会社の顧客管理システムに流すスクリプトの結合テスト - オンライン処理とバッチ処理の二種類 - 顧客のデータを管理している性格上、即時性のあるクエリも発生する。その場合即時でレスポンスを返す処理がある - メインはバッチ処理で、大量データ。夜間で一回とか月1とか。 - 全国の顧客のデータを一括で処理するので何千万件とかを一気に扱う。 - 毎月リリースがあって、それに向けて機能の追加や改善の作業 ## 規模感 - チームは25名 - 製造/開発 - 単体テスト/開発 - 結合テスト/ - シナリオ作成チーム - 試験はブラックボックスで。詳細設計を見ながらテストを行う。コードは見ない。 役割:メンバー 自身の担当フェーズ: - 結合テスト実施 - テストの際の資材準備 - 問題があった場合の起票 - SQLレビュー - データの在庫管理 - DB洗い替え ### 課題 1. テストの実施準備及び実施にかかる時間の短縮 1. テスト実施及び実施の手順が複雑で、初回は1つの実施準備に12時間、実施には8時間ほどかかった。 2. 実施に時間がかかるので、最初の月は40個ほどしかテスト出来なかった 2. 実施準備、実施の際のミスを減らす 1. 最初の月のミス率が40％ほどあり、再実施が多かった。 ### 工夫 1. ミスした箇所を全て細かくメモ。 2. 最初ミスした時、なぜミスしたのか、どうしたらミスがなくせるのか、凡ミスなのか、知識不足によるものなのか、「なぜなぜ分析」を行い、全てメモした。 3. 分からないときは理解できるまで何回も聞き直した。 ### 取組の成果 - テストメンバーの誰よりもテスト実施数が多い月が続いていた。 - ミスが初月は40%程あったが、３ヶ月経過するころには１％まで落とせた。 SQLのレビュー 静的解析結果管理

# プロジェクト概要 ソニー銀行のWebアプリケーションフロントエンド開発チームに中途参画 開発自体はほぼ終わっているが、不具合が多すぎて人手が足りない＆テストしないといけない部分も多いため、実装修正と点検要因として参加することに。 ### 規模感 全体:100人前後 チーム構成:7人 使用技術:React,TypeScript、Gitlab、AWS,AWS Codecommit、VScode, 担当した役割：メンバー 自身の担当フェーズ - 実装修正 - 校正回覧で修正依頼が出された実装部分の修正。 - 障害対応 - 毎日降りてくる障害の対応。自身の対応数は1日1～2件。 - 各種点検、エビデンス作成 - 画面の点検 - ボタンや文言点検 - デザインガイド点検 - 設計書点検 - URL遷移先点検 - レスポンシブ点検 - 英語版表記点検 ### 課題 1. 自分よりも経験の浅いメンバーが居たため、その人のフォローをしながらタスクをこなした - なるべく分かりやすく、簡潔に教える努力をした 2. 自分自身もReact、TypeScriptは初めてだったので学習が必要だった ### 工夫 1. gitの概念と使い方、codecommitの見方、プルリク作成の仕方、vscodeの使い方等、過去のプロジェクトでNotionにメモっていたものを活用しながら教えた。 2. PLからタスクを降られる時、経験の浅いメンバーにも説明が出来るように理解しながら聞いた。 1. 何故そのタスクをする必要が出来たのか 2. 何故このやり方でテストをするのか 3. 仕事から帰宅後、まずjavascriptを一から全て学習し、そのあとReactを使用してTodoアプリを作成した。 ### 取組の成果 1. 教えながらでも、自分より経験の浅いメンバーよりはタスクを3～5倍上げることが出来た。 2. 殆どつきっきりで教えた結果、経験の浅いメンバーは1.5ヶ月後には単純な事なら一人で出来るようになっていた。(gitやAWSの使い方、エラーの解決方法、処理をlog出力で追う等）