AsianPLoPでアレグザンダー建築の盈進学園東野高等学校に訪問した

コロナ後リブート開催のAsianPLoPのエクスカージョンで、埼玉県入間市にある東野高校に行ってきた。米国の建築家であり、パターンランゲージという取り組みで、アジャイルの源流に大きな影響を与えたクリストファー・アレグザンダーが設計したことで、界隈では知らない人がいない場所だ。(ただし界隈はそんなに広くない気もする)

盈進学園東野高等学校は、ただ偶然に外国人の建築家を呼んで校舎を作ってもらったわけではなく、まず先生方が移転にあたって理想的な学舎を考えるという試みが2年あった上で、実現できる建築家を探して『オレゴン大学の実験』に辿り着き、偶然の伝手で、中埜先生が軽い気持ちで誘ってみるところから実現してしまったらしい。中埜先生がアメリカ留学で身につけた楽天的にトライする文化も、先生方の熱意も常務理事さんのビジョンも地域の協力もゼネコンさんの妥協も、全てが組み合わさってそこに結実してた。完璧はないけど、40年近く経ってもいまだに現役生に愛されるキャンパスは半端ない。

それを誇らしく説明してくれた当時を知る先生も素敵だし、そこに注目し続けて縁を紡いだ井庭先生始めパターンコミュニティの人たちも、何より当時の苦労をはにかみながら、でも誇らしく語る中埜先生も素敵だと思った。パターンと原寸設計と模型が繰り返し更新され、アレグザンダーが米国に帰っても作られ続けたし、重要なところは確認しながら進められていた。施主の、といってもオーナーではなく教鞭を取られる先生方の建築家へのリスペクト。それを作ったのはアレグザンダーからのしつこい全員インタビューだった。1986年前後の奇跡をもう一つ知った。

アレグザンダーに確認して追加した武道館のウォールクッションや、木枠から大判のガラスに変わっても守られ続ける意匠、当時に込められた一つ一つの工夫、一つ一つ全部違う教室。建物に込められた情報量がまるで違った。同じものを量産しない。多様性を楽しむ。でも共通性やシンプルさを尊ぶ。エゴレス。

自由で心理的安全性に富んだ現役生の皆さんの反応も素敵だった。珍しいであろう外国人の訪問客に自分から飛び込んでいく、先生の助言とかじゃない反応が、ああこの人たちは普段からこのように信頼されて日々を暮らしているんだな、と感じられた。建物以上にハートに心打たれた訪問でした。

建物はみんなのもので、未来に使っていく人たち自身のものにしなければいけないという、強い理想が、そのために現実との折り合いで理想と違う点が出たとしても、全体としては強く異彩と魅力を放ち、それが決して良い立地とは言えない私立学校の経営を多少以上に「成り立たせている」と感じた。

校舎裏の林は保護者の皆さんが小川復活を試行錯誤しておられた。雨水の調整池を兼ねる中央の人工池に流入させ、池の水の水質改善を目指しているのだそうだ。この人工池は、一度水を抜いて掃除したら大きな鯉が何十匹も出てきたらしい。

 

f:id:wayaguchi:20240303014353j:image

この外門は守衛さんが常駐する場所。通路を抜けるとさらに正門がある。
f:id:wayaguchi:20240303014510j:imagef:id:wayaguchi:20240303014413j:image
f:id:wayaguchi:20240303014444j:image

門を入ってすぐ右が大講堂。卒業式の準備がされていた。
f:id:wayaguchi:20240303014422j:imagef:id:wayaguchi:20240303014438j:image

教室は交差並行。互い違いに並行して二列に並んでいる。中央は中庭で木が植えられている。校長先生がそこを通ると学生たちがキャーキャー言ってた。人気者。もしかしたら、いじられてるのかもだけど、心理的安全性が無茶苦茶高い。
f:id:wayaguchi:20240303014526j:imagef:id:wayaguchi:20240303014533j:image

教室をつなぐ渡り廊下。雨が降り込むので不評な面もあるそう。でも開いていることが重要というのがアレグザンダーの意見。
f:id:wayaguchi:20240303014305j:imagef:id:wayaguchi:20240303014448j:image

窓を通して隣の教室が見える。この景色の中で毎日を過ごすのが羨ましい。
f:id:wayaguchi:20240303014520j:image

教室の床ももちろん木造。
f:id:wayaguchi:20240303014454j:image

教室の後ろにロッカールーム(サンルーム)への入り口がある
f:id:wayaguchi:20240303014314j:image

小割りの窓。現在は大判の窓ガラスに小割りのフレームをつけているが、当初は木のフレームに小割りのガラスを嵌め込んだクラシカルな窓だった。
f:id:wayaguchi:20240303014340j:image

教室のロッカールーム(サンルーム)は窓があって生徒たちが溜まって話ができる小部屋になっている。
f:id:wayaguchi:20240303014432j:image

教室は全て二面採光。両側が窓になっている。6x6=36名定員は当時としては少人数。
f:id:wayaguchi:20240303014513j:image
f:id:wayaguchi:20240303014350j:imagef:id:wayaguchi:20240303014419j:image

池は現在少し淀んでいて、水を引きこんで綺麗にするプロジェクトをPTA主導で行われているということだった。この日(土曜日)も作業されていた。
f:id:wayaguchi:20240303014317j:imagef:id:wayaguchi:20240303014301j:image
f:id:wayaguchi:20240303014441j:image
30x30cmの木材の柱は、奈良の仏閣建築の職人さんに依頼。アレグザンダーは土地の技術で作ることを重んじた。しかし職人さんもこの太さは初めてやったという。縦に裂け目が入っているが構造上は全く問題ないらしい。鉄の杭を入れているが、職人さんは鉄を入れると弱くなるのでやりたくなかったとか
f:id:wayaguchi:20240303014347j:imagef:id:wayaguchi:20240303014504j:imagef:id:wayaguchi:20240303014311j:image

各教室は二階建てで2教室ずつの独立した建物。2階は独立した階段で直接入れる。エンブレムは建物ごとに全て違う
f:id:wayaguchi:20240303014523j:image
f:id:wayaguchi:20240303014406j:imagef:id:wayaguchi:20240303014333j:imagef:id:wayaguchi:20240303014343j:image

図書館の入り口。もともと短大まで作る計画があり、大きめに作られた。蔵書数は二万冊以上。
f:id:wayaguchi:20240303014357j:imagef:id:wayaguchi:20240303014337j:imagef:id:wayaguchi:20240303014542j:image

