こんにちは。Finatextホールディングス 広報担当、ミヤカワです。
Finatextグループのメンバーを紹介していく社員インタビュー、今回はFinatextのソリューションアーキテクト、塚本さんにお話をうかがいました！

塚本 幸嗣 – ソリューションアーキテクト

CNET Japan（現 朝日インタラクティブ）や日本技芸（現 rakumo）など数社でプログラミングの経験を積む。2017年1月に株式会社Finatextに入社し、プロジェクトマネージャーやコミュニティ型株取引アプリ「STREAM」の開発を担当。2020年からはソリューションアーキテクトとして、ベトナムのオフショア開発チームと連携し、金融機関の自社ユーザー向けサービスのシステム開発を担う。
趣味は、スノーボードとキャンプとサウナ。

Finatextにおける「ソリューションアーキテクト」とは

– 入社間もない頃の塚本さんのインタビュー記事、拝見しました。Finatextに入るまでいろいろな会社で開発経験を積まれてきたんですね。

はい。自分で手を動かしてプロダクトを作るのが好きで、複数の会社で幅広い技術を学ばせてもらいました。

– 入社理由などはぜひ前回の記事を読んでいただくとして、今日は「ソリューションアーキテクト」の仕事についておうかがいしたいと思います。さっそくですが、Finatextにおける「ソリューションアーキテクト」ってどんな職種なのでしょうか？

もともと「プロジェクトマネージャー」という名称で募集していたのですが、この名称では僕たちが期待している内容をきちんと表現できていなかったんです。Finatextでいうプロジェクトマネージャーって、進捗管理とかマネジメントだけでなく技術的な要素についてもけっこう知っている必要があって。例えば、お客様との打ち合わせで尋ねられたことに対し「技術的なことについては持ち帰って確認します」とか「次回エンジニアを連れてきます」というスピード感ではダメで、その場で返答できて信頼を得なければならない。大手のSIerでプロジェクトマネージャー経験のある方が応募くださったりしていたのですが、もうちょっと技術的なことがわかる方を求めていました。そのことが「プロジェクトマネージャー」では伝わらないと気づき、「ソリューションアーキテクト」と呼ぶことにしました。

– お客様のカウンターパートとなる人にも技術的な知識が求められているんですね。塚本さんは、Finatext入社以来、ずっと「ソリューションアーキテクト」的な役割を担ってきたんですか？

実は、以前のFinatextでは「エンジニア自身がお客様と直接話してタスクに落とし込むことができればプロジェクトマネージャーは要らない」という考え方で全員の認識が合致してたんです。僕もエンジニアとして採用されました。ただ、ちょうど僕が入社したくらいのタイミングで大きめのプロジェクトを受注し、開発をオフショア（現 Teqnological ）でやることになり、要件をまとめる担当者が必要になったのとお客様の要望もあって、プロジェクトマネージャーという立場で動くことになりました。以前在籍していたウェブ制作会社で顧客対応も開発も一通りやっていた経験が買われたのかなと思います。自分としても、お客様が思っているほど重要ではないタスクを削るなどして短納期でもきちんとデリバリーしたいという思惑があって、そのロールを受けました。

– そんな経緯があったのですね。今は具体的にどんな業務をされているのですか？

案件によって業務内容が変わりやすい職種なんですけど、今はお客様へのヒアリングとドキュメント作成が多いですね。今回のお客様はウォーターフォールを強く希望されているので、最初の要件定義が非常に重要。要件をヒアリングして固めてドキュメントに落としていく工程を、かなり詳細まで詰めています。ヒアリングの中でお客様が見落としていることに気づいたり、複数社が絡む案件なのでタスクが宙に浮いてないかとか、不確実なことは無いかとか。

サービスはAWSなどのクラウド上に構築することが多いのですが、お客様のリテラシーに合わせてアドバイスしながらこちらの提案も早めに伝えたりしてます。インフラやAWSの知識を持ってる人が来てくれたら、かなり強いと思いますね。最初に各工程のスケジュールについてお客様ときちんと握っておくことで、プロジェクトの進行に余裕を持つことができます。もしこれがプロジェクトマネージャーとエンジニアとで分かれていたら、確認だけでタイムロスだろうなと思います。

– 技術的に必要な工数やリソースがわかっているから、それを考慮に入れてお客様とスケジュール調整ができるというのはプロジェクトにとって大きなアドバンテージなわけですね。

はい。お客様側のエンジニアがどれくらいのスケジュール感でやってるかも見えるので、それに合わせてこちらの開発ペースを調整することもあります。お客様としては「こんなの1週間あれば十分」という認識でも、実際は1ヶ月かかったりすることもあって。その感覚がわからないと、多分引き受けちゃうと思うんですよね。お客様が「作りたい」という機能があったとしても、なぜそれが要るのかを掘り下げていくと意外と要らなかったりする。もし期日までにリリースすることがゴールなのだとしたら、いったんここは見送れるんじゃないかとか、そういう話もできるのは強いかなと思います。

