天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

【DMM×グロービス】DMM.comとグロービスの開発組織構造の変遷に参加してきた

globis.connpass.com

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

会の概要

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

開発組織構築を進めていくと、あらゆる課題に立ち向かう必要が出てきます。

CTO、VPoE、エンジニアリングマネージャーなどの役割を持つ中でマネジメントや課題に対する意思決定にお悩みの方も多いのではないのでしょうか。そこで今回は、直近で開発組織の大変革を行った合同会社DMM. com釘宮さんをお招きし、グロービスのVPoE末永と一緒にエンジニア組織で起こる課題と対処事例や、失敗談などをお話しするトークイベントを開催します。 エンジニア組織についてお悩みの方や、これから起こる事象に対する対処事例などを学びたい方はぜひご参加くださいませ!

会の様子

DMMのこれまでの開発組織の変遷

DMMは、元々受託っぽい雰囲気の会社になっていて、エンジニアがビジネスに参画することがはばかられるような雰囲気だった*1そうですが、徐々にエンジニアがビジネスに参入するような事業部が出てくるようになってきて現在に至るそうです。
ただし、現在も主業務からはエンジニアが一線を置く組織もちらほらあるということでした。

DMMが現在の開発組織に至った背景

DMMでは、決裁権や評価を事業部長が元々行っていたそうですが、その結果エンジニア視点だと決裁権や評価に対する満足度が低くなってしまったり、エンジニアの能力向上にコミットするインセンティブが少なくなりがちな問題が出てきたということで、エンジニアの決裁権や評価に関しては責任と権利をエンジニアに寄せるようにしようと考えたのが、現在の開発組織になるきっかけだったということです。

HRポリシー

グロービスではHRポリシーがあるそうですが、ビジネスと開発で一見相反するような部分*2が出てくることがあるそうで、その点は悩ましいという話が出ていました。

事業部型組織と職能型組織

スクラム関係だと事業部型組織に近い組織を作りがちな印象があり、GitLabでは職能型組織に近い組織を作っている印象があって、グロービスではそれぞれのいいとこ取りをしようとマトリクス型組織にした結果、非常に難度が高く*3、現在は事業部型組織に近い形になったということでした。(ただし育成の観点で横串のラインは通している)

釘宮さんからは、職能型組織はスペシャリティが高い人が上に行きがちになるため、そうなったときに異なるスペシャリティを持った人同士でコミュニケーションを取れるかというのは一つのハードルになりそうだと感じているという話がありまいた。(とはいえDMMでは職能型組織の立ち上げに現在はチャレンジしているということです)

規模拡大に伴う組織変遷

規模が拡大していくとどうしても大きな変更をするタイミングが出てくることがあるそうですが、その際に一気にハレーションが起きてしまう懸念があったそうで、変更を起こす際は如何に大きなハレーションを起こさないか?ということに集中していたそうです。

また、規模が増えてくると木こりのジレンマに対する投資(=エンジニアが個々の現場で頑張っているところに、開発生産性をあげるような取り組みをする)の意味合いがより上がってくるよね、という話も出ていました。

今後の展望

DMMでは、会社の方針としても意図的に個別最適が強い会社になっているそうですが、エンジニア1000人体制になってきている今、徐々に全体最適化にも舵をきっていくということでした。

グロービスでも、チーム数としては20-30チームを超えてくる規模になってきたため、全体最適化に舵を切りつつあるそうです。
また、同じチームにずっといると飽きてしまうような人の流動性を上げるような施策も考えているということです。

会全体を通した感想

こんなにいい会社だよ!の宣伝をひたすらするという形ではなく、うまくいっていない部分もかなりはっきりと話をしてくれたのが非常によかったです。

オンサイン参加だったのですが、自分の環境問題なのか釘宮さんのちょいちょい音声が途切れて聞こえており、断片的にしか聞き取れない部分が多かったのが残念でした。。

*1:開発側とビジネス側が明確に分かれてしまい、お互いに牽制しあってしまってデッドロックが発生

*2:エンジニアの時間はすべて事業を良くするために使う VS エンジニアの技術力向上に一定は時間を割いてもよい

*3:マネジメントラインが一本のほうがシンプルにならない

インフラエンジニアBooks 30分でわかる「ゼロトラストアーキテクチャ入門」に参加してきた

infra-eng-books.connpass.com

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

会の概要