武道場の小割りの窓はオリジナルの木製フレーム。壁のクッションは、安全上アレグザンダー帰国後に追加。色を合わせている。アレグザンダーに追加についての相談をしたら、使う人たちが手直しすることで建物が完成していくという返事だったそう。
f:id:wayaguchi:20240303014536j:imagef:id:wayaguchi:20240303014327j:image

中庭と教室の間の通路。ちょうどよい幅と置き石。単純な線がなくて、自然と情報量が多い。天気が良くてよかった。

f:id:wayaguchi:20240303014403j:image

食堂(Future Vision Base) から池と校舎を望む。木の枝が自然に張り出している下を歩く。正面右が体育館。

f:id:wayaguchi:20240303014426j:imagef:id:wayaguchi:20240303014400j:imagef:id:wayaguchi:20240303014500j:image

10代の小部屋。10代ではないジェダイマスターたちも吸い込まれてたのでジェダイの小部屋かもしれない。

f:id:wayaguchi:20240303014530j:image
f:id:wayaguchi:20240303014409j:imagef:id:wayaguchi:20240303014321j:image

調整池は雨水を逃す機能のもので中埜先生たちが容量計算したそうだが、アレグザンダーの水と川へのこだわりでもある。先生方は運動場を広く取りたいというが、アレグザンダーは人が自然と集まる憩いの場所にこだわった。
f:id:wayaguchi:20240303014435j:imagef:id:wayaguchi:20240303014330j:image

特徴的な正門。外から入ってくると門から急に風景が広がる。中埜先生によると門の位置は最初に決まったという。理由は「よくわからないがここしかないと、みんなが思った」
f:id:wayaguchi:20240303014416j:image
f:id:wayaguchi:20240303014507j:imagef:id:wayaguchi:20240303014324j:imagef:id:wayaguchi:20240303014539j:imagef:id:wayaguchi:20240303014429j:imagef:id:wayaguchi:20240303014517j:imagef:id:wayaguchi:20240303014308j:image

大講堂の柱は地元川越の黒漆喰。当時は伝統技能が存続の危機になってて、全体を請け負えるなら安くやる、という条件だったらしい。その後、伝統技能も復活したそう。落ち着きがありながらチャーミングな特徴的な意匠はアレグザンダーによる。
f:id:wayaguchi:20240303014457j:image
f:id:wayaguchi:20240303014451j:image

スクラムフェスとRSGTで脱予算経営をやってみている話

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月13日の記事として書きました。本日はすでに12月21日です。遅れてすみません。

 

脱予算経営に出会った

2012年にAgile 2012のキーノートで脱予算経営に出会いました。そのあと、当時日本語で訳されていた本を二冊ほど読みました。後から出ている方が読みやすかったです。と思ったらキーノートスピーカーはそちらの本の方でした。当時の理解は、予算を使わない代わりにキャッシュフローの透明化をして、各部門の裁量になるべく任せる、というかんじでした。やろうと思ったらできそうだけど、部署間の信頼がないとできなさそうなのと、大きな会社だと、そんなに役員同士が仲良くないというか、仲はいいのかもしれないけど競争させられてたりするので、普段の会議は割と攻防戦になっちゃうよなーと思ってました。

kawaguti.hateblo.jp

 

2022年にもう一度脱予算経営に出会う

2022年に Joe Justice さんのトレーニングで、テスラ社が脱予算経営を実施している話を聞きまして、当時のセッションがビデオで出ていたので、内容を聞き直して、日本語でセッションをしました。テスラ社は給料が時給制で均一で、リーダーは特に偉いわけではなくそのロールをこなしていて、ただ技術進歩のためにみんな働いて、ストックオプションをもらって後日の資産形成をしている、ということでした。雑な理解ですが、ああ、確かにそうすれば、お互いの削りあいは不要になって、みんなで前を向けるかもね、と思いました。

 

speakerdeck.com

www.youtube.com

 

脱予算経営の12原則を訳した

合わせて、脱予算経営を推進するBBRTという団体が出している12の原則を訳してみました。アジャイルを学んで作ったわけではないのに、すごくアジャイルとの共通性が高いと感じました。現代のマネジメントの「よい原則」というものが変わってきたことをそれぞれが感じて、偶然にして一定していたと言うことかなと思います。Agile 2012 のキーノートになっているくらいなので、そう感じている人が多数いるのでしょうね。

kawaguti.hateblo.jp

 

リーダーシップ原則

  1. 目的 - 大胆で崇高な目的のために人々を巻き込み、奮起させる。短期的な財務目標ではなく
  2. 価値 - 共有された価値観と適切な判断によって経営する。細かいルールや規則ではなく。
  3. 透明性 - 自律的な規制、イノベーション、学習、コントロールのために情報をオープンにする。それを制限しない。
  4. 組織 - 強い帰属意識を育み、責任あるチームを組織する。階級的管理・官僚主義排除する。
  5. 自律性 - 人々を信頼し、自由に行動させる。もしそれを乱用する人がいても(それ以外の)全員を罰することはしない。
  6. 顧客 - 全員の仕事を顧客ニーズと結びつける。利益相反回避する

マネジメントプロセス

  1. リズム - ビジネスリズムやイベントに合わせて、ダイナミックにマネジメントプロセスを組織化する。年次の決算に合わせるだけでなく。
  2. 目標 - 方向性と、野心的・相対的な目標を設定する。固定の、カスケード(上位から分解した)  目標を避ける。
  3. 計画と予想 - 計画や予測を、無駄のない公平なプロセスにする。硬直的で社内政治的なエクササイズではなく。
  4. リソース配賦 - コスト意識を醸成し、必要なリソースを提供する。年次の詳細な予算配分を行わない。
  5. パフォーマンス評価 - 学習と能力開発のために、パフォーマンスを総合的に評価し、ピア(1対1の)フィードバックを行う。計測のみでなく、報酬決定のためだけでなく。
  6. 報酬 - 競争ではなく、ともに成功することに報いる。固定のパフォーマンス契約に対してではなく

 

スクラムフェスとRSGTの運営でやってみた

