0
4
DBを専門とするエンジニアのキャリアと評価について
DBエンジニアの評価はどのように行われているのかをお聞きしたいです。
所属している組織の技術レベル・評価体制・規模にもよると思いますが
DB側のリファクタリングやインフラ改善は
・ユーザやエンジニアではない方からは目に見えてわかりづらいこと
・パフォーマンスチューニングや保守性の高い設計などはある程度の規模に達しないと効果を発揮しないこと
という特徴があると考えていて
特に受託開発企業に関しては
・マネージドDBも普及してきており、作成するだけである程度どうにかなってしまう
・非機能要件に対してクライアントが必要性を感じておらず、納期や依頼金額に含まれない
ようなケースが私の周りだけかも知れませんが起きていて
中小企業規模の受託開発であればDBエンジニアの活躍ポイントがあまりないのかなと思ってしまいました。
ましてやアンチパターンでの設計をしてしまっている方のほうが、その修正のためにさらに開発費をもらっているようなケースもあり複雑な気持ちです。
あくまで私の観測範囲ではありますが、このような状況下で
DBエンジニアの方が評価を得て、キャリアを積んでいく（給料を上げていく？）ためには
・自分よりもDBの知識がある評価者のもとで働く
・自社開発企業で自社サービスの改善をすることでアピールする
等が必要なのかなと考えていますが、世の中のDBエンジニアの方は実際どうなのでしょうか？
回答いただけたら嬉しいです。
背景、状況
現在DB周辺の知識に興味があり、主に
・パフォーマンスチューニングによって目に見えて速度改善が見えること
・テーブル設計を工夫することで今後のシステム開発の保守性や柔軟性が高まること
・DBの知識は比較的移り変わりがWeb開発に比べると早くなく汎用性が高いこと
などに魅力を感じています。
まだDBエンジニアの大変な部分を知ることができていませんが
上記の理由からキャリアの選択肢の1つとして興味があり、現役の方から回答をいただけたらと思い質問しました！
回答3件
#1
総合スコア85945
投稿2024/02/18 14:33
DB専門のエンジニアでは無いのですが、意見が付かないので書いてみます。あくまで私の周りの経験ベースの意見ですが。
どういった業務イメージなのでしょうか？
「DBが得意なインフラエンジニア」「DB設計が得意なアプリケーション設計者」は色々な規模のIT企業に居るかと思います。で、担当外のシステムで、DBで何か問題が起こると一時応援の声が掛かったり、「これはちょっとDB設計ちゃんとやらないと性能が出ないぞ」という新規プロジェクトの立ち上げメンバーに呼ばれたりとかはありそうです。そういうイメージであれば、やっていけると思います。
「DBMS以外のインフラはあまりやりたくない」とか、「DBMSやSQLには興味があるが業務システム設計はちょっと」とかだと、職務として成り立ちにくいのではないかと思います。
あるいは、オープンソースDBMSのコアなコミッターであるとかであれば、また別の活躍イメージもあり得るかも知れませんが。
・マネージドDBも普及してきており、作成するだけである程度どうにかなってしまう
構築運用面では、中途半端なDB構築運用エンジニアは要らないかも知れませんね。普通にクラウドサービスの管理画面操作でDB構築・運用しているレベルと、マネージドDBの中味まで設計できるレベルのスキルで中味も想像しながら使いこなすレベルとに分化するのでは？
一方、テーブル設計やSQL設計で性能をだすというのは、クラウドになっても必要な技術ですし、RDBが使われる分野ではずっと必要な技術かと思います。
ただ、メインフレームや巨大UnixサーバーでDBMSが動いていた時代は、CPUやメモリー、HDDなどのネックで性能が出ない時に、おいそれとリソース増強できないので、アプリ側で頑張るしかなかったわけですが、今だと「日中は性能に問題が無いが、夜間に洗い替えなど重いバッチ処理があり、4時間掛かるのを2時間に出来ないか」とかであれば、2時間だけCPUとメモリを増やすともしかすると終わるかも知れません（終わらないかも知れませんが）。
仮に日中性能にも問題があり、24x365のリソース増強が必要なレベルだったとしても、そのコストと、アプリでやるチューニングとの、コスト・期間比較で考えることになるかと思います。
特に期間。あれこれ考えている間に、ダメ元で試しにリソース増やしてみて、解決すればそのままで、解決しなければ戻して、アプリ設計を考え直すと言うことになりそうな気がします。
ということで、これも、多くのシステムでは活躍の場は狭まっていくのかも知れません。
もちろん、いくらリソースをつぎ込んでも安易なDB/SQL設計では駄目なケースもあるでしょう。（思いつきなので合ってるかどうか分かりませんが）
・ミリ秒以下レベルが問題になるような為替や証券取引関係
・ユーザー数千万人クラスのWebシステム
・メガ金融機関の口座処理
・やたらに複雑なSQLが要りそうな処理（これもビジネス系であれば現行踏襲をやめて抜本的業務見直しで解決可能だったり）
・・・・・などなど
#2
@otn
ご回答ありがとうございます。
どういった業務イメージなのでしょうか？
私としては「DB設計が得意なアプリケーション設計者」としての業務を考えております。
担当外のシステムで、DBで何か問題が起こると一時応援の声が掛かったり、「これはちょっとDB設計ちゃんとやらないと性能が出ないぞ」という新規プロジェクトの立ち上げメンバーに呼ばれたりとかはありそうです。
このような場合、基本的には他人の設計したシステムのリファクタリングでの評価が主になり、自分が上手く設計できたDBが評価されるようなことはないのかなと思っています。（問題が起きないことが良いことであるため）
また最低限
DB設計ちゃんとやらないと性能が出ないぞ
という発想になる方が同僚・上司にいる必要があるなと思いました。
あるいは、オープンソースDBMSのコアなコミッターであるとかであれば、また別の活躍イメージもあり得るかも知れませんが。
また私個人の話ですが「DB設計が得意なアプリケーション設計者」を目指しているのでコミッター等のキャリア等はイメージしていませんでした。
マネージドDBについてもこの回答を読んで、私も中途半端なエンジニアは不要になるのかなと思いました。
お金で解決できる場合はスケールさせれば解決する問題ですし
スケールだけでは解決しないトランザクションやロック・その他の知識が必要なシステムは
最近まで色々と大変だった金融系のシステム等、大規模で専門的なものに限られてくるのかなと思います。
DB一本でキャリアを進んでいくというより、この人に聞くと解決するかも？みたいな人になることを目指してみようかなと思います。（それが自分の武器になるかはわかりませんが・・・）
ご親切に長文での回答本当にありがとうございます！
#3
総合スコア85945
投稿2024/02/19 10:04
担当外のシステムで、DBで何か問題が起こると一時応援の声が掛かったり、
このケースでは、「性能が出なくて困っている状態で、原因はDBじゃないのか？ということになって呼ばれて対応する」イメージなので、
このような場合、基本的には他人の設計したシステムのリファクタリングでの評価が主になり(中略)（問題が起きないことが良いことであるため）
じゃなくて、「性能問題が解決できた」ことが評価ですね。解決出来なければ評価されませんが。
何も問題が起きてない状態での維持管理工程でのリファクタリングということであれば、
リファクタリングを勝手にやって良いはずはなくて、「これこれの理由でこういう変更をすればこういう良いことがあるのでやりましょう」という提案もしくは「これこれの所をこれこれになるようにリファクタリングして」という指示のどちらかがあるかと思うので、提案した場合であればそのリファクタリングの目的が達成されたかどうか、指示されてやった場合は指示通り出来たかが評価対象ではないのでしょうか？
「これはちょっとDB設計ちゃんとやらないと性能が出ないぞ」という新規プロジェクトの立ち上げメンバーに呼ばれたりとかはありそうです。
自分が上手く設計できたDBが評価されるようなことはないのかなと思っています。
このケースでは、新規構築なので、改善前という比較対象がなく、うまく行ったとしても、
誰でも出来て問題なかったのか、凡人がやると性能問題が出てたはずの所をスキルでうまくやったのか、部外者には分からないですね。
これはそういう回数を積み重ねて認知してもらうか、分かる人にだけ分かってもらっていることでしょうがないか。
また最低限
DB設計ちゃんとやらないと性能が出ないぞ
という発想になる方が同僚・上司にいる必要があるなと思いました。
これはもちろんそうですが、そうじゃないケースというのはどういう状態の企業でしょうか？
・ DB設計に力を入れなかったがDBに起因した性能問題でプロジェクトが遅延したり赤字になったことが過去に無い（極小企業とか、若い企業とか、対象分野がDBをあまり使わないとか）
・DB設計に起因した性能問題に直面したことが過去にあるが、過去から学ぶという考え方が会社全体に無い
・技術者はDBちゃんとやらねばと思っているが、人員計画やプロジェクト計画立案に技術者の意見が入ってない
・とかとか
結構危ない企業かも知れません。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。