大人のソフトウェアテスト雑談会 #231【走れ】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

気合をいれるコーチング

普通に英語は喋れるんだけれども英語でがっつりディスカッションをするのがきついといった状況でコーチングをするときに有効な方法として、相手が話した分からない言葉や発言がどういう意味なのかをとにかく聞いていくという手法があるという話を聞きました。

テクニック的にも難しいところはあるものの、何よりも気合が必要だということです。

海外ミーティング

海外の人とミーティングする際に、どの国も非ネイティブの方と話をするときは辛い(もちろん日本人が英語を話すときも)という話を聞きました。

一部の語彙や文法がそもそも英語でもないうえに早口でなまりが強いシンガポール英語や、末尾を消してしまうベトナム英語など、色々つらい英語の話をしていきました。

アメリカ大統領になるためには？

おおひらさんを名誉会長に立てて葛飾党でアメリカ大統領戦に立候補するためにはどのような手段があるのか？という話をしていきました。

ハードルは想像以上に高そうですが、海兵隊になってしまうのがいいんじゃないか？という話や、

www.yomiuri.co.jp

americancenterjapan.com

オンライン区長

アメリカでも区長がオンライン州知事と名乗ればいいのではないかという話から、オンライン区長のことを知らない人はオンライン区長と会うと本当の葛飾区長だと勘違いされてしまいがちで混乱を巻き起こすという話をしていきました。

都内自治体

葛飾区の区長は自治体をやっていると普通に来るそうで、地域密着型の古き良き地方都市感があふれる自治体になっているという話がありました。

渋谷アジャイル

shibuyagile.connpass.com

アジャイルなんもわからん枠で申し込みしたいものの今の参加者を見ると申し込みずらいという話が出ていました。

スタートアップの定義が知りたいという話やこばせさんにどいてもらえばいいんじゃないか？という話をしました。

全体を通した感想

書くか悩んだあげく書きませんでしたが平鍋さんのkeynoteを製造業でずっとやってきた人が聞いた立場での感想を聞けたり、最初はいつもどおりゆるい話をしているなかでどんどん濃い話が出てくるタイミングを味わえる濃密な会でした。

Frontendのテスト全部知る 〜Unit TestからE2Eまで〜 - Encraft #18に参加してきた

knowledgework.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

フロントエンドのテスト、書いてますか？

何を目的にテストを書くのか、どこまで書いたらいいのか、どう書くのがいいのかなどなど、フロントエンドのテストに関する悩みは色々とあるかと思います。

今回はフロントエンドのリアーキテクト文脈でのテストの話や、デグレを起こさないためのテストといった観点に焦点を当てながら、Unit TestからE2Eテストまで、広い範囲でお話しします。

会の様子

コンポーネントのテストとして採れそうな手法と、その効果を考える

最初にnus3さんからコンポーネントテストの話がありました。

Vitest, Playwright, Storybook, WebdriverIO, Cypress, Safetestを使用してそれぞれのライブラリでテストを書いてみたそうで、それぞれの特徴の説明がありました。

• Vitest...設定を切り替えるだけで同じテストを別の動作環境で実行できる
• Playwright...Testing Libraryのような書き方で記法は違えどテストができる
• Storybook...いろいろなテストフレームワークで利用ができる(所感)
• WebdriverIO...Vitestと同じようなイメージ
• Cypress...spyなど独特な記法があるが、基本的には他ライブラリと同じようにテストが書ける
• Safetest...アプリのエントリーポイントでSafetestのbootstrapを呼ぶのが他にはない特徴

次にフレームワークごとのベンチマークの話がありました。*1
計測した結果、以下のようになったそうです。

• Vitest + jsdom...46.31s
• Vitest(Browser Mode) + Playwright...82.84s
• Vitest(Browser Mode) + WebdriverIO...195.73s
• WebdriverIO...65.54s
• Storybook...80.16s
• Safetest...29.2s

次に、この結果を踏まえてどのような違いが考えられるかという話がありました。
まず、コンポーネントがレンダリングされる場所が違うということで、Node.jsで完結するのかは差異として出てくるということです。
また、ブラウザの自動操作をする際のアーキテクチャも違うため、Webdriverに関しては間にDriverがある分一方向通信が必要で実行時間が長くなってしまうということです。(CDPでは実行時間の問題は解決されるもののブラウザがChromiumベースであったり、Cypressではブラウザ上にテストランナーが独自に存在している)
最近では、Webdriver BiDiという新しいプロトコルの仕様策定が進んでいるそうで、CDP/Webdriverのデメリットをそれぞれ解決することも目指されているということです。

最後に、コンポーネントテストの効果に関する考察がありました。
jsdomを使ったコンポーネントテストはNode.jsで完結し導入コストが低いものの、複雑なコンポーネントテストには向いていないという話がありました。また、シンプルなコンポーネントテストだと思っているテストに対して簡単にテストを書けるのか？というのを見定めるために有用なのではないかということです。
また、ブラウザを使ったコンポーネントテストをすると、信頼性が高く複雑なコンポーネントテストの第一の選択肢になると考えているということでした。一方でexperimentalなものも多かったりするのは今後注視していく必要があるそうです。

また、nus3さん個人としてはApp Routerに刷新されたNext.jsがどうコンポーネントテストと関係していくのか気になっているということでした。

上手に付き合うコンポーネントテスト

続いて@Quramyさんから話がありました。

自動テストは開発規模が増えていってもスピードを損なわずに関係を続けていくために重要だと思っているそうです。
コンポーネントテストは運用コストも安くはないので新規PJのときは使わないこともあるそうですが、Storybookで後から導入できるようにしておくことは常にしているということでした。*2

Storybookを使う際には、お金があるならChromaticをまず使うといいのではないかと思っているということで、やはりオフィシャルサービスは強いそうです。
他にもLost PixelやStorycap、Storybook/test-runner、storycap-testrun、Jest/Vitestなどが候補にあるということでした。

運用の際には実行時間をとにかく落とすことが重要だということで、個人的な見解では5-10分くらいが閾値になってくるということです。
実行時間を速くするには、

• 札束で叩いてCIの実行環境をCPU増強して並列実行
• スケールアウト的な発想でGitHub Actionsのmatrixなどで並列ジョブ実行
• ブラウザを使ったテストを削る

をするということでした。

また、Flaky Testが起きないように注意しているということで、100ピクセル程度(0.01%)は差異が起きても妥当と判定したり、コンポーネントの一部が不安定な場合はVRT時のみ別divに差し替えてFlaky Testにならないようにしているそうです。(どうしてもだめならskip)

急拡大するナレッジワークの開発組織を支える E2E テスト基盤

最後に鳥居さんから話がありました。

ナレッジワークではPlaywrightを採用していて、FrontエンジニアとQAエンジニアが共同でテストを実装しているということです。
E2Eテストの役割としては、基本的な機能のデグレードがないことを保証したりモジュール単位のテストでは不安なシステム全体のテストをするようにしているということでした。

続いて、E2Eテストをしているなかで直近直面した課題と解決策に関して話がありました。
まず、同じテナントで同時に複数人同時にテストを実行すると落ちたりしてしまうということです。
そこで、テナントプールを使用して解決を試みているということでした。
次に、認証周りに関して開発環境限定のテスト用APIを使っている関係で本番環境でテストができていないことが挙げられていました。
この問題に対しては、Testing Gatewayを使っているそうです。
最後に、テナントのセットアップ方法がわからないという話が出ていました。ここは地道にリバースエンジニアリングをして手順をドキュメント化したそうです。