インフラエンジニア向けの書籍を取り上げ、その著者や翻訳者を招いてライブトークしていくイベントです。

今回は、「ゼロトラストアーキテクチャ入門」がお題でした。

会の様子

本書の狙い

ゼロトラストがバズワード的になっており、サイバーセキュリティの常識がゆらぎつつある中で、多くの企業がゼロトラストに向かうための支援をしていると、様々な躓きポイントがあることに気がついたそうで、多少泥臭い部分も含め、ノウハウを惜しみなく公開しようと考えたのが本書だということでした。

CHAPTER1の概要

ゼロトラストをすることでこれまでと何が変わるのか?に関して話が書いてあるということです。

CHAPTER2の概要

なぜゼロトラストを導入するべきなのか?という話を記載しているそうです。

CHAPTER3の概要

歴史を踏まえながらゼロトラストをどのように構築していくのか?という話が書いてあるということです。

CHAPTER4の概要

具体的な実装や技術的な話をしているということです。

CHAPTER5の概要

ゼロトラストの運用にまつわる話が書いてあるということです。

CHAPTER6の概要

ゼロトラストにまつわる娯解に関して話が書いてあるということです。

執筆するにあたってよかったこと

続いて執筆するにあたって小林さん個人がよかったことを聴いていきました。

  • ゼロトラストの専門家で執筆できた
  • ターミノロジーガイドがあって表記統一コストがめちゃくちゃ低かった

の2点があるそうです。
一方で、執筆中にPJが大炎上して執筆時間が取れなかったのは大変だったということでした。

ゼロトラストとは?

境界防御的なセキュリティ方式から、リモートワーク/クラウド/生成AIの普及により、脅威が変化して攻撃が内部/外部というくくりでは難しくなったことで、「ここなら安全というエリアはなく、境界内でも安全ではない」という考え方が生まれ、これがゼロトラストだという簡単な説明がありました。

ゼロトラストアーキテクチャのベストプラクティス

NIST SP800-207にあるベストプラクティスの紹介がありました。

詳しくは本元を見ていただければと思うのですが、ユーザーIDだけを信用するのではなく、様々なガイドラインやルールをはじめとしたユーザーのコンテキストを都度都度見ていくのが重要だという説明がされていました。

ゼロトラスト全体像

ゼロトラストの全体像を見ようとすると横文字や略称がとにかく多くなってしまうのが難点だということですが、都度都度認証を行う部分が心臓部になってくるということでした。

最後までゼロトラスト化できなかったことは?

小林さんの会社でもゼロトラストを実践しているそうですが、唯一印刷機だけはゼロトラスト化できなかったという話が余談としてありました。

これは、早くからゼロトラストに取り組んでいたGoogleMicrosoftもゼロトラスト化できていない部分らしいということです。

ゼロトラストの娯解

ゼロトラストに関する誤解として、以下が挙げられていました。

  • ゼロトラストにすればコストが下がる(全体最適化した結果コストが下がる可能性はある)
  • すべてクラウドに移行する必要がある(すべて信頼しないのが基本であり、クラウドに移行するかは本質ではない)
  • 境界をすべて無くす必要がある
  • ゼロトラストを実現できるパッケージがある

会全体を通した感想

かなり前から、このコミュニティおすすめだよと複数の方からレコメンドいただいていたのですが、インフラエンジニアじゃないしなあ...と思ってなかなか足を運べておらず今回が実は初参加でした。

実際に参加してみて、著者の方から本の執筆にあたる余談などが聞けることと、講演時間が30分と短めなので参加しやすいのがよかったです。

今回のように気になる本や気になる著者がいる場合は、定期的に参加してみようと思います。

プロを目指す人のためのTypeScript入門 - Forkwell Library #35に参加してきた

forkwell.connpass.com

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

会の概要

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

今回の第35回目では、昨年4月に発売された『プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで』著者のうひょ氏をお招きし、お話を伺います。

根幹となるJavaScriptの仕様・機能とともに、TypeScript独自の仕様・機能を解説している本書について、うひょ氏に書籍の内容を振り返りつつ、TypeScriptの面白いところをピックアップしてご紹介いただきます。

事例講演では、FastLabel株式会社 VPoEの植野 晃司氏に、FastLabel社の事例についてご発表いただきます。

会の様子

基調講演「TypeScriptってどんな言語? 言語そのものを知る面白さ」

