# アート向けCtoCサービスの立ち上げ(メルカリ+レンタルのアート版)
## 概要
- キックオフ直後からの参画で、ソフトウェア開発の全工程を担当しました。
- 諸事情あり、ディレクターの業務を巻き取ってたので、半分PMのような立ち位置でした。
- 品質と開発速度を上げるために、Jest, StoryBook, ESLint, Pretter, huskeyを導入し、GitHubActionsでプルリクごとに回すようにしました。
- アプリケーションの複雑性に対応するためにオニオンアーキテクチャーを採用しました。
- 開発を高速化するためにチームビルディングに積極的に関与しました。
## チームの編成
- クライアント
- クライアント3名
- 自社
- ディレクター (マネージャー) 1名
- リードエンジニア (私) 1名
- フロントエンドエンジニア 1～3名
- バックエンドエンジニア 1～2名
- インフラエンジニア (CTO) 1名
- 技術顧問 (臨時) 1名
- テスター 1名
- デザイナー 1名
## チームの特徴・課題
- クライアントがシステム開発初心者
- ディレクターが新人で要件整理に不慣れ
- メンバーの中に育成要員やオブジェクト指向を理解していない者が多い
#### 使用した技術・バージョン：
フロントエンド：Next.js, TypeScript, Storybook
バックエンド：NestJS, Node.js, TypeScript, オニオンアーキテクチャ
インフラ：AWS (EC2, S3)
データベース：Prisma, MySQL
CI/CD：GitHub Actions
コミュニケーション & プロジェクト管理：Miro, Gather.town, Backlog
#### 担当サービス・プロダクトが属する業界：
アート業界、EC業界
#### サービス固有の技術的特徴：
- 販売だけでなく、レンタル機能がある。
- 発送元は自社倉庫ではなく、作品の所有者（ユーザー）
- 配送処理にユーザーが配送会社のAPIを使用する必要あり
#### チームでの役割：
- クライアント対応
- 要求定義、要件定義、各種設計
- 環境構築
- マネジメント、チームビルディング
- コーディング、コードレビュー
## チームの課題と自身が工夫したこと
#### クライアントの中で要求の整理が不十分に感じたこと
- 課題
- クライアントは初めてのシステム開発、初めての新規事業でした。
- 自分たちのサービスが「誰の」「どんな課題を」「どのように解決し」「どうやって収益を得る」か整理できていませんでした。
- 結果、自分たちも何をやりたいのかわからないままプロジェクトが始まってしまい、いつまで経っても要求がまとまりませんでした。
- 取り組み
- 資料のビジュアル化を徹底しました。
- デザインはワイヤーフレームで確認してもらう
- フローはmiroで確認してもらう
- 結果
- 資料のビジュアル化うまく行った部分は多いものの、やはりクライアントの自分のサービスへの自己理解に時間がかかってしまい、要件が納期直前まで纏まりませんでした。
#### 要件定義完了前に納品日を決めてしまったこと
- 課題
- 要件定義完了前に納品日が社内事情によって決まってしました。
- 取り組み
- 炎上前提のスケジューリング、炎上時のマネジメントをしました。
- 工数を見積るのではなく、納期から逆算して、この時期に何ができていなくてはいけないかを決めていました。
- できていない場合、なぜできていないか、どうやったら改善出来るのか、をヒアリングしました。
[炎上プロジェクト中のPM・リードエンジニアに捧ぐ。炎上時のテクニック集](https://zenn.dev/ampersand/articles/4d5a5605e96c3b)
- 結果
- 取り組みにはうまく行った点も多かったものの、小手先のテクニックではどうにもならず、納期が大幅延長してしまい、クライアントの信用を大きく失ってしまいました。
- 反省
- 最初の意思決定時点で**経営層に直談判すべき**でした。
#### ジュニアメンバーの育成が必要だったこと
- 課題
- ジュニアメンバーを戦力化する必要がありました。
- 取り組み
- 数カ月間、毎日13時〜15時の2時間、ハドルタイムを設けました。
- これは、この時間は必ずハドルする(ミーティングルームに入る)という決まりです。
- その時間はペア・プログラミングをしつつ、その必要がないなら音声を繋ぎながらモクモクと作業します。
- 結果
- ジュニアメンバーのやる気もあり、プロジェクト中盤以降、大戦力として大活躍しました。
[移譲の物差しを活用してエンジニアを育てる](https://zenn.dev/ampersand/articles/1ead4ef4b9d081)
#### リモートチームだったため、チーム内のコミュニケーションが希薄になったこと
- 課題
- チーム内のコミュニケーションが希薄でした。
- 結果、意図が伝わらなかったり、手戻りが起きる、質問がしづらいといった課題がありました。
- 取り組み
- Gather.townの導入
- 毎日2時間のミーティングタイムの導入
- 結果
- Gather.townの導入により、リモート上で雑談が可能になりました。
- 結果、課題だった質問がしづらいなどの課題を解決できました。
[難しく考えない1on1](https://zenn.dev/ampersand/articles/c03d12a64be9a6)
#### 品質を確保する必要があったこと
- 課題
- 複雑なシステムになることは最初から理解していたので、如何にして品質を維持するかが課題でした。
- 私は品質の高さ=開発速度だと思っている人間なので、短納期をカバーするために品質の確保が必要でした。
- 取り組み
- GithubActionsを導入し、プルリクごとにテストが走るようにしました。
- フロントエンドはstorybookでデザインを確認しました。
- バックエンドはjestでのテストを(ほぼ)必須にしました。
- 結果
- 上記が達成できている内は開発速度が高く開発できました。
- 反省
- 一部テストのためのテストを書いてしまったこと。
### 炎上時、テストコードが捨てられて技術負債が一気に積み上がってしまい、却って開発スピードが落ちてしまったこと
- 課題
- 上記で品質を確保していたが、遅延のリカバリ策として、品質は人力でカバーする方針になりました。
- 取り組み
- なし
- 結果
- 技術負債が積み上がり、却って開発スピードが落ちました。
- 反省
- プロジェクトにおいて、雑に書いても良いゾーンと雑に書いてはいけないゾーンを設けてメリハリをつけるべきでした。
- 例
- アトミックデザインを採用しているフロントエンドの場合、
- テンプレート層は雑に書いても良い。
- しかしページ層は雑に書いてはいけない
- ドメイン駆動設計を採用しているバックエンドの場合、
- ユースケース層は雑に書いてもいい。ドメイン知識が漏れ出しても良い。
- しかし、それ以外の層は雑に書いてはいけない。
- このように負債を一部のレイヤーに閉じ込めることで、コードをリファクタ可能圏内に収めることができると思います。
### チーム開発速度を更に向上させる必要があったこと
- 課題
- 納期に間に合わせるためにチームの開発速度を上げる必要がありました。
- メンバーはチケットのみに向き合い、孤独に仕事をしていました。
- 取り組み
- 毎日午前中に最短5分程度の1on1を実施し、「今日の調子どう？」「困っていることありますか？」と問いかけました。
- 結果
- メンバーが悩んでいることや困っていることをその場で解決できるようになり、チーム開発速度が向上しました。
- メンバーが感じている不吉な予感を早期に探知できるようになりました。
[難しく考えない1on1](https://zenn.dev/ampersand/articles/c03d12a64be9a6)