会全体を通した感想

コンポーネントテストに関して、実行速度の問題はやはり課題感として大きいんだろうなあと思いながら話を聞いていました。

Unit Test周りの話が具体的にはそこまでなかった気はしたので、もう少し詳しくこのあたりが聞けると良いなあとは思いました。

*1:ただしデフォルトだと並列実行ができないCypressと用意したテストケースの書き方が複雑すぎて分からなかったPlayWrightは除外。また、Storybookのビルドやアプリのサーバー起動が必要だが時間を含められておらず、Vitest(Browser Mode) + WebdriverIOではVitest側からproviderOptionsを使って並列実行の設定を渡せていない

*2:ただし@QuramyさんはStorybookが嫌いで、experimental RSCがRSCでもなんでもないのにGoを出したということに全く信用を置けない

GitHub CI/CD実践ガイド~ Forkwell Library#67に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第67回目では『GitHub CI/CD実践ガイド ――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』を取り上げます。
GitHub Actionsの基本構文から，テスト・静的解析・リリース・コンテナデプロイなどを実際に自動化する方法をハンズオンで学べるこの本。あわせてDependabot・OpenID Connect・継続的なセキュリティ改善・GitHub Appsのような，実運用に欠かせないプラクティスも多数習得できる一冊です。これまでもアンケートでリクエストの多かった本書を今回イベントとして取り扱いします。

会の様子

講演

CI/CDとは？

ソフトウェア開発はソフトウェアを通してユーザーに価値を届けることが目的であり、試行錯誤を繰り返す必要があるため、そこに役立つのがCI/CDだと考えているということでした。

そのうえで、CIはコードの変更を頻繁にコードベースに統合して正しく動作するか繰り返し検証する行為であり、CDはいつでも安全にリリースできる状態を保ちソフトウェアを繰り返し改善する行為であるという定義の説明があり、現場だとCIはCDに包含されることも多いという話がありました。

GItHub ActionsをCI/CDで実践する理由

GItHub ActionsはCI/CDを実践する上で、YAMLをリポジトリに追加すればすぐ動く手軽さが魅力的だという話がありました。
また、YAMLをキャッチアップさえすれば大体書くことができるしPublic Repository上であれば無料で実験がし放題なため、学習コストとしても低いと考えているということでした。
ただし、見様見真似で書きやすく動いたことがゴールになってしまうことも多いため、場当たり的かつ雑に扱われるのは課題だと思っているということです。

書籍の構成

まず一部で使い方を重点的かつ体系的に学習することを目的としているそうで、その上で第二部ではリリースに関する話題や長期運用で重要になってくる話を取り上げているということでした。

最後の第三部は玄人向けに、セキュリティや持続可能性に関する話を取り上げているということです。

GitHub Actionsのコンテキスト

時間の関係もあってコンテキストだけ具体的な機能としての紹介がありました。

データへのアクセスに利用するため利用頻度が高いそうですが、公式ドキュメントも含めてシェルコマンドに直接コンテキストを埋め込んでしまうアンチパターンをよく見かけるそうで、スクリプトインジェクションの脆弱性が発生しがちだという話がありました。

外部から入ってくるユーザー入力値は信頼してはいけないというソフトウェアの原則を考えると、コンテキストはいろいろなプロパティ(ブランチ名やラベル...)を含むため、コードレビューでもほぼ確実に見落とされてしまうということです。

そのため、中間環境変数を使用することが望ましいということで、環境変数を必ずクォートしてほしいという話がありました。

他のグッドプラクティスやアンチパターン

コンテキスト以外にも、グッドプラクティスやアンチパターンは存在するということで、グッドプラクティスの例としては

• タイムアウトの明示的指定
• パイプエラーが拾えるようにデフォルトシェルを記載
• Concurrencyでワークフローを自動キャンセル
• ログをグループ化してログの読みやすさを向上

が挙げられていました。また、アンチパターンの例としては、

• Secretsのログマスク
• パーミッションの省略(過剰な権限付与)

が挙がっていました。
基本機能に関しては、使うのは簡単ですがうまく使うのには時間がかかるため、少し時間をつけて応用力を身につけるための基礎力を本書で身につけてほしいということでした。

持続可能性を高める習慣

ソフトウェアの想定稼働期間中に依存関係・技術・製品要件における変化に反応できるために、依存関係のバージョンアップを習慣とする必要があるということでした。

依存関係のバージョンアップは面倒*1な仕事になるため、Dependabotを利用するのがおすすめだという話がありました。

他にも、クレデンシャルをソースコードへ平文で保存しないようにしたりレビューやCIを必須にしたりリリースで適切なバージョニングやアナウンスを実施したりすることも重要な習慣だということですが、率直に言ってしまえば面倒くさい話なことがおおいため、なるべく既存ソリューションを使うことを大切にしてほしいということです。

意図的脅威に対する防衛

GitHub Actionsはソフトウェアサプライチェーンの中心的存在ではあるものの、攻撃される件数は増加傾向にあり、意図的脅威として第三者が実装したアクションの話が説明としてありました。

具体的な事例としてはCodecovの侵害によってクレデンシャルが流出してしまったりした話があり、アクション提供者を信頼するかは常に意識的に決断しないといけないということです。

とはいえ開発効率の観点を考えるとアクションを一切使わないことは難しいので、0にはできないもののVerified Creatorsを信頼性の目安にするなどといったリスク低減策が重要だという話がありました。

執筆中に心がけたこと

経験をとおして学ぶコトの言語化に注力したのと、最高の読書体験が提供できるようにめちゃくちゃチューニングをしたという話がありました。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

GitHub Actionsの実行時間を短縮するための工夫は？

キャッシュを使う、Larger Runner、テストの並列実行、ジョブの分割...があるということでした。

Webアプリかつデプロイ先がクラウドの場合、CI/CDはクラウドの仕組みを使うのかGitHub Actionsどちらを使うべきか？

デプロイ部分はセンシティブなのでクラウドに寄せたりするほうがいいという考え方もあるが、楽さはGitHub Actions。カナリアデプロイみたいな小難しいデプロイをするときにはクラウドの方が早い。

セルフホステッドランナーはどのサービスを使うのがおすすめか？

EC2よりマネージドなECSのほうが楽ではあると思う。ネットワーク制限がないならLarger Runnerを使うとよりよいとは思う。

terraform applyをGitHub Actionsで自動化するとき、.tfstateはどのように管理するのか？

オブジェクトストレージを使うのがいいと思う。AWSならS3とか。

なお、SaaSをカジュアルに入れるのが難しい会社にいたことが多いので、terraform applyを実行するサービスを使わずにGitHub Actionsで実装しちゃうことが多い。

スキルをどのように身につけてきたか？

アプリケーション開発→EM→SREとキャリアチェンジをしてきた。チームを変えながらスペシャリティを磨いてきた。

執筆依頼はどういう経緯でくるのか？

雑誌寄稿の縁。そこから2年かけて完成した。

複合アクションや再利用ワークフローは一つずつリポジトリを作成するべきか？一つのリポジトリでファイルやディレクトリで分けるべきか？