これをどこかの企業でやってみるのはなかなかハードル高いかなと思っていたのですが、ちょうど私が代表理事をやっている「一般社団法人スクラムギャザリング東京実行委員会」は、全国各地でスクラムフェスが立ち上がってきたのも支援しており、それぞれは独立した実行をしているものの、会計・資金リスクは助け合いたいなーと言うことで進めているので、ここでやってみよう、と考えてきたのですが、ちょうど年度が替わる2023年7月から、やってみることにしました。

 

カンファレンスのキャッシュフロー

カンファレンスの会計はだいたいこんな感じです。

kawaguti.hateblo.jp

これを、私たちが「票読み表」と呼んでいるExcelシートで管理してきました。スポンサー数や参加者数は読めないので、それを予想しながら、準備期間を1-2か月単位で区切って、その中でなるべく収益のバランスを取っていこうという考え方です。ある項目を、売れたらやるし、売れなければやらないと考えてシミュレーションしていきます。

期間収支は、ざっくり書くとこんな感じかなと思います。まだ確定していないお金は、昨年実績を使って仮にアテておきます(昨日の天気)。

  1. 序盤 (セッション確定前)
    収入: 最初から乗ってくれるスポンサー、アーリーバードチケット
    支出: 会場確保、キーノートスピーカー予算
    (最低限の開催にかかる費用をカバーする)
  2. 中盤 (セッション確定後)
    収入: 通常のチケット
    支出: ノベルティ、配信やZoomなどのコスト
    (チケットの売れ行きに合わせて参加者還元を考える)
  3. 終盤 (開催一か月以内くらい)
    収入: 終盤でのチケットやスポンサー
    支出: 会場で使う物品の配信やZoomなどのコスト、お弁当
       付箋などの少額備品類
    (余裕があればできる納期で参加者還元をする)

当初はスポンサーもチケット収入もゼロですが、昨年と同じだとどうか、50%ならどうか、100%ならどうか、などは件数のところを書き換えれば簡単にシミュレーションできるわけです。これで継続的に無理のない運営を考えます。

 

そして今回、これを、月単位での集計にして、全国で行われるスクラムフェスを横に並べて月単位で集計表を作りました。

やったのはこれだけです。

これで、各カンファレンスでの月額収支と、全体での残額が月単位で把握できるようになりました。実際にどのカンファレンスがどのようにお金を使ったのは、各カンファレンスの集計表で明らかです。

 

ポイントは見える化と相互扶助

ポイントはなるべくちゃんと使ってほしいというところなのと、お互いの助け合いを引き出すところです。赤字になれば他のカンファレンスから借りることになりますし、黒字なら他のカンファレンスを助けることになります。

ここで足を引っ張りあうかどうかは、実際はマネジメントの問題ではなく、日々のお互いのコミュニケーションの問題なのだと思います。そして、私達のカンファレンスはボランティアで、給料は出ていませんので、お互いに格差も競争もありません。一年を通してマイナスだといずれ破綻しますが、それも一年くらいなら特に問題ありません。やり方をみんなで考えることができると信じています。

ですので、私は代表理事ではありますが、「こういう経費使っていいですか?」というような問い合わせも承認もしていません。(以前はありましたが基本すべてYesと答えてました。) すべて各地の実行委員の皆さんが自律的に検討していただいています。
私たちは会計の専門家でもないですし、予算を仕切るマネージャーを置いているわけではないですが、全員ボランティアで、使えるお金をうまいこと再分配して、何とか運営できてるかなーというのが今のところの感触です。

実験を始めたばかりなので、今後どうなるかはわかりませんが、良かったら、RSGTで話し合えればと思っております。よろしくお願いいたします。

confengine.com

 

ジェンダー平等を考える Women in Agile。この一年で学んだこと

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月6日の記事として書きました。

日本で最初のWomen in Agile カンファレンスをやりました

今年2月に、日本で初めての Women in Agile のカンファレンスを行いました。

kawaguti.hateblo.jp

エンタープライズアジャイル勉強会さんに共催の形をとっていただき、何とかリアル会場で一回目の場が作れたな、というところが嬉しかったです。参加された皆さんのOSTでの闊達な議論が、この場の必要性を強調していたと思います。

まず第一歩は、女性が発表する場所を自分たちで作る

Women in Agile の発起人の Jamie は第一回のAgile Conferenceに参加して、「いつか私も、あの人たちのように登壇したい」と思って、Lyssa Adkins に相談したそうです。女性がはじめて発表しやすいような場所を提案して作ればいい、ということになり、Women in Agile の活動が始まりました。それ以来、さまざままなカンファレンスで、Launching New Voices というセッションを作って、10分枠を複数用意して、初めて国際カンファレンスで発表する女性たちをサポートしてきました。この写真は10月のアムステルダムでのGlobal Scrum Gatheing でのセッションのものですが、この日も3名の新しいグローバススピーカーが生まれました。

Global Scrum Gathering Amsterdam 2023 での Women in Agile セッション

私たちも日本で、まずは Women in Agile Tokyo で公募枠でのセッション提案を受け付けていこうと思います。幸い公募の仕組みは Scrum Gathering や Scrum Fest でいつもつかっていますので、いつも通りのセッションプロポーザルの仕組みを提供できると思います。そしてグローバルへの飛躍もサポートできたらいいですね。

実は世界どこでも苦労している。日本以上に

8月にオンラインで行われた Local Organizer ミーティングに参加しました。そこで日本以外の各国の人たちと、活動や悩みを共有しあったのですが、カンファレンスを始めるのが大変なものなので、なかなか始められないのだ、という意見をいくつか聞きました。一方で、ー私たちは今年、スクラムギャザリングやスクラムフェスの経験や知見、サポートを活かし、エンタープライズアジャイル勉強会の支援も得て、第一回のカンファレンスを成功させることができました。これにあたっては RSGT2023 で来日した Lyssa Adkinsさんの後押しもいただいています。

これはとっても恵まれていることだと認識しました。放っておいても勝手に動き始めるようなムーブメントになっているわけではないですが、少なくとも私たちが動けば動いた分だけ世界は動く。いろんな人が手助けしてくれる。こんな恵まれてるコミュニティは世界でもそんなに多いわけじゃない。私たちは「この指と〜まれ!」の指を上げ続けることが大事。それを押し留めに来るような社会的な力がかからない日本社会、素晴らしい。指を上げる腕力とカロリーをちゃんと培えばいい。言ってみればそれだけの話でした。

