ID:43598さん

## プロジェクト詳細 Gmailガイドラインに準拠にするにあたって、DKIM/SPF/DMARCは対応済みでした。 4,5,6月と段階的に厳しくなっていく1click配信停止に対して全社的に対応するために他部署のフォローアップをしていました。 具体的にはスプレッドシートにメールの利用用途とそれに対して利用しているメールツール、1click配信停止が要不要の旨、対応状況等を記述していただきました。 このプロジェクトを達成することは以下のことがモチベーションとなっています。 - 会社が持つ各サービスからのメールの当たり前品質・信頼性の維持 - 仮にGmailガイドライン周りで後々問題が出たとしても、対応までの時間を短縮する - 各部署のメール運用者のメールに対して解像度向上 ## 担当業務 - 知識のキャッチアップ - 各部署のの各ステークホルダーへのヒアリング・折衝 - 現状整理・結局何をしたらよさそうかの提案 - 進捗管理 - 時々postmaster toolsを見て、状況共有 ## メインで触った技術 - スプレッドシート（スプシ） - Slack ## 実績 - 各部署の1click配信停止の対応状況のリスト作成 - 各部署の運用担当者のメールに対して解像度向上 ## このプロジェクトならでは、なかなか得難いなと感じた経験 - 各ステークホルダーへの折衝 - スプシの「〇〇番の〇〇列は〜ですが、〜みたいな状況の時、運用どうですか？進捗どうですか？」という対応依頼や進捗管理、スプシの更新依頼や深堀りヒアリング等 - 細かい内容は担当者に任せ、自分の業務はほぼスプシとSlackを打つこと - 振り返ってみると自分の時間は短い気がしますが、濃密に感じました ## このプロジェクトから得た学び・反省 ステークホルダーが多くいる場合のスプシのシートの分け方を学びというか次からはこうしたいという反省がありました。 具体的には、各部署ごとにスプシのシートを分けることです。 このプロジェクトでは、もともとGmailガイドライン対応で利用していた、全部署のまとめ用の1シートで進捗管理をしました。 ただ、ステークホルダーも多かったり、メールの用途毎に記述していく量が多くなっていきやすく、スプシの更新や行を増やしたりするハードルが大きくなっていた気がします。 進捗管理に当事者意識を出すためには自身で更新をしてもらうということが重要な要素の1つだと思っており、そこへのハードルの低減に苦労しました。 なので、仮に似たようなことが今後ありそうなら、ステークホルダー毎に中のシートを分けて、更新のハードルを下げ、まとめ用のシートは別で作りたいと思いました。 ## このプロジェクトから広がった自分の関心ごと 最初でかっちりヒアリングせずに、ヒアリングの度に現状が更新されていく中での進捗や状況整理・管理方法に対して関心ごとが増えた気がします。 ただ、積極的に学ぶというよりは「次はこうしたいな」みたいな熱量です。 理由としては本や方法論を学ぶより、実践ありきな気がしたためです。

