『2時間スプリント』とフルリモートワークなシステム開発

デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。

2時間スプリント?

みなさん、すでにスクラムで開発してますよね!

ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。

2時間スプリントとは、その期間を2時間にするという話です。

スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。

kyon-mm.hatenablog.com

2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうちの実態に合わせていったところ、2時間スプリントという形に落ち着いてきました。

後段でも言及しますが、1時間にするか、2時間にするか、はたまた15分にするかは、チームの状況や練度によって異なってきます。ただ、一般的な常識で考えるスプリント期間よりも超短期にすることが重要な要素の一つとなります。

超短期間スプリントを導入するメリット

成果報告のタイミングで「えっ、まだ完了してなかったの??」「えぇ…、その作業をやる必要は一切なかったんでは…」「何でもっと早く相談しなかったの??」ってなってる場面に出くわすことありませんか?こういうことに身に覚えのあるチームであれば、導入を検討する余地が十分にあります。

私は超短期間スプリントの本質を「時間経過をトリガーとして、他動的かつ適切な方法でチーム内で情報を同期し、高頻度に計画を見直す」ことだと認識しています。

いわゆる報連相とかいうやつを各自の判断でやらせると、強く属人性が発生します。結果、適切に動ける人と破滅する人間に分かれていきます。

残念ながらチーム内に破滅するタイプの人間が出てしまうと、チーム全体の生産性を低下させる要因になりがちですし、当人の人事評価も自己評価も下がってしまうし、全くいいことがありません。破滅しない側の人間であっても、忙しくなってくると報告が滞りがちになることは多々あり、結果的にチーム全体の生産性を低下させる要因となってきます。

この部分から属人性を排除すれば、作業ロスを減らすことができるはずです。みなさんが大好きなトヨタ生産方式で言うところの『ムダ取り』を、作業プロセスに対して適用しようという話です。

超短期間スプリントとリモートワーク

超短期間スプリントはリモートワーク専用ではありません。全員がオフィス勤務でも適用でき、非常によく作用します。実際、オリジナルの1時間スプリントを体験したときは、ほぼ全員がオフィス勤務でした。

そのうえで、超短期間スプリントは同じやり方のままで、オフィス勤務でもリモートワークでも、どちらにも対応できることができます。デンキヤギに関していえば、2時間スプリントの習熟度が上がってきたこともあり、フルリモートワークになる以前よりも今の方が生産性が上がってきていると認識しています。

そもそも「リモートワークになったから、生産性が落ちたよねー」という話は、リモートワークになったことで対話するきっかけが少なくなり、非常に属人的な『チーム内で情報共有する能力』に生産性が強く依存していたことが顕在化しただけのことです。 超短期間スプリントは、まさにこの部分の属人性をなくそうぜという話なので、ここが問題にならないのであれば、生産性に影響はありません。

とはいえ、リモートワークでは、ペアプロやらモブプロをやるには制約はあるし、大部屋の壁に付箋を貼りまくるような情報ラジエーターにも制約はあるし、といった空間的な制約で出来ないことや苦手なことがあるのは間違いありません。この点ではオフィス勤務の方が明らかに有利です。一方で、通勤による時間と体力を消耗していることが過少評価されている気もします。

2時間スプリントを行っている実感値としては、フルリモートだろうがオフィス勤務だろうが、生産性はほとんど同じだと思っています。もし差があっても、オフィス勤務が1-2%ぐらいは有利になるケースがあるかもね?ぐらいです。

繰り返しますが、超短期間スプリントは、オフィス勤務だろうが、リモートワークだろうが、全く同じやり方のままで仕事できます。今後、リモートワークが必須でなくなったとしても、やり方を変える必要がありません。

チーム構成と業務内容

デンキヤギ内で2時間スプリントで開発をしているるチームは、現状はこういう感じの体制です。

  • terurou(役員定額働きたい放題) - 1人
  • 時短正社員(6時間勤務) - 1人
  • 学生アルバイト - 4人
    • だいたい週2-3日、14時~19時の時間帯で2~5時間ぐらいの稼働
    • 学業や私用で突発休みもOKにしているため、勤務日や勤務時間はかなり不定
  • フリーランス - 1人
    • 週で8時間ぐらいで、特に時間帯を決めていない勤務体系
    • この人は今のところスプリントには参加していないが、学生アルバイトの担当作業の技術面や管理面を主体に支援してもらっている状況
  • ある程度同じような時間帯に働いてはいるが、始業/終業時間かかなりバラつきがあり、全員が揃う日はほとんどない

