ID:22001さん

# 一言で要約 要件定義・見積もりから設計、ユーザーインタビュー、タスクの整理と実装まで何でもやる0→1開発 タイムラインは以下の通りです。 - 2019/11: 開発開始 - 2020/1: フルリモートに移行 - 5月末にリリース。業務委託のサーバーサイドエンジニアが参加 - # 担当業務 インフラは強くないですが、フロントエンドとバックエンドのどちらもやっています。 - 課金サーバーの設計・実装（ - [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)とMartin Fowlerの[PresentationDomainDataLayering](https://martinfowler.com/bliki/PresentationDomainDataLayering.html)を参考にレイヤードアーキテクチャを採用 - TDDで開発。CIでテストを実行。 - Stripeを利用 - React + Next.js + TypeScript によるSPAの設計・実装 - [経年劣化に耐える ReactComponent の書き方](https://qiita.com/Takepepe/items/41e3e7a2f612d7eb094a)を参考にし、Presentation / Container Componentに分けた書き方をしています。 - CSSはCSSモジュールの形式で、コンポーネントと1対1になるように設計しています。HTML、CSSのコーディングはデザイナーさんが担当しています - Atomic Designは採用していませんが、Storybookは導入しました - Jestでロジックのテストを記述している。E2Eテストは未導入 - AWSの運用（ECS（Fargate）、S3、SSM、EFS） - Datadogを使ったサーバー監視 - GitLabのCIを利用して、テストの実行、コンテナイメージのビルド、ECSのタスク作成・デプロイをしています。 # 習得スキル ## エンジニアリング - Cleanな設計とCleanなコードで[質とスピード](https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition)を両立すること - テストを記述し、デプロイ時のバグ混入率を下げてデプロイから不安を取り除くこと - 「自分たちが考えたすごい機能をリリースする」というプロダクトアウトではなく、「ユーザーが欲しい機能から実装する」というリーン・スタートアップのマーケットインという考え方と実践 - 6月から業務委託の方がチームに参加して以降、一貫してペアプログラミングを行なっています。 ## ドメイン知識 - ユーザーインタビューのノウハウと課題の抽出 - ユーザーの業界の特殊性 ## ビジネス知識 - サブスクリプションサービスの収益構造、値段設定 - サービスの価格設定や損益分岐点、チャーンレートなどのビジネス知識 # チーム開発 - チームメンバーは、プロダクトオーナー1人、デザイナー1人、エンジニア（自分）、そして業務委託のサーバーサイドエンジニア1人の4人です。 - 「お隣さん」には、本部長、テックリード、インフラ担当のエンジニアがいて、密に連携を取っています。 ## プロダクトのリリース前 - OOUIの考え方をデザイナーさんに紹介し、画面デザインやユーザー行動について話し合って画面をシンプルにしたり、プロダクトオーナーとサブスクリプションというビジネスの成功の鍵について話し合い、価格設定からユーザビリティまでエンジニアの枠にとらわれず、幅広くアイデアを出し、プロジェクトを前進させています。 ## プロダクトのリリース後 - 現在は、2週間ごとのイテレーションでJIRAを使ったチケット駆動で開発をしています。また、私はイテレーションごとのミーティングのファシリテーションをやっています。 - タスクについては、簡単にできるものではなく、時間がかかってもプロダクトとビジネスの成長にとって重要なものから取り掛かるよう、プロダクトオーナーにアドバイスしています。ここで言う重要とは、売上増加やユーザー数増に直結するということです。チームが赤字や利益額が少なくては、プロジェクトに人員を増やすこともできず、さらにプロジェクト自体が存続できなくなるからです。 - 振り返りの際は、KPTではなく、代わりに「完成したタスクをもう一度初めからやり直すなら、改善点はどこかあるか」と必ず聞くようにしています。これは[「フロイドの解き直し」](https://readingmonkey.blog.fc2.com/blog-entry-495.html)という手法です。ここにプロセス自動化やより良い意思決定のためのタネを見出します。 # チームでの業務の進め方 - チームの中では意思決定をする役割を担っています。プロダクトオーナーが他事業と掛け持ちであるため、リリース後に次に開発するべき機能やデータの精査など、次の一手を打つ準備がなかなかできないと言う状況を早めに察知しました。このため、POの代わりにエンジニア兼ディレクターのような働きをしています。 - **データ・ドリブン** : このため、POの代わりにデータを分析して解約率が一般的なプロダクトより高いことをチーム内に共有して、「新規登録者を増やすより、まず解約者を減らす施策を打ちましょう」と提案して改善施策を実装する方向に持って行きました。 - **タスクの優先順位付け** : また、チーム外からの提案が多くなってきたタイミングで、「プロダクトのロードマップを作りましょう」とチームに呼びかけてプロダクトの方向性に対する認識を合わせて、チーム外の思いつきにメンバーが振り回されないようにしました。 # 発信 本プロジェクトで経験したことを個人の技術ブログにまとめています。 ## フロントエンド - [Next.js + TypeScriptにStorybookを導入して遭遇したエラーを全て共有します](https://panda-program.com/posts/nextjs-storybook-typescript-errors) - [Next.jsでGoogle Analyticsを使えるようにする](https://panda-program.com/posts/nextjs-google-analytics) - [Reactコンポーネントの雛形生成のシェルスクリプトを書いた ](https://panda-program.com/posts/automate-creating-react-component-with-shell-scripts) ## 業務効率化 - [GASをclasp（CLIツール）+ TypeScriptでローカルで開発する](https://panda-program.com/posts/clasp-typescript) - [GASで議事録のテンプレ作成と周知を自動化する](https://panda-program.com/posts/copy-google-document-weekly) - [Stripeの全てのSubscriptionsのstatus（active, trialing）を集計する方法を紹介します](https://panda-program.com/posts/collect-stripe-subscriptions-by-gas) ## テスト - [テスト駆動開発（TDD）とは何か。コードで実践方法を解説します](https://panda-program.com/posts/test-driven-development) # その他 OSS活動: [Next.jsのドキュメントを日本語に翻訳するプロジェクト](https://github.com/Nextjs-ja-translation/Nextjs-ja-translation-docs)にコントリビュートしました。