ストリームアラインドチームで、マネージャーをしている宇都宮です。
私たちは現在、一緒にプロダクトをつくっていくエンジニアを募集しています！
この記事では、求人票だけではなかなか伝えきれない、私たちのチームがどのようにプロダクトに向き合い、どんなことを大切にしながら開発しているのかを紹介できればと思います。
ストリームアラインドチームについて
まず、ストリームアラインドチームについて簡単に説明させていただきます。
私たちのチームでは、主にmicroCMSの新機能開発・改修・保守の業務に取り組んでいます。
特定の領域だけを担当するのではなく、仕様検討から開発、リリースしてユーザーに価値を届ける一連の流れに対して責任を持つチームです。そのため、エンジニアの仕事も「決められたものを実装して終わり」ではありません。
プロダクトマネージャーやデザイナー、エンジニアなど、それぞれの専門性を持ったメンバーがユーザーにどんな課題があるのか、その課題に対してどんな価値を届けるべきなのかを一緒に考えながら、プロダクトを前に進めています。
採用している背景
現在、私たちはプロダクトをさらに成長させていくために、ストリームアラインドチームの採用を進めています。
もちろん、より多くの開発を進めていくために仲間を増やしたいという側面もありますが、単純に「開発できる人数を増やしたい」というだけではありません。
私たちが目指しているのは、エンジニアが決められた仕様を実装するだけではなく、ユーザーが抱えている課題やプロダクトの状況を理解し、プロダクトマネージャーや他チームのメンバーと一緒に「何をつくるのか」「どうつくるのか」を考えられるチームです。
また、まだチームが小さく、一人ひとりが開発だけでなく、チームのあり方などに大きく影響してくると思っています。チームがまだ小さい今だからこそ、これから仲間になってくれる方とも一緒に開発の進め方やコミュニケーションのあり方など、チームそのものをつくっていきたいと考えています。
どうやってプロダクト開発しているか
microCMSでは、ユーザーの課題や事業上の優先順位をもとに、プロダクトマネージャー、およびデザイナーとストリームアラインドチームのメンバーが協力しながらプロダクト開発を進めています。
大まかな流れは、次のようになります。
- ユーザーの声・事業上の課題をまとめて、優先順位付け
- 仕様検討
- 設計・実装
- QA・受け入れテスト
- リリース
私たちのチームでは、主に仕様検討、設計・実装、QA・受け入れテスト、リリースの工程で関わってきます。
プロダクトマネージャーとエンジニアで仕様を考える
開発するものが決まったら、プロダクトマネージャーが作成した仕様をもとに、担当するエンジニアも一緒になって、具体的な仕様や実現方法を考えていきます。
プロダクトマネージャーは、ユーザーの声や事業上の課題をもとに優先順位を整理し、どのような価値を届けるべきかを考えます。エンジニアは、技術的な知見や既存プロダクトとの整合性、実現可能性といった観点を持ち寄り、仕様を具体化していきます。
書かれている仕様をそのまま実装するのではなく、「本当にこの仕様で課題を解決できるのか」「既存の機能と合わせて考えるとどうあるべきか」「技術的にはどのように実現するのが良いか」といったことを相談しながら、実際につくるものを決めていきます。
また、開発を進める中で新たな問題や考慮すべきことが見つかれば、当初決めた仕様を完成させることだけを優先せず、必要に応じて仕様そのものを見直すこともあります。
microCMSに限った話ではないかと思いますが、プロダクトの成長とともに、考慮しなければならないことも増えていきます。単純に「コードが複雑になる」というだけではなく、たとえば次のような複雑さがあります。
- 機能同士の関係性：新機能が既存機能に与える影響を考える必要が増える
- 後方互換性：すでに利用しているユーザーへの影響を考慮しながら改善する必要がある
- 意思決定：「新しくつくる」だけでなく、「既存の仕組みとどう整合させるか」を考える必要がある
こうした状況で、プロダクトマネージャーだけですべてを決め、それをエンジニアが受け取って実装するという形では、技術的な制約や既存機能への影響を、検討の段階で十分に拾えないことがあります。だからこそ、プロダクトマネージャーとエンジニアがそれぞれの持っている情報や専門性を持ち寄り、一緒により良い答えを探していくことを大切にしています。
設計・実装
基本的には1人1機能を担当し、担当するエンジニアが主体となって設計・実装を進めます。一方で、すべてを一人で判断するのではなく、必要に応じてチームのメンバーと相談しながら進めています。
先ほど触れたようなプロダクトの複雑さもあり、担当している機能だけを見ていると気づきにくい影響や、過去の経緯を知っているメンバーだからこそ気づけることがあります。
そのため、担当者だけで設計・実装を完結させるのではなく、それぞれが持っている知識や経験を持ち寄りながら開発することを重要だと考えています。
その一つの仕組みとして、実装に入る前にDesign Doc（実装方針や技術的意思決定を議論するためのドキュメント）を作成しています。
仕様や既存のコードをもとに、どのような変更が必要になるのかをAIも活用しながら整理し、Design Docにまとめます。主に複数人のマネージャーがレビューを行い、チーム全体が閲覧・コメントできる体制にしているため、担当者以外からの提案も歓迎しています。
実装時のレビューにもAIを活用しています。単にコードをAIにレビューしてもらうだけではなく、これまでチームで培ってきた知識やルールをAIが参照できるコンテキストとして整備し、レビューに活かしています。
人が直接レビューすることで知識や経験を持ち寄ることはもちろん、チームに蓄積されてきた知識をAIからもフィードバックできるようにすることで、担当者だけでは気づきにくい観点を補えるようにしています。
こうしたDesign Docの活用やAIによるレビュー、知識を共有しながら開発する考え方は、ストリームアラインドチームだけに限ったものではありません。開発部全体で取り組んでおり、チームを越えて知識や経験を開発に活かせる環境づくりを進めています。
QA・受け入れテスト
実装が完了したら、QAチームによるテストを行います。また、プロダクトマネージャーとカスタマーサクセスチームの方による受け入れテストも行い、仕様通りに動作しているかだけではなく、意図した価値をユーザーに届けられるものになっているかを確認します。
テストの中で問題や改善すべき点が見つかれば、担当するエンジニアと連携しながら修正し、リリースに向けて品質を高めていきます。
リリースして終わりではない
QA・受け入れテストを終えたら、いよいよユーザーへのリリースです。
もちろん、リリースしたらそこで終わりというわけではありません。
実際にユーザーに使っていただくことで、開発中には気づけなかった改善点が見つかったり、「もっとこうしてほしい」といった声をいただいたりすることもあります。
そうしたユーザーの声は、カスタマーサクセスチームなどを通じて共有されます。届けたものに対するフィードバックを受け取り、それを次の改善や新たな開発につなげていきます。
フルリモートで、一緒につくる
離れた場所で働くからこそ、情報をオープンにすることや、気づいたことを伝えることなど、会社のVALUEを日々の仕事の中でも大切にしています。
必要な情報をドキュメントとして残したり、困っていることや気づいたことを共有したりと、それぞれが自律しながらも、離れていても一緒につくっているという意識を持つことが大切だと考えています。
また、フルリモートという働き方も当たり前にあるものではなく、一人ひとりの行動によって成り立っていると思います。
オープンでいることや、気づいたことを伝えること、相手に対して誠実に振る舞うこと。そうした一人ひとりの行動の積み重ねが、フルリモートでも安心して一緒に働ける環境につながっています。これは開発部に限った話ではなく、会社全体で大切にしているVALUEが日々の仕事の中に表れている部分でもあると感じています。
どんな人と働きたいか
私たちは、仕様を受け取って実装するだけではなく、その背景にあるユーザーの課題や「なぜこれをつくるのか」に興味を持てる方と一緒に働きたいと思っています。
自分の専門領域だけに閉じるのではなく、プロダクトマネージャーやデザイナー、他のエンジニアと意見を交わしながら、より良いプロダクトをつくることを楽しめる方を求めています。
もう一つ、大切にしたいのが、チームやプロダクトに対する貢献欲です。
「自分の担当ではないから」とそこで線を引くのではなく、チームやプロダクトをより良くするために、自分にできることを考えて行動できる姿勢を大切にしたいと思っています。
もちろん、貢献の形は一つではありません。気づいたことを共有したり、困っているメンバーに声をかけたりすることだけでなく、ドキュメントを整備すること、コードや開発環境を改善すること、深い専門知識を活かしてチームを支えることなど、それぞれの強みを活かしたさまざまな貢献があると考えています。
そして、こうした日々の行動を通して、会社のVALUEに共感するだけではなく、一緒にVALUEを培っていける方と働きたいと思っています。
プロダクトだけでなく、チームや働く環境も含めて、より良くしていくことを一緒に楽しめる方に仲間になっていただけたら嬉しいです。
