マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 1人でガッと進められる範囲の仕事のインパクトには限界があり、あるレベル以上に達すると、誰かに何かを依頼したりチームを超えて足並みを揃えたりする必要が出てくる。 ここで要求される能力には、チームビルディング、ネゴシエーション、ファシリテーション、スケジューリング、ロードマップ作成といったものも含まれる。マネージャーロールではない場合、「これってマネジメントなのでは？」と感じることもあると思う。それに対する自分の答えは「Yes」である。仕事のインパクトの大きさを広げようとすると、マネジメントと同じようなスキルはプレイヤーにも必要になる。結局 Manage (なんとかする) 能力も技術と捉えて磨いていく方がよい。 つまるところ、いわゆるマネージャーとプレイヤーの違いは、

最近雑じゃなくなってきた気がするのでより雑めに垂れ流すことにする。 自分が苦手だと思い込んでいたことが、苦手とかそういう属性次元の話じゃなくて事前の準備が足りないだけということがある。 たとえば、自分は「メールが苦手でつい見逃しちゃうんですよね」と言っていたことがある。Slackだとすぐ反応できるのにメールだと億劫になってしまうのだ。 少し時間を取ってラベルを整理したりSlackに連携して流すようにしたりすることで解決した。苦手とかではなくて、単に工夫のひと手間をサボっていただけだった。 人前で話すのも苦手と言って避けていたことがある。 話すのがうまいように見える人にどうしてるか聞いて観察してみると、自分より入念に調べてフィードバックをもらって10倍リハーサルをしていた。苦手とかではなくて、単に補うための準備が足りていないだけだった。 懇親会でボッチになるのが苦手と言っていたことがある。話

ソーシャル経済メディア「NewsPicks」SREチームの美濃部です。 NewsPicksではアプリケーションのビルドにAWS CodeBuildを使用しており、ビルドキャッシュの格納先としてAmazon EFS（AWSのフルマネージド型NFSファイルシステムサービス）を利用しています。 アプリケーションビルド構成 以前はS3に格納していましたが、EFSにする事でビルド時間が2分程短縮できる事がわかったので多少コストを払ってでも開発者の生産性を重視しました。1日に何度もビルドを行う開発者にとってこの2分の積み重ねは大きな価値があります。開発者の人数が多ければ多いほどこの価値もあがります。 ただし、想像以上にEFSの利用料金が発生してビルドに関わるコストが上がってしまいました。 この記事ではバーストクレジットを効果的に活用することでコストを4分の1に削減する事に成功したお話をしたいと思います

