摩擦のないコミュニティ運営を考える

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

今日はカンファレンスの運営について、ちょっと言語化してみました。

f:id:wayaguchi:20211223084115p:plain

RSGT、スクラムフェス、DevOpsDays Tokyo

f:id:wayaguchi:20211223084154p:plain
Regional Scrum Gathering Tokyo (RSGT) というカンファレンスを始めて、ちょうどこの10月で10年が経ちました。最初は「スクラムギャザリング東京」という名前で始めたのですが、私たちのカンファレンスをずっと支援してくれていて、世界中で Scrum Gathering というカンファレンスを主催している Scrum Alliance という団体の方で、同団体が直接運営しないカンファレンスを Regional Scrum Gathering という名前にしよう、ということになり、私たちもRSGTという名前で行うようになって、現在はこの名前が定着しました。

それと、スクラムフェス(Scrum Fest) というカンファレンスの実行委員をいくつかしています。スクラムフェス大阪というのが最初で、これは関西のスクラムコミュニティの人たちが、東京のRSGTに参加してくれていて、「こういうカンファレンスを関西でもやりたい」ということになり、じゃあ、Regional Scrum Gathering Osaka やろう!ということになったのですが、当時の Scrum Alliance の地域コミュニティ担当さん(RSGxxを支援してくれている人)が、「近い地域では一つずつにしたい」という意向だったので、その名前を使わず、別の名前をつけよう、ということでスクラムフェス(Scrum Fest)という名前になりました。Scrum Alliance の許可をもらわなくても開催できるので、結果的に、大阪札幌三河という感じに「スクラムフェス」が行われるようになり、来年は新潟が増える予定です。

もう一つ、DevOpsDays Tokyo というカンファレンスもやっています。これも RSGT みたいなカンファレンスを作りたい、DevOps という領域でやりたい、ということになって、2017年から開催し始めました。DevOpsDays というカンファレンスは、元々システムアドミニストレーターカンファレンスというのをはじめようと考えていた人たちが、2009年のFlickr社の発表に共感して、「DevOps」という名前が発案され、2010年からDevOpsDaysというカンファレンス名を冠して世界中で行われるようになりました(関連資料)。日本でも2012-2013年に行われていたんですけど、後を引き継いでやっている人がいなかったので、私たちが名前を使わせてもらうことにしました。

ということで、RSGTというカンファレンスを起点に、そこに共感してくれた人たちが、自分たちでやりたいカンファレンスを始めてくれている、というのがこれまでの流れです。このことは決して私が始めたことでも、私一人が行ってきたことでもないのですが、カンファレンスの運営について、ちょっと思っていることを書いておこうかな、というのがこのエントリの趣旨です。興味のある人だけ、ちらりと読んでいただければ幸いです。

Fearless Changeという本、リンダ・ライジング (Linda Rising) という人

f:id:wayaguchi:20211223084249p:plain
勉強会というものを始めたのは、2009年からのすくすくスクラムというコミュニティからが本格的なところです。それまでにも、LLxxRubyKaigiオブラブXP祭りといったカンファレンスや勉強会には参加せてていただいたのですが、スクラムをはじめて社内でやるにあたって支援してくれた林栄一さんと、当時同僚だった江端一将さんが、自分たちで勉強会をやろう、ということになり、始めたのがすくすくスクラムでした。そのころ、Fearless Change という本がある、というのを江端さんがコミュニティの誰かに推薦されたということで、教えてくれて、その読書会をやろう、ということで、懸田剛さんや近藤寛喜さん、他にもいろんな人たちとその本の読書会をやりました。

この本の著者の一人、リンダ・ライジング (Linda Rising) さんは、米国のカンファレンス Agile 20xxでは知らない人がいない、という常連で、2011年の基調講演は私もレポートしました。

enterprisezine.jp

この著者らのアプローチが、パターンランゲージという手法を用いた、実践者による形式知の書き起こしと、実践者同士でそのパターン名をまさに「ランゲージ=共通言語」として、伝え合って活用しよう、というものです。Fearless Change では「新しい考え方を組織内に広めるためには?」という観点で、すでにうまくいった人たちの見識を集め、共通性のある項目について「パターン形式」で抽出・記述・推敲されています。そもそもアジャイルという新しいやり方が、まさに組織内でのコミュニケーションを必要としますし、それ以外にもさまざまな考え方の普及に役立つだろう、ということです。

また、この普及のアプローチそのものも、「トップダウンでやらせる」とか「声の大きい人に主導してもらう」のではなく、自分自身が実践者として、着実に周りを巻き込みながら、中長期的視野に立ってコミュニケーションをしていくという、まだに「アジャイルな普及方法」になっていることも、重要なポイントかなと思います。

新しいアプローチを導入したいなら、強制的に使わせるのが一番早い、という主張を聞いたことがあるかもしれない。もし一度した約束には絶対に従わなければならないとすれば、人はなるべく約束を回避するようになるだろう。王様が性急な改革を命令するかもしれないとわかれば、すぐに抵抗勢力が結成される。経営陣が「さあみんな、今すぐ<イノベーション>に飛び込もう!」と言えば、すぐに実現されるなんてことは期待できない。トップダウンの変化の特徴は、そのスピードにあるが、問題があればすぐに対応しなければならない。ボトムアップの変化はゆっくりだが、抵抗勢力への対応はもっと効率的にできる。ボトムアップな変化の特徴は、参加型、情報共有、不確実性、そして抵抗が最小限になることだ。私たちは経験上、現場管理職や上級管理者の適切な援護射撃をもらいながらのボトムアップな変化こそが最良と信じている。

アジャイルの本質 - 納期は決められないという現実を認める

f:id:wayaguchi:20211223084526p:plain

アジャイルな普及方法」ってなんだよ、という話になるのですが、この点については、ちょうど8月にあった Agile 2021 というカンファレンスで、アジャイルマニフェスト起草者の一人、エクストリームプログラミング(XP) の Kent Beck 氏が興味深いことを言ってました。

エクストリームプログラミングの原動力のひとつは、ビジネスとテクノロジーの間の溝を癒すことでした。私は、一般的に言われている2つのグループが激しく対立し、協力する方法を見つけても必要なものが得られないという状況を目の当たりにしてきました。つまり、自分には納期を決定する力があると思っている人が、その力の幻想を手放そうとしなかったのです。そこにエクストリーム・プログラミングが登場し、一連の人間関係とそれを支える儀式、そしてそれらの儀式や人間関係を支える技術的な慣習を提示しました。そして、その代償として、締め切りを指示することができなくなりました。
注: Otter.aiによる書き起こしと、DeepLによる機械翻訳をかけているので正確でない可能性があります。

