プロダクト開発の舞台裏で活躍するエンジニアたちを紹介する「Wantedly Tech Talents File」。その第1回を飾るのは、開発チームのアーキテクトを務める竹野創平です。新卒入社以来、Wantedly Visit、Wantedly Peopleの開発に携わり続けてきた彼は「ある発見」を機に、プロダクトの開発から設計へと活躍のフィールドを移しました。なぜ彼は愛してやまないプロダクト開発から距離を取り、サービス全体を設計するアーキテクトになったのでしょうか。竹野が歩んできたこれまでのキャリアを振り返りながら、プロダクト開発やサービス作りへの信念、アーキテクト哲学について話を聞きます。

アーキテクトへの道を拓いた「本質を追求する」思い

「入社してしばらくは、ソフトウェアエンジニアとして、Wantedly Visit、Wantedly Peopleのグロース施策や機能開発に携わっていました。もちろん当時からプロダクト開発が好きでしたし、その気持ちはアークテクトになったいまも変わりません」

いまもプロダクト開発を愛し、ソフトウェアエンジニアを自認する竹野はなぜ、サービスの骨格を構想・設計するアーキテクトになったのでしょうか。それは「優れたプロダクトを作ろうと思ったら、手元の開発だけに集中しているだけでは不十分」だと感じたからだと、竹野は振り返ります。

「Wantedlyの代表的なプロダクトである、Wantedry Visitの性質をひと言で表すと『ユーザーと企業の橋渡し役』です。だとするなら、精度の高いマッチングこそが、プロダクトの価値を左右することになる。でも、実際に自分でマッチングを改善するアルゴリズムを開発してみると、作ったアルゴリズムがサービスの隅々まで自然と適用される構造になっていないことに気付きました。基盤や構造を改善することで、サービスの質を高められるのではないか。新人時代に継続して一つのプロダクトの改善に携わる中で、その重要性を自覚するようになりました」

とは言え、改善の余地があると感じたのは、大規模な構造やソフトウェア基盤だけではありません。ソフトウェアエンジニアが書く1行のコード、もっと言えば、関数名や変数名の付け方にまでおよぶと、竹野は言います。

「きっと細か過ぎると思われるでしょうね。でも、それがもし『機能的には同じなのだからどうでもいい』という理由なら、その考えには賛同できません。サービスは長く続くもの。継続的な改善が不可欠である以上、名前から想像できない挙動をするモジュールを『まあいいか』と、放っていておいては迅速な改善など望めません。ソフトウェアで実現したいことを考える意味でも、プロダクトやサービスの一貫性を保つ意味でも、ユーザーから見えない細部にもっと目を向けるべきです」

開発の過程で、当初の目論見や本来の意義が失われてしまった機能やプロセスを洗い出し、より適したものへと改善する。ソフトウェアエンジニアが日常的に行うコードの見直しもサービス基盤の刷新も、すべてはサービスの本質的な価値を高めるために行うものと、竹野は考えています。

「ユーザーグロース担当のソフトウェアエンジニアとして、メールのA/Bテストや文言の見直しやUIの改善を担当していたころから、改善自体を加速させるような、より高次の価値について考えることが少なくありませんでした。『いまこの施策をやるのが本当に最適だろうか、同じ時間でもっとレバレッジする解決策はありえないだろうか』ということを常に考えてしまう。目指してなったアーキテクトではありませんが、強いて言えば、私自身のそうした志向が私をアーキテクトに導いたのだと思います」

アーキテクチャは「技術」だけでは成り立たない

竹野は現在、開発チームのアーキテクトとして、Wantedlyが運営するサービスの中核構造の設計や課題解決に携わっています。しかし彼の仕事はソフトウェア領域だけに留まりません。

「ソフトウェア全体を設計の対象としているわけですから、今後の開発方針や技術選定などについて、フロントエンド、バックエンド、モバイル担当のテックリードたちと領域横断でよく話をします。でも、私が向き合うのは、そうした一次的な作り手だけではありません。エンジニアリングマネジャーや経営陣とは、組織計画や採用、プロダクト戦略などについてよく話をします。サービスのアーキテクチャは技術だけでは成り立つものではなく、プロダクト、ビジネスモデル、そしてそれらを支える組織と相互に影響を与えあうものだからです」

