  |
はてなキーワード: スクラムとは
https://www3.nhk.or.jp/news/html/20220317/k10013538631000.html
んで、停電伴う地震では必ずこのアークによる発光現象は起こるんですのよ。
https://www.youtube.com/watch?v=VrY_k_pdlCs
これは活線状態の送電線をカットする断路器ってやつで、巨大なアークが発生してるのが判ると思う。
因みにアークが上っていくこの現象をjacob's ladder（ヤコブの梯子）っていうよ。
空気は絶縁体なんだけど一定以上の電圧掛けると絶縁破壊って現象が起きる。絶縁破壊された空気に電気が流れるとプラズマ化してアークが発生する。プラズマは熱いので上に登る→ヤコブの梯子→距離が長くなりすぎて電気が流れなくなる、って機序。
しかも紫外線と赤外線をバカみたいに出す。だから工事現場の溶接の光を直接目で見ちゃうと網膜が痛んで目が痛くてその夜は寝れなくなるよ。
変電所断路器のアークも近くで見ちゃうと目が思いっきりイカレると思うよ。溶接のアークが夏の太陽の50倍以上の紫外線を出すと言われてるので、断路器のアークなら数百倍？
TVやエアコンのリモコンが電池切れか判らないときのテクとして、スマホやデジカメで撮りながらリモコンのボタンを押すっていう手がある。
すると見えなかったリモコンの光が見えるんだな。これはリモコンが赤外線LEDを使っていて、デジカメセンサーは赤外線の波長を感知出来るからで、モニタの方は赤外線表示は出来ないからピンクっぽい白色（ハレーション）で表示するからだよ。
因みにリモコンは赤外線の点滅によるパターンで通信しているよ。簡易的なシリアル信号だ。
だから変電所のアーク光は可視光だけでも眩しいのに、デジタルカメラは更に赤外線までつかまえて白い光としてモニタやTVに表示させるので爆光に見えちゃうのだな。
じゃあ何で地震では断路器が作動して停電するの？って事なんだけど、これは発電所を守るために自動で行われるよ。
まず、大きい揺れに見舞われた発電所は自動で緊急停止するよ。原発だったらスクラム（制御棒全挿入）セにゃならない。
火発や水発の場合は、大質量のタービンがグルグル回ってるわけだ。地震でグラグラ揺れたら軸受けが壊れてしまうね。だから圧力を逃がしてタービンは停止させる。
当然発電は出来なくなるし停止前に異常な電圧や周波数が出力されてしまうから地震を感知したら速攻で断路器を作動させて送電網から切り離すよ。
するとその分の負荷は他の発電所に行くね。
それでそこの発電所が過負荷になると…周波数が落ちるのだ。富士川より東が50Hzとか西が60Hzとかのあれだよ。夜に自転車漕いでて上り坂でダイナモの発電量が落ちて暗くなるのと同じ。
この過負荷で周波数が落ちた瞬間っていうのは、照明やTVやモニタが点滅したり、TVや電源がしょぼいデスクトップパソコンが再起動したりするよ。地震の時に経験あるのでは？
この時に発電所の負荷を下げる為に変電所が負荷遮断を行う。それが例の断路器の作動で、眩しいアークが発生するのだよ。
変電所には周波数を監視するリレーがあって、周波数が下がったら速攻で自動で作動して、その受電地域は全部停電してしまう。
じゃあ負荷遮断しない場合はどうなるか？というと、送電周波数が下がると他の発電所は同調出来なくなる。電圧マイナスになってるタイミングでプラスの電圧繋げば過電流が流れたり発電機が壊れる。
だからその予防の為に発電所が自動遮断するのね。遮断されると無負荷になるから発電機がブンまわってしまうね。なので緊急停止も必須だ。
そしてその自動遮断カスケードは連鎖していき、僅か数秒で全部の発電所が停止して全域ブラックアウトになるというヤバい事態になってしまう。
ここに2018年の北海道胆振地震での全域停電のレポートがあるけど（PDF）
http://www.iee.jp/wp-content/uploads/honbu/03-conference/19-taikai/symp/h1-1.pdf
発電所停止→周波数低下で変電所負荷遮断はされたのだけどその後がうまく行かなくて周波数低下と新たな負荷遮断を繰り返して結局全発電所停止、全域停電という事態になってしまった。（6頁）
一旦全域ブラックアウトになると段階的に復旧しなきゃいけないので停電時間は数日にも及んでしまう。（PDF18頁）
電力不足ヤバいの具体的ヤバさがこれで、周波数が下がるからヤバくて、周波数が下がると発電所がどんどん勝手に止まっていくからヤバいって事なんやね。
それを防ぐにはどっかの地区が停電して犠牲になるってわけやね。その犠牲の瞬間が例のビカビカーなのよね。
発電所緊急停止による負荷遮断の場合は、問題ない発電所が再開したり他の発電所が頑張って出力上げたりすれば需給バランスが元に戻るから10～30分程度で送電復旧するよ。
でも家が倒壊するような地震では送電すると火事になったりショートで過負荷になるから、電工が地区を回って問題無いか確認、倒壊家屋があったら切り離し工事ってやって少しずつ復旧させていくからすごく時間が掛かるよ。
って書いてるけど日本の送電線は裸線じゃないじゃん。誘導電流が一瞬流れるだけだから眩しいほどの大アークは起きないよね。
なので光は変電所断路器の作動によるもので、それは発電所を保護して全域停電カスケードを予防する為に行われるよ。
アークが出す赤外線がデジタル化のプロセスで可視光として表示されるから映像では爆光になるよ。ってなお話であった。
あと、地震のP波＝初期微動、S波＝主要動って学校でも習って暗記したけど、これってPrimary WaveとSecondry Waveの事なんよね。
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
友人の間のグループラインに「うぉー！結婚式見積600万！金が足りねぇ！」ってメッセージが飛んできた。
60人程度でその値段とのことだけど流石にたけーよ！緊急グループ通話会議が開催される。
なんとか削減できるところは削ることになったが、風呂に入ってゆっくり考えたら、一生に一回のことだし、奥さんの望みを叶えてあげるために色々と二人でこれまで考えたことを、浪費だとか無駄だとか断罪するのは甚だおこがましいことだったなと思い直して反省。詫びの電話と困ったなら何でも相談してくれ、俺については車代もお礼も何も要らないと伝えた。
打算的な文脈で言えば、そこで漢気をみせたからこそ幸せな思い出が夫婦関係や出席者からの見られ方がよくなるんだろうし、そんな打算的な話はおいておいても、二人で頑張ったという話は一生覚えているかけがえのないものだと思う。
人生におけるムダとしてよく挙げられる結婚式。多大な費用がかかる。
けれど、俺たちはその幸せを得るために戦っているのではないのか。
かっこええぞ、応援してるぞ。頑張れよ。
★追記★
一つだけ追記させてほしいことがある。
話になってるラインのグループは男子校出身の俺たち5人のグループなんだ。ずっと格闘技とかやってて、家族より長く一緒にいたし、大学受験だってスクラムで乗り切った。結構みんな落ちたけど。本当に文字通りブラザーで、誰よりもお互いを理解して信頼してる仲間なんだよ。
だから、俺含め他の友人たちに対して、この友人が高額な結婚式やるからってマウント取って来たわけでもないし、それを俺（達）が馬鹿にしてる訳でもない。それは分かって欲しいんだ。
IT業界は、良くも悪くも、GAFAMをおいかけてきていて、彼らが作ってきたフレームワークKubernatesなりReactなりNuxtなりGoなりC#なんなりを使って彼らと同じようにやらないと！という雰囲気があったと思う。
そのGAFAMが衰えつつあるということは、IT業界そのものがもうオワコンになり、別ビジネスのコアコンピタンスに結びついてDX化を進めるという各産業の社内システム部門の勢いが日本でも増してきているということだと思うがどうか
要するにBtoCのサービスはGAFAMらプラットフォーマーによって出尽くし買収されつくして、ここからは非IT企業がいかにビジネスを自前でDX化していくためのスクラムを組めるかというフェーズに入ったんじゃないのか
与えられたお仕事に文句言うだけなら簡単だろうけど、じゃあそれをしっかり上の人間に説明してみろよ。クソが。
つーか同じようなミーティング何回も繰り返して、やっと3-4回目で懸念点出てくるなら意味ねぇだろ前半の時間。なんだよ今更『これって本当に必要？』って。一週間前に言えや。なんでミーティングしてんの？
ミーティングも無駄なのばっかり増えてきてるし。やっぱ普通の会社である程度決められた仕事の進め方とか知らない野良みたいなもんだからな。しょうがないよ。
とりあえず型にはめてやればいいのに、なんか中途半端にあれこれ試して無駄にしてるし。そのくせ仕様に関してはいっちょ前に『無駄なものはそもそも作りたくないよー』だって。あほくさ。
スクラムでやるならその型にはめてやりますって押し通せよ。そうしないといずれ崩壊するんだからこのまま引き続き。全然合理的じゃない。
俺がやれって？結局開発リソースがすべてだからオレが口をだせるところじゃないよ。言ったところで『それはエンジニアが考えればよくない？』って。アホか。なんかもう疲れたなぁ。
外注先もクソ見てぇなクオリティで毎回だしてくるし。それで金取れると思ってんのか？まじで。俺らにできねぇことができると期待してプロに依頼してるんだから、俺らができないレベルの仕事をしろよ。
『アジャイルソフトウェア開発宣言』の価値観に反対する人はほとんどいないと思う。
よりよい開発方法を見つけだそうとしている。
かつて、数々のアジャイルな開発手法が存在して（というか今も存在しており）、この宣言はそれらの開発者が集まって合意したものだ。
ところが、最近ではスクラムだけがもてはやされ、他の手法に全く触れられないことに違和感がある。
また、「うまくいかない原因の根本はそもそも開発チームの問題なんだっけ？」って問題そのものを議論せず、スクラムだけを導入すれば解決すると思い込まれていると思う。
私がスクラムについて違和感を持っているのは以下のような点だ。
※ただし、開発チーム以外を変えなくても導入できるのはメリットでもあり、それでチームの負荷を下げつつ他の問題に対処するのは悪い手ではないと思う
一方で、例えばXPは「開発が成功するためにチーム内外に向けてなんでもやれ」という視点が強く、「ビジネス上と技術上の責任を分ける」などのアドバイスの章も用意されている。
ただその分「ここに注意せよ」くらいしか書かれておらず、結局どうやるかは自分たちで試行錯誤しなければならないことは変わりがないが。
スクラム（というか開発手法全般）を不適切に導入した後の最悪のケースは、本当は他の要因で問題が起きているのに、その分析が全く行われずに、開発チームにだけ際限のない改善が要求されることだ。
例えば「みんなリファクタリングをしなきゃいけないことに気づいており、それが評価されないから新規プロジェクトに力を入れざるを得ない状況だと知っているが、それを誰も口に出さない。その状態で正確な見積もりをしようとしたり、開発スピードだけ効率を上げようとする」という状況は誰もが身に覚えがあると思う。
つまり、我々の所属するソフトウェア開発チームでは、目の前に存在する問題に対処してアジャイルチームになることが重要で、その方法はスクラムで主張されているような開発手法とは限らないし、むしろそのわかりやすさやきれいなドキュメントがミスリードである場合もある。
そのためには、まず現実の課題が何なのかしっかり把握して、フェアに議論することから始めるのが重要なんじゃないか。
| 番号 | 選手名 | 所属チーム | 試合結果 | 対戦チーム | 寸評 |
|---|---|---|---|---|---|
| 1 | 東恩納寛太 | キヤノン | 24-26 | ドコモ | スクラムで相手を圧倒、最前線で体を張った |
| 2 | マルコム・マークス | クボタ | 43-17 | サニックス | 本領発揮。圧倒的なアタック力で試合を支配 |
| 3 | 三宮累 | Nコム | 41-13 | ホンダ | 序盤の劣勢をスクラムで跳ね除け快勝に貢献 |
| 4 | ブロディ・レタリック | 神戸製鋼 | 47-38 | NEC | FW戦を牽引。一時退場時にはチームが機能不全に |
| 5 | フレッド・ヒュートレル | ヤマハ | 52-17 | 日野 | 20歳がデビュー戦で3トライ。将来の日本代表？ |
| 6 | リアム・ギル | Nコム | 41-13 | ホンダ | 全ての局面に顔を出すNコムの真の中心選手 |
| 7 | クワッガ・スミス | ヤマハ | 52-17 | 日野 | 理想の7番。「ジャッカル」が「クワッガ」と呼ばれる日も近い？ |
| 8 | ヴィリー・ブリッツ | Nコム | 41-13 | ホンダ | 力強いアタックで牽引。マフィ不在も問題なし |
| 9 | TJペレナラ | ドコモ | 26-24 | キヤノン | 圧巻、真のワールドクラス。チームに勝利をもたらす選手とは正にこの選手 |
| 10 | アレックス・グッド | NEC | 38-47 | 神戸製鋼 | プレーと声でチームを統率。大国の10番の風格 |
| 11 | テビタ・リー | サントリー | 75-7 | 三菱重工 | 5トライ。サントリーのバックス陣にこのフィニッシャー、強すぎる |
| 12 | マリティノ・ネマニ | NEC | 38-47 | 神戸製鋼 | バックスを牽引。巧みなランで神戸製鋼を翻弄 |
| 13 | ディラン・ライリー | パナソニック | 55-14 | リコー | パナのバックスの中心。パワーとスピードで相手DFを崩した |
| 14 | 茂野洸気 | ドコモ | 26-24 | キヤノン | ボールを持てば細かなステップで確実にゲイン。勝利に導く見事なトライ |
| 15 | サム・グリーン | ヤマハ | 52-17 | 日野 | キック、アタック、ディフェンス全てが高次元。五郎丸の出番は来ない？ |