クラムでも同様に、プロダクトオーナーは要件をプロダクトバックログに順番をつけて記載できるだけで、開発者たちに納期の約束を迫ることはできません。開発者たちは、一つ一つのプロダクトバックログアイテム(PBL)のサイズを見積もったり、これまでのスプリントで完成させた量(実績値)から、チームが持つベロシティを推測することはできますが、それは納期の約束ではありません。

そもそも、実現しようとしているものが、さまざまな要素がからんだ複雑なものである以上、どれだけ深く考えても、事前に完成時期を予想することがきわめて難しいという前提に立つことに、アジャイルの本質があります。ある程度、作ってみたり、使ってもらったり、ということを通じて積極的にフィードバックを受け、絶えず状況を分析しながら、できる限りやっていくしかない、ということです。「事前に机上で分析した納期を満たすように、一方的に履行を強いる」ということがないように、組織や仕組みからととのえるのがアジャイルの本質、というわけです。

当事者であり、最良の予測をアップデートし続ける

f:id:wayaguchi:20211223084636p:plain
私たちのカンファレンスは、誰か他の人のためにやっているものではありません。自分たちが当事者として、一番学びたくて始めたものですし、おそらく一番知りたい人たちが実行委員として、自分の労力を差し出しているという形態です。「いやもっと自分の方が上だ」という人はぜひ、スタッフや講演者として入り込んでいただきたいです。中心にいる一番欲しい人が一番労力を支払っていて、その周辺に、だんだん労力以外のものを支払うという集団が形成されるというモデルです。実行委員会、当日スタッフの皆さん、登壇者さま、スポンサー各社さま、参加者の皆さま、という風に。実行委員会は企画や意思決定をすることよりも、とにかく実現することに重きをおいて作業しています。できることなら、議論すらしたくない。議論はトヨタ生産方式で言えば、付加価値を生み出さない「必要なムダ」にすぎないからです。ですので、基本的には「議論していないことは昨年を踏襲する」という不文律で進めています。会場もなるべく変えないし、お願いする業者さんや、日程などもできる限り変えません。実行委員の入れ替わりも数えるほどしかなく、スタッフも経験者が多いです。学生時代の文化祭とかだと「来年は後輩に譲る」という文化になりますが、私たちは社会人なので、できる限り来年もやってくれるようなくらいには、燃え尽きないようにタスクを健全に回していきたいのです。疲れないようにしたい。

「スタッフが大変な仕事をしている」こともまた、必要なムダ、下手をすると、まったくのムダなので、できる限りスムーズに、無理なく開催したい、と考えています。今年経験した人が来年もスタッフをやってくれれば、教えるコストが少なくてすみます。スケジュール・スコープ・リソース・品質のすべてを、去年の実績を元に考えます。もちろん、変えざるを得ないところは、ちゃんと議論して、実験して、変えることになりますが、まあ、8-9割は去年と一緒でいいと思ってます。ソフトウェア開発をしていても、運用というのは案外そういうもので、運用が安定しているからこそ、ユーザーさんは信頼して使ってくれるのです。ちゃんと実現していれば、期待もしてくれるし、使い続けるものであれば、要望もくれるようになるかもしれません。

チームで行い、知識の塔を切り崩す

f:id:wayaguchi:20211223084707p:plain

安定した運用を続けるために、できる限りチームで進めます。チームといっても「全員が同じスキルになる」とか「意思決定を全会一致で行う」ということではありません。最低限、二人以上で作業内容を把握するとか、相互にカバーできるようにしていく、ということです。「じゃあモブでやりましょーか」とか、「やったことがないので一緒にやりたいでーす」とか、「やってくれてありがとうございます。尊敬してまーす」とか、「今週は都合がつかないので行けませーん」とか、ってな感じで、作業を無理のない範囲で複数人で進めたり、逆に最悪、自分が参加しなくても、大丈夫になるように考えながら動きます。もちろん完璧はないのですが。

知識の塔は周囲から大事にされているが、その人自身はそうした状況に満足しているだろうか?そんなことはない。デイブは安定した立場というメリットを初めのうちは感じるものの、やがて牢屋に閉じ込められて逃げ出せないような気分になってくる。知識の塔は組織全体のボトルネックとなってしまうんだ。デイブは休暇の予定を組めない。現在のプロジェクトだけでなく、すべての顧客からの緊急事態に対して、彼は欠かせない人物となっているためだ。デイブがやっと休暇を取れても、ノートPCは手放せない。休暇から戻ってくれば仕事は山積みになっている。緊急性の低い仕事もすべて彼のところに回ってくるせいだ。

ペアを頻繁に組み替えながら作業する職場では、知識を独り占めするのは不可能だ。ペア作業は本質的に、知識の集中に反する。 僕たちが毎週ペアを組み替えるのは、毎週知識の塔を崩すためだ。チームの誰か一人だけがシステムのある場所を理解していたり、一人だけが精緻なアルゴリズムを把握しているということは起きない。

モブ作業をすると、毎回感じるのは多様性の力です。アジャイルではよく「四つの眼 Four Eyes」でチェックすると言うのですが、二人以上で作業を行うと、それだけでほとんどのミスはなくなります。それでもミスが起きたときは、おそらく全員の責任なので、やはり誰かがつらくなるということもありません。誰かのせいにすることも、ありません。

「おじゃる様」がなぜダメなのか?

f:id:wayaguchi:20211223084837p:plain

技術のわからないマネジメント層のことを、私は「おじゃる様」と呼んでいます。以前ははげちゃびん問題とも呼んでました。「おじゃる様」には悪気はなく、もしかするとまじめで、だからこそ問題を起こします。理解していないけど、責任を持っています、というのは詭弁です。実際に作業していないと、責任を持つことはできません。

「おじゃる様」の存在を許すと、おじゃる様への説明のために作業が発生していきます。「おじゃる様」なりに実績を残さないといけない、となると、問題はさらに悪化していきます。わからない人の実績をつくるために、わかっている人のリソースが消費されていきます。会議が増え、分かりやすい資料作成を求められ、どんどん「おじゃる」度がひどくなっていきます。さらに、そういう会議では「もっと斬新なアイデア」を求める傾向にあります。人々をもっと引き付けたい。聴衆を増やしたい。社会に変革を起こしたい...。自分でやらない分、会議で満足感を得たくなるのかなと思います。でも、そういうことを言っていいのは、自分で実践する人だけにしてほしいです。他人にやらせる社会変革なんて、誰も許容できません。

ということで、私たちのカンファレンスは、おじゃる様は許容しないし、会議だけでアイデアが盛り上がっても、燃えません。それよりも、集まったら共同作業をして、一つずつでも仕事を終わらせていきたい。壮大なビジョンがどうでもいいとは言いませんが、そういうのはカンファレンス本番の発表だけで十分です。それをするのは、実行委員ではなく、発表者の皆さんであるべきだと思います。

