祭り(Regional SCRUM Gathering Tokyo 2024) チケット購入

気がついたら9月の中程を過ぎていた・・・

そう、RSGT2024の9月チケットの発売日を逃したのだ。気を取り直してカレンダーを確認する。幸い、10月1日は日曜だった。チケット申し込みに休暇を取る必要はない。

10月1日

12時前にPC前にスタンバイ。RSGTの公式ホームページを開く。チケットは未だ発売されていない。12時を過ぎてF5アタックを繰り返しチケット購入サイトへ飛ぶ。
チケット残数は数十枚ある。余裕を持って購入枚数を入力。アンケートへの回答も普通に入力。購入ボタンをクリック。

「購入枚数を入力してください。」とエラーが発生する。

「ん?入力したぞ・・・」

確認すると確かに入力されていない。再入力して再度購入ボタンをクリック。

「あれ?動かない・・・」

よく見ると、unavalableの表示・・・
そう、10月のチケット購入に失敗したのだ。売り切れるのが早すぎである。確かにコロナ直前は激戦だった。しかし、コロナを経てオンラインチケットも販売され、その視聴環境もかなりいい。去年は余裕があった。

想定以上にみんなオンサイトで参加したいらしい。自分もその一人なので気持ちは分かる。だが、しかしだ。早すぎる・・・

仕方がないので、11月に万全を期すことにする。

10月某日

業務上セキュリティが非常に厳しく、許可されていない社外サイトも多い。何より昼休み中はアクセスが集中して重い。そんな高リスクの中、チケット購入にチャレンジする勇気はない。これを逃すとオンサイトでの参加はないのだ。

「11月1日に休暇を取りまーす。」

幸いにも休暇はかなり取りやすい。

「え?休暇申請結構出てるよね?」

上司から休暇取りすぎじゃねオーラが出てる。気が付かないふりをして

「10月中の2回は親の通院の付き添いなので家事都合です。これはRSGTのチケット購入なので自己都合です。」良く分からない説明で押し切る。休暇ゲット。

11月1日

10月と同様に12時前からスタンバイ。12時を過ぎても公式サイトの販売状態がSOONから変わらない。何かおかしい。eventbriteのサイトへアクセス。

オープンしてたorz

幸い残数がある。慌てて手続き開始。10月の経験を踏まえ、速攻でアンケートに回答。購入。paypalでの決算完了!

オンサイトでの参加が確定した瞬間であった。

 

Day1へ続く

祭り(Regional SCRUM Gathering Tokyo 2024) Day1

準備

スマホ内にチケットが保存されていることを確認する。念のため、Eventbriteアプリとウォレットの両方。どちらも問題ない。Discodeを開き、receptionチャンネルから登録を済ませる。

「RSGT2024-attendeesのロールをつけました!」

準備完了。

Day0

忙しくはないが、流石に仕事がある。いくらオンラインでも参加は難しい。諦める・・・orz

Day1

移動を伴うDay1の朝は早い。田舎住みの辛いところで4時半起きである。準備を済ませいざ出発!
無事東京着。先ずはホテルへ向かい、荷物を預かってもらいつつ、ついでにチェックインも済ませる。

「何時頃戻られますか?」

難しい質問である。飲むメンツと勢いによる分かるわけがない。適当に

「分かりません。遅くなると思います。」

とだけ伝え、歩いて会場に向かう。

8時半頃に会場到着。少し早いかと思いつつビルの外から様子を伺う。問題なさそうなのでそのままGO!

エスカレータの下では、いつもの様にスタッフの永瀬さんが笑顔で元気に迎えてくれる。帰ってきたと実感する瞬間である。こんな気持になるカンファレンスは他にない。(自分調べ)本当に良い。高揚した気持ちでエスカレータを上がると知った顔のスタッフが迎えてくれる。みんなワクワクした顔をしている。受付を済ませて名札を準備。メイン会場は同時通訳が無い。躊躇わずに隣の同時通訳有りの会場に行く。

流石に未だ誰も居ない。席を確保後ホワイエに戻る。