はじめに 皆様こんにちは、ソーシャル経済メディア「NewsPicks」(Media Infrastructureチーム)エンジニアの北見です。 弊社では Server Side Kotlin を採用しており、昔に書かれた一部のコードは Java ですが、基本的に新規コードは Kotlin で書いており、既存の Java コードも Kotlin 化を推し進めています。 tech.uzabase.com tech.uzabase.com 今回は Kotlin の sealed class を使って、コードをシンプルにする例をご紹介します。 kotlinlang.org 微妙に異なるけど殆ど同じ処理を共通化 例えば、クレジットカードとキャリア決済の2通りで商品を購入するユースケースを考えてみます。 class PurchaseService( val productRepository: Pro

社員数が1000人を超えてから、組織的にはいろいろと「よろしくない面」が出てきました──。サイボウズ代表の青野慶久はそう打ち明けます。 かつてのサイボウズでは考えられなかった出来事が起きたり、社歴の差による考え方の違いが出てきたり。2024年には、これまで胸を張って掲げてきた、働き方に関する表現を見直す決断もしました。 このままサイボウズは、よくある大企業の1社になってしまうのか。サイボウズが変えるべきもの、守り続けるべきものとは。 他社でも同じような悩みを抱えるケースは少なくないはずです。組織が拡大するなかで、企業としての成長と、社員一人ひとりの幸福を両立し続けていくためには何が必要なのでしょうか。 サイボウズの社内大学「CAAL（カール）」卒業生の2人が青野を囲み、本音を語り合いました。

先日、DevLOVE関西の200回目を記念するイベントで登壇してきました。 登壇内容を考えるにあたって、大きく2案あったので、没にしたほうのネタを簡単にブログに書いて供養しておきます。 ロックバンドの成功の証は、日本武道館でのライブである、みたいなイメージがなんとなくあります。 地元の小さなライブハウスで、客席に友人しかいない状態で演奏するところからはじまって、そこそこ有名になり、対バンに呼ばれるようになって、ソロでライブハウスが埋まり、Zeppなどの大きなハコでやるようになって、そういうステップアップを繰り返した先に、ついに武道館を満員にする。 そのときの彼らの気持ちは、どんなものなんだろうか。 自分にとって、かつて武道館のような舞台がありました。 今は会場が変わりましたが、かつては毎年目黒の雅叙園で開催されていたデブサミ。ここは自分にとっての武道館のようなものでした。 2010年ごろに

[アップデート] AWS Lambda コンソールのコードエディタが Visual Studio Code ベースでリニューアルされました いわさです。 先日のアップデートで AWS Lambda コンソール上で使えるコードエディタが新しくなりました。 前回 Lambda コンソール上の CloudWatch Logs Live Tail 機能が実装された時にそんな予兆を感じており、その時点ではオレゴンリージョンでのみ今回の新しいエディタが使える状態でした。 re:Invent も近いですし、近々 Lambda のコードエディタアップデートされるのかもしれませんね。ちょっと楽しみですね。 今回のアナウンスで Lambda が使える全リージョンに展開されたそうです。 Code-OSS (VS Code open source) のコードエディタ 以下に AWS Lambda コンソールコード

仕事もそこそここなせるようになり、周りの人間も安心してタスクを渡せる「中堅」と呼ばれる層。ある程度難しいタスクも自走して調査・調整をしてゴールまで導いてくれるが、ベテランレベルである「1人で全てをいい感じにしてくれる」には至っていない。 中堅層になると急に成長が鈍化する。この原因を考えてみる。 褒められなくなる若手であれば少しの成果でも褒められ称賛される。しかし中堅層になると褒められることがほとんどなくなる。これは「この程度のことやりきれて当然」と本人も周囲も考えていることと、「褒めたら逆に失礼になるかも」と周囲が考えるため、よほど大規模な成果をあげなければ褒められなくなる。 褒められなければ当然ながら自己肯定感は下がり、モチベーションも低下する。褒められるなどの外的な報酬に期待が持てないのに、成長を続けるのはなかなかに難しい。 指導・注意されなくなる指導・注意は多くの場合上長・先輩など上

メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、Amaz

人がやる気になる理由というのはそんなに単純に整理できるものではないが、自分にとっては"報酬"と"成長"と"貢献"の3つのバランスで成り立っていると感じる。 そんなに整理できていないので雑にまとめておきたい。 報酬 いくらもらえるかはめちゃくちゃ大事 報酬で自分の価値を確認できるという人もいる 安かったらいざという時に踏ん張れないし、高かったらその分頑張ろうと思える 成長 自分のためになっているか、成長しているかという感覚もめちゃくちゃ大事 まわりに尊敬できる人がいるとか、近くで働いていると刺激を受けるとか勉強になるとか 成長実感以外でも、すごい/かっこいいと思われたいみたいなのもこれ 貢献 同僚の役に立てたり、ユーザーに喜ばれたりする感覚もめちゃくちゃ大事 自分の力を何かしら活かせているかという話で、これを満たしていると自己肯定感も高まっていく 全部大事と書いてしまったけれど、年齢やライフ

こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上

来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は

はじめまして、asachiです。 普段はプロダクトマネージャーとかデザインとかをやっています。 最近、会社・事業のインフラコストをどう評価するかという話に社内でなって、実際各企業どんなもんなんだろうなと気になり、IR資料から頑張って漁ってきました。 せっかく色々と見たので、気になった事例等含めて書いていこうかなと思います。 TL;DR 上場企業のインフラコストを調べた 規模・業態問わずで30社くらいのデータを発掘できた 最もコストがかかっていたのはゲーム会社アカツキ約11-12億/年 次点はツイキャス運営のモイ 約5.8億/年 「メメントモリ」が流行ったため、BANK OF INNOVATINが直近四半期でサーバー費用が3億円/四半期(前年同期比1,153%)になっていた 各種会計項目に対してサーバー費の比率が安定しているのは、GunosyとGameWith 売上原価に占める割合が高いのは

7月くらいに入社した同僚氏は「問題を放置しない」が口癖で、半ば麻痺している痛いところを突いてはすぐに何かしらアクションに移して状況を変化させている。ハイレベル問題解決ブルドーザーである。 「これは放置しないほうがいいですね」、「放置しないほうがいいのでやりましょう」といった感じで話してくることもあれば、「これどうします？放置しますか？」のように聞いてくることもある。見て見ぬふりをしたり、なんとなく結論が曖昧な状態のままにしておくことを"放置"と言っているらしい。ややこしい言い方をすれば、"今は (いつまで) 放置する"と決めたのであればそれは放置してはいないということなのだそうだ。 先日、彼が会議中にボソッと「問題を放置さえしなければちょっとずつよくなっていくんですよ」と言っていて、たしかになあとしみじみ噛み締めてしまった。 何かチャレンジをしていれば問題が多々発生するのは当たり前ではある

初めましてこんにちは！ ソーシャル経済メディア「NewsPicks」プロダクトエンジニアの 寺坂 です。 2024年5月に中途入社して4ヶ月が経ちました。 だんだんと会社にもチームにも慣れてきたぞ！、ということで、今回は私のオンボーディング体験をご紹介します。 初めましてこんにちは！ 私とオンボーディング オンボーディングカリキュラム ユーザベースでは、パーパス・バリューがとても大事 オープンコミュニケーションと風通しの良さ とても手厚い1on1 まとめ 私とオンボーディング 私にとって、今回が初めての転職となります。 これまではずっと受け入れる側の立場にいたので、改めて逆の立場になってみると、 「最初ってこんなに分からないものだったのか」 という想像以上の戸惑いと驚きがありました。 特に、会社の価値観や文化面の違いは新鮮な刺激として楽しみつつも、歯車を噛み合わせていくためには自分の中で十

クラウドストレージ、特にオブジェクトストレージについて質問があります。 AWSを例に出すとS3への書き込み速度と読み込み速度はローカルのHDDとSSDの中間くらい出ている認識です。そのような性能を持っているのに25ドル/TBのような安価で提供できているのはどのような実装がされているのでしょうか？ 軽く検索するとS3のレイテンシは1桁ミリ秒、帯域はクライアント側のネットワークがボトルネックになるまで(つまり100Gbpsレベル)出るようですね。しかも99.999999999%(11ナイン)の耐久性という数字は生半可な努力で出せる数字ではありません。 なぜそんな高速なストレージがこんなに安いのかというのは一言では「経済の力」となりますがもう少し噛み砕くといくつかの要素があります。 S3はまき餌かも知れないクラウドビジネス各社ではオンプレミスやコロケーションで顧客自身が契約している物理ハードウェ

AWSの東京リージョンでFargate Spotを「中断されたら困る」割合で利用している場合、2024年10月は見直し時かも知れません。 はてながECS Fargateで運用しているWebサービスの多くは、状況に応じてリクエスト数≒負荷が増減します。 これに対して、リクエストを受け持つECSサービスのタスク数をオートスケールさせてコスト最適化を図っています。 ボトルネックはCPUで、CPU使用率を追跡していることが多いでしょうか。 オートスケールで追跡する使用率にはスケールアウトまでの間の負荷に耐えるための余裕を持たせます。 この余裕の部分をSpotタスクで確保することで更にコストを削減できます。 AWS Fargate Spotの発表で示されているユースケースでは以下に該当します。 また高可用性を求められるウェブサイトやAPIサーバーのように、ECSサービスの一部となるタスクに対してもF

こんにちは、レシピ事業部プロダクト開発グループの赤松(@ukstudio)です。 昨年の10月頃からレシピ事業部ではひとつの大きなプロジェクトに取り組んでいました。このプロジェクトは社内ではOne experienceと呼ばれています。本記事ではこのOne experienceについてご紹介します。 One experienceとはなにか クックパッドではレシピサービスを日本を含めた71ヶ国、29言語で展開しています。これまでは日本のサービスと海外のサービスは独立した別のシステムで別のサービスとして展開してきました。日本のレシピサービスは日本の組織が、海外のレシピサービスはイギリスにオフィスを置く海外の組織によって開発・運営を行なっていました。 One experienceはこの独立した2つのサービスを1つに統合し、国内・国外関係なく、全ユーザーに同じ体験を提供することを目的としたプロジェ

はじめに ソーシャル経済メディア「NewsPicks」SREチーム・新卒エンジニアの樋渡です。今回は、AWSサービスである「Lambda」「CloudFront」「S3」を用いて、弊社で使用している社内向けシステムの基盤を再構築し、開発者体験の向上やセキュリティ対策を行なったお話です。 お話の内容 弊社で使用している社内向けシステムの一つに「Watson」というシステムがあります。「Watson」とは簡単にいうと「NewsPicks」のユーザーIDをもとにユーザーごとの情報を検索・閲覧できるシステムで、お客様からの問い合わせ対応等に活用される重要なシステムです。「Watson」は構築されたのが８年前と歴史が古く、歴史が古い故に数々の問題を抱えていました。今回のお話では、歴史の古い社内システムのインフラとバックエンドを更改し抱えていた問題を解決したぜ！というお話となっています。 抱えていた課

2024/10/5 YAPC::Hakodate 2024