アクションについては一個のリポジトリで分けて作成することが多い。Public Repositoryの公開基準にそろえている。
再利用ワークフローは一つのリポジトリに入れちゃうことが多い。再利用ワークフローは一部の人に使ってもらうようなユースケースが多いので、利用者のことを考えて分けないようにしている。

CI/CDはなぜ浸透していないのか？(IPAの報告によるもの)

普通に利益は出ていて機会がないとかはあるのかもしれない。あとはベテランの人たちが慣れ親しんでいるツールを使いたがるとかはあるかもしれない。
他にも同じ人が同じ現場をずっと見ているとか。

CI/CDを使うためにどう説得するのか？コスト的なメリットとか

開発が楽になっちゃうのであんまり許可を取ることなく始めることが多いのだが、ミニマムにスタートするとかはあるかもしれない。

会全体を通した感想

信頼できる知り合いの方がおすすめしていた本だったのでまだ読んでいない中でも参加してみたのですが、豊富な経験と幅広い範囲の領域を勉強してきていることがよく分かる内容で、ぜひ読んでみようと思いました。

特にグッドプラクティス周りは知っている知らないで大きく差が出るところなので重点的にチェックしてみようと思います。

*1:検知・把握・実装・テストをすべてするのが大変

スタッフエンジニアの道~ Forkwell Library#66に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第66回目では『スタッフエンジニアの道―優れた技術専門職になるためのガイド』を取り上げます。 本書は技術専門職としてのキャリア成長に必要な考え方やスキルを詳細に解説しています。上級技術専門職に求められる役割、大局的な視点を持って自らの仕事に取り組む方法、大規模プロジェクトを成功に導く手法、自身の専門性を深めながらチームメンバーの成長を支援する方法を学ぶことができます。

今回は技術専門職としてのキャリアを目指すエンジニア必携の本書をテーマに、訳者の島田 浩二 氏に本書のポイントについてお話していただきます。

スライド

speakerdeck.com

会の様子(講演)

スライドがあるため、スライドにかかれていない内容を中心に書いていきます。

本書の概要

ソフトウェアエンジニアとしてのキャリアはマネジメントとしてのキャリアや技術専門職としてのキャリアがありますが、技術専門職としてのキャリアに関してはまだあまりキャリアパスのイメージが少ないという問題意識をもとに書かれた本だということでした。

内容としては、著者自身の経験やコミュニティの経験をもとにスタッフエンジニアのキャリアが整理されているということです。

技術専門職としてのキャリア

技術専門職というとICが有名ですが、ICは個人貢献者のような間違った印象を与えかねない名称で、組織的なところにこだわる必要があるという話がありました。

局所最適と全体最適

やりたいことがあってその要件に満たすソフトウェアを探す際に、セットアップが容易なものとセットアップが複雑なものがある状況だと普通は前者を選びますが、例えば前者に関して法務部門とセキュリティ部門の仕事が必要な場合は、後者を選ぶような動きができるような人材がスタッフエンジニアだという話がありました。

ロケーターマップ

自分たちのコンテキストで見るのではなく、自分たちを見ている人たちの視点で俯瞰的に見られるようになるために使えるロケーターマップが重要だという話が書かれているそうです。

トポグラフィックマップ

地図の特徴を観察するようなものが語源で、組織の特徴を理解するマップが紹介されているそうです。
こういう話は政治の話として扱いが難しいことを理由に蔑ろにされがちですが、理解をしてもらうために働きかけたりすることは自然なことなので、重要な仕事の一つだという話がありました。

トレジャーマップ

シビラリゼーションというゲームを題材に、多くの技術投資は長期的な目的があってこその投資であることが多いという話がされているそうです。

リーダーとしての資質

ギャップを見つけるだけではリーダーではないし、ギャップが見つけられていない状況でただ行動するのもやはりリーダーではないという話が書かれているそうで、リーダーとはギャップを見つけてそこに向かって行動するのが重要だという話が書かれているそうです。

また、誰かがなんとかしないといけない状況では、誰か=自分だと捉えることが重要だというお話があり、プロジェクトを動かすために必要なものは雑務であってもやるべきだという主張がされているということでした。

メッセージを発信したりルールを決めたり福利厚生を充実させたりをしがちではあるんだけれど、思うような成果に繋がらないことも多いという話があり、組織をレベルアップさせるために

• ロールモデルになる
• 良い影響力を広げる
• 自分自身をレベルアップする

というのが重要だという話があるそうです。

なんでもやるなら結局マネジメントと同じでは？

書籍の話を踏まえると、マネジメント/スタッフエンジニアは同じ方向に進むタイミングもあって、重なるところもあったりする(一本道ではなく行って戻ってを繰り返したりすることもある)ということですが、技術でプロジェクトが詰まる際にそこを解決するのは技術専門職の仕事だということでした。

「会社、チーム、自分自身」フレームワーク

書籍エレガントパズルでは「会社、チーム、自分自身」フレームワークが紹介されているそうですが、著者が自らそのフレームワークを紹介したのは失敗だったという話があるそうです。

モデルとしては正しいと思っているものの、燃え尽きるような人たちも多く見てきたそうで、概念的には正しいことであってもそこに厳密に従うのではなく、自分自身のエネルギーの厳選を大切にすることも同じくらい重要だということでした。

会の様子(Q&A)

講演のあとはQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

スタッフエンジニアのポジションが一般的になるまでの課題は？

CTOや技術顧問くらいしか職位がない。また、そんなに大きくない組織では技術者が輝けるようにしていくのが大切

スタッフエンジニアとシステムアーキテクトの違いは？

システムアーキテクトはスタッフエンジニアの仕事の一つであると思っている。

スタッフエンジニアは職能かグレードなのか？

ここは混乱があるため、スタッフ+という概念が出ているのだろうと思っている。

スタッフエンジニア=優れた技術を持つエンジニアというイメージがないのだがなぜか？

技術参謀と日本語訳してもらえれば大分レベルが高そうだなと思ってもらえるはず。

スタッフエンジニアという肩書がある会社はあるのか？

ある。CARTA HOLDINGSなど。

スタッフエンジニア/マネジメントを超えるリーダーシップとの比較をしてほしい

内容は近いと思うが、マネジメントとしての立場なのかスタッフエンジニアとしての立場なのかが違うので、客観的な話(外から見ている)なのか主観的な話(中から見ている)なのかは違うはず。

スタッフエンジニアは複数いるのか？それとも一人の想定なのか？

アーキテクトやソルバーという役割の話もあるので、一人だけではないと思う。

一番訳しにくかったところは？

4章の限りある時間に関しては、E+2Sというタイトルがあるのだが数式にしか見えないので日本語訳するときに頭を悩ました。

スタッフエンジニアに憧れているマネージャーが読むべきところは？

書かれている内容はマネージャーにとっても全部参考になると思う。

スタッフエンジニアの道を読む時の適齢期は？

読まなくてもいいというと誤解があるが、シニアエンジニアになる前の人は対象読者ではないような気がする。キャリア的には10年くらいのイメージ。

会全体を通した感想

書籍を自分も読んだのですが思ったよりもマネージャーに近い話が多く書かれている感じがあって、そのあたりの背景を自分が読んでいない書籍も絡めながら説明してくれたのが特にありがたかったです。

また、島田さんが最後にどうしても話したいということで入れ込んだ自分自身のエネルギーの話は、すごく身に沁みましたし、自分自身のやりたいことはなにか？というのも常に問いかけられるようにしたいなあと思いました。