Lyssaさんは、人の資質を男性的(Masculine)と女性的(Feminine)に分解した例を出していました。これは男女関わらずどちらの指向性も持っていて、性差ではないと注釈をつけてます。競争的でゴール指向なのが男性的、協調的で関係性指向なのが女性的。「うまくいく」「解決する」というのを活動の目標にすると、「うまくいかないものはやっても仕方ない」と短絡的に答えを出しがちになりますが、それはおそらくここでいう男性的指向に引っ張られてるかなと気付かされました。しかし、私たちの前には人がいて、続いている営みがある。全てが繋がっていて、澱みはあるかもしれないけど、リセットはできない。地道に話しながらよりよい状態を一歩ずつ考えていく取り組みにも意味がある。傷を舐め合ってるわけじゃなくて、ちゃんと観察して、理解をしようとする。現在を壊さずベターを考える。ここでいう女性的指向というのは、コミュニティで私たちがずっと目指してきたこととも符合するような気がします。俺が俺が、ではなく、No Blame(非難しない)。うまくいかない時も、苛立つのではなく、ちゃんと悲しむ。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

米国のコンピュータ科学系大学での女性比率はむしろ下がってしまった

今年の Agile 2023 カンファレンスでは、Agile Together というセッションが行われました。これは主に、Women in Agile(性別の多様性) と Agile in Color (人種の多様性) の2つの活動を中心に、ダイバーシティ&エクイティを実現していこうという取り組みでした。その中で、興味深い話がありました。米国のコンピュータ系の大学での女性比率の話です。1985年には半々くらいだったそうなのですが、数字は忘れてしまいましたが、近年は大きく女性比率が下がってしまったのだそうです。米国ではBlack Lives Matter などの活動が盛り上がる一方で、ジェンダーの多様性についてはむしろ逆行してしまっている部分もあるそうです。ちょうどカンファレンスが行われていたフロリダ州でも、性の多様性に反対する法案を知事が通していることもニュースになっていました。

注目されないことをやり続ける。信頼を培い、社会を変えていく

2月のWomen in Agile Tokyoでは瀬谷ルミ子さんに基調講演をいただき、アフガニスタンの脱出支援の話をしていただきました。タリバンが実権を握った一昨年の秋は、アフガニスタンからの脱出に関するニュースでもちきりでした。しかし、そのあと、ウクライナ侵攻が起きると、国内外のニュースはそちらが中心になりました。しかし、アフガニスタンの問題がなくなったわけではないのです。瀬谷さんたちは引き続き、クラウドファンディングなどを通じて状況を報告し、支援を集めて脱出支援を継続しています。

私たちも、Women in Agile の活動や、ジェンダーギャップの解消に向けて、注目されてない時期であろうと、無理なく継続的に活動し続ける必要性を認識しました。問題がなくなったわけではないですし、単に慣れただけということになれば、ギャップが社会に受け入れられ、定着してしまうことになります。

瀬谷さんのお話で印象に残ったのが、支援地域でも女性の活動、エンパワーメントに力を入れていること。安定した地域を作るためには、復興プログラムに女性が入ることが重要だそうです。女性の比率が高い方が平和維持・復興プログラムが3倍ほど長持ちするという国連のデータがある、というようなことをおっしゃっていたかと思います。そのために有力者(主にシニア世代の男性)の協力をうまく引き出す重要性を話されてました。

Lyssa Adkins さんの RSGT2023 キーノートにみんなで字幕をつけました

Women in Agileの有志で、Lyssa Adkinsさんの基調講演に字幕を付けました。現代がこれまでと違う、連続的で偏在的で指数関数的な変化の時代を迎えていること、アジャイルがそこに役立つことをわかりやすく教えてくれています。私はもう擦り切れるほど見ているのですが、いろんな方にもお勧めしています。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

マイノリティ平等を実現するためには、マジョリティの力が必要

第一回のWomen in Agile Tokyo では、40%ほどは男性の方にご参加いただきました。ジェンダーギャップを解消するためには、マイノリティである女性だけでなく、現在のマジョリティである男性の協力や、知識のアップデートが不可欠です。そうしたことに問題意識のある多くの方々に参加いただき、今後私たちができそうなことを議論していければと考えています。

ジェンダーギャップを形成しているのは、誰かの悪意でも偏見でもなく、ちょっとした理解不足やコミュニケーション不足なのではないかと考えています。ひとつひとつの小さな違和感を表明し、そこに働くフォースを考え、緩和や解消に向けた一手を打っていく。まさにスクラムでいつも行っているようなことが、この問題にも対応可能なのではないかと考えています。

目指したいのは、みんなで勝てる社会。アジャイルコミュニティの力を活かして

私たちは長らくアジャイルコミュニティ、スクラムコミュニティで活動をしてきました。ここでは普段ジェンダーギャップを感じることがあまりないのが実情です。アジャイルスクラムは、そこで活動する一人一人とコミュニケーションをとることを重視します。相手を「Javaプログラマー」などの属性で考えることはほとんどありません。スクラムのチームは基本的に片手ほどの人数で構成されます。ですので、全員と密に話ができる。これがおそらく、私たちの属するコミュニティでジェンダーギャップを感じることが少ない理由ではないかという仮説を持っています。そして、Women in Agile の活動は、スクラムコミュニティであればできることを、もう少し広げていく、という面もあるのかなと考えています。コミュニティのみなさまのご支援をぜひいただければと考えています。ぜひ一緒に考えていきましょう。

開催趣意書はこちらです。現在スポンサーを募集しております。ぜひご検討お願いいたします。サイト公開はもう少々お待ちくださいませ。

docs.google.com

職場で周りを巻き込んで参加するRSGT2024

このエントリーは、Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023 の 12月5日の記事として書きました。

コロナ禍からの回復にともなってオンサイト(現地)参加が人気に

RSGTでは、近年コロナ禍からの回復に伴って、現地でのオンサイト参加のニーズが高まっております。2020年1月のコロナ前最後のカンファレンスでは、チケットが瞬時に売り切れてしまうことが問題になっておりましたが、その後2021年より増床し、席数を増やしているのですが、チケットの入手の困難さが高まってきています。

実行委員会としては、会場の増床を含め、持続的開催のための対策を持続的に検討していく方向ですが、当面できる対策も行っていきたいと考えています。

コロナ後は全セッション配信しています