業務としては自社サービス(yagisan)の開発がメインですが、内製ツール開発やOSSにPRを投げたりする他、受託の技術コンサルティングサブスクリプション契約の開発なども並行しています。常時3-5プロジェクトが動いています。terurouは普段普通にコードを書いてますが、PMやPO的なロールもこなしていたりする一方で、代表取締役的な業務があったり、営業対応なんかもあります。

まあ、何も考えずにやっていたら、管理面が破滅するしそうだなという雰囲気です。実際には普通に回せてしまっています。

1日のタイムライン

  • (みなさん適当な時間に始業)
  • 11:00 スプリントレビュー&プランニング
  • (昼休憩、みんな時間はバラバラ)
  • (14時ぐらいからアルバイトがぼちぼち始業しはじめる)
  • 14:30 スプリントレビュー&プランニング
  • 16:30 スプリントレビュー&プランニング
  • 17:00 KPT(レトロスペクティブというよりも雑談)
  • (みなさん適当な時間に終業)

細かいことは後述していきます。

プロダクトバックログ

プロダクトバックログにはやっていく作業リストがたまっています。デンキヤギではAzure DevOpsをメインに使っていますが、開発対象によってGitHubも併用しています(以前はGitLabも使っていましたが、今は使ってません)。ここには超短時間スプリント固有の話はありません。

各担当者レベルのプランニング(随時)

各担当者は、作業の着手時や割り当てられたタイミング等で、割り当て作業をタスクレベルに細分化してもらっています。

タスクの最小粒度は5分で、30分より大きくしないことを推奨値にしています。最近は弊チームではみんな慣れてきているので、各自のプランニングにお任せ気味になっていますが、「かなり細かくタスクを分割する」ことは重要なポイントです。

タスクを切る粒度の例としては、

  • GitHubにprivateリポジトリを立てる(5分)
  • XXX処理をするクラスの命名を考える(15分)
  • XXX処理のバリデーションを実装する(20分)
  • ダミーレスポンスが返せるようにする(10分)
  • XXXの公式ドキュメントのGetting Startedのページを読む(20分)
  • XXXを公式ドキュメントに沿ってインストールして起動してみる(30分)

という感じです。XXXを実装するとか設計するとかで計画が終わらせがちなところを、もっと細かく切ります。ただ、どうにも細分化しづらいタスクというのも当然あるので、そういう場合は無理して細分化せず、とりあえず大きな粒度のまま残してもらいます。

細分化することで、どこに時間がかかりそうかといったことを、着手前に可視化します。

ウィークリープランニングやマイルストーン

2時間じゃないやんけ!みたいな話になりますが、月曜日11時のスプリントレビュー&プランニングで、1週間でだいたい何をやっていくか決めていくことはやっています。

超短期間スプリントは超短期計画でしかないので、全体の方向性は決めることができません。マイルストーンを置いたり、週次のおおまかな計画は、これはこれとして考えていきます。

ここも一般的な期間のスプリントでやるプランニングと大差はありません。

デイリープランニング

やっていません。毎日11時のスクラムイベントで「今日中でここまで終わらせたい」みたいな話をすることもありますが、デイリープランニングになっているかと言われると、なっていません。

前述の通り、全員が11時のタイミングでは揃っておらず、14:30でも始業していないことが普通にあるので、朝会なり昼会なりでデイリープランニングするということ自体が稼働実態にマッチしていません。

超短期間スプリントだと、朝会なり昼会に参加しなかったせいで、一日の計画がよくわからない!ということは発生しにくくなります。1日に何度もプランニングをしているので、どこかのタイミングで参加すれば、最新に追いつくことができます。

2時間スプリントレビュー&プランニング

前スプリントまでの作業成果の共有と、次スプリントのでやる作業の計画(の補正)をします。全員が参加した状態で、次のようなテンプレートに沿って各自に話してもらっています。

f:id:terurou:20200913190201p:plain

テンプレートを使うという発想も47機関のパクリです。このテンプレートは紙に印刷して、スプリントレビューの際に視界に入るようにしておくことを推奨しています。