CEO・CTOが語る！大企業でのDX内製化に向けた組織立ち上げのリアル〜三菱商事・ミスミでの体験談〜に参加してきた

developer-productivity-engineering.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(15 分くらい遅れての参加でした)

会の概要

以下、イベントページから引用です。

競争力を高めるためにDXや開発組織の内製化に取り組まれている企業は多いですが、組織の立ち上げ時にはさまざまな壁に直面することもあるかと思います。 そこで、日本を代表する企業の中で自らDX組織を立ち上げられた、三菱商事グループのエムシーデジタル株式会社 CTO 久保長様、ミスミグループの株式会社DTダイナミクス 代表取締役社長 道廣様にご登壇いただきトークセッションを実施いたします。

DXを推進する会社として組織を立ち上げる際に生じた、周囲とのコミュニケーションやエンジニア組織作りでの苦悩や乗り越え方などリアルな体験談をお話しいただきます。

会の様子

内製組織立ち上げの経緯

• DTダイナミクスさんは、受発注の関係で開発ベンダーとやっていくというよりは社内のエンジニアが攻めていく必要があるよねという話になり、良いエンジニアが働きやすい文化や良いエンジニアが仕事しやすい制度に特化した組織を立ち上げようという経緯で内製組織を立ち上げしたそうです。また、機動力を高めてアジャイル開発をしやすい土台を作りたいという狙いもあったということでした。
• MC DIGITALさんはデジタル戦略部という部ができたことがスタート地点で、そこから商社の文化とエンジニアの文化の違いに対応するために内製組織を立ち上げたということでした。ただし、コミュニケーションは密接に両社で取るようにしているということでした。また、採用プロセスをエンジニアに特化できるという狙いもあったそうです。

組織設計のポイント

• MC DIGITALさんはスタートは一人だったということですが、データサイエンスに関するニーズが2019年当初から高まっているのが分かっていたため、外部のコンペで優秀な成績を納めている人に声をかけたり、社員にコンペへの参加を奨励するようにしてきたということです。こうして少人数で会社の土台を作った後は、スキルの整備を行いながら、「エンジニアの日」を作ったりと社員のエンゲージメント向上に向けた取り組みを進めたということでした。また、採用に関しては尖ったメディア(atCoderやKaggleといったメディア)を中心にPR活動をしたり、ポテンシャル採用を進めたりしたそうです。
• DTダイナミクスさんは、責任分界点が明確になりすぎないことに注意したそうで、非効率なお客さんの作業を取り除いていくというビジョンを共有したうえで、本社の方と連携を密にとるようにしたということでした。採用に関してはかなり苦労もあったそうですが、ビジョンへの共感を中心に人を集めたのはよかったということです。また、お客さんに対面して話を聞くという取り組みも積極的にやっていったということでした。

開発生産性の捉え方

• DTダイナミクスさんは、Jiraなどで基本的な指標は見ているものの、ニーズをどれだけ早く満たせているのか？という部分に関する滞留ポイントを特定できるような指標を定量的に取得しているようにしているということでした。ただし計測難度が非常に高いので、過度に複雑にし過ぎないことは意識しているということでした。
• MC DIGITALさんはJiraやFindy TeamsによるFour Keysといったメトリクスを取得しつつ、マージまでの速度が長いPRなどを具体的に話せるようにしているということでした。また、言われた通りに作るのではなく課題を解決するためのシステム設計や開発ができることをかなり重要視しているということです。

現在、開発組織において優先度が高いこと

• MC DIGITALさんは、特に電力や人事の領域に関して親会社を超えて価値提供することがまずは挙げられるということでした。次に、昨今進化が目まぐるしい生成AIに関して、汎用型の大規模モデルを活用して、便利になる業務を強化していきたいと思っているそうです。最後に、なんだかんだ採用が重要ということで、今会社にないエンジニアリングマネジメントといった力を蓄えていきたいということです。
• DTダイナミクスさんは、中国との連携が非常に良かったと感じることも多くあったそうで、海外との共同開発を推進していきたいということでした。また、アジャイルシフトに合わせて開発体制やプロセスを整備したいということで、サービスの負債が徐々に溜まっていくなかでアーキテクチャ再考などが早期に回せるような環境構築を目指しているということでした。最後に、アジャイルで素早くデリバリーしていくような人材を採用していくことがやはり重要だと考えているという話もありました。

Q&A

パネルディスカッションの後はQ&Aセッションがありました。
以下、質問と回答を一問一答形式かつ常体で記載していきます。

開発生産性に関する取り組みを非技術者に説明するための工夫は？

• Jiraなどで重み付けをして、開発生産性を意識してからどれくらい効果が変わったのか？というのを数字で示している。特に滞留ポイントを見るようにしていて、こういう部分がどれくらい滞留が早くなったか？というのを話したり、障害対応時間のBefore/Afterを提示したりしている。

子会社が親会社のベンダーにならないようにしていることは？

• 月並みの回答にはなってしまうが、経営者の理解はとても大切だと思っている。また、最新の技術トレンドなどを伝えながらそこからの事業展望を話してもらうようにしている。

内製だからこそ話せるようなテーマはあるか？

• 最上位(親会社の経営者)の人たちと関わりながら、どうすればよりよいものが作れるのか？という話ができること。OpenAIのモデルが出た時にそれをどう使うかをクイックに話せたり、SaaSのコンバウンド戦略の話ができたりしている。

生産性への意識付けは採用時から大切にしているのか？

• 採用時のほうが重視している。テクニカルドキュメンテーションは国語力が求められていると思っているので、採用した後に育てるのが難しいと考えているため。

親会社のビジネスニーズにマッチする開発を行うためには何が課題でどのように対処しているのか？

• 製造業に向けて何を出していくのかってビジネスのドメイン知識も必要になってくると思うので、顧客会議に同行してもらうようにしたりWeb会議で同席したりしている。また、展示会などでプロダクトを触ってもらう機会を大切にしている。(意外と自分のプロダクトの説明ができないことが分かったりする)

会全体を通した感想

採用に関して創意工夫をして一定の成果が残せているのにもかかわらず、やはりまだ採用がkey pointだと話があったのは非常に印象的でした。

大企業が子会社を立ち上げて、具体的にどのようなコラボレーションをしていくのかという実例が聞けるのはなかなか貴重な機会だったので、勉強になりました。

スクラムフェス三河2024のDay2に参加してきた

www.scrumfestmikawa.org

表題の通りスクラムフェス三河のDay1に参加してきたので、そのまとめです。

会場に遅い到着

昨夜が遅かったため、大分遅れて会場に到着しました。会場に到着した後は、頭取と紺野さんと中さん(+途中からmoriyuyaさんと古川さん)と話をしていました。

