Scrum Fest Mikawa 2025 登壇報告:アジャイルを活用したProject-Based Learning (PBL)を通じた新卒研修

2025年9月6日、Scrum Fest Mikawa 2025にて「アジャイルを活用したProject-Based Learning (PBL)を通じた新卒研修:技術体験の深化とチーム協力文化の醸成」というタイトルで登壇させていただきました。

 

発表スライド: 

speakerdeck.com

登壇メンバー

今回は5名のアジャイルコーチが集まり、それぞれ異なる視点から新卒研修の実践について語りました。川口恭伸(アギレルゴコンサルティング)、永瀬美穂(アトラクタ)、竹葉美沙(カサレアル)、及部敬雄(ホロラボ)、そして秋元利春(Kumu)という多彩なメンバーで、実際に同じ現場で協働している仲間たちです。

今年度の大きな変化:環境構築デーの導入

私たちは6年間この新卒研修に関わってきましたが、今年度は特に大きな改善を行いました。それが「環境構築デー」の導入です。

発注側になるような大企業の場合、社員が「企画屋」や「手配師」的な役割に留まってしまい、大筋は発注先に任せる、ということが起こりがちです。新人研修においても、デプロイやテストなどの基礎を経験しておかないと、自律的に「企画偏重」に陥ってしまうチームが出ます。アイデアは素晴らしいのですが、いざ実装となると技術的な壁にぶつかってしまう。しかし、賢いので「実装をしなくてもアピールできるプレゼン」を作れてしまう。技術研修ですので、それだと少し寂しいです。そこで今年は2日間をかけて、まず技術的な足場をしっかりと固めることから始めました。

初日は実際の企業環境を模したインフラ構築を体験してもらいます。二日目には、その技術的理解を踏まえて「完成の定義(Definition of Done)」を各チームで策定してもらう。この取り組みにより、夢や妄想だけが膨らんでテストがおざなりになってしまう状況を防ぎ、最初から技術的な品質意識を醸成することができました。

特に印象的だったのは、APIレベルでのテストを実装できるようになったことです。以前はウェブUIのテストで躓いてしまうことが多かったのですが、今年はきちんと層を分けることで、テストを書きながら実装できるチームが増えました。

生成AI時代の衝撃

今年からCopilotやChatGPTが研修で使用可能になったことで、想像以上の変化が起きました。技術的な詰まりがほとんどなくなり、従来であれば技術サポートに頻繁に相談していた内容が、AI先生に聞けば解決してしまう。開発スピードは1-2週間分も向上し、特にフロントエンド開発ではAIがほぼノーコードでUI要素を生成してくれるようになりました。

興味深いのは、社内インフラなど企業固有の領域ではAIが対応できないため、従来通り社内担当者への相談が必要だったことです。AIが得意な領域と人間のサポートが必要な領域のバランスが、研修設計にも新たな視点をもたらしています。

受講生の一人が何気なく「ダークモードとライトモードの切り替え機能を作ってください」とAIにお願いしたところ、一瞬で実装されて「意味を聞いても仕方がない」と思ったというエピソードも印象的でした。

AI時代のコードリーディング革命

セッション後に、生成AIでコード生成すると中身を読まない人が出るので、許可していいか悩む、というご相談をいただきました。今年のケースだと、生成するばかりではなく、コードの理解や、エラーの理解に生成AIの手を借りていたようです。文字化けしてしまっているエラ〜メッセージも、生成AIは解読してくれます。そうしたこともアドバイスしながら、さまざまな実践的な使い方を体得してくれたのではないかと思います。

牛尾さんが「ディープコードリーディングのすすめ」で述べている「他人のPRを読んで100%理解する」ことの重要性を指摘しています。AIがある時代だからこそ「完璧に理解できる環境」を活用し、短期間で深い理解を得ることができるのです。

PBLの本質:探索能力の育成

私たちがPBLで最も重視しているのは、探索能力の育成です。従来の座学型研修では、特定の技術や手順を教えることはできても、「分からない状況でどう一歩目を踏み出すか」という能力は身につきません。

PBLでは、特定の技術ABCを教えるのではなく、AやBやCにたどり着く方法、そして組み合わせ方を体験的に学んでもらいます。これは転用可能な学習であり、配属後に違う技術に出会っても応用できる根本的な力です。

