COBOLからJavaエンジニア──新天地を求めてKeepAliveへ

▲ DevOpsグループ 祷あゆみ

私は大学が理系の学部で、ものづくりや考えることが好きなタイプです。一方で、人を管理したりネゴシエーションをしたりするのは苦手だと思っていました。そんな自己分析を踏まえて就職活動をし、新卒で大手SIerに入社しました。

クライアントは大手通信系企業で、汎用機系のシステム開発、COBOLが中心。そこで経験したプロジェクトは、同じ会社の人が10~30人ほど、元請けや協力会社のSEを含めると50人規模の編成でした。

COBOLが中心だったものの一部Java化があり、そのときに勉強したことがJavaに興味を持つきっかけになりました。

実はそのプロジェクトが終了するタイミングで、汎用機からLinuxシステムへのリプレイスプロジェクトに異動したいと思っていました。しかし、会社がその案件を受けなかったので希望がかないませんでした。ホストのオープン化構想に対する提案を行ったものの、プロジェクト自体がなくなってしまい、それならば新天地を求めようと転職活動を開始しました。

その過程で出会ったのがKeepAliveです。市場におけるKeepAliveの立ち位置や特徴について調べていく中で一番魅力に感じたのは、当時はまだ構想段階のDevOpsでした。

オープン系・Javaを扱っている会社は他にもたくさんありました。しかし、その中でもSpringBootを使っている点やアーキテクチャに重きを置いている点、自動化などの先進技術に触れられる点が楽しそうだと思い魅力を感じました。

ただ、前職で経験したプロジェクトがひとつだったことと、会社が大規模すぎて全体を俯瞰できなかったことはネックになるかもしれないと不安もありました。

しかし、前職の現場できっちりテストをやっていたことや、他人の書いたソースコードを修正していた経験は自分の強みだと思い直して、面接に挑むことにしました。前職ではかなわなかったことから、会社全体を俯瞰して見たいという想いもありました。それも、小規模であるKeepAliveを志望した理由のひとつです。

KeepAliveに入社して感じた“違和感”こそDevOpsだった

▲ 開発リードの成田 敦にアドバイスをもらうことも

入社してから、前職とKeepAliveの仕事のやり方の違いはさまざまな部分で感じましたし、KeepAliveでのものづくりで「変だ!」と思った点もいくつかありました。

具体的には以下の点です。
1.テストをあまりしない
2.違う言語で分業されている(JavaScript/PHP/Java)
3.ドキュメントが少ない

「変」という感覚はなんだろう…。はたして、世の中が変なのか私が変なのか?変だと思うことが変なのではないか?と思いを巡らせていくうちに、ふと理由があることに気付きました。

それは、KeepAliveは効率化を図るために冗長な作業を減らしているということでした。その反面、有益な作業に関してはとことんやっていることにも気付きました。工程の中の作業一つひとつにメリハリを付けているということが、段々とわかってきたのです。

入社後は、毎日が新しいことの連続でした。たとえば、 ER図を書いたのも初めてで、「本当にこのやり方でいいのかな?」と不安に思うこともありました。でも、心配する私に対して上司と先輩がすかさずフォローしてくれましたし、丁寧に説明してくれるので大丈夫でした。

DevOpsの開発手法は、「パラダイムシフトを受入れDevOpsエンジニアに進化―若手エンジニア1年の軌跡―」で紹介していた通りエンジニアの桜井さんが固めてくれたもので、その手法にもだんだんと慣れていきました。

このように挑戦と試行錯誤を繰り返しているうちに、あっという間に入社から1年がたちました。KeepAliveという組織やDevOpsをベースにした仕事のやり方やJavaにも慣れてきたころ、「新規の開発プロジェクトをアジャイルで進めろ」という指示が降りてきました。

ウォーターフォール思考のアレルギー反応がアジャイルの壁に

▲ スクラムマスタとして会議をファシリテートしている

そのプロジェクトは、中古流通業の物品買取から店頭へ並ぶまでの基幹システムの刷新プロジェクトでした。5つのサブシステムに分離していたシステムをひとつの基幹システムにまとめるというもので、バリューチェーンが一気通貫するように設計しなければなりませんでした。

業務要件上、機能ごとの追加項目が多いため、「ユーザーからのヒアリング」「素早くシステムをつくり上げて改善」を繰り返し、完成度を高めるというアプローチを取る必要がありました。そして、そのアプローチはウォーターフォールでは難しく、アジャイルが適しているという判断でした。

アジャイル開発手法のひとつであるスクラムは、途中で要求や必要事項を変えられることが基本原則です。

しかし、プロジェクトにはウォーターフォール思考の人たちがたくさんいて、要件変更や仕様変更というアジャイルでは当たり前のことも、「変更」という言葉だけでアレルギーが出てしまう状況でした。

きっと、アレルギーが出た人たちは、いつもと違うことを「変」だと思ったのでしょう。それは、私が入社後に経験した「変」と同じだと思いました。それに対して根気強く説得して回り、アジャイルの基本的な精神に立ち返って考えてもらう活動を粘り強く行っていきました。

そんな人たちと心をひとつにできたのは、「アジャイル宣言の背後にある原則」をみんなで読み上げたときです。なんのためのアジャイルなのかが理解できました。

また、プロジェクトメンバーが、私を後方からサポートしてくれたことも心強かったです。「本件をアジャイルでやり遂げよう」という共通認識のもと、スクラムに対して前向きに取り組むことができました。

こうして、少しずつ自分を含めてチームの理解も深まり一体感が増していったのです。

スクラムマスタはエンジニアのキャリアパスとして良い選択肢のひとつ

▲ 女性同士の勉強会の様子

初めての試みであり、チャレンジングなプロジェクトもリリースまであと2カ月というところまできています。通常リリース間近は仕様が凍結されがちですが、アジャイルの本領を発揮して、仕様変更に柔軟に対応しています。

私が以前から好きだった、ものづくりや考えることは今も変わらず楽しめています。ただ、このプロジェクトを経験して、チーム運営の楽しさを新たに見つけることができました。

これまで、プロジェクトマネージャーになる将来像はあまり考えていなかったのですが…。

しかし、今は、顧客も巻き込みながらチーム一体となって価値の最大化を目指し、全体を支援する役割のスクラムマスタに楽しさを感じています。

エンジニアのキャリアアップ先としていいポジションだと思いました。

一般的に、リリースしたシステムの初期メンバーは解体になることが多いです。しかし、本件はリリース後もDevOpsとして資産価値の向上を目指すため、これからもスプリントを回し続けます。