皆さんの推薦書 ~ みんなで選ぶ!今読むべきアジャイル本・技術書

XP祭りに関連して、「みんなで選ぶ!今読むべきアジャイル本・技術書」というアンケートをしております。

kawaguti.hateblo.jp

 

アンケートでご推薦いただいた本


およせいただいた推薦書を、併せていただいたコメントとともに、貼っていきます。

エクストリームプログラミング
 

古典になりつつありますが、あえて今読むべきと推薦します。思想や考え方の根底はここに書かれているので、チームや組織で解釈を共有しあうことで、次の一手につながるのではないでしょうか。

自分の著作なので手前味噌で恐縮ですが、 「なぜアジャイル開発なのか」を非エンジニアでもわかる地点から丁寧に読みといた、DX時代にフィットする良書だと自負しています

インターネットに関わる仕事をしている人なら、どのエピソードを読んでも 「わかる!!」 「あーーー・・・(遠い目)」 「な、なるほど、、、これをやったのか、、、すげえ、、、俺らもやるしかないのかなー、、、」 みたいになると思います。

MSAをはじめ現代のソフトウェア エンジニアリングの"当たり前"が体系的に分かるため

トヨタ生産方式

トヨタ生産方式

 

Lean, KANBAN, Agileのルーツ(の一部)がここに! 先の見えない低成長時代・無成長時代でも利益を確保し、生き残るには、変化する顧客-市場の要望に対応しながらも(多品種少量生産)、原価低減のために徹底的に無駄を省くこと。 そのためにはニンベンのついた自働化(個々の専門能力を高め、幅を広げ、多能工を実現する)とやらなくていいことをチームワークで最大限排除して"ジャスト"インタイムを追求する2本柱によるトヨタ生産方式。 米国のFordやスーパーの在庫管理からの学びをもとに、カンバン、平準化、カイゼン、5Whys(なぜを5回繰り返す)などの創意工夫の歴史など、著者の伝えたい事が母国語で読めます。日本人で良かった。 大野さんも自分たちの知恵がソフトウェア開発者に活用されて、Agileというかたちで幅広くプロジェクト管理や経営に活かされる事になるとは想像してなかったのでは。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

  • 作者:Matt LeMay
  • 発売日: 2020/03/19
  • メディア: 単行本(ソフトカバー)
 

組織運営において陥りがちな3つの重力は、会社全体でアジャイルを考える必要があることを痛烈に感じさせてくれます。また、3つの重力に対して、組織が良い方向に進んでいるのか?、悪い方向に進んでいるのか?、を判断できる組織の兆候が記されていることにより、自身が所属している組織の状態を、明確に知ることができ、組織の指針となる本になっています。

 

 

アジャイル戦略論 「チーム作りの巻」 ~ わたしの場合

RSGT2021にプロポーザルを出しました。3人で自分の言葉でチーム作りを語ってみようという話になりまして、まず私の分の概要を書いてみました。

Regional Scrum Gathering Tokyo 2021 - アジャイル戦略論 「チーム作りの巻」~すべての基礎はチーム作りにあり。 | ConfEngine - Conference Platform

まずはさっと脳内をダンプするというレベルなので、みなさんのご意見をいただければ幸いです。10行くらいの概要と、本番スライドが作れるといいなぁと、差し当たって考えております。

 

ここから原稿です。

 

f:id:wayaguchi:20200907093341p:plain

  1. 一人目の仲間を作る

デレク・シヴァーズが有名なTEDトークで語った通り、何かの社会的な活動を起こす際に、一人目のフォロワーが鍵となる。何かを始める時には、まず先行者を探し、フォロワーになれないか考えてみるのがよい。適切な先行者がおらず、リーダーにならざるを得ないときは、一人目フォロワーを見つける必要がある。
https://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=ja

 

一部の方の期待を裏切ってしまうかもしれないが、アジャイル戦略論は、アジャイルという武器を使ってあなたをリーダーにする話ではない。アジャイルという企業活動上の新しい必然を、企業の中に定着させるためにどうすればいいか、ということだ。だから、あなたに権力があればそれを適切に使い、ないなら権力を持った人とうまくふるまうことによって、目的を達成しよういう立場をとる。それゆえ、まずビジョンを共有し、自分の持っていないものを補完してくれる仲間が必要なのだ。

 

  1. 話し合いながらアウトプットする

