これまでのご経歴と、ラクスに入社を決めた理由、背景等を教えてください。

始めてITエンジニアを目指したきっかけは幼稚園の頃におじさんが持っていたファミコンとの出会いでした。はじめてやったゲームは『グラディウス』だったはず。自分の操作でTVに映る映像が変化することを面白く感じてた気がします。なので最初はゲームクリエイターになりたくて、小学生の頃は自作のアナログゲームを作ったりして遊んでいました。

中学生になると明確にプログラミングを仕事にしようと考え始めて、高校で本格的にプログラミングを始めてC, Perl, COBOL, Fortran, Java, Pascalなどの言語を覚えました。大学卒業後、独立系SIerに入社しオンライン証券システムの開発にてプロジェクトマネジメントを中心に経験しつつ上流から下流までの開発工程全体を経験。その後10人規模の検索サービスベンチャーを経て、2013年にラクスに入社しました。

ラクスに入社したのは受託開発によるワンオフ製造ではなく、作ったものを多くの人に利用してもらえるという点がソフトウェアの強みであると感じるようになっていたため自社でWebサービスを展開している会社に絞って探していたことと、まだラクスがそれほど大きくなかったことと新規サービス（楽楽明細）の立ち上げ期で裁量が得られそうだったこと、事業経営そのものが順調で毎年増収増益を続けていたことが決め手で入社しました。

入社以降に関わったプロジェクトと、そこでの役割、業務内容について教えていただけますでしょうか。

ラクス入社時は楽楽明細がサービスインする2ヶ月前でした。もともと社内での利用に特化していたサービスを汎用的に作り直している真っ最中で、サービスインのあとも世間で一般的に利用されている販売管理ソフトのデータ構造と楽楽明細に採用されていたデータ構造のギャップを埋めるために、販売管理ソフト各社のマニュアルを読んで設計したりしていました。それからしばらく楽楽明細の機能開発を行いつつ、営業同行でお客様先で仕組みの説明したり、お客様からの技術的な質問に回答したりといったことをしていました。

また2017年からはかみせんプロジェクト（のちの技術推進プロジェクトの前身）の初期メンバーとして今後導入する技術の先行検証業務も開始しました。ちなみに「かみせん」とは、開（か）発の未（み）来に先（せん）手をうつ、の略です。

「しばらく新サービス作られていないなぁ」と思っていた頃に楽楽労務（現在は販売終了）立ち上げの話があり、アーキテクチャ部分の検討に参加しました。実際の開発は新たに採用したエンジニアが担当するということで進めていたのですが、結局採用がうまくいかず大枠が揃うくらいの初期開発まで参加することになりました。

その後は開発管理課という開発部門を横断的に改善するための部署に異動となり、楽楽労務開発中は中断していたかみせんプロジェクトが再開すると共に検証業務に復帰、さらに継続的なプロジェクトとして認められ技術推進課の発足とともに異動し、プロジェクト名も技術推進プロジェクトと改名されて今に至ります。

各役割の中で、どのような課題があり、どのように取り組んでこられましたか？

楽楽明細での開発を行っていた頃は顧客も少なく1件でも契約を増やしたい時期ということもあり、特定顧客にのみ必要な機能でも機能要望として挙がってくる時期でした。売上が上がらないとサービス継続できない反面、使われない機能を作り込んで今後の運用コストを増やしてしまわないように判断するというところが難しいところでした。

また、技術推進プロジェクトでは検証に半年から1年をかけることと、開発計画が年単位で計画されることを考慮すると、実際に各サービスが利用する2～3年前に検証する内容を決めて取り組まないといけないのですが、2年後の必要性を読むことと、検証してから2年程度は実際のサービスに活用されないという状況で成果を求める圧力に抵抗する必要があるのが苦労するところです。

これまで～現在に至るまで、どんな時・どんな点にやりがいを感じてきましたか？

やりがいというかやってよかったと感じていることは、ラクス社内にコードレビューとビアバッシュの文化を根付かせることができたことです。ビアバッシュは、業務後に軽食をつまみながら好きなテーマでLTを楽しむ会のことです。

2013年の入社当初は担当した楽楽明細ではもちろん、他のサービスでもコードレビューが一部を除いて行われていませんでした。当時から私自身はコードレビューがないプロダクトコードに恐怖を感じるようになっていたので、早々にチーム内にコードレビューを導入しました。おそらく社内で一番最初に楽楽明細がコードレビュー100％を達成したサービスになっていたと思います。現在ではもちろん他サービスでもコードレビューが当たり前のように実施されています。