このテンプレートで会話する作業は、前述の各担当者レベルのプランニングで細分化したタスクレベルになります。ここで、各自が立てた計画に『違和感』を感じた場合や、何か課題が発生している場合は、チーム全体で対応策を検討したり、計画の補正をかけていきます。

  • 当人は知識がなかったので半日ぐらいかかるつもりだったが、実はチーム内にかじったことがある人がいて、その人からの情報を足掛かりにすれば30分ぐらいで終わりそう
  • 逆に30分ぐらいで終わるつもりだったが、傍から見たらどう考えても見積もりが甘すぎる
  • やってみたら実はめちゃくちゃ実装が難しいので助けてほしい
  • 要求仕様がよくわからないので悩んでいた など

また、テンプレートに「成果デモの実施」とありますが、これも非常に重要です。「全部完成する前に、上の人に方向性が合ってるか見てもらうね」と指導された経験がある人は多いと思いますが、これを2時間毎にワークフローとして強制的に実施します。全部作りきってしまってから、実は方向性が違ったとか、過剰品質だったとか、品質不足だったとかという不幸は、本当によくあります。

適切な手法で超短時間にスプリントレビューを実施することで、ムダの発生を早期に検出して対処していくことで、生産性が高くなっていきます。リモートワークではコミュニケーションが取れないから生産性が落ちるという話を、属人性にゆだねることなく、仕組みで未然に防いでいきます。

超短期間スプリントの期間の決め方

スプリント期間をどれぐらい短くするかという点は、47機関とデンキヤギで考え方の違いが出ている大きな箇所です。デンキヤギというか、PMとしての私の考え方では、

  • 最悪半日ぐらい工数をドブに捨てるようなことになっても、他に得るものがあったなら、まあ仕方ないかなー
  • とはいえ、1日まるっと無駄にされたら、若干イラっとするよね
  • 2時間ぐらいなら全然仏の顔できますよ。人間、眠気に襲われたりして30分ぐらい意識が朦朧としたりすることもあるよね
  • 1時間間隔でチェックポイントを仕込むのは、せわしくなくなりすぎて、逆にストレスが溜まる…

という仕事感覚なので、2時間に落ち着いてきた次第です。

KPT(レトロスペクティブというよりも雑談)

スクラムではレトロスペクティブ(ふりかえり)が重要ですが、それに該当するもので、KPT形式で行っています。

デンキヤギの場合、レトロスペクティブという面もありますが、社員間で雑談する機会を設けるという面を優先しているので、別に実業務とは関係のないことを話してもらってもOKにしています。ちなみに参加者は社員のみに絞っています。

  • アルバイトは稼働時間が短く、スプリントレビューも含めると、稼働時間の結構な割合が打ち合わせ時間になってしまう
  • チームをまたいで人が参加するので、当然他のプロジェクトの話が出てくることがあり、社員間ならともかく、アルバイトの人に不必要なNDA的リスクを負わせたくない

という判断でやっています。このあたりの匙加減は、これで正解とは思ってないので、今後変わる可能性はあります。

細かなテクニック

仕事に集中していたりして、スクラムイベント(スプリントレビュー&プランニング、KPT)の時間になったことに気が付かないみたいなことは結構あるので、少し前に時報を鳴らすようにしています。フルリモートワークになる前はチャイムを鳴らしていましたが、フルリモートワーク以後はチャットに通知を流すようになりました。

超短期間スプリントをやらなくても、時報を鳴らすこと自体はかなり良いです。自分で時間を確認しに行かなくても、時間の経過がプッシュされてくるのは、仕事のリズムを作っていくためのフックポイントとして使いやすいです。

超短期間スプリントが適用できないチーム

チームメンバーの働いている時間帯が全く違っていて、全く重なっていないという場合には適用ができません。こればかりはどうにもなりません。

さいごに

長々と書いてきましたが、興味があるチームは id:kyon_mmアジャイルコーチを依頼するといいじゃないでしょうか。正直、うちが高精度に2時間スプリントを導入できたのは、オリジナルを実際に体験できたことが大きいんじゃないかと思っています。

とはいえ、とりあえず時報を導入して、時報が鳴ったら強制的にチーム全体で話すようにするというところからでも良いかもしれません。そして、前述の報告テンプレートを適当に改変して使えると、なお良いという感じがします。

報連相とかいう属人性の塊みたいな文化を抹殺しましょう。

Haxe 4.2で導入される Module-level fields を試した

Haxe 4.2は順調にいけば、2020年10月14日にリリースされるはずです。とはいえ、Haxeのマイナーバージョンアップのリリースは、バグフィックスも含めると2か月前後ぐらい後ろ倒しになる印象なので、2021年初に使えるようになってるかなーぐらいでしょう。

