東京都

「世の中の会社にとって大切な売上やKPIという概念に触れずにいて良いのか不安だった」会社の安定でなく自分の市場価値に向き合った中堅エンジニアが今シェルフィーでやりたいこと

栗原志保, Funakawa Taiki

採用担当, Web エンジニア

栗原志保

シェルフィー株式会社 / 採用担当

フォロー

Funakawa Taiki

Web エンジニア

フォロー

on 2021/11/26

💁今回の主役：舟川太基

長野県生まれ千葉県育ち。大学では金融工学を専攻。
新卒で信託銀行のIT子会社に入社し、流動性リスク管理のシステムに携わり、4年で退職。
その後、受託開発系のITベンチャーに10ヶ月勤め、入社時に「絶対炎上するよ」と言われたプロジェクトをリーダーとして納期通りにまとめ上げ大成功を収める。
「やっぱり自社開発に携わりたい」と2019年1月にシェルフィーに入社。

シェルフィー入社前

＊自我があんまりない？！レールに乗って走ってきた学生時代

私は長野県の梓川村という今は松本市になっている村に生まれ、小学1年生の秋までいました。梓川村は本当に自然が豊かで、カブトムシを取ったりカマキリの卵を取ってきて庭で孵化するのを見てるような虫取り少年でしたね。
父親の転勤もあってその後千葉に引っ越すことになり、それからはカブトムシはいなかったのでひたすらザリガニを釣っていた記憶があります（笑）

正直なところ、私の学生時代はあまり自我を持たず用意されたレールに乗ってきたと自分で思っているからか、ほとんど記憶がないんですよね……（笑）

唯一、小学生のとき高学年から始まる学級委員に毎年立候補していたことを覚えています。
しかも私の場合は別に学級委員やりたくてやってるわけではないんです。学級委員を決めるホームルームの時間に誰かが手を上げるまでシーンとなるあの雰囲気が嫌すぎて自分で手を挙げてました。

当時をこうして振り返ってみるとめちゃくちゃ偉いなと思いますが、モチベーションはあの雰囲気が本当に嫌いだったということと、学級委員になったところで対してやることないからいいかなと思ってましたね。
中学ではやりたい人が結構いたので卒業することができてよかったなーくらいにまで思ってました（笑）

積極性が特別あるわけでも、不良だったわけでもなく、友達とモンハン（モンスターハンター）に明け暮れ、陸上部も入ってそこそこ頑張る「普通のいいヤツ」だったんじゃないかなと思いますね。

＊エンジニアになったきっかけ

自我があまりなかったものの、初めて自分で何かを大きく選択したのは高校２年生の進路を決めるタイミングでした。

私達の世代って、高校入ってすぐにリーマン・ショックが起こっているんですよ。当時何が起こっているのかはわからないものの、ワイドショーでたくさんの経済学者が議論していたんです。それを見て「経済学があるのになぜリーマン・ショックが起きたんだろう？」と思いました。これがきっかけで経済学科を選びました。

無事大学に入学すると、今度は経済学の授業以上に統計学がすごく面白かったんです。そのまま金融工学のゼミを選択し、「どんな組み合わせの株だと低リスク高リターンか？」といった命題を統計学的に分析していてすごく楽しかったですね。

ところが就職活動の時期になり、周りの同期が軒並み銀行や金融系の社団法人に営業職として就いていく一方で、自分としては当時すでに「自分に営業は向いていないな」と思っていました。そんなエネルギッシュな若者枠には入れないなと（笑）

どうしようかと悩んでいた矢先、とある保険会社の説明会にIT子会社の方が来られていてそこで初めて「金融系のIT子会社」の存在を知りました。それからはIT子会社に狙いを定め、結果的に信託銀行のIT子会社から内定を頂いて就職活動を終え、エンジニアとしての人生をスタートしました。

研修後は経営管理支援部に配属されました。
経営管理支援部とは、信託銀行の経営管理部の人が使うシステムを開発する部署です。経営管理部ではいくつか専門が分かれているんですが、私はそのうち流動性リスクを管理するシステムの担当でした。

