山元 亮典 / ryosuke.yamamoto

職種
Engineering Manager
Data Engineer
Full stack
写真
36d014e9-f738-441c-bad0-615b229651b8_vuK%253B.jpg

自己紹介

鹿児島生まれ、横浜育ち。天然パーマです。マンガと酒が趣味で、特技はタップダンス。
早稲田大学でマルチメディアと機械学習の研究を行い、修士号を取得後、Yahooに入社。 Yahoo社ではヤフー検索のバックエンドをフルスクラッチで開発していました。
Voicyではエンジニア部門の責任者として開発組織全体の統括をしており、チーム設計/アジャイル開発導入/エンジニア組織開発などを行いながら、インフラとサーバサイドとデータ/機械学習領域ではプレイヤーとしても従事しています。
エンジニアリングが大好きで、学生時代にはフルコミットでiOS開発にチャレンジしたり、技術書の翻訳で出版歴もあり、新たな技術に取り組み、挑戦し続けることを大切にしています。

Voicyの好きなところ

稀有なカルチャーで稀有な事業にチャレンジできる環境

好きなVoicyパーソナリティ

私が思う「声で未来をつくる」

カジュアルに話してみる

経年インタビュー

入社エントリー

メディア

ピックアップコンテンツ

Pythonではじめるソフトウェアアーキテクチャ - 共立出版
スケーラビリティ、頑健性、セキュリティ、パフォーマンスが優れているアプリケーションをPythonで実現!  本書は、Pythonを用いたアプリケーション設計方法を様々な観点から解説します。ビジネス要求を満たす製品を構築するためには欠かすことのできない、保守性、再利用性、テスト容易性、スケーラビリティ、パフォーマンス、ユーザビリティ、セキュリティを取り上げ、読者が頑健かつ柔軟なソフトウェアの設計方法を理解することを目的としています。  またDevOpsや継続的インテグレーション、最適なオブジェクト指向の使用方法なども紹介しています。これらを理解することで、読者はビジネス規模が拡大しても耐え得る、スケーラブルなアプリケーション設計を構築できるようになるでしょう。  アプリケーション構築に欠かせない、各フレームワークのメリットなどにも焦点を当てており、これからアプリケーションを設計しなければならないエンジニアにとって価値の高い実践的な内容も含んでいます。特に第7、8章で解説されるデザインパターンとアーキテクチャパターンは、汎用的に使える知識であり、たとえPythonを使用しないエンジニアでも大きな恩恵を受けることができるでしょう。 本書で学ぶこと - 品質属性を正しく考慮したプログラムの実装 - スケーラブルなWebアプリケーションの設計 - Pythonの特徴を活かしたデザインパターン - テストツールを用いたパフォーマンスの最適化 - Pythonアプリケーションをリモート環境やクラウドへデプロイする方法 - Pythonのセキュアアーキテクチャアプリケーション 第1章 ソフトウェアアーキテクチャの原則 1.1 ソフトウェアアーキテクチャの定義 1.2 ソフトウェアアーキテクチャの特性 1.3 ソフトウェアアーキテクチャの重要性 1.4 システムアーキテクチャとエンタープライズアーキテクチャ 1.5 アーキテクチャの品質属性 1.6 まとめ 第2章 修正容易性と可読性 2.1 修正容易性とは 2.2 修正容易性に関連する品質属性 2.3 可読性とは 2.4 可読性向上のテクニック 2.5 凝集度と結合度 2.6 修正容易性向上のテクニック 2.7 静的解析ツールとメトリクス測定 2.8 コードリファクタリング 2.9 まとめ 第3章 テスト容易性 3.1 テスト容易性とは 3.2 テストの戦略 3.3 ホワイトボックステスト 3.4 テスト駆動開発 3.5 まとめ 第4章 パフォーマンス 4.1 パフォーマンスとは 4.2 ソフトウェアパフォーマンスエンジニアリング 4.3 パフォーマンステストツールと測定ツール 4.4 計算量 4.5 パフォーマンス測定 4.6 プロファイリング 4.7 その他のツール 4.8 データ構造のプログラミングパフォーマンス 4.9 まとめ 第5章 スケーラビリティ 5.1 スケーラビリティとパフォーマンス 5.2 並行性 5.3 マルチスレッディング 5.4 マルチプロセッシング 5.5 マルチスレッディング vs.
EMの定義から考えてEM始めました - voicy tech blog
こんにちはエンジニア リングマ ネージャの山元です。 この記事はVoicy アドベントカレンダー 23日目の記事です。 最近社内の特にPMチームで自分の役職を説明している記事が増えていて、 確かにマネジメントって 言語化 しないとわからないよなあ〜と思って 影響されて自分も書き出してみたいと思いました。 ぜひプロダクトチームのみなさんの記事も見てください (文面真面目人間なので、キャッチーな文章かけて羨ましいです!) PMの長のぶんたさんの記事 PMMのDさんの記事 この記事ではEM歴6ヶ月の自分が、「EMってなんだ?」から「こういうことやってるよ〜」となった思考のプロセスをつらつら書いています ぜひ以下のような人にぜひ! EMになりたいエンジニア EMのことを理解したい人 EMやっていて他社事例を知りたい人 まさかのここからです笑。 本などを読んで初めて知ったのですが、「EMが何か」は実は世の中の人はちゃんと教えてくれなくて、まるっと「適材適所だよ〜」と書かれています。 EMになったらまずEMの定義を作るのが仕事かもしれません。 前提としてマネジメントの言葉の定義を決めておくと ドラッガー 氏の「組織に成果をあげさせるための道具、機能、機関」が良いと考えています。 ではエンジニア リングマ ネージャは何をする人でしょうか? ソフトウェアファーストによると以下です。 実装を担当するソフトウェアエンジニアを取りまとめる役割です。 及川 卓也. ソフトウェア・ファースト (Japanese Edition) ( Kindle の位置No.3124-3125). Kindle 版. ここではエンジニアという人のリソースで成果を上げているマネージャですね。ピープルマネジメントで1on1してそうだな〜なんてやることが想像つきますね。 そしてソフトウェアファーストにもしっかり適材適所ですよと書かれています。 これらはあくまで筆者が一般的な開発にあてはめて職種と役割を 言語化したものなので、当然、企業や開発するプロダクトの性質によって細かい役割の違いがあっても構いません。大事なのはこうした職種を置くことではなく、それぞれがきちんと役割を全うし、機能させる環境を整えることにあります。 及川 卓也. ソフトウェア・ファースト (Japanese Edition) ( Kindle の位置No.3131-3134).
SQSから10000レコードのバッチをLambda + Goで高速で処理する方法 - voicy tech blog
こんにちはVoicyで技術責任者としてエンジニア リングマネージャとか色々やってますやまげん@yamageniiです。 最近 Twitter 頑張ってるので、よかったらフォローしてください。 どれだけマネジメントが忙しくなっても、プレイヤーとして現場に入りたいと考えていて ボトルネック にならない範囲やお助けタスクなどでまだまだ実装をしています。 今回は自分がVoicyで実装した時のTipsを紹介します。 早速本題に入るのですが、今回は「SQSから10000レコードのバッチをLambda + Goで高速で処理する方法」を紹介します。 SQSはスケーラブルなメッセージングキューで、大量のアクセスを取りこぼさず処理をすることができます。 SQSではメッセージ処理にLambdaを利用することができるので、サーバレスに大量のメッセージを処理するのは簡単になったと思います ただし無限にスケールするメッセージをLambdaが無限に起動して処理をしてくれるなどというものではなくて、リソース制約があります。 例えばSQSで FIFOキューを利用しない場合はLambdaでは最大10000件のレコードを処理することができます。 AWS公式 Amazon SQS での Lambda の使用 その他にもLambdaは 自動起動数などの制限もあります。コスト節約のためにLambda実行数は抑えたいと考える人は多いかもしれません。 そうなるとLambda1つあたりに処理するレコードはなるべく増やしたいはずで、最大数の10000件に近いレコードを処理したいはずです。 それらを直列で処理をしたいということはあまりなく、並列で実行したい ユースケース がほとんどでしょう。 今回はそういった ユースケース をGo言語で実現する方法を紹介します。 Lambda Go 1.x 公式ドキュメントを読みましょう。課題に詰まってから公式ドキュメントに戻ると大体書いてあるというのはあるあるです(反省してる顔) これを見るだけでも大量のレコードをSQSLambdaで処理する時の スループット に関わる様々な抑えるべきポイントがあります。 バッチサイズが 10 を超える場合は、MaximumBatchingWindowInSeconds パラメータも 1 秒以上に設定します。 Batch window (バッチウィンドウ) - 関数を呼び出す前にレコードを収集する最大時間

音声アウトプット

テキストアウトプット