他のカンファレンスと異なり席に座ったまま開始時間を待つ参加者は少ない。いろいろな所でワイワイしている。年に数回、若しくはRSGTでしか合わないのに時間を超えていつも会っているかのごとく楽しそうに。そんな雰囲気を作り出すのがスタッフと参加者全員。これもこのギャザリングの魅力の一つである。いろいろな人と挨拶したり、おしゃべりをしたりしているうちに開始時間。

スタッフのWelcome Noteが相変わらずゆるい(笑)必要な注意事項は伝わっているが、ゆるい。そんなWelcome Noteが終わるとプラチナスポンサーのスポンサートーク。いつもの寸劇。初めての参加者の何人が社長自らノリノリで寸劇に参加していると分かったかは不明であるが、いい会社であることは伝わっていると思う。いきいきしている社長の会社が悪いわけがない。

キーノートが終わると昼食。お弁当の時間である。このお弁当が美味しい。

午後からは、5トラックに分かれてのセッション。

confengine.com

例年は17時頃に終了だが今年はエクストラセッションがあって18時15分終了。Day1はこれで終了。

だが、しかし。エクストラセッションに参加せずおじさん4人で中華屋へ移動。本番の始まりである。セッション内容について議論したり、ただただ喋ったり。偶々、製造業に関わるおじさんが二人揃ったので、

ジョーが語る、Teslaでの衝撃的な開発スピード

について、

「認証取るのがね~」

「製造プロセスだけでなく、部品が変わってしまうとね〜」

「シミュレーション結果だけで認証取れるのは良いよね〜」とは

盛り上がってた。

 

Day2へ続く

 

 

祭り(Regional SCRUM Gathering Tokyo 2024) Day2

Day2

名札を首から掛け、Aftershokzを装着。これで会場に入れるし、オンラインの音声を聞きながら会話も可能。モバイルバッテリーはポケットへ。荷物になるようなカバンは持たず、手ぶらで出発。完璧である。

 

想定通り早い時間に会場到着。Day2が始まる。

著とした高揚感と冒険心が同通なしの会場に足を向かわせる。席も取った、前日のセッションで気になったことと自分の考えていることを答え合わせをするため、セッションスピーカを捕まえて意見を聞く。セッションスピーカも参加者である。セッション終了後にはいさようならではない。全力で3日間を楽しんでいる。そんな渾然一体となったこのギャザリングは実に有意義な時間を作り出してくれる。

キーノートが始まる。

途中でギブアップ!多少は聞き取れるかもと期待していた自分を叱ってやりたい。過大評価し過ぎである。だが、しかし。オンライン参加可能なデバイスが手元にある。ヘッドセットも装着済み。周りに音が漏れる心配もない。早速ZOOMにログイン。日本語が聞こえてくる。幸せを噛み締めた瞬間であった。セッション終了後、スピーカのMichael Feathersさんの著書「レガシーコード改善ガイド」の即売会&サイン会が行われた。既に持っているがサインの魅力には勝てず、購入。サインゲットだぜ!

 

 

お弁当は今半のすき焼き弁当をチョイス。冷えているにも拘わらず肉が柔らかい、油も浮いていない。タレを掛けて半熟卵を絡めて口に運ぶ。チョーうまい!来年も食べること決定である。

 

Day1と同様、午後からは5トラック並列でセッション。17時終了。

Regional Scrum Gathering Tokyo 2024 - Program Schedule

数人で本番会場(近くのお店)へ移動開始。ふと階段を見ると知った顔が。しかし、様子が可怪しい。階段の最上段を残してそれ以上上がってこない、それに昼は顔を見ていない。
そう、近くのホテルからオンライン参加して終了後に飲みに行くために会場に来たとのこと。参加規約に則り、会場(最上段の階段)には入らず知り合いの出待ちをしていたらしい。(自分もオンサイトチケットが取れなかったら同じことをしていた)そんな愉快な仲間達を巻き込んで改めて移動開始。2時間毎に店点々としつつ結局1時過ぎまでワイワイ。そんな時間が楽しい。

 

Day3へ続く

 

祭り(Regional SCRUM Gathering Tokyo 2024) Day3

Day3

 

前日までの決まったセッションとは打って変わって、午前中の内容はワークショップ以外は未定。それもそのはず、午前中はOST(Open Spece Techonology)。