滑り出しの力、できることをさっさとやるために

f:id:wayaguchi:20211223084913p:plain
回数を重ねたカンファレンスや実行委員であれば、自発的にやるべきことをみんなでこなせるようになります。定期的に知識の塔を崩していくような取り組みもできるでしょう。しかし、初回はとても難しいものです。お金についても心もとないし、何をやっていいかわからないし、夢は大きい。ですので、すでに開催したスタッフが、他の地域や別のカンファレンスの実行委員に参画して、やるべきことを伝えたり、一緒にモブ作業して、こういうことだよ、というのを伝えていきます。会場やツールにお金がかかるときは、費用のサポートをしたり、旅費が必要な時にはそれをサポートしたりします。

スクラムでは「チームにとっての障害物を取り除く」という表現をよく使います。スクラムマスターという役目の人がよくやるのですが、それが無くなればチームはもっとスムーズに前に進めるのに!という課題や制約を、できればチームのメンバー(開発者たち)自身で取り除けるようにサポートするのです。私たちのカンファレンスでは、誰もがそうした動きを理解しているので、だれかが障害物について言語化したら、それを取り除くにはどうしたらいいか、ディスカッションや、実際に動いてしまう人が出てきます。少なくとも、応援をします。

そこにいる人で決めてもらって構わないし、必要な時には立ち止まって全員の確認をとって決めます。もちろんそのためには資金的な余裕も必要なので、うまく余裕を持てるようにも、考えています。

摩擦がなく動き続けるギア(場)を目指して

f:id:wayaguchi:20211223084946p:plain
私たちのカンファレンスは、実行委員も含めボランティアで運営されています。ボランティアでやる以上は、参加は任意で、個人の意志で参加してもらいます。なんとなく、より多くの時間を貢献するであろう人が実行委員、という感じになっています。もちろんチームなので、その年の個人的な状況によって、貢献できる量はさまざまだったりしますが、信頼しあって、無理のない範囲で、お互いに調整しながら、必要なタスクをこなしていく感じです。成果主義も泣ければ、評価もなく、組織パターンにおける「信頼で結ばれた共同体」のようなものを形成しています。

それなりにタスクがある中で、なにかをやっていくことのモチベーションがどこにあるのだろうと、改めて考えると、いくつかありました。

  1. キーノートに自分が呼びたい人を呼ぶ
  2. 情熱を摩擦なしで行動に移せるような環境を作る
  3. 自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう
  4. 技術とはすべて摩擦を減らすためにある
キーノートに自分が呼びたい人を呼ぶ

RSGTの実行委員をやっていて、最大の恩恵だな、と思うのは、キーノートスピーカーの設定です。これはまったく忖度も配慮もなく、自分が呼びたい人を提案しています。だいたいは海外のカンファレンスに行って、トークを聞いて感動したり、知り合って惚れこんだりした人たちを、日本の人たちに紹介したいというモチベーションです。これは、なぜカンファレンスや勉強会や、研修なんかをやっているか?ということの根幹に関わるところなのですが、日本と海外(特に欧米)との間のディレイを減らしたい、という思いがあります。言語差・地域差・交流の差があるので、そんなギャップは永遠に埋まらないわけですが、それでも、通訳付きで欧米では当たり前かもしれない話を聞いたり、逆に質問や交流をもって、一方的な情報以上の解像度と幅をもって理解を深めていくことは、継続的にやっていくべきことだと思っています。なぜRSGTやDevOpsDays Tokyoが海外スピーカーのキーノートなのか?といえば、それが根本のモチベーションだからです。なので、ある意味そこは、聴衆の意見を全く聞かずに、実行委員のなかでの議論で候補を決めて、その中で交渉して話してくれそうな人をブッキングしています。キーノートスピーチはカンファレンスの全体のテーマをなんとなく決めていくので、早めに決めて告知することで、みなさんからの公募のテーマにも活かしていただけるのかなと考えています。

情熱を摩擦なしで行動に移せるような環境を作る

次が、情熱を摩擦なしで行動に移せるような環境、少なくとも雰囲気を作りたいというところ。セッションを公募制にしたり、Open Space Technology (OST) やパーティ、Discordを通じて皆さんが自己組織的にテーマ設定をして、自由に語り合えるようにしたり、クロージングキーノートで「気持ちの後押し」をしてもらって会期を終えるように工夫したり。関わるすべての人々の情熱がこの一年の活動のエネルギーであり、それは有限なものなので、なるべく摩擦や摩耗なく、仲間を見つけてやり始めてほしい、と願っています。そして、そうした情熱を瞬間的に爆発させるのではなく、なるべく平準化して、安定して燃やしてほしいと考えています。そのための知恵を交換したいです。

自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう

そして、摩擦なくなにかをやっていきたいと考えている、おそらく最大の人間が自分だと思っています。みんなの雰囲気が、どんどん摩擦をなくす方向になっていけば、たぶん自分ももっとやりやすくなると思うんですよね。なにが摩擦になり、人の情熱を活かせなくするのか?多くの皆さんによる「群衆の英知」によって、さまざまなことを学んできましたし、摩擦を減らしてくれたと思います。他の人の情熱に後押しされることもしょっちゅうです。

技術とはすべて摩擦を減らすためにある

そして最後に、「技術を向上したい」という欲があります。人間面や、テストなど技術面の知識はもちろんのこと、オンラインカンファレンスやハイブリッドカンファレンスを行うための機材・配信・コミュニケーションの技術、安定した運営を支える財務面や税法の知識などは、やっていると学べることが多くあります。これらのことは、結果的に自分がなにかをやりたい、と考えたときの摩擦を減らしてくれます。やったことがあれば、できる。まさに経験主義(Empirical) そのものです。

摩擦のないコミュニティ運営

f:id:wayaguchi:20211223085035p:plain
というわけで、普段どんなことを考えながらカンファレンスのタスクをこなしたり、コミュニティに参画しているのか、というあたりをつらつらと言語化してみました。その中で出てきたのが「摩擦のない」というキーワードです。人が複数で何かをすれば、もちろん摩擦が存在するわけですが、できる限り摩擦を取り除いて、ちゃんと議論するべきところはして、社会的に最大効率でものごとが完成(Done)するようにしたい、と考えています。

このことは、カンファレンス運営だけでなく、さまざまな組織的な活動にも共通することなのかもしれないな、と思うところがあります。人々の情熱のエネルギーを最大効率で活かしながら、成果を積み上げていくことができたら、とても素敵なことだし、経済的にも、より幸せが巡ってくる可能性が高まるのではないか、と無邪気に期待している部分があります。

私が関わっているさまざまな場所で、そんな雑談も出来たら楽しいんじゃないかと思います。ぜひ声をかけてくださいまし。