未来は決まっていない。アジャイルな考え方とやり方を、組織の人々がどのように体現するようになるかは、全く予想もつかない。しかし、現在のような激しい競争環境のなかで、かつ技術人材も潤沢とはいえないあなたの環境で、実のある成果をどのように、文字通り「ひねり出して」いくかを考えないといけない。発想だけでなく、なるべくコストも期間も使わずに最初の成果(Low Hanging Fruits)を手に入れるために、何ができそうか、二人で考える必要がある。今使えるリソースは何で、どうであれば成果といえるのか。足りないものはなにか。多少のはったりは必要かもしれないが、基本的には大きなリスクを会社や上司にとらせないで最初の勝利を得るには何ができるか。(ちなみにここで大きな借りを作ってしまうと、要求水準が高まって、無理な成果を求められたり、叱責されることになるので、できれば大きな借り物をせず、バットを短く持って振りぬきたい。借りるにしても少人数からとしよう。踏み倒しても許してくれるような信頼関係のある相手=パトロンがいれば最適だ)。

 

Software in 30 Days でスクラム共同創設者の二人は「パイロットプロジェクト」の選び方として、2つ選ぶように推奨している。失敗してもリスクの小さい新規事業のようなものと、社内で重要な機関となるプロジェクトだ。もし、上級の管理職の指示やサポートの上で行うならば、そうした戦略がよいだろう。もしそれほど支援を得ていないのであれば、もっと軽量に始めるほうがよいように思う。組織を一切いじらず、既存のチームである程度始められるならそれが一番良い。

 

  1. ものの置き場を確保する

仲間と初期の目標を決めたなら、まず大事なのが、ものの置き場を確保することだ。そんなことあとでいいと思う人もいるかもしれないが、トヨタ生産方式でも、道具の位置を決めることはとても重要と考えられているという(要出典)。企画はどういうフォルダに置くのか、ソースコードや成果物はどこに置き、誰に見てもらえるようにするのか。デリバリー先のサーバやハードウェアはどこか?ネットワークは用意できているか?実は多くのアジャイルコーチングの現場で最初に問うのがこの点だ。遅いプロジェクトは、だいたいここができていないか、複雑すぎるか、後回しで考えていない。アジャイル最大の敵が、堅牢というか、昔ながらすぎる会社のITインフラだったり、そうした人々の無知だったりするのっではなかろうか。まずそうした部門への味方づくりが必要という場合も少なくない。

 

社内の根回し、というと大げさだが、あなたがもし「相手が何者かもわからない人から特別対応を求められた」としたら、どうするか考えてみてほしい。上司と相談のうえで、正式に断る理由を考えるのではないだろうか。こちらも忙しいのだ。特に何かをなそうとしている人であればあるほど、忙しいので、関係ないことに巻き込んでほしくないものだ。社内で最初に成果を出すためには、ここは避けて通れない。同意してくれない相手でも、戦わないですむような線引きをしておくことが重要だ。しばらくはお目こぼしをお願いして、その間に成果を出せばよい、かもしれない。

 

  1. 成果をアピールする

成果がでるかどうかは、進め方次第だろうが、忘れてはいけないのは、アピールすることだ。人は、やらせてほしいときにお願いすることは熱心だが、やり終わった後の宣伝は面倒くさがる。しかし、やったことをアピールすることはとても重要だ。組織にとってもあなたにとっても。アピールによって、次のステップに向けての理解を醸成することができる。逆にアピールできないとしたら、目標が間違っていたということかもしれない。アピールの仕方も求められるものも組織文化によってまちまちだ。誰も聞いてくれなさそうな時は、社外コミュニティで発表するのがよいかもしれない。もし社内が社外発表を許容しないような文化なら、コミュニティの先達に相談してみるだけでも、自分の立ち位置が明確になるはずだ。

 

  1. やったことをふりかえる

自分たちでやったことをふりかえる時間をとることも極めて重要だ。まず、ノーム・カースの最優先指令どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」を肝に銘じよう。そして、自分たちがやってきたこと、できていることを認識する。そのうえで、次の実験をどうするか、考えてみるのだ。

