データベースエンジニアの仕事がきついと言う話を聞いたことがありませんか。
その話によると
- 業務過多になることがある
- 責任が重い
との事ですが、本当にそうなのでしょうか。
私は違うと考えています。
(会社やプロジェクトによってブラックなものもあるかもしれません。)
この記事では、きつい仕事と言われているデータベースエンジニアの仕事の内容とそのきつさの真偽
そしてやりがいについてデータベースエンジニア歴25年の私が解説いたします。
データベースエンジニアの仕事の概要
データベースエンジニアの仕事の種類には「設計開発」「管理」「運用」の工程があります。
私はスキルを伸ばす際、この３つの工程のどの工程で必要となるスキルか常に意識する事が必要であると感じています。
私は各工程で肝となる作業が実際の「きつさ」につながると感じています。ではそれぞれの仕事内容を簡単に解説したいと思います。
データベースの設計開発
データベースの設計はお客様から要件を聞き出し、整理し、最適なデータベースを設計し、実際に構築していく作業です。
この工程での失敗は後工程のすべてに影響する非常に重要かつ責任の重いパートなので、私でも適度な緊張感を感じながら仕事をします。
それでもゼロから何かを生み出す作業はやりがいのある仕事だと私は感じています。
私はコンサルタント業務も行うのですが、この工程で獲得した業務系の知識がベースとなっています。
データベースの管理
データベースの管理とはデータベースを使っていくうえで、日々増加するデータに伴ってデータ領域の拡張を行ったり、検索の多重度が上がり応答時間が長くなりすぎていないかなど、チェックし手当します。
また、この工程では他のシステム関係者と共同で解決にあたる作業もあります。
私が担当したプロジェクトでも実際にあったことなのですが、
他のシステムとのシステム間接続を行う事になりました。
初めての事なので様々な問題が発生しました。その都度データベース以外の分野の学び、既存の知識とのコラボで乗り越えていきました。それは気取った言い方をすれば、クリエイティブで胸躍る作業でした。
データベースの運用
データベースの運用にともなう作業、例えばユーザの追加削除やセキュリティレベルを考慮してアクセス権限をユーザに付与するなどを行います。
私の予想ではこの工程はいずれ自動化されていくと考えています。
というのは、この工程は少ないメンバーで多くの客先やプロジェクトを担当します。
このため効率化が求められる事に加え、単純作業が多く自動化向きな工程だからです。
データベースエンジニアがきつい仕事と言われる理由
一般のITエンジニアも前述の「設計開発」「管理」「運用」の工程を仕事としている事があります。
私の友人の一般のITエンジニアに話を聞くとデータベースは扱っていないながらも似たきつさはあると感じました。
そこで以下に一般的なきつさとデータベースエンジニアのきつさについてお話します。
前述の「設計開発」「管理」「運用」工程に分ける事で私なりの整理をしたので参考にしてください。
きつい理由1 (データベース設計開発)
お客様がデータベースの導入案件に慣れていない場合、お客様の要件に具体性が欠ける場合が多いのです。
こういったケースは同じ業界の類似のプロジェクトを参考にして仕様を決めていきいます。
そしてそのお客様の使い方にあった設計であるかどうかは、使い始めて分かります。
つまり、システムがほぼできあがってから問題が発生し、それを何とかする為に大きなの手戻りが発生するという事です。。
設計に問題があり、プログラミング等の開発・テスト作業をやり直すことは、他のIT案件でも普通に発生します。
しかし、データベース案件は単純な項目追加修正でさえ、テストは全てやり直しになります。
私なりにイメージしやすい例を考えてみました。
例えば元の業務データ一件あたり500の項目があり、そのデータが100万件あったとすると
項目数は単純に掛け算なので、テストをやり直す対象項目数はなんと50億！。
50憶の確認作業を何度もやるって、顔に斜線入りませんか？
その場合最悪徹夜だったり、休日出勤となるかもしれません。
・・・・以前はそのような事もありました。
しかし現在のプロジェクト運営は、既存メンバーに過度に負荷かけるの事はないのです。
問題点をプロジェクトのリスク範疇として捉え、作業量に応じた人員を追加し対応する。
また、最近のテスト作業はツールも充実しているので以前よりは楽ができます。また、単純作業やボリューム的に大変な作業は今後自動化されていくので、心配する必要はないと私は考えています。
システム開発でデスマーチは少なくとも私の会社では過去のものです。
以上のことから設計開発でのきつさは、設計時考慮もれを起こさないプレッシャーと設計変更時の手戻りと考えられます。
最近のプロジェクト運営では、考慮もれはある程度あって当然というスタンスです。プロジェクト運営上リスク管理で取り扱うので、
きつい理由2 (データベースの管理)
管理業務ではデータベースの空き具合や使い方の統計を取り、容量の拡張やパフォーマンスのチューニングを実施します。
一般的なシステムの場合、データが増える事で極端に応答性能(パフォーマンス)が劣化する事はありません。
データベースシステムでは一般的なシステムと比較して膨大な量のデータが日々蓄積されていきます。
このため、データベース容量のチェックやパフォーマンスチェックは欠かせません。
私が遭遇した以下の障害ではこれを怠ったため発生していました。
- 空き容量不足でデータを書き込めなかった
- データが多くなりすぎで検索に時間がかかりすぎるようになった。
実際の対応方法としては、日々のデータベース更新作業を手作業でやり直したり、検索用言語であるSQLを変更して応答性能が出るように改善します。
これらの作業はデータベース処理の流れ、データベースの仕組み加えて業務の知識が必要となるため、かなりの経験・スキルが必要です。
応答性能改善は最終的にお客様の本番システムでしか確認する事ができないため、その申請手続きに苦労しました。
また、実際お客様が業務で使用されているシステムが使い物にならない程遅い場合、「直ぐに直せ」とか「月初のシステム利用ピーク日までに直せ」など期限が切られるケースも私は経験しています。
ただし、日常的に発生するわけではないのでデータベースエンジニアのきつさに含めるのは早計と考えます。
他のITシステムと比較して発生しやすいといえ、障害対応がきついのは他のITシステムのエンジニアと同じです。私の経験上、応答性能が問題となるケースは1年に１度あるかないか程度です。
きつい理由3 (データベースの運用)
お客様の会社で部署異動があるとデータベースを使う人の入れ替えがあります。
新しくデータベースを使用する新規着任ユーザのためにログインIDや権限を設定し、離任したユーザのIDや権限を削除する設定を実施します。
私の経験した年度の切り替え作業では、大量のID削除・作成・権限削除・権限付与が発生し、システムの規模によっては大変な作業となります。
最近は社員データベースから送られてくる所属部署の情報からIDの作成や権限の付与を自動的にする仕組みにする事が多いので、今後異動にともなうきつい作業はなくなっていくと考えられます。
きつい理由4 (その他)
他のサイトで「データベースエンジニアはプロジェクトやチームに基本的に1人のため、データベースに関する業務は全て集中します。」
社内システムでデータベースエンジニアが不足している場合には発生するかもしれません。
私の会社はデータベースの会社なので特殊かもしれませんが、こういった経験はありません。
また「企業のデータを守る重大な責任があるため、時にはプレッシャーが負担に感じることもあるかもしれません。」との記述がありました。
私の意見ですが、確かに何かあれば顧客情報流出で賠償金も発生する世界です。
また、私をはじめデータベースエンジニアは常に重要な情報を扱っている自覚はあります。
とは言え、個人の不注意で事故が発生しないような仕組みの上で仕事をしています。
例えは、本番システムと開発システムを間違えないように本番システムはネットワークが別になっており接続できない。とか。
また、プレッシャーを感じるレベルは一それぞれなので、会社が契約している産業医に相談できるようになっています。
データベースエンジニアは残業が多い？
仕事のきつさにおいて、残業時間は大きな要素といえます。
残業について客観的なデータとして多くのサイトで参照しているのは政府発表の「賃金構造基本統計調査」なのですが、データベースエンジニア職種が単体扱われていません。
また全体的に数値の平均なので他のIT関連業種においても少し違和感を持ちました。
あまり参考にならないと考えたので統計の具体的数値を上げる事は差し控えます。
代わりに私の個人的な例を挙げる事にします。あくまで個人の一例なので参考程度に考えてください。
私の会社は年俸制なので残業代はつきません。人事部によると年俸には2時間程度の残業代が含まれている計算になっているとの事なので、月間40時間を上限目安に考えて仕事をしています。
ただし、仕事は所属するプロジェクトによって波があり、忙しい時期、暇な時期があります。このため年間を通してバランスをとるっているのが現状です。
私は仕事量が自分の残業でどうにかなるレベルでない場合は、上司、チームメンバーと相談してヘルプを受けます。
もし毎日毎日夜半まで仕事しても終わらないボリュームであるなら、仕事の配分が間違っています。
私の場合、仕事を中途半端にするのではなく、他の人に渡せるように手順を確立して、誰にでも引継ぎできるよう準備します。
その上で何人で何日かかる仕事か把握して、それができる人的リソースを要求します。
長時間労働はミスも置きやすく、働く側も顧客も不幸になります。
そういう状況下では正攻法(人的リソース追加)の対応を要求しましょう。
こういった要求は下請け孫請けでは通りにくい現実があるので、なるべく元受けに近い会社で仕事する事が自分を守ります。
そのためには自分を磨き資格やスキルを身に付けましょう。
データベースエンジニアのやりがい
ここまで、データベースエンジニアのつらさについて書いてきましたが、それに見合うやりがいも書かなくては片手落ちです。
言うまでもありませんが、私の現在があるのもデータベースエンジニアにやりがいがあったからです。以下、私なりに考えたやりがいについてお話したいと思います。
最新のITテクノロジーに関わる事ができる
情報をデータベースで管理する事が今後なくなる事はありません。
そして様々な最新ITテクノロジーを取り込んで新しいシステムを構築していく事も実際多いのです。
私自身も経験していますが、新しい技術を参加プロジェクトで形にしていく作業は技術者冥利に尽きます。
プロジェクトメンバーと一つの目標を目指せる
データベースエンジニアの仕事は「プロジェクト」単位で仕事を進めていきます。他のエンジニアと協力しながら、システムを構築していきます。
同じプロジェクトで辛さや喜びを共有する事は大きな達成感に繋がります。
プロジェクトあるあるで、「プロジェクトが辛ければ辛いほど打ち上げは盛り上がる」は私も経験済みです。つらい経験を共有する事で結束が高まったのだと思います。そんなメンバーとは今でも交流があります。
規模の大きな仕事、重要な仕事に携われる
分析を行うシステムでは、マーケティングや経営の知識も身に付きます。コンサルタントや経営者としてキャリアの可能性が広がるのも魅力です。
キャリアパスについて様々な選択肢があります。
これについては別の記事にしようと思います。
開発プロジェクトの主要メンバーになることが多い
システム開発を行うにあたり、データベースの構造がシステム方向性を決めることが、ままあります。
そしてシステムの仕様の概要あるいは詳細を正確にプロジェクトのメンバーに伝える役割をデータベースエンジニアが担うのです。
その役割からデータベースエンジニアはプロジェクトの主要メンバーとなることが多くなります。
技術的な仕様ではプロジェクトマネージャーを補佐する立場になるため、私もその役割に身が引き締まった思いが何度もあります。
まとめ
データベースエンジニアのきつさは、他のITエンジニアと大した違いはありません。
データベースのパフォーマンスチューニングは期間や期日に間に合わせる関係でタイトな仕事です。
しかし徹夜して終わらせる仕事ではありませんし、頻度は高くありません。
残業はプロジェクトの繁忙期によっては多くなりますが、定常的ではありません。
さらに、単純でボリュームのある作業は今後ツール等で代替し、なくなっていくと考えられます。
また、やりがいから見てもデータベースエンジニア魅力的な職種ではないでしょうか。
