arveltのソフトウェア技術メモ

Arvelt's software technology memo

SIerを退職し、Web系に転職しました。アフター

銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することにしました という記事を書いたところ、想像以上の反響がありました。 それから一年経ったので、その後のことなど書いていこうと思います。

 

1.変わったこと

2.変わらなかったこと

3.これから

 

1.変わったこと

COBOLとJavaAppletを書いていたかつてのシステムエンジニアはフロントエンドエンジニアになった

それっぽく言ったけどjavascriptを書く人になったということですね。今の会社はGoogleApps上でのクラウドサービスを提供していてサーバーをGAEで書いています。私はjsで書かれたフロントを主に、たまにpythonで開発をすることになりました。

 

・仕事へのモチベーションは上がった

受託で常駐で、というかつてのビジネス構造的から発生していた理不尽さが減りました。github閲覧できないとか。紙と印鑑ありきのフローであるとか。

 

・出社時間を強制されなくなった

名目ばかりではない裁量労働制になっているんだなあと思います。

 

・会社でブルックスのコーヒーがおいてあって好きに飲んでいい

大したことない感じするかもしれないが案外こういうのが日々のやる気につながってくるのだと知りました。ところでみなさんレッドブルとかは本当に今この瞬間だけがんばりたい、という時以外は飲まないほうがいいですよ。

 

Windowsの世界で生きてきたからMacというかUnixを使うのは大変だった

右クリから空のファイル作ったりできなくてつらいとか、SSどうやって撮るのとか、そもそもこのコマンドボタンというものは一体なんなんだ?とかありました。そして開発に関する作業は結局ターミナルからやるのがいいのだと思い至ります。昔はCOBOLコンパイルするときくらいしか黒い画面触らなかったものなのですがね。ただしエディタはIDE

 

・昔のような方眼紙の設計書はなくなった

もちろん設計書自体がないわけではなく、プログラムの処理を日本語で書いたいわゆる詳細設計書がなくなりました。納品とかありませんし。 ドキュメント的に残すのはサーバーはAPI仕様、クライアントは特にまとまったものはなく、あとはソースとかモデルのコメントみてね、という感じです。最初は何から手を付けていいかわからなくて途方に暮れましたが、慣れると案外なんとかなります。小さく始める、を地で行けるやり方です。

 

・スケジュールだけが決まっている開発、が基本なくなった

アジャイルっぽくやっているおかげで、ストーリーとそのベロシティで線を想定しています。もちろんリリース先ぎめの物も存在しますが、その時は機能のスコープで調整します。あっこれアジャイルサムライで見たやつだ!ってなりました。

 

ユニットテストとCIをするようになった

業務でユニットテストを書くようになりました。今までどうしてそういう現場がなかったのかと思っていましたが、ユニットテストは設計時に予めそうできるような構造しておかねばいけないのであり、そしてその技術はしっかり考えて身につけるべきものであって、なんとなくでできるものではないのだ、ということがわかりました。だから今まではそういう現場に出会わなかったのでしょう。 ユニットテストがあるので、デグレしていない証明のために全てのテストパターンを手動で1週間かけてやるというようなこともしなくてよくなったわけです。自分の書いたコードが既存の仕様を壊せばJenkinsから通知が来るのですから。

 

・手動でぽちぽちしてExcelにSSを貼るテストはやらなくなった

ユニットテストを通してあるため、手動でやるのは実際のストーリーに沿ったところだけで済みます。いわいるシステムテストのレベルです。

 

・総じて、開発時に感じる理不尽さや非合理さは以前より減った

コードで解決できることはコードで解決しようという方針が実践されていて、これがプログラマなんだなぁという気持ちになりました。

 

2.変わらなかったこと

・残業

リリース前には忙しくなり、帰るのも遅くなります。これは想定済みですし、慣れてもいるので特に所感は湧きません。

 

・絡まったスパゲッティのようで誰も手が出せないが重要なので使わざるをえないレガシーコード