• 83ラジオがもはや83ラジオではなくなっており、製造業のあるある話をするような場になっているという話をしました。ただ、これは狙い通りだそうで、OSTのような形で雑談ができるブースがあるというのはすごく大切なことだよねという話が出ていました。
• どこにでもスタッフとしているように錯覚してしまう頭取ですが、実際はスクラムフェス新潟とスクラムフェス神奈川とスクラムフェスニセコに関しては馴染みがないということでした。特に新潟に関しては行きたいと思いつつも仕事の時期が被ったりすることもあってチケット購入すらできたことがないということで、来年以降はタイミングが合うならば参加したいということです。
• 各社の経費事情(スクラムフェスに参加するとき、どういう参加方式だと経費申請ができてどれくらいの金額が経費として承認されるのか？)に関して話をしていきました。概ねどこの会社も、何かしらコアな関わり方をしている場合に旅行費用等も含めて経費が出るというのは同じでしたが、色々と条件もあってなかなか経費申請するのは簡単ではないという話をしていきました。
• スクラムフェス三河やスクラムフェス仙台ではそろそろ若い世代にということで代表交代が行われているようですが、頭取は(スクラムフェス福岡は)代表交代するつもりがあるのか？という話を聞きました。福岡に関しては頭取がやりたくて始めたものであるため代表交代というのはまったく考えていないそうですが、年齢関係なくもしも「自分がスクラムフェス福岡の代表をやりたいんだ！」という人が現れてきた場合は代表交代を検討することになるのかもしれないという話をされていました。
• スクラムフェスに関して、その地域が盛り上がってスタッフも地元の人が中心となっている状態はすごくいいよねという話をしました。一方で福岡に関しては中心メンバーで福岡に在住しているメンバーは3人だけのため、もっと地元の人が出てくると良いということでした。
• スクラムフェス沖縄はスクラムフェス福岡ともはや一体になっているという話をしました。また、スクラムフェス沖縄に関しては今年ワークショップを募集してはいるものの、会場は大きめの部屋が一つぽつんとあるだけなので、並列実施などは難しいと想定され、そう考えるとワークショップの種類としてはできても2-3個なんじゃないか？という話が出ていました。
• 古川さんが最近転職をされて、前職と比べて感じることや大企業ならではの話を色々と聞きました。また、もうあと5年で定年という中で、お金に関しては生きていけるような目処がたったため、思い切って英語が日常的に使われる環境に転職されたという話を聞いて、年齢など関係なく新しいことにチャレンジし続けるすごみを感じました。

登壇

登壇してきました。

speakerdeck.com

避難

登壇が時間ぴったりに終了したと同時にすごい音のブザーがなり、随分と大きな音で登壇終了時刻の管理をしているんだなと思っていたら、火災報知器が作動した音でした。

その後は施設の方の誘導にしたがって非常階段からいとうさんと一緒に避難をしましたが、皆さん慌てることなくスムーズに避難されていたうえに、集合写真まで取れてしまうという事態になり、スクラムフェスに参加されている方々の自律性を実感するイベントになりました。(なお、火災報知器は誤作動ということでした)

クロージング

びばさんが場をもたせるために(??)、みんなでふりかえりをするようにファシリテートしており、その流れにしたがって参加者のみなさんがFun/Done/Learnでふりかえりをしていました。(火災報知器の話はなしという制約でした)

その後はまつしゅーさんからクロージングがあり、矢田さんへの代表交代の話がありました。自分はDiscordとかもみていたので知っていたのですが、よく考えたらこの場で初めて発表されることで、Day1のブログにその話は書かないほうがよかったな...と思いました。

最後に、今回のスクラムフェス三河がスクラムフェス初登壇の方が一言で感想をいう時間ができたのですが、スクラムフェス初登壇ではなくスクラムフェス三河初登壇の方が最後に感想を述べていて、なんか定義がおかしいぞ、と思っていたところ、めちゃくちゃニヤニヤしている人が前にいるんですけど...と絡まれました笑

けんしろうさんと再会する

けんしろうさんと福岡以来の再会を果たして挨拶を軽くしたのと、アンジェラさんと名刺交換(といっても自分は名刺を持っていないので一方的...)をしました。

アンジェラさんがスクラムフェス新潟でスクラムフェスの雰囲気が好きになって登壇したい！と思ったのが今回参加のきっかけだそうで、雰囲気が好きになったという理由からはるばる福岡から来てくださっている行動力がすごいなあと思いました。

発表の質問をしてもらう

お名前を伺えなかったのですが、自分のセッションを聞いてくださっていた方が発表に関して質問をしてくれました。

取り組みをただやるだけではなく、自分自身の言葉でどういう意味やどういう機能があるのかを言語化していたにもかかわらずスライドには(誤解)がついていたのはどういう意図なのか？という質問をしてくださったので、47機関が誤解を恐れないことを大切にしているという話や、統一した意味や全員の共通理解ということよりも誤解を恐れずにそれぞれが得意な領域でポジショントークをしていく大切さを体現したスライドだったという話をしました。

懇親会

懇親会としてとりとんに行きました。
とりとんというと寿司しか思いつかなかったのですが、焼き肉居酒屋の名前で、7時間くらいずっと同じ店で過ごすというスクラムフェスでは初めての体験をしました。(この同じ店でずっと過ごすというのが三河名物だということ)

りょかさんかずーさんと話す

最初はずっとりょかさんと話していました。後半はかずーさんも加わり、3人で話をしていました。