またビアバッシュについては発起人自体は別の方だったのですが、ビアバッシュを東京開発組織で始め異なる部署（現在のラクスパートナーズの前身組織や大阪開発）にも拡散させることができました。2014年頃だったと思いますが、この頃は年間で40回くらいLTを行っていました。最近はコロナで長らく休止していましたが、少しずつ再開し始めています。

技術推進課の目的・役割を教えてください。

技術推進課は主に技術推進プロジェクトというプロジェクトの運営を行っています。

技術推進プロジェクトでは日々の開発業務により、後回しになりがちな仕組みの刷新を少しでも進めるために今後必要になりそうな技術要素を先回りして検証しています。技術推進課ではどんな技術要素をいつごろ検証するべきか、誰に検証してもらうか、といった項目を開発メンバーからの意見を収集しつつ計画しています。

普段の業務は前年度に定めた技術要素の検証作業を進めつつ、並行して翌年度の検証計画をたてていくことが主な業務となります。

検証する技術要素の選定思想は「B2Bサービスの長期運営を見据え、開発の仕組みそのものをアップデートし続けるための技術」です。経費精算や請求書発行など、お金が絡み正確さを要するアプリケーションを効率的に開発するため、テスト自動化やセキュリティ、ミドルウェアなど、パフォーマンス改善やソフトウェア観点で高品質を実現する技術を選定することが最近は多くなっています。

直近では上記に加え、コンテナを活用した効率化技術に注目しています。現在各プロダクトで手作業を含めて個別運用されている構築フローを標準的なフローに刷新していくことで、SREの取り組みが進めやすくなったり、新しく参画される方へのオンボーディングも行いやすくなると思います。

技術推進の取り組みで、プロダクトでの利用事例があればご紹介いただけますか？

ドキュメントDB活用の検討においてRDBのドキュメント型とドキュメントDBのどちらが有用か検討していたことがありました。技術推進プロジェクトで検証した結果、ドキュメントDBにて無停止でのバックアップができないことが判明していたため採用しないという判断を行いました。このように新しいものであっても必ずしも要件を満たすわけではなく、満たすことができない要件を明らかにしておいて、採用しないという判断にも役立てています。

他にも存在する課題に対して、課題を解決できそうなプロダクトがどのような課題を対象としていて、どのように使うことになって、エラー発生時やリトライ処理の考え方など、といったプロダクトレベルで考慮しなければならないことを事前にまとめておくことで、実際に導入を検討する際の効率化に役立てています。

ご自身の今後の目標を教えてください。

ITエンジニアとして職歴が長い人は、エンジニアとして続けていくかマネジメントの道に切り替えるかといった人が多いかもしれませんが、プロジェクトマネジメントについては20代である程度経験したので、技術スペシャリストを志向していきたいと思っています。

職歴としてはずっとウェブアプリケーションエンジニアとしてキャリアを積んできましたが、ITバブル、Web 2.0あたりの時代でウェブアプリケーションが盛り上がってから約20年が経ちました。ウェブアプリケーションが廃れるような気配はまだまだありませんが、そろそろ次の技術トレンドを見越して取り組む動きもしていきたいと思っています。それがウェブアプリケーションの延長線上なのか、それ以外のものなのかは模索中ですが。

オフタイムはどう過ごされていますか？

オフかどうかわからないところから行くと、会社ではサークル制度を利用して工作系サークルの部長をやっています。プラモデルや粘土工作などを有志で楽しんでいます。部長としては購入する参考書の選書や、道具類の調達などを中心に快適な制作環境づくりを進めています。

他にはゲームづくりや写真展示を行っています。ゲームづくりはIT関連のネタをモチーフにしたアナログゲーム制作を2016年から同人サークルを立ち上げて行っています。発表済みの作品としてはカラーコードかるた、要件定義ブラックジャックといったものや、2022年の新作では最近AI関連の演算を効率的に行えることで注目されているINT4（4ビット整数）での2進数演算速度を競うゲームを制作しました。
写真はだいたい年1回くらいのペースで展示発表しています。最近ではJR関係の施設や、杉並区役所ギャラリーで展示していました。個展も10年以上やってませんが、そろそろまたやってみたいと思っているので、必要な作品点数が揃うように撮っていきたいです。