kawaguti.hateblo.jp

  1. 技術的負債を解消する

ソフトウェアシステムというのは、おそらく、いつか破綻する構造物だ。一度書いたものが永遠に動き続けると考えるのは幻想にすぎない。しかも現代のソフトウェアのほとんどは他社が作ったライブラリにそのほとんどを依存しており、自分が書くコードなどはほんの一部、多くても1%にも届かないだろう。既存の優れたライブラリや仕組みを使って、自分たちのしたいことを組み上げるのがソフトウェア開発というものだ。常に陳腐化するし、常に不確実性というものが存在する。すでに書いて動いエイルコードでも、不断の注意をもって学び続けなければ、容易に操作不可能になる。様々な階層のテストを書く、リファクタリングを行ってコードを改善する、などは自分たちのコードをチームで再学習することにもつながる。中身がわからないのに、次の一歩を効率的に進めることはできない。アジャイルの要諦は、迅速に作れるチームを作ることだ。自分たちの作ったいるものに徹底的に慣れる必要がある。

スクラムマスターに関する翻訳書が出ます - ScrumMaster the Book

スクラムのコミュニティの皆さんと訳したスクラムマスターに関する本が出ます。開発チームの支援にとどまらず、組織全体でのスクラムマスターの働き方について、幅広く言及した本です。 

 

そのコンセプト「スクラムマスター道 ScrumMasterWay」はこちらのサイトに手短にまとまっています。

scrummasterway.com

このサイトの翻訳は永瀬美穂さん。本書では日本語版序文をお願いしました。

ちなみにもう一人日本語版序文をお願いしていまして、ロッシェル・カップさん。原著でお読みいただいて、ご推薦をいただきました。

 

この本の面白いところ 

この本のどこがおもしろいのか、といえば、ちょうどさっきFacebookにこんなことを書きました。

スクラムマスターの本なのに、まるで組織そのものの隠れたプロダクトオーナーのようなビジョンを持ってるところですこれをエグゼクティブ向けに書いてないあたりは、いかにもスクラムだと思う。傾聴や促し、コーチングなどの知識は深くて果てしないものなので、あえてそこに深く立ち入るのではなく、ポインタと簡潔な説明で済ませ、組織全体に目を向けさせようとする。開発チームやスクラムマスターが初期の成功のあとで、しばしば内向きになってしまうことを戒めている。プロダクトオーナーであれば、ビジネス的な結果が出ないことで間違いを否応なく知ることになるが、開発チームやスクラムマスターは、自ら目線を上げない限り、Us and them (あいつらわかってない)になりがちなのかもしれない。少なくともスクラムマスターは、長期的なチームの成功を目指して、様々なリスクを顕在化し、一つ一つ潰していく手助けをしないといけないのだろうと思う。テストはこけるし、UIはいけてないし、コードは腐っていく。人は痛みに慣れる。いつのまにか、焦燥は当たり前にとって変わり、安定は慢心に変わって足元を脅かす。改善し続けないといけない。コストを下げ、当たり前をアップデートする。目に見える戦いが始まる前に、勝っておかないといけない。オペレーショナルエクセレンスを実現するために、今日何をするのか。ヒントをちりばめ、調べやすく整理してくれている。

翻訳作業の過程も面白いので、これは折に触れて訳者陣から発表されていくものと思います。同じく自分のFacebookより。

しかし訳者陣が一人として同じ組織にいないのが面白い。コミュニティで集まって訳した、というのがバッチリ当てはまる。たまにZoom集まって、くだらない話をしながら、淡々とリモートモブプロで訳をみていく。コロナがきたことで期せずして当たり前になったこの働き方を、昨年からずっと探求してきました。リモートワークでも全然変わらず働けているのは、この翻訳作業によるところも結構あります。楽しかったです。ありがとうございました。

 

原著はこちら

アジャイルではおなじみ、Mike Cohn Signature Series です。

 
書いたのは Zuzana Shocova (ズザナ・ショコバ) さん。チェコにおられる認定スクラムトレーナーです。チェコアジャイルコミュニティイベントを立ち上げた人でもあるそうです。カンファレンスで何度かお会いしていて、「あなたはどこにでもいるね」と言われております。

 

