システムの最深部から全社にインパクトをもたらす、プラットフォームエンジニアの仕事

■企業情報
サイボウズ株式会社
「チームワークあふれる社会を創る」を企業理念に掲げ、ビジネスインフラとなるグループウェアの開発・運営を手掛けるIT企業。
「kintone」や「Garoon」「サイボウズ Office」「メールワイズ」などの自社開発プロダクトを展開し、多くの企業や法人の業務改善・情報共有を支える。パブリッククラウド（AWS等）に加え、自社で独自のオンプレミス環境やコンテナオーケストレーション環境（Kubernetes基盤）を構築・運用するなど、インフラ領域における高度な受託開発・運用も行う。

■お話を伺った人
平井 雅人（ひらい まさと）さん
サイボウズ株式会社 プラットフォームエンジニア
京都大学大学院情報学研究科修士課程修了。学生時代はサークルで競技プログラミングに取り組み、「AtCoder」にて青色レートに到達し、開発のベースとなる下地を築く。バックエンド領域のアルバイトで実務経験を積み、大手IT企業のセキュリティチームでのインターンも経験。大学院ではゼロトラストやOAuthなど認証・認可に関する研究を行う。 新卒でサイボウズ株式会社へ入社。現在は全社共通のミドルウェアコンポーネントの保守・実装に携わる。 
 

• 就活の中でじわじわと定まった自分の軸 。大規模オンプレミス基盤のサイボウズを選んだ理由

• 全社規模の難題に自らの技術提案で挑む。大規模基盤の信頼性を裏方で支えるエンジニアの仕事

• 認証認可の研究を共通基盤のコア領域へ活かす。専門性を武器に目指す次なる挑戦

   

 

就活の中でじわじわと定まった自分の軸 。大規模オンプレミス基盤のサイボウズを選んだ理由 

── 学生時代はどんなことに取り組んでいましたか？

大学の1〜2年生の頃は競技プログラミングに傾倒し、そこで培った基礎を活かして、開発現場でのアルバイトにも注力していました。

実は高校時代に『苦しんで覚えるC言語』という書籍を読んだ程度で、入学前は特にプログラミング経験は無かったんです。当時はプログラミング自体への興味はあったものの、「具体的に作りたい制作物」が思い浮かばず行動に移せずにいました。

そんな中で出会ったのが、競技プログラミングのサークルです。競技プログラミングは特定のプロダクトを想定しなくても純粋にロジックを解く楽しさを味わえるため、「特に作りたいものがない」「でもプログラミングはやりたい」という自分のジレンマを解消してくれました。

そこから本格的にのめり込み、約2年間主軸として活動した結果、国内最大級のコンテストサイト「AtCoder」で上位数%の精鋭層に位置する「青色」レートに到達するまでのアルゴリズム力を習得できました。この時期にプログラミングの基礎力をつけたことで、学生時代の後半には開発現場でのアルバイトに挑戦するなど、実務へも関心が広がっていきました。 

── そのアルバイトでは、具体的にどのような開発を行っていましたか？ 

大学2年生の時に参加した、ITコンサル企業の2週間の短期インターンが始まりでした。

期間中の取り組みを評価され、終了時にそのままアルバイトとして残らないかとお声がけをいただいたんです。そこから結果的に1年以上継続して働くことになり、バックエンドからインフラ、さらには機械学習まで非常に幅広い領域の開発を経験させてもらいました。 

具体的な業務としては、まずAWSのCLIを用いて、インフラを自動化するような社内ツールの開発に携わりました。その後、社内でのチーム異動を経て機械学習の領域に移り、そこでは機械学習の算出結果をビジュアライズするツールの設計と実装を担当しましたね。

当時は実務の開発経験も無かったため何でも吸収する気持ちで臨み、1年以上働いた中で、バックエンド領域の実務を勉強させてもらいました。 

── そこから派生して取り組んだことはありますか？ 