## プロジェクト詳細 メールSaaSを複数使っており、割高なメールSaaSに依存していた分析部分がありました。 また、Gmailガイドライン対応で複数のメールSaaSを利用していると運用・管理コストが高いことがわかりました。 このプロジェクトは安いメールSaaSを運用しながらも分析も可能にするためのプロジェクトでした。 以下の項目がこのプロジェクトを進めるモチベーションとなります。 - 管理するメールSaaSを "減らす" ことで、管理・運用コストを下げる - 割高なメールSaaSをやめ、全体の料金を下げる ## 担当業務 - 知識のキャッチアップ - マーケやユーサポ等のグループの各ステークホルダーへのヒアリング・折衝 - 現状整理からのメールドメインの設定方針の提案 - 依頼と対応実施 - 監視ツールの作成と啓蒙活動 ## メインで触った技術 - Terraform - AWS Firehose - AWS DataGlue - AWS Redshift Spectrum - AWS S3 - AWS Lambda - Rundeck - GitHub Actions - Go ## 実績 - メールの分析基盤を作成・社内向けのユーザガイド作成・改善 ## このプロジェクトならでは、なかなか得難いなと感じた経験 - 分析基盤の作成 - Redshift Spectrum周りの知識 - 利用SaaSを減らす際の運用設計（できることは減らさない等、スムーズに移行するためのサポート等々） ## このプロジェクトから得た学び・反省 - 分析基盤を作成する時のRedshift SpectrumやFirehose、Lambda等のAWS周りの知識 - メールの生の運用 - メールにかかっている料金 Redshift Spectrumでは、Athenaと異なり自動パーティショニングが無いことやFirehoseとDataGlue連携にてとても細かく設定する必要があることを学びました。しかしこれによってAthena側もいつのまにか利用できるようになることを知りました。これにより、Redshift Spectrumを利用しなくても済むような状況ならば、FirehoseとDataGlueさえ編集できたら良いことを知りました。 技術ではないですが、マーケチームが実際に何を気にしてメールを送っているかをヒアリングすることで知ることが出来ました。 1ヶ月に何通送信して、それにはどれくらいの費用がかかっているのかを知りました。 このプロジェクトはちょうど期中で始めたこともあり、半期をまたぐ形になったことによる評価周りが反省ポイントとしてあります。 せっかく良いものを作っても、伝達不足もあったせいか、評価に載せきることが出来ませんでした。 ## このプロジェクトから広がった自分の関心ごと - 分析基盤について - 「どのように使いたいか」「どういう分析をしたいか」「1クエリに対してのパフォーマンス」「既存のテーブルと一緒に分析可能か(JOIN可能か)」みたいな

## プロジェクト詳細 2024年2月から適用される、「メール送信者のガイドライン」への対応 ## 担当業務 - 知識のキャッチアップ - 現状調査・進捗管理 - マーケやユーサポ等のグループの各ステークホルダーへのヒアリング・折衝 - 現状整理からのメールドメインの設定方針の提案 - 依頼と対応実施 - 監視ツールの作成と啓蒙活動 ## 実績 - [Postmaster Toolsの迷惑メール率をDatadogで監視する](https://engineer.crowdworks.jp/entry/2024/02/19/105453) - Postmaster Toolsの迷惑メール率をDatadogに投げて、Slack通知するような仕組みを作り、また他部署への横展開をしました ## このプロジェクトならでは、なかなか得難いなと感じた経験 - 知識不足・状況理解不足からのタスクマネジメント - メールヘッダーの細かい知識 ## このプロジェクトから得た学び・反省 - マトリクスを使ったチェックリストの伝達効率の良さ - 知識不足だと、理由のわからないチェックリストを作るので、何度も作っては、作り直しをしました - MarketingメールとTransactionメールの違い ## このプロジェクトから広がった自分の関心ごと - 知識不足・状況理解不足においてのタスクマネジメント - まず、1月末という締切がありました。更に年末年始という長期休暇もありました。そんな中、不確定要素を洗い出し、ステークホルダーが居て時間がかかりそうなところを優先したりしていったりするところは学びになりましたし、インボイス施策より締め切りが短かく、納期ファーストをこんなに意識したのは初めてだったかもしれません。 - その御蔭で、高い温度感のの中でも優先順位を付けるという行為は存外楽しく、上長・リーダーに状況をどう伝えると安心してもらえるかということへの関心がより高まった気がします。 - 今まで全然意識してこなかった、迷惑メールなどについては、フィルタリングでなんとかしてたのですが、そもそもメールセキュリティについてちゃんとやれば、迷惑メール率は減り、良い世の中になるんだなと学ぶことができ、メールセキュリティそのものに関心をもつようになりました。