本のコンセプト

応用に踏み込まずTypeScriptそのものを教科書的に学ぶようにしているそうですが、現場でプロフェッショナルとして振る舞えるような本にはなっているそうです。

また、JavaScriptの経験がなくてもTypeScriptが学べるようなスタイルも特徴的だということでした。

他にも、初心者向けに誤魔化したような説明は書かず、厳密な用語の使い方, 厳密な定義を記載するように心がけたそうです。

2章のおさらい

基本的な構文の学習に加え、文と式の違いや式文に関して正確な説明をしているということでした。(なんとなく動くことよりも体系だった説明を意識)

3章のおさらい

オブジェクトの概念やオブジェクトに関連した構文を学び、===の判定や部分型関係など込み入った話も曖昧な表現なく正確に説明するようにしたということでした。

4章のおさらい

関数に関して学ぶとともに、ブロックスコープの概念も説明しているそうです。
ジェネリック関数の型引数が省略された場合にどのようなメカニズムで推論されるのか?という部分を詳しく説明して深い理解を促しているということでした。

5章のおさらい

クラスやエラー処理に関して解説しているそうです。thisの解説もここに突っ込んだということでした。

6章のおさらい

TypeScriptの醍醐味である高度な型に関して解説しているそうで、一番分量を割いたということでした。タグ付きユニオンや型の絞り込みに関してもこの章で解説しているということです。

7章のおさらい

モジュールシステムに関して解説しているということでした。

8章のおさらい

非同期処理をPromiseなど含め裏側の仕組みから丁寧に解説しているということでした。

TypeScriptの面白いところ

ユニオン型と型の絞り込みが一番面白いところだと考えているそうで、6章で丁寧に解説しているということでした。

タグ付きユニオンが使えるようになることを本書でも目標としているそうで、論理和論理積で表現しないようにアンチパターンとともに説明しているということでした。(静的解析を受けるためにも、正確に可能性を表現することが重要)

基礎固めをなぜするのか?

読者次第で幅広い応用ができて技術進化に立ち向かえることや、読者が自ら考える助けをすることを補助するために、基礎固めをしているそうです。

何より、仕組みから実装を理解することで楽しめることも基礎固めをするメリットだと考えているということでした。

発売当初からのTypeScriptの進化

Node.jsのCJS/ESM両対応機能にTypeScriptも対応したことや、.cts/.mtsの導入、空オブジェクトやunknownの相互運用性向上、satisfies構文の追加、デコレータのサポートによるクラスの表現力向上、using宣言のサポートなどが本書からバージョンアップしているということです。

事例講演「スタートアップにおけるTypeScript運用の変遷」

TypeScriptを使ってよかったこと

TypeScriptで言語を統一することで、言語のキャッチアップコストを抑えられていることと、ライブラリが提供している型に従うことができている(CDKの型定義に従うとソース的に正しいものがすぐ書ける)ことがよかったそうです。

anyとasは使わない

TypeScriptで言語を統一した上にスピード優先の開発をしていた結果、anyが乱立する事象が発生したそうです。(自分たちが定義した以外の型を一旦anyとした)

結果、型定義の恩恵を受けることができなくなり、最終的にはすべてのanyを消すためにコストをかける羽目になったということでした。

同様のことがasに関しても起きたそうで、この2つは運用ルールなりでカバーする重要性を実践の中で実感したということです。

tsconfig/basesを使おう

元々はCompilerOptions等を自前で設定していたそうですが、必要な部分だけ現場に合わせて変えないといけない部分だけ変更しておくと、初学者がTypeScriptを変な形で使うことがなくなるし、ベストプラクティスに従えている確信が得られるため、是非使ってみてほしいという事でした。

Q&A

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

jest.fn()などはそのままでは引数も戻り値もanyになってしまう。テストコードのみはanyを使うというのは例えばありなのか?
  • テストコードではありかなと思う。ただ、一旦本番をanyで書いてしまうとテストを回すまではコンパイルエラーに気が付けないとかの可能性もあるので、
  • めちゃくちゃ無理はしなくてもいいが可能ならanyを使ったほうがいいとは思う。なお、jest.fn()はanyを使わずとも意外と楽に書けるので、そこはanyを使わないチャレンジをしてみてもよいと思う