– ソリューションアーキテクトって、プロジェクトマネージャーとエンジニアの中間みたいな存在なのかなと思いました。そういう仕事に面白みを感じる方というのは、どんな方なのでしょう？

僕自身はエンジニアから来てるんですけど、エンジニアの中でも35歳ぐらいでもう技術的にも体力的にも若い人に追いつけなくなってきたからマネージャーやろうかな、みたいな人は、ちょっと僕ら的にはあまりうれしくないかなと。どちらかというと、エンジニアとして手を動かすだけじゃなく、このプロジェクトが成功するためにどうすればいいかを考えてしまうような人。技術は他人に任せることになるけどプロジェクト自体を円滑に回すにはどうすればいいかみたいなことをエンジニア視点で考えていた人がいれば、一番いいかなと思ってます。

– エンジニアの視点を持ちつつ、プロジェクトを成功させることにコミットしたいタイプの人が理想？

そうですね。「新しい技術でコードが書ければいい」っていうエンジニアもいるんですが、プロジェクトを成功させて、お客様のユーザーやPVが増えたとか、そのへんにコミットできる人がいいかな。

– 言える範囲でいいので、今のプロジェクトについて教えていただくことってできますか？

とある新しい金融サービスのプロジェクトで、フロント部分を開発しています。お客様が「フロント部分はちょっと面白い切り口で作りたい」ということで、Finatextが採用されたかたちです。

ちょっと話が逸れますが、Finatextは「金融版AWS」とも言われるBaaS（Brokerage as a Service）に注目いただくことが多いんですけど、フロント開発もけっこうお客様からの引きが強いところがあって。そこはディレクターやプランナーが誇りを持ってやってるところでもあるので、社内外のプレゼンスがもっと上がればいいなって思ってます。

チーム編成に合わせて多様なロールを担いながら、ベトナムのエンジニアチームと一緒に新しい技術にもチャレンジ

– 今のチームについても簡単にご紹介いただけますか。

今やってるプロジェクトは、ソリューションアーキテクトが私を含めて２人、ブリッジ SEが２人、ディレクターが３人、デザイナーとプランナーがそれぞれ１人ずつですね。

– 大所帯ですね！

今のチームはそうですね。僕もこんなにたくさんのメンバーと一緒に働いたの割と初めてかもしれないです。チームの仲も良くて。今までにないですね、会社で働いててこんな仲良いの（笑）。チームメンバーはプロジェクトのレベル感や規模に合わせて編成されるので、もっと少数精鋭でやることもあります。案件によって動き方がかなり変わりますね。

– 案件によって様々な役割を担う可能性があるということは、「私はこれが専門だからこれしかやらないです、他の人アサインしてください」みたいなスタンスの方は、ちょっとつらそうですね。

僕はインフラエンジニアではなかったけど、あるプロジェクトのために勉強してインフラ周りを自分で構築しましたし、必要なら契約書や見積書を作ったりとかもします。確かに、あんまり自分のキャリアにこだわってるとつらいかもしれない。

逆にいうと、新しい案件ばっかりなんで新しいことにチャレンジしやすいと思います。例えば、（ベトナムでオフショア開発をしている）Teqnological のエンジニアが「新しい技術を使いたい」というのを吸い上げて技術の選択肢を確保してあげたりして、自分も新しいことができる状況を自分で作ってますね。

– へえ！それはすごく魅力的ですね。

BaaSのエンジニアから羨ましがられることもあります（笑）。

今の僕はエンジニアとしての開発はバリバリできないけど、ベトナムのチームの皆には何か新しいことをやらせたい。その方が彼らのモチベーションにもなるから、お客様と話す前に次何をやりたいかとか注目してる技術を聞いてます。あんまり突飛過ぎるのは怖いんですけど、ある程度実現できそうで、かつお客様に許容いただけるようなものであれば、提案して採用いただいてますね。

Teqnological はもともとスマホアプリ開発がメインの会社で、サーバーサイドの言語のバリエーションはさほど多くなかったんですけど、KDDI様の「au WALLET アプリ（現 au PAY アプリ）」の「お金の管理」機能の開発でBaaSと同じGo言語を使う必要があったので、ちょっと時間を作って2ヶ月ぐらい勉強してもらいました。皆とても勉強家で、最初は自分が教えてたんですが、今では教えられる側です（笑）。

（ベトナムチームとのやりとり）