speakerdeck.com

 

内容は、参加者次第。
開始時刻が近づく。今までと何か違う・・・

「!!」
「参加者が多い!」

例年であれば、前日の遅い時刻まで掛かる熱い議論(飲み会とも言うが・・・)のため、OSTの開始時点での人数は減っている。しかし、今年はそれがなかった。

OSTの説明が終わり、テーマだしになった途端人が殺到。マーケットプレイスも大事に。

「皆んな楽しみすぎじゃね」

と思いつつセッション開始を待つ。
例年であれば、気になるセッションに後から行っても議論に参加できることが多かったが、今年はどこのセッションも一杯。早々に諦めた。

ホワイエで喋っていたら、配信設備ツアーが近くを通ったので途中参加を決め込む。これは良かった。

 

Day3の昼は、サンドイッチ

午後のクロージングキーノとは、みんな大好き狩野モデルの狩野先生。
狩野モデルが有名すぎて、どこか遠くに感じてモデルの提唱者がご存命だと思っていなかった、(狩野先生、本当にごめんなさい)

盛況のうちに予定時刻で終了。

最後は、参加者で記念撮影と撤収。

 

15時から開いている店がなかなか見つからず難民と化すが近くで17時までならばOKの店を発見。17時以降なら他の店が開き出すのでむしろ好都合。
店が変わる度にメンバの分裂と結合が繰り返され色々な人と話ができるのも醍醐味の一つ。

なんやかんやで3時頃まで飲み歩き、ホテルに帰って、本当に終了。

 

感想

初めて参加したのが2013年なので、全てに参加できたわけでは無いし、スピーカをしたことがあるわけでは無いけどもう10年以上関わっているらしい。それだけの年月を経て状況が変わったな〜と思うことをつらつらと

  • 最初は、製造業の参加者は殆んど居ない状態。(知っているのは自分の他に1人だけ)
    今では、普通に居るし、セッションもある。
  • QAの関係者も居なかった。
  • 規模は言うまでも無く。
  • 規模とは別に、年々参加者の幅が広がっている。エンジニアだけでなく、学生も居る。近年では聴覚障がいを持つ参加者も居る。今年は、手話通訳さんも居た。こんなに色々な人が関わることができるコミュニティに居られることに感謝。

 

さいごに

スタッフの皆さん

今年も、素晴らしい場を提供してくれてありがとうございます。

参加者の皆さん

楽しいひと時を一緒に過ごしてくれてありがとう。定年を間近に控えてもなお、エンジニアで居られるのは皆さんのおかげです。また、来年一緒にワイワイしましょう。

 

なお、エンジニアを辞めるわけでは有りません。

JaSSTソフトウェアテストシンポジウム - JaSST'22 Tokyoに参加しました

3月10日(木)、11日(金)に開催されたJaSSTソフトウェアテストシンポジウム-JaSST'22 Tokyoに初めて参加しました。

コロナの影響もあり、全セッションオンラインでした。

スピーカーの皆さん、スタッフの皆さんお疲れ様でした。

いつも参加するギャザリングや祭りと異なり「シンポジウム」なだけあって、論文の表彰があったのは非常に新鮮でした。また、ソフトウェアテストシンポジウムなだけあって、QAの担当者が中心でそれも新鮮でした。

 

弊社もそうですが、SCRUM等に従ったソフトウェア開発でQAとして如何に関わって行くかに皆さん苦労されていると感じました。

ここからは個人的な意見ですが、

QA視点で設計に対するフィードバックが欲しい

開発者はテストファーストによりユニットテストレベルでのテスを実施し、必要であればリファクタリングによりテスタビリティを改善します。(する筈です)

QAを含めたテスト担当者は、テストに関する専門知識を活かし効率的且つ効果的なテストを実施し、問題があれば開発者にフィードバックし開発者はプログラムを修正します。

開発者もテスト担当者もそれぞれの視点からテストを実施し、ソフトウェアの品質を上げていいています。

ここまでが僕の知っているソフトウェア開発のコーティング以降の状況です。

