一緒に働くエンジニアの平均値 and/or 中央値が高い。技術スタックしかり、テストの自動化みたいなところしかり、随分とイマドキな感じになったなーと思っている。SIer 時代はどうしても、ビジネスの構造上、できるだけ少ない社員でたくさんのBPを引き連れて売り上げをあげる、という方向に行きがちだった（少なくとも自分がいたところは）。結果として玉石混交になりがちで、イケてるエンジニアと技術的にイケてる話をする、というよりは石の方のケツ拭きをしてる印象があった。それがなく、少なくとも開発に携わっているメンバーはちゃんとコードを読める前提で動けるのはとても快適
熱がある。秤の金ちゃんじゃないけど、ちゃんとプロダクトに興味があり、（程度の差はあるかもだけど）本当によくしていこう、という気持ちがあるのは大きいなーと思っている。SIer 時代ももちろんある程度は思っている話だけど、そもそも顧客側にも本気で「作りたい！」という気持ちでいる人があまりいなかったりするので、深いところで他人事みたいなところがあったなーと思っている（本当はおかしい気はするけどここから先は先方のスコープだから、的なね）
組織のしがらみ/所掌範囲のゴチャゴチャが少ない。良くも悪くも各組織の所掌範囲がそこまで固まっていないこともあり、クラウドを使うのに上司の上司の上司に話を通して・・・みたいなのは無くなった。まぁこれは順調にデカくなっていくと色々バランス取るのが難しいところなんだろな、とは思う

大変なところ・昔も良かったところ

品質管理。よくバグ密度で品質を測っていることに対して批判されるけど、それはSIerが行なっている品質管理のごく一面であって、今の所に来ると色々と改善の余地があるなーと思うところはある。基本的に極力自動化する、みたいなHowの部分は進んでいるんだけど、そもそも何を検証すべきか、みたいな部分がふわっとしていることがある。開発のスピードとのトレードオフで意識的に取捨選択してる部分は良いけど、正解が分からず、みたいなところもなくはないかも
人数。GAFAみたいなところはまた別だろうけど、万年人手不足、みたいなところはある。兎角批判されがちな多重請負の仕組みだけど（そして批判は尤もだけど）、やりたいこと・期間を元に必要な人手を集めてきて作りきる、というのは実はやっぱり結構すごいことなんだな、と改めて思っている。まぁSIer 時代の最後の方はこちらもリソース不足で何でもかんでも受ける、とはいかない状況だったけども…今のような基本自分のプロダクトを内製している会社にいると、開発者の人数がビジネスの律速になるケースがあって、大丈夫か？という気持ちになることはある
将来性というかキャリアパス。SIer 時代は、良くも悪くも定年退職までのいくつかの道筋が見えているところがあって、路頭に迷うことはないな、という安心感はあった。幸い今いるところはすぐには潰れそうにはないけど、でも突然部門が無くなったり、AWSが急に自分のところこのプロダクトを食うようなサービスを発表する、という可能性はなくはない。選ばなければ転職はできる気はするけど、あと三十年とかをどうサバイブするのか、という漠然とした不安はある