• りょかさんが今回やさしさにフォーカスした際、考え方の参考にしていた文献だったり他にも色々と大事な要素がある中でやさしさにフォーカスしようと思った理由の話を聞きました。
• りょかさんは47機関という名前にしようときょんさんが言い出したあたりでチームを離れたそうですが、その当時の基盤チームと今の47機関は随分と別物だろうし、基本的に成長意欲が高いチームであることを考慮すると全く別のチームになっているというのがある意味自然だと思うという話を聞きました。*1当時は余裕もなくてかなり大変だったという話も聞いていきました。
• 47機関の話は自分たちのチームに取り入れようという考えにはならないという話をしていきました。まさに自分自身が今回の発表で苦労したところでもあって、何かしら行動変容に繋げようと発表の中で色々と工夫をしてもどうしても一般的なチームでは取り入れようと思いにくい話になってしまうため、良いのかわからないけれども取り入れやすいプラクティスのような形でも紹介をしたという話をしました。
• スクラムフェスに何回も参加しているりょかさんであっても、こうしたコミュニティの場に来ると会話の輪に入ることにはうっとなってしまうという話やスクラムフェス三河に関してはホームな感じがあるけれど他のスクラムフェスに関してはアウェーな感じがあるという話を聞いて、スクラムのコミュニティが初めて参加するような人たちにやさしくあるためにはどうしたらいいんだろうね？という話をしていきました。やや強引な感じもあるけれど、懇親会のタイミングで強制的に色々な人が交わるようにしてあげるといいんじゃないか？(初心者の人が常連の人と繋がるようにグループ分けをしてしまう)という話をしていました。また、今自分が計画しているスクラムフェスでは小さなコミュニティを作ることを重視しているという話題など、初心者が入りやすい空気を作れるといいよねという話をしていました。
• マネージャーをやっていると、技術から逃げたような印象を時々受けるという話をしていきました。エンジニアは自分自身に合っている職業だとは思っているものの、そこよりもマネージャーのほうが価値を発揮できるということで責務をまっとうしているという話でした。また、りょかさんの場合は47機関に所属していた(47機関と一緒に仕事をしてきた)という経歴だけで非常に「強く」みられてしまうというのは悩みの一つで、これももしかすると技術から逃げたような印象を時々受ける原因なのかもしれないという話をしました。
• 技術書を読むとき、哲学書はすごく役に立つという話をしました。知識的には直接リンクはしていないものの、大局的にものごとを捉えたり哲学書の論理構造を理解しておくことができると、技術書を読むときも技術という手段に対してどういう目的や背景、課題があるのか？という観点で自然と読めるということです。また、丁寧に本を読むということができるようになっているのが大きいんじゃないか？という話や、本を読んだ後にすぐに使えるという意味での実用性というのは哲学書にはないけれど普遍的な考え方やモノの捉え方に繋げられるというのはすごくいいという話をしました。
• カルチャーフィットってどういう状態のことなんだろう？という話をしていきました。ベンチャー企業の場合、採用基準はかなり厳し目にしている会社が多いものの、漫画とか物語の世界みたいなカルチャーフィットしない事件は起こるという話をしていて、特に「自分自身で手を動かせない人」はマッチしない可能性が高いんじゃないか？という話をしました。また、似たような話として、手戻りすることが怖くてなかなか行動を起こせなかったり、理想は語ることができるんだけれど現実とのGapが大きかった時に愚痴を言うだけになってしまったり他人を動かしてどうにか理想に近づこうとしようとしてしまう人も、ベンチャー企業だとマッチしないことが多いという話をしていきました。
• 以前りょかさんの同僚である脇田さんがリトリートに来ていましたが、なぜりょかさんが来なかったのか？という話として、こういったコミュニティの中でも特におかしい人に会える機会を作っておくことで、アジャイルコミュニティの空気感をエクストリームに体感してもらうことが目的だった*2という話を聞きました。そうしておくことで、りょかさん自身が何かコミュニティに関して語ったりせずともコミュニティの雰囲気が今後分かるようになるし、スクラムやアジャイルといった思想の部分も体感できるんじゃないか？と思ったそうです。
• スタートアップやベンチャー企業の場合、昔は仕事のやりがいが報酬というケースが多い印象があったものの、最近は給料を高く設定して引き抜くようなケースというのも非常に多くなってきている印象があるという話をしました。
• 30分セッションは意外と難しかったという話をしていきました。(自分もりょかさんも30分セッション)普段20分or45分の発表に慣れているので、20分の感覚でいると時間が余ってしまうし、45分の感覚だと作りすぎているような感覚が出てしまうということで、りょかさんは発表時間が10分ほど余ったし自分は発表時間がめちゃくちゃギリギリになってしまったという話をしました。
• スクラムフェスで定期的にスポンサーしていると採用効果としてはどれくらいあるのか？という話をしていきました。昨日別の企業さんからも似たようなテーマで話を聞いたのですが、ぜんぜん違う回答で、そのGapが面白かったです。
• 仕事をしているとカンファレンスに参加するのはなかなか難しいという話をしていきました。特にハードワークがある程度前提になっているような会社だと、特に平日にカンファレンスに参加するのはかなりハードルが高く、そういう意味でもおおひらさんはかなり特殊な存在ですごいという話を聞きました。(かずーさんとおおひらさんは同じ会社)
• スクラムフェスやRSGTは値段を高くしたり、チケットを闇雲に増やさなかったりしていて、スケールすることに対してとにかく慎重なのが素晴らしいという話をしました。内輪だと言われてしまうこともありますが、長くコミュニティにいる人が作る空気感が土台にあって、その空気感に少人数が触れることで、少しずつコミュニティが大きくなってアジャイルやスクラムが広まっていくというのは、アジャイルやスクラムの勉強をしている人たちのコミュニティならではだという話でした。
• 残業は成長に繋がるのか？という話をしていきました。ハードワークが前提になっている会社では、残業することが成長に繋がるという考え方も多くあって、ポジティブに残業を捉えているところも多いということです。仕事が成長に繋がるというのは一定理解できるものの、限られた時間内で高い成果を出すやり方を身に着けにくくなるという弊害が起きたり、効率的なやり方を学ぶことができずに過去に解決されている問題を何度も解いてしまうような事態にもなりかねないため、特に若い間は残業をすることに対して慎重になったほうがいいのではないか？という話をしました。一方で、ある程度基礎的な知識やソフトスキルが身についているような状態のときは、仕事をたくさんこなしていくことで実用的な知識が一定得られることはあるよね、という話も出ていました。
• かずーさんは今回Zoomの録画を流しながらちょいちょいコメントをいれるというやり方で登壇したそうですが、もういっそのことZoomの録画などは流したりせずにかずーさんがひたすら話せばよかったんじゃないか？という話をしました。この話自体は他の参加者の人にも多く言われたそうで、何が起こるかわからない状況を楽しめる参加者の人たちの特性を感じたそうですが、さすがに専門知識もないような状態ですべて一から話すというのはできなかったということでした。
• スタートアップが上場すると、株主との揉め事をはじめとした色々な面倒くさいことが起きるという話をしました。会社によっては、上場廃止をして経営権を取り戻すという選択をすることもあったという話や、そうすることによって徐々に"大企業らしさ"が出なくなっていたという話をしたりしました。
• かずーさんは今回が初めてのスクラムフェスだったそうですが、非常に楽しかったというお話をしてくれました。いきなり登壇することになったりしたり色々大変だったそうですが、こうして飲み会まで様々な話ができたのはよかったということです。
• かずーさんはおおひらさんと社内の勉強会ではよく一緒に活動していたけれど別チーム(かずーさんはFASTを実践しているチーム)だという話を聞きました。ただしおおひらさんは社内でもコミュニティや勉強会を立ち上げつつこうした社外コミュニティでも活動しているというのがすごいという話が出ていました。また、今回のかずーさんの発表はQAの話だったので、おおひらさんに代打ででてもらう方がよかったんじゃないか？とも後で気がついたそうです。

moriyuyaさんかずーさんAckyさんと話す

2時間くらい話をしていたところで、moriyuyaさんがりょかさんの席にやってきて、少しお話をしました。
同時に、席が近かったAckyさんと頭取なども交えて話をしました。

