【Part1】システム開発に見た夢

今日から数回に分けて、これまで私が辿った道を書いていきます。
自分のキャリアの整理と、これからどこに向かうべきかを問うことが目的です。

システム開発に夢を見る

未経験からシステムエンジニアになり、３年が過ぎようとしていた。
なんとなくエンジニアになって、なんとなく３年過ごしてきたが、これといってスキルを高めたりはしなかった。
そもそも、開発から試験、リリースを３年かけてやるプロジェクトだったし、その開発もほとんど、関わることができなかった。
なんとなく不安になるも、なんとなく流していた。

でも、そんな中でも、システム開発の上でよく聞く問題点は、自分なりに気にしていた。

• なんで、プログラムを書くって効率的じゃないのだろう？
• コンピュータを扱っているのに、なんで人の作業は楽にならないのだろう？
• なんでエンジニアなのに、スキルがある人とない人がいるのだろう？

最後の問いなんて、自分みたいな未経験が入れるのだから、すぐに気づいても良いものだろうに。
そんなことが気になった私は、システム開発とはなんぞやを書店で調べるようになった。

ほとんどの問いは解決しなかった。
結局、コンピュータを扱うのが難しいから、我々エンジニアがいるのだという結論に至った。
いま思えば、なんと考えが浅いことか。
そして、クラウドコンピューティングに代表する新しい技術によって、
コンピュータの扱いがどんどん楽になっていたことに、このときは気づかなかった。

ドメイン駆動設計との出会い

効率的じゃないプログラムの書き方しか知らなかった私は、Seasar2のようなフレームワークを使うことが、効率的なのだと思っていた。
そもそも、フレームワークを使うことが目的ではないはずなのに。
そのズレに気づいたのが、オブジェクト指向プログラミングとの出会いである。
如何にプログラムを整理して書くか、その手法がカタログになっているデザインパターンに興味を持った。
Javaをやっていたのに、こんなことを気にしたことがなかった私は、こうして効率化の道筋を見たのである。

ただ、デザインパターンとて、結局はパターンでしかない。
どんなときに、どのように適用するかまで示してくれるものではない。
答えを知りたかった当時の私は、それ以上の考察はしなかった。浅はかである。

そして出会ったのが、ドメイン駆動設計である。
ただの技術的な手法ではない。物事の整理の方法を示している、そんな気がした。
答えを知ろうとしたのが、そもそも間違いだったとそこで気づいた。

業務を分析すること。
そして、適切な単位で分割をして、境界で区切ること。
境界（ドメイン）同士がお互いに協調して、業務を遂行すること。
境界内は、業務をモデル化して組み立てること。

システムの構成は、扱うドメインで違うため、適切に分析して、分割して、協調させる。
そんなやりかたがあったのか、と驚くと同時に、なんかすっと自分の中に入ってきた気がした。
今までのデザインパターンの応用もあり、複雑な業務領域をシンプルにする思想もあり、またエンジニアとして挑戦する気持ちを刺激するものでもあった。
当時の自分は、素直にそう感じたものだった。

現実のシステム開発のやり方との乖離

ただし、現実のシステム開発のやり方とは全然違うというのも、素直に思ったことだった。
どうやったら、こんな不確実なやり方ができるのだろうと。

私が仕事をする界隈では、ウォーターフォール的にしかやらない。
作れるのか作れないのか、それしかない。どう作るのか、は要求されないからだ。
要求されるときは、作り方も降りてくる。
それがもどかしかった。一体どこのシステム屋なら、このやり方が実践できるのだろうと思った。
中途半端にやると、かえって仕組みを複雑化してしまう。だから、下手に手をつけられなかった。

近年のIT業界の動向を見てみると

近年というか、もう当時からそうであったが、システムはどんどん分散化していっている。
マイクロサービスなんて言葉ももうコモディティ化している。
Dockerを始めとするコンテナ仮想化技術が発達して、ある程度小さい単位のコンポーネント同士が、協調してシステムを構成するのが一般化してきている。
複雑化するコンテナのリレーションは、Kubernetesなどのオーケストレーション技術によって、容易に管理できるようになった。

昔より、ドメイン駆動設計の威力を発揮する土壌はできているはずなのに。
私の周りでは、コンテナオーケストレーションはおろか、Dockerすら登場しない。

３年目のときに疑問に思ったことは、ことごとく新しい技術が解決していっている。
特に、CI/CDなんて、ある程度の品質担保、デプロイ、リリースをプログラミングで実現できる手法だ。
コードを書くのが好きなエンジニアなのに、自分の作業を楽にするコードは書けないのか。
コンテナ技術も、インフラをコードで書いて構築する技術だ。
すべてコーディングできる。
コードは書いたとおりに動く。人間のやることが減る。
効率的じゃないか。

多層構造

ここに来て、私はもうこの業界が世の中の動向についていけていないのは、環境にあるのではないかと考えている。
トップダウン的に見て、コードを書いて作業を効率化することが、上の人にとって自分のこととしてメリットに感じられてない。
だから導入しない。自分の仕事を効率化するなら取り入れているはずである。
所詮、開発会社がシステム開発を請け負っている環境では、エンジニアの作業レベルの効率化はメリットに感じない。
そう思えて仕方がない。

これは批判ではない。
私が自らの立ち位置を客観的に観察した結果、感じたことである。
私はそう感じた。それだけ。
だから、別の環境に移らなくてはならない。

システム開発に見た夢は、きっと見ている場所が違うだけで、実は夢なんかじゃないのではないか。
そうやって、発起するに至る。