製品を作りながら、製品を作るための仕組みやチームも育てる 
 共同開発も含めた自社製品や、ちょっとした受託の開発の両方をやっています。担当範囲はかなり広く、新機能の追加から障害のサポートまで行うのはもちろん、ユーザーの満足度や売上を伸ばすための検討から、開発ロードマップの検討まで関わっています。BtoBなのでエンドユーザーと直接のやりとりは少ないですが、色々な部署の人と窓口としてやりとりもします。
その内容から、複数人のチームで同じ製品を長い間バージョンアップすることが多くなってきます。なので、チーム全体が楽になるような改善や仕組み作りを重視しています。例えば、リリース作業の負荷が一人に集中してキツかったなら、次は自動化して誰でもできるようにするなど。地味ですが、確実に次の仕事を楽にするのでやりがいがあります。最近の用語を使うとDevOpsですかね 。  

自分の得意分野を生かして成果に繋げられる 
ユーザーの要望を直接聞いて、実現方法の提案から実現まで関われることです。「こういう事をやりたいのだが、現実的に実現出来る案は？」に対して提案を出す。作り方の提案はもちろん、機能を作らないで実現するという提案もあり得ます。「言われた通りの仕様で作ります」よりも大変ですが、やりがいは大きいです。
今の製品では、ある操作がセキュリティホールだからと禁止されていて、とても不便だから何とかしたい、という相談がありました。今ある製品の機能と、Windowsの知識を組み合わせて、「その操作自体は可能だが、別の後処理をすることで、実質的にセキュリティホールにならないようにする」という提案をして開発・リリースしました。相談元からもユーザーからも好評だったようで、やった甲斐があったと思います。   

何か工夫をして成果を上げたら素直に評価される 
一番大きいのは、実践的なプログラミングの仕事が多く、技術力が付くと思ったことです。特定の分野で高く評価される技術を持っている会社であるため、一部だけの単純作業ではなく、ソフトウェア全体の開発に関われそうだと感じました。また雰囲気として、何か工夫をして成果を上げたら素直に評価されそうで、前例主義とは無縁の印象を感じました。実際に入社してみてもこういった点は印象の通りで、好きなところです。 

小規模案件を一人でこなす事から始まり、続けてパッケージ製品の継続的な保守・リファクタリングや大規模バージョンアップなどを担当し、過程で数人のチームを持ったり採用に関わったりと広い経験をしています。