Haxe 4.2の目玉機能の1つとして、Module-level fieldsが導入されます。雑に言ってしまうと、Go言語に近い書き方が導入されます。

haxe.org

この機能は既にマージ済みとなっているので、nightlyビルドで動作確認することができます。

とりあえず、次のコードはコンパイルできて、ちゃんと動作します。

// Main.hx
final version = 4;

function main() {
    trace("Hello from version " + version);
}

このコードは、次のコードと等価です。要はシンタックスシュガーに過ぎません。要点としては、

  • クラス名はモジュールファイル名から設定される(ここではMain.hxなので、Mainになっている)
  • すべてpublic staticとして扱われる
class Main {
    public static final version = 4;

    public static function main() {
        trace("Hello from version " + version);
    }
}

このような変換ルールなので、例えばこのように関数定義なしにロジックを記述することはできません。

// このコードはコンパイルが通らない
final version = 4;

trace("Hello from version " + version);

サブモジュールを作る/使う際も、特に難しいことはありません。

Haxeを知っている人には、import Lib1してるだけなのに、なんでadd(1, 2);って書けるの…?となる部分がありますが、これはimport Lib1.*しているのと同じ扱いになっていようです(ちゃんと情報を読み込んでないので本当に*シンタックスシュガーなのか自信がない)。

// Main.hx
import Lib1;

function main() {
    final result = add(1, 2);
    trace(result);
}
// Lib1.hx
function add(a:Int, b:Int):Int {
    return a + b;
}

モジュールの初期化を行いたい場合は、__init__()関数を使います。急にPython感が出ますが、実は少なくともHaxe2の時代には存在していた機能です(Haxe2以前は触ったことがないのでわかりません…)。

// Lib1.hx
var value:Int;

function __init__() {
    value = 10;
}

ただし、残念ながら__init__()final変数の初期化はできないようです。シンタックスシュガーであることを考えると仕方ない感じがします。

// これはコンパイルが通らない
final value:Int;

function __init__() {
    value = 10;
}

また、モジュール外に公開したくないものはprivate修飾子を指定します。

// Lib1.hx
private function add(a:Int, b:Int):Int {
    return a + b;
}

全的的に、かなり直感的に書けるようになった印象です。いちいちclassとかstaticと書かなくて良くなったことは、特定の層には刺さりそうな感じがします。

強いて気になる点を挙げると、クラス構文の場合とは、importの挙動が異なることと、publicデフォルトなのかprivateデフォルトなのかに差異があることが、気になるといえば気になります。

UXデザインとHCD(人間中心設計)の本を教えてもらった

TwitterでUXについて雑なこと(後に認識違いだとわかった)を言っていたら、@nobkz 氏にいくつか本を教えてもらったので一気に読んだ。紹介してもらった本は、タイトルの通り教科書的な内容で、基礎知識を得るには良い本だった。

UXデザインの教科書
UXデザインの教科書
安藤 昌也(著)
¥3,300 (2020-08-16時点)
5つ星のうち3.9
人間中心設計の基礎 HCDライブラリー第1巻
人間中心設計の基礎 HCDライブラリー第1巻
黒須 正明(著), 黒須 正明(編集), 松原 幸行(編集), 八木 大彦(編集), 山崎 和彦(編集)
¥4,180 (2020-08-16時点)
5つ星のうち2.4

改めてUX本を読んで、UXという用語の定義範囲について完全に認識が誤っていた。UXは企画~設計プロセス(特に反復開発とユーザビリティテストに重きを置く)事を差していて、UIはスコープ外だった。5年ぐらい前にいくつかUXの本は読んだ記憶はあるのだが、おそらく当時はマイクロインタラクションなどのUI/UX本(UI要素が強い)を中心に読んでいて、UX単著の本は読んでなかったことで認識誤りが生じていたようだ。

「UXについて理解してるつもりだけど、そういえばUX単独で学習をしたことがないかもしれんなー」っていう人は、おじさんのように実は用語の理解が誤ってる可能性があるので、見直しのために読んでみるとよさそう。

2冊紹介してるけど、UXデザインの教科書の方だけ読めば十分かなあと思う。

「心理学,認知・行動科学のための反応時間ハンドブック」を読んだ

読みました。

www.keisoshobo.co.jp

全ての人間が読むべき本かというと、そうではないです。

