米マイクロソフトに勤める牛尾剛氏によると、マイクロソフトでは、インディビジュアル・コントリビューター(IC）と呼ばれる開発者一人ひとりが個人商店のように扱われ、マネジャーは部下の主体性をサポートする「サーバントリーダーシップ」を徹底しているという。 部下に細かく指示を出して管理をする「コマンドアンドコントロール」が一般的な日本企業と比較すると、どのような違いがあるのか。『THE21』2025年1月号では牛尾氏に話を聞いた。（取材・構成：村上敬） ※本稿は、『THE21』2025年1月号特集「人が育ち、チームも伸びる最高の任せ方」より、内容を一部抜粋・再編集したものです。 初歩的な質問にも 「グッドクエスチョン!」 新人が活躍できる理由として、もう一つ、人に質問しやすい環境が整っていることも大きいと思います。 仕事を進めていけば、新人に限らず誰でもわからないことが出てくるものです。日本の場合

サービスプロダクト本部技術統括（TVerサービス開発部門内のVPoEみたいなポジション）兼バックエンド部部長の脇阪(@tohae)です。 この記事はTVerアドベントカレンダー 2024 25日目の記事です。24日目の記事はSREチームの鈴木さんの「AWS re:Invent 2024に1人で参加してきました」でした 今年の1月からEMとして入社し、約1年間開発組織の拡大や開発生産性の向上のためにいろいろな取組みを行ってきました。 本記事では約1年前のTVerのエンジニア組織がどのような課題を抱えていて、それに対してどのような手を打ってきたかというところをまとめます。 2024年初頭の課題 Q. 「機能開発をより早くしたい」は本当？ Q.「サービスを安定させたい」は本当？ Q. 「そのためにエンジニア組織を強く大きくしたい」は本当？ 課題解決の方針 エンジニア組織の人数を1年で倍にする 組

Twitter で DHH が共有していた記事が面白かったので著者の許可を得て翻訳します。 "If you don't hire juniors, you don't deserve seniors", spot on! We've had phenomenal success hiring junior developers at Basecamp. @jasonfried first tech hire was particularly junior at the time 😂https://t.co/QczMtsou4J — DHH (@dhh) September 21, 2018 ジュニアを採用しない連中はシニアに値しない、というもの。 If you don't hire juniors, you don't deserve seniors (2023) • Minimum V

私が日本で働いている時に頻繁に出会った存在が「〇〇だから出来ない」おじさんだ。誰かが新しい事に挑戦しようとしているのに「やめておきなさい」とか「〇〇だから無理」とか「弊社は特殊なので無理」とかともかく出来ない理由を探すことにかけて天下一品の人の事だ。 私は今アメリカのクラウドプラットフォームの開発者としてアメリカのレッドモンドというところで勤務しているのだが、ふと気づいたのが、日本であれだけ頻繁に見かけた「〇〇だから出来ない」おじさんに出会ったことが無い事に気づいたのだ。「そういえば全然いないぞ！」と。 今回はなぜ今の職場環境だとそういう人に出会わないかということを周りの人を観察して、考えてみて、少なくとも自分がそういう風にならない方法を考えてみた。 先日ふとX (旧Twitter) を見ていると、高齢からでもプログラマ挑戦できるはずがない。証拠をあげてみろ！という人がいて今の職についたの

創作者がＳＮＳで意見や情報を発信し、「作者の顔が見える」が当たり前になった今の時代。そんな中で「あえて発信しないこと」が持つ意味、ネットとの距離の取り方について、『鋼の錬金術師』『銀の匙 Silver Spoon』『黄泉のツガイ』などで知られる漫画家の荒川弘さんにお話を聞きました。 荒川弘（あらかわ・ひろむ） 北海道生まれ。1999年、第9回エニックス21世紀マンガ大賞受賞。2001年から10年まで「月刊少年ガンガン」連載の『鋼の錬金術師』（全27巻／スクウェア・エニックス）は全世界でシリーズ累計発行部数8千万部。11年から19年まで「週刊少年サンデー」にて『銀の匙 Silver Spoon』（全15巻／小学館）、06年からエッセイ漫画『百姓貴族』（既刊8巻／新書館）を連載。最新作は『黄泉のツガイ』（既刊9巻／スクウェア・エニックス）。 ＜漫画で描いて発散しちゃってるんでしょうね＞ ――『

イオンスマートテクノロジーは、絶えず変化する市場や顧客ニーズに応えるために2022年から本格的にデュアルトラックアジャイルによる開発を目指し、内製化に取り組んできました。今回は、組織立ち上げ・組織のスケール化・内製化率95%を達成した「道のり」を紹介します。スクラムガイドをベースにして立ち上げ時から再現性の高いアジャイル開発組織を組成すること・エンジニア採用が難しい中でパートナーとの協働で組織をスケールさせる方法・新旧メンバー混成チームでの価値・パフォーマンスの最大化の3点を詳しくお話します。

長いので3行まとめです。 最近、エンジニアリング経験の浅い方にアドバイスをする機会が増えてきたので、紹介時に使えるポインタをまとめました 何が合っているかは人によるので、正直正解はないと思いますが、少なくとも自分に効いたやり方をまとめています 合いそうなところだけをピックアップして真似してもらうだけでも全然いいと思います 「他にもこういうのをやったら伸びると思うよ!」というのがあったら、SNSなどで反応ください はじめに 真似するのが簡単で効果が大きい Pull Requestをセルフレビューする 趣味プロジェクトを持つ 参考: 自分が過去にやっていた趣味プロジェクト 真似するのは簡単で効果はそこそこ 地味な改善活動を拾い続ける 地道な活動例: READMEやsetupスクリプトの修正 地道な活動例: アーキテクチャ図を書き起こす / 改善する 仕組み化でチームや自分を楽にする 真似するの

アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由　日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ

2015年から続く個人の技術ブログ「Konifar’s WIP」。あえて雑に書くことをコンセプトに2017年に立ち上げた「Konifar’s ZATSU」。こにふぁーこと小西裕介さんはこれら二つのブログを通じて、いくつものヒット記事を世に送り出してきた。書いて発信しながら、キャリアを切り開いてきた一人だ。 エンジニアが発信すること自体は珍しくないし、その意義はさまざまなところで語り尽くされている。小西さんが書き始めたのも、そうした先達への憧れからだったという。 だからこれは個人的な物語。Kyashの「執行役員VPoE」を務める今、小西さんはかつての憧れの存在になれたのか。書いて発信することは、彼のキャリアの中でどのような意味を持ち、どう変化していったのだろう。 プロフィール 最初の記事から大反響。だけど一度は「書くのをやめた」 こにふぁーさんといえばブログでの発信があまりに有名なので。キャ

ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日

1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿で

PHPでアクターモデルを活用したSagaパターンの実践法 / php-saga-pattern-with-actor-model

こんにちは。たかやまです。 いままでいくつものIaCツールをベースにAWS構成図作成する作図ツールがでているかと思います。 ただ、これらは独自ツールでユーザー側で編集できないものだったり、作成された構成図のエクスポート先がPDFやPNGだったりと、後から修正や更新がしにくいという課題があります。 私は普段draw.ioやCacooを使ってAWS構成図を作成しています。 日々新しい生成AIモデルが登場していますが、draw.ioはXML形式で構成図が定義されるため、生成AIでも扱いやすいのではないかと考えました。 実際に試してみたところ、想定以上に高品質なAWS構成図を作成してくれたので今回はそちらをご紹介します。 さきにまとめ CDKやCloudFormation、Terraformのコードから直接構成図を生成できる モデルはClaude 3.5 Sonnet以上がおすすめ Anthrop

これはラムダノートの宣伝を含みます。 Web は専門ではないが、勝手にお勧めの本を書いておこうと思う。 ハイパフォーマンス ブラウザネットワーキング - O'Reilly JapanWebブラウザセキュリティ ― Webアプリケーションの安全性を支える仕組みを整理する – 技術書出版と販売のラムダノートReal World HTTP 第3版 - O'Reilly JapanWeb配信の技術 ―HTTPキャッシュ・リバースプロキシ・CDNを活用する - 技術評論社プロフェッショナルTLS＆PKI 改題第2版 – 技術書出版と販売のラムダノートいろいろなところで言っているがハイパフォーマンスブラウザネットワーキングを読んで欲しい。10 年以上前の本だが、古い部分は他の書籍でカバーすればよい。 セキュリティ関連は Webブラウザセキュリティがとてもわかりやすい。今や HTTPS ありきの時代にな

今日のお題 結局、CDKとTerraformどっちがいいんだろう、という宗教論争 それぞれをある程度触ってきた上での個人的見解を今後の自分のためにまとめます。 長くダラダラした記事なると思いますがご容赦を。 先に結論 CDK、非常にいいんだけれど、ちょっと辛いかも。 ずっと運用することを考えるとTerraformかな。 (2022/07/22追記) ・・・と思っていたが、使い方によってはCDKの方が良さそうという人になってきました。 その内容は　こちら そもそも、CDKとかTerraformってなんだ？ 一言で言えば、Infrastructure as Code(IaC)のツールです。 AWSに限らず、GCPやAzureなど様々なクラウドサービスがありますが、これらのクラウドサービス上でコードによりインフラ管理を行う仕組みがIaCです。 これにより、コードさえあれば、どのアカウントにも同じ