TypeScriptで書いたコードをテストするときのベストプラクティスを知りたい
  • TypeScript特有のテストはないと思うが、なるべく型に寄せて、コンパイラがチェックできることはなるべくテストでチェックしないようにするのは重要だと思う
  • カバレッジ100%は現実的ではないので、自分たちが書いたソースコードが意図した通りに動いているかをテストするのがいいと思う
エラー処理についてRustのResult型のようなものを定義して使うか?

人によって言うことがぜんぜん違うのではと思う。uhyoさんとしては、両方使うことが多い。RustでResultで書けるならResultで書けるし、Rustで言うpanicに相当するものはThrowで書く。

アップデートで追加された機能はすぐ使うのか?周りのメンバーのキャッチアップを待つか?

基本的にはどんどん使っていくスタイル。人のスキルレベルに依存しないものは特に積極的に使う。

TypeScriptのデメリットや選択しないケースは?

正直思いつかない。

anyではなくunknownならどうしていいのか?
  • unknownなら不要に使いづらいのでまだマシと言うだけで、unknownを使っていいというわけではない
  • これなんだっけ?というのが本当に分からない場面もあるので、その際にはunknownを使ってもいい
エラーハンドリングに関してもっと詳しく知りたい
  • TypeScriptは言語仕様上何が投げられるのかわからないので、エラーをキャッチするときはunknownにすると良いと思っている。
  • instanceofのエラーならこう処理する、みたいなのを決めておくとかは現場でやる
DenoやBunといった環境も出ているが、Node.jsがやはり多いか?
  • 今はメジャーなのでNode.jsを使っているという感じ
  • 現状はNode.jsだと思うし、将来的にもNode.jsがデファクトスタンダード的な立ち位置を守り続けるような気がする(Node.jsも健全な進化をしているので)

会全体を通した感想

初心者向けの本というと、とりあえず動くアプリケーションを作ると言った構成のものが多い中で、プロフェッショナルになるために教科書的な基礎を盛り込んだという部分には特に共感できました。

freee Tech Night in Kansai「モデリング重視のRails開発」に参加してきた

freee-tech-night.connpass.com

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

会の概要

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

今回のテーマは「モデリング重視のRails開発」です。関西支社のメンバーが中心になって作っている「freee販売」の開発では、Ruby on Railsを使いつつ、モデリングアーキテクチャに工夫を加えています。今回は関西支社からの開催で、freee販売の開発メンバーにお話を聞いてみます。

会の様子

freee会計のRailsアーキテクチャ

通常のRailsだとController/View/(Active Recordで作られた)modelが近しいところにいるのが通常多い印象がありますが、Presentationが上にあり、真ん中にドメインモデルがあり、下にインフラがある三層アーキテクチャに近い構造を取ってきているということでした。

このようなアーキテクチャにするならRailsにする必要ないのでは?というツッコミはよく受けるそうですが、長年freeeさんで培ってきた厳しいセキュリティ要件に耐えられるだけのライブラリを再利用できるメリットがあるため、このようなアーキテクチャになっているそうです。

実際中途で入られたkakkinさんの目線でも、自分が知っているRailsとは全然違うぞ...となったそうで、特にmodelのディレクトリが2ついる*1アーキテクチャには戸惑ったそうです。

開発スタイル

ざっくりいうとオニオンアーキテクチャに近いアーキテクチャ×DDD*2が開発スタイルになっているそうです。

また、品質特性の中ではテスト容易性を重視したということで、カバレッジが100%に近い膨大なテストがある中でもテストが開発を早められるようになっているということでした。

開発の中では、名前づけを超重要視しているということで、開発者全員で複数のユースケースを考えてモデルの名前を変化させるスタイルを取っているということです。(腹落ちできないモデルの場合はコードをすべて捨てることも厭わない)

ドメインオーナー(ドメインエキスパート)

上記の開発の中では、PM/PdMがドメインオーナーを努めているということで、ドメインオーナーはドメインや販売に関してめちゃくちゃ詳しい猛者が揃っているということでした。

モデリングを常時しているメリット

開発者20人が全員同じ共通言語を持っており、設計が安定し、破綻しづらいアーキテクチャになっているということでした。

他にも、開発者が自分たちで見つけたものを自分たちで作っていくような感覚に陥るため、モチベーション向上に繋がるということでした。

モデリングを常時しているデメリット

コードを何回も書いては捨てる関係で短期的にはすごく時間がかかるように見える点はデメリットではないかという話がありました。