私がプログラマーなので、プログラマー文脈になってしまいますが、

  • ゲームおよびゲームに非常に近しい分野(VRなど)に携わるプログラマーおよびプランナー
  • 特にUIの応答速度、入力性、使いやすさなどに強い興味のあるプログラマー

あたりの人間が読むと、知識に深みが出そうです。

実務的な数値とかは、こういった記事の方が揃ってます。ただ、こういった記事を読む際に「そもそも反応時間とは???」という基礎知識を得ておきたい場合には非常に良い本でした。

jp.gamesindustry.biz

私が読んでた時のログはTwitterに流してました。これを見てもらえば書いてある雰囲気は伝わると思います。

各用語や過去の研究等の説明がかなり丁寧で、入門レベルの人間でも読めるようになっています。元々の想定読者に研究者が想定されていて、関連論文のサーベイ本みたいな感じもあり、引用文献は巻末に大量に書かれています。この本を片手に用意しておけば、反応時間関連の英語論文もなんとなく理解できる程度のは読めそうな気がしてきます。 ただし、かなり工学書に近い書き方をしている本なので、こういった本を読みなれてない人にはかなりしんどいと思います。

設計書には何を書くべきなのか

設計とは、

  1. 要求(やりたいこと)をヒアリングする
  2. 要求を要件(何を満たさないといけないのか)に落とし込む
  3. 要件を実現するために考えられる手段を洗い出す
  4. 手段の検証を行う
  5. 検証結果を元に、どの手段を使うかを選定する
  6. 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する)
  7. 合意内容を元に、実装や設定に落とし込む

をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。

設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、

  1. 要求
  2. 要件
  3. 方式
    1. 対応案(いわゆる比較表で書いていくのが楽)
    2. 検証結果
    3. 選定・合意結果(合意した代替策や妥協ラインについても記載する)
  4. 詳細設計(どういう実装にするとか、パラメーターにするとか、細かい話)

という感じで書いていけばよい。

ありがちな失敗としては、4.詳細設計しか書かないことである。これだと、後から読んだ際に「なんでこれ使うことにしたんや…」がわからないという事態が発生してしまう。前述のとおり、画面設計や機能設計では方式を選ぶという事が薄いので、普段このあたりを多くやっている人ほど、3.方式を書くという意識が飛びがちになる。

あと、2.要件はまあまあ書かれるのだが、それに対して 1.要求は「ちゃんとした設計書」ですら書かれていないことがあり、やはり「なんでこの要件になったんだっけ?」が発生しがちになる。

ASUS TUF Gaming A15を買って、すぐにRAM32GB/SSD1TBに換装した

ASUS TUF Gaming A15(FA506IU)を買いました。この記事を書いている時点ではこの機種が在庫切れのようで、次のAamzonリンクは1つ下位の機種(GTX 1660 Ti ではなく GTX 1650 Ti、他は同じ)です。

B089SV43Q6
ASUS ゲーミングノートパソコン TUF Gaming A15 FA506II (Ryzen 7 4800H / GTX 1650 Ti / 16GB・SSD 512GB / 15.6インチ / FHD(1920 × 1080), 144HZ) / フォートレス・グレイ / MIL規格準拠)【日本正規代理店品】【あんしん保証】FA506II-R7G1650T

TUF Gaming A15は、Ryzen 4800H搭載で2.2kg程の15インチゲーミングラップトップです。同じようなカテゴリーでは、同じASUSのROG ZEPHYRUS G14がRyzen 4900HS搭載で1.7kg程ということで、大きなインパクトがあり有名です。

では、なぜわざわざASUS TUF Gaming A15の方を購入したかというと、これにつきます。

