Claude Code 用に WSLをインストールするときのメモ

Claude Code の情報はここです

docs.anthropic.com



Windows マシンでは WSL が必要ということでインストール

wsl --install

wsl --install ubuntu

 

一台のマシンは以下のエラーになった。

Wsl/Service/CreateInstance/CreateVm/HCS_E_SERVICE_NOT_AVAILABLE

こちらを参考に。

github.com

タスクバーの検索窓から「Windows の機能」で検索してWindowsの機能(Windows Features)画面を呼び出す。
"Virtual Mashine Platform"は入っていたが、"Windows ハイパーバイザープラットフォーム" は項目自体がなかった。

ということで次は以下を参考に

qiita.com

Powershell を管理者モードで立ち上げて(検索窓から Windows Powershell を探して右クリック [管理者として実行])、

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform

再起動 (Y) で再起動して、再度、[Windows の機能] で "Windows ハイパーバイザープラットフォーム" にチェックが入っていることを確認。

ふたたび、

wsl --install ubuntu

でインストールできました。

インストールするとまず管理者アカウントの作成を求められるので、作成してパスワードマネージャーでパスワード作成して忘れないように記録。

 

改めて Antropic の説明を読むと

  • ソフトウェア:
    • Node.js 18+
    • git 2.23+ (オプション)
    • PRワークフロー用のGitHubまたはGitLab CLI (オプション)
    • 拡張ファイル検索用のripgrep (rg) (オプション)

ということなので WSL上で node.js をインストールしていく

learn.microsoft.com

まず WSL 上に node がないことを確認。

> /mnt/c/Users/kawag$ node -v
node: command not found

 

まずは curl をインストール。

> /mnt/c/Users/kawag$ sudo apt-get install curl
[sudo] password for kawaguti:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
curl is already the newest version (8.5.0-2ubuntu10.6).
curl set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

>

次に、nvm

> curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16631  100 16631    0     0  38898      0 --:--:-- --:--:-- --:--:-- 38948
=> Downloading nvm from git to '/home/kawaguti/.nvm'
=> Cloning into '/home/kawaguti/.nvm'...
remote: Enumerating objects: 382, done.
remote: Counting objects: 100% (382/382), done.
remote: Compressing objects: 100% (325/325), done.
remote: Total 382 (delta 43), reused 179 (delta 29), pack-reused 0 (from 0)
Receiving objects: 100% (382/382), 385.06 KiB | 24.07 MiB/s, done.
Resolving deltas: 100% (43/43), done.
* (HEAD detached at FETCH_HEAD)
  master
=> Compressing and cleaning up git repository

=> Appending nvm source string to /home/kawaguti/.bashrc
=> Appending bash_completion source string to /home/kawaguti/.bashrc
=> Close and reopen your terminal to start using nvm or run the following to use it now:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

bashの設定が更新されたので読み込んでnvmのインストール確認

> source ~/.bashrc
>  nvm -v
0.40.3

現在インストールされているnodeのバージョン確認 (まだインストールしていないので、ないはず )

> nvm ls
            N/A
iojs -> N/A (default)
node -> stable (-> N/A) (default)
unstable -> N/A (default)
>

LTS (Long Time Supprt 長期サポート版) をインストール