RSGT2021で基調講演していただきます

この出版のタイミングもあり、Regional Scrum Gathering Tokyo 2021 では基調講演をお願いすることになりました。左上の赤髪の女性がズザナさん。

f:id:wayaguchi:20200903072743p:plain

2021.scrumgatheringtokyo.org

 

おたのしみに!

 

XP祭り2020 にご協力いただいた見本誌・寄贈本を随時公開していきます。

XP祭り2020は9/19(土)にオンラインで開催されます。オンラインでは場所は特にありませんが、アギレルゴコンサルティングの新宿のオフィス Agilergo Dojo としてご協力しております。

f:id:wayaguchi:20200825165837p:plain

jp.agilergo.com

 

アジャイルコミュニティへの入り口。XP祭りもオンラインへ

XP祭りは初めて開催されて以来ずっと、週末に無償で行われてきたイベントです。初心者/入門者の比率が高いのが特徴です。かくいう私も初めて参加したアジャイルコミュニティイベントはXP祭りでした。

ここ数年はずっと鷲崎先生のご協力で、早稲田大学さんをお借りしてきたのですが、残念ながら今年はコロナということでオンサイト開催は行わず、オンラインで開催されます。オンラインのZoomなどのアカウントに関しては、スクラムフェス大阪が支援しています。

 

お寄せいただきました見本誌・寄贈本を公開します

XP祭りでは例年、出版者さまや有志のご協力のもと、見本誌や寄贈本をいただきまして、当日陳列しております。新しいかたが、自分にあった様々な良書に出会うチャンスになっているのではないかと思います。

日本のアジャイル英語圏に比べるとやはり翻訳書によって知識がいきわたっている面が大きいと思いますので、この活動が20年近く続いているのはすばらしいことだと思います。ありがとうございます。

昨年のリストはこちらです。今年もいずれ本編にマージしたいです。
http://xpjug.com/xp2019-sponsor-presentation/#more-4736

 

f:id:wayaguchi:20200909161656j:image

Python2年生 データ分析のしくみ 体験してわかる! 会話でまなべる!

Python2年生 データ分析のしくみ 体験してわかる! 会話でまなべる!

  • 作者:森 巧尚
  • 発売日: 2020/08/21
  • メディア: 単行本(ソフトカバー)
 

f:id:wayaguchi:20200904100314j:image

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

  • 作者:Henrik Kniberg
  • 発売日: 2013/10/26
  • メディア: 単行本(ソフトカバー)
 

f:id:wayaguchi:20200904100236j:image

実践 反復型ソフトウェア開発

実践 反復型ソフトウェア開発

  • 作者:津田 義史
  • 発売日: 2012/12/01
  • メディア: 単行本(ソフトカバー)
 
テスト駆動開発

テスト駆動開発

 

f:id:wayaguchi:20200904100231j:image

Gitによるバージョン管理

Gitによるバージョン管理

 
プログラミングElixir

プログラミングElixir

  • 作者:Dave Thomas
  • 発売日: 2016/08/19
  • メディア: 単行本(ソフトカバー)
 

f:id:wayaguchi:20200903122813j:image

 

f:id:wayaguchi:20200903122751j:image

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

 
プログラマーのためのVisual Studio Codeの教科書

プログラマーのためのVisual Studio Codeの教科書

 

 

f:id:wayaguchi:20200903122746j:image

 

f:id:wayaguchi:20200831112130j:image

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

  • 作者:Matt LeMay
  • 発売日: 2020/03/19
  • メディア: 単行本(ソフトカバー)
 
Effective Python 第2版 ―Pythonプログラムを改良する90項目

Effective Python 第2版 ―Pythonプログラムを改良する90項目

  • 作者:Brett Slatkin
  • 発売日: 2020/07/16
  • メディア: 単行本(ソフトカバー)
 

f:id:wayaguchi:20200825165617j:image

 

リモートモブプロの原則

コロナ前からですが、リモートでモブ作業をすることがすっかり当たり前になりました。会議を含むリモート作業がうまくいくための条件はいくつか思い当たるのですが、こちらのサイトでシンプルにまとまっていたので、紹介したいと思います。