個人的にはこの状況は料理ができた後に味見をして問題があれば調味料を足すなどして味を整えているのと同じなのでは?と感じています。最後に味見をしたところで調理方法が正しくなければそこそこの味の料理しかできないのと同じで、設計が正しくなければ(視点が不足していれば)変更しにくい、技術的負債が溜まったままのそこそこ品質のソフトウェアしかできないと思います。

なので、テスト担当者には問題を見つけた場合に、開発者に対し問題を指摘するだけでなく、設計の意図を確認したり、不足している視点をを指摘したりするフィードバックをしてもらえれば次のスプリントやプロジェクトでの品質向上が期待できると思っています。

テスト担当者はテストに関する知識の習得だけでなくソフトウェア設計に関する知識の習得も必要となるので負担が増えるとは思いますが、設計段階からテストを見据えた開発ができるようになれば負担増も軽減されるのではないかと思っています。

QA担当者は、品質を担保する上での最後の砦なので頑張ってもらえたらと思います。

 

Regional SCRUM Gathering Tokyo (RSGT) 2020に参加してきました。(Day 1)

Regional SCRUM Gathering Tokyo (RSGT) 2020に参加してきました。

2020.scrumgatheringtokyo.org

スピーカーのみなさんお疲れさまでした。そして何より今年も楽しく素晴らしいギャザリングの場を提供してくれたボランティアを含めたスタッフの皆さんありがとうございました。あなた達のおかげで今年もまた楽しい3日間を過ごすことができました。

長くなったので分けて書きます。

以下が参加レポートになります。

 

Befor the event

11月にチケットが発売されるのを待って早速購入。と思っていたら出張のバタバタで30分後に確認したら既に売り切れ。ショックでしばしボーゼン。12月の発売日に気を取り直して再チャレンジ。12時前から準備してなんとかゲット。

 

Day1

Welcome Note

グローバルスポンサーKDDI 佐野さんの時間。相変わらずラグビー愛に溢れる話。スクラムを制するものが試合を制する。 スクラム頑張っていこう。

 

Keynote "The Ten Bulls of the Scrum Patterns" by James "Cope" Coplien

十牛図との対比によるスクラム追求の話。迷ったら「Why」を求める。

 

Lanch

危うくぼっち飯になりそうなところをなんとか回避。メニューは、普通のお弁当だけでなくグルテンフリー等、参加者に配慮したメニューがあってスタッフのホスピタリティを感じる品揃え。

 

アジャイルコーチ活用術 by Ryutaro Yoshiba (Ryuzee)

職種柄、なかなか外部からコーチを雇うわけにもいかず、チームの成長を促すには少なくとも最初は誰かがコーチをして助けてあげる必要があると思って聞いたセッション。

冒頭、シャッター音は出さない様にと注意が、小さな規則が守れないチームはきちんとした成果が出せないと。割れ窓理論じゃないけど、小さな規則が守れないとそこから段々なあなあになってしまって気づいたときには手遅れになりかねない。

僕自身もシャッター音は気になるので、Microsoft Pixカメラを使っている。シャッター音を消せるだけでなく、スライドの補正もしてくれるのでオススメ。

www.microsoft.com

 

コーチとチームは、相互コニュニケーションを持って適切にナレッジトランスファーを実現する必要がある。

コーチは、コーチングだけでなくチーチングも合わせて実施する必要があるがそれらのバランスが大切。

チームは、コーチに対して「期待値を設定する」事が重要。コーチに依頼するだけで魔法の様に自分達が欲しいことを教えてくれる訳ではない。優先順位を付けて明確にコーチングして欲しいことを伝える。コーチングの期間はケチってはだめ、3ヶ月は必要。すると変化が見えてくる。とはいえ、フルタイムでコーチに入ってもらう必要はない。週1〜2回位でOK。

チームは自分達でやるべきことはやる。チームがやるべきことを依頼するのはコーチングの依頼ではない。成果物を作る責任はあくまでもチームにある。コーチはチームが自分達で走れるようになるまでのサポート役。

f:id:yo4-furukawa:20200113175247j:plain

 

 

みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか? by Yoh Nakamura

OutcomeとOutput似たような概念でいまいちわかって無かったので参加した。簡単に言うと。

Outcome : ビジネス成果や人の行動が変わる成果

Output :機能

