アプリケーションエンジニアにとって、SQLとデータベース(DB)は切り離せないものだ。
だいたいはアプリケーションエンジニアがDB設計をしてそのシステムのデータ保存の形を決める。
そして、SQLの組み方に関してもそれなりに詳しく知り、ミドルウェアとしてのデータベースアプリケーションにも知見は持っておく必要がある。
ただ、SQLの高速化やデータベースアプリケーションの設定のチューニングなどはかなり専門的なので話が別になってくる。
現場によっては、その分野の専門家がいてDB最適化のためにアプリケーションエンジニアとは別に雇うくらいだ。
Oracleなどは有名な資格がある。
実際の現場では、アプリケーションエンジニアがSQL等を調整することが多く、データベースやSQLの専門的な人員がいないといことも多々ある。
マネージャー側としては、明らかにインフラ寄り以外のものはSQLやDBはアプリケーションエンジニアにとりあえずふってしまう。
その中には、本当に専門的な知識が必要なタスクがある。
現場の人間としてはこの部分の捌き方は非常に難しく、一概にNOとも言えない。
なぜなら、その現場に他にデータベースの専門家がいないのを理解しているからだ。
もちろん、専門家がいればその人に触れば良い。
ラーメンで例えると、チャーシュー麺が良い例だ。
チャーシュー麺のメインはラーメンだ。
チャーシュー麺を提供していたところ、「ラーメンはいらないからチャーシューをもっとくれ」と言われるようなものだ。
それであれば最初からチャーシューだけを山盛りで頼んでくれ、という話になる。
これが、システム構築という見えないジャンルでは理解してもらうことが非常に難しい。
今までの経験上、８割ぐらいのマネージャーがこのあたりの切り分けはできないと感触だ。
多分、説明しても理解してもらえないし、大抵は忙しすぎてそこまでケアは出来ない。
個人的な経験からは、
■アプリケーションエンジニアが対応可能なもの
・DB設計とDDL/DML作成
・明らかに速度が遅いSQLの改善
・SQLの不具合の修正
■データベースエンジニアに任せたいもの
・データベースアプリケーションの設定値等の最適化
・一般的な速度のSQLのさらなる高速化（チューニング）
という切り分けになると感じている。
現在はOpenAIの力を借りてかなり知識を補完できるようになったので良い時代になったと思うが、後者はそのビジネス・システムごとに業務知識として現場最適化する必要があるので、OpenAIには限定的なことしか聞けず本質的には専門家の知見が必要だろう。
この部分はマネージャーや現場のリソース自分のスキルセットとのバランスで変わってくるものの、どの現場でも発生しうる潜在的な問題だ。
よって、自分の中で受け入れるラインとNOと言う部分を持っておくのがベターだ。
出来ないことを受け入れてしまい現場にも自分にもよろしくない結果にならないようにしたい。
入会申込
ログイン