想像はしていたしまあそうだよね、という感じです。でもそれが問題だと認識する素地があるし、なにかにかこつけてリファクタしたり、あわよくば作りなおそうとしていて大変よいと思います。

 

・勉強しなくてはいけないということ

覚えなくてはいけないことが多すぎてこれはもはや死ぬしかないのではとと思っていましたが、自分の及ばない部分にまで無理に手を出すのがいけないのだと気づきました。まず今業務で使っているものを理解する、しかしそれを完璧に理解しようとすると死ぬのでほどほどにする。次にその周辺を理解する、しかし完璧に理解しようとすると以下略。さらに流行りもの。しかも完璧に以下略。なのです。スーパーハッカーばかり見ていたので勘違しかけていましたが、普通の人は普通の人なりに生きて行くのがよいのです。

 

・給料

金額自体はちょっと上がったような気もしますが、かつての銀行系列子会社の福利厚生も考えるときっと下がっているでしょう。

 

・将来

かつては曲りなりに用意されてたPG→SE→PMというキャリアパスはもはや関係なくなりましたので、将来のことはわからなくなりました。

 

3.これから

変わったことと変わらなかったことも踏まえて考えると、きっと私はこの転職をしてよかったのだろうと思いました。とはいえ今もあのCOBOLJava基幹システムやC#Excelの業務システムを保守している人達がいるのですから、私にはできなかったことをする彼らには敬慕の念が止むことはありません。ただきっと私には合わなかったのなのだろうと思います。それに気づくのに6年かかってしまいましたが。

 

私は今年で30才になります。とても若いとは言えない年なのですから、これからどういうふうに生きていくのかも考えなくてはいけません。 ただコードを書くだけなら、アルバイトにきている学生の子の方ががよっぽどよくできます。 私はコードを書ける上に、さらに◯◯がわかる、◯◯ができるにならなければいけません。かつてのようにシステムエンジニアだったのなら、それは業務知識だということになっていたことでしょう。会計、流通、生産、在庫。 しかしもはや特定の業種の特定の業務に精通するすべはないし、するつもりもありません。私はコードを書くことでどんな問題を解決できるようになるべきなのでしょうね。 よくあるゼネラリストスペシャリストの区分ならスペシャリストの方がイメージしやすいです。いずれかの技術の領域に詳しい上に、それを自社のプロダクトにどう活かすのか、という考慮ができる人。そのプロダクトがなんなのかについてはきっと限定させない方がいいとは思いますが。

 

とはいえこれと決めてかかってそれしかやらないのも視野狭窄だと思いますし、日々の興味の先にあるものにしなければ破綻することは経験から学びました。そういう要素になりうるものを日常的に意識しなくてはいけないのだと今では思っています。

 

あまりハードよりには興味が向かないことが判明してきています。アプリケーションのよい設計とはどういうものか。保守しやすいコードはどういうものか。どんなドキュメントがあるべきなのか。どういうテストをするべきなのか。品質とはどういうことか。そういうことに興味が向いているのかもしれないと思い始めています。おそらく昔苦しめられたから。

 

でもそれはテストエンジニアになりたいのか、と言われるとと少しちがっていて、私が作ったアプリケーションが不具合や不都合がなくユーザーに対して最大限利益を与えるためにはどうすればいいのか?ということを突き詰めるべきだと考えるのがしっくりきます。 何もかっこよい意識高いアピールのために言うのではないのです。そうすれば、「私自身が最も外部から煩わされない」状態になるに違いないからです。非常に利己的な理由です。だから信じるに値する目標なのです。つまり、これを言葉にすると、「アプリケーション開発のスペシャリスト」になるのかもしれません。一気にうさんくさくなってしまいますが。

 

ところで転職以前の当時の自分のツイートなんかを見なおしてみると。当時まったくその気はなかったです。なかったののですが。どうみても病んでますねこれ。気づかないものですこわい。 かつて私は、情熱の炎を燃やすために危機感をくべました。だがそれもいずれ燃え尽きるときがきます。そのとき私は何を差し出すことになるのでしょうか。