実践レベルになるための要件

1. フレームワーク・ライブラリの思想や構造を理解している。
2. フレームワーク・ライブラリの思想に基づいて詳細設計ができる。(*1)
3. 言語・コーディングルールに基づいてコーディングができる。
4. システム仕様・フレームワーク・言語に対する理解を元にレビューし、明確な根拠で指摘ができる。
5. フレームワーク側の不備を解析できる。
6. テスト手法を確立している。

*1 「頭の中で組み立てる」で十分。ドキュメントは本質ではない。
ここも本質を考えずに「書」に拘っているのがいたけど、時代錯誤。
マシン語でダイレクトに組んでいた時代なら理解できる。
アドレスを1バイトでも間違えたら飛ぶからね。

*2 要するに好みをぶつけるような薄っぺらいレビューはしないってこと。

何となくものを作るだけなら、まったくの未経験でも1-2週間程度で良い。メジャーなフレームワークならばググればヒントは見つかる。
今ならCopilot for Microsoft 365で秘匿も扱える。ここに金をかけたくないような連中は、勝手に非効率 or 情報漏洩させればいい。
それでも、英語サイトを見たくない人は熟れたもの以外触らない方がいい。

1ヶ月のOJT後でも、実践にはほど遠く理解できないような人もいる…というか大半が理解しきれていない。

フレームワーク・ライブラリのデメリット

大前提。

1. 人はミスを犯す。
2. ソフトウェアは人が作っている。
3. 人が作ったソフトウェアにはミスがある。

無理に使わなくても良い代物。
実装コストを天秤にかけながら検討に加えて良いけど、強迫観念で「フレームワーク・ライブラリを使わなければならない」は論外。元が駄目だと、それに足を引っ張られる結果にもなることは考えておかないと駄目。

大きいフレームワークだとStrutsが良い例。
2017年の記事だけど。

Apache Struts 2の脆弱性で日本郵便のサイトにも不正アクセス、国際郵便用サービスの登録メールアドレス2万9116件、送り状1104件が流出
https://internet.watch.impress.co.jp/docs/news/1049600.html

フレームワークの便利な面だけ見て、リスクを考えていなかった事例。システムを請け負ったSIerはどこだろう？
いい加減Strutsなんて使っているところはないと思うけど、Springだって100%OKな訳ではないと思う。

ライブラリはLog4jとか。
CIでLog4jを個別にチェックしているのもある模様。

便利なものは利用していく一方で、リスクは考えておく。
それがフレームワークやライブラリとの付き合い方。
マイクロサービスアーキテクチャみたいな考え方でいけば、安全な設計に近づくと思うけどね。

手段と目的がごちゃ混ぜになっている人が多い日本のIT業界。
だから、いつまでも外国を超えられない。