• moriyuyaさんのような方が急に現れるのはすごいことなんだけれど、普通に飲み会の席に座っているとmoriyuyaさんに限らずすごい人なのかどうかが分からないという話をしました。
• moriyuyaさんはスライドに関して数で圧倒しているという話をしたのですが、moriyuyaさんも自分(aki.m)の発表は大体数で圧倒している話が多いという話で対抗してきました。ただ、自分は今年になって数が明確な意味を持つものや効果の度合いを正確に表しているもの以外に関しては、数で攻めるような発表はしないという話をしました。実際今年自分が発表した内容に関しては数が出ているのは3/10であり、なおかつ今年出したプロポーザルという意味だと2/10なので激減しているという話をしました。また、2本のプロポーザルに関してもタイトルに数がないと具体的にどれくらいの効果がある発表なのかが分からないものなので、数で圧倒しているわけではないという主張をしたのですが、かずーさんには高度な煽りをしていると言われてしまいました。
• RSGTに出すプロポーザルに関しては6つ候補を持っているものの、現時点で優先的にやる必要があるバックログが積み重なっているためなかなか出すことが難しいという話をしていきました。ただ、プロポーザルの数が昨年のように200個くらいに落ち着くと考えると、80個くらいの今がベストタイミングなのではないか？という話をしていました。
• Ackyさんが最近自分が抱えている悩みは何か？と質問をしてくれたので、ビジネスシーンでも使えるような英語が喋れないことを挙げました。それなりに時間もかけてやってはいるのですが、ライティングとリスニングが上達しているのにも限らずスピーキングに関してはまるで上達せずだという話をしたのですが、日本語が上達するプロセスを考えて、そのうえで英語が上達しないプロセスと比較をしていくとヒントが見つかるんじゃないのか？という話や、ネイティブじゃない外人だと、文法などはめちゃくちゃだし正確な英語はそんなに求められないことがビジネスシーンであっても多いという話を聞きました。
• moriyuyaさんは怖いという話がよくされていますが、Ackyさんも負けず劣らずシャープな返答をしているという話をしました。
• 三河でやり残したことはないか？という話をされて、今回じゅんぺーさんに話をすることが一番のやりたいことだったし、三河だからこそやりたかったことということでりょかさんとも話ができたので満足しているという話をしました。ただ、おがさわらさんとはあんまり話せなかったという話をしたところ、ちょうどおがさわらさんがいらっしゃり、この後話す約束をしました。
• moriyuyaさんが今回RSGT2025で出したプロポーザルは、本当は5年後にしようと思っていたという話を聞きました。moriyuyaさんは最近およべさんやいくおさんが話をしていることやSNSでオープンにしている内容を見て、そろそろ話をしていかないと他の人が先に話をし出してしまうと感じたそうで、今が話をするベストタイミングだと感じたそうです。
• moriyuyaさんが今度RSGTとは別の場で話をする内容を少しだけ聞きました。スライドは非公開になってしまう可能性が高いそうですが、これまで共感をしてもらった(別の場で話をしてほしいと言ってもらったきっかけになった)話を軸にしつつ、経営陣やマネージャーといったメンバーじゃない社員の人たちが自分で道を切り開いて会社を良くしていくぞという内容を話す予定だということでした。
• 頭取が昨年プロポーザルを出さずに今年プロポーザルを出した理由を聞きました。昨年も本当は出そうと思っていたそうですが、タイミング的に今年のプロポーザルで書いたような内容の取り組みをやり始めたばかりだというのが気になったそうでプロポーザルは今年に見送りしたそうです。

ぽめさんと話をする

ぽめさんとスクラムフェス新潟2023以来の再会を果たして、少しだけではありますがお話をしました。
ちょうど自分の発表の直前がぽめさんの話だったので聞いていたのですがフィードバックが欲しいというお話をいただいたので、自分の直前の発表だったので素直にあまり聞くことができていなかったという前提のもと、そこまでへりくだった感じで話をせずに堂々と話してもいいんじゃないか？というお話をしました。

おがさわらさんミツカワさんじゅんぺーさんtamagoさんkenzzzzzyさんと話をする

おがさわらさんと話をしたいという流れから、おがさわらさんミツカワさんじゅんぺーさんたまごさんkenzzzzzyさんと同じテーブルになり、話をしていきました。(途中でめーぷるさん？も加わっていたような気がしたのですがめーぷるさんなのかの確信が持てませんでした...)
最初はおがさわらさん以外の人たちを無視して話をスタートし、その後は全員で色々と話をしていきました。

• 先日社内でスクラムフェス仙台の再演をしたのですが、その際に出た感想がスクラムフェスでは出ない視点で面白かったので、それを共有しながら色々とお話をしていきました。まず、話には理解を示しつつも現行教育に対して意外と肯定的な意見が多くて*3、教育以外の観点(その人の幸せ)での意見が出ているのは面白いという話をしました。幸せに寄与する重要な能力として、自己決定能力(自分で自分のことを決めていく力)というのはあるんじゃないかと思っているという話から、じゃあその自己決定能力に対して個別最適な学びと協働的な学びはどのくらい寄与しているのだろうか？他に寄与するような因子はないのだろうか？という話でした。自己調整学習の文脈を考慮していくと、メタ認知みたいなところはかなり重要度が高いのではないかという意見や、個別最適な学びと協働的な学びに関してもおがさわらさんのお子さんの学校の様子をみるとディベートなどを通してどんどん自己決定できる風に育っているような印象があるので効果はあるような気がしているという意見や、GRITが重要なのではないかという話が出ましたが、自己決定能力に対して何が影響するのかが述べられている文献は思い至らないという結論になりました。また、これも感覚的な話ではありますが、高い自己肯定感というのは大切なポイントな気はするという話もしました。
• おがさわらさんがtamagoさんをいじるのを一年で一番楽しみにしているという話を聞きました。tamagoさんもいじられるのを楽しみにしているということで良好な関係(?)が築けているようですw
• 東三河と西三河のバトルと俯瞰して上から見てくる尾張を合わせた三つ巴が発生していたのですが、この内容をブログに文字として書くと(東三河と西三河の人は特に)不機嫌になる人が出てくるのでやめておいた方が良いという話をおがさわらさんにされました。なので、ブログには書かないでおきますw
• 三河は正直あまり名産品と呼べるようなものはないという話やうなぎを食べたけれど福岡の方が安いし美味しかったという話から、Kiroさんはご飯が今ひとつなのがわかって一度も現地に行ったことがないらしいという風の噂に関して話をしていきました。美味しいものがないのは仕方がないし地元の人も認めているそうですが、各地のスクラムフェスがどこも美味しいものをたくさん用意できる地域だというのも三河の食の不充実さを際立たせてしまっているポイントなんじゃないか？という話をしていきました。
• 食の充実度合いでいうと、個人的には一番は北海道なんだけれどもかなりいい線に福岡がいてほぼ同着だという話をしました。その話をしたところ、じゅんぺーさん的には新潟がそこに絡んでこないことが不満だという話になり、新潟はお米は一番美味しいんだけれど福岡や北海道(特に福岡)は何を食べても美味しいというのがなかなかすごいことだという話をしました。
• スクラムフェスの代表や運営がkeynoteをするのはなしだよねという話をしました。また、川口さんは今回のDevOpsDays Tokyoで運営でありながらkeynoteを務めていましたが、めちゃくちゃ嫌がりながらもテーマに合致しているという理由で受けていたという話も聞きました。
• 米にこだわりを持っているという話から、炊飯器に何を使っているのかという話や、美味しいお米を取り寄せるために農家を回って一番美味しいお米を直で契約して取り寄せているという話をしました。じゅんぺーさんはお米に対してこだわりがある人が大好きだそうで、住所さえくれればお米を送ってくれるという話をしてくれました笑 なお、じゅんぺーさんはお米を釜で焚いて真ん中の部分をすくうタイミングが至福だと思っているそうです。
• tamagoさんが「こわけて」という三河弁を使っていたのですが、これが三河弁だと分からずみんな混乱していました笑
• 海外スピーカーを日本に招くというのがなかなか大変だという話をしていきました。スクラムフェス三河における昨年のJoeは日本にも拠点があるということで一定楽ではあったそうですが、新潟でダニエルをよんだりDevOpsDays Tokyoで海外スピーカーを呼んだりするのは色々と苦労があるそうです。具体的には、日本に来てもらったからには観光を楽しんでもらわないといけないということで色々とコーディネートをしたり、海外と日本の文化のGapに対してがんがんフィードバックをしていくのを止めたり、お金を海外通貨で渡したりしないといけない点は特に大変だというお話を聞いていきました。海外と日本の文化の違いに関しては、海外の人はすごく敏感になることもあるそうですが(観光案内の人が英語を喋ることができなかったり、カンバンに英語がなかったり固有名詞が乱発されていたり...)、それは日本が海外に行ったときも同じなので、日本固有の問題ではなさそうだという意見も出ていました。ただし、現状だと日本に来てもらうメリットがそういった観光的な部分にフォーカスしてしまって、どうしても「招き入れる」ような関係性になってしまっているというのも難しいところだという話をしました。
• じゅんぺーさんの話はスケールが非常に大きくて、話を聞くと一つ目線が上がるという話をしました。Day1のブログで言及した内容に加えて、じゅんぺーさんは更にスケールが大きいこととして、JaSST新潟やスクラムフェス新潟を合体させてどでかいカンファレンスをやりたいと思っているという話や、もはやベルギーと新潟を姉妹都市にしてしまいたいと思っているという更にスケールが大きい話をしてくれました。
• 前回のスクラムフェス仙台でふじえもんさんが中心と鳴って情報保障の取り組みをしていたのですが、これはすごい良かったのではないか？という話をしていきました。アクセシビリティの問題はどこにいってもあるし、所謂マイノリティ的な問題はどのカンファレンスでも課題として抱えているので、こうした取り組みを各地の地域スクラムフェスがやって、その取り組みを他のスクラムフェスに展開してくような流れが作れるとすごくいいんじゃないかということです。同様にマイノリティ繋がりで、小さい子持ちの人でも参加しやすいようにベビーシッターを無料で提供するといった取り組みもできるといいよねという話も出ていました。

