メソッド屋のブログ分かります。誰も使ってないんだから。やめといた方がいいですよね、正直話無理があります。開発者それぞれが責任を持って設計し実装する次は、僕のチームがどんな感じで運用されてるかっていうお話をします。マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。だいたいみんな似たような感じでやってると思います。基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。Contributorですね、開発者。マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。それぞれがレスポンシビリティを持っていて、それぞれが実装をする。同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」(バディ)みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。答えてくれやすいですね。他のチームとかになると、ちょっとバリアがあって。みんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。司会)ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。(右下の点線で囲われたところ)このチームはスケールコントローラをやっていて、(右上の3つのICを指して)このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。司会)隣のチームと、このチームを分けているのは、マネージャが違うだけ?ええと、大きな機能で分かれているというのがあります。Functionsのランタイムを担当してるんですよ。給料を上げるのは他人との競争ではなく自分との戦いさて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。参考:GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】この図がまさに僕が言いたいことなので、この図を使います。いう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。いうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。自分が給料を上げたかったらどうするかっていうと、プロモート(ランク上げ)してもらえるように頑張るって感じです。他の人との戦いじゃないんです。いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。やってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。いうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。他の人と比べて不公平とか全然思わない。給料を上げたかったら次のレベルになればいい。いうアクションをとればいいので、あくまで自分との戦いって感じになります。マネージャが自分の仕事やキャリアを助けてくれるマネージャの存在っていうのは僕的にはすごい(日本と)違ってるように感じています。日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。マネージャはみんなそういう動きをしてくれます。マネージャの大事な仕事「アンブロック」マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。いうブロックをされる状況が一番生産性を阻害すると思うんですね。いうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。基本的に納期の設定はない。マネージャも急かさないあと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。基本的に納期的なものはなくて、できたときが終了なんです。マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。これは多分いろんな意味合いがあるんですよね。クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。理解して、より良いアーキテクチャを作らないとひどい目にあう。マネージャは絶対に急かさないんだと思います。理解して出来るようになれば、次からは開発が速くなる。マネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。バックログはあり予定もあるが、達成されないこともしょっちゅう司会)すいません、マネージャの話しに行く前に。納期がないという話に関して皆さんが大混乱に陥っていてですね(笑)。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。いうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。それが今期に達成されないということはしょっちゅう起こります。思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。それでそのICが責められることはないです。変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。司会)お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか?僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略(ストラテジ-)とカスタマフィードバックですね。あとはハッカソンでエンジニアがなにかプロポーズするときもあります。いうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。それが達成されてリリースされるまでの期間は本当にピンキリです。僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。僕の上司で僕よりもプログラミングができない人はいないではマネージャの技術力の話に進みたいと思います。僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。彼らの技術力はどんな感じか。FunctionsのJavaランタイムをイチから書いた人です。Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。給料が高くて当然だと思いますね。これはAzureの主要なサービスをイチから書いていたりします。何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。いう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。こんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。≫次の記事に続きます。次の記事では、日本と米国のエンジニア層の違い、イノベーションの背後にあると思われるもの、そして会場からの質問などに答えていきます。関連記事2016年に行われたエバンジェリスト時代の牛尾さんの講演も非常に大きな反響がありました。あわせてお読みください。「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(前編)。2016「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化(後編)。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか(前編)。ガチ三流プログラマが超巨大クラウドの中の人に転生した話。2022超巨大クラウドのシステム開発現場を行動観察。MicrosoftPublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Copilotが複数ファイルにわたるコード変更や生成に対応。CopilotがAppleのXcodeに対応。Xcode」パブリックプレビューOrbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に[PR]日本人プログラマ向け、プログラミングに適した「フォント」まとめ。2024年版GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。100」の仮想マシンを正式提供開始JetBrains、JavaScript/TypeScriptのためのIDE「WebStorm」と.NETのためのIDE「Rider」、非商用利用ならば無償で利用可能に。