RSGTでは、2021年のコロナ後初のカンファレンスから、全セッションをオンライン配信し、オンライン登壇も可能にしています。会場も継続的に確保しつつも、第n波や緊急事態宣言などが発生した場合、いつでも自主的にオンラインに切り替えていただけるような体制をとってきました。その結果、2021年は半数以上の方がオンラインを選択され、会場は閑散としていたのは記憶に新しいところです。ほぼすべてのセッションは後日Youtubeに公開され、自由に観ることができます。

https://youtube.com/@scrumtokyo

bayashimura.hateblo.jp

オンラインの「廊下」としてDiscordも盛り上がるようになりました。多くの方が積極的にDiscord上で新しいつながりを作ろうとしたり、新しい試みを楽しもうと努力された結果と思います。ありがとうございます。夜中の3時までDiscordで毎日話すようになったのはこのころからです(早く寝てください)。

オンライン参加はDiscordの活用がカギ!

はじめてオンライン参加される方は、ぜひDiscordのテキストチャンネルもチェックしてください。現地の人も、オンラインの人も多くの人がDiscordチャンネルにアクセスして、登壇者の話に反応しているのを見ていただけると思います。また、Discordにはボイスチャンネルもありますので、セッションがない時間帯などはふらりと参加して、ラジオのように交わされる会話を聞いたり、思い切って声をかけてみていただければと思います。



ギャザリング(実践者の集まり)を楽しむために

徐々にコロナの状況も改善し、企業でもオンサイト参加について問題がない、という判断がされるようになった結果、徐々にオンサイトの人出が増えてきています。「オンサイトで参加したい」「懇親会で新しいつながりを作りたい」「普段なかなか会えない旧知の人と久しぶりに語り合いたい」というニーズはまさに「ギャザリング」の大事な目的ですので、一方的に講演を聞くだけでなく、実務者同士のつながりを生かしていただいていて、場づくりを支援している私たちスタッフとしても非常にうれしく感じています。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube

職場で周りを巻き込んで参加するRSGT2024をやってみていただきたい

また、一昨日以下の情報を公開いたしました。

会社の中で、アジャイルの普及や仲間づくりをされている皆さんにとって、周りを巻き込みながら会議室で一緒に観るなんて機会が作れたらいいな、というご意見をいただいて、この取り組みを始めました。

一つの参考になる例は、XP祭りでの食べログさんの取り組みです。

XP祭りに集まったメンバーで、オンラインでの参加申込をしたのですが、
「せっかくなら現地参加したかった」というメンバーの声があり、
リモート参加と現地参加、両方の良い所を実現できる参加の形がないか、TDD道場破りの参加メンバーで考えました。

tech-blog.tabelog.com

適正な利用範囲についてぜひ議論に参加してください

有償でオンラインチケットを買っていただいているカンファレンスですので、どのあたりまでの同時視聴であればフェアなのか(買った方に不公平感がないのか)、Discordチャンネルの中で議論をしています。ぜひ、議論への参加をお願いいたします。

うちの会社ではこんなことをやってみようと思います!みたいなアイデアや実行宣言も、ぜひDiscordの中でしていただければと考えています。

そうした意見や実施状況をみながら、来年のチケットの販売方法も見直していければいいのかなー、と話しています。まずはフィードバックとか、どれくらいニーズがありそうなのか、データを集められればと思います。ぜひ参加のご表明や実施後のレポートなど、ご協力いただければ幸いです。

Lyssa Adkins "The Agilists’ Emerging Superpower and Our Planetary Challenge" (日本語字幕つき) - YouTube



プロダクトオーナーの考えるべきところ

プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。

  1. 序盤戦、中盤戦、終盤戦の戦略
  2. 一番美味しいアイデアがでる可能性に備えるために
  3. 引き継ぎにはコストがかかるので人を追加すると遅くなる
  4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる
  5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない

あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。

1. 序盤戦、中盤戦、終盤戦の戦略

「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユーザーから見れば、ある程度理解したタイミングで、本当に欲しいものが提示される、というのは購買行動につながりやすいのですが、作り手側の戦略としてはうまくいきにくいのです。なぜかというと、序盤の基礎のところで、本当のウリは意識しておかないと、後付けでつけようとしてもうまく作れない、ということが起こるからです。

プロダクトオーナーとしては、顧客に対しても、開発者に対しても、同じようなストーリー戦略になってしまいがち、というのはわかるんですが、まず、作り手と顧客は別物であるという理解が重要です。作り手には完全情報を提示し、顧客には順を追ってストーリーを提示するように心がけましょう。開発者をびっくりさせても儲かりません。

これは『ユーザーストーリーマッピング』に出てくる画像ですが、横方向がユーザーの使う順序、縦がリリースの順序になっています。これがユーザーストーリーマッピングというもので、プロダクトの全体像を表します。ユーザーの使い方と、構築の仕方をリンクさせて一枚絵にしているところが重要なポイントです。

まず序盤戦の内部リリースでは、技術的にちゃんと動くものができることを確認し、中盤戦でその機能を改善し、終盤戦はリリースのために必要となる、運用面やセキュリティなど、細かなところを調整します。この終盤戦は意外とやることが多く、プロダクトオーナーから見ると「思ったほどスピードが出ない」と考える要因になりがちですが、(技術に詳しくないプロダクトオーナーの場合に特に)中盤のスピードを重視してしまって、終盤のタスクが膨大になってしまっている例をよく見ます。もっと開発者と話し合って、作り手の視点を学ぶ必要があるかもしれません。

現在では、競争がないソフトウェアというのはほとんどないので、同じリソースを投入するならば、賢く使う必要があるかと思います。やるべきことを見える化して、序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います。「自信をもってリリース可能か?」は作っている開発者にしか判断できません。一方で開発者も経験不足でわからないことも多いので、とにかく出して社会勉強するしかないケースも多々あります。

プロダクトオーナーはまずなによりも、全体戦略を開発者たちに示しておくべきです。そのうえで抜け漏れがないようにプロダクトバックログを整備し続けます。コンセプトだけでなく、周到な構築計画と、柔軟な対応、生き残るためには、すべてが必要になります。

speakerdeck.com

2. 一番美味しいアイデアがでる可能性に備えるために

1番でちゃんと全体像をみて戦略を立てることをお勧めしておきながら、逆のことを言うようですが、実際に一番売れるアイデアが出てくるのは、顧客にフィードバックをもらってからであることは間違いないです。一番賢くなっているのは、時系列的には最後だからです。おそらく、今日思いついたアイデアよりも最良のものを明日思いつきます。ですので、私たちは常に変化に適応できるようにしたい。

