プラットフォームエンジニア
平井 雅人
（2024年 新卒入社）
京都大学工学部情報学科を卒業後、同大学大学院 情報学研究科修士課程を修了。 大学入学後に参加したサークルで競技プログラミングと出会い、AtCoderでは水色〜青レベルまでレーティングを伸ばし、思考力と実装力を磨いた。 2024年にサイボウズに新卒入社し、プラットフォームエンジニアとして、社内で利用される多数のミドルウェアコンポーネントの保守・改善に携わる。
2026年5月に公開
競技プログラミングから広がった、エンジニアとしての土台
エンジニアとしての原点を教えてください。
京都大学工学部情報学科で学び、その後同大学院情報学研究科へ進学しました。
高校時代から「いつかプログラミングをやってみたい」という気持ちはあったものの、当時は明確に作りたいものがあったわけではありませんでした。
そんな私が本格的にプログラミングにのめり込むきっかけになったのが、大学1年生のときに参加したサークルでの競技プログラミングでした。
競技プログラミングは、明確なアウトプットを決めなくても純粋に思考力や実装力を磨ける点が、自分の性格にとても合っていました。
気づけばAtCoderのレーティングは水色〜青レベルまで到達し、プログラミングそのものを「楽しめる感覚」が自然と身についていったと思います。
学生時代には、どんな知識や経験を積み重ねてきたのでしょうか？
大学では、データベース、CPU実装、Verilogによるプロセッサ実装、機械学習の実装実験など、いわゆるコンピュータサイエンスの基礎を幅広く学びました。これらは直接プロダクトを作る力というより、後々どんな技術にも応用できる知識の土台になっていると感じています。
一方で、実務的な力を大きく伸ばしてくれたのは、インターンやアルバイトの経験でした。バックエンドやインフラの自動化、AWS CLIを使った社内ツール開発、機械学習結果を可視化する内製ツールの実装など、学生のうちから比較的実践的な開発に携わることができました。
大学院では、認証・認可やゼロトラストといったセキュリティ分野を研究。修士論文ではOAuthをテーマに、よりユーザー主体で認可できる仕組みの提案に取り組みました。
大規模基盤の裏側に惹かれて選んだ、サイボウズという選択
就職活動では、どんな軸で進路を考えていましたか？
就職活動では、バックエンドとセキュリティの両方を選択肢に入れていました。
ただ、インターンや研究、自己分析を進める中で、「自分は前面に出るよりも、プロダクトやチームを裏側から支える方が性に合っている」と感じるようになりました。
数ある選択肢の中で、サイボウズを選んだ理由は何だったのでしょうか？
私にとっては、「オンプレミスのKubernetes基盤を自社で構築し、その上に複数のプロダクトを載せて運用している点」が非常に魅力的でした。
大規模なユーザーを支える基盤の裏側を、自分の手で支えられる。その好奇心が、入社の決め手になりました。
また、学生時代のチーム開発経験から「良いプロダクトは、良いコミュニケーションから生まれる」と感じていた私にとって、チームワークを大切にするサイボウズの文化も大きな魅力でした。
数十のミドルウェアを支える「責任感」こそが、プラットフォームエンジニアのやりがい
入社後は、どのような仕事を担当していますか？
入社後、まずは研修を経てプラットフォームエンジニアとして配属されました。
所属チームでは、社内で使われている数十種類のミドルウェアコンポーネントを管理しています。配属直後は、その数と複雑さに圧倒されました。どのコンポーネントが何を担い、どんな構成で動いているのかを理解するだけでも一苦労です。特に最初の頃は、本番ログを見ても「どこまでが許容されるエラーなのか」が分からず、常に手探り状態でした。
そんな中で私が意識していたのは、自分なりの言葉で整理することです。調べた内容をメモにまとめ直し、「なぜこうなっているのか」を自分の頭で噛み砕くことで、少しずつ理解を積み上げていきました。
特に印象に残っている仕事について教えてください。
印象に残っている仕事のひとつが、非同期処理を担うミドルウェアコンポーネントの改善です。新機能の追加によってインフラに想定以上の負荷がかかってしまい、改善が求められました。
KubernetesのCronJobやLeaseオブジェクトを活用し、Podのリーダーエレクションを自前で実装することで、負荷を大きく軽減する設計を提案。エンジニアリングマネージャーと相談しながら進めたこの改善は、自分のアイデアが形になり、プロダクト全体に影響を与えられた実感のある仕事でした。
プラットフォームエンジニアとして、仕事をする上で大切にしていることは何ですか？
この仕事で特に意識しているのは、信頼性です。プラットフォームは多くのプロダクトチームが共通で利用するため、ひとつの変更が大きな影響を与える可能性があります。
新しい機能を増やすことだけでなく、「最悪のケースでも被害を最小限に抑えられるか」「本当に安全にリリースできるか」を常に考え、慎重に判断しています。
その責任感こそが、この仕事のやりがいでもあると感じています。
私のオフタイム
- インタビュー内容は取材時点のものです。ご了承ください。