受講生からよく聞かれるのが「PBL終了後にSBL(座学型学習)をやりたかった」「座学型学習の重要性が分かった」という声です。これは反転学習の効果で、実際に困った体験をしてから学習することで、なぜその知識が必要なのかを実感として理解できるからです。

この現象は学習心理学の観点からも理にかなっています。人は抽象的な知識よりも、具体的な困りごとや課題から出発した学習の方が定着率が高いのです。PBLでプロダクト開発を体験した後に「あ、この場面でデザインパターンの知識があれば良かった」「データベース設計をもっと深く理解していれば効率的だった」という気づきが生まれ、その後の学習に対するモチベーションが格段に向上します。

 

 

また、チーム開発の過程で「自分が知らないことを適切に伝える技術」を身につけることも重要な成果です。多くの新入社員が「聞きたいことがあるけれど、何を聞けばいいかわからない」「そもそも何がわからないかがわからない」という状況に陥りがちです。PBLでは、このような状況が自然に発生し、コーチや先輩と一緒に「分からないことを言語化する」プロセスを経験できます。

さらに、実務に近い不確実性の高い環境を提供することで、新卒と企業のギャップを埋める効果もあります。学校では正解がある問題を解くことが多いのに対し、実務では正解が不明確で、試行錯誤しながら解決策を見つけていく必要があります。PBLではこの不確実性を意図的に組み込み、先生と生徒の関係を作らないことで、より現実に近い学習環境を提供しています。

アジャイルコーチだからできること

なぜアジャイルコーチが新卒研修をサポートするのか。それは私たちが「講師」ではなく「コーチ」として関わるからです。

分からない問題に対して、私たち自身も「分からない」と言いながら一緒に調べます。これは勇気がいることかもしれませんが、実際には「分かります」と言って答えられなかった時の方がよほど勇気が必要です。私たちは参加者だけでなく、運営チーム、組織全体をホールシステムとして見てサポートします。

新入社員が最も困るのは「分からないことをどう伝えるか」です。最近の新人は聞いてくれない、分からなくても黙っているという声をよく聞きますが、私たちの研修では、コーチが率先して「分からない」ことを表明し、一緒に探索することで、この重要なスキルを自然に身につけてもらいます。

竹葉さんからは、受講生が最初は一人でDiscordのボイスチャンネルに来て口で説明していたのが、画面共有を覚え、チーム全体で相談するようになり、最終的にはコーチを呼んで効率的に問題解決するようになる成長プロセスが紹介されました。

継続することの価値:地層効果

6年間継続してきたことで、教える側も「何でもこい」の状態に到達しました。どんな技術的な問題が起きても、慌てずに対応できる余裕ができています。

さらに重要なのは、研修を受けた先輩が事務局として参加してくれるようになったことです。毎年50人ずつアジャイル経験者が組織に蓄積され、同じ研修を受けた先輩後輩のコミュニケーションが円滑になります。部署を超えたつながりも生まれ、配属後の実務でも「あの時のPBLでコーチに言われましたね」という共通言語で話が通じるようになりました。

ある受講生からは「仕事をしていて、事業側の人がアジャイルスクラムの話を全部理解していて、エンジニアをリスペクトしているから仕事がめちゃめちゃしやすかった」というフィードバックも得られています。これは組織全体への波及効果の表れです。

 

本質的な学習目標

私たちはアジャイルという枠を超えて、社会人として必要な汎用的スキルの習得を目指しています。対話をちゃんとすること、意見を言うこと、自分の頭で考えること、当事者になること、問題解決の仕方、そして社会参画の仕方。これらの根っこの部分は、配属先がアジャイル開発をしていなくても活用できる普遍的な価値を持っています。

短い期間ですが、ある程度そういった素養がある人材がそれなりの数でできてくるといいのではないかと考えています。配属先がアジャイル開発をしているかどうかに関係なく、一般的に活用できる職業人としての根っこの部分を大切にしています。

評価とフィードバック

企業からの評価は非常に高く、6年間継続できているのもその表れです。私たちは週1回のヘルスチェックを行っており、今年は「チームが楽しい」「しんどくない」という回答が大幅に増加しました。また、一日のデプロイ回数も従来の1回から4回まで向上し、スムーズに開発が回っていることがデータからも確認できています。