既にあるプロダクト戦略やビジネスモデル、組織のあり方を踏まえた上で、ソフトウェアの設計を考えるのはもちろん、直接的にエンジニア組織の設計に与することもあります。

「たとえば新しい技術の導入を考えたとき、その成否を決めるのは、技術自体の良し悪しはもちろんですが、それと同じくらい、技術の使い方のノウハウを蓄積して正しく使うことがポイントになります。そうすると組織内でナレッジを拡散するためのコミュニケーション手段や情報の流れを設計することも必要です。サービスはソフトウェア部品の集合体であり、各所で利用されている技術が大事なのは言うまでもありません。しかし、技術的観点で施策を取捨選択するだけでは、アーキテクトとしての責任を果たせないのです」

ソフトウェアのアーキテクチャはそう頻繁に変えられるものではないからこそ、プロダクトのコアバリューなど変化しにくい要素を基準に、日頃からベストな取り組みを考えておくことが大切だと、竹野は説きます。

「課題に対して適切なソリューションを前もって準備、検証し、最適なタイミングで使ってこそ、プロダクトはよりよくなっていきます。逆にいつ変化するかわからない個別のプロダクト機能や要素技術については、それがいつ変化してもいいような設計をしておくのもアーキテクトの務め。アーキテクトは、設計という行為によってエンジニアの能力を最大限引き出し、サービスの価値を最大化させるのが使命です。いついかなるときにも対応できるよう、肩書きや職域などにとらわれず準備しておくべきだと思います」

「植物を育てるように」サービスを育んでいく

ソフトウェアエンジニアとして本質を求め、突き詰めるなかでアーキテクトという仕事に出会った竹野。アーキテクトに必要な素養はどうしたら磨けるのだろうか？

「サービスが抱える課題と真摯に向き合い本質的な解決に向けて努力できるかどうか。それに尽きると思います。長期的な視点で開発に取り組む姿勢が大切ですし、小手先の対応で終わらせず、よりよい解決策を求める真摯な姿勢も欠かせません。ソフトウェアエンジニアであれば、1行1行のコードを書くとき、またバグを発見したり、小さなトラブルに見舞われたりしたときこそ、自らの真価が問われていると思うべきです」

竹野は、アーキテクトとしての仕事を「時間をかけ、植物を育てるつもりで取り組んでいる」と言います。継続して開発しているサービスは、四六時中手を入れられ成長していく植物のようなもの。であれば、その変化の力を正しい方向に導くことが、もっともサービスの成長に寄与すると考えているからです。

「新人時代、Wantedly Visit のレコメンド機能を強化したいと思って、Netflixの技術論文を読みました。それを読んで感じたのは、世界中で支持されるサービスというのは、コアバリューがしっかり定義されていて、それが継続的に強化され続けるような部品のネーミング、ソフトウェア構造になっているということでした。本質的な課題と向き合い続けることで、長い時間軸の中で高い価値を持つに至っているのだと改めて感じました」

竹野は、よりよいサービスを追い求めた結果、アーキテクトとして開発基盤や組織、環境作りなどにも携わるようになりました。サービス愛が高じてアーキテクトになった竹野は、これからどのようにプロダクトとかかわっていきたいと思っているのでしょうか。

「私は、ソフトウェアエンジニアとしてプロダクト開発に携わり、途中、プロダクトマネージャーを経てアーキテクトになりました。もちろんいまもプロダクト開発には大きな魅力を感じます。この先、肩書きや立場が変わったとしても、『いいサービスを作りたい』『多くの方に使っていただきたい』という気持ちは、これまで通り変わらないでしょう。アーキテクトとして経験を積んだだけに、何かを変えたいと思ったときに切れる手札の種類は格段に増えました。以前とは違ったアプローチでプロダクト開発の理想に近づけたら、うれしいですね」

取材・執筆／武田敏則（グレタケ）