今後取り組みたいこと

最後に、パネラーの方からそれぞれ今後取り組みたいことに関して話がありました。以下、内容を常体で記載していきます。

  • 使っている人同士が接続できるのにシステム都合で接続できないことがあるので、freeeを使用している人は全員がつながるような仕組みを作りたい
  • 自分で販売を使ってみようと思っている
  • クライアントに同じ販売管理をしている会社は一社もないのだが、モデリングをすることで共通プラットフォームを作れるようにしたいとは思っている

Q&A

モデリングの中でER設計はするのか?

あんまりER設計を意識はしていないということでした。大事なのはモデルを作ることであり、図を作ることではないと考えているそうです。

ドメインエキスパートの人はモデル図ベースで議論できるのか?

ドメインエキスパートは全員エンジニアリング能力高いので、モデル図やER図を見てレビューができるということでした。

複数拠点での議論をどう進めているか?

基本はオンラインなので問題ないが、最近はモデリング合宿をチームでやったりしているということです。

Rails以外の言語は使っているのか?検討などはしたのか?

Goも候補に挙がったりはしているが、これまで溜まってきた資産を考えるとRails一択の現状になっているということです。

開発者全員の認識を揃えるのに時間はかからないのか?

基本的には全員が参加しているので、時間はかからない。全員が参加しない場合は、結果を全員に共有する時間を設けるようにしているということでした。

会全体を通した感想

教科書にしたがってできていてすごいなあと思いながら最初は聴いていたのですが、途中から、教科書的な内容にしたがうというよりはそれぞれが「これいいよね」と合意できるものを取り入れた結果教科書的な内容になっていったという話があったのが一番の驚きでした。

*1:Active Recordが強力なので、依存を避けるためにActive Recordに依存したmodelと依存していないmodelにディレクトリを分解することで、機能拡張をやりやすくしている

*2:ただし俺流DDDが多いので、社内ではDDDと言わないようにしている

Tech系Podcastを同時視聴したり、アジャイル系の相談したりに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームについて考える会に参加してきたので、会の様子と感想を書いていこうと思います。

今日は最近参加者限定公開されたばかりのXP祭りの同時視聴をしていきました。

東京都庁アジャイルを実践するための「都庁アジャイルプレイブック」のご紹介

confengine.com

自分が気になっていた都庁×アジャイルの話を聴いていきました。

アジャイルって何それ?という状態かつアジャイルにそこまで興味がない人に対してどうやってアジャイルを知ってもらうか?で、ゲーミフィケーションを意図的に取り入れている部分などは面白いなあと思って聴いていました。

都庁アジャイルプレイブックの中身などは、一般公開されているということもあったのかあまり話されず、個人的にはもう少し聞きたかったですが*1、どうやってゼロからアジャイルを導入していくのか?という観点で色々考えることができる面白い発表でした。

半年間ずっとオンボーディングをし続けた話

confengine.com

続いて、おおひらさんがオンボーディングを受けたという話を聴いていきました。

オンボーディングの具体的な内容はもちろんですが、QAのオンボーディングの一貫として、テスト関連のFWを使ったりすることなく、プロダクトのビジネスモデルキャンバス/リーンキャンバスを書いてみるというのは特に面白いなあと思いながら聴いていきました。
また、期待値のずれの部分で話があった「オンボーディングを受けているうちに自分が成果をすでに出せる気になった」というのは、充実したオンボーディングがゆえの悩みなのかな?と感じました。

最初、おおひらさんの副音声を聴いてみたいと話していたら、まさかの主音声で笑いました。

「Fearless Change」と心理的安全性への旅

confengine.com

あれ、スライドは?と思っていたらそのまま45分(QAも含めると60分)怒涛の勢いで過ぎ去っていたすさまじいプレゼンテーションでした。

心理的安全性とFearless Changeってどういう関係だったっけ?と思って話を聴いていたら、そんなには関係していないという話があって笑いましたが、その中でも正確な知識(出典が明示的である知識)を組み合わせて話を作り出し、勘違いされそうな部分をはっきりと提示してくれていて、すごく面白かったです。

JaSST Tokaiでも同じテーマで話があるようで、ここではどんな形で語られるようになるのか、非常に楽しみです。

すぐに使える! システム思考を現場で実践するための3つのやりかた

confengine.com

