こんにちは。第一ビジネス部の高田と古謝です。
2/13.14に開催された「Developers Summit 2025」に原田さんと一緒に参加してきたので、私たちも受講の感想をレポートします。
◾️Architecture to Design より良い設計を目指して(高田)
このセッションでは、設計の本質を捉え、どのように考え、進めていくべきかが体系的に説明されていました。
単なるテクニックの紹介ではなく、設計の根幹となる考え方を深く掘り下げた内容で、設計に対する理解をより深めることができました。
特に印象的だったのは、設計において重要なことは個々の原則を暗記することではなく、その背後にある原理を理解することだという点です。原理を正しく 理解することで、状況に応じて適切な原則を選択し、適用できるようになるという話は非常に納得感がありました。設計の原理が適用の軸となり、そこに原則をどう当てはめるかが鍵になるという視点は、今後の学びや実践においても意識していきたいと感じました。
私はキャリアパスとしてアーキテクトを考えているため、このセッションの内容は非常に参考になりました。
登壇者の米久保さんは「アーキテクトの教科書」の著者でもあり、設計に関する体系的な知識を持つ方なので、その視点から語られる内容には多くの学びがありました。今後、自身のスキルを磨きながら、設計の原則を理解し、より良いアーキテクチャを追求していきたいと改めて感じました。
余談ですが、「アーキテクトの教科書」はすでに電子版で購入済でしたがサインが欲しかったので書籍版を改めて購入しました。
◾️スタートアップ1人目QAエンジニアがQAチームを立ち上げ個からチームそして組織に成長するまで(高田)
こちらは登壇者の方が立ち上げ期にQA（Quality Assurance）エンジニアとして1人でPRJへ参画し、体制が大きくなっていくなかでの経験談を共有するセッションでした。
特に印象的だったのは、「再現性」を意識することと、育成の観点から「失敗」を経験してもらうことの重要性です。個人が担っている業務を仕組み化し、誰が担当しても同じ成果が出せる状態を目指すことで、組織としての強さが生まれるという話には納得感がありました。加えて、経験豊富なメンバーが過度に介入せず、若手の成長を見守ることの重要性についても触れられていました。短期的には、経験豊富なメンバーの介入が早期の解決に繋がるかもしれませんが、長期的にはそれが若手の成長機会を奪い、学びのチャンスを減らしてしまうことになります。経験豊富なメンバーが過度に手を出すのではなく、適切なサポートをしながら、若手が自らの力で成長できるような環境を提供することが大切だと感じました。
現在関わっているプロジェクトでも、特定のメンバーの経験やスキルに依存している部分があり、チームとしての体制をどう築いていくかが課題になっています。今回のセッションで得た「再現性」と「失敗」を経験してもらうという視点は、こうした課題に対するヒントになりそうだと感じました。
◾️急成長する企業で作った、エンジニアが輝ける制度(高田)
本セッションの内容はタイトルの通りで、中で触れられていたスキルツリーの整理と多面的な評価が特に印象に残りました。
スキルツリーは、エンジニアがどの技術分野をどのレベルまで習得しているのかを可視化する仕組みで、業務を通じて得たスキルが体系的に整理されることで、自分の強みや今後伸ばすべき領域が明確になり、計画的な成長につながると感じました。
また、技術スタックとロールの二面での評価という考え方も興味深かったです。技術スタックを軸にした評価では、エンジニアが習得した技術力そのものを正当に評価できるようになっています。一方で、ロールの評価だけだと、プロジェクト内での役割や立ち回りが中心となり、技術力の向上が評価に直接結びつきにくいこともあると気づきました。今回のセッションでは、この二つを組み合わせることで、エンジニアが専門性を高めながら、組織貢献も正しく評価される仕組みが紹介されていました。
業務を通じてスキルを身につけることはもちろん重要ですが、それがどのように評価されるかによって、成長の方向性が大きく変わるのだと改めて感じました。今回のセッションで得た学びを、自分自身のキャリア開発や後輩の育成の中でも意識していきたいと思います。
■楽天ペイにおける障害対応の実践と学び – WAR ROOMは精神と時の部屋 –(古謝)
私自身金融系のシステム維持保守業務に携わっており、他企業のシステムでは維持保守業務でどういう取り組みをしているのか気になり受講しました。
我々と異なった点として、楽天ペイでは開発チームと別にサービスオペレーションチームが設けられている点でした。金融系システムでは多くのシステムが複雑に連携して動作しているため、開発チームと保守チームの境界が結構曖昧になっていることがあると考えています。それ故に、システム障害で手を取られると開発業務への影響が出て遅延につながる、といったことがあるかと思います。
一方、楽天ペイではシステム全体を俯瞰できるソリューションを取り入れ、何か障害が発生するとすぐに対応に入れるサービスオペレーションチームを設ける取り組みが紹介されていました。システム全体の障害発生頻度や複雑度の違いもあるかと思いますが、理想的な体制になっていると個人的に思いました。その体制を実現するために、保守メンバの育成やオペレーションの整備などにも力を入れていることが伝わってきました。
また、障害対応の際はサービスをいかに早急に復旧させるかが重要になってくることから、障害対応をやる度にシステムに関する知識が深まり、成長が加速する感覚がある、ということに触れられており、とても共感しました。
私自身もこれまで大きいものから小さいものまで障害対応をいくつも対応してきたこともあり、その度に自身のエンジニアとしてのスキルが向上していくような感覚がありました。その点については、他システムの業務に携わっていても共通してくる価値観なのであるという気づきがありました。
■「スタッフエンジニア マネジメントを超えるリーダーシップ」 時代の変わり目に考える自分のキャリア(古謝)
スタッフエンジニアというキャリアは1年ほど前から認識していましたが、具体的なイメージを私自身持っていなかったため、詳しい話が聞けると思い受講しました。
このキャリアは「技術力を武器にしたテクニカルなリーダーシップを発揮する役割」となっており、海外ではメジャーなポジションと紹介されていました。日本で近い役割だとテックリードやアーキテクトが該当しますが、実態として具体的に何ができればスタッフエンジニアと呼べる、といった明確な定義はない、と触れられていました。スタッフエンジニアは技術力が単純に高いだけでなれるものではなく、あくまで組織への技術的貢献が高い人がなれる（≒その貢献を組織から認められる）ことが一番重要という話が特に印象に残りました。
私自身がエンジニアとしてのキャリアを志す中で、技術力自体はそこまで高くないと自覚していたため、このまま進んでもいいか悩んでいる部分がありました。しかし、今回組織への技術貢献を念頭に置くことで進んでいけるキャリアもあるということがわかり、悩みが多少解消に向かいました。
私がこのキャリアを志すかどうかはまた別ですが、エンジニアのキャリアの一つの選択肢として 会社内で設置されると、同じようにキャリアに悩みを持っている社員の助けにもなるかなと感じました。
私は今回のような大きなイベントに参加することは初めてだったため、 社外のエンジニアの方々を知る機会として参加を決め、とても刺激になりました。また是非こういったカンファレンスや勉強会に積極的に参加していきたいです。