受講者の多くが翌年度の運営参加を希望してくれることも、研修の価値を示す重要な指標です。新卒の人たちが当事者として、自分の経験を次の世代につなげていくために声を上げてもらうことで、組織全体での好循環が生まれています。

セッション後のDiscussionで見えてきたもの

セッション後のDiscord上で活発な議論が続き、多くの深い指摘をいただきました。

「つらい思いをしたほうが後に記憶に残るみたいなことはないんでしょうか」

これに対して、つらい思いが人間を強くする面は確かにあるものの、研修として「果たしてその体験を設計できるのだろうか?」という点で疑問があると答えました。岩田聡さんの「クソゲーはなぜ生まれるのか?」の説明にあるように、作っている人たちが上手くなりすぎて「ヌルい」になってしまう問題があります。人為的に難しく調整した課題が実務に役立つ「よい学び」につながる線が見えていないため、人為的に難易度を上げることには否定的です。

「AIと一緒にやっていくとなんかわからんけど上手く動く、が起こりやすいのかなー」

これは重要な観点で、私たちは単純なコード生成だけでなく、コード分析を駆使してチーム全員で理解することに使ってもらうことを促していると説明しました。別の方からも「書いてもらうよりも読んでもらうほうが実用性が高い」というご指摘をいただき、多くのチームで共通の発見となっているようです。

「体験とインプットの繰り返しなのだな。本当にわからなくて知りたいことへのインプットなら吸収度合いも変わりそう」

まさにその通りで、体験は一人一人異なるため、講師から確実に手が回らない現実を踏まえ、自己組織化してもらう方が現実味があります。だからスクラムをマネジメントの仕組みとして取り入れたというロジックで考えています。

「それでも5年かかるんですね!」

組織文化の変化について、「組織文化の変化は計画できない」というFearless Change、リンダ・ライジング『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』(川口恭伸ほか訳、丸善出版、2014年)の教えを引用してお答えしました。興味深いことに、今回の登壇メンバーである川口は同書の日本語版翻訳者の一人でもあり、組織変革の実践者として長年この分野に携わっています。組織の変革は段階的で予測困難なプロセスであり、継続的な取り組みと忍耐が必要だということを改めて実感しています。

 

 

アジャイル/スクラムを組織マネジメントや育成に活かすというのは、概念としてはわかっていたつもりでしたが自分の中ではイマイチ腹落ちしていなかった」

これこそが私たちの狙いで、概念的な理解から実践的な理解への橋渡しができたとすれば、セッションの意義があったと感じています。

今後の展望

生成AI時代の到来により、座学型研修のあり方も変化が必要になってくると考えています。一方的なインプット後のPBL実践ではなく、AIを活用した自律的な学習とチーム実践をよりシームレスにつなげる方法を模索していく予定です。