システム思考に関して、自分はノータッチなので何も分かっていないのですが、議論の正解(いわゆる本質と呼ばれるようなもの)を見つけるのではなく対話のきっかけにするためのツールというのは意外でした。

発表後は、因果ループ図を使うと図をすべて見ないと理解できない状態になってしまうのが厳しいと感じる(考える負荷が高い)という話や学習コストが高すぎて始めにくいなどの感想戦もあり、学びが深まりました。

全体を通した感想

2時間近く同時視聴をしたこともあって、早速4本も動画を見ることができて大満足でした。(しかも3本は自分が見たいと思っていて公開を楽しみにしていた動画だったので、より嬉しかったです)

同時視聴の感想戦から、唐突にシステム思考の話が飛び出したのも面白かったです。

*1:理想的にはQAで聴いていたような話が聴いてみたかった

アジャイルカフェ@オンライン 第42回に参加してきた

agile-studio.connpass.com

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

会の概要

アジャイル実践者からの質問に対して、アジャイルコーチの天野さん木下さん家永さんが答えてくれるイベントです。

今回の質問は、「アジャイル開発での失敗談と教訓は?」でした。

会の様子

天野さんの失敗談と教訓

アジャイル開発に限った話ではないかもしれないということですが、インセプションデッキの「なぜここ」をやらなかったことにより、ステークホルダーが開発チームに対していいたい放題になってしまったそうです。

時間がなくても、自分たちがなぜここにいるのか?のスライドは飛ばさないほうがいいと実感したそうです。

家永さんの失敗談と教訓

テストの自動化を頑張っているという思い込みがあり、受け入れテストに書かれているようなテストが漏れ、重大なバグを出してしまったことがあったそうです。

このエピソードがあってからは、教訓として、レビューにステークホルダーを全員読んで受け入れ条件を必ず明瞭にすることを意識し始めたということでした。

木下さんの失敗談と教訓

POが途中で変わってしまい、経緯がよくわかっていないことやこれまでの進め方に馴染めないことでチームがぐだぐだになってしまうケースが何回かあったということです。*1

引き継ぎを、プロダクト/仕事/Devやステークホルダーとの関連性の観点から行うことを教訓としているということでした。

天野さんの失敗談と教訓その2

ふりかえりのファシリテーターをしたタイミングで、前の開発者がしていた見積もりに忠実に従っていたことで、プロダクトバックログにコミットメントしない人たちが生まれた失敗談があるそうです。

古いPBIが大量にあることがいけないので、在庫を作りすぎないこと(20-30が限界)を教訓としているということでした。

家永さんの失敗談と教訓その2

ワンチームでそれとなくうまくいっているチームができた後、そのチームのマネージャーの理想が高くなってしまい他のチームに対して以前より厳しく当たるようになってしまったことがあったそうです。

チームは違う特性があり、成長速度などを比較することはしないようにすることやうまくいったチームができた後2つめのチームを作るときこそ慎重に携わることを教訓として学んだということでした。

会全体を通した感想

失敗談から導き出される教訓が自分が想像していたものと結構乖離があったので、こういう風に失敗談を捉えるのか、というのを知れて学びが深かったです。

アジャイルラジオが爆誕していたのは笑いました。

*1:余談になるが、退職や定期異動、昇進によってこういうことが起こるということでした

大人のソフトウェアテスト雑談会 #184【猪鹿蝶】に参加してきた

ost-zatu.connpass.com

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

自己紹介(?)

今回おそらく初参加の方がいらっしゃり、自己紹介スライドを見ながらみなさんで話していきました。(転職を最近考えていることもあり、自己紹介スライドを作ったということでしたが、自己紹介スライドを持って自己紹介している人を見たことがないので、面白かったです)

以下のような話をしていきました。(大体の時間は映画の話をしていました笑)

裏のチャットでは、森さんの本棚の話や採用面接で聞いてはいけない質問の話(愛読書の話)などをしていきました。

改名騒ぎ

aki.mで長いあいだやっていますが、やはりspring_akiさんとかぶるということで、改名候補として色々な名が挙がっていました。

eki.mが人気だったようですが、丁重におことわりしておきます笑

全体を通した感想

自己紹介スライドを持ってきて、そのスライドをもとに話をしていくというのは新しいパターンで面白かったです。

スライドを作っているのもすごいですし、スライドをもとに多方面から話を突っ込んでいけるというのもすごいなあと思いました。