## プロジェクト詳細 - crowdworks.jpの請求書にインボイス制度に対応させる ## 担当業務 - 23年10月1日から開始されるインボイス制度の調査・ヒアリング（国税庁確認・経理確認・法務確認等含む） - 現状調査：現プロダクトの帳票周りの機能に関しての調査 - 差分確認：現プロダクトに社会制度をどのようにフィットさせるか方針検討・決定 - どこまでやるか、何をやらないかの方針検討・決定 - 方針決定後の実装の設計 - 実装 - 他チームへ依頼 - チームのリリース調整 - どれくらい・どんなトラブルやエラーを許容するか、起きた時どう対応するかの方針検討・方針決定・相談・決定・テクニカルサポートガイド作成 ## 実績 - 特定条件を満たした場合の請求書をインボイスとして発行可能にする機能の追加(返還インボイス等も含む) [23年9月28日：インボイス制度に関連する機能のご利用開始時期について](https://blog.crowdworks.jp/archives/5443/) ## このプロジェクトを通して、なかなか得難いと感じた経験（主観） - 他チーム(合計4チーム)を巻き込んだプロジェクト - 経理の方々とのやり取り - POを通じてですが、法務とのやりとり - 10ヶ月以上に渡る長期プロジェクト ## このプロジェクトでぶつかった課題とどのような対応をとったか - 他チームとのコミュニケーション - 上長の助けをもらいながら、できる範囲でコミュニケーションをとっていきました - 期日が近づく中、計画や準備が全然できてなかったこと - 「やらないとねー」ってなってた部分でも、どんどん削っていきました ## このプロジェクトを通して、得た学び・反省 - 「契約」と「帳票」周りについての自社サービスのドメイン知識 - 調査もモブ作業でやることの楽しさと重要性 - 上長に対してだったり、他チームへの期待値調整の重要性 - 助けを求める重要性 - ドキュメントの重要性 - リリース調整の重要性 - マネジメントの重要性 - プロジェクトの締め方の重要性 社会人としては当たり前のこととなることだったり、基礎の部分かもしれませんが、改めてその重要性に痛みを伴って学ぶことができた貴重な経験でした。 ## このプロジェクトを通して、広がった自分の関心ごと 元々色々なところに手を出しては、積読状態を繰り返す自分ですが「要件定義」についてやっと、自分から手を伸ばし始めました。 - 主業務としてやりたいとまではないのですが、実感を持って書籍を読めるようになり、知りたい・学びたいという思いが強くなりました。 - 今まで「要件定義」というものに関してふわっとした興味程度でいましたが、要件を伝達する側になってようやく自分ごとととして捉えられるようになったと感じており、主体的に学ぶ意思が芽生えたことが直近での自分の心の変化としてあります。 - プロジェクト後半にて、受け入れテストの重要さに改めて再認識し、JSTQB等のテスト周りの勉強からV字モデルの上側について関心を持つことができました。（それに対応するのが「要件定義」等だったので、より「要件定義」により関心を持ったという背景があります）

## プロジェクト詳細 「CWアカウントでログイン」という機能を実現している、認証基盤に利用しているソフトウェアのバージョンアップとDBのメジャーバージョンアップ（RDS→Auroraへ切り替え含む） Hydra：v1系→v2系 MySQL：5.7(AWS(RDS))→8系(AWS(RDS))→8系(AWS(Aurora)) ## 担当業務 - 主にSREの方に手伝っていただきながら、2人で進めました - 学習、計画、影響連絡、日程調整、実施 - 学習含め、作業自体はほぼモブでしており、レビューしながらやっていきました ## 実績 - ソフトウェアのメジャーバージョンアップ - DBのメジャーバージョンアップ - RDSからAuroraへの切り替え ## このプロジェクトを通して、なかなか得難いと感じた経験（主観） - ソフトウェアのメジャーバージョンアップ - DBのメジャーバージョンアップ - RDSからAuroraへの切り替え - ドキュメントを一緒に読むという楽しさ 実績全ては貴重な経験だと思っています。 利用されていて動いているプロダクトがある中、いかに冷静さを保ちながら作業をするための前準備の工程が全て貴重だと感じました。 また、馴染みのない技術に関してのドキュメントは文量が多いと疲れてしまったり萎えてしまったりする場合があるのですが、モブで読むことで終始楽しくできたのかなと思っており、なかなか貴重な体験でした。 ## このプロジェクトを通して、得た学び・反省 - 前準備の重要性 - マイナーバージョンで1ずつ上げること - DBのアプデにては失敗時のシミュレーションをこと細やかに「事前」に記述しておくこと - 影響範囲や注意することを考えながらリリースドキュメントをモブでやると、ワイのワイの言いながらできるので楽しいこと ## このプロジェクトを通して、広がった自分の関心ごと このプロジェクトに関わる前から「認証認可」には関心があったのですが、更に強まりました DBについても関心ごととしてより強まった気がします

