望月いろいろなタイプのエンジニアがいると思うのですが、1つの要素として挙げられるのは、「自分なりの哲学を持ってエンジニアリングをしている人」です。

コードを書く上で、「なぜそう書いたのか」という自分なりの考えを持っていて、それを言葉にできる人。さらに言えば、クライアントのビジネスを理解した上で、どういったものを提案すべきか考えられる人。そこを考えられる人は、どんなものを作るにしても、品質の高いものを生み出せるのではないかと思います。

武石エンジニアの採用面接では、これまで取り組んできたプロジェクトにおいて、どの程度腹落ちして仕事していたかを聞いています。

もちろんコーディングスキルが高いに越したことはないのですが、サービスやビジネスモデルとの接続まできちんと考えられているかどうかもエンジニアのスキルとして重要で、話せばすぐわかります。

全体を見通し、自分の作業をビジネスの一部と理解して仕事しているかどうか。ピンと来るエンジニアの方は、そういう目線を持っている人が多いですね。

佐藤自分の抱えているシステムに、どれだけのアウトカムがあるのか。それが見えている人は強いと思います。ビジネスを意識して、「このビジネスのためにはこういう特性を持ったシステムが良い、この技術を使うのが良い」と考えられる人。

手段としてエンジニアリングを捉え、高い水準を目指していける人には、大きなポテンシャルを感じます。

武石システム単体としての成功に囚われているうちは、エンジニアとしてそれ以上の成長は望めません。

システムがクライアントのビジネスに与える影響を気にするようになってはじめて、「だったらUXはこう考えませんか」みたいな会話が出てくる。そうやってPDCAが回り始め、成長につながっていくんだと思います。

望月もちろん、ずば抜けて技術力の高い天才的なエンジニアであれば、そこまでビジネスやクライアントのことを考えられなくても一定のバリューを出すことはできます。ただ、私たちも含めて世の中の大半の人は天才ではありません。

そういう“一般的な”人たちが大きなバリューを出そうと思ったら、ビジネスへの想像力と技術力を組み合わせることで価値を出していく必要があるのではないかと思います。

武石FinTechという成長領域で戦うには、常に新しい技術をキャッチアップしていく必要があります。また金融のシステムである以上、高い品質が求められます。

時には非常に短い納期の中での開発が求められることもあります。そうした、他業界に比べて高い要求水準に答え続けていく中で、自然と成長していくという側面はあるのではないかと思います。

武石ビジネスモデル上、上流から降りてきた設計書どおりに作るような、大きなシステムのほんの一部にしか携われないエンジニアも多いと思うのですが、そうした環境ではビジネス全体のことを想像するのがどうしても難しい部分もあると思います。

その点、最上流から運用保守まで一気通貫でやっているシンプレクスでは、ビジネスの全体像が見渡しやすい。

また、目には見えない顧客のことを想像しながらサービスを提供するtoCビジネスの企業について、僕はとてもリスペクトしていますし、toCならではの面白さもあることは十分承知しています。しかし、僕たちの取り組むtoBビジネスでは直接クライアントと相対する分、そのビジネスに寄り添いやすいとは思います。

望月メンバーに対しては、「ゴールに向かっていかにやり切るか」という姿勢を徹底的に教え込むようにしています。最後まで責任を持ってやり遂げられる人材は、どんな会社にとっても居たら嬉しい存在だと思うので、転職市場においてはそこが一定評価されているのではないかと思います。

佐藤「自分が必ずしもやりたくないロールだったとしても、プロジェクトを成功させるために必要であれば自分がやる」というマインドを全員が持ち合わせている。こうしたプロジェクト成功に対するコミットメント意識の強さは、意外に希少価値が高いのかもしれません。

佐藤シンプレクスは、クライアントが言うとおりのシステムを作って褒められるような会社ではありません。

クライアントへ届けるものに本質的な価値があるかどうか、社内で常に検証されますし、その結果クライアントからの要求を差し戻して、別のものを提案する場合もある。そうした“本質的なものづくり”に対するプレッシャーが常に働いています。

望月「最高の結果」を追求するために必要があると判断すれば、クライアント側で窓口を担っていただいているシステムの部署だけでなく、周りの関係部署やユーザーの皆様まで自ら巻き込んでいきます。

