日本コントロールシステム(株)

新人研修後に配属してからの大半は製薬会社向けの業務支援アプリの開発に携わっています。
配属直後は検査要員として検査を通してアプリの仕様の理解を深め、配属2, 3ヶ月後くらいから徐々に製造に関わるようになり、現在では主に製造（と検査）を担当しています。

業務知識に関しては、わからないことがあるたびに知識豊富な上司に質問したり、非常に難解でまどろっこしい厚生労働省の文書を確認したりと未だに不足していますが、わからないことがあったときに「どこ見ればいいか/誰に聞けばいいか」さえわかってしまえば何とかなると割り切っています。

プログラミングの知識に関しては、基本的には既存のソースコードを参考にしたりググったりするのが主で、本当にモチベーションが高いときに限って自分で参考書を買って読んでみたりしていました。

「プロジェクトが成功した時」「自分が関わったアプリが顧客に褒められた時」

...といったようなことではなく、「バグの原因を突き止めた時」です。

バグ調査というものは、与えられた情報から可能性を1つずつ潰していって原因特定に至るのですが、その過程で過去に蓄えた知識・記憶を総動員する感じがまるでクイズやゲームのようで個人的にはとても楽しいです（特に少ない情報から短い時間で原因特定できたときは最高の気分になります）。

「それがやりがい？」と思うかもしれませんが、やりがいというものは自分のモチベーションを維持するためのものなので、それが「楽しさ」のような一見仕事には似つかわしくない不真面目に思えるものだとしても、結果に繋がるのならばそれはそれでいいのではないかと個人的には思っております（変に堅苦しく考える必要はないのでは？と）。

・適度に手を抜く
常に全力だと身が持ちませんし、周りの人から全力の状態を平常運転だと見做されてしまい、身の丈に合わない仕事を振られてしまう可能性が生じてしまいます。

・できることをやる
自分ができない（と思っている）ことをやるのは精神的に苦痛で成果も上がらないという誰も得しない状況を生み出すように思われます。そのため、自分ができない（可能性が高い）ことははっきりと断るようにしています。「それだとできることが何もない状況になりうるのでは？」と思うかもしれませんが、その時は雑用でもなんでも甘んじて受け入れるしかないと考えています。

・自分の役割を考える
チームの中でどのようにふるまえば最も効率よくチームに還元できるかということは、しばしば考えます。
製造・文書・顧客窓口担当といった業務的な役割だけでなく、「ミーティングであまり意見が飛び交わないチームなら意識的に先陣を切って意見を出すようにする」「個々のパフォーマンスは高いがちょくちょくミスをする人が多いチームなら自分自身が他の人のミスを検知することに注力する」といった個人的な役割も含みます。