また、Agile PBL祭り2026(2026年3月21日、大崎ブライトコアホールで開催予定:https://agilepbl.org/ )というイベントも開催しており、学生主体ながら企業の新人研修チームも発表参加するなど、学校から企業へのシームレスな接続を目指した取り組みも行っています。スポンサー募集も始まりますので、ご興味のある方はぜひご連絡ください。


今回の登壇を通じて、6年間の継続的な取り組みの価値と、今年度の新たな改善による効果を多くの方に共有できました。PBLとアジャイル開発の組み合わせが、単なる技術研修を超えて、社会人としての基礎力育成に大きく貢献できることを改めて実感した45分間でした。

私たちはこのやり方を独占したいわけではまったくありません。できれば業界全体で、このスクラムコミュニティ全体で、みんなができるようにしたいというのが私たちの願いです。ぜひ必要なことがあれば何でも聞いてください。

 

 

Pretix:圧巻のドイツ品質?! オープンソースのイベントチケット管理システム

RSGT(Regional Scrum Gathering Tokyo) 2026では、新たに「Pretix」というチケットシステムを使ってみることにしました。チケットはこちらで販売します。

pretix.eu

Pretixとの出会いは昨年9月にベルギーで行われたDevOpsDays Antwerp 2024です。ちょうどインボイス制度に対応できそうなチケットシステムの選択肢を探していたところで、最初はそれほど気にしていなかったのですが、オープンソースで自前デプロイもできるということで、品川アジャイルの田上亮さんがかなり調べてくれて、2月のWomen in Agile Tokyo / 運営 in Agile 2025で試すことになりました。当初はセルフホストのDocker版を検討したのですが、そのままクラウドにホストされたpretix.euを使っています。

これまでWomen in Agile Tokyo / 運営 in Agile 2025を皮切りに、スクラムフェス大阪スクラムフェス三河などで使ってきた実績があり、その使い勝手の良さから今回のRSGTでも採用することになりました。今回は、このPretixについて簡単に紹介したいと思います。

www.wiajapan.org

Pretixとは

Pretixは、カンファレンス、フェスティバル、コンサート、技術イベント、ワークショップ、展示会などあらゆるイベントのチケット販売に対応したオープンソースのWebアプリケーションです。ドイツで開発されたこのシステムは、これまでに数千のイベントで使用され、数百万枚のチケットが販売されており、すでに実用性が証明されているとのことです。

主な特徴

1. オープンソース&柔軟な運用

Pretixは100%フリーでオープンソースソフトウェアとして提供されています。GNU AGPLライセンスの下で公開されており、自分のサーバーにインストールして利用することも、公式のホスティングサービスを利用することも可能です。

2. 多言語対応

多言語イベントへの対応が組み込まれており、参加者とのコミュニケーションを複数の言語で行うことができます。グローバルなイベントや海外からの参加者が多いイベントには特に重要な機能です。翻訳への貢献も可能です。

3. 高い拡張性

数千の設定項目と拡張モジュールにより、特定の用途に合わせてPretixをカスタマイズできます。プラグインシステムを通じて機能を拡張することも可能で、必要に応じて独自の機能を追加できます。

4. 包括的な機能

Pretixには以下のような豊富な機能が含まれています:

  • チケット販売管理
  • 参加者管理
  • 決済処理(PayPal、Stripe、SEPA口座振替、銀行振込など)
  • クーポン・割引機能
  • 座席指定
  • PDF チケットの生成・カスタマイズ
  • 入場管理(QRコードスキャン)
  • レポート機能
  • API連携

料金体系

Pretixの運用方法は主に3つあります:

1. セルフホスティング(無料)

自分のサーバーにインストールして運用する場合は、ソフトウェア自体は無料です。ただし、サーバーの維持管理は自分で行う必要があります。

2. Pretix Hosted

公式のホスティングサービスでは、年間500枚までの無料チケットがあり、それ以降は1チケットあたり2.5%の手数料が発生します。ただし、600€を超える高額チケットの場合は、2.5%ではなく1チケットあたり最大15€の固定料金となります。

3. Pretix Enterprise

大規模な組織向けのエンタープライズ版も提供されており、追加のサポートと機能が含まれているそうです。

導入のメリット(Pretixサイトより)

プライバシー重視

ドイツのGDPR準拠で開発されており、データセキュリティがISO 27001認証を取得しています。個人情報保護に関して厳格な基準が求められる現在、この点は大きなメリットです。

環境への配慮

ホスティングサービスは100%再生可能エネルギーで運営されており、環境に配慮した運営が行われています。

豊富な決済オプション

様々な決済サービスプロバイダーに対応しており、参加者にとって支払いしやすい環境を提供できます。

実際に使って感じたメリット

私がありがたいなと思った点は以下の通りです:

日本語対応

日本語訳については、Pretix translateというサイトで貢献者として登録すれば自前で貢献することができます。当初は翻訳率が達してなくて日本語が使えなかったのですが、いつの間にか日本語対応になっていました(やっていただいた方に感謝)。

インボイス対応適格請求書

品川アジャイルばやしさんがPDFのフォーマットをいじってくれて、国税庁が出している対応要件をカバーする項目が、文字化けせずに日本語フォントでPDFに反映できることを突き止めてくれました。

前回のエントリでも告知をしたのですが、これまでいくつかのカンファレンスで利用した限りでは、各社の経費精算処理で問題があったという報告はいただいておりません。

低廉な価格

価格はサイトに掲示の通りですが、従来使っていたチケットシステムより1%ほど安く(後発だからかな)なるようでした。1%は、チケット代の高いRSGTにとっては、なかなか大きな金額になるのではないかと思います。

PayPal以外の決済手段への対応

今年のRSGTではまだ対応できていませんが、PayPal以外の決済手段として、いずれStripeにも対応可能で、実績もかなりありそうという点もポイントでした。

入場受付アプリPretixSCANの完成度

入場受付の時に使うQRコード読み取りアプリPretixSCANも出来がよく、これまで使ってきたカンファレンスでも、レスポンス良好でした。スタッフの皆さんの方でも特に問題は見つからなかったと認識しています。

API連携の容易さ

品川アジャイルで内製しているDiscordに連携するボットアプリmogiriも簡単PretixAPIに対応することができました。

優れたレスポンスとドイツ品質?!

さらに実際に試してきたところ、日本国内でのレスポンス(画面の反応速度)も大変良く、ストレスなく使えています。設定は従来使っていたものと少し変わるので、概念をつかむのに少し労力を使いましたが、わかってくると、一つ一つの要件のモデリングが優れていると感じる点が多々ありました。

何というか細かいところに手が届く。これまでのサイトでは、少しハック的にテクニックを駆使して、私たちの使いたいように使ってきたところがあったのですが、Pretixはだいたい標準機能でできるケースがほとんどでした。「うわー、よく考えられてる。すごいぞドイツ品質」って言いながら設定するのが恒例行事です。言っているのは私だけですけど。

まとめ

Pretixは、小規模なワークショップから大規模なカンファレンスまで、幅広いイベントに対応できる柔軟性を持ったチケット管理システムです。オープンソースでありながら商用レベルの機能と信頼性を提供し、プライバシーとセキュリティにも配慮されています。

毎年1分くらいで売り切れてしまうRSGTで使うのは初めてなので、ドキドキしますが、こないだスクラムフェス三河ではやはり数分で売り切れていたので、トランザクション的には安心かなと思っております。

2025年7月には、運営会社が「rami.io GmbH」から「pretix GmbH」に社名変更し、イベント業界への製品開発により注力していく方針を明確にしました。同社としても力を入れていく方向なのかなと思います。

これまでインボイス制度対応のチケットサイトを探し始めてから2年弱、Pretixを試し始めてからももうすぐ一年になりますが、まずもって運用に乗るくらいまでこれたことは、皆様のご協力あってのことです。大変ありがとうございます。今後も様々な課題が出てくると思いますが、透明性・検査・適応で対応していければと思います。よろしくお願いいたします。

イベント運営の効率化を検討している方は、一つの選択肢としてPretix検討してみてもいいかもしれません。チケットを販売しなければ料金は発生しないため、リスクなく試すことができます。

参考リンク

一部のスクラムフェス/RSGTでは、インボイス制度対応の領収書発行方法が変わります

スクラムフェスやRSGTでは、これまでEventbrite という米国企業のチケットプラットフォームを使ってきましたが、徐々に Pretix というドイツ企業のチケットプラットフォームを試しています。

pretix.eu

 

インボイス対応の領収書の取得方法が変わります

基本的な機能はEventbriteと変わらないと考えておりますが、インボイス対応の請求書 (領収書に相当) が、Pretixから直接発行されるようになります。

以下のようなサンプル書式になります。
(これは支払い前のサンプルなので金額のところは変わります。)

 

これまでいくつかのカンファレンスで利用した限りでは、各社の経費精算処理で問題があったという報告はいただいておりません。

なにか問題があった場合はぜひご指摘いただければ幸いです。

 

社名入り請求書が必要な方は

チケットをカートに入れた後、[チェックアウトを続行する] をクリックすると、

次の画面で、メールアドレスを入力する欄の下に、請求書の宛名を入力する欄があります。

 

社名なしの請求書が出てしまったら、情報入力してメールかDiscordで実行委員に請求書の発行を依頼してください

上記の入力をスルーしてしまった場合は、購入後に届いたメールから、チケット情報画面へのリンクがありますので、請求書情報を更新することができます。ただし再発行はスタッフの操作が必要ですので、情報を更新した上で再発行のリクエストを実行委員までいただければ再発行いたします。

メールはこういうものです。リンクが付いてます。

リンク先は、購入者ごとのチケット情報画面です。

あなたの情報、のところに企業情報を入力の上、実行委員に再発行を依頼してください

 

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