DevOpsDays Tokyo に向けて揃えた機材

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

品川アジャイルが配信を担当したカンファレンスの一つが DevOpsDays Tokyoです。

www.devopsdaystokyo.org

RSGT2021,2022での配信も、実はDevOpsDays Tokyo で機材の購入を支援してもらっていました。DevOpsDays は、もともと「システムアドミニストレータカンファレンス」という名前を考えていたくらい、運用に関して考えるカンファレンスですので、もちろん私たちは、配信のシステム運用をいかに安定させるかを考えているわけです。安定運用できない配信は価値がありませんので(キリッ)。

安定した運用を支える試行錯誤

ところで、安定した運用とはどこから来るのでしょうか。私が考える重要な要素は二つです。

  • 試行錯誤を繰り返して、練り上げた機材構成
  • 試行錯誤を繰り返して、運用習熟した人々

品川アジャイルでは、毎週のように機材の話をして、運用を繰り返しながら、DevOpsDays Tokyo や RSGT におねだりして機材を整え、試行錯誤を繰り返しています。

今回のRSGTでどんな機材構成にするかは、ばやしさんがすでに書いてくれていますので、今回は、その前にどんな試行錯誤をしてきたかについて、機材の紹介を中心に書いてみます。

bayashimura.hateblo.jp

 

配信に向けて買ってよかったもの

ゲーミングノートPC

いきなり大きな買い物ですが、これがないと話にならないのが、ゲーミングノートPCです。機種についてはもう一年くらいたっていて、内容も変動してしまうので割愛しますが、持ち運びに適した13-15インチで、ちゃんとしたグラフィックカードを載せていて、有線LANとHDMI出力に対応したものを選びました。録画したビデオの編集作業などもあるので、エンコード時間短縮のためにも、グラフィックカードは重要です。

www.mouse-jp.co.jp

ビデオキャプチャカード

ビデオカメラからの入力を取り込むために必要なのがビデオキャプチャカードです。

www.avermedia.co.jp

proav.roland.com

それほど高解像度や最新の機材を求めているわけではないので、割と安定したものを使っているのですが、買ってみたらつながらないなどの失敗もありました。最近購入したこれは、USB-Cではなく、Thunderbolt 3 が必要なのに M1 Mac ではソフトウェアが使えないという困った商品でした。

 https://www.amazon.co.jp/AVerMedia-Live-Gamer-Ultra-GC553/dp/B07DHV47HF/

M1 Macbook Pro

昨年、コスパがよいということで急いで確保したのが M1 Macbook です。しかし、有線LANにこだわったことによって、USB-Cに負荷がかかったのか、突如リブートをしてしまうという問題に当たりました。USB-Cが二ポートしかないことと、バスもあまり太くない、ということなのではないかと思います。機械というものは、挿せば動くということでもないのが難しいところです。

www.apple.com

音声インタフェース

パソコンに音声を取り込むための音声インタフェースは、利用実績の多いAG03を使いました。会場からマイク音声をもらって、こちらを経由してパソコンに取り込みます。マイク用のXLR端子も使えますが、基本的には、ステレオ標準プラグで出してもらいました。

jp.yamaha.com

ミキサー、スピーカー、マイク

DevOpsDays Tokyo 2021では、PA機材(マイクやスピーカー)のない部屋の配信があったので、検討の結果、以下のミキサーを入れて実施しました。狭い部屋なので大規模の機材は不要なのですが、ホールなどと同様にマイクとスピーカーを同じ場所で使ってもハウリングが起きないようにする必要があり、定番のヤマハEMXシリーズの中で、最もローエンドなモデルを選択しました。実はこれを買ったおかげで、後述のiPad+iRig2の検証にも役立ちました。

www.amazon.co.jp

スピーカーはJBL BT104 という小型/軽量のものを採用しました。パワーは十分でした。

https://www.soundhouse.co.jp/products/detail/item/269502/

マイクは、ワイヤレスマイクも用意したのですが干渉などであまりうまく使えず、安定して使えたのは、やはり定番のShure SM58 でした。ダイナミックマイクなのですが、いい感じに登壇者の声だけを拾ってくれる感じで、安心感があります。

https://www.soundhouse.co.jp/products/detail/item/69782/

iPad 第9世代

RSGT2022 に向けて、2021年秋モデルの iPad を購入しました。Center Stage 対応版です。配信だけなので64GB版で十分です。カメラ、音声インタフェース、(内蔵カメラ用の)ビデオキャプチャ、Zoom クライアントが全部一台に詰まっているのが衝撃です。

www.apple.com

iPad の現場運用に欠かせないのが、タブレットホルダーです。最近は譜面をiPadで見るプロが多いみたいで、安定したマイクスタンドにホルダーが組み合わせられた安定感抜群のモデルがありました。これはおすすめです。

https://www.soundhouse.co.jp/products/detail/item/208134/

音声インタフェースとしては、iPadの3極端子(入出力)を、通常のライン端子に変換する必要があるので、iRig2を利用しています。

www.ikmultimedia.com

それから HDMI出力で会場プロジェクタに投影するためには純正のLightning-HDMIアダプタを利用しています。

www.apple.com

f:id:wayaguchi:20211216141143j:plain

会議用スピーカー

複数人で話すケースで、かつ会場にPA機材がない場合は、会議用スピーカーを使うことがあります。その場合には、これを使います。RSGTでは、Open Space Technology ように使ってみようと思います。

www.jabra.jp

 

iPadとJabraを駆使した配信を行った映像はこちらになります。


www.youtube.com

 

以上、他にも買って試したものはいくつかあるのですが、結果的に運用に耐えていて、おススメできる機材はこうしたものでした。皆様の参考になれば幸いです。

 

DevOpsDays Tokyo では現在セッションプロポーザルを募集中です!

DevOpsDays Tokyo では現在セッションプロポーザルを募集中です。アジャイルな開発を支えるテストや運用で、日ごろ行っていることをぜひ教えてくだい!

https://confengine.com/conferences/devopsdays-tokyo-2022

 

では、RSGTでお会いしましょう。機材の実際は、ナイトセッションでも話し合えると思います。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16210/night-sessions

実行委員、Women in Agile、品川アジャイル、アギレルゴコンサルティング

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

それなりに年を取ってきて、自分は何をしている人だろうか?という問いがどんどんあいまいになっていくことに、どんどん慣れていく人生を過ごしています。そういう人も多いんじゃないかと思います。「この人、名前は知られてるけど、何ができる人なんだろう?」という痛い視線を感じることもなくはないです。実際、私も、わからん。

f:id:wayaguchi:20211208090910p:plain