競プロで培ったアルゴリズムへの理解や、バックエンド領域への関心の広がりから派生して 、Webアプリケーションの高速化を競うコンテスト「ISUCON」へ参戦するようになりました。

通算で3〜4年ほど出続けているのですが、大学院生の頃などは平日と土日の境目がなく常に研究に追われていたため、自主的な勉強に使える時間を十分に確保できていなかったんです。当時は過去問を少し解くといった対策は一応していたものの、どうしても多くの時間を割くことは難しく、純粋にイベント自体の熱量を楽しむお祭り感覚の側面が大きかったと感じています。

しかし、社会人になって土日はしっかり休める環境に変わり、仕事とプライベートのメリハリが生まれたことで、精神的・時間的なゆとりが生まれました。この変化によって事前対策へ集中して時間を割けるようになったことが功を奏し、並み居る強豪エンジニアの中で、全体18位での入賞を果たすことができました。 

── 学業の中でもさまざまなことを学ばれたのでしょうか？ 

学業に関しては、コンピューターサイエンスの分野全般において、しっかりと講義を受けてきたように思います。

学部時代にはデータベース周りの勉強をはじめ、ハードウェア記述言語の「Verilog」を用いたCPUやプロセッサーの実装、さらには機械学習の実装を行う授業などを幅広く履修しました。これらすべてが汎用的な知識として、現在の自分の地盤になっていると感じています。

学部4年の卒論からはセキュリティ領域の研究室に所属し、新時代のセキュリティ思想である「ゼロトラスト」に基づいた認証・認可の連携に関する先輩の研究を引き継ぐ形でスタートしました。

その後、修士課程に進学してからは、Web連携で広く用いられる認可プロトコル「OAuth」をテーマに設定し、ユーザーが自ら主導して認可を行えて、なおかつ、それをある程度自動化していけるような仕組みの提案を修論で取り組んでいました。

──学生の頃からバックエンドとセキュリティの両輪の経験を積む中で、自身の適性やキャリアの方向性をどのように見極めていきましたか？ 

就職活動を意識し始めた頃、自分の中でどちらの領域に進むべきか、適性を見極めようとしていました。

業務経験の長さで言えばアルバイトで行っていたITコンサル企業でのバックエンド開発が軸にありつつも、大学院での研究テーマがセキュリティ分野だったため、双方に可能性を感じていたんです。

ただ、言語化が難しいところではあるのですが、振り返ってみると自分に向いているのはやはりプログラミングの方だなと感じることがありました。

純粋にロジックを解く競技プログラミングをずっと楽しめていたこともそうですし、サークルで何人か集まってゲーム開発をしていた際、メンバーからの技術的な相談に乗ったり、課題を解決していくプロセス自体をそれなりに楽しんでやれていたんです。

こうした経験を通じて、裏方として開発を支えるバックエンド側のほうが自分の好みにマッチしているのではないかと、就活を進めながらじわじわと気づいていきました。

──それでは就活では、最初からバックエンドに絞って受けていたのでしょうか？ 

いえ、最初からバックエンド一本に絞っていたわけではなく、まずは裾野を広げてどちらの領域も受けてみようという形からスタートしました。そのため、インターンの繋がりがあった大手IT企業のセキュリティ職などにも実際にエントリーをしていたんです。

しかし、その企業の選考では結果的に不合格となりました。自分なりに理由を分析してみると、企業側がプロダクトのセキュリティメンバーに求めているのは、脆弱性を見つけて叩くような「ホワイトハッカー的」な振る舞いや実践スキルだったのに対し、私の研究は認証・認可というシステム基盤の仕組みに寄っていたんです。

私はCTF（セキュリティコンテスト）などは熱心にやってこなかったため、求められる方面の知識が正直自分には足りていないという、技術的なミスマッチを客観的に認識しました。

こうした実際の選考を通じた経験も踏まえて、やはり自分に向いているのはバックエンドのほうだと納得がいき、じわじわとそちら方面のエントリーの割合を増やしていったという流れです。