そのためには、プロダクトバックログをクリアに運用する必要があります。その新しいアイデアを実現するためには何をあきらめなければいけないか。これがはっきりしていれば、常に新しいアイデアを最優先で実行するためのコストが分かります。一方で、新しいが大したことがないアイデアを優先するあまり、1番で出てきた後半戦をないがしろにして、リリースされるソフトウェアの品質を下げてしまうことになると、障害とクレームに苦しんで全然前に進めなくなるプロダクトが生まれてしまいます。実際、そういうプロジェクトをいくつも見てきました。(私はそういうの作ったことないけど)

早く動けるようにするためには、現状をちゃんと整理して、コードもきれいにしておく必要があります。

ユーザーストーリーマッピング』より

3. 引き継ぎにはコストがかかるので人を追加すると遅くなる

これはブルックスの法則として有名な話ですが、人員の追加は、その人が活動できるようになるまでに時間がかかり、また、それを教えるためにチーム全体のスピードも一時的に落ちます。ですから、プロジェクトの終盤で人を追加するとか、遅いと思ったのでテコ入れのために人を増やす、というのは、実はもっと完成を遅くしてしまいます。

1.新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
2.人員の投下は、チーム内のコミュニケーションコストを増大させる。
3.タスクの分解可能性には限界がある。

人員の追加に意味がない、というつもりはありません。そこには教育コストがかかる、ということを認識して進める必要がある、ということです。チームが最も賢くなった後半であれば、最も上手に教育できることも間違いないと思います。そのコストを上手に配分していく必要があるでしょう。

以前、引継ぎについて、10年以上悩んだ結果、気が付いたことは「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。これは一緒に作業をすることで、長い時間をかけて引き継いでいくしかないかな、と思います。

4. システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる

従来、システムを作るというのは、完成してリリースに向けて作る、という印象だと思いますが、実際に最もユーザーが使うのはリリース後になります。長年プロダクト開発の分野で仕事をしましたが、一番情報量が増えるのは、実はリリース後なのです。ですので、使ってもらいながら、「もっと使ってもらうためには何が必要か」という情報を得ることがビジネス上とても重要なのです。

従来型のプロジェクトだと、リリースしたら人を減らす戦略をとってしまいがちだと思いますが、その結果、ほとんどの業務ソフトウェアが、利用者が使い始めた後に「全然なおせない」という状況に陥ります。これでは役に立ちません。しかも業務はかわっていくのに、ソフトウェアが追いつけないなんて、どこが「ソフト」なんでしょうか。

プロダクトの課金体系がライセンス販売にせよ、サブスクリプション契約にせよ、継続的に支払いを増やしていただくことが、ビジネスにとって有利であることは間違いありません。ですので、実際に使っていただいたお客様の意見を聞いて、もっと使い続けてもらうための施策をうつべきです。本気で使ってくれているお客様のクレームには一切のリップサービスがありません。ですので、こちらも本気で対応をして、信頼を積み上げることが、次の契約につながる、と考えてみましょう。

繰り返しになりますが、本当に大変なのは、リリース後なのです。継続的に問題を解決しない業者を信頼する顧客はいません。

5. システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない

クラウドベースのオープンシステムが一般的になり、うまく他者を利用することで素早く安くリリースできるようになりました。一方で、顧客から見れば、サービスしているのはあなた(の会社)です。これは運用にとってみれば非常に難しい問題を起こしがちです。「こんな問題が起きてるんですが」「いやうちが作って部分についてはお答えできません」これでは顧客に信頼されません。システム間が接続され、自分が作っていない部分が増えれば増えるほど(つまり効率が高まるほどに)、こうしたクレームがどんどん増える傾向にあります。

では、このクラウド時代に我々はどうするべきなんでしょうか。重要なのは、顧客の代わりになってちゃんと調べるエンジニアを育てておくことです。できることならば、顧客が困る前に、その問題が起きないように作りこみます。これは一朝一夕ではできません。連携するシステムが多くなればなるほど、学ぶべきことが増えていきます。そして、時間がかかります。米国Microsoftの河野通宗さんが、このように語ってくれました。

logmi.jp

クラウドって、いろんなサービスの大きな集合体なので、自分のところを(ダウンさせずに)動かし続けるしかないんです。ほかのサービスが一時的にダウンしても、当たり前に動かします。ネットワークが切れたり、毎日どこかが壊れるんです。そういう中でも毎日動かしつづけるためには、テレメトリの運用、あとは、そういうのをあらかじめ全部考えた上での運用方法の確立というのは、絶対に必要です。

ある時点でなにかがちゃんと動いていても、次の週にはもう前提が変わっているんです。なので、完璧というのは世の中に存在しない。どうやってシステムを動かし続けるかには、答えはないんですけど、その中でやり続けることが、すごく楽しい。たぶんご理解していただけると思います。

内製化でエンジニアを育てる価値は、まさにここにあると思います。逆に、どれだけ詳しく見えても、ベンダーのエンジニアはその対象領域の教育しか受けられません。ですので、あなたの問題を解決できるのは、あなたと苦楽を共にしているエンジニアだけなのです。3番の引き継ぎのところでも書きましたが、急には育ちません。

業界には詳しいふりをする人がたくさんいて、困っていると甘い声ですり寄ってきますが、だいたい契約後に幻滅することになります。そんなに都合の良い話はないのだ...というのを学習するタイミングがプロダクトリリース直前だと、もう取り返しがつきません。

プロダクトオーナーは収益性の最後の砦として、ちゃんと責任を取っていくべきロールです。あなたの後ろに人はいないので、ちゃんと判断をしていく必要があります。判断を間違えば、プロダクトの収益性が低下し、チーム全体が危機に陥ります。永続的なものなど何もありませんが、プロダクトオーナーの見識と、戦略が成功のカギになることは間違いないところです。オープンに相談しながら、一つ一つプロダクト仮説を検証して、顧客からの信頼を積み上げましょう。

おわりに

いかがだったでしょうか。プロダクトオーナーの考えるべきところについて、少しケースを挙げてみました。全体の戦略については、繰り返しになりますが、こちらの本をお勧めしたいです。

技術プラクティスや戦術については、監修でお手伝いした本がもうすぐ出ます。チーム戦術から運用までカバーしているので、プロダクトオーナー(PO)にとっても良いガイドブックになると思います。