流動性リスク指標って、わりとニッチなんですよ。もしかすると銀行で働いていても知らない人がいるくらいです。しかもこの分野自体はリーマンショック後に新たにできた概念で、特別希望を出したわけではありませんが、不思議なご縁でこの部署に配属になりました。

流動性リスク指標のうち、例えばLCR（Liquidity Coverage Ratio）という指標は、金融危機下での資金流出に対応できるよう銀行に対して適切な流動資産を保有することを求めるものです。
すごくざっくり言うと、もし銀行が預金をすべて上場株式として運用しまうと、金融危機下では株式は現金化するのが難しいので資金繰りが困難になります。そうならないようにだいたいの銀行は返さなければいけないお金をしっかり返すために流動性を担保できるよう管理しているということです。ちなみに金融庁からは最低100％という数字を保つよう言われていますね。

新卒でこのシステムの実装を主に担当していたのですが、IT子会社は基本的に保守運用の世界なので今あるシステムを理解しないといけないですし、そのためにはその業務が実際にどのように行われていて、どう判断されているのかを理解しないといけなかったので、実装そのものよりも業務を理解することのほうが大変でしたね！（笑）

シェルフィー入社後

＊面談を重ねるほど「納得感」と「人の良さ」を感じた

そうして開発における一連の工程を経験して4年が経とうとしていたときに、ふと「このまま会社にとって大切な売上やKPIという概念に触れずにいて良いのかな」と不安になったんです。
IT子会社は基本親会社の業務で使うシステムを管理したり運用するために存在しているので売上は気にしないですし、どちらかといえばコストカットが重要視される世界ですが、どちらにせよKPIが現場に降りてきていなかったこともあり、他の企業との違いを感じて自分の市場価値を考えるようになりました。

更に上司からは「そろそろ実装は卒業して要件定義や上流工程メインで動いてほしい」と言われていました。それにも違和感を感じ、もっと実装していたいと思ったことも後押しとなり転職を決意。受託開発もやりつつ自社サービスを運営している会社を挟んで2020年1月にシェルフィーに入社しました。

基本的に自社開発をしている企業中心に見ていたのですが、シェルフィーのことは当時採用を担当していた鈴木（陵太）からスカウトをもらったことで知りました。
実は最初タイトルの「建設業界」を見てスルーしちゃったんですよ（笑）イメージがわかなくて！でもその後たまたま開いてメッセージを読んでみたらめちゃくちゃアツいメッセージが書かれていて、「これは行かないといけない！」とすぐに思いましたね。

面談を重ねれば重ねるほど、めちゃくちゃいい会社だなと思いました。
鈴木と川永はとにかく熱かったし、大佐と石川健司は掛け合いが漫才状態で（笑）、最終面談でのロイと石川は本当に頭が良くて驚いたのを覚えています。「何をやってるか」よりも「どんな人が働いているか」で入社を決めましたね。

特に、納得感を大切にする文化には本当に共感しています。実際、前職の社長はオフィスにいなかったんですが、海外の会社を買収してたからなんです。でも私がやってる業務とその会社に何の関係があるのか最後まで分かりませんでした。こういう経験があるからこそ、シェルフィーのこの文化は今でも大切にしたいです。

シェルフィーに入ってもうすぐ2年になりますが、この「いつでも納得感を持って仕事できてること」と、「一緒に働いているメンバーがいいヤツ」だから未だに気持ちよく働けていると思います。

しかもこれまでシェルフィーにいて納得感がなかったことはないんです。

ARA（Ask Roy Anything）で気になることは聞くことができるし、大佐や石川といつでも話すこともできます。こうして向き合ってくれたからこそ、今となっては呂や石川、大佐のことを全面的に信頼しています。会社が自分が思っていた選択と逆のことを選択したとしても、「一回乗っかってみるか」と思ってます。なんか生意気ですね（笑）

＊PMFできた今、複雑な建設業界にシステムから向き合う

今は内部品質を上げるために、バックエンドを動的型付け言語から静的型付け言語へと変更するプロジェクトを進めています。私が主導してちょうど１つ目をつくっているところですね。これができたら少しずつみんなを巻き込んでいこうと思っています。

