【CTO室責任者】C# エンジニアとして受託から大手自社開発までPL経験を積み、スタートアップのプロダクト品質責任者になるまで
Profile
CTO室 責任者
畠山 圭佑（39）
新卒で入社した独立系の中小受託開発会社で、C# エンジニアとしてのキャリアをスタート。船舶や製鉄、金融系などの大規模システム開発プロジェクトでPLを数多く務める。その後、パーソルキャリア株式会社のダイレクトリクルーティング刷新プロジェクトのサブリーダーを務め、ネクスタへジョイン。
入社4年目からPLを経験 大規模プロジェクトを通して粘り強く学んだ受託開発時代
ー 現在、ネクスタのCTO室で責任者をされている畠山さん。新卒で入社された、1社目の受託開発会社での経験から教えてください。
1社目の受託開発会社では、新卒で入社してから13年間、エンジニアとしてさまざまなプロジェクトを経験しました。開発要員としては一番思い出深いです。
入社後3年間はプログラマーとして働き、4年目以降からSIerとしてプロジェクトを担当していきました。4年目あたりから、先輩エンジニアのサポートを受けながらPL（プロジェクトリーダー）としての経験も積み始めました。
ー 入社4年目でPLとなると、かなり早いのでは。
はじめのうちのPL経験は、会社としても育成目的だったとは思いますが、PLになれたタイミング自体は早い方だと思います。お陰様で、役職につく前からPLのキャリアを築いていけました。
ー その中でも、特に印象深かったり、今のキャリアにも活きていると感じたりするプロジェクトはありますか。
特に印象的だったプロジェクトが2つあります。1つは、PLとして一番多いメンバーをマネジメントしていた、船舶向けシステムのプロジェクトです。要件定義から携わらせていただき、自分を含めて8名のメンバーで開発を進めました。このプロジェクトでは、基本設計は170ページくらいにわたって作り込みまして、お客様から「ここまで細かく作り込む人は見たことない」と言っていただけました。
ー 基本設計で170ページ！あらかじめそこまで細かく設計されていたら、その後の詳細設計やメンバー配分もスムーズになりそうです。
そう思って頑張って書いたのですが、結果的にお客様にとっては「どこに何が書いてあるのかわからない！」とご意見いただいたり、仕様変更時にドキュメントを正しい状態に維持するコストも高くなってしまいました。総じて学びが多いプロジェクトでしたが、難しい案件を粘り強くやりきる経験にもなりました。これ以来、相手の立場で物事を考える癖が付いたのも学びかなと思います。
何より、このプロジェクトではエンドユーザ様から「エンジニアの役割はユーザの課題解決だ」という姿勢を叩き込まれました。
それまでは、設計書を作ったり、プログラムを書いたりすることが仕事だと思っていましたし、受託開発ではその姿勢でも会社の利益を出せてしまいます。そういう「作ることが仕事」という姿勢が見透かされたのか、「この画面デザインをあなたは使いやすいと自信をもって言えるか」「誰が使う想定で書いたのか」「言えないならなぜ改善提案をしないのか」といったご指摘をいただきました。今思えば、コーチングを受けていたのだと思います。エンドユーザはITをどのように考えているのか、エンドユーザがどうやって意思決定するかなど、お客様の視点を知ることができました。
ー 以降の、自社開発エンジニアとしてのキャリアでも役立ちそうな考え方ですね。もう1つの印象的なプロジェクトというのは？
もう1つは、僕の経験の中で一番大規模な、製鉄所向けのシステム開発です。700億円規模のプロジェクトで、C#の基盤開発から関わらせてもらいました。
ー そんなに大きなプロジェクトで、基盤開発から！
たしか、その年度の国内IT投資予算でもトップ10に入るような予算規模のプロジェクトでした。予算もさることながら、参画した基盤チームのレベルがとにかく高かったです。元請けの会社もこの案件のために社内で精鋭部隊を作ったのですが、そこにたまたまC#に強いエンジニアがいませんでした。その流れで、私が船舶系のプロジェクトでC#を使っていたこともあってか、お誘いいただきました。
ー 以前のプロジェクト経験を活かし、より大きなプロジェクトにチャレンジできる貴重な経験。いざ取り組んでみて、いかがでしたか。
船舶系のプロジェクトをやり切り、ある程度自信が付いた頃だったのですが、要求レベルが非常に高く自信がなくなりました。「WinFormsとFlexのそれぞれの採用時のメリデメまとめて」や「数十万件のデータを、API取得からグリッド上に表示まで3秒以内で実現する方法を検討してフレームワーク作って」等の、いわゆるアーキ選定やミドルウェア開発を初めて経験しました。「ITってアプリ作るだけじゃなかったんだなあ」と思いつつ、何とかこのレベルに食らいついていきたい、とがむしゃらにやりました。気づいたら2年くらい経っていました。
ー 2年間、レベルの高いプロジェクトを全力で走り抜けられたのですね。他にも、現在ネクスタで活かせている経験はありますか？
品質管理委員会に所属していた経験は、現在のネクスタでの品質管理業務に活きています。品質管理委員会の社内監査員として、自社のQMS（クオリティマネジメントシステム）をもとに開発の型や品質評価方法を決め、社内で実施してもらう活動をしていました。
品質を評価するためには、評価方法だけでなく、基準となるやり方も決める必要があります。やり方が決まっていないと、何を振り返ればいいかも不明瞭になってしまうので。それらの型や仕組みを決めて、PCDAサイクルが回せるようにしていました。この時に学んだノウハウは、今もCTO室での業務に役立っています。
受託開発から自社開発へキャリアチェンジ スキルを磨きながら大手企業の組織運営も経験
ー 幅広い経験を積み上げてきた受託開発会社から、パーソルキャリアに転職した背景についてもお聞かせください。
受託開発のビジネスモデルに疑問を持ち、自社開発に携われる大手企業で働いてみたいと思ったのがきっかけです。その頃はちょうどコロナ禍で色々考える時間があり、当時「IT・35歳限界説」のような言説があった中で35歳を迎えたのもあって、転職に踏み切りました。
船舶系のプロジェクトで「自分が在りたいエンジニア像」みたいなのが見えてきて、製鉄業界向けシステムでIT業界における座視が上がった中で、この経験を大手企業で活かしてみたいと思いました。
ー 実際に、パーソルキャリアでの仕事はいかがでしたか。
組織全体に良い方が多く、レベルの高いエンジニアの方とも出会えて、良い転職になりました。業務としても、さまざまなプロジェクトに携わらせていただきました。エージェントサービスの社内向け基幹システム「ARCS」の開発に携わったり、ダイレクトリクルーティング刷新の「プラスARCS」プロジェクトのサブリーダーをさせていただいたり。あと、インフラチームにもちょっぴり参加しました。
ー パーソルキャリアでも、数多くのプロジェクトにアサインされていたんですね。
パーソルキャリアは社内公募制度が整っていたので、自分からも応募していました。大手企業ならではの、社内制度がしっかりした環境で働くという点でも、良い経験になりました。スタートアップであるネクスタでも還元できる経験です。
ー スタートアップの組織作りのフェーズでは、大手企業の確立された制度下で働いた経験は貴重な意見となりそうですね。
そうかもしれません。実際に、ネクスタで開発組織の組織運営について意見を求められ、パーソルキャリアで働いた経験からアイデアを提供できることは今までも度々ありました。人事面だと社内評価制度の設計、もう少し身近な組織運営の話でいうと、エンジニアへの仕組みの周知方法など。エンジニアとしてジョインしたネクスタで、社内制度作りにまで関わることになるとは思っていなかったので、「こんなところで大手経験が役に立つとは」という感じでした。
ネクスタへジョインし、よりインパクトの大きい事業で更なるチャレンジを
ー パーソルキャリアからネクスタへ転職したのは、どのような理由だったのですか。
スタートアップという新しい環境でチャレンジしたかったからです。パーソルキャリアはあくまで人材会社で、システム開発の事業インパクトはどうしても限定的になります。もっと自分のキャリアを役立てられる環境はないかと、C# のスタートアップ求人を見ていたところ、ネクスタを見つけました。
ー その際、他の会社も比較検討していましたか？
転職を急いでいるわけではなかったので、情報収集程度でしたが、いくつかオファーはもらっていました。とはいえ、スタートアップにC# エンジニア求人はほとんどないので、そこまで選択肢はありませんでした。C# はレガシーな業界で使われるケースが多く、ネクスタのような新しい事業で使われることは少ないので。
ー スタートアップの転職には、不安はありませんでしたか。
スタートアップというと、バリバリ仕事ができる集団みたいなイメージがあったので、自分の力が通用するかは少し心配でした。でも、カジュアル面談で実際にソースコードを見せていただき、自分にできることがありそうだと思い、決断できました。選考中にQAエンジニアとして打診をもらった際は、品質管理委員会での経験も活かせそうだと思いました。
他にも、ネクスタがE2Eテスト作りをしたいと考えていて、そこを仕組み作りから携われるのは魅力でした。WindowsのデスクトップアプリでのE2Eテストは、製鉄業向けシステムのナレッジをそのまま活かせると思いました。スタートアップへの転職なので、もしスキル不足で開発についていけないとしても、ニッチな領域の強みを生かせられるのであれば何かしら役割はあるだろうという打算もありました。
ー ご自身の経験を活かせる役割があるのは大事ですね。実際にネクスタへジョインした後の業務内容についてお聞かせください。
はじめは開発部署の1チームであるQAチームとして、品質を担保する方法について議論する機会が多かったです。プロダクト品質を保つ方法はE2Eテストだけではなく、単体テストやAPIテストなど、いろいろあります。そのあたりも、ゼロベースで再検討しました。その後、QAチームがCTO室という部署として独立することになり、マネージャーの打診をいただきました。
ー CTO室マネージャーの打診は、すぐに受けたのですか。
いえ、打診を受ける前に、開発メンバーと話す時間を取りました。システムの品質改善はCTO室が頑張るだけではなく、開発メンバーも品質の意識を持って取り組まなければならないので、開発メンバーの考えも知っておきたかったからです。複数の開発メンバーと話して、これなら品質向上が見込めると思えたので、受けさせていただきました。
ー 納得したうえでCTO室の責任者になったのですね。CTO室が立ち上がってからの仕事内容についても教えてください。
CTO室の最も大きな役割は、品質担保・向上のナレッジ共有や仕組み化を通して、開発チーム全体をより高い品質で開発できる組織にしていくことです。そのなかで自分は、CTO室の責任者として、実際に作った仕組みやナレッジの共有、課題解決支援や開発メンバーへのOJTをはじめ、中長期的な開発アーキテクチャの刷新、プロトタイプ開発なども行っています。
ー 改めて、プロダクト品質に関わる重要な役割を担っていることがわかります。
弊社のスマートＦは、ちょうど小規模プロダクトから中規模プロダクトに成長している最中です。開発の複雑さや難易度の上昇に対して仕組化やガバナンスの浸透は急務だと感じています。今の時点で質の高い仕組みを築くことが、今後のIT戦略での選択肢の数に影響してくるので重要ですし、やりがいも感じています。
ー 組織作りにおいても、前職までの経験を活かせそうですね。CTO室のメンバーの業務はどのような感じですか。
CTO室では、各メンバーが異なる専門領域に関する業務を分業しています。チームプレイというよりは、各領域のプロフェッショナルが各職務に責任を持って取り組むイメージです。メンバーが増えれば、これらがチーム単位での分業になっていくかと思います。
ー そんなCTO室の組織運営において、気をつけていることはありますか。
専門性がある仕事は、外から見えにくくなりがちなので、こちらの情報を事実ベースでオープンに語れるよう心がけています。たとえば、中長期的に解決しなければならない問題に取り組んでいる時って、外から見たら何をしているかわかりにくいと思うんです。なぜ今この業務に取り組んでいるのか、それをしないとプロダクトはどうなりそうなのかなど、責任を持って説明するよう心がけています。
ネクスタには「数字で語ろう」というカルチャーがあるので、より数字も含めた事実で話せるようになっていきたいです。改善点を指摘する立場になることが多いので、面白くない話をしなければならないこともありますが、スマートＦをより良いプロダクトにしていくためにも誠実に取り組んでいきたいです。
ー 大変なミッションの中、邁進されている様子が伺えます。今後、CTO室をどのような組織にしていきたいですか。
専門性をもって、会社の事業成長に貢献できるプロフェッショナル集団にしていきたいです。専門性があるだけではなく、それを何かしらの形で役立てられる人がプロフェッショナルだと考えているので、そんなメンバーが集まったプロフェッショナル組織にしていきたいです。ネクスタのようなスタートアップにこそ、プロフェッショナルが必要だとも思います。
ー 最後に、畠山さんはどんな人と働きたいですか。
「エンジニアとして一周した人」と働きたいです。「スキルを磨きたい」「キャリアを伸ばしたい」「安定した職場」という人には、もっと大手のIT企業やメガベンチャーが制度も整っていますし、自分の時間も作れるので向いていると思います。
そういう座学や研修から学べるものが少なくなっていて、食いっぱぐれる危機感もないけれど、チャレンジャーでいたい。そういうエンジニアにとってネクスタは恰好の遊び場だと思います！
ー 貴重なお話、ありがとうございました！
★株式会社ネクスタでは一緒に働く仲間を募集しています