アート向けCtoCサービスの新規立ち上げで苦労したこと・課題・失敗したこと・工夫したこと
アート向けCtoCサービスの新規立ち上げで苦労したこと・課題・失敗したこと・工夫したこと
概要
- 2022年2月から株式会社アイディオットに入社し、アート向けCtoCプラットフォームの開発にリードエンジニアとして参画しました。
- キックオフ直後から参画したため、アーキテクチャの選定、要件定義、設計、環境構築、コーディング、テストのすべてを担当しました。
- アーキテクチャはプロジェクト当初から複雑なアプリケーションになることはわかっていたので、ドメイン駆動設計を採用しました。
- 品質を高く保つために、環境構築時点でGithubActionsを利用したテスト自動化環境を整えました。
- プロジェクトに参画したジュニアエンジニアの育成やオフショア担当者とのやりとりをしていました。
- ディレクターに代わりディレクションやスケジュールの調整、要件の調整もしていた時期があり、半分PMのような立ち位置のリードエンジニアとして活動してきました。
使用技術
- フロントエンド：React/Next.js/TypeScript/Stroybook
- バックエンド：Node.js/NestJS/Typescript/Prisma/DDD(オニオン)/RestAPI
- インフラ：AWS,Github
- その他：miro
時期
- 2022/2 〜 2023/2
チーム
- クライアント
- 代表者(1人)
- 代表者上司(1人)
- 情報子会社のSE(2人)
- 自社
- ディレクター(1人)
- リードエンジニア(私)
- フロントエンドエンジニア(1〜3人)
- ※うち1名はオフショア
- バックエンドエンジニア(1〜2人)
- インフラエンジニア(CTO)
- 技術顧問(1人)(短納期のためのピンチヒッター)
自分の役割
- リードエンジニア
- 設計
- アーキテクチャーの選定
- 要件定義
- すべての設計
- 環境構築
- CI環境の構築
- 開発環境の構築
- コーディング・レビュー
- マネジメント
- ジュニアエンジニアの育成
- オフショアとの連携
- ディレクターのサポート
- クライアントとの折衝
課題と取り組み
クライアントが要求をまとめられないこと
- 課題
- クライアントは初めてのシステム開発、初めての新規事業でした。
- 自分たちのサービスが「誰の」「どんな課題を」「どのように解決し」「どうやって収益を得る」か整理できていませんでした。
- 結果、自分たちも何をやりたいのかわからないままプロジェクトが始まってしまい、いつまで経っても要求がまとまりませんでした。
- 取り組み
- エンドユーザーから見たとき、どんなサービスになるかを意識し、とにかくワイヤーフレームおよびデザインを見せて、デザインベースで会話を進めました。
- 結果
- このやり方は部分的には成功しました。
- しかし、どうしてもクライアントの自分のサービスへの自己理解に時間がかかってしまい、要件が概ねまとまったのが納期直前でした。
- その結果、大炎上しました。（納品が4ヶ月伸びた）
ディレクターが要件と仕様を定義できないこと
- 課題
- 上記の要求がまとめられないのに合わせ、ディレクターもシステム開発が初めてでした。
- 決まった要求に対して、整合性の取れた要件が定義できませんでした。(中途半端かつ雑なことになってしまいました)
- 取り組み
- ディレクターのタスクを一旦私がすべて巻取り、要件を整理しました。
- その上で、小さいチケットに分けてディレクターが処理出来るようにしました。
- 結果
- タスクを巻取り過ぎて自分がプロジェクトのボトルネックになってしまい、プロジェクトの遅延原因の1つになってしまいました。
- 一人でディレクター、各種レビュー、プレイヤー、育成をやるのは無理です。大声で助けを求めるべきでした。
要件定義完了前に納品日が決まってしまったこと
- 課題
- 要件定義完了前に納品日が社内事情によって決まってしました。
- 取り組み
- 炎上前提のスケジューリング、炎上時のマネジメントをしました。
- 工数を見積るのではなく、納期から逆算して、この時期に何ができていなくてはいけないかを決めていました。
- できていない場合、なぜできていないか、どうやったら改善出来るのか、をヒアリングしました。
- 結果
- 部分的にうまくいってしまったことが却って良くない結果を産みました。
- あとあと大きく遅延したのでクライアントの信用を大きく失ってしまいました。
- 反省
- 最初の意思決定時点で経営層に直談判すべきでした。
- クライアントに対して、あとから「大きく遅れています」と言うより、最初から「大きく遅れています」と言っていたほうが結果的に失う信頼が小さく済んでいました。
ジュニアエンジニアを育成する必要があったこと
- 課題
- 経験1年程度のジュニアエンジニアを戦力化する必要がありました。
- 取り組み
- 毎日13時〜15時の2時間、ハドルタイムを設けました。
- これは、この時間は必ずハドル(ミーティングルームに入る)するという決まりを作り、必要ならその時間ずっとペア・プログラミングをしていました。
- 必要ないなら黙々と作業していました。
- その他様々な取り組みをしました。
- タスクを一旦TODOリストに書き出してもらって、レビューする
- テストコードだけ先に書いてもらって、レビューする
- タスクの粒度を下げる
- コードの雛形をtodoコメントベースで実装してレビューする
- 結果
- とてもうまくいきました。
- 本人が意欲高く、努力出来るエンジニアであることもあり、やがては本人がプロジェクトを主体的に進めていけるぐらいに成長しました。
- 反省
- なし
品質確保
- 課題
- 複雑なシステムになることは最初から理解していたので、如何にして品質を維持するかが課題でした。
- 私は品質の高さ=開発速度だと思っている人間なので、短納期をカバーするために品質の確保が必要でした。
- 取り組み
- GithubActionsを導入し、プルリクごとにテストが走るようにしました。
- フロントエンドはstorybookでデザインを確認しました。
- バックエンドはjestでのテストを(ほぼ)必須にしました。
- 結果
- 上記が達成できている内は開発速度が高く開発できました。
- 反省
- 一部テストのためのテストを書いてしまったこと。
炎上時、テストコードが捨てられて技術負債が一気に積み上がってしまい、却って開発スピードが落ちてしまったこと
- 課題
- 上記で品質を確保していたが、遅延のリカバリ策として、品質は人力でカバーする方針になりました。
- 取り組み
- なし
- 結果
- 技術負債が積み上がり、却って開発スピードが落ちました。
- 反省
- プロジェクトにおいて、雑に書いても良いゾーンと雑に書いてはいけないゾーンを設けてメリハリをつけるべきでした。
- 例
- アトミックデザインを採用しているフロントエンドの場合、
- テンプレート層は雑に書いても良い。
- しかしページ層は雑に書いてはいけない
- ドメイン駆動設計を採用しているバックエンドの場合、
- ユースケース層は雑に書いてもいい。ドメイン知識が漏れ出しても良い。
- しかし、それ以外の層は雑に書いてはいけない。
- このように負債を一部のレイヤーに閉じ込めることで、コードをリファクタ可能圏内に収めることができると思います。
リモートチームだったため、チーム内のコミュニケーションが希薄になったこと
- 課題
- チーム内のコミュニケーションが希薄であり、意図が伝わらなかったり、手戻りが起きる、特に質問がしづらいといった課題がありました。
- 取り組み
- Gather.townの導入
- 毎日2時間のミーティングタイムの導入
- 結果
- Gather.townの導入により、Slackではやりにくいちょっとした会話などもしやすくなった。
- 結果、課題だった質問がしづらいなどの課題を解決できました。
ビジュアルドキュメントが作りづらいため、あまりドキュメントが作られないこと
- 課題
- テキストドキュメントというよりは、フロー図、イメージ図、ドメインモデル図、ガントチャートなどのビジュアルドキュメントが作りづらい環境にあった。
- 取り組み
- miroを導入した
- 結果
- ビジュアルドキュメントが手軽に作れるようになったため、
- クライアントとのコミュニケーションが円滑になった
- メモ程度でも簡単に作れるため、どんどんドキュメントが溜まっていくようになった
- 社内で評判になり、会社としてmiroを導入するに至った
反省
もっと人に頼るべきだった
- 助けてくれない前提で仕事をしていましたが、案外炎上すれば皆助けてくれたので、もっと早い段階でヘルプを上げるべきでした。
和製APIの場合は工数の見積もりを多めにとるべきだった
- ヤマト運輸の配送連携APIを使用しました。
- とても扱いづらく、想定を遥かに超える時間をかけてしまいました。