らしい。普段System of Systemsの一部を作っているとビジネス成果と言われてもいまいちピンとこないが、人の行動が変わる成果と言われるとなんとなく分かった気がする。何れにしても、Scrumチーム全員でPBIをリファインメントする事が重要。

 

f:id:yo4-furukawa:20200113175503j:plain

みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか_グラレコ

 

モブプログラミング × 行動分析学 × 教育 by Takuo Doi

教育の場に行動分析学を持ち込み、生徒が宿題をやって来るようにしているとのこと。行動分析学自体をよく分かっていなかったが、チーム行動の動機付けに使うと面白そう。

f:id:yo4-furukawa:20200113175650j:plain

モブプロ×行動分析学×教育_グラレコ

 

特殊部隊SETチームの日常 −技術と実験を融合した実践アジャイル術− by 伊藤 宏幸、高橋 勲

LINEのSET (Software Engineer in Test)は、自社内にある他チームのサポートや社内ツールの開発・運用だけでなく組織を超えた課題発見と解決や技術戦略の策定・実施まで行っている。

技術の進歩が早い今、開発チームだけで改善やら将来を見据えた技術戦略の策定までをカバーするのは困難なのでこの様な専門チームがあるのは正直羨ましい。羨ましがっていても仕方がないので、立ち上げを企ててみるか。

 

f:id:yo4-furukawa:20200113180034j:plain

特殊部隊SETチームの日常_グラレコその1

f:id:yo4-furukawa:20200113180126j:plain

特殊部隊SETチームの日常_グラレコその2

 

A Scrum Bookの歩き方 by Harada Kiro

書籍「A Scrum Book」をどの様に読み進めたら良いかだけでなく(というか、こっちが少ないw)Copeを交え

、キーノートに対する質問を受け付ける等多彩な内容のセッション。それにしても一人で英語を喋ったり日本語を喋ったりと兎に角多才。それにしても A Scrum Bookは鈍器で英語版なので何かとハードルが高いw

 

Networking Party

例年の如く、Day 1最後を締めるのはネットワーキングパーティー。1年ぶりに合う人、初めての人、ちょくちょく合う人、いろいろな人が居るけどそんな事は関係なく気軽に話せるのがこのコミュニティーの良いところだと思う。また、パックマンルールもコミニュケーションを促進する良いルールだと思う。

 

After Networking Party

ネットワーキングパーティーが終われば1日が終わりではなく、次の店に移動。ここでは、その日気になったことを話してもよし、全然関係のないことを話してもよし。参加者としてはここが本番な気がする。

 

 

Modering Forum 2019に行ってきました

11月28日(金)に開催されたUMTP主催のModeling Forum 2019に行ってきました。

今年のテーマは「新時代のモデリング視点を求めて」と題し、「DX、AI、IoT、Society 5.0、アジャイル開発、マイクロサービスなど、新しい時代におけるモデリングの最新情報に触れていただく機会を提供いたします。」という事で開催されました。

午前中は、基調講演が2講演、午後は講演とワークショップの2トラック構成です。自身、UMTPのモデリング実践部会に関わらせていただいていることもあり、モデリングのワークショップのお手伝いを少々してきました。

全体的にはスーツ率と参加者の年齢層が高いフォーラムですが、内容も開発寄りではなくどちらかと言うと上位層向けといった感じ。

