趣味で始めたWebサイト運営の経験がその後の人生を大きく変える。
エンジニアとして働き始めたのは今から7年前。
きっかけは、趣味で始めたマンガやイラストを取り扱うWebサイトの運営経験でした。元々マンガが好きだったこともあり、同じマンガ好きな友人を誘って共同でWebサイトを運営していましたが、ある時に開発を担当していた友人が辞めることになり、Webサイトの開発が一切できない状況になってしまいました。
当時開発経験のなかった私は企画として運営に携わっていましたが、どんなに企画を考えられたとしても、自らWebサイトを作ることができない現実に無力さを感じ、エンジニアを目指すことになりました。
そこでIT業界に身を置くSESの開発会社に入社し、Skyfallへ入社するまでに受託開発や自社サービスのWebサイト開発など合計3社でエンジニア経験を積み、開発知識やスキルを習得しました。その中でも特に、自社サービスのWebサイトを展開する会社で学んだ教えを今でも大切にしています。
それは、常にプロダクトをアップデートし続けることと、サービスを作るために必要な観点を常に意識することです。
エンジニアとして働く以上、個々の開発スキルはもちろん重要ですが、それ以上に大切なことは、あくまでも開発はサービス作りの手段であるということです。
その後は大好きなマンガに携われることを理由に、マンガDX＋のバックエンドエンジニアとしてSkyfallに入社しました。入社当時は今よりも社内にエンジニアが少なかったので、エンジニア組織のカルチャーを作るなど、開発以外のことにも挑戦できることに魅力を感じました。
また、Skyfallの開発組織にはチームで仕事をする以上最低限のルールはありますが、誰かが独断でルールを決めることはありません。チーム全体で会話して全員の理解を得た上で仕事をしていく方針があり、働きやすさと年次問わず正しい意見が採用されるやりがいのある環境に惹かれました。
自社サービスならではの達成感とやりがい。ユーザー起点の開発でアプリの成長に貢献。
Skyfallに入社してからはマンガDX＋専属のエンジニアとして、ユーザーが使用するアプリのバックエンド開発、社内の運営メンバーが使用する管理画面のフロントエンド・バックエンド開発に加え、アプリ全体のインフラ構築にも携わりました。
Skyfallに入社するまで扱ったことのない技術も多く、都度本を読んだりネットで調べながら自主学習を重ねてきましたが、エンジニアとして働く上で知らなくても良い技術は一つもないので、バックエンド・フロントエンド・インフラなど、様々な業務を経験して知識を身につけられたことで、確実に自身のスキルアップに繋がっていることを実感できました。
また、前職までは一人でプロダクトを開発した経験がなかった中で、1人目のマンガDX＋専属エンジニアとして、裁量を持って働ける環境がやりがいでした。
自社サービスを開発しているからこそ、受託開発のように要望のある機能をそのまま開発するのではなく、ユーザーが操作するアプリと運営が操作する管理画面で必要な機能をそれぞれ予測し、運営から要望のあった事以上のアウトプットをすることを目標に掲げて開発に励みました。
アプリ内のランキング機能やレコメンド機能をはじめ、開発に携わった機能は複数ありますが、次第にユーザー数が増えてユーザーの継続率を上げることができ、さらに運営メンバーの作業工数を削減することができたので、自分の開発した機能が人の役に立っていることを実感できました。
前職では、あくまでもエンジニア組織の一員として働いているような感覚がありましたが、Skyfallに入社してからは「エンジニアも運営も職種は関係なく、サービスを成長させる同じ目的のもと、同じ志を持ったマンガアプリチームの一員」として働いていることを感じました。
中でも一番難しかったことは、インフラを構築するための運用保守の考え方を習得することでした。今までインフラを専門的に学んだことがなかったので、入社当初はキャッチアップに時間を要しました。インフラという目の前には形のないものを想像して、全体の繋がりを図として理解することに当初は苦戦しました。
例えばユーザーがボタンを押した場合、どのような画面が表示されることが正しいかどうかなどのシステムとしての一連の流れについて、自分の意図した流れで処理されていたことをインフラ知識を身に着けることで分かるようになり、さらに機能をリリースした後に不具合や障害を発生させないための開発を習得できるようになったことが大きな収穫です。
また、外部からアプリをアクセスされないようにするためのインフラの構成における知識を身に着けることができ、バックエンド開発やフロントエンド開発にも活かすことができました。
インプットとアウトプットを繰り返す日々。今までの慣習に捉われず、正しい開発ができているかを徹底的に追及する。
今までSkyfallの開発組織は各事業部にエンジニアが所属する体制でしたが、社内のエンジニアを一本化し、担当するプロダクトを問わずエンジニア全体で知識やナレッジを共有していく方針に変わりました。
そこで、社内全てのエンジニアが所属するプロダクト本部に異動することになりました。
プロダクト本部に異動してからは、自社サービスの広告マネタイズプラットフォームSKYFLAGの開発に注力しています。Skyfallへの入社をきっかけに、業界内でSKYFLAGの影響力が非常に大きいことを知っていたので、国内に留まらず海外を視野に開発をしているプロダクトに携われることに胸が弾みました。
当時のプロダクト本部は、SKYFLAGの大幅なリプレイスを控えていたことに加え、一人一人が抱える開発プロジェクトが複数あり、そのことから組織内の横の連携が十分にとれていない場面がありました。
このような場合、フロントエンドとバックエンドと共に100点の成果物を作ることができたとしても、連携した際に0点になってしまう可能性も大いにあります。些細なことでもチーム間で連携がとれておらず、フロントエンドとバックエンド間の認識に齟齬がある状態でそれぞれ開発を進めてしまうと、意図しないものが画面に表示されてしまうなどの不具合が起きてしまいます。
開発組織をより強固にしてプロダクトをさらに成長させるために、組織内の横の連携を強化することと、今まで私が経験してきたサービス作りの観点から、インフラを意識した開発の考え方をメンバーにレクチャーするようになりました。
一つの機能を開発する上でも、そのための準備や開発の進め方などで意識することは沢山あります。また、エンジニアなので全員がコードを書くことはできますが、そのコードが正しくない可能性もあるので、プロダクト全体を意識して開発することの重要性をメンバーに伝え続けました。
異動してから数ヵ月間は全てのプロジェクトに入り、今までどのように開発をしてきたのかをキャッチアップしながら、同時にチーム全体のコミュニケーションを活性化させることに注力しました。
今まで行ってきた開発準備、開発工程、プロジェクトの進行方法が必ずしも正しい訳ではないと感じていたので、プロダクト事業部長と協力し、本部全体が今までの慣習に捉われず、チーム全体で話し合いながらルールを決めていく方針に転換しました。
その結果、年次問わずメンバー間でお互いに感じたことに対して意見を出し合うカルチャーを作ることができ、実際にメンバーから出た意見で正しいことは全て採用しています。
全ての開発はインフラに通ずる。本部全体で運用保守を意識した設計・開発を目指して、メンバーの育成に注力。
プロダクト本部へ異動して2ヵ月後、運用保守の観点からSKYFLAGを今まで以上に安全に稼動するシステムにするために、インフラを専門とするチームを作ることになりました。そこで、SRE（システム運用管理）やQA（品質保証）の役割を担うQM局を立ち上げました。
インフラ構築や運用保守の観点を意識した設計とは、サービスを考えることに等しいと考えています。そこで、マンガDX＋時代の開発経験を活かすべく、SKYFLAGの全ての開発プロジェクトをQM局が監修し、エンジニア全員の開発スキルの底上げを目指して、最初は全てのコードのレビューに私が入り、改善方法を提案するようにしました。徐々にメンバーに考え方が浸透してからは、メンバー間で相互にレビューを行うように変更しています。
機能リリース後、不具合が発生した時にその不具合を直すことはもちろん大切ですが、不具合を発生させないためにリリース前に対策できることは沢山あります。これがサービス作りを意識した開発だと考えているので、メンバーにとっては今までのプロジェクトと比較し進行方法や開発手順が異なり、やりにくい部分もあったと思いますが、開発として正しい選択をとる必要があったので、その大切さを伝え続けました。
QM局が新設されてから2ヵ月後に局長代理に昇格しました。
今までも若手メンバーのマネジメントをすることはありましたが、プロダクト本部に異動して局長代理になってからは技術としてのマネジメントをする機会が増え、さらにマネジメントを担当する人数も増えたので、個人としても新たな挑戦が多くあった期間でした。今までは自分自身がプレイヤーとして仕事をしてきましたが、局長代理になってからはQM局のメンバー育成をより考えるようになり、次第にプロダクト本部全体のメンバー育成についても考えるようになりました。
エンジニア全員が納得して仕事に向き合える環境とはどのような環境なのかなど、考えることの規模が次第に大きくなったことは大きな成長だと思っています。
ある時リプレイス後に、障害を発生させてしまったことがありました。それは、開発時の考慮漏れとテスト期間が短ったことが原因で起きた事故でした。今までもリリース前のテスト期間中に不具合を発見するケースはありましたが、リリース後に不具合が発生してしまうと、取引先やユーザーなど関係各所に迷惑をかけてしまい、さらには営業部が築いたお客様との信頼関係を一瞬で崩すことにもなりかねないので、その時の事故を特に重く受け止めていました。
エンジニア職に就く前にセールス経験のある私にとって、営業部がどれだけお客様を大切にしているかを知っているからこそ、社内の営業部に対して申し訳ない気持ちになりました。この障害を通して、より一層本部全体がQM局の存在意義やインフラの重要性を再認識する機会になりました。
その後はリリーススケジュールを再設定し、今までよりもテスト期間を長く設定して考慮漏れが発生しない状況を作っています。同時にメンバーに対して設計の勉強会を開き、私が直接指導する機会を増やすようにしました。
時代のニーズに応えて業界の最先端をゆくSKYFLAG。グローバル市場で通用する強いプロダクトを作るために、この先も挑戦し続ける。
プロダクト本部では、この先SKYFLAGを何千万人のユーザーが利用した場合も問題なく安定的に稼働するようなシステムを作り、社会へ提供することを目標に掲げています。
将来的にはSKYFLAGをグローバルで活躍するプロダクトにすることを目指しているので、私自身がこの挑戦に力を貸すことができればと思っています。
そのためにも、会社が新たなことに挑戦する時には積極的に提案できるような新しい技術を身に着け続ける必要があります。
SKYFLAGは他の広告プロダクトと比較して様々なことに挑戦しているので、時代のニーズに応えて最先端をゆく点は、SKYFLAGが世界中のどのプロダクトにも負けないと思っています。
同時に、時代の変化と共に着実に成長を遂げるプロダクトの開発に携われることにやりがいを感じています。
現在は本部長代理としてプロダクト本部をまとめる立場になりましたが、これからもプロダクト本部のメンバーと一緒にエンジニア組織のカルチャーを作っていきたいと考えています。エンジニアとして高い技術力と発信力、志のある人と共にSKYFLAGをはじめ、Skyfallの全てのプロダクトの成長に貢献していきたいと考えています。
Skyfallには、エンジニアとして高い技術力を持ち今後もその技術を磨いてプロダクトの価値を上げていくエキスパート職と、メンバーのマネジメントを中心に行うスペシャリスト職があります。
将来的にプレイヤーとして活躍していきたい人と、マネジメント職に就きたい人に向けたポジションをそれぞれ用意し、どちらも同等に評価するSkyfallには、この先様々な夢を持ったエンジニアが集まると確信しています。このような環境があるからこそ、将来的にCTO（最高技術責任者）とVPoE（技術部門のマネジメント責任者）のどちらも担えるような人材になり、プロダクトと共に私自身も成長していきたいと考えています。
この記事をご覧になり、「SKYFLAGの規模を拡大させたい！」「急成長中の企業で自分自身も大きく成長したい！」と思った方は、ぜひお話ししましょう。
