マネジメントでよく言われるセオリーとして、組織の「これをやらねば」という "must" とメンバーの「これやりたい」という "will" とメンバーの「これが得意」という "can" の重なるところを見出して目標設定やアサインをすべしという話がある。 特に "will" が大事で出発点にすべきという話も聞く。現在の興味領域である短期的な will に加えて、キャリア志向を踏まえた中長期的な will もきちんとすり合わせていくとよいという。まあわかる。人間やりたいことをやってる時が一番力を発揮できる。逆にやりたくないことをやっている時は全然パフォーマンスが出ないものだ。 わかるんだけど、メンバー "will" をどのように考慮するかって結構難しいなと思っていて、雑に考えを残しておきたい。 何が難しいというかというと、メンバーが考えている "will" というのはあくまで今のメンバーの目線で

アニメ『輪るピングドラム』に、 「きっと何者にもなれないお前たちに告げる」という名言があります。最近このセリフにある『何者にもなれない』焦りを感じることが多いです。 頑張って色んなことを勉強すればするほど何もできない自分に凹んでいくというか、なんだかよくわからないけどすごく焦ってしまいます。この 『なんだかよくわからないけど焦る』という感情を抱えた状態は結構しんどいので、ちょっと自分の思考を整理して言語化しておこうと思います。 と言ってもあくまで自分の感情の整理なので、論理的に矛盾しているところもあるかもしれません。すみません。。。 きっと何者にもなれない焦り 「あぁ自分はまだ全然ダメだなぁ」とか「こんなことして何やってるんだろう」と考えて、言いしれぬ焦りを感じてしまうことがあります。 まわりから見ると大して気にすることでもなかったりするんですが、本人からするとものすごく気になってしまうん

マネージャーは「面倒なことをやってくれる人」なのか 最近マネージャーな方を「面倒なことをやってくれる人」として認識されていることがあります マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ？」って言われることもあります なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります マネージャーは「面倒なことをやってくれる人」なのでしょうか 「面倒なことをやってくれる人」と思われる背景と影響 「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな？と思いました 自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です 結果としてメン

Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件（主に平均CPU使用率）を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握

www.itmedia.co.jp 住友商事傘下のシステムインテグレーターSCSKは11月6日、ネットワーク領域に特化したシステムインテグレーターのネットワンシステムズに対し、完全子会社化とその後の合併を目的とした株式の公開買い付け（TOB）を実施すると発表した。7日から12月18日にかけて行う予定で、取得金額は約3600億円。ネットワンシステムズは賛同の意思を示している。 最近のIT業界の象徴みたいなニュース。もうずっとこの業界の古豪のような二社がくっつく。 昔は、人の確保が簡単だったから、案件を受注する人が最も上。そして設計する人たちがいて、実装する人は一番下、みたいなヒエラルキーがあったものよ。 ところが、クラウドサービスの登場や、優れたソフトウェアのおかげで、設計したらそこから実装するまでの手間が格段に少なくなった。ヒエラルキーは崩壊し、二層構造ぐらいのシンプルなものになりつつある

マネージャーではなくとも、ある程度高い成果を期待されている人にはマネジメント能力を要求される。そういう話を雑に書いておきたい。 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 まとめ 私とオンボーディング 私にとって、今回が初めての転職となります。 これまではずっと受け入れる側の立場にいたので、改めて逆の立場になってみると、 「最初ってこんなに分からないものだったのか」 という想像以上の戸惑いと驚きがありました。 特に、会社の価値観や文化面の違いは新鮮な刺激として楽しみつつも、歯車を噛み合わせていくためには自分の中で十