f:id:wayaguchi:20200511090557j:plain

Remote Mob Programming | How we do Remote Mob Programming.

 

紹介されている原則は以下の15個です。

  1. Remote Everybody (全員リモート)

  2. Camera Always On (カメラは常時オン)

  3. Regular On-Site Meetings (定期的に対面で会う)

  4. Small Team (小さなチーム)

  5. Same Time (同じ時間)

  6. Typist and the Rest of the Mob (一人は入力者、残りはモブ)

  7. Screen Sharing (画面共有)

  8. 10 Minute Intervals (10分インターバル)

  9. Git Handover (Gitで引き継ぐ)

  10. Group Decisions (グループで決定)

  11. Constant Momentum (常に前進する)

  12. Learn from the Team (チームでお互いに学ぶ)

  13. Trust (信頼)

  14. Save the Planet (地球環境に優しい)

  15. Dine with your Family (家族と夕食を)

とにかく信頼が大事で、他のメンバーがどんな人かがわかっていれば、結構気にならないことが多いです(3と13)。そのためにはチームが小さいことも重要で、見えない人がいるとちょっと気になりだします。特に時間が迫って焦っているようなときはひどくなりがち(5)。人数が多いとファシリテーションも必要になってしまいますしね。「均等に、順番に話す」みたいなファシリテーションをしてしまうと、話しているんだけど、チーム全体の成果に向かって進んでいるのかがわからなくなることがよくある気がします。

進め方については、常に成果物を中心において(8)、一人が代表して入力し、コンピュータの延長の拡張入力装置(Hunter)のように、基本的にはモブからガイドしてもらって進みます(7)。全員がサポートしたり、意思決定します(11)。入力者は定期的に交代します(9)。

家から移動しないので地球環境に優しく(15)、移動時間もないので家族と夕食を取るのもやりやすい(16)といったあたりもリモートの大きなポイントですね。

 

やっている人にとってはほぼ説明不要で、共感することばかりだと思います。

 

以上、リモート作業をうまくやるシンプルなルールとして、"Remote Mob Programming"のサイトを紹介しました。

アジャイルテストの世界 - Agile Testing Condensed と実例マッピング

リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。

leanpub.com

アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

アジャイルテストは、アジャイルソフトウェア開発の原則に従ったソフトウェアテストの実践です。アジャイルテストは、顧客が望むビジネス価値を頻繁に提供することを確実にするために、テスターが提供する特別な専門知識を含め、職能横断的なアジャイルチームのすべてのメンバーが関与し、持続的なペースで作業します。例示による仕様(Specification by Example)は、望ましい動作と望ましくない動作の例を捕捉し、コーディングのガイドとするために使用されます。

Agile testing - Wikipedia

ジャネットとリサの本は最初が2009年です。これは同年のうちに当時IBMの榊原さん監訳で、IBMのQAの人たちが翻訳されたと聞いています。

 日本語訳はこちら。

で、この本の白眉は第5部です。

これは出版後しばらくして、私が個人的にジャネットを知り合って、読書会に参加するようになって知りました。世の中で受け入れられていたのは第4部以前の部分。テスト自動化の方法の分類や、アジャイルテスティング四象限の話でした。

第5部はストーリー仕立てになっていて、どのようにPOと開発者とテスト技術者がイテレーション(反復)を回していくかという部分で、実際にインデックスカードがバンバンでてきて、どのタイミングでどういった粒度で話し合うのかが克明に表現されていました。(ちょっと訳は難しかったようで、ちょいちょい誤訳を見つけましたので正誤表を翔泳社さんに載せていただきました。)

実はこの本のジャネットと、アジャイルサムライのジョナサンにはカナダで深い関わりがあり、双方の本に名前が出てきます。XP/TDDのコーチであったジョナサンがプロジェクトに呼ばれたときに、POがジャネットで、ジャネットはQA出身でした。そこで、ジョナサンがジャネットに言ったのが「XPでやるからQAいらないよ」。いやそんなことはないはず、というジャネットの思いから(リサと一緒に)アジャイルテスティングコミュニティが生まれ、アジャイルテスティングの本につながっていきます。 

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

  • 作者:Jonathan Rasmusson
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
 