プロダクトについてはだいたい、馬田さんのスライドを見とけばいい気がします。

speakerdeck.com

speakerdeck.com

speakerdeck.com

技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する

常松さんの新著、アジャイルラクティスガイドブックに、監修としてお手伝いさせていただきました。

本書には11本のコラムが掲載されているのですが、うち一本を私の方で書かせていただきました。技術プラクティスの説明のために技術的負債という用語を使う方は多いと思いますが、デプロイの自動化がどのようにメリットがあるのかを説明してみた、というコラムになります。

許可をいただき、こちらのブログにも掲載させていただくことになりました。校正中の原稿ですので最終稿は少し変わるかもしれませんが、ご賞味いただければ幸いです。

本原稿については、特別に角征典さん、大金慧さんのレビューをいただきました。ありがとうございました。もともと伝えたいことがだいぶ散漫だったのですが、多少読めるものになったとすれば、お二人のおかげです。

 

技術的負債 - 問題発見までの時間とリスクをビジネス側に説明する

技術プラクティスに関わるコストについて話していると、「開発者たちは認識しているが、ビジネス側に説明しにくい」という意見を聞くことがあります。まさにそういうケースで発明された用語が「技術的負債」です。経営者や財務担当者にとって、負債は必要な時にはとるべきリスクであり、一方で溜めてしまえば会社を危機にさらすものだと理解されています。この負債をメタファーとして使って、エンジニアが抱えている課題を説明しようとしました。例えば、「問題の発見までの時間がかかっている」ことは、現時点ではリスクにすぎませんが、緊急の障害が発生した場合には、そのビジネスを危機にさらすことになります。当面は問題ないように見えるかもしれないが、実は大きなリスクがあるということをビジネス側の人にも共有しておき、リスクを減らすための投資として技術プラクティスを調べたり、適用するコストをとることの共通理解を作りたい。アジャイル開発を作り上げてきた先達も、エンジニアでありながら、相手に伝わるようなうまい説明を編み出し、かかわっているビジネスの成功を目指してきました。

しかし、ただ「技術的負債があるから返済したい」と言っても、ビジネス側の人には伝わりません。具体的なエピソードにかみ砕いて伝える必要があります。一つの例として、問題が見つかってから、直すまでにかかる時間について、いくつかのケースを通じて考えてみます。

1.リリース前の手動テストに頼っている

初期にプロトタイプとして作ったアプリケーションが、よい評価を受けて本番に成長していく過程では、自動テストは後回しにしておき、自分で動かして確認た上で他の人に渡す、というケースがよくあります。自動テストができることよりも、新しい機能を早く客に見せたいと判断するケースはこれに当たります。リリースした後に問題が発見され、数週間前に作った部分のどこかにあるであろう原因を調べる必要が出てきます。報告者の勘違いで問題がない可能性も考慮に入れるべきですし、かなり広い範囲の推測を頭に描きながら、問題の理解に頭を使うことになります。これはストレスも高い作業です。そして、対応をリリースすると、さらにその変更によって同じような問題を埋め込んでしまうことすらありえます。サービスが正常に動いている状態に戻すには、リリース前の状態に戻す必要があります。もし、このタイミングでリリースしないといけない機能がある場合、かなり難しい判断を迫られることになります。

2. テストを自動化して、毎日ビルドとテストを行っている (デイリービルド)

以前は毎日ビルドを行うことをデイリービルド、夜間に行えばナイトリービルド、などと呼んでいました。ビルドを自動化して毎日自動的にチェックするようにすれば、翌日には問題が発見されることになります。ただし、テストケースの範囲内だけですが。少なくとも、ビルドできない、などの致命的な問題は発見できます。昨日行った作業のどこかに問題があったということはわかるため、まず一旦そのコミットを取り消して前日の「動いていた」状態に戻すことができます。一日分の作業を一時的に戻すだけなので、それほど大きなインパクトはない可能性があります。その上で、その後に行ったコミットを確認して、怪しいところを探り出していきます。