ということで、Regional Scrum Gathering Tokyo 2022 では、実行委員業のほか、ご採択いただいた講演を一つ、それからWomen in Agile としてナイトセッションで話題を一つ、あと、品川アジャイルとして配信周りを担当していきます。アギレルゴコンサルティング株式会社としては、2011年から10年以上にわたって Scrum Alliance 認定スクラム研修をずっと提供させていただいている恩返しの意味を込めまして、スポンサーをしています。なんかいろいろありますね。準備ちゃんとできるんでしょうかね。

2022.scrumgatheringtokyo.org

自分としては、だいたい以下のルールでやることを選んでいます。

  • 独自性 = すなわち、自分しか興味持たない部分に戦力を投入する
  • シンプルさ =  すなわち、あまり複雑な技術を使わない。作りこまない
  • 協調作業 = すなわち、必ず誰かとやる。相手にとってメリットのあることを

あと、選択ではなく実施に際しての重要なこととして、ローコストで実行する道が考えられないことは「今はやらない」ということもあります。またそのうちできるかもしれないので無理しない。

f:id:wayaguchi:20211208091014p:plain

実行委員業2022

  • 独自性: 誰かがやっとけばほかの人は楽しめる
  • シンプルさ: 継続的にできることを積み重ねる。ムダを落としていく
  • 協調作業: 実行委員、スタッフ、講演者、スポンサー、参加者の皆さんと

f:id:wayaguchi:20211208090902p:plain

今回の実行委員業は具体的にはたぶん6月くらいから始動しています。本当は10か月前である3月くらいには基調講演を確定させたいなと思っているんですけど、ちょっと遅れてしまいました。できれば日本に来日してくれる人を、と思っていたんですけど、コロナの状況は先がよめないので、オンラインだとしても問題ない形ですすめてきまして、今回は3名とも北米からのオンライン講演となりました。事前録画収録ではなく、英語セッションは当日通訳付きで提供する予定です。

チケットはオンサイトとオンラインをいつでも選択可能な通常チケットと、オンサイトを選択できないオンライン専用チケットを用意しました。食品ロスを軽減するため、事前のアンケートはさせていただくと思いますが、基本的にはいつでも、オンラインとオンサイトを選択できます。前回と同様の対応ですが、コロナの状況が読めない状況では、これが最善と考えています。ありがたいことに、本年も順調に通常チケットは完売いたしました。会場の収容人数は、昨年同様、最大でも定員の50%としています。

実行委員はすべてボランティアで活動していますので、議論や作業の効率性を重視しています。基本的に、なるべく前回実績を活用するべく、「明示的に議論していないことは昨年と同じ仕様にする」という方針です。定員50%も今回は特に議論していないので、前年同様ということになっています。会場の御茶ノ水ソラシティさんも3年目になりますね。昨年はコロナ対策のためのリモートカンファレンス対応ということで、新たに回線の増強などをしていただき助かりました。

昨年、スタッフ作業中に発明された「尊敬してまーす」とインカムで伝える風習があるのですが、本年も運営のFacebookのコメントで飛び交っています。誰かが何か作業を自発的にしてくれたら、感謝を込めて「尊敬してまーす」というのを表明します。半分、冗談のように使っていて、常に微笑みを巻き起こしていますが、尊敬に嘘はないと考えています。日本人はなかなか「あたりまえのこと」を表現することを省略しがちなので、改めて尊敬を表明する風習は、とても心地よいものだな、と感じています。スクラムマスターの皆様、パクっていいですよ。

講演 - スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum (2005) を語るナラティブ

  • 独自性: 案外これまでだれもやってない
  • シンプルさ: 過去の講演に沿って話すだけ
  • 協調作業: 過去のジェフ・サザーランドさんと。壁打ちも繰り返す

f:id:wayaguchi:20211208091238p:plain

今回は、2005年に行われたスクラムの共同発明者ジェフ・サザーランド博士による、スクラムの源流についての講演について、できる限り原典に忠実に伝える試みをする予定です。同タイトルの講演を、2011年の初来日で、Innovation Sprint 2011 の基調講演として行っていただいたのですが、残念ながらビデオを録画できなかったため、それ以前の講演から同内容を探っていきます。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/15962/the-origin-jeff-sutherland-roots-of-scrum-2005

スクラムを着想するにあたって、どういったものを参考にしたのか?最初のスクラムはどういったものだったのか。スクラムガイドには記載されていない、源流を探る内容になっています。それを知ったからと言って、スクラムをうまく適用できるようになるというものではないでしょうけれど。生物学の世界では「個体発生系統発生を繰り返す」という言葉があるそうです。ある生物が生まれる過程は、その進化の過程で経てきた様々な生物をトレースするように行われるということです。ジェフさんがスクラムを着想してやってみた、という情報の中には、ソフトウェアやものづくりの進化そのものも織り込まれているのではないかと思います。その知識を深めることで、さらに皆さんのチームのスクラムの進化にも役立つかもしれません。

個人的には、スクラムフェス大阪でスクラムの源流となる「The New New Product Development Game (新しい新製品開発のゲーム)」(竹内・野中論文)をみんなで読みました。スクラムフェス三河XP祭りでは、認知科学の領域で協調作業を研究した論文「Constructive interaction and the Iterative Process of Understanding(建設的相互作用と理解の反復的プロセス)」(三宅なほみ「ボビンの論文」)をみんなで読みました。偶然にも同じ1986年に発表されたこの二本の論文は、当時の組織論と、認知科学におけるコラボレーションの研究の代表例と考えています。35年前の論文ではありますが、ほとんど色褪せず、現代の私たちのスクラム実践に示唆を与えてくれるものだったと思います。

f:id:wayaguchi:20211208091402p:plain

スクラムの最初の実践は1993年で、この野中竹内論文を参考にしたと、ジェフさんは語っています。また、主体的なチームメンバーによる協調的なコミュニケーションを活用する点は、強いリーダーによる専制的な組織運営とは、真逆の文化を感じさせます。また、トヨタ自動車の文化を参照している点で、日本人にとっては理解しやすい内容になっていると思います。

実は、こうした過去の資料や講演をとりあげるようになったのは、昨今の機械学習音声認識技術の向上が背景にあります。このセッションの準備においても、そうした技術を活用しています。10年前にも同じ元資料は存在してたのですが、そうした原典に、容易にアクセスできるようになったことは、現代の我々にとって、日本語と英語の垣根を超えるための、非常によい機会になっていると感じます。

f:id:wayaguchi:20211208091447p:plain

以前は「自分の運営するカンファレンスでは講演しない」というルールを自分に課していたのですが、最近はスタッフ業もこなれてきたので、講演もできるようになってきました。今回もプロポーザルを出しまして、ありがたいことに多くのLikeをいただきまして、採択されました。(実行委員なんだから自分で採択されるようにできるだろう、と感じる方もいらっしゃるかもしれませんが、このトークに関しては完全にLikeの数で採択されていて、忖度も関与もしていません。)