以下、セッション概要等です。

  • 基調講演Ⅰ 「DXレポート作成の背景と政策展開」

    〜データとデジタル技術の重要性をドメインモデルの観点から〜

    経済産業省 商務情報政策局 情報産業課 ソフトウェア産業戦略企画官 和泉憲明 氏

    • 経産省にお勤めの方とは思えない面白い内容。とはいえ、そこは経産省、1企業の視点ではなく国全体を見ていて刺激が多い。

    • 平成30年9月に出されたDXレポートに書かれている「2025年の崖」とか超ヤバそうw

    • DXは既に始まっていて、AI/IoTは使える時代から消える(小さく気づかない)時代へ移りAIプラットフォームは当たり前の時代になっていく

    • 欧米と比較し、要素技術は日本が上だが、違いはビジネスの考え方 フランスの自動運転地下鉄やスループットを最大化することを考えたAmazon Go等、新しいビジネスが沢山、それに対し日本は・・・慎重というか丁寧というか・・・

       

  • 基調講演Ⅱ 「AI x 量子コンピュータ時代のモデリング

    株式会社グルーヴノーツ 代表取締役社長 最首英裕 氏

    • AIは対象をベクトル化する数理モデルであり、ベクトル化すると計算できるようになる。

    • AIで大切なのはデータ量ではなく、「何を特徴ベクトルとするのか」であり、現場感が大切。

    • AIを実装することはできる。それより大切なものが何にどうやって適用するか。

    • 特徴ベクトルに合ったネットワークモデルを選択する。

    • 計算量の多いAIには、量子コンピュータを活用。

    • 量子コンピュータは既に実用段階にある。

    • 量子コンピュータは、プログラミングするのではなく、「数式」を入力するイメージ。

     

     

  • ETロボコンにおけるモデリングとその評価方法」

    ETロボコンモデリングはどう変わってきたか〜

    ETロボコン本部審査委員長  富士ゼロックス株式会社SOL 基盤開発統括グループ 開発5G グループ長 土樋祐希 氏

    • ETロボコンとは、組み込みシステム技術協会(JASA)主催のソフトウェアコンテスト。

    • ソフトウェアの性能と設計を競う二つの審査。

    • 当初はモデルの利用促進が主な目的。そこから、順に設計品質向上に向けて進化。

    • 前年のモデルとその評価が公開されておりそれがモデルの進化を後押し。

    • 近年では、モデリングパターンが固定化してきており、競技・審査内容を大幅に変更し、新しいモデリング課題を提供。

    • 2019年(今年)のETロボコンの課題としてAI/IoTの要素を導入。

    組み込みのエンジニアとはいえ、AIやクラウドと無縁ではいられなくなってきている事がETロボコンだけを見ても分かるようになってきている。ますます、ソフトウェアエンジニアが覚えることが増えていくな〜

 

  • 「Society 5.0の実現に向けてのSystem of Systemsエンジニアリング」

    慶應義塾大学大学院 システムデザイン・マネジメント研究科 研究科委員長・教授 西村秀和 氏

    • システムズエンジニアリングとは、システムを成功裏に実現するための複数の分野に跨がるアプローチおよび手段。

    • ISO 15288が改定され、いくつかのプロセスが追加された。

    • アーキテクチャは、システム要素とその関係性の中で具体化された、ある環境中のシステムの基本概念または特性であり、またシステムを設計し進化させるその原則

    • システムアーキテクチャの決定には、さまざまな観点からの検討が必要

    • マネジメントのの考え方は、Wave Modelとして表される。

    • 利害関係者毎に適切なビューポイントを設定し、抽象度をコントロールする。

    弊社にとってど真ん中の話題。SysMLでシステム設計してUMLでソフトウェア設計する。一番の課題は、皆がそれなりにモデルを読み書きできるようにすること。SysMLでも一部のダイアグラムなら導入は比較的簡単なんだけど・・・パラメトリック図とか内部ブロック図とか今までの設計方法では全く使ったことがなかったり、違う表記方を使っていたりすると途端に導入できなくなる。

    あと、Wave Modelのアーキテクチャ構築と更新の実装からSystem of Systemsの継続的分析に如何に早くフィードバックするかかな。

 

  • 「UMTPモデリングワークショップ」

    株式会社オージス総研 ビジネスイノベーションセンター 原田巌 氏

    メインスピーカーは原田さん。自分は参加者の皆さんの手が止まった時のサポート役。

 

  • おまけ(その1)

    昼を原田さんと食べたんだけど、その時に「一度作った検証用モデルを如何に捨てるか」で話が盛り上がった。

    • 作ってから時間が立つほど愛着が湧いたりもったいない気がしてきて捨てられない

    • モデルはどうしても最終成果物のイメージがあるので捨てづらい

    • 作り直しても最初のモデルのイメージに引っ張られて同じ様なモデルになっちゃう

      とか

      結論ぽいものとしては以下

      • 検証用モデルは最初から捨てるつもりで描く

      • すぐ実装して良し悪しのフィードバックまでの時間を短くする