── 数ある企業の中から、どのような基準を持ってサイボウズに出会い、最終的な入社の意思決定をされたのでしょうか？ 

企業選びにおいては、何よりも「技術的に面白いことができそうか」という純粋な知的好奇心を最優先に考えていました。その技術的なバックボーンとなったのが、大学院の研究室の環境です。

私の研究室には、Kubernetes（クバネティス）などのコンテナ技術や仮想化技術に専門的に取り組んでいる同期が身近にいて、彼らから構造や仕組みを色々と教わって勉強していました。その中で、低レイヤやインフラ基盤の持つ面白さに深く魅了されていったんです。

そんな折に出会ったのがサイボウズでした。サイボウズはパブリッククラウドに依存するのではなく、自社でオンプレミスのKubernetes環境の基盤を構築し、その巨大な自社基盤の上に製品をデプロイするという独自の運用フローを取っています。

国内を見渡しても極めて珍しいこのインフラ環境を知ったとき、純粋に「これは面白そうだ」と強い好奇心を掻き立てられました。

パブリッククラウドの既製品を使えば容易に解決できる規模を、あえて自社インフラでどのように制御し、高可用性を担保しているのか。その裏側を自分の手で解き明かし、開発に携わってみたいという好奇心がすごく大きかったかなと思います。

それから、すごく信頼できる周囲の方から、サイボウズは労働環境や福利厚生がいいよという話を事前に伺っていたこともありました。それなら安心して働けそうかなと思い、入社を決めましたね。  

全社規模の難題に自らの技術提案で挑む。大規模基盤の信頼性を裏方で支えるエンジニアの仕事

──入社後に配属されたプラットフォームエンジニアのチームでは、初期にどのような技術環境と対峙し、キャッチアップを進めましたか？ 

4月から8月の頭くらいまで、半年ほど開発系も含めた研修を受けた後に、現在のチームへ本配属されました。

私のチームは社内で使われている10個のミドルウェアコンポーネントを管理しているのですが、特定のコンポーネントだけを担当するという形ではなく、タスクごとに見るコンポーネントが変わるため、全員でこれらすべてを網羅的に見ていく体制でした。

最初の頃は、どれが何をしているのか、どういうインフラ構成になっているのか、コードベースで何をやっているのかを、頑張って理解して必死に食らいつくような感じでしたね。

さらに大変だったのが、必要とされる前提知識の多さです。私たちが管理するミドルウェアは、「kintone」や「Garoon」といった様々なサイボウズ製品から触られる部分になります。

そのため、コンポーネント単体の仕組みだけでなく、それを叩く側の裏側がどうなっているのかもザックリと頭に入っていないと、内容を理解することすら難しかったんです。配属直後は、カバーしなければならない範囲の広さに、とにかく圧倒されたことを今でも覚えていますね。

── 現在は扱うタスクの難易度も上がっているとのことですが、最近取り組まれた難易度の高い技術的課題の具体例を教えてください。

比較的最近手がけた、非同期処理を司るミドルウェアコンポーネントの改善対応が、これまでに取り組んだ中では大きなタスクであり、非常にやりがいを感じた経験でした。

当時、「すべての環境に対して非同期の状況を定期的に確認しに行く機能」を導入したばかりだったのですが、これが1時間に1回などのタイミングで集中的にアクセスを走らせる実装になっていたため、インフラ側に過大な負荷がかかってしまい、インフラチームから改善依頼が届いたんです。

対応にあたってはアクセスのタイミングを分散させる処理も行いました。しかし、根本的な原因を調べていくと、定期実行の処理にKubernetesの「CronJob」というリソースを大量に立てて利用していること自体が、インフラへの別の負荷になっていると分かったんです。