この「手段を選ばず、“自分ごと”としてプロジェクトを進める意思」は、この会社のメンバーは間違いなく強いと思いますし、そうした姿勢をメンバーにも求めています。

望月シンプレクスでは「札入れ」という、メンバー一人ひとりの評価を先輩や上司たちの投票によって決める評価手法を採用しています。

「自分だったらこの人をいくらで雇いたいか」を投票し、そう評価した理由を各自が発表してみんなで議論します。かなり激しい議論になることも多いので、初めて「札入れ」の会議に参加したメンバーから「こんなにしっかり話し合うんですね」と驚かれることもありますね。

武石40人弱のメンバーが会議に参加するのですが、基本的に時間制限などはありません。必要があればいつまででも議論を続けます。

また当然ながら、評価を受けるメンバーと他の評価者に対して、「なぜそのような評価になったのか」を説明する責任は強く求められます。そのために評価者は、常日頃からメンバーのことを細かく観察する必要があります。

佐藤「プロジェクトマネジャー」や「開発リーダー（テックリード）」といったロールは一応あるものの、「この人はエンジニアだから」「この人はマネジャーだから」と語られることはほとんどないんです。もちろん、メンバーそれぞれの強みを基に、ある程度の濃淡はついていくんですけどね。

望月僕たちも、キャリア序盤はコードを書いていたところから徐々にマネジメントをする立場になっていったわけですが、それはあくまで「プロジェクトにおいて自分にできることは何なのか」を考え、実行していった結果に過ぎません。なので、「自分が何をやるか」に対しては、そこまで強いこだわりはないんです。

武石ここには偶然マネジメントキャリアのメンバーが集まっているだけで、10年以上エンジニア一筋で技術を高め続けているメンバーもいますし、そうしたキャリアで昇給し続けていくことも可能です。

佐藤ただ、前提として「組織にバリューを発揮する」ことは必要にはなります。

開発でバリューを出せる人には当然開発の仕事が回ってきますし、「開発がやりたい」と思っていても開発でバリューが出ないとしたら、もっとその人の強みを活かせそうな別のスキルやグレードアップの道を提案することもあるのが、それぞれの強みを活かそうとするシンプレクスという組織です。

望月僕が社内の若手に向けて言っているのは「知識を得ることそれ自体が目的化しないように」ということです。

知識をインプットすることはもちろん大事なのですが、結局は「それをどう活かすか」という部分がより重要になるので、「アウトプットをイメージしてインプットする」というのが大切になるのかなと。

また、自分がテクノロジーをどう使っていくか考える立場になった際には、成し遂げたい目標に対して技術要求を自分がどう設定するかをベースに考えていくことになると思います。

そう考えると、クライアントから日々高いレベルを求められ、実践しながらそのスキルを身につけられる環境は、20代の成長環境としてやはり良いのではないかと思います。

佐藤キャリアに関して言えば、もし「今の年収に対してなんとなくの不満」を感じているとしたら、その「現年収を構成する中身」を構造分析した方が良いのではないかと思います。

企業自体の業績が振るわないケースもあれば、自身のスキル不足や、業務とスキルが合っていないという場合もある。それらを明確にせずに転職をしてしまうと、本質的には自分が変わるべきだったのに会社を変えてしまったということにもつながり、その先のキャリアパスが見えづらくなってしまいます。

自分の評価や年収を上げたいと思うのならば、客観的に自分を分析した上でどういうアクションを取るべきなのかを考えられると良いですね。

武石ビジネスと技術をつなげる役割を目指す人であれば、コーディングの技術はもちろん、さまざまなビジネスモデルに触れておく必要があります。若いうちから“全体感”を見ることのできる立場で仕事するのは、そのための1つの近道ではないでしょうか。

また「何でも面白がって取り組むことのできる人」は、やはり間違いなく伸びていくなと感じます。「ちょっとここ自動化できないかな？」というネタを与えると、次の日めちゃくちゃ嬉しそうに「こんなのできました！」と報告してくれるようなタイプの人ですね。

なので、プロジェクトにおいてもどんどん自分からタスクを取って楽しみながら仕事ができれば、必ず成長につながると思います。