その後、ジョナサンはSpotifyで初期はアジャイルコーチ、そのあとエンジニアとして働くことになるのですが、その間にWebでのテストについての入門書を書いています。

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

  • 作者:Jonathan Rasmusson
  • 発売日: 2017/09/21
  • メディア: 単行本(ソフトカバー)
 

 

ジャネット来日に合わせてトークショーも行いました。 

codezine.jp

その後、続編である More Agile Testing が出版されました。BDDや Specification by Exampleなど、さまざまな技法がコミュニティでは開発されてきたので、そのあたりをフォローアップした本になっています。この本はまた読書会で読み進めています。 

で、2冊となると重いので、名刺代わりに配るにはちょっとかさばる。ということで、薄い本を作った、というのが最初に触れた Agile Testing Condenced です。薄いからといって網羅性は落ちてなくて、むしろ具体的なところは別の資料であたるわ、っていう人には必要十分かもしれません。

 

この本の中で言及されているのですが、BDDの人たちがやっている、カードを使ってテストを洗い出す技法が Example Mapping です。これも風間さんが訳してくれてますので、こちらをご覧ください。この記事のレビューもお手伝いしております。

nihonbuson.hatenadiary.jp

 

商業的なソフトウェアではもちろんテストが重要です。価値に直結します。ですので、こうした議論を適切にアップデートしていく必要があると思います。....頑張りましょう。

DevOpsDays Tokyo 2020 中止の経緯

DevOpsDays Tokyo 2020 は実施・オンライン配信・延期・中止を検討の結果、中止ということになりました。関係する皆様、ご支援いただいている企業様には大変ご迷惑をおかけしまして恐縮ですが、何卒ご理解をいただきまして、今後も引き続きご支援いただければ幸いです。

www.devopsdaystokyo.org

 

実行委員会での議論はどのように進んだか?

実行委員会での議論の経緯は以下のような感じでした。

 

まず中止の場合のコストを検討しました。会場費、キャンセルできない渡航費、通訳、あたりはかかってしまうけど、返金はしたいので前年からの繰越金を手当てしても、資金不足になることはほぼ確定しました。しかし、今後関係者に支援をお願いする可能性がありますが、なんとかなりそうという感触を得ました(ここ大事)。

海外スピーカーのほとんどは来日してくれる姿勢でしたので、そのまま開催する案を検討しました。ギリギリまで開催する方向で動いて、1-2週前に最終判断する案です。オンライン配信も準備して最悪無観客開催する案です。ありがたいことにオンライン配信のサポートをご提案もいただきました。この案は一見凄くいいのですが、スタッフの作業と判断の負荷が高いのが問題という話になりました。皆さんボランティアですし本業もあります。本業もカンファレンスも今後どういった対応が迫られるか不明な状態で続けるのはしんどい。また、パーティや懇親会は実施が難しいとなると交流できないのがつらい。「交流できないならやる意味がない」という委員もいて、そうだよねー、と思いました。

そのあと3ヶ月延期案が出ました。ちょうど同じ会場を使わせてもらえる可能性があったためです。これはよいのではないかということで、海外スピーカーがどう考えるかは保留として散会しました。その後、やはり海外スピーカーは旅程の組み直しなので難しいだろうという意見が出ました。

これまでの議論を踏まえて、仕切り直して来年に向けて頑張りましょう、と決まりました。

 

以上が決定に至る議論のおおよその経緯です。今後の安定したカンファレンス開催に活かせればと考えております。こういうことも検討したほうが良かったのではないか、などのご意見いただければ幸いです。

 

(2020/3/9 追記) 会場オーナーの品川区の決定で予約金が全額返金に

大崎ブライトコアホールのオーナーである品川区が今回のコロナウイルスの影響でキャンセルとなった場合の対応として、払い込んだ予約金が全額返金となりました。DevOpsDays Tokyoは、一ヶ月以上前に支払っている費用のほとんどが「会場の予約金」ですので、大変ありがたいことです。

協議の結果、2/20-5/31の期間でご利用予定だったお客様の

新型コロナウイルスの影響によるキャンセルの場合に対して

ご予約金を全額返金」の対応が決まりました。

来年もぜひ大崎ブライトコアホールで行いたいと考えております。ビバ品川区。