ターゲットは、マルチプロダクト戦略をとっている企業をイメージしています。
プロダクトは複数あるが、データとしては繋がっているような、論理的な境界線を持ったプロダクトのイメージ(コンパウンドスタートアップと言われるような形態)
複数のプロダクトを同時に開発している場合、大体プロダクトごとにチームが分かれていることが多いと思います(Microserviceを意識するなら、よりチームの切れ目がプロダクトの切れ目となってることが多い)。
この場合、あるチームで起きた問題が別のチームでも起きてることはよくあります。 このようなサイロ化(組織や情報が孤立し、共有できていない状態)した問題は、チームの中では気付かないことがあります。
アプローチとしては、Team TopologiesのEnabling Teamのような形で専門的な人がチームに入って一緒に課題を解決しながら、課題の解決方法を学べるような状態にしていく方法があると考えています。 この時に解決した課題を、他のチームにうまく共有することで他のチームでも同じ問題が起きにくくなったり、問題自体が減らせたりします。
自分の場合は、もともと一定期間特定のチームに入って開発をしながら、横展開をするような横断的なチームにもいるという形が多かったので、このようなアプローチには慣れている部分があります。また、チームに閉じずに色々なチームのレビューに勝手に参加することも多く、そうすると同じ問題が複数のチームにあることにも気付けます。
そういった複数の場所で起きてる問題は、何かしらの仕組み化をした方がいいので、その仕組みづくりをすることもできると思います。
このアプローチは、ボトムアップで問題を見つけて解決していくので多少時間がかかる気はしていますが、セキュリティやパフォーマンスなど非機能要件でも通じやすいアプローチだと考えています。
個人的に100倍早く開発したいという想いはありますが、それと同時に全員が10倍生産性が上がればもっとよくなると考えているので、両方ともやるのが良いと思っています。
さまざまなタイプの課題が出てくるので、それに対してアプローチできること。 同じような課題であっても、チームなどのコンテキストが異なれば、実は違う課題の場合もあります。そのような課題の多様性を認識して、アプローチできること。
また、各自が裁量を持って動ける状態かどうか。色々を課題を見て、解き方を考えて解くのが好きなので、ある程度各自がちゃんと動ける状態にならないと課題が減らない気はしています。
期待する報酬は、希望する年収 に書かれているもの。