Masashi Tajiri

◾️システム ・インフラ：AWS(EC2、RDS MySQL Aurora、ALB、CloudFront、Elasticache、S3、Lambda、DynamoDB...etc) ・監視：Datadog、NewRelic ・開発環境：Docker ・バックエンド：PHP、Laravel ・フロントエンド：HTML、 SCSS、jquery ・構成管理：ansible ・CI/CD：GithubActions ・バージョン管理：Git (Github) ◾️チーム規模 ・最大6名（PL（自分）＋5名） ◾️業務内容 ・要件定義 　・ビジネスサイドのディレクターの要求を開発観点で要件化、またはそのお手伝い ・基本設計 　・ MySQLのテーブル設計 　・API IF設計 　・ファイルIF設計 ・詳細設計 ・実装 　・LaravelでのPHPの実装 　・HTML、SCSS、jqueryの実装 ・単体テスト 　・ PHPUnitを用いたテスト ・ソースコードレビュー 　・GithubのPRを使用したコードレビュー ・結合テスト準備 　・Gatlingを用いた負荷試験の設計 　・Cypressを用いたくじ引き機能の確率検証の設計 ・結合テスト実施 ・アラート対応 　・NewRelicを使用したログ調査 　・AWS EC2に接続しての調査 　・CloudWatchを使用したログの調査 　・Lambdaのエラーログ調査 　・SQSの調査 ・総合テスト準備 　・開発側主導の案件などの要件に基づくテスト項目の作成、そのレビュー ・総合テスト実施 ・リハーサルテスト実施 ・その他タスク 　・調査タスク 　　・ビジネスサイドの依頼で調査を実施、必要に応じてSQLを作成しEC2上から実行するなど 　・メンテナンス 　　・ALBやCloudFrontを操作してサービスをメンテナンス状態にする作業 ・1on1 ・顧客折衝 ・メンバーのサポート ・プロジェクト進捗管理 ・案件優先度調整 ・人事評価をつける（2023年7月~） ◾️実績 ⚫︎性能試験の実施 ⚪︎状況 ・リニューアルをするコンテンツでは、くじ引き機能があり、管理画面上で設定した確率で当選が出るかの検証が必要であった ⚪︎行動 ・負荷試験にて使用したGatlingは、サーバに繰り返しアクセスをすることでサーバの性能を試験するものだったため、ロジックの検証には使用できないと判断。Cypressを用いた自動画面操作によって当選が設定通りの確率で排出されるかを検証 ・当時、Cypressはプロジェクトで導入した実績がなかったが、以前の経験からテストコードの実装と導入手順を整備し、担当エンジニアの性能試験実施をサポートした ・確率の検証方法についても調査し、数学的に妥当な試行回数を検討、設定し、確率の検証を実施 ⚪︎結果 ・リリースから現在に至るまで等賞の売れ残り、早い段階での売り切れが起きておらず、おおよそ設定値通りの確率で抽選が行われるシステムになった ⚫︎コンテンツリニューアル案件のリリース ⚪︎状況 ・コンテンツリニューアル案件において、初めてマネジメントを担うことになった ・メンバーは全員フルリモートでの勤務 ・プロパー1人、BP2人の構成 ⚪︎行動 ・個々人のスキル感を詳細に把握し、担当する機能を適切に分担した ・フルリモート勤務であることから、作業進捗や問題の発生に気づきにくい状況であったため毎日実施していた夕会に加えて昼会も実施し、早めに問題の回収、対応に当たれる環境を作った ・（スキル感が心許ないメンバーもいたため）チーム内でスキルのレベルに差があったため、PHP Unitの勉強会の開催や、モブプログラミングを実施した ・顧客とのMTG結果は実施後、翌日すぐに展開を行い、メンバーがプロジェクトの最新の情報を常に知っている状況を作った ⚪︎結果 ・切り戻しになるバグもなく、大きな遅延も発生させずにリリースまで完遂 ・現在もサービスの主力コンテンツとして、200万件/日 のアクセスがあるコンテンツとなっている ⚫︎Laravelアップデート実施 ⚪︎状況 ・Laravel6のサポート終了のため、Laravel6から8へのアップデートを実施 ⚪︎行動 ・調査はアップグレードガイドをベースに基本的なことを明文化し、認識のずれを防ぐことで大きな手戻りを防いだ ・結合テスト期間の見積もりを見誤り、担当のエンジニアだけでは対応しきれなかったため、他のエンジニアにもサポートを依頼し、オンスケジュールでテストを終えることができた ・リカバリを増員だけでなく、タスクを分解し、集中的にテストデータの入稿方法や、バッチの実行方法、実行するSQLの作成などに専念する体制を構築した ⚪︎結果 ・メンバーが迷うことなく迅速にテストを終えることができ、手戻りなくアップデートを完遂 ⚫︎システムの引き継ぎ ⚪︎状況 ・保守対象のシステムの中で、引き継ぎが完了していないものがあった ・LambdaやSQSを組み合わせた複雑なシステムのため、前任よりレクチャーの時間を設けたものの、理解の浅い状態であった ⚪︎行動 ・チーム内で工数に空きがあり、新しいチャレンジをしたいエンジニアにタスクアサインし、引き継ぎ資料のブラッシュアップを依頼 ・完成した資料をベースに、あらためて自身のシステム理解も進め、システムアラート発生時には、積極的に対応を拾うことでさらに自身の理解度も高めた ・対応実績をナレッジとしてドキュメント化し、次回以降のアラート対応を他のメンバーに実施してもらうサイクルを生み出した ⚪︎結果 ・システムのアラート対応ができるメンバーを増やし、属人化しない体制を構築できた ・現在は、アラート対応も自チームで巻き取れるようになり、お客様の監視工数の削減にも寄与 ・この取り組みの他、重大なインシデントをチーム発足以降発生させていないことから、顧客満足度も高く社内表彰にも繋がり、チームの取り組みを全社的に知ってもらう機会となった ⚫︎外国籍メンバーのマネジメント ⚪︎状況 ・2023年5月から外国籍のメンバーがチームに参画 ・日本語は話せるものの、システムの複雑な話や、チームビルディングに関する話ではうまく意思疎通が図れない場面がある ⚪︎行動 ・わからない単語を伝えるときは、言葉を英語に翻訳して伝え、加えて「図を使う」ことを意識している ・draw.ioというツールを用いて会話中に言葉ではなく言葉ではなく、図示しながら頭の中のイメージを擦り合わせるようにしている ・また私が役割上コミュニケーション機会が多いため、そこで得られたコミュニケーションの工夫を他のメンバーにも展開し、メンバー間のコミュニケーションにおいても問題が発生しないように努めている ⚪︎結果 ・現在に至るまでコミュニケーションに起因するタスクの大きな手戻り等は発生しておらず、高いパフォーマンスを発揮してもらえている ・他メンバーとのコミュニケーションも問題なくできており、私の指示やサポートがなくともチームが回る状態を作ることができた ⚫︎DynamoDB 　・リニューアル案件ではDynamoDBのテーブル設計が必要であったが、これまでDynamoDBに触れた経験がなかったため、公式ドキュメントを読み込み、稼働中のテーブルやソースコードを見る等してキャッチアップを行った 　・結果として、テーブル設計において顧客から大きな指摘もなくクリアすることに至った 　・理解度を高めたため、途中に発生した要件変更によるテーブル設計の変更や、テスト時に発覚した問題にも柔軟かつ迅速に対処することができた ・結合テスト 　・プロジェクト参画前までは標準的な開発プロセスに沿った開発の経験がなく、結合テストの適切な粒度や単体テスト、総合テストとの棲み分けの理解が低い状態であった 　・知識を得るために、ネット上の解説記事を読み、PMへレクチャーを依頼し、書籍を読み込んでキャッチアップし、結合テストに対する理解を深めた 　・学習の成果として、テスト観点を盛り込んだ結合テスト仕様書のフォーマットを作成し、テスト作成の品質向上に寄与 　・現在は単体テストと総合テストとの棲み分けに対し、自分なりの見解を持てる状態に至っている ・プロジェクトマネジメント 　・これまでは2名で回していたプロジェクトだったため、形式的なマネジメントは不要であったが、メンバーが4名に増員し、かつ2名はBPのメンバーだったため、プロジェクトマネジメントの学び直しを行った 　・業務とは別に社内の課題改善チームで社内業務の標準ドキュメント作成を行なっており、PMBOKを学習していたため、解説本からPMBOKをキャッチアップしていた 　・結果として、プロジェクトマネジメントや、このチームでは何をすべきかの理解に繋がり、計画段階におけるWBSの作成、ガントチャートへの落とし込み、ステークホルダーの把握を行った ⚫︎1on1の導入 　・チーム内で実施していながった1on1を導入し、メンバーのメンタルの変化や、業務の中での困りごとを細かく回収する仕組みが整った ・会議体の改善 　・顧客への報告会を毎週月曜日に実施していたが、報告前の社内打ち合わせを金曜日に行っていたため、打ち合わせ時の状況と報告会の時の状況に乖離が発生し、報告の品質が下がっていた 　・顧客の担当者がエンジニアで、具体的なシステムに関する報告が求められる中で、ディレクターを介したコミュニケーションがなされていた 　・この状況に対し、打ち合わせを報告会の当日に移し、自身も報告会に参加するよう自ら志願した 　・結果、打ち合わせ時の状況と報告会時の状況の乖離が小さくなり、顧客にプロジェクトの最新の状況を報告することができるように至った 　・社内打ち合わせ時に「この内容は自分の方が説明できるので、自分に振ってほしい」とファシリテーターのディレクターに依頼し、発言機会を増やしていった 　・最終的にファシリテーターの業務も巻き取り、顧客に伝わりやすいようなアジェンダに刷新し、ディレクターを介したコミュニケーションの解消を行った 　・また、会議時にカメラをオンにすることを提案し、自身の顔を顧客に覚えてもらい、信頼関係の構築を測った結果、顧客との関係性も改善 　・これらの取り組みとプロジェクトマネジメントの実績から、顧客からのフルリモートチームでの開発業務に対する不安を払拭でき、サービスのメインコンテンツのリニューアル案件を任せてもらえるようになった ・新規参入メンバ受け入れフローの整備 　・リニューアル案件の対応時に2名の増員があり、増員メンバーがスムーズに業務に参画できるように新規参入メンバ受け入れフローの整備を実施 　・3ヶ月という期間を見据えた受け入れフローは存在していたものの、この案件において、キャッチアップ期間は2週間しかとれない状況であった 　・2週間でキャッチアップが完了するよう「キャッチアップ後の状態を具体的に設定」「キャッチアップ範囲を絞り込む」「キャッチアップ中は専用のTeamsに専用のスレッドを立てていつでも質問をしていい状況を作る」というアクションを実施 　・これらによりキャッチアップが計画的に進み、プロジェクト参画時に頻発する「聞きづらい状況」の回避にも繋がった 　・ここで整備したフローが現在も活用され、現在までのメンバーの入れ替えや受け入れ時にもキャッチアップ期間を2週間で収めることができ、メンバーの入れ替えによる業務品質の低下を出すことなくプロジェクトの運営に繋がっている