設計者の発言

業務システム開発とデータモデリングに関する語り

開発者が自動化に負けないためのたったひとつの方法

 ソフトウエア開発者の立場をもっとも脅かすものは、「新たな開発用ソフトウエア」である。それまで半日がかりだったような作業が、新たなソフトウエアを用いることで一瞬で片付いたりする。こういった合理化にともなって開発者の人員削減が進む。そのときに少数精鋭要員として生き残るために欠かせないスキルは、「ソフトウエア仕様の構想力」である。。

  自作のローコード開発ツールを使って日常的に作業しているのだが、ツールに組み込んだ最新機能を用いて、テーブルやアプリの名前(ID)を一瞬で変更(リネーム)できるようになった。ときには膨大な定義要素が関わるので、リネームの過程は単純ではない。たとえばALTER命令を使えばテーブルモジュールのIDを変更することなど簡単だが、それらのIDを参照している箇所を全定義要素に渡って新しいIDに置き換えなければならない。今までは、クロスレファレンスを見ながら煩雑な手順を踏んで変更していたのだが、半月前にふと気づいて試してみたら完全に自動化できてしまった。ことほどさように、クロスレファレンスの分析機能とリネーム機能は双子のようなものなのである。結果的に、これまでやっていた作業は何だったのか思えるほど楽になった。

  考えてみると恐ろしい。もし、リネームのための複雑精妙な手順を実施することで価値を提供している技術者がいるとしたら、その仕事が霞のように消えてしまったことになる。もちろんリネームだけの話ではない。ソフトウエア開発にはそのような「複雑かつ厳密な手順」が求められる工程が多く含まれている。定義情報を様式化することで、それらは想像以上に容易に自動化できてしまう。いやはや、プログラミングの破壊力は恐ろしい。

  これに関連して、最近驚かされたことがある。あるプロジェクトで「フロントエンド」と「バックエンド」との分業がなされていた。そういった体制は最近では珍しくはないようだが、弊害が理解されているとは言い難い。フロントエンドを支える技術は刻々と変化するだけでなく、作業を合理化する形で発展してゆく。遅かれ早かれ、バックエンドを担う要員がフロントエンドを片手間で扱えるようになる。"フロントエンド・エンジニア"なんてアダ花的な言い方もあるが、これを専門とする働き方は長い目で見ればリスクが大きすぎる。

  私が新人を指導する際には、フロントエンドだけをまかせるような真似はしない。アジャイル開発のように小さな機能単位でちまちま回すことも許さない。そんなやり方ではシステム全体を構想するセンスがいつまでたっても身につかないからだ。代わりに、テーブル10個程度で済みそうなサブシステム1個について、関係者からのヒアリングとDB設計からプロトタイプの作成・検証までの一切をまかせる。そこまでやってみなければシステム設計のダイナミズムや責任の大きさを理解できないし、必要な適性を有するかどうかを本人や周囲も判定できないからだ。

  テーブル100個以上を含む業務システムを一体として構想できるようになる――これこそが、システム開発者が自動化に負けないための最善の対処法である。オブジェクト指向プログラミング(*1)をはじめとする「仕様を実装する過程」は、手間暇がかかるゆえに自動化の標的にされやすい。リネームが自動化されたのと同じ話だ。いっぽう「適切なシステム仕様を構想する過程」は複雑すぎて様式化できない。ゆえに自動化できない。この役割こそがシステム開発者が提供する価値の源泉であって、これを担うためのスキルとセンスを獲得することが、末永く現場で活躍し続けるための最強のコツである。これが結論。

 しかしながら、システム全体の仕様を構想するには、広範囲な業務知識やDB設計の重厚なスキルが必要だ。習熟するには5年から10年はかかる(だからこそ参入障壁が高い)。そのための時間的・精神的余裕をどのように確保すればよいのだろう。ローコードのような合理化技術がそのためのカギだ。実装過程を自動化することで余裕がうまれるからだ。おおむね定時で帰れていないとしたら、自動化の余地があるか基本設計に失敗していると考えていい。

 ところが困ったことに、少なくない技術者がプログラミングへの強いこだわりを持っている。偏愛といってもいい。多くの技術者が自動化を毛嫌いするのは、プログラミングの意義や機会が棄損されると感じるからだ。しかしそれを是としたままで30代を迎えると困ったことになる。20代から設計の訓練と実務経験を積めば、35歳までには大きなシステム全体を構想できるようになる。40歳までにそのスキルを身につけなかった技術者は、「別の誰かによる構想の一部をプログラミングする立場」から抜け出せない。技術者自身の「プログラミングへの偏愛」によって自らの立場を弱体化させているということだ。しかしこれはまだましな事態で、オブジェクト指向プログラミングに習熟したという理由で、いきなりシステム設計を含めたアジャイル開発を担わされたりする。大きな案件では本人も周囲も七転八倒することになる。

 そういうわけなので20代のうちから、開発過程がじゅうぶんに合理化されたプロジェクトに積極的に関わってほしい。こまごましたコーディング作業に時間を奪われ過ぎないためだ。もちろんプログラミングのスキルは不可欠だが、その蠱惑的な世界に没入し過ぎてはいけない。代わりに、システム設計の学びと実務経験を積むことに意識を向けてほしい。なんのためか。現場でシステム開発の仕事を末永く楽しみつつ、年季に応じて所得を増やし家族を養っていくためだ。

  

*1.最近ではドメイン駆動設計ともいう。ソフトウエアの仕様をクラス構造として捉えるためには効果的な枠組みではあるが、RDBを核とする情報管理システムとの相性が悪すぎる。オブジェクトはオブジェクトIDによって識別されるため、DB設計のスタイルが「IDリクワイアド(前記事参照)」になってしまう。いずれにせよ、オブジェクト指向プログラミングにハマりすぎて、オブジェクト指向を「世界を認識するための汎用的枠組み」などと奉ってはいけない。