サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
都知事選
sonots.medium.com
CRuby, Fluentd, and Chainer committer. SRE, Specialist at ZOZO Technologies, Inc. ex-DeNA.
ZOZOが歩んできたテック組織の作り方 — クラウド時代のエンジニア像とは？ supported by AWS
ZOZOテクノロジーズとクラシコムさんの合同で社内でマネジメント勉強会を開催し、自分の方から４月に本部長になって感じたことや、実施していることについての共有を行いましたので、その時の資料を公開します。
MLOpsチームは４名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。 また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。 本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。 チームリーディングで気をつけていること私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と
ZOZOテクノロジーズでは、「社員がOSS活動しやすいようにする」というのをゴールに掲げて、2020年4月にOSSポリシーを策定しました。詳しくは techblog の方にも書いていますが、弊社のOSSポリシーには、以下のような特徴があり、非常にOSS活動がしやすい環境になったと思ってます。 業務時間中であっても指示なく自発的に作ったソフトウェアは個人のものにできる（例えば.emacsや.vimrcなどを指していますが、それに限りません）業務時間中に指示があって書いたソフトウェアでも著作権譲渡申請の許諾によって個人のものにできる従業員が自己の所有するOSSプロダクトに対して自己が業務で作成した著作物を取り込む場合、著作権譲渡申請がなくても個人の著作物にできる合わせて、社内的にはOSS公開ガイドライン、OSSコントリビューションガイドライン、OSS利用ガイドラインを用意して、OSS活動しやす
著者である小野さんは、起業したベンチャーを老舗金融起業に売却してその老舗企業でCTOを務めた人物である。私が現在、所属している企業と似たような状況にあるのではないか？と予想して読んでみた所、示唆に富んでいるところが多々あったので、久しぶりにブログにメモを残しておく。 第１章「谷」を埋めるな、「山」を作れ 特にベンチャーにおいては、競合他社がすでに実現している機能を実装するのに時間を費やすのではなく、自分たちの特色となる「山」に時間を費やすのが大事 コンサルを入れて実績のある方法論を導入して失敗するチームもある。 第２章「ハンマーと釘」の世界の落とし穴 新しい技術が日々生まれ、私たちエンジニアは「手にしたハンマーで釘を打ってみたい」衝動にかられながら仕事をしている。 とある企業のプロジェクトでは、新技術が出るたびに「新技術で既存の製品を作り替える」ということを繰り返していた。「新技術が出たか
以降は、今回の発表の個人的な感想です。 私個人として今回の発表の一番の目玉は、私自身の発表というよりも、幣チームメンバーの亀井（亀ちゃん）に発表してもらったことです。ID基盤についての設計思想から何から整理して最高の発表資料を仕上げてくれました。私は軽くレビューをしただけで何もする必要がありませんでした。 元々ID基盤のインフラは、１年ほど前にオンプレ歴は長いがクラウドも Kubernetesも初心者だったEnKUMAと亀ちゃん、そして私とインダクターの４人で始動した紆余曲折ありながらも進めてきたプロジェクトでした。今となってはチーム規模も大きくなり、新卒メンバーもJOINしたりと大きく変わっていますが、当初はオンプレとクラウドネイティブアーキテクチャの考え方の違いを教える所からスタートし苦労もありました。しかし、年下であるインダクターからも貪欲に学ぼうとする2人の姿勢は端からみていても感
新型コロナウイルスの影響でIT勉強会が軒並み中止または延期になってしまっている昨今ですが、4月24日に Forkwell さんの主催で大規模なオンライン勉強会 Infra Study Meetup #1 「Infrastructure as Code」が開催され、LT発表をしてきました。最終的には 2400 人を超える参加者表明があったようで、最初こそ配信トラブルがあってしまいましたが、非常に有意義な会だったのではないかと思います。 内容ももちろんそうですが、コロナの影響で勉強会が開けてない今、道を切り開く良いチャレンジだったのではないかと思っています。他の勉強会も続いてくれるキッカケになって、リモートで開催される勉強会が増えていくと個人的には嬉しいです。主催の Forkwell さん、まつもとりーさんありがとうございました。 さて、今回はリモートの勉強会で Infrastructure
1/25(土) に開催された「SRE Next 2020」 という日本では初めて行われる SRE (Site Reliability Engineering) に関するカンファレンスに登壇しました。 2019年4月にチームを新規に発足してから、どのようにチームを率いて成果を上げ、社内の信頼を得てきたのか 、メンバーの成長を促してきたのか、について語りました。 https://docs.google.com/presentation/d/1zEkR9Dm_epg7fxOCFE-asBsUlHDozwObsBEGAILiqic/edit#slide=id.p1 [B6] ZOZO MLOps のチームリーディングとSRE(Engineering) 私は2019年4月にZOZOにMLOpsチームを作り、それから10ヶ月ほどチームをリードしてきました。 その10ヶ月の間にZOZOでは買収も含め色々
4/1付けでZOZOテクノロジーズにMLOps (Machine Learning Operations)チームが作られ、そのリーダーを務めることになりました。全社のML案件のインフラ整備を進めていきます。 1月に入社してからまずはデータ基盤をやり、MLOpsをやるのはいつの話になるか分からないがそのうち、と書いていましたが、思っていたより早くまたMLに携わることになりました。拙作 Embulk プラグインの更新業をやりそこなった感がありますが、弊社(ないしは前職)のデータ基盤チームがやってくれるに違いない。 というわけで取り急ぎMLOps人材の募集です。会社の募集ページはこれから作ります。 ざっくりいうと以下のような人材を募集します。 MLに興味のあるコードの書けるインフラエンジニアもしくは、インフラ基盤整備に興味のある元AIエンジニア必須要件 1.コードが書ける 歓迎 MLの知識がある
入門kubernetesを読んだ。今更入門か？と言われそうだが、１年半ほどデープラーニングをやっていて、インフラ業から離れていたのでご容赦頂きたい。 これを読む前にk8s tutorialを読んだりしたが、圧倒的に物足りなかったので良い本はないかと探してこの本を読んだ。 正解だった。Kubernetesの作者が書いているので、単なる使い方だけではなく、設計指針なども書いてあって面白かった。 k8s は、コンテナの運用なり、Immutable Infrastructure のベストプラクティスを詰め込んで作った感がした。 k8s を使わないにしても、k8s の設計を知っておくことはアークテクチャ設計の上で役立つと感じた。 通読にかかったのは４時間ぐらいで結構サクッと読めた。ちゃんと試したりすればもっと時間がかかると思うが、概観を掴むにはそれぐらい。 目次 1章 Kubernetes入門2章
2018年12月に株式会社DeNAを退職し、2019年01月に株式会社ZOZOテクノロジーズに入社しました。 誰？瀬尾と言います。インターネット上では sonots (そのっつ) というIDで活動しています。 著名どころでは CRuby, Fluentd, Chainer といったOSSのコミッタをしています。 DeNAには2012年10月に入社し、6年弱勤めたことになります。 当初は mobage プラットフォームのインフラチームでWebインフラの運用、自動化を行うと同時に、Fluentdを用いたログ監視システムの開発、Railsアプリケーションの本番導入のための下周りの開発を行いました。 その後、分析基盤部に異動して、データエンジニアの経験を積むと同時に、分析用のウェブアプリケーション開発、AWS、GCPを使ったAI基盤の構築などを行いました。 最後の一年弱は縁あって、Preferre
メタ学習をここまでしっかりと分析したことはなかったので、脱帽。私のやり方と共感できる所が多かったので、やったことがないメソッドも自分にあってる可能性高い。 実際にやってみないとイマイチ肌感がわからないので、ちゃんと吸収するにはまだ時間がかかりそう。チャンスがあったら忘れずに試していく。 目次 第1章 新しいことを学ぶには第2章 やる気を出すには第3章 記憶を鍛えるには第4章 効率的に読むには第5章 考えをまとめるには第6章 アイデアを思い付くには第7章 何を学ぶかを決めるには第1章 新しいことを学ぶにはだいたい、他の章に書いてあることを言っているようなので省略 第2章 やる気を出すにはタスクを絞るタスクが絞れていないとやる気が出ない まずは全体像を把握する. Getting Things Done：まずすべて集める、そのあとで処理をする 処理する 「行動を起こす必要がないもの」をゴミ、資料
Rust Programming Language を読んだ。 多くのC++ユーザが、コーディング規約や linter でベストプラクティスとして縛っていたものを言語仕様として取り込んだ、C++ユーザの夢を叶えた言語というイメージを持った。 デフォルトで value semantics が move semantics だったり、 参照は immutable がデフォだったり、解放されたリソースへの参照が持てないようにライフタイム管理がコンパイラレベルでされたりする。 書籍としては、単語の定義がちゃんとされていないことがあったり（トレイト境界とか）、不意に細かい rust 内部の実装レベルに飛んだりして tutorial としては微妙な気がした。Rustプラグラミングの方を買って読むべきだっただろうか。一方、コンピュータアーキテクチャないしはコンピュータサイエンス的にはこう呼ばれる概念、の
タスクを順調に計画通りに進めるコツは、大きいタスクを小さく分割して１つずつこなしていくことである。 しかし、タスクによってはまるで先が見えず、タスク分割することすらできないことがある。研究要素の強いタスクはそういう傾向がある。 私の場合、具体的には Cumo プロジェクトをやり始めた時がそうだった。Ruby Association グラントに提出はしたものの、見えているものだけでもやることが非常に多く、さらにそのやり方が適切かどうかすら分かっていなかった。自然、やる気もでない(自分で提出したのに)。しかし、締め切りはある。 ポモドーロ・テクニックそこで試してうまくいったのが、ポモドーロ・テクニックである。 ポモドーロ・テクニックは簡単に言うと、「25分（集中）・5分（休憩）・25分（集中）・5分（休憩）…」のリズムで仕事をするというやつ。 ポモドーロ・テクニックは時間で区切る(私は)いつも
チームのマネジメントから始まり、複数チームのマネジメント、マネージャーのマネジメント、経営幹部と各段階における心構えを概観できた。 個人的にはチームのマネジメントはやったことがあり、複数チームのマネジメント辺りまではリアリティを伴って読むことができたが、管理者の管理など、それ以上はまだリアリティを持てなかったので、必要になった段階で再読しようと思った。 著者はマネジメントキャリアパスを進む前に、最低でも 1 種類のプログラミング言語を自在に使いこなせる程度の技術力は身につけておかないと、技術力不足とみなされキャリアパスが頭打ちになることがあると繰り返し言っており、個人的には DeNA 時代はマネジメントはやらないと宣言して技術研鑽だけしていたのは正解だったのかもと思うなどした（それが功を奏すのかはまだ何もわからないが）。 目次 1章 マネジメントの基本2章 メンタリング3章 テック
このページを最初にブックマークしてみませんか？
『sonots.medium.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
