【Part4】師匠のいない専門家
第四回です。
今回は、私の不安感をもう少し深掘りして、結局どのような環境を求めているのかを整理しました。
元来の性格と、仕事上の不安感を俯瞰して眺めたとき、その原因となるものがこれなんじゃないか、というお話です。
コンプレックスと野心
学生時代は、勉強はできない方だった。
高校も大学も、そんなに学力は高くないレベルで、その中でも平凡な位置にいた。
親は口癖のように、世の中には頭が良い人がいて、それでいてうちの家はごく平凡だ、とよく言ったものだった。
それが私にとっても、実際にそうであるのは疑いようの無いほど、考え方に刷り込まれていた。
だから、世の中に出れば、頭が良い人がたくさんいて、私が考えもしないような理屈で、目的で、手段で、世の中を動かしている、そう思っていた。
それは、就職をして新人時代を過ごすくらいまで、信じて疑わなかった。
私はバカで、世の中は学びに溢れていて、すごい人間がたくさんいて。
そんな人たちをいつか見返してやりたい、それが心の底で密かに燃やしていた野心でもあった。
新人時代
新人時代は、本当に学びに溢れていた。
先輩や上司は、みな仕事ができる人で、私の仕事を見守ってくれて、ときには仕事のやり方を教えてくれた。
そのおかげで、私は順調に学生気分を抜くことができ、社会人としての基礎を身につけることができた。
この頃には、一切の不満もない。感謝しかない。
そして、この感謝を恩返しする間もなく、当時の先輩・上司はすべて転職していった。
このプロジェクトを離れて、初めて私は、一番最初のプロジェクトが恵まれていたことを知った。
現実は違った
他のプロジェクトを経験するにつれ、世の中が基本的に出来ない人間で成り立っていることに、ようやく気がついた。
特にIT業界はそうかもしれない。人材流動が激しいこの業界は、できる人間は基本的に回ってこない。
私はこうして、新人時代は忘れていたコンプレックスと野心を思い出した。
世の中は私より頭が良い人で構成されていて、私が一番バカで使えない世界ではなかったのか？
これは衝撃的だった。
コンピュータ・サイエンスのプロフェッショナルがいて、そんな人がたくさんいるプロジェクトで、私が一番出来ない。
出来ないから食らいついて、腕を上げていく。職人気質な環境を夢想していたのだ。
本当の恐怖とは
私は出来ない人間ではなかった。頭が悪くて、きっと社会では苦労する人間だと思っていたが、そうじゃなかった。
これで自信をつけて、一人前に歩き出せると考えられる人間だったら、楽だっただろう。
そう素直に喜ぶことはできなかった。
師匠・師範のいない専門家になってしまうのが怖かった。
だから、せめてもの目的や向いている方向の確認ぐらいはやらないと、不安になってしょうがないのだ。
私には、この業界の危ういバランス感覚が、恐怖でしかない。
みんなそれをわかっていて、そこに立っている。
それは、私には無い強さではあった。
コンプレックスが前提にある人間には、軸となる何かがほしいのだ。
強いエンジニア
新人時代はコンプレックスを忘れていた、と書いた。
でも、それは本当にそうなのか？と思い返すと、そういうことでもなかったなぁとも思う。
あのプロジェクトは、目的、手段、そして、その遂行が、明確だった。
なぜそれをやるのか。
どうやってやるのか。
リハーサルをやって本番に備えよう。
もし問題があったら、どういう判断で切り戻すのか明確にしよう。
そうやって仕事をしている先輩・上司、それにお客さん、関係会社の人たちも、知識と経験と、それに準備を入念にやっていた。
その理路整然とした仕事っぷりに、自らの学びを感じ取っていたのかもしれない。
だから、新人としても、いち個人の仕事の仕方としても、充実感があったのかもしれない。
みんな専門家として、屹立していたように見えたからだ。
私が強いエンジニアになるためには、この環境が必要ではないかと感じている。
私がそびえ立つための土壌は、今一度、私が一番出来ない環境に放り込まれることで培われる。
今の環境は、私のなんちゃってコンピュータ知識が、まかり通っちゃう環境だ。
そんな環境で、こわごわと仕事をしていたところで、私は止まりかけのコマのようにグラグラする自分を変えることは出来ない。
強いエンジニアになりたい。
地に足のついたエンジニアになりたい。
私はそのためには、師匠となる存在を見つけることが突破口なのではないかと思うのだ。
【Part3】システムは生産するもの？
第三回である。
今回は、自分が何に喜びを感じるか、ということをまとめてみました。
洗練される要件
要件が降りてきて、詰めて固めて、それから作っていく。
要件は、得てして曖昧なことが多い。
そして、要件の先に、本来の目的やユーザへの気遣いがあったとしても、それが見えなくなるほど洗練されて降りてくることが多い。
実際に要件通りに作ってみると、使いづらかったりする。この機能、何がしたいんだ？と、テストしながら首をかしげることも多い。
要件通り作ること
最初にこの話をしたのは、この要件定義の目的が、作るシステムを明確にして、開発を始められるようにするため、という、システム屋目線になってることが気になったからだ。
私が気にしちゃうから、このシステム屋目線に違和感を覚えてしまうのだが、そもそもエンジニアというのは開発の専門家であるのが前提だから、この視点で考えていくのはおかしくない。
だから私は、システム屋の職務である工数管理が苦手である。てか、嫌いだ。それは、要件通り作ることへの、小さな抵抗の表れかもしれない。
システム開発の専門家になりきれないのは、ひとえに、このシステムを使うシーンを考えてしまうことにあった。
だれが、どんなときにこのシステムを使い、どう感じるのか。
ユーザがこのシステムを使うとき、何かを解決するために使うはずである。目的がある、ということである。
それを期待してしまっている。ユーザの気持ちに訴える何かがあるのではないかと、システムを作ることに対して期待してしまっているのだ。
業務システムを開発していると、その期待を裏切られることが多い。
業務システムは、その使い方はユーザの運用次第。だから、どう使われるかは開発者の俎上に載らない。
この、現場と会議室の乖離みたいな状態が、それでいいのか？という気持ちにさせて、なんだか落ち着かないのだ。
要件通り作るって、最終的に誰のためにしているのだろう？って思ってしまう。
隣の人のために
私のこの６年のエンジニア人生を振り返って、一番心を震わせていたのはなんだろう。
そう思い返したとき、思いついたのは、新人時代にやっていた業務改善のツールを作っていたときのことだ。
プロジェクトのメンバーが、作業上ちょっと困っていることを、ちょっとしたツールを作ることで、その作業が少し楽になったのだ。
このとき、私は隣に座ってるこの人が実際に困っていることを、自分がプログラムをちょっと書くだけで少し改善したことが、何よりうれしかった。
- ミッションクリティカルなシステムのアーキテクチャを決めて、プロジェクトを先導すること
- 隣の人が困ってることを、簡単なツールを作ることで、少し役に立つこと
この２つの仕事があったとき、私は迷わず後者を取る。
それは、責任の重い社会的に価値のある仕事よりも、誰かに直接的に貢献できる仕事のほうが、私の心を震わせるからだ。
これって、私が仕事に求めるものを端的に表していると思うのだ。
システムは生産するもの？
システム開発は、よく産業・工業のように言われることがあるような気がする。
確かにウォーターフォール式のシステム開発は、生産ラインのように流れ作業感を感じさせる。
もちろん、その過程では、多くのエンジニアが頭を使い、汗水たらして作り上げるのだから、機械的とまでは言わない。
ただ、システムは生産するものだという認識を持ってしまうと、とたんに私はそこに価値を感じなくなる。
きっとこんな人が使ってくれて、身の回りのことがちょっと便利になって、実は人知れず感謝してくれている。
そんなものが作れる可能性を、ITは持っているんじゃないかって思うのだ。
システムを開発するのは手段であり、システムを作って叶えたい目的が何かあるはずである。
その目的に、誰かに直接影響を与える何かがあると、システムを開発することに価値を見いだせる気がしている。
【Part2】我流が暴走する悲劇
第二回です。
前回は、エンジニアとしての土壌が合わないという話をしました。
夢を見ていたことが、実は夢なんかではなく、いる場所が違うのではないかと。
今回は、合わない土壌でもがいて、今思えば暴走していたとも思える出来事をまとめていきます。
チャンス到来！
あるプロジェクトで、システムの構成から考える必要がある開発に携わることがあった。
よく言えばアーキテクチャから任せてもらえたが、悪く言えば丸投げである。作れればいい、みたいな空気である。
私は、これまで学んだあれこれをベースに、アプリケーションの構成案を考え、リーダーの承認を得た。
よくある、コントローラ、サービス、リポジトリの構成である。
ドメイン駆動設計を軸にしている私は、中途半端なモデルは作らず、トランザクションスクリプトを目指して設計した。このプロジェクトでは無理というか、やる必要はないと思っていた。それは結果的には、そのとおりだった。
私がこのプロジェクトで最大限気にしたのは、次の点である。
この取り組みは、概ね有効に働いた。
我流思想
こうやって、あれこれ自分で考えて決めて開発ができたことは、当時の私には嬉しかった。
ただ、考えて決めたことは、リーダーの承認は得たが、各メンバーが飲み込めていたのかは、正直微妙なところだった。
上記羅列してみても、特におかしなことは言っていないと思う。
だが結果的に、プロジェクトに一つの状況を招いていたことに、今になって気づいた。
つまり、あれこれ考えた私だけが、この思想を意識していたのである。
なんのための施策なのか、それはみんなが同じ方向を向くルールである。
結果として、ルールはルールとして有効だったが、これはみんなが私と同じ方向に向いただけだった。
つまり、私が間違えていたら、みんなが間違えた方向に向かってしまうのだ。
我流の思想が、我流のままルールとなり、それがプロジェクトの法となってしまうのだ。
それが怖いと感じたのが、とある事件が起きたときだ。
よくあるデータベースの問題だが
システムがいよいよ完成を見たときに、問題が発生した。
データベースのロックが、画面表示を妨げる事象が発生したのだ。
事態の深刻さはそれほどではなかったが、改善を検討する必要があった。
私としては、処理の妥当性を保証する上では、行ロックによるシーケンシャル処理を実現しないといけないと思って導入したのだが、それが画面表示に影響する場面があることに気づけなかった。
この問題は、ひとえに私の技術知識の不足が露呈したために、起きた出来事だった。
と、最初の頃は謙虚に自分を戒めていたのだが、見方を変えたときに一つのことに気づいた。
原因は私だけなのか？
他の人でも気づけたんじゃないか？
これは責任転嫁ではない。
構造上の問題が表面化？
なんで、チームの方向性が偏ってしまったのだろうか？
ただ、お前の責任だろう、と言われればそうなのだが、だれか一人が責任を取って反省するのが、唯一の対処法なのだろうか？
こういう問題が発生しやすい作業分担を、暗黙的にしてしまう風土が、実はあったんじゃないか？
そう思えてならなかった。
ドメイン駆動設計の思想は、業務領域をモデル化するにあたり、業務のエキスパートと、エンジニアが蜜に連携を取り、ドメインモデルを構築していく。
その過程では、みんなが全体の構造に関心を持ち、全体から部分に注目していく意識の流れがあるはずである。
要するに、複数の人の目が入る風土がそこにはあるのではないか、と思うのだ。
そういう複数の目を入れるのが、本来はレビューなのだろう。
ただ、このプロジェクトでは、レビューは形骸化していた。そこは別の意味で問題だった。
でも、トップダウン的なレビューを行ったところで、結局私の目が入るだけである。事件は防げなかっただろう。
暴走が起こりやすい土壌
私は、アーキテクチャを考えて決める段階から、これで良いのか？って思うときはよくあった。
特に、私のような実績がそんなに無いエンジニアが、ちょっとかじった程度のアーキテクチャ知識を振りかざして進める開発がまかり通っているこの状況には、大きな不安があったものだ。
だが、それはプロジェクトの遂行上問題にならなかった。
問題感が出るのは、実際にバグが出たとき、続行が不可能になったときだけだ。
目的はその突破でしかない。再発防止策は、ボトムアップで上げるだけだ。
なんで、こんなに上も下も乖離しているのだろう？みんなで一つのものを作り上げていく感覚が、このプロジェクトからは感じられなかった。
産みの苦しみ、と言ったらそれまでだが、苦しんでいるのは直接的な開発部隊だけである。
みんなが同じ方向を向いている
私は常々、みんなが同じ方向に向いていないと、何事もうまくいかない、と思っている。
それは、私が道を示して同じ方向を向かせることではない。
みんなが向いている方向と自分の向いている方向をすり合わせていくことが大事だと思っている。
その営みが、大手SIerでは上と下の乖離（社間的な、役職的な、契約的な、どれも当てはまる）で難しくなっている。そう思うのだ。
我流がひとりでに暴走するのは悲劇でしかない。
ただ、システム開発に関わる全ての人が我流を持ち合わせていたら、それをすり合わせることで、暴走ではなくチームとしての適切なベクトルになる。
そういう環境で仕事がしてみたいと思う、今日この頃であった。
【Part1】システム開発に見た夢
今日から数回に分けて、これまで私が辿った道を書いていきます。
自分のキャリアの整理と、これからどこに向かうべきかを問うことが目的です。
システム開発に夢を見る
未経験からシステムエンジニアになり、３年が過ぎようとしていた。
なんとなくエンジニアになって、なんとなく３年過ごしてきたが、これといってスキルを高めたりはしなかった。
そもそも、開発から試験、リリースを３年かけてやるプロジェクトだったし、その開発もほとんど、関わることができなかった。
なんとなく不安になるも、なんとなく流していた。
でも、そんな中でも、システム開発の上でよく聞く問題点は、自分なりに気にしていた。
- なんで、プログラムを書くって効率的じゃないのだろう？
- コンピュータを扱っているのに、なんで人の作業は楽にならないのだろう？
- なんでエンジニアなのに、スキルがある人とない人がいるのだろう？
最後の問いなんて、自分みたいな未経験が入れるのだから、すぐに気づいても良いものだろうに。
そんなことが気になった私は、システム開発とはなんぞやを書店で調べるようになった。
ほとんどの問いは解決しなかった。
結局、コンピュータを扱うのが難しいから、我々エンジニアがいるのだという結論に至った。
いま思えば、なんと考えが浅いことか。
そして、クラウドコンピューティングに代表する新しい技術によって、
コンピュータの扱いがどんどん楽になっていたことに、このときは気づかなかった。
ドメイン駆動設計との出会い
効率的じゃないプログラムの書き方しか知らなかった私は、Seasar2のようなフレームワークを使うことが、効率的なのだと思っていた。
そもそも、フレームワークを使うことが目的ではないはずなのに。
そのズレに気づいたのが、オブジェクト指向プログラミングとの出会いである。
如何にプログラムを整理して書くか、その手法がカタログになっているデザインパターンに興味を持った。
Javaをやっていたのに、こんなことを気にしたことがなかった私は、こうして効率化の道筋を見たのである。
ただ、デザインパターンとて、結局はパターンでしかない。
どんなときに、どのように適用するかまで示してくれるものではない。
答えを知りたかった当時の私は、それ以上の考察はしなかった。浅はかである。
そして出会ったのが、ドメイン駆動設計である。
ただの技術的な手法ではない。物事の整理の方法を示している、そんな気がした。
答えを知ろうとしたのが、そもそも間違いだったとそこで気づいた。
業務を分析すること。
そして、適切な単位で分割をして、境界で区切ること。
境界（ドメイン）同士がお互いに協調して、業務を遂行すること。
境界内は、業務をモデル化して組み立てること。
システムの構成は、扱うドメインで違うため、適切に分析して、分割して、協調させる。
そんなやりかたがあったのか、と驚くと同時に、なんかすっと自分の中に入ってきた気がした。
今までのデザインパターンの応用もあり、複雑な業務領域をシンプルにする思想もあり、またエンジニアとして挑戦する気持ちを刺激するものでもあった。
当時の自分は、素直にそう感じたものだった。
現実のシステム開発のやり方との乖離
ただし、現実のシステム開発のやり方とは全然違うというのも、素直に思ったことだった。
どうやったら、こんな不確実なやり方ができるのだろうと。
私が仕事をする界隈では、ウォーターフォール的にしかやらない。
作れるのか作れないのか、それしかない。どう作るのか、は要求されないからだ。
要求されるときは、作り方も降りてくる。
それがもどかしかった。一体どこのシステム屋なら、このやり方が実践できるのだろうと思った。
中途半端にやると、かえって仕組みを複雑化してしまう。だから、下手に手をつけられなかった。
近年のIT業界の動向を見てみると
近年というか、もう当時からそうであったが、システムはどんどん分散化していっている。
マイクロサービスなんて言葉ももうコモディティ化している。
Dockerを始めとするコンテナ仮想化技術が発達して、ある程度小さい単位のコンポーネント同士が、協調してシステムを構成するのが一般化してきている。
複雑化するコンテナのリレーションは、Kubernetesなどのオーケストレーション技術によって、容易に管理できるようになった。
昔より、ドメイン駆動設計の威力を発揮する土壌はできているはずなのに。
私の周りでは、コンテナオーケストレーションはおろか、Dockerすら登場しない。
３年目のときに疑問に思ったことは、ことごとく新しい技術が解決していっている。
特に、CI/CDなんて、ある程度の品質担保、デプロイ、リリースをプログラミングで実現できる手法だ。
コードを書くのが好きなエンジニアなのに、自分の作業を楽にするコードは書けないのか。
コンテナ技術も、インフラをコードで書いて構築する技術だ。
すべてコーディングできる。
コードは書いたとおりに動く。人間のやることが減る。
効率的じゃないか。
多層構造
ここに来て、私はもうこの業界が世の中の動向についていけていないのは、環境にあるのではないかと考えている。
トップダウン的に見て、コードを書いて作業を効率化することが、上の人にとって自分のこととしてメリットに感じられてない。
だから導入しない。自分の仕事を効率化するなら取り入れているはずである。
所詮、開発会社がシステム開発を請け負っている環境では、エンジニアの作業レベルの効率化はメリットに感じない。
そう思えて仕方がない。
これは批判ではない。
私が自らの立ち位置を客観的に観察した結果、感じたことである。
私はそう感じた。それだけ。
だから、別の環境に移らなくてはならない。
システム開発に見た夢は、きっと見ている場所が違うだけで、実は夢なんかじゃないのではないか。
そうやって、発起するに至る。
