全4257文字
PR

 いささか刺激の強い題名は日経クロステック編集部が付けてくれたものだが若手のエンジニアを批判する意図はまったくない。題名にある「若手エンジニア」はかつての私だからである。

 50代に突入した現在の私は、いわゆるWeb系企業に所属し、業務システムを含むバックエンド領域の設計と開発に従事している。もともとはPCのデスクトップアプリケーションを開発するプログラマーとして仕事を始め、途中から業務システムの設計・開発に移った。そのとき若手エンジニアであった私は「業務システムになぜRDB(リレーショナルデータベース)が必要か」、よく分からなかった。

 RDBを使いこなせなかったわけではない。業務システムを使う利用者から要求を聞き、画面をつくる。部署によって要求は異なるから複数の画面ができる。画面で入出力されるデータ項目を集め、正規化してRDBにまとめ上げることはやれていたし実際につくった業務システムはきちんと動いた。

 だが“デスクトップアプリケーション上がり”の私には業務システムにおけるRDBの位置付けについてモヤモヤするものがずっと付きまとった。デスクトップの場合、アプリケーションの利用者がやりたいことを整理すれば開発できた。ところが業務システムの場合、現場オペレーションの要求を分析しただけではRDBの設計につながらない。

 RDBの設計には現場から独立した目線が必要で何か特権的な作業に思えたのだがなぜそうなのかが腹落ちしなかった。悩む過程でエリック・エヴァンス氏が説くところのドメイン駆動設計を学んでみた。だがドメイン駆動設計にそって考えてもやはりRDBの存在がより特異に浮かび上がるばかりでモヤモヤは消えなかった。

 本連載の第1回でIT勉強宴会を主催する佐野初夫氏はメインフレームからオープンシステムに移行する際、業務システム設計に関するノウハウが継承できなかったという見立てを次のように述べていた。

 「新入社員として入ってきた技術者は先輩から教わる機会があまりなく、プログラミングやデータベースの導入などのスキルは研修と自力で身に付けたが、業務設計やそのノウハウ習得まで手が回らなかった」

 佐野氏はメインフレーム世代、私はオープンシステムど真ん中の世代である。振り返ると若いころの私には「業務設計やそのノウハウ」の何かが足りなかった。IT勉強宴会に参加し、メインフレーム世代の方々と交流することでRDBを使う設計の勘所がようやく腹に落ちた。その経緯をお伝えしたい。