3.コミットをフックして、自動的にテストが走る(継続的インテグレーション

コードの修正をメインブランチにプッシュすると、自動でテストが走るようにしておくことを、継続的インテグレーションといいます。開発者たちにとっては、作業完了ごとにさまざまなフィードバックが得られるようになります。それまでに「動いていたコード」と「パスしていたテスト」のいずれかが、「先ほどの作業」で動かなくなったということがわかります。原因を探すために検討すべき範囲は非常に狭くなります。製品を作り込んだ10分後に問題が発見されたなら、まずはその10分間にした作業を疑うだけでよいですし、その部分を一旦捨てることは容易でしょう。


アジャイル開発では「既知の不具合はない」状態を維持することを目指します。それは既知の問題に関するテストを自動化しておいて、人間はそれ以外の部分をちゃんと探索するようにしよう、ということです。「ゼロバグトレランス(Zero Bug Tolerance)」ともいいます。もちろん我々は全知全能ではないので未知の問題は発見できないわけですが、この状態をなるべく高い頻度で確認できる状況を作り、維持することで「次に問題が見つかったとき」の反応速度が向上し、障害対応時の心理的負荷が下がります。そして「今は深刻ではないが、いずれ大きな問題になるかもしれない懸念」について、早い段階で検討することができるようになります。心の余裕を持ちながら、検討を忘れない慎重さが生まれてきます。品質の悪いコードを抱えているチームほど、次に発生する問題に対する余力は少なくなり、しばしば明確に存在している問題にすら対応できません。

「それは理解しているものの、ビジネス側から継続的インテグレーションやテスト作成のための時間を許可してもらえない状況だ」という相談を受けたことがあります。こうしたときに「技術的負債」のアイデアを活用して、ビジネス側にもわかるように説明することができるかもしれません。以下のように説明してみるのはいかがでしょうか。

バグが少なく、問題点の修正が早いということは「アジリティ」すなわち「近い将来のビジネスの変化についていくためのスピード」を向上させることにつながります。技術プラクティスを自分たちの選択肢として使えるようにしていくことは、ビジネス価値を高めることにつながります。まだそうなっていないのは、これまで対応のコストをかけてこなかったからかもしれません。その部分を「技術的負債」として考えることで、未来への投資となることがわかります。もちろん、いきなり大きな時間をかけてシステム全体をカバーする自動テストを書くなんてできませんし、まずは目の前にある1 つの変更点から、自動テストを足がかりにしていきます。

具体例を使って説明することで、ビジネス側の人にもリスクを伝えることができます。技術的負債を解消することには、ビジネス的に価値があります。「なぜそんなこともわからないんだ!」口にしてしまう前に、一歩一歩説明する勇気を持ってみましょう。深刻な問題が起きてしまう前に、こうしたことを話す勇気を持っておきたいものです。今日からでも遅くはないはずです。

次の第3章では、こうしたビジネス環境を作るための具体的な方法として、継続的インテグレーションと継続的デリバリーについて説明します。

 

ド素人がポッドキャスト編集に Hindenburg PRO (ヒンデンバーグ/ヒンデンブルク) を使ったらやりたいことが楽にできた

ポッドキャスト(PodCast)の音声編集、なんか時間を無限に溶かしそうで、手を出していなかったんですが、以前出演した furoshiki_fm  で、岩瀬さん (@iwashi86) がすごい頑張ってfukabori.fmを編集してる、という話に感化されたいっしーさん(@oturu333)が、最近、編集頑張り始めたそうで。ただ、Mac付属の無料の GarageBand だと編集の手間がたくさんかかるという話になり、ちょっと周辺をググって「Podcastのおすすめソフト」の記事をリサーチしたところ、サブスクの一部とか(Adobe Audition)、無料とか、デスクトップ音楽用の定番ソフト(Cubase)、メーカー自身がレビューしているもの(Cyberlink)といったものがのっているレビュー記事のなかで、共通して参照されているソフトに「Hindenburg Journalist PRO」(現在の製品名は Journalistが外れて単に Hindenburg PROらしい)というのが見つかり。特に理由もなく推されることもないことを考えると、これはもしかしていいソフトかもね。と思って調べました。

なお、元の音声素材はZencastrで録音した、話者ごとに独立した音声mp3ファイルです。

zencastr.com

まず、Hindenburg PRO のビデオが勉強になった

日本語の記事が全然見つからず(ツェッペリン社の飛行船ヒンデンブルグ号の事故については学べた)、しかし英語の操作チュートリアルを見たら、なんかやりたいことができそう、ってことになりました。このビデオのこの辺です。英語のみですが、画面見とけばだいたいの操作が分かるかなと思います。Podcastホスティング会社が作っているみたいです。(そこでホスティングしている人は90日間無料クーポンがあるみたいです。ビデオの最後に出てきます。)
08:52 - How to import files into Hindenburg 10:34 - How to edit your audio files

youtu.be

基本操作はこっちのビデオもわかりやすいかも

youtu.be

 

やりたかったこと1 : 簡単なインポート

これはmp3ファイルをドラッグしてトラックに置くだけでした。途中で作業フォルダを変えると依存ファイルを探すのにちょっと戸惑うかもしれません。最初から場所決めるほうがいいかも。作業結果は Hindenburg のプロジェクトファイルに出力できるので、元のmp3ファイルと、出力結果の mp3ファイルは同じフォルダに出すようにして、Dropboxでバックアップ取るようにしてます。

やりたかったこと2 : 音量の標準化

トラックごとに収録音量が違ったりすると、バランスさせたいわけですが、これが一発でした。[Tools]-[Auto Level]。ちなみにこれだけ PRO版のみの機能でした。

試用版が1か月使えるのですが、試用中は[Manage My Acount]でPRO/Liteの切り替えが可能です。

PRO版は月額1479円で使えるのですが、Lite版は買い切り11431円のみらしいので、私はLiteを使うことはないかなーと思います。

やりたかったこと3 : 特定トラックのノイズ除去

特定のトラックで一時的にノイズが乗ってしまっているとき(マイクに触ったとか)、はその部分だけ選択して下げることができます。これが直感的で惚れたところです。(実際はちょっと使ってみると、オブジェクトの触り方にコツがあって、ちょっと慣れかなと思いますが、「下げたいところを下げる」という直感的なUIがよかったです。)


Windows版ではマウスの縦ホイールと横ホイールにも対応しているので、30分くらい作業したらかなり手になじんできました。CTRL-ZのUNDOもちゃんと効くので安心感があります。

同様にトラック全体の音を下げることもできるので、ミュージックと音量バランスを取りたいときも簡単でした。

やりたかったこと4 : 発言の衝突をずらす

収録中に、同時に話してしまって衝突するケースが起こりますが、これ、ちょっとずらしてあげると会話としてスムーズになったりします。これはマウスでドラッグしてずらせます。ただ、一トラックだけずらしてしまうと全部後ろがずれてしまいますので、まず全体で空白時間を作って(3トラック分をずらして空白を作る)、そして個別のトラックをずらします。

この例だと、収録時は完全に声が被ってしまっていたのですが、ずらすことで、いい感じに受け答えしたかのような流れを捏造できました。これはマジで使えます。聞きやすくなります。あと自分の変なリアクションとか、気持ち悪いとこ、いい感じに消せます。精神衛生上、非常によいですね、これ。

やりたかったこと5 : BGMをいい感じに繰り返す

音楽を勝手に繰り返す機能はないのですが、簡単にコピー&ペーストができるので、あまり苦になりませんでした。あ、繰り返し機能探したらあるのかもしれませんが、chatGPTに聞いたらないって言われたので調べてません。(やり方を知ってる人がいたら教えてください。)

それどころか、話の盛り上がっているところでBGMをうまく繰り返したり、ちょうどBGMが切れるところで話に集中してもらったり、という工夫ができました。トークの最後にちゃんとBGMが終わるようにしたりできます。

初見、1時間ちょっとで40分くらいの番組をいい感じにできた。

ということで、初見でド素人の私が実時間の1.5倍くらいでいい感じにPodcastを編集できたので、これは便利だなーと思いました。講演録画のちょっとしたノイズ除去や失言の除去とかにも使えるのかも。

ほかのツールは使ったことがないので、いやこっちの方がいいよ、とかあればぜひ教えてほしいです。今回初めて編集した、ずぶの素人なもので...。

あと、Hindenburg PRO のもっと上手な使い方とかも、知ってたら教えてほしいです!

ここで編集したfuroshiki_fmは明日配信

編集した furoshiki_fm の番組は明日配信だそうです。お楽しみに―。

furoshiki.fm • A podcast on Spotify for Podcasters

(追記) 私が編集したPodcastが配信されましたー

スクラムフェス福岡で品川トラックをやってみた話です!

podcasters.spotify.com