研修担当から基盤構築へ。設計が主役になる開発の現場
うわっ、プログラムって“書かない”ところから始まるの!?
そんな衝撃から、私のメッセージキューイングシステムとの出会いは始まりました。
それまで私は研修担当として、アプリケーション寄りの世界にいました。ところが次に任されたのは、サーバ基盤の構築担当。舞台は、ソフトウェア工場で作られた Cosminexus を中心とした、いわゆる「開発基盤」の世界です。
■ 初めて触れた、メッセージキューイングの仕組み
私が作ることになったのは、メッセージキューイングシステムの自動生成。
サーバを呼び出すプログラムには、実はいくつかの決まったパターンがあります。そしてそのパターンは、実装段階ではなく設計の時点で見えてくる。
「だったら、そのパターンを設計書で指定してしまえばいい」
「決められたソースは、自動で作ってしまおう」
そんなコンセプトでした。
■ 設計から、プログラムが生まれる
設計書に「このパターン」と書けば、対応するプログラムが自動で生成される。
今でこそAIがコードを作る時代ですが、設計書から、設計したとおりのプログラムを作るという発想は、当時としてはかなり画期的でした。
その結果、設計と実装のズレは大幅に減り、実装ミスも少なくなる。
コンセプトは明確で、迷いがない。
■ Justwareという基盤フレームワーク
この仕組みは、Justware というJavaのフレームワークに上書きする形で実現されていました。
単なるツールではなく、開発の考え方そのものをプラットフォームとして提供する。
「さすが大きな会社…プラットフォームまで作るのか」
そう感じた瞬間でもありました。
■ 設計者に突きつけられる現実
この開発に関わって、強く実感したことがあります。
それは、設計者がプログラムをどれだけ理解しているかが、すべてを左右するという事実。
設計からプログラム、そしてテストまで。
この流れがスムーズにつながってこそ、大規模システムは安定する。
それは、構築に関わる人すべての願いでもあります。
「それを実現しよう！」という本気が、この仕組みには詰まっていました。
■ 大規模開発に効いてくる理由
人が多く、システムも大きい。
そんな環境では、個人の頑張りよりも仕組みの力がものを言う。
設計を起点に、自動でプログラムが生まれ、テストへとつながる。
この一貫した流れこそが、大規模開発の現場で本当に効いてくるのです。
私は、そんな開発に関わってきました。
そして今、その経験が確実に次へとつながっていると感じています。
※本記事は、特定の製品仕様や内部設計を開示するものではなく、筆者の経験を抽象化して紹介したものです。
コメント
コメントを投稿