はじめに
このエントリは、初挑戦カレンダー Advent Calendar 2025 の 4日目記事です。
https://qiita.com/advent-calendar/2025/silvia
今年、Twitterで何か主張したかったことを拾いながら記事を書いていきます。
本文
Javaの現場でライブラリを利用する時に、よく出て来るアノテーション。
C#ではアトリビュート。
これらは非常に便利な機能で、バリデーションチェックや、コアライブラリで開発の簡略化を行うなど、開発ではなくてはならないものとなっている。
しかしこのアノテーションを 「使う」 ことは簡単なのだが 「作る」 のはかなりの技術知識が要求される。
リフレクションを使って、各クラスのフィールドやメソッドなどをチェックし、アノテーションが付いているかどうかを確認し、その付いているアノテーションの状態を確認して処理を行うなどする。
更には、そのアノテーションが付いているクラスを使った共通部分などではインターフェースによる型強制、他にはマーカーインターフェースが実装されていたら何らかの特殊な処理を行うなど、本当に様々な知識が要求される。
これらの知識は、プログラミングオタクである我々は興味本位で調べたり、試しに使ってみたりすることで、長い経験を積むことにより会得したものだ。
しかし、ライブラリ利用開発が基本となっている現場において、アノテーションが一体どのようにして機能を実現しているのかという知識は、経験が浅い若いメンバーにとっては 「知らなくてもよい」 ことであるため、技術知識として継承する場がない。
基盤チームなどで、新しく配属されたメンバーに、アプリ構成を覚えてもらうために説明…といった状況はあるかもしれないが、そんなチームに新人を入れて育てるというのはあまりなく、知識のあるメンバーで固めて盤石化する方が多いだろう。
そうなると本当にもうこの手の知識を継承する場がない。
プログラミングオタクが自分で勉強するしかない。
勉強会などを開いたとしても、前提知識が多すぎるため、いろいろなものをほぼ一から教える必要がある。
アスペクト指向プログラミングなど、1時間では概念の説明くらいしかできないだろう。
開発現場が、この手の知識を必要としないようになってきており、更にはAIによる強力な開発サポートが得られるようになってきている現在において、誰でも、あるいはAIでもある程度できるような事しかできないようではただの人員として数えられるだけになってしまい、開発者として生き残るのが難しいのではないかと危惧している。
後輩にこの手の技術を継承できれば、かなり現場で重宝される人員となれるため、会社として強くなれるとは思っているものの、流石に難しい。
現場においてはそんな難しい話を長々と教えている暇はないし、勉強会は何度も開催する必要があり、開催者、参加者共に負担が大きい。
目標としては、アノテーションがどのようにして内部処理に組み込まれているのかというプログラム構成を、ある程度認識できるようになり、不具合が起きた時に解決できる能力を技術知識として後輩に継承したい。
個人レベルではかなり難しい話であるので、会社全体としての取り組みが必要なのかなあと、そこまで考えたところで、この話は独り言としてTLを流れて行った。