なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか
コメント
注目のコメント
以前の勤め先はナゼナゼ5回の自動車会社だったから、管理部門でさえ要件定義でイタレーション回してました。
なぜなら一施策の影響力があまりにもデカくて、絶対に的を外せないから。
制度設計でhowを考える前に、徹底的にwhyとwhereとwhoをいろんな方面と議論するので時間は掛かりますが、これによってhowも確度が上がるんで結果的に近道。
転職先では、思いついたことやってみよう！という進め方にかなり戸惑った。モダン。
やらないとわからないですしね。の最後のセリフが、まさにモダンと感じました。私のイメージは仮説→仮説が検証できる方法を見つける→やってみる→次行く の繰り返し。
オールドエコノミーな（←こんな表現あるか分からないですが・・・いわばウォーターフォールなアプローチを迫られる）開発と比べると、モダンはチーム内部に対立を生みにくく、解決するべき本題に向き合いやすいアプローチだなと思います。
オールドでは「え、叶えたいのそこ？？」という場面はしばしばあり、「局所最適化！どこ見てるの！」とかモヤモヤしつつ、そこを立ち回りと実装で抗い、無駄無理なところに力が入ってしまう感じがあります。
一方、要件定義をモダンにするには、自分自身の思考停止を防いで、課題をより上のレイヤーから見る、謙虚になる、自分の考えに間違いがあると疑う、誤認しやすいポイントを知る、自分が優秀じゃないことを知る、など、より自分や他人に向き合う感じがします。
自分がガチガチになってるのなかなか気づかないですからね、謙虚、オープンマインドを心がけます。
私の今の立ち位置で、私のような者がこのまんまモダンな環境にステイするべきなのか揺れてるところです。この記事に書かれていることが間違っているとは思わないですし、こういうやり方もあるだろうとは思いますが、余りにも仕組み化された仕事の仕方にはエモさが足りなくて機械的な印象すら受けてしまう（あくまでエンジニアとしての個人の意見です）。
職能別に仕事を分けることで組織規模をスケール出来ますし、それぞれのプロフェッショナルを集められるというのは間違いないでしょうが、こういう欧米的なやり方が日本でも本当に効果的なのかは一考の余地があるのではないかと思います。個人的には、Problem と Solution で区切られたスペースの中で仕事をすることが楽しいとは思えないんですよね。
日本で流行したアジャイルは実は欧米的なアジャイルとは少し違っていた気がしていて、プロダクトオーナーと開発者がキッチリ分かれるのではなく、「エンジニアがプロダクトオーナーを兼ねる（少なくともその一員になる）」ものだったように思います。言い替えれば「エンジニアも Problem のレイヤーまでしっかり見ていこう」という考え方に、日本のエンジニアは惹かれたんだと思います。実際にこういう考え方を持ったエンジニアは凄く多い。プロフェッショナルとしての専門性を突き詰めたいという人よりも、エンジニアリングという領域を踏み越えて事業貢献したいと考えるエンジニアの方が多いように感じています。こういう国で、この記事にあるような仕組み化された組織づくりが最適解なのかは考えるべきなのではないかなぁと思います。
勿論すべてはバランスですし、この記事を書かれた方はそれぞれのロールに対してしっかりリスペクトを持たれているように感じたのできっと上手くエンジニアの能力も引き出せるのではないかと思います。一方でこういうやり方は容易にお互いのリスペクトを失い、エンジニアの創造性を奪い取りかねません。このやり方を機能させる為にはもう少しマクロレベルの組織づくりがしっかり出来ていることが必要で、メルカリはそれが上手くいっているということなのでしょう。この記事だけ見て真似しても、容易に同じような成果が出るものではないと思います。