## プロジェクト詳細 - メンテ中扱いになっていた「PayPal決済」を停止する - 元々デッドコードになっていた部分を削除し、コードを読む際の認知不可を下げる ## 担当業務 - 調査、計画、実施 - 調査のメインは自分1人でしたが、計画と実施はもう1人と自分とPOの3人でやりました（POには外部との連絡をお願いしたり、お知らせブログを記述をしていただきました） ## 実績 - [【重要】PayPal決済の取り扱いを停止いたします。](https://blog.crowdworks.jp/archives/4923/) ## このプロジェクトを通して、なかなか得難いと感じた経験（主観） - 利用事例等から削除 - 剪定する時、ドキュメントからも剪定するということ ## このプロジェクトを通して、得た学び・反省 - 剪定する場合、削除するのはコードだけではないということ ## このプロジェクトを通して、広がった自分の関心ごと - 特にありません

## プロジェクト詳細 返金時に一律銀行口座ではなく、決済元となった機関へ返金 ## 担当業務 - 調査、計画、実施 ## 実績 - お金周りを管理するテーブルのリファクタリング・機能追加（クリティカルな障害無し） - クレカ等の決済機関経由の預り金や支払金の返金手続きの簡略化(出金申請不要) - [テックブログ：決済機関上への返金に対応した話](https://engineer.crowdworks.jp/entry/2022/09/30/150311) ## メインで触った技術 - Rails, Python, SQL ## 実績 ## このプロジェクトを通して、なかなか得難いと感じた経験（主観） - クレジットカード決済の知識（与信等） - DBテーブルのリファクタリング（並行稼働） ## このプロジェクトを通して、得た学び・反省 - DBテーブルのリファクタリングの方法 ## このプロジェクトを通して、広がった自分の関心ごと - 「DBリファクタリングってとても難しそう。」みたいなイメージを持っていたのですが、今回のプロジェクトを通して、「あぁ、大変だけどできそうだな」みたいな心のハードルが下がりました。ハードルが下がったことによってDB関連のリファクタリングについて、より関心を持つことができるようになりました

## プロジェクト詳細 記述できる程のプロジェクトはやっていないです （セキュリティチームの引き継ぎからの運用・保守がメインでした） ## 担当業務 - SREの方々と一緒にEOL管理等をやってました - 他社向けに時々記述するセキュリティチェックシートの回答テンプレみたいなものを用意 - 引き継いだ基盤システムの運用・保守 ## メインで触った技術 - DynamoDB、Rundeck ## 実績 特に有りません ## このプロジェクトならでは、なかなか得難いなと感じた経験 - 諸事情により、チーム所属期間が短期間にはなってしまいましたが、セキュリティ周りについて関心を持つ良い機会となりました - 継続的なEOL管理 ## このプロジェクトから得た学び・反省 - バグバウンティ - セキュリティチェックシートの面倒臭さ ## このプロジェクトから広がった自分の関心ごと - よりWebセキュリティの関心が広がりました

## プロジェクト詳細 元々デスクトップアプリとしてあった、時間単価制のお仕事用に利用する「CWタイムカード」アプリをWebアプリにする ## 担当業務 - RSpecの記述 入社して初めてのプロジェクトということも有り、ドメインのキャッチアップをしつつ、ほとんどのロジックを一緒に居たメンバーが書いたコードを読みながら、テストを記述していました。 プロジェクト途中で、退職者が出たので引き継ぎメンバーとしてチーム移動することが決定し、あまり深く関わることができませんでした。 ## 実績 - [時間単価制の契約にて利用できる「CWタイムカード」が新しくなります](https://blog.crowdworks.jp/archives/4515/) ## このプロジェクトならでは、なかなか得難いなと感じた経験 - プロジェクトを途中で抜けるという経験 ## このプロジェクトから得た学び・反省 - リモートワークが当たり前の仲、中途で入社したばっかりの場合、テキストコミュニケーションスキルはめちゃくちゃ必要だなと感じました ## このプロジェクトから広がった自分の関心ごと - 改めて、自分の明文化能力というかテキストによる伝達力の低さを痛感したので、ライティングスキルについて関心をもちました