機種選定にあたっての利用想定は、

  • ゲームではなく開発で使用
    • Haxeがメインだが、Scala, Java, .NET(C#, F#), Goあたりも触る
    • JavaScript開発が多いが、OSSにPRを投げる他、ゲームクライアント開発のお手伝いがあったりで、それなりに大きなプロジェクトも日常的にビルドする
  • RAM16GBでは人権が守れない
    • エディタやらIDEやらWebブラウザやらチャットクライアントやらローカル開発サーバーやらを立ち上げるだけでカツカツ
    • 更にHadoopやらSparkやらNiFiやらのクラスタ検証でローカルでコンテナを立ち上げまくるような作業もある
  • 自転車移動で持ち運んで使うことがありうるので、現実的な重量のラップトップ

という感じです。

CPUパワーが欲しいので、今のご時世ではRyzenしか考えられません。というか、Ryzen機のコストパフォーマンスが良すぎます。Core機より5万円ぐらいのレンジで平気で安いの、一体どうなってるんだ。

現行世代のRyzen 4000でRAM16GB超となると、選択肢がかなり限られてきます。冒頭でも書いたROG ZEPHYRUS G14もかなり本気で検討したのですが、RAMが24GBシングルチャンネル(オンボード8GB+換装可能スロット1)にしかアップグレードできないROG ZEPHYRUS G14はしんどいなあと判断して見送りました。

TUF Gaming A15はRAMスロットが2本あり、スペック上は64GBまで増設可能となっています。YouTubeでもRAMアップグレード動画が十分に数があり、かなり簡単なことは確認できたので、完全にこれが決定打です。

本体2.2kg+ACアダプター450g程度と、最近の15インチのラップトップでは若干重い(ゲーミングとして考えると軽い)のですが、ここ数年の自分の稼働状況とCOVID-19の状況から、持ち出し頻度はかなり少ないだろうと判断し、重量は優先度を下げました。

最初から自前で換装して使う想定なので、RAMとSSDも合わせて買いました。Amazonのリンクを張ってますが、実際にはarkで勝っています。

B07Q7T9NSC
Crucial CT2K16G4DFD832A 32 GBキット(16 GB x 2)(DDR4、3200 MT/秒、PC4-25600、CL22、デュアルランクx 8、SODIMM、260ピン)メモリ、グリーン

B07YFFX5MD
ウエスタンデジタル WesternDigital SSD WD Blue SN550シリーズ NVMe M.2 2280 1.0TB WDS100T2B0C

WD Blue SN550は、発熱が低めで、なによりコスパが良いという理由で選んでます。連続書き込みでキャッシュアウトした際にシーケンシャルリードが500MB/s弱しか出なくなるので、あまり性能が良くないという言い方のレビューも見てはいるんですが、ぶっちゃけシーケンシャルリードが500MB/sでも3000MB/sでも、日常の利用シーンでの違いは体感できないので、問題なしという判断です。高解像度の動画なんかを操作する人達には当然違うんでしょうが、自分はそうではないということで。

換装の手順は、この動画を見てもらうのが分かりやすいです。当然ですが、換装する前にはリカバリーメディアを作っておきましょう。これは換装後でも大丈夫ですが、MyASUSアプリから製品登録をしておくと無難です。

www.youtube.com

動画ではわかりづらい点を強いて上げると、

  • ネジは普通のプラス精密ドライバーがあればOKだが、いわゆる「こじ開けツール」が必要
  • 底面パネルのネジがいくつか長さが違うものか混ざっているので、ネジを締めなおす際に間違えないようする
  • SSDを換装した際は、BIOSでSecure Bootを無効化しないとエラーが出る(Secure Bootを無効化しろいうエラーなので、わかると思いますが)

といったぐらいです。

私は、元々取り付けられていたSSDを外して換装しました。NVMeスロットが2本あるので換装前のSSDをセカンドスロットに刺しなおしてもよかったんですが、いざとなったときは刺しなおせば工場出荷状態に戻せます。

換装が終わったら、普通にWindows 10をインストールするだけです。私はVisual Studioサブスクリプションを持ってるので、Windows 10 2004 Enterpriseをインストールしました。

ドライバー類はWindows Updateから全て自動で入りましたが、Windows Updateでは入らないASUSのUtility類もサポートサイトから全てダウンロードできます。

ASUS TUF Gaming A15 | ASUS TUF Gaming | ノートパソコン | ASUS日本

次をインストールすればOKです。

  • ASUS System Control Interface V2
  • DTS Ultra LPAP Component Driver
  • ROG Live Service Package
  • Refreshrate Service
  • ARMOURY CRATE Service
  • Armoury Crate UWP
    • 排熱(ファン)のモードとか、キーボードのゲーミングっぽいイルミネーションの設定
  • DTS:X Ultra UWP
  • GameVisual UWP
    • 液晶パネル設定だが、Armoury Crate UWPに統合されているので不要
  • MyASUS UWP
    • サポート関連の他、バッテリー充電設定がここにある

これで換装は完了です。

  • Ryzen 4800H
  • DDR4-3200 16GBx2
  • SSD NVMe 1TB
  • GTX 1660Ti

キャンペーン価格や自前アップグレードパーツ代を込みで、トータル157,980円(税込)でした。Ryzen安すぎる…。