そこで、負荷を分散するために複数のコンテナをまとめて管理する「ReplicaSet」の構造に着目しました。すべてのコンテナ（Pod）から個別にアクセスさせるのではなく、その中の特定の1つのコンテナだけを代表（リーダー）としてアクセスさせる形にすれば、データの永続化処理などが不要になり、実装もシンプルに抑えられると考えました。

具体的には、Kubernetesの「Leaseオブジェクト」を用いて、コンテナ群の中から動的にリーダーを選出する「Podリーダーエレクション」という仕組みを自分で提案しました。私のチームはベテランの大先輩ばかりなのですが、製品の開発責任を持っているEM（エンジニアリングマネージャー）の方と直接コミュニケーションを取り、色々と相談を重ねながら方針を決めていきました。

周囲に相談しながらのプロセスではありましたが、自分から提案した内容で綺麗に課題を解決できましたし、実際の設計からリリース、全社基盤への実装までを一気通貫でやり切ることができたため、エンジニアとして大きな手応えと楽しさを感じられる経験になりました。

── 入社後に、最も苦労した出来事は何ですか？ 

配属直後の、本番環境のログ監視業務が一番大変でした。当時はちょうど、従来の古い基盤からKubernetesを採用した新しい基盤へ、社内のあらゆるシステムを移行している最中だったんです。その新基盤が安定して動いているかを確認するため、チーム内では2日に1回の交代制で本番ログを見る運用を行っていました。

入社直後の私にとって難しかったのが、出力される大量のエラーや警告の中から、「即座に対応すべき致命的なログ」と「許容していいノイズ」を嗅ぎ分けることでした。

Kubernetes環境特有の挙動として、一時的なラグやエラーが発生しても、コンテナ自体の回復力によって自動で正常な状態に戻ることがよくあります。そこまで気に留めなくてもいいエラーなのか、本当に危ないアラートなのかがどうしても分からなくて。動的なシステムの理解が追いつかない内は、判別が極めて困難で本当に難しさを感じていました。

それを乗り越えるために工夫したのが、自分なりのメモ作りです。コンポーネントが複数あってそれぞれが複雑に絡み合っているため、断片的な知識のままだと記憶がぐちゃぐちゃになってしまうんですよね。

だからこそ、分からないログや仕組みに出会うたびに自分で色々と調べて、「自分の言葉」でローカルのメモに整理し直すようにしました。情報を一つひとつ噛み砕いて構造化していくことで、頭の中がクリアになり、少しずつ「これは大丈夫なログだ」と判断できるようになっていきました。

── ベテランのエンジニアに囲まれたチーム環境だと伺いましたが、どのような雰囲気の中で働いているのでしょうか？ 

私たちのチームはそもそも人数がそんなに多くないのですが、今のところ若手が僕しかいないのもあって、周りはみんな大先輩ばかりという環境で仕事をしています。

ただ、大先輩ばかりだからといって、若手の自分を単なる作業者として扱うような雰囲気は一切ありません。さきほどの非同期処理の改善タスクでもそうだったのですが、プロダクトの開発責任を持っているEMの方と直接コミュニケーションを取って、自分の提案をしっかりと壁打ちさせてもらえるんです。

ベテランの先輩方に囲まれながらも、一人のエンジニアとして提案を対等に聞いてもらえますし、信頼して「これで進めていいよ」と大きなタスクを任せてもらえる土台があります。このフラットなカルチャーがあるからこそ、委縮せずにのびのびと技術的な挑戦に向き合えていると感じています。

── 全社のプロダクト開発を支えるプラットフォームエンジニアとして、実務において最も重視している思想やスタンスは何ですか？ 

一番考えているのは「信頼性」の部分かなと思います。私たちが扱うミドルウェアコンポーネントがある種の複雑性を吸収することで、他の製品チームが共通して持つようなコードを減らすことができるんです。

その意味で非常にレバレッジが効く仕事なのですが、裏を返せば、複数のチームが共通して使うからこそ、何か起こった時のダメージが全社規模で非常に大きい部分でもあります。