まつしゅーさんmoriyuyaさんおがさわらさんかつさんhisaさんパウリさんと話をする

まつしゅーさんmoriyuyaさんおがさわらさんと話していきました。途中でかつさんやhisaさん、パウリさんが代わる代わる席にいらっしゃりました。

• スクラムフェス三河も5年目ですが、本当に製造業や初参加という色が見事に出て、参加人数もすごい多いし雰囲気もすごくいい最高のカンファレンスになりましたね、という話をしていきました。まつしゅーさんは本当は代表として引っ張っていくような立場ではなくてサポートするような立場が好きだということで、そういうのもあってかメール対応などは全てまつしゅーさんがやっているという話を聞きました。まつしゅーさん的にはみんながなかなか対応せず我慢してやってしまうそうですが、もう少し待つと誰かがやってくれるんじゃないか？という話は出ていました。ちなみにDevOpsDaysに関しては、誰もやらないので最終的にはおがさわらさんがやるようにしているということでした。
• スクラムフェス大阪は、トラックもめちゃくちゃ多いしそのトラックに採択されたからといってその地域に行かなきゃいけないわけではないので、「神奈川サテライトでスクラムフェス大阪の福岡トラックとして登壇する」みたいな複雑すぎる状況が起きていたのは面白かったという話を聞きました。
• スクラムフェス大阪がどういう経緯で立ち上がったのか？という歴史の話を聞きました。Devsumiの録画が残っていると本当はそれがいいんだけれど...という前提で、コロナになって一ヶ月半でオンライン勉強会の動きが立ち上がり、そこで色々な実験が行われ、それが迅速にコミュニティの中で展開し、技術的検証を済ませてあっという間にスクラムフェス大阪のオンラインが開催されたという話を聞きました。その集大成をDevSumiで録画として発表したそうです。
• オンサイトの勉強会は最近復活傾向にあるけれど大分減ってきた印象があるということで、オフィスが閉まって回り道をしながらみんなで出ていた時代はすごく懐かしいという話を聞きました。ただしそういった懐かしさがある一方で、仕事の後にオフィスに勉強会に行くというのは子どもが小さかったりといった家庭事情がある人にはかなりきつい話だっただろうなあということで、オンラインになってよかった部分もありはするという話が出ていました。また、オンサイトだと入館管理をはじめとした手間がかかることもネックの一つではあったそうです。
• 平均して1日に20kmくらい走っているのと毎日3時間以上歩いているのはどちらがおかしいかという話をしました。結論は出ず、どちらもおかしいという話になりましたw

おがさわらさんに送ってもらう

始発で帰るか終電で帰るかを悩んでいたのですが、とりとんが0時には閉まるということで、最後はスクラムフェス仙台に引き続きおがさわらさんに豊橋駅まで送ってもらいました笑(おがさわらさんも歩数稼ぎがあるということでした)

かなりの時間歩くようにすると健康チェックができたりしてすごくいいですよねという話をしたりしながら今度はしっかりホームまで送ってもらったのですが、自分が「もう分かったので大丈夫です！」と言ったタイミングで自分が実はまだ駅までの道を間違えて認知していたのがハイライトでした。

*1:ただし、当時チームの中にいるときに感じていた印象と外からぼーっとみていた印象とでは全然違うことを踏まえると、自分が今回した発表を聞いてもピンとこないというのが正直なところだそうです

*2:リトリートに参加する人は、こうしてスクラムフェスに参加している人たちの中でも更にコアなメンバーに限られる

*3:パラダイムシフトを起こす根拠が不十分なのではないか？新しい教育の効果としてあった勉強することが楽しいというのは素晴らしく感じる一方で、知的労働をすることが当たり前の世の中になっていくなかで勉強が好きだったり得意ではないと生きづらいような世界線を作っていないか？

yr-learning Vol35に参加してきた

yr-camp.connpass.com

今週もこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

今日は関数型デザインの第8章を読んでいきました。

循環依存

説明用のコードだからというのはありそうですが、循環参照が出てきて驚いたという話がありました。

処理がそこまで複雑ではなくマルチスレッドのことも考慮していない現状だからこそできるソリューションで、問題がまったくないとは考えていなかったんじゃないか？という話をしました。

ただ、Clean Architectureをみる限りはADPの文脈で循環依存は絶対だめだと記載しているので、パッケージレベルではないとはいえしれっと循環依存をしているのはだめじゃないか？という話をしました。

噂話は誰が持つべきか？

現実世界をイメージすると、噂話を持っているのは人なのでドライバーが噂話を持っている方が良いのではないか？という話が出たのですが、今回の仕様的にバス停ではないと噂話は広めることができないので、バス停が噂話を持っているような仕様の方が自然なのではないか？という話が出ていました。

Clojureのプログラムを読み解く

ひたすらClojureのサンプルコードを読み解いていきました。

話しながら処理を口頭で説明すると、理解が捗るなあと思いました。

ClojureとJavaのコード比較

使用するメモリは直感的には大分すごそうですが、新たにオブジェクトを作るのではなく操作ベースで分類したほうがバグは絶対に起こりにくそうだという話をしました。

また、Javaはオブジェクト指向プログラミングを実践するためにまずは概念ベースで整理をしているのに対して、Clojureは関数ベースでプログラミングをしていくためテストから始めているというのは大きな違いの一つになっていそうだという話もありました。(Clojureはデータを分けない前提で進められていそう)

関数型の方が面白そうな作り方をしているしバグも上手くできそうだなあという感覚があるという関数型言語への目覚め？みたいな感覚も参加者のなかで登場していました笑

ただ、相変わらず慣れの問題もあるのか読みにくさは感じるという話をしました。

全体を通した感想

次回から関数型のモデリングとオブジェクト指向のモデリングの違いが分かってくるという話をされ続けていてなかなか関数型のモデリングとオブジェクト指向のモデリングのどちらがいいのかの話はされないというのは面白いなあとボブおじさんらしくて面白なあと思いました笑