ナイトセッション: Women in Agile 

  • 独自性: 案外これまでだれもやってない
  • シンプルさ: アジェンダなしで話すだけ
  • 協調作業: WiAメンバー4人で

f:id:wayaguchi:20211208091518p:plain

初日(1月5日)の夕方には、通常のセッションのあと、懇親会の代わりにナイトセッションという枠を用意しています。特にアジェンダを用意していませんが、あらかじめ提案された内容について、Open Space Technology のように、カジュアルな雑談をしよう、というセッションです。 

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16210/night-sessions

Women in Agile は、職場や社会における女性や多様性についての課題に取り組むコミュニティ活動として、世界中で行われているものです。Women Developers Summit で日本の有志のセッションを行いました。引き続き Women in Agile を立ち上げていくべく、カジュアルな議論を行っていきます。女性はもちろん、それ以外の方の参加も歓迎です。ぜひ、立ち寄ってみてください。

そのほかに、オンライン配信について語り合うセッション、地方コミュニティについてのセッション、新しく参加した方向けの知り合いを作るセッションなどが行われます。他にもセッションのテーマを追加することもできますので、興味あるテーマを見つけて、参加してみてください。

品川アジャイルによる配信 - よりシンプルに

  • 独自性: 手間も機材費用もかかるのでボランティアでやる人がいない
  • シンプルさ: 放送機材ではなくパソコン技術を活用
  • 協調作業: 品川アジャイルの皆さんと

f:id:wayaguchi:20211208091606p:plain

すでにばやしさんがブログに書いてくれている通り、今年も品川アジャイルとして、ハイブリッドカンファレンスを支えるリモート配信を行います。昨年の反省を活かしながら、さらに新しく発表された機材を活用して、よりシンプルでスリムな配信体制を実験してきました。これがうまくいくと、多くの勉強会のハイブリッド開催に活用できるのではないかと思います。機材も含め、ぜひ参考にしていただければと考えています。

bayashimura.hateblo.jp

アギレルゴコンサルティング株式会社スポンサーセッション

  • 独自性: アギレルゴはそもそも人が少ない
  • シンプルさ: 今回は松元さんにおまかせ(丸投げ)するだけ
  • 協調作業: 松元さん、松浦さんと

f:id:wayaguchi:20211208091745p:plain

アギレルゴのスポンサーセッションとしては、松元さんに話していただくことになりました。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16242

本年も大変盛況な、認定アジャイルリーダーシップ研修に関連して、リーダーシップ論の最新の話をしてくれるようです。チームとしてスクラムを行うだけでなく、組織に新しい仕組みを導入するリーダーとして、どのようにふるまうと良さそうなのか、大企業でアジャイル適用から経営企画までこなしてきた、松元さんなりの視点で整理してくれそうですね。

ゲーム業界の大規模カンファレンス「CEDEC2021」で、松元さん、松浦さんと、リーダーシップについてのセッションを提供しました。こちらも大変盛況で、多くの好意的なフィードバックをいただきました。

cedec.cesa.or.jp

ということで、RSGT2022でお会いしましょう!

  • 独自性: ハイブリッドカンファレンスとして二年目の実績
  • シンプルさ: チケットを買うだけで参加できる
  • 協調作業: 実行委員、スタッフ、講演者、スポンサー、参加者の皆さんと

f:id:wayaguchi:20211208091929p:plain

ということで、今回のRSGT2022で私が担当する予定のことや、その関連のお話をまとめました。会場で、Discordで、みなさまのご参加をお待ちしております。

 

ちなみにこのブログの草稿は、「閃光のハサウェイ」という映画を一本聞き流しながら書きました。約100分の集中時間確保に使っています。「ハサウェイタイマー」と呼んでいるんですが、他の人におすすめしたところ、「やってみたけど、全然集中できない」というフィードバックをいただいております。あれ、おかしいな。

f:id:wayaguchi:20211208092004p:plain

全然関係ないですけど、閃光のハサウェイについて、プロデューサーの小形さんがどういう考え方で進めているかを話しているインタビューです。

s.akiba-souken.com

 

カンファレンスの基調講演を誰にお願いするか考える時のノート

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

 

基調講演を決める時に考えたらよさそうなことを徒然なるままにあげてみたメモです。