これまでシェルフィーのシステムは何がお客様のためになるのか実際につくってみないと分からず、壊す可能性もあったことから、短期のスピードを優先して動的型付け言語で開発をしてきました。
そしてありがたいことにたくさんのお客様から反響を頂き、ようやくPMFできたといえるフェーズとなりました。今後はSaaSサービスとして勝っていくために「高アジリティであること」と「開発サイクルの高速化」の2点が大切であり、そのためにはプロダクトの複雑性を下げ続ける必要があります。

特に私達が対象にしている建設業界は業界そのものが複雑なので、いかにドメインの知識をコードに落とし込めるかがより大切になってきます。その場合、クラス設計がしやすい静的型付けの方が相性がいいんです。
静的型付け、動的型付けのどちらが優れているというわけではなく、向き不向きがあります。個人的には動的型付けで複雑なドメインを対象にしたものを作ろうとすると、チーム全体として求められるエンジニアスキルがかなり高くなってしまうので今後のシェルフィーのフェーズには合っていないなと感じました。

静的型付け言語にはJavaやScala、Goといった選択肢がありますが、私達はKotlinを選択しました。

面談や記事でも「なぜその言語を選んだか」と良く聞かれますが、今回は何よりも分かりやすいこと、曖昧さを減らせる言語を選択しました。

KotlinはJavaよりも簡潔に書けてnull安全だったり、ScalaやGoよりはキャッチアップしやすいのが良いですね。今いるメンバーというよりは、チームがスケールしていく中でもKotlinがフィットしているのは想像しやすかったです。また、実績があるJavaのエコシステムを利用できるというのも大きなメリットですね。

例えばJavaは昔から使われている言語でその分色々な処理ができますが、簡単な処理をするにも若干長いコードを書く必要があります。スタートアップに来てまでJavaやりたい人もいるのか？と考えるとちょっとモダンさに欠けるのも微妙でした。
ScalaはJavaを超えるために作られた言語であり、アカデミック寄りな性質があります。やはり自由度が高い分チーム全員で開発する際のメンテナンス性を考えると少し難易度が上がります。
Goに関しては不確実性が高いことが懸念となりました。メンバーの技術スタックからのジャンプ幅が大きいことや、Goはマイクロサービスに強みがあるものの、Greenfile.workはマイクロサービスではないので本当に相性が良いのかというと不安が残りました。

とはいえどの言語も本当に一長一短で、シェルフィーの開発神である柳とエンジニアリーダーの大佐と3人で、ウンウン唸りながら2週間前くらいに決めました。かなりタイムリーなトピックで正直まだ私も色々開発環境で試し始めたくらいなので今後どうなるか楽しみですね（笑）

＊「シェルフィー」でエンジニアから安心される会社にしたい

シェルフィーに入る前までは、周りのエンジニアは技術重視の方が多くて、自分はコミュニケーションを武器にしていたし、そうして市場でも生き残っていくんだろうと思っていました。ところが今シェルフィーではみんな本当によく喋るし技術にも貪欲で、そんな中で相対的に技術力を発揮していく立場になりました。自分の長期キャリア、生存戦略はもはや迷子です（笑）

今のシェルフィーは、機能やコードなど目に見えるところはお客様やグロースチーム、そしてエンジニア同士でもたくさんフィードバックし合える良いチームです。
ただし、目に見えない部分の良し悪しを判断できる人が少ないなと思っています。そして、この領域については私自身良し悪しを判断できると自負していますし、個人的な興味も強いので部分でバリューを発揮したいなと思いますね。
この目に見えない部分をしっかりやらないと後々苦しむことになると思うので、将来みんなが苦しまないで開発できるようにしたいです。

私が銀行の子会社で働いていたときに、設計面でかなり専門的な知識を持っている協力会社の方と一緒に働いていたことがあったんです。未だにその会社から教えていただいたことを業務に活かしたりしているんですが、たまたまこの前とあるセミナーを見ていたら登壇されていたあるベンチャーのCTOの方がその会社のご出身でした。その瞬間すごい安心感を感じている自分に気づきました。

今シェルフィーにいるメンバーも絶対にずっとシェルフィーで働き続けているわけではないですよね。だからこそ、今のエンジニアメンバーがもし別の会社に転職したとして、転職先で「あのシェルフィーから来た！」と思ってもらえたら嬉しいです。そういう会社にしたいなと思います。