そのため、新機能をバリバリ急いで開発するというよりは、どちらかというと結構慎重になりながら、「最悪のケースでも被害はこの程度で収まるだろう」という当たりまでしっかりつけた上でリリースする、ということは入社直後の最初の方からずっと気をつけてやっていますね。  

認証認可の研究を共通基盤のコア領域へ活かす。専門性を武器に目指す次なる挑戦

── 今後新しく挑戦したいことやエンジニアとしての展望を教えてください。 

タイミングとしては入社2年目を経て、これから3年目を迎えるところなので、まずは足元の実務をしっかり固めていくのが最優先です。その上で、中長期的には自分の学生時代の研究領域を今の業務に掛け合わせていけたらな、と考えています。

大学院時代は認証や認可について専門的に研究していたのですが、この仕組みは現在のプラットフォームエンジニアという職種ともすごく親和性が高いんです。

せっかく培ってきた知見なので、自分の専門性を武器にしながら、共通ミドルウェア基盤の中でもよりコアな領域の開発へと挑戦の幅を広げていけたら面白いなと思っています。

──平井さんの視点から見て、プラットフォームエンジニアに向いているのはどのような人だと思いますか？ 

技術的な面で言うと、やっぱり幅広い知識があって、それを支える基礎知識がしっかり身についている人ですね。私たちのチームでは10個の多種多様なミドルウェアコンポーネントを扱っているので、いろんな技術要素を広くインプットして活用していかなければなりません。

ただ表面的な技術に詳しいだけでなく、それらをパッと迅速に理解して自分のものにするための、コンピューターサイエンスをはじめとした基礎知識を学生時代からしっかり身に付けた人にはすごく向いていると思います。

マインドの面で言うと、エンドユーザーからは見えにくい「裏方」の仕事に、おもしろさを見出せる人でしょうか。フロントエンドや一般的なプロダクト開発とは違って、システムの最深部を支える仕事なので、一般のユーザーから直接目に見える成果としては現れにくいんです。

スポットライトが当たりにくい領域ではあるのですが、全社のシステムや製品群を陰から支える仕組み作りに魅力を感じて、責任感を持って愚直に向き合い続けられる人にとっては、すごくやりがいがある環境だと思います。

── 平井さんが日々実務の中で実感している、プラットフォームエンジニアならではの魅力や面白さはどこにありますか？ 

魅力としては、やっぱり自分たちのミドルウェアがいろんな製品チームから使われているので、ちょっとした改善でも会社全体に影響がいき、レバレッジが効くという点かなと思っています。

個々の改善をすることで社内の開発チーム全体の幸福につながる一方で、逆に不幸につながる可能性もある部分なので、良くも悪くも影響が大きく、そこは責任感と緊張感もありますけど、すごく面白いところなんですよね。

あとは、本当に色んな技術に触れるところも面白いなと感じています。たくさんコンポーネントがあって、それをみんなで広く見ているので、特定の技術だけじゃなくて、様々なモダンなツールを触りながら自分の幅を広げていけるんです。そのプロセス自体が、純粋にやっていて楽しいなと感じる部分ですね

── 最後に、プラットフォームエンジニアを目指す学生の皆さんへメッセージをお願いします。

プラットフォームエンジニアにとっての「ユーザー」というのは、他ならぬ社内のプロダクト開発チームそのものなんですよね。彼らの開発生産性を自分たちの技術力で底上げして、組織全体にすごく大きなレバレッジを利かせていける仕事なので、とても価値があって面白い領域だなと思っています。

こうしたシステムの土台や仕組みのコアになる部分を支えることや、技術の力で全社に大きなインパクトをもたらすことに少しでも興味がある方は、ぜひ学生時代から自らの土台をしっかりと磨いていただいて、このフィールドで一緒に挑戦してみてほしいと思います。  

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

                                                           就活アドバイザーに相談してみる