f:id:wayaguchi:20211208093527p:plain

  • 実行委員からアクセスできるか(間接的でもよい
  • どんな話をして欲しいか伝えられるか
  • なぜその人に、いまお願いしたいかを伝えられるか
  • 適切な謝礼でお願いする = 無償カンファレンスの場合は、そこの場所で話すことに意義を感じてくれそうな人 (お互いのリスペクト)
  • 他のカンファレンスで話している人だとお願いしやすそう(聴衆がかぶらないなら新作である必要はない
  • 当日のスケジュールを確実に抑えてもらう
  • 初めての参加者も聞くべき話
  • アジャイル歴が長い人だけが聞きたいような奇をてらった人選はよく考えてから(悪いとは限らないので、ちょっと冷静になってもやろうって思えるか
  • オープニングを除けば、その人のトークから1日のテンションが決まるので、刺さるとか明るいとか燃えるとか、イメージをつけられる(終わった時にどうなってそう?
  • そういう意味では聞いたことある話者はお願いしやすいかもですね(思ったよりマンネリって起こらなそう
  • コミュニティのカンファレンスは集客できなくても赤字にならないようにやるので、基調講演者の人気で参加者を増やそうというのは考えなくて良さそう(客寄せパンダさんじゃなくていい
  • 断られたら引き下がる = 優先順位付き候補リストを作っておく
  • 性別とか年齢とかのダイバーシティも考えるといいこともある...けど、そこそこに (属性だけでいい話がハマるわけでもない
  • ここ数年以内にお願いしてないこと
  • 実行委員ではないこと
  • ただし正解はない

株式会社ホロラボに入社しました。 - 最初の2週間でやったこと

株式会社ホロラボに入社しました。アギレルゴコンサルティング株式会社は退社するわけではなく、引き続き研修中心に仕事を行っていきます。

ホロラボとのご縁

ホロラボは、Kinect とか HoloLens をやっているコミュニティのエンジニアを中心に2018年のHoloLens 日本向け正式販売開始を契機に設立されました。私は当時楽天株式会社で Rakuten Technology Conference というのを実行委員の一員として運営していて、そこで、ARとVRに関する展示をしてもらおう、という回があり、その際に、ホロラボ設立直前のCo-Founder、中村薫さんと伊藤武仙さんに出展をしていただいたのがご縁の発端になります。中村さんについては、さらにさかのぼること10年くらい、Shibuya Trac とか すくすくスクラムといった勉強会からのご縁になります。遠巻きにKinectやHoloLensでの活躍を眺めていたのですが、2019年末にホロラボの拡大に伴って組織コンサルのご依頼をいただいたところあたりから、RSGTで話してくれたり、たまにお邪魔してピザを食べたり、などという交流があったのですが、今回、組織拡大に伴って起きてきそうな様々な課題を一緒に考えていきながら、エンジニアの人たちが明るく暮らせるような組織づくりに寄与できたらうれしいな、ということで入社させていただくことにしました。

f:id:wayaguchi:20210817082852p:plain

ホロラボの組織

ホロラボはまだそれほど大きくない組織です。学校で言えばひと学級分くらいの規模感なので、組織階層はかなりフラットです。いくつかのチームに分かれています。2019年にコンサルしたときには、ちょうどこのチームを作ろうか、というあたりだったのですが、そこから1年半ちょっとが立って、おおまかには企業向けにソリューションを展開するチームと、プロダクトのチームに分かれています。軽量ですが本部機能や総務の人たちもいます。

もともと企業向けに個人として受託をやっていた人たちが会社を設立した、というのが源流ということもあり、企業としてPOC(概念実証)や先行研究としてVR(仮想現実)やMixed Realityを取り組んでいく際の技術的なパートナーとして多く採用されています。一人一人が実現力のあるエンジニアで、顧客の要望に合わせて、というだけでなく、相談にのりながら、現時点で技術的に実現可能な部分を見極めて、比較的短期間で成立させていく、というのが現在の主流のビジネスになります。

プロダクトとしては、もともと様々な企業向け案件での実績の蓄積から、共通化されたワークフローや、煩雑なデータ変換(ETL)などを、プロダクトとして切り出したものがあります。

https://hololab.co.jp/service/

f:id:wayaguchi:20210817083237p:plainf:id:wayaguchi:20210817083255p:plain

f:id:wayaguchi:20210817083330p:plainf:id:wayaguchi:20210817083354p:plain

f:id:wayaguchi:20210817083528p:plainf:id:wayaguchi:20210817083552p:plain

最初の二週間でやったこと

まずは、企業向けにソリューションを提供しているチームの人たちと面談をすることにしました。本当はもう少し手っ取り早く、ワークショップで課題や方向性を、というイメージで相談されたのですが、任天堂の故岩田聡さんが、前職であるHAL研究所の社長を引き受けた際に全員との面談をしたというエピソードを思い出しました。
f:id:wayaguchi:20210817080529p:plain

しかし、岩田さんと違って、私はこの組織についても人々についても、技術についてすら全くの素人であることもあり、まずは皆さんがどんな仕事をしているのか?なぜホロラボに入ったのか、など、個人的に興味のある範囲の話をざっくばらんに教えてもらいました。これは本当に楽しい時間で、特色のある多彩なエンジニアが集まっている会社であることを、改めてはっきりと認識できました。

まさに、岩田さんが言っていることを、その片鱗だけですが、追体験できたような気がします。

いろんな人に面談すればするほど、
わたしはいろんなことがわかりまして、
そのなかから
どういうふうに
組織を作りなおして、
どういう運営をしたらよくて、
なにがみんなのやる気を
ひきだすことに役にたっていて、
なにがみんなの
やる気を阻害しているのかとか……

すべて見えてくるんですね。

半分正しいことを避ける

今回、組織について考えていくということもあり、改めてボブ・サットンさんが話していたことについて読み直したりしています。「半分正しいこと」を避けながら、一歩一歩みんなで考えて、社内だけでなく、お客さんやユーザーさん、もちろん家族や地域社会の人たちを含め、いろんな人が幸せに楽しくやっていけそうな組織を目指していければな、などということを考えています。

kawaguti.hateblo.jp

今後とも、ご指導ご鞭撻のほどをよろしくお願いいたします。

 

エンタープライズアジャイル勉強会 - マネージャー向けのマネジメントセミナーやります (5月12日)

エンタープライズアジャイル勉強会という団体の実行委員として、創立時からお手伝いさせていただいております。エンタープライズアジャイルが特定の方法論や、既存のエンタープライズXXの焼き直しにならないように、ちゃんと大組織の人がアジャイルをやる場合の手助けになるような勉強会にすることを目指して、お手伝いを続けてきました。

で、主要メンバーの方々との議論の結果、いま大きな課題になっているのが、アジャイルにピンときて乗ってきた「以外の」「普通の」マネージャーの方々への啓発や教育やサポートであろう、ということになりまして、そうした方々向けの「セミナー」(サミットとかカンファレンスとか勉強会って言わない)を開催しよう、という運びになりました。ですのでこれはセミナーです。怖くないし、平日ですし、無償なので、安心して周囲のマネージャーさんを誘ってください。決して「はげちゃびん」とか言わないように。

タイトルにデジタルトランスフォーメーションを冠したのは、「デジタルトランスフォーメーションって言ってる人ってマジはげちゃびん率高いよね」ということでは決してなく、DXが意味するのは「全員がちゃんと学んで近代化していくこと」であろう、本気でやっていかないとやばい、ということです。マネジメントが正しく、現場の観察や、学習科学、チームマネジメント、サーバントリーダーシップリーンスタートアップなどのアイデアを学び、各現場なりの取り組みをサポートして学び続ける組織ができたならば、現在のように割と同度でもいいツールや仕組みやしがらみに追いかけられて本業が解決すべき顧客課題に時間をさけないなんて、子供のような言い訳をしなくてもよくなるに違いない、という思いがあります。

ということで、普通にマネジメントセミナーとしてよい構成にしたつもりですので、安心して周囲のマネージャーの皆様や人事・教育研修担当様へのお声掛けをお願いいたします。オンライン開催です。 5月12日は平日です。

申し込みはこちらからです。

エンタープライズアジャイル勉強会

f:id:wayaguchi:20210408150241p:plain

f:id:wayaguchi:20210408150259p:plain



新幹線お掃除の天使たち 「世界一の現場力」はどう生まれたか?

新幹線お掃除の天使たち 「世界一の現場力」はどう生まれたか?

  • 作者:遠藤 功
  • 発売日: 2012/08/28
  • メディア: 単行本(ソフトカバー)
 
見える化―強い企業をつくる「見える」仕組み
 
コロナ後に生き残る会社 食える仕事 稼げる働き方

コロナ後に生き残る会社 食える仕事 稼げる働き方

  • 作者:遠藤 功
  • 発売日: 2020/07/18
  • メディア: 単行本(ソフトカバー)
 
サーバント・リーダーシップ入門

サーバント・リーダーシップ入門

 
教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)

 
教育心理学特論 (放送大学大学院教材)

教育心理学特論 (放送大学大学院教材)

 
Fearless Change

Fearless Change

 

 

This is DevOps : 4/15-16 DevOpsDays Tokyo 2021 を開催します。

もう来週にせまってきたのですが、DevOpsDays Tokyo 2021をオンライン/オンサイトのハイブリッドイベントとして行います。場所はいつもの大崎ブライトコアホールです。感染対策に注意を払いながら、オンラインとオンサイトの垣根をできる限り作らない運営を心掛けていきます。4/15-16です。

昨年4月のカンファレンスはコロナウィルスの緊迫感が高まる中、まだオンライン開催のノウハウもなく、やむなく中止といたしました(DevOpsDays Tokyo 2020 中止の経緯 - kawaguti’s diary) 本年は、コミュニティやホール関係者の皆様の継続的な努力の賜物で、オンライン開催もよく行われるようになりましたし、1月のRSGT2021ではハイブリッド開催にトライして成功を収めましたので、DevOpsDays も、ハイブリッド開催にトライしております。実費負担の公平性の観点で、オンラインのほうが価格を安く設定しております。オンサイトチケットの方もオンラインで鑑賞いただけますので、それぞれご都合の良い方法でご参加ください。

 

f:id:wayaguchi:20210406100217p:plain

今回もなかなかほかのカンファレンスにないラインアップとなっておりますので、ぜひぜひご検討ください。

 

いくつかのセッションを紹介します。

 

モブプログラミングとDevOps、テスト自動化

モブプログラミング発祥の地、Hunter Industries のソフトウェア開発部門の、現在の代表者、Chris Lucian さんのセッションです。

f:id:wayaguchi:20210406100805p:plain

一昨年私も2週間ほどお邪魔しまして、モブで継続的デリバリーをずっと行っているワークスタイルや技術への探求、お互いに学びあう組織の実際の姿に感動しました。最新版のレポートを現地から、していただきます。通訳もあるし、正直これだけでたぶん元が取れるんじゃないかと思います(サンディエゴまで見学に行くことを考えれば)。

confengine.com

Hunter Industries からの最初の経験レポートを翻訳しました。著者のWoodyさんは当時のIT部門の代表者です。CEOに招聘されて、旧来型の運営をしていた部門を大きく改善しました。最初の一歩は「見積もりはしない、リリースタイミングは開発部門が決める、半年はこのやり方に任せる」というのをCEOと握ったそうです。ストーリーカードをベースにXPのプラクティスに従い、技術的卓越性とビジネスサイドとのコミュニケーションを常に行って、一年半の間、不具合が出ないことで、信頼を勝ち得たそうです。

kawaguti.hateblo.jp

この先で、コロナ禍の現在、同社がどのように仕事をしているのか、どんなチャレンジをしているのか、すごく気になりますよね。

 

育児的ソフトウェア開発

シリコンバレーから日本のソフトウェア開発文化を見つめ続ける、バリバリのエンジニア川口耕介さんによるセッションはこちらです。従来の狭義のDevOpsから視野を広げ、雇用形態からソフトウェア組織に至るまで言及していくそうです。これはエンジニアだけでなく、さまざまな職種の方に参考になりそうです。

confengine.com

このセッションだけでも元が取れる感じがします。いやほんとに。

f:id:wayaguchi:20210406101912p:plain

 

 

日本企業の現在進行形、文化的負債との戦い

「いやいや米国の事例はええねん。日本でどうするかや。」とお思いのみなさま、もちろん日本の企業での実践事例もたくさんお伝えします。最初の一つはウイングアーク1stの皆さん。品質保証部門の改革から始め、8年にわたって技術的負債と組織的に向き合ってきた皆さんのセッションです。もちろん、経営陣が全員エンジニアのようなラッキーな会社さんではありません。ビジネスと向き合い、組織と、人と向き合って、どのようにトライを重ねてきたのか、とても気になります。

confengine.com

正直このセッションだけで、元が取れる人も多いんじゃないでしょうか。いやマジで。

f:id:wayaguchi:20210406102941p:plain

 

ほかにも日本企業の現在進行形がたくさん

これ以外にも、多くの日本企業の現在進行形の取り組みをご紹介いただきます。ここまでのセッションでもう元を取っていると思いますので、なんて贅沢なご褒美でしょうか。ほんとにほんとに。

 

 

海外からも多くご登壇いただきます(通訳付き)

さらに多くの海外講演者もいます。米国大手小売業(ショッピングセンター)のTarget社のDX/DevOpsを支えるTarget Dojoのミグスさん。

中国テンセントのJihai Zhouさん

 

機械学習(ML)時代のDevOps

機械学習の時代を迎え、大規模なデータをどうやって運用・テストしていくか、先進企業のお話もいただきます。

もちろん初めの一歩もカバーしてますよ!ありがとうございます。

 

今回はテストやインフラのコミュニティのレジェンドの皆様も

DevOpsの時代には、どんどん複雑化、高頻度リリースをすることになり、どうやって品質を作りこんでいくかが、これまで以上に課題になってきます。テストのモダナイズなしにDevOpsはありえません。テストコミュニティのレジェンドの皆様の知見もいかんなくご紹介いただきます。え、こんなにそろってしまっていいの?

 


基調講演はDevOpsDays 創始者のPatrick Deboisさんと、マイクロサービスアーキテクチャのSam Newmanさん

ダメ押しになってしまいますが、今回は欧州からお二人のキーノートをいただきます。

Patrick Deboisさんは、DevOpsDaysカンファレンスの創始者です。もともとはシステム管理者のカンファレンスを考えていたそうなのですが、そこで2009年のDevOpsという用語の誕生に立ち合い、DevOpsDaysを立ち上げるにいたりました。2019年にはベルギーのヘント市で10周年のミートアップが開催されました。現在は欧州、北米、アジア、南米、アフリカと、全世界に広がっています。
Sam Newmanさんは、名著「マイクロサービス・アーキテクチャ」、そしてさらに近著「モノリスからマイクロサービスへ」を通じて、安易なマイクロサービスの導入に警鐘を鳴らし、分析から移行までを詳細に紹介しています。

f:id:wayaguchi:20210406110456p:plainf:id:wayaguchi:20210406110510p:plain

基調講演だけでも貴重すぎて、これだけでお釣りが来ますね。

 

エンジニアリングプラクティスの現在と組織的移行の未来を

このほかにも数多くのセッションと、スポンサーセッションがあります。スポンサーの皆さんも、なんといいますか、ぜんぜん売り込む感じではなく、あくまで実践者としての知見を共有していただきます。ぜひともDevOpsの現在を感じてください。これ以上はちょっと考えられないラインアップになっております。ぜひご参加をご検討ください。

https://confengine.com/conferences/devopsdays-tokyo-2021/schedule/rich

f:id:wayaguchi:20210406102057p:plain

f:id:wayaguchi:20210406100529p:plain