泥臭さも醍醐味のうち。スクラムで学んだ組織心理学的なアプローチを活かして、チームやお客様との信頼関係を築く

– 今までのお話の中でその片鱗は見えている気がしますが、改めて「ソリューションアーキテクト」の醍醐味ってどんなところでしょう？

醍醐味であり大変さでもあるのですが、エンジニアに比べて泥臭いことが多いですね。プロジェクトを自分の進めたいように進めるには、お客様と頻度高くお会いして人間関係や組織構造をよく理解する必要があります。昭和的かもしれないですが、お客様がお酒好きであれば一緒に飲みに行って信頼関係を築くのも大事です。自分の能力や頑張りとは無関係のところでプロジェクトが中断することもありますし、人間関係で大変なこともあれば人間関係で救われる部分もあります。エンジニアってこういう人付き合いを好まない人が多いですが、好きな人なら割と楽しいと思います。プロジェクトマネジメントの中でも、組織学や心理学的な側面に興味ある人とかだと、けっこう面白いんじゃないかな。

実は昨年、スクラムマスターの認定研修に行ったんですね。

– えっ、そうなんですか！

はい、当社ではまだ実践できてないんですけど。スクラムの中に「チームを外圧から守る」っていう考え方があって。その闘い方の話の中に、組織学や心理学的な要素がありました。僕の場合、そこで理論的に学んだことがお客様との折衝やプロジェクトの進捗管理にも活かされています。

– スクラムに興味あるエンジニア、多そうですね。

多いですね。弊社内にもいますし。人をシステムに見立てて手を加えて調整していくみたいな考え方はけっこう面白いかなと。

– で、塚本さんはスクラムマスターになったんですか？

なりました！会社に研修費出してもらって資格取れなかったら、（CFOの）伊藤さんに何言われるかわかんなかったんで（笑）。

スカウトサービスでエンジニアを探すときも、「スクラムマスター」で検索したりします。お客様の言うことって変わりやすいのですが、スクラムはゴール設定がけっこうシビアなので、そのへんを詰めていけるようなマインドセットを持ってるんじゃないかと期待してます。

– 少し切り口を変えて、どんな時に「ソリューションアーキテクト」をやっててよかったなと感じますか？

僕の場合はお客様と接する時間が長くて、リリース後にお客様とご飯食べたり遊びに行ったりすることもあるんですけど、そういう時に「あなたが担当でよかった」とか「技術力が高かった」「Finatextにお願いしてよかった」みたいなこと言われるのがすごくうれしいですね。そういう声を直接聞ける立場にあることがうれしい。仲良くなって一緒にサウナ行く人もいたりするんですけど、そういう人間関係ができた上で評価をいただけるのは、本当にうれしいです。人が好きなんだと思います。

あと、ベトナムチームの存在ですね。新しい技術で、理論上は動くけどまだ検証されてないものを皆であーだこーだやって何とか動いた時には、言葉は通じないけどめちゃめちゃ感動します。僕はそういうのが多いかな。

プロジェクトの成功率を1%でも上げるために一緒に頑張ってくれる人と働きたい

– そろそろインタビューも終わりに近づいてきたのですが、「こういう人と働きたい」というイメージはありますか？

僕がいつも思ってるのは、「プロジェクトの成功率を1%でも上げたい」ってことなんです。今までたまたまうまくいってるだけかもしれないし。その確率を上げるために、ロールにこだわらず一緒に頑張ってくれる人がいいですね。チームが今とてもいい感じなので、メンバーとうまくコミュニケーションできて責任感が強ければ、多少エンジニアのスキルが低くてもそこはカバーできると思います。スキルを伸ばすためのサポートはいくらでもしますが、コミット力とかマインドセットってなかなか伸ばせないので、そこさえ備わっていればあとは何とでもなるかなと。

ごく個人的には、最初から「ソリューションアーキテクト」という道を歩んできた人と一緒に働いてみたいですね。僕はソリューションアーキテクトを目指してきたわけではないので、僕がモデルケースとも限らないよなと思っていて。

– 最後に、塚本さんがこれからチャレンジしたいことを教えてください！

できればエンジニアとして、スクラムをチームで回してみたいですね。スクラムが当社に合うのかを確かめたいし、スクラムを社内に薦めるにしても一度結果を出さないとなとも思うし。そして、もともと自分で手を動かすのが好きなので、やはり、ゴリゴリ開発しながら最新のトレンドを追いかけたいという気持ちはあります。

– なんと（笑）。でも確かに、エンジニアとしてのスキルがあっての「ソリューションアーキテクト」ですから、スキルのアップデートは必要ですよね。そのためにも当社の「ソリューションアーキテクト」の層を厚くしていかないとですね！

そうなんです（笑）。ぜひとも、ご応募お待ちしています！