> nvm install --lts
Installing latest LTS version.
Downloading and installing node v22.16.0...
Downloading https://nodejs.org/dist/v22.16.0/node-v22.16.0-linux-x64.tar.xz...
################################################################################################################# 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v22.16.0 (npm v10.9.2)
Creating default alias: default -> lts/* (-> v22.16.0)
>

再びインストールされたnodeバージョンを確認

> nvm ls
->     v22.16.0
default -> lts/* (-> v22.16.0)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v22.16.0) (default)
stable -> 22.16 (-> v22.16.0) (default)
lts/* -> lts/jod (-> v22.16.0)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.2 (-> N/A)
lts/hydrogen -> v18.20.8 (-> N/A)
lts/iron -> v20.19.2 (-> N/A)
lts/jod -> v22.16.0

コマンドラインから呼び出される node のバージョンも確認

> node --version
v22.16.0

他はオプショナルということなので後回しにして、早速 Claude Code をインストールしてみる

> npm config set os linux
> npm install -g @anthropic-ai/claude-code --force --no-os-check
npm warn using --force Recommended protections disabled.

added 3 packages in 4s

2 packages are looking for funding
  run `npm fund` for details

あ、これは問題があったときの手順でした。もう一度ちゃんと npm でインストールし直し

>  npm install -g @anthropic-ai/claude-code

changed 3 packages in 1s

2 packages are looking for funding
  run `npm fund` for details

特に問題なさそうです。

> claude

なんか起動した!
CTRL+C CTRL+C (二回連打) で終了できるみたいです。

上記の画面でEnter を押すと次に

まずはアカウントログイン。

私は Claude Pro  のサブスクリプションに入っているので、そのまま Enter

この長いURLに入れということなので (途中割愛してます)、ブラウザURLにコピーしてアクセス。

ログインは済んでいそうなので「承認」を押す。

赤線部分をさきほどのコマンドラインにコピー

Paste code here if prompted > の後にコードをペースト

Login successful うまくいったみたい。Enter を押す。

起動したっぽい!

いま、homeディレクトリで起動したので、home に Claude が触っちゃうけど大丈夫?
ということで起動前に cd して別のディレクトリに入って始めるとよさそう。

一旦 ESCキーで抜けて、

mkdir claude
cd claude

とかかな。

以上、動くところまで行けた感じです。

だれかの参考になれば幸いです。

 

 

(補足) 次回起動するときは

 

Windows メニューに Ubuntu というのがいるので、これを起動すると、シェルが起動する。

シェル上でclaudeコマンドを入れる

> claude

そういえばディレクトリの指定をしてなかったので ESC で戻る

もう一度

> mkdir claude
> cd claude
> claude

 

このフォルダは空っぽなのでEnterして入る。

こんにちはこんにちは!

> "how does <filepath> work?"

ここを日本語に書き換えて質問してみる。

おっと Offline とな。ファイヤウォール設定ですかね

CTRL+C CTRL+C で Claude を抜けて、シェルから ping を打ってネットワークがつながっているかどうかを確認。つながっていそう

> ping google.com
PING google.com (142.250.199.110) 56(84) bytes of data.
64 bytes from nrt13s52-in-f14.1e100.net (142.250.199.110): icmp_seq=1 ttl=115 time=2.92 ms
64 bytes from nrt13s52-in-f14.1e100.net (142.250.199.110): icmp_seq=2 ttl=115 time=3.07 ms
64 bytes from nrt13s52-in-f14.1e100.net (142.250.199.110): icmp_seq=3 ttl=115 time=3.25 ms
64 bytes from nrt13s52-in-f14.1e100.net (142.250.199.110): icmp_seq=4 ttl=115 time=2.79 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 2.794/3.008/3.254/0.172 ms

そうなると、Claudeの方で、APIへの接続ができていなさそう。もう一度 claudeコマンド起動。

一回「こんにちは!」は通ったので、うーん、なんでしょう。

Windows Defender に引っ掛けられてるかな?

github.com

待っていると帰ってきたので単にサーバサイドが重いだけかも

しばらくこのまま様子見てみます。

『オープンソースで未来を築こう スキルを磨き、ネットワークを広げ、技術の未来を創造しよう!』

角川書店さまにご恵投いただきました。

www.kadokawa.co.jp

スクラムのコミュニティのカンファレンスを手掛けるようになって長いですが、源流はオープンソースコミュニティのカンファレンスや勉強会です (ブログを古くたどるといろいろ出てくるかと思います)。

本書は20年以上をオープンソースコミュニティで過ごしてきた著者が、オープンソースの成り立ちやライセンスの種類から、参加方法、コミュニケーション方法、イベントの運営や参加の心得、会社からオープンソース活動に参加するための説明方法まで、とても実践的に指南してくれている本です。

 

オープンソースは多くの人の貢献から成り立っているコミュニティなので、文化とか、コミュニケーションがとても重要になります。ソフトウェアを開発するという部分はきわめて技術的な作業でありながら、お互いを尊重して、貢献から大きな力を生み出していく、ある種の政治が必要な部分は、最初はなかなか理解が難しいところかなと思います。

 

私たちのコミュニティも、主たる成果物はオープンソースプロジェクトではないものの、多くの文化をオープンソースコミュニティから学んで、取り入れてきました。本書はその点を思い起こさせてくれますし、新たに参加する人、運営する人にも読んでいただきたいです。

なお、FOSSというのは、本書でフリーソフトウェア(GNUライセンスなどのコピーレフト型で、改変者にも公開を強制するタイプ)とオープンソース(MITライセンスやApacheなどより緩い利用を許すタイプ)の総称として使われている用語です。

 

「第8章 FOSSは人のことである」はコミュニティやミートアップでの行動や、開き方についての部分です。カンファレンスに関わる方にお勧めしたいです。

第8章 FOSS は人々のことである

すでに気付いているかもしれないが、本書の大部分は他者との交流の方法やヒントを説明している。FOSSにおいて最も重要なのは、コードではなく人々だからだ。FOSSに貢献するというのは、コード、デザイン、ドキュメントを作るだけでなく、コミュニティに参加するということでもある。ソフトウェアを利用可能にするのはライセンスだが、ソフトウェアを作っているのは人々であり、人々はコミュニティがサポートしている。この関係性が失われると、全体のシステムが壊れてしまう。

この章でのふるまいの記述や、コミュニティの内側に徐々に入っていく(正統的周辺参加といわれるやつと重なる)話は、みんなでカンファレンスに参加する前に話し合うといいかもしれません。

本書では以下の図が出て来ます。それぞれ貢献や経験の度合いの違う人々がどのようにコミュニティを形成しているかということの説明ですが、一方で、参画スタイルの変遷も示していて、新しく来た人は、外側、オープンソースプロダクトの利用者からだんだん貢献の度合いと人間関係を深くして、中に入っていくわけです。もちろん、途中で中に入らなくなって止まる人も、出ていく人もいます。じっくりと、貢献とフィードバックを確かめながら、コミュニティでの立ち位置を深めていくとよいのだろうと思います。

f:id:wayaguchi:20250529104256j:image

 

初めてカンファレンスに参加する時には、まさに以下のアドバイスがありがたいと思います。

8.2.2 セッションよりもネットワーキングを優先する
FOSSプロジェクトのカンファレンスの目的は、コミュニティで集まり、学び、作業することである。そのために、チュートリアル、ワークショップ、講義、司会付きディスカッションなどのブレイクアウトセッションが企画され、トピックが似ているセッションはトラックとしてまとめられる。はじめてカンファレンスに参加するのであれば、すべてのセッションに参加したくなるだろう。もちろんそれも可能でだが、一つ秘密を教えよう。すべてのセッションに参加する必要はない。もっと価値のあることをしているのであれば、セッションをスキップしても問題ない。「もっと価値のあること」とは何か?それは、廊下トラックと呼ばれるものである。
廊下トラックとは、公式に企画されたセッション以外の学びの場である。たとえば、廊下、スポンサーブース、コーヒー飲み場での会話のことを指す。多くの参加者は廊下トラックで多くのことを学んでおり、イベントで最も価値があると考えている。メインセッションでも多くのことを学べるが、廊下トラックではセッションを座って聞いているだけでは出会えないような人たちや会話に出会える。こうした会話では、コミュニティ、プロジェクト、業界について多くのことを教えてもらえる。ここで、将来の友人やメンター、時には次の雇用主が見つかることもある。

次の章での「クソったれ (asshole)」への対処方法などは、短くまとまっていて、他の人と一緒に読んで、自分たちの文化を確認しあうと、事態の悪化を避けられる可能性がちょっとだけ上がるかもしれません。

9.7.4 コミュニティの政治

「過剰に反応するコミュニティ」のセクションからもわかるように、FOSSプロジェクトのコミュニティは政治的な問題を抱えることがある。2人以上の人間がいれば政治的な問題が発生すると言われるが、FOSSのメンテナー、コントリビューター、ユーザーは非常に情熱的な集団だ。その情熱が対立を引き起こし、対立が政治的な問題を引き起こす。もちろん、すべての政治が悪いわけではない。人間は政治的な生き物であり、そのおかげで素晴らしい成果をやり遂げてきた。だが、政治が引き起こす、あまり好ましくない結果もよく知られている。

よく見られるのは、プロジェクト内の派閥争いだ。この派閥はこの意見を持ち、その派閥はその意見を持ち、あの派閥はあの意見を持つ。具体的な意見が何であれ、他の2つの派閥がやろうとしていることには反対する。もうひとつよく見られるのは、野心的なメンバーによる帝国の構築だ。権限を保持することと同様に、他人から重視され、認められることが人生において重要だと考えている人たちがいる。FOSSプロジェクトの小さな権限(ロードマップの設定や変更の承認など)でさえも、それを利用して自分の目的のために他人や貢献を操ろうとするのである。

コミュニティにはいろんな人がいて、その多様性の良い面が大事なのだけど、逆に、未熟というか、コミュニティには適さない考え方やふるまいをしてしまう人も、ごくたまにいるのは否めないわけですが、まず悪い行動を顕在化させないことが大事で、「まああの人だから仕方ないか」で済んでるうちはいいし、学びのチャンスだと思います。

でも、どうしてもそういう枠内での行動に納得できない人もいて、いずれはコミュニティから離れていくのでしょうけど、それまでしばらくは、それなりに周りが疲れてしまうような行動をとってしまうことがあるのかもしれません。

本書はそのような場合の「クソったれ(asshole)」との付き合い方や、疲れた時にコミュニティから一時的に離れる方法などにも言及しています。

自分も「クソったれ(asshole)」になってしまうこともありえますので、思う通りにならない時には一旦距離を置いて冷静になるのが大事でしょう。

 

従来、OSSコミュニティの運営について、うまく表現した話が「伽藍とバザール」で、以下の本に収録されていたり、他にも翻訳を山形先生が公開してくれています。

本書は、そこから20年たって、実践的で網羅的で、かつコンパクトな指南書として、まとまっている本だと感じました。

また、日本のOSSの代表格RubyのMatz(まつもとゆきひろ氏)との対談を元にしたこの記事も読みやすくておすすめです。

www.1101.com

本書のAmazonリンクはこちら。

 

 

PBLで考えていること。Project Based Learning 形式のモノづくりチーム実践研修

ざっくりこんなような感じのコンセプトというか想いというか、価値を訴求できるといいのかなと思いました。どうでしょうか。

 - 実務者である私たちが思う一番よいやり方を教えます。それは常に変化していますが、常にアップデートしていきます。
 - 現実的なプロジェクトマネジメント方法、チームでの効果的なコミュニケーション方法、バージョン管理・品質チェックのノウハウ、生成AIの活用方法を含みます。
 - 私たちは、普段はさまざまな企業で働いており、コミュニティで出会いました。コミュニティは実践者が集まって意見やノウハウを交換する学びの場で、誰でも参加することができます。もちろん学生でも新人さんでも大丈夫です。
 - ITの世界はこれまでも進化が速かったですが、AIの登場でさらに変化が加速しています。開発の仕方がどんどん変わっています。個別のプログラミング言語や設計手法も重要ですが、今回は「チームとして、誰かにとって使えるものを作る」ことに力点をおきます。
 - 時間内に、与えられた(獲得した)リソースでベストを尽くすということが重要です。失敗するのも学びです。ふりかえりも重要です。長期計画よりも、今できていること、今日作れるものを重視します。
 - 「どう作るか?」だけでなく「なぜつくるのか?」「誰に使ってほしいのか?」を自分たちで考えていきます。
 - 個人としてのプログラミング知識以上に、小さなチームとしてアウトプットをまとめる練習を重ねます。チーム内の全員が自分から貢献する必要があります。
 - こうした進め方は、必ずしも各企業でちゃんと上手にできているわけではないのですが、今回体験して身につけておけば、いずれ役に立つと考えています。
 - 作ったり、表現したり、他者に説明することを通じて、学んだことや知っていることを、より深く考え、応用可能な知識やスキルとして定着することを狙っています。
 - 私たちは、先生でも上司でも指導者でもなく、コーチのような立場で皆さんの学びを支援していきます。なるべく指示は行わず、最低限の目標の提示と、皆さんの仕事のサポートを提供したいと考えています。
 - なるべく実際の開発に時間を使いたいと考えています。ですので全員の積極的な参加をお勧めします。(学びと楽しさに直結します)
 - 来年以降も改善していきたいので、積極的なご意見お待ちしてます。できれば問題は今期のうちに解決したいです。
 - 実際に社会人としてどんなことを体験しているのかは、ぜひ私たちに質問してください。課題をこなして終わりではなく、うまくこの機会を使っていただければと思います。

Scrum: ホンダ初代シティプロジェクトとのつながり

Regional Scrum Gathering Tokyo 2025 

Regional Scrum Gathering℠ Tokyo 2025

Day3 クロージングキーノートではホンダ初代シティプロジェクトに実際に参画された本間日義さんにお話いいただきますが、スクラムとのつながりは、Jeff Sutherland がスクラムを作るときに参照した竹内・野中 The New New Product Development Game です。 英語版は無償で読めます。

hbr.org

www.diamond.co.jp

 

一方、ラグビー方式だと、各部門から選び出されたメンバーが最初から最後まで一つのチームを構成し、製品開発プロセスは、こうしたチームの絶え間ない相互作用から生まれてくる。そのプロセスは、きちんと境界線のある高度に構造化された段階を進んでいくのではなく、チームメンバー同士の相互作用から生じるのだ(図表1「開発プロセスの違い」を参照)。
(中略)

これが「Cタイプ」になると、重なりは複数のフェーズにまたがって生じる。筆者らはBタイプのオーバーラップを富士ゼロックスで、Cタイプを本田技研工業(ホンダ)とキヤノンで確認した。”

この「サシミ」という言葉が富士ゼロックスのやり方を明示しているとすれば、「ラグビー」という言葉は、ホンダのオーバーラップ(重なり)方式を説明している。実際のラグビーと同様、ホンダの開発担当チームでは中核メンバーが最初から最後まで変わることなく、彼らがすべてのフェーズをつなげる責任を負う。

Jeff Sutherland はここから “Scrum” という名前を取りました。

toyokeizai.net

https://youtu.be/ipuwbFanqMY?si=qJDKpdoyvNeeyHnP&t=2040s

失敗を学びに変える アジャイルなマインドセット

これはRSGTとスクラムフェスのアドベントカレンダーの記事です。

Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2024 - Adventar

adventar.org

 

スクラムフェス関連の日程と場所、これまでの動画リンクを整理してるので、こちらもぜひどうぞ。

kawaguti.hateblo.jp

 

RSGTで話す内容はこんな感じです

マルチトラックのカンファレンスですし、ほかのセッションも充実していると思いますので、話す内容を公開しておこうと思います。

confengine.com

今回のお話は、私がアジャイルコミュニティで学んできたことをちょっとおすそ分けしようというセッションです。今回取り上げるのは、Agile2011 の Linda Rising、RSGT2023 の Lyssa Adkins、スクラムギャザリング東京2011 の Jeff Patton、そして、RSGT2020 で来日してくれた Michael Sahota の著書 "Emotional Science" です。

これまで記事にしたり、ほかのカンファレンスで発表したものがほとんどですが、Day1 午後の最初のセッションということもあり、まだこうした話を聞いたことがない方も想定し、アジャイルスクラムがどういうところを目指しているのか、私なりの視点で描いて説明してみよう、という気持ちで資料を作っています。

 

Linda Rising : 失敗を学びに変えるアジャイルマインドセットとは?

最初に紹介したいのは、Linda Rising さんの Agile 2011 クロージングキーノートです。

enterprisezine.jp

このセッションでは、キャロル・ドゥエックの『マインドセット』という本の内容を紹介しています。私はこの講演で初めて知ったのですが、そのあと多くのビジネス書で参照されるようになりました。Microsoft のCEOサティア・ナデラさんの本でも取り上げられていて、奥さんにお勧めされて読んだこの本に感銘を受け、会社のモットーの一つにGrowth Mindset が掲示されるにいたります。

人々の行動の傾向を大きく二つ「Fixed Mindset」と「Growth Mindset」に分けています。

Fixed Mindset は見栄えの良さとか、褒められることを目指しがちで、能力そのものは変わらないと考えているタイプの人です。外発的動機付けに駆動されているともいえるかと思います。こうタイプの方の問題は、少し難しい挑戦が現れると、それを避けたり、あきらめてしまったりしがちだということです。

Growth Mindset は、Lindaさんは講演で「アジャイルマインドセット」と言い換えてますが、学びを目標にしていて、熟達に向けて自ら努力できる傾向を持っています。こういう方は、困難に対しても、立ち直ったり、柔軟に挑戦できる傾向があるそうです。

アジャイルコミュニティでLindaさんが学んできたこと、コミュニティで語られてきていることは、まだにこの Growth Mindset に重なるのではないか?というのがLinda の語り掛けです。 アジャイルにはエンジニアリングが不可欠と思いますし、Lindaさんもコンピュータサイエンスを専攻したエンジニアですが、こうした心理面も無視しないでほしい、という願いを伝えてくれています。

 

 

Lyssa Adkins : 安定期のない変化の時代こそアジャイル

次に紹介するのは、RGT2023 のキーノートの Lyssa Adkins さんのトークです。字幕つけてますのでぜひお楽しみください。

speakerdeck.com

www.youtube.com

 

これまでの変化は、変化の後に一定の安定期が来る、という性質があったのですが、

昨今の変化は、安定期が来ない、連続的な変化が訪れている、という指摘にうならされました。

スクラムの源流の一つとなった論文 "The New New Product Development Game(竹内・野中)" は、変革期の新しい製品開発のやり方を調査研修したものです。特に、ホンダの初代シティ開発プロジェクトは、タイプC「スクラム」としてされており、結果的にJeff Sutherland 博士たちがスクラムを作るときの名前として採用するほど、影響力のあった事例です。

(なお、今回のクロージングキーノートは初代シティ開発チームにおられ、野中先生の取材対応もされた本間日義さんに話していただきます。)

私たちはもう変化変化の時代にいますので、安定期の手法ではなく、変革期の手法を学ぶべきなのではないか、というのが Lyssa さんのキーノートからの学びの一つです。

この来日の後、ついにLyssa さんの著書が日本語訳刊行されました。翻訳チームお疲れさまでした。

 

Jeff Patton : 話しながら付箋に書いて共有しよう

Jeff Patton さんは、第一回の「スクラムギャザリング東京2011」で初来日されました。今回のキーノートは2回目のRSGTということになります。ユーザーストーリーマッピングに限らず、プロダクトオーナー、アジャイルプロダクトマネジメントといえば Jeff Patton ということで、世界的に有名なスピーカーです。私が最も影響を受けた師匠の一人といって間違いありません。

 

序文に、ユーザーエクスペリエンスの大家、アラン・クーパーがこう記しています。デザイナーとプログラマーが全く違う言語を使っているため、なかなかうまく協業できないという業界の問題があり、そこで、Jeff Patton の手法が大きく役に立つだろう、という見解を示しています。

第一章で紹介されている事例は、史上初のユーザーストーリーマッピングになることになる、ゲーリーさんの事例です。Jeff Patton さんが支援して、音楽スタートアップの創業者であるゲーリーさんが考えているコンセプトをカードに書き出していったのですが、ゲーリーさんは業界にあまりに詳しく、機能を絞れなかったという課題を発見し、その整理を行ったのがこの床いっぱいのカードということになります。

しかし、この事例で忘れてはいけないのは、ゲーリーさんが詳しかったことはとても重要で、ただ、作るには整理が必要だった、という点です。逆に、あまり情報を持っておらず、シンプルなユーザー像や機能イメージだけを持っていたとしたら、もっと早く実現できていたでしょう....けれど、たぶん売れた可能性は低いんじゃないかと思います。

皆さんの職場で、利用者の現場を一度も見たことがないのに新事業を企画したりしていないでしょうか?「情報が足りてないとわかる」ことも重要なヒントなので、整理をすることは重要と思いますが、足りないとわかったら、情報を取りに行く必要があるのだと思います。

また、付箋にリアルタイムに書き出していく素早さが、Jeff Patton の特徴です。初めて見たときは大変驚きました。ああ、アジャイルってこういうことなのか!付箋に書くってこんなに早いのか!と感動したものですが、なかなか通じないのが現実です。付箋やMiro/Muralに情報を高速に、しかも全員で書き込んだり操作することが、アジャイルでは肝になります。未体験の方は、ぜひこのRSGTで体験してみてほしいです。

 

Michael Sahota : 感情的なささくれとうまく付き合おう

RSGT2020でキーノートをしてくれた Michael Sahota さんは、Certified Agile Leadershipという研修を日本で始めてやってくれたトレーナーです。社内のアジャイルリーダーを育てるための彼の研修も本当に素晴らしいのですが、今回は、オードリーさんとの共著の "Emotional Science" を取り上げます。

チームやコミュニティで密に話し合って作業をしていると、ときおり、心がざわめく瞬間に出会います。心理的安全性の高い、真摯に正直に指摘できる関係性であればあるほど、「えっ....」と思うような指摘も出してくれるからです。しかし人は、そうしたときにうまく感情を整理する方法がありません。過去の嫌な体験が思い起こされ、絶対にそれはいやだ、と頑なに反論してしまうこともあるでしょう。

そうしたときに、冷静に戻る重要さや、テクニックを教えてくれる本です。

変化の波を乗り越えていくときには、こうしたテクニックが頻繁に必要になるように思います。

 

アジャイルな変化を続けていくために

アジャイルといっても、ずーっと、アジャイルであり、変化を続けることは容易ではありません。

今回この4つのテーマを通じて、形式的なアジャイルのプラクティスやスクラムフレームワークが語っていない側面について、少し頭を巡らせていただければ、このトークをやる甲斐があるなー、と思っています。

 

気が向いたらぜひ会場でお会いしましょう。

オンラインチケットやサテライト会場もありますので、ぜひご検討ください。

2025.scrumgatheringtokyo.org

 

RSGT2025 虎ノ門サテライト会場【RSGT2025のオンラインチケット購入が必要です】 - connpass

 

ナイトセッション(17時以降に行うカジュアルセッション)もやりますので是非来てねー。(飲みに行く人や、会社に戻る方は気にせず行っちゃってください。)

Regional Scrum Gathering Tokyo 2025 - [ナイトセッション] これが私の生きる道 - 組織の中で自分らしさを貫くアジャイル実践者たちの物語 | ConfEngine - Conference Platform

全国のスクラムフェスをまとめたスクラムフェスマップを作ってみました

次のスクラムフェスはいつですか?

動画どこにあります?

というご質問に答えるべく作りました。

EventMapViewer

f:id:wayaguchi:20241219141108j:image

f:id:wayaguchi:20241219141113j:imagef:id:wayaguchi:20241219141225j:image


作った経緯はこちらに。AIエージェントで作ってみました。
Replit Agent - Speaker Deck

シン・レッツゴーデベロッパー 2024 仙台に行ってきた

2011年から協力している、仙台のレッツゴーデベロッパーが開催されたので行ってきました。録画も行ったので後日公開できると思います。

https://lets-go-developer.connpass.com/event/337114/

ハイライトは、長らく「地元の人主催で開催してほしい」と言ってきた綿引さんの想いがかない、仙台在住の主催者に引き継がれることになったことです。東北への想いに、感動しました。

 

ライトニングトーク(LT)してきました

ここ一週間ちょっといじってきた Replit Agent について印象を共有するトークをしました。さまざまな 生成AI コーディング支援がありますが、チャットでコーディングから、Gitコミットまで行い、そのままデプロイされるのは新しい体験でした。プロダクトオーナー(PO)として口頭で開発者さんに指示出す練習になるんじゃないかなと思いました。

speakerdeck.com

replit.com

chatgpt-lab.com