天の月

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

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

https://ost-zatu.connpass.com/event/339611/

葛飾例大祭

いよいよ葛飾例大祭が開催されるということでその話をしていきました。

  • 実は一番長いオンライン区長のお言葉
  • keynote4本立て
  • 昼休憩なし
  • Youtube?で中継される可能性あり

が見どころだということです。

テスト系のイベント

やまずんさんが主催しているものを中心に、テスト系のイベントがいくつか紹介されていました。

warai.connpass.com

over-30-start.connpass.com

Tokyo Test Fest - 日本で毎年開催される、ソフトウェアテストの国際カンファレンス

オンライン勉強会

オンライン勉強会のおかげで勉強会に参加しやすかったという話や、オンライン勉強会が普及していることが原因でまだ対面では一度も会ったことがない人たちがいるという話をしました。

このテストの街葛飾でも、毎週のように話しているけれども対面では会ったことが一度もない人というのもいるので、不思議な限りです。

JSTQB

Advanced Level Specialist テスト自動化エンジニアの資格を持っているからといってテスト自動化ができるわけではないという話や、テストアナリストの資格を持っているからと行ってテスト分析が上手なわけではないという話が出ていました。

ただし、必要最低限の知識があることは証明できるかもしれないという意見も出ていました。

デシジョンテーブル

デシジョンテーブルの見やすさを追求してしまうことで陥る罠だったり、手法としての厳密性を追求してしまうことによる罠だったり、デシジョンテーブルをどういう目的で使うのか?という話だったり、色々と盛り上がっていました。

zenn.dev

sqripts.com

www.kzsuzuki.com

状態遷移テスト

状態テストに゙関しては何を状態と定義するのか?という話で盛り上がるという話がありました。一応定義自体は古典(?)にはあるものの、これが正しい定義なのかはよくわからないということです。

全体を通した感想

今回は久しぶりにはじめましての方*1がいらっしゃり、いつもとは異なる雰囲気で盛り上がりました。

特にテスト周りの話がガッツリ出ていたのは興味ふかい内容ばかりで面白かったです。

*1:ただし4年ぶりくらいの参加ということで超古参勢でした

スクラム祭りの打ち合わせ(16回目)をしてきた

aki-m.hatenadiary.com

こちらの打ち合わせをしてきたので、会の様子と感想を書いていこうと思います。

HPを直す

今日は最初二人しか参加者がいなかったので、もともとやる予定だったふりかえりはやめて、XP祭り運営の直近の様子(ちょうど今日忘年会だったらしいです)をゆるゆる話しながらHPを直していました。

  • VenueのところにScheduleが記載されているのがよくわからなかったので場所を移動しました
  • sessionに関して言及されているセクションが複数あったので一つのセクションにしぼり、他のセクションからはSessionの言及を消しました
  • Sessionなどを記載するセクションに関しては、しばらく更新することができないですしkeynoteは1つだろうし、あんまり意味がないので消すことにしました
  • モバイル版とWeb版それぞれで、セクションの幅を微調整しました

keynote検討

HPを直している最中に、そういえばkeynoteどうするんでしたっけ?という話になり、やることは決まっている&最優先で作りたかった趣意書とHPはどちらも外部公開できるようになったにも関わらずまだ実は何も話していないということに今更気が付き、検討を始めました。

今日のところはとりあえずby nameでこのひとにkeynoteをお願いしたいというのを一旦ブレスト形式で出してみて、そこでなんでその人にお願いしたいと思ったのか?というのを改めて書き出してみながら、どんなスクラムフェスにしたいのかやどんなkeynoteをお願いしたいのか、というのをその人の名前から言語化していきました。

候補者自体は10人以上出てその中でも特にこのひとにお願いしたいというところまでは話がいったので、あとはもう少しどんな話をしてほしいのかというところを言語化しつつ、一定のところまでいったらその人も交えて話して欲しい内容をその人に直接伝えてみてその人から意見をもらったりしながら話を組み立てようということになりました。

子育て1年半のふりかえり

子育てエンジニア Advent Calendar2024に投稿しようと思っていたら登録ミスっていてできていなかったので、投稿予定だった記事の供養です。

adventar.org

子育てして1年半くらいした現断面でのふりかえりとして、子供ができる前の生活と比べて、続けていること/減らしたこと/やめたこと/始めたこと/増やしたことをそれぞれ書いてみます。

続けていること

ブログ

このブログは子供ができてからも継続して続けています。
何かしらの変化が計測しやすかったり外部からフィードバックがもらいやすいことを理由に、外から見れるものかつ自分の中で継続して積み上げているものというのは一つでも継続しておきたいというのが個人的にはあって、その機能として継続している側面が強いです。

Writing code every day

こちらもブログと似ている側面はあるのですが、こちらに関しては最近だと毎日コードを書いてみることで、その日の自分の調子を見極めるためという側面が強くあります。

ただ、もともとはt_wadaさんのスライドを見てエンジニアとしての研鑽を目的に始めたものなので、その時から比べると続けるモチベーションやコードを書く題材の選び方は変わっている印象があり、優先的に見直したい習慣の一つになっています。

減らしたこと

コミュニティ活動(参加)

コミュニティに参加者として関わる回数は20%くらい減らしました。(1000回/年→800回/年)
色々知識や経験が増えてきたことで自分が続けたりしている他の活動に比べて頻度を継続する意義があまり感じられなかったことと、オンラインだとどうしても片手間参加になってしまうしオフラインだと家族の都合がつけずらいという理由から参加するモチベーションが減ってきたことが理由になります。

読書する時間

こちらも子供の面倒を見ながらという意味だと大きく効率が悪くなってしまううえに、読書している最中とかに子供がなにか危ないことをしたりしているのが何回かあってからは子供が心配になってしまって読書どころではなくなってしまったのが理由です。

現在は子供が寝た後や会社の通勤時間など、子供と完全に隔離された状態が作れた時のみ読書をするようにしています。

やめたこと

毎日のふりかえり

ふりかえり自体に意味はあると思っていたのですが、子供や家族が体調不良だった日や子供の面倒に思いの外時間が取られた時にふりかえりをすると、罪悪感や焦燥感のようなものが多々出てきてしまい、あんまり良くないなと思ってやめました。

パーソナルコーチン

じっくり一人の時間をとるというのが難しくなった関係で各セッション後の宿題に取り組むことがなかなか難しくなったことが理由で一度距離を置くようになりました。

意義を感じられなくなったわけではないので、今後復活させる可能性は高いです。

始めたこと

運動

体調を崩せない状況に常に置かれているのと、ストレスからか食べる量が増えてしまったことがあり、健康を維持するために運動をすることにしました。自重トレーニングや、子供が寝たり家族が子供を見てくれている時間に走るようにしています。

コミュニティ活動(運営)

自分のペースで自分がやりたいことをやりやすい勉強会を立ち上げました。
自分のために作っている勉強会ということもあり、あまり大きく宣伝したりはせずに細々とやりたいことをやっています。

増やしたこと

家族と過ごす時間

ここは言わずもがなかもしれませんがめちゃくちゃ増えました。
以前よりも夫婦で話し合う時間も増えましたし、子どもとなにか一緒に遊ぶ*1時間も増えました。

今しかできない時間だということを噛み締めることで、勉強や仕事ができていないという焦燥感のようなものは以前に比べると大分減りました。

カンファレンス登壇

カンファレンス中は家族旅行を兼ねるようにするというメソッドを使うことで、家族との調整が非常につきやすくなり、以前は自重していたり選んでいたカンファレンスでも登壇が増えました。

*1:といってもまだ子供は遊んでもらっているような感覚は持っていないでしょうが...笑

AIロボット・完全自動運転 開発の魅力と課題 - Jizai石川さん、Turing山口さんに聞く!に参加してきた

findy.connpass.com

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

会の概要

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

本イベントは、株式会社Jizai CEO 石川さんとTuring株式会社CTO 山口さんのお二方をお招きするイベントです。

ロボット開発や完全自動運転の実現に向けて、ハードウェア×LLMの開発を進められているお二方から、最新技術への取り組みについてお話しいただきます。LLMやハードウェアの効率化をはじめとした、開発における面白さや課題等の実態、SaaSのようなソフトウェア開発とは何が違うのかといった知見をご共有いただく予定です。

会の様子

Jizaiが進める生成AIプロダクト開発のご紹介

少子高齢化労働力人口の減少への課題に対応するために、

  • AI Solution / AI SaaS事業
  • 企業向けAIロボット事業
  • 新AIロボット開発

といった事業をしているという話がありました。

Turing株式会社が取り組む自動運転・生成AI開発について

Turing株式会社は完全自動運転(自動運転のLv5)に取り組んでいるという話があり、具体的にはE2E自動運転や走行データセットの整備、視覚・言語モデルや運転に特化した動画生成モデル(生成的世界モデル)といった話がありました。

パネルディスカッション

セッションの後はパネルディスカッションがありました。以下、テーマと話された内容を一問一答形式かつ常体で記載していきます。

ハードウェアに大規模言語モデルを搭載するためには?
  • 試行錯誤の途中ではあるが、実現したりするためにはGPUを自社で作ったりする必要があるのが分かっている。ただし、自社でどんどん開発していくようなやり方だと、どうしてもGAFAの参入で負けてしまったりすることもあるので、そこは難しい
  • LLMをそのまま使うと低レイテンシー要求に応えられなくなってしまうため、色々なモデルを組み合わせていくような形になっている。例えば、生成AI単体でやるのは難しいので、高速モデル+賢いモデルを組み合わせするような方法を取っている
  • ハードはプリミティブなエリアなので、研究投資がまだまだ必要なところが多いとは思っており、ある種のベストプラクティスがあるものではなく、それぞれがそれぞれのアプローチで問題を解こうとしている領域だと考える
ハードウェア開発ならではのAI開発の面白さや課題
  • スタンドアロン前提になるので、レイテンシースループットの部分が課題になってくる(0.5秒遅れたら話にならない)
  • どこまでクラウドに逃がすか?というのが大切
  • デザインの幅が無限大であり、実体を持たせることで初めて価値を作れるみたいなことがある
  • 高度にやろうとすると色々なパーツを突き詰めていきたいのだが、やりすぎると顧客が買えなくなってしまう(価格とのトレードオフがある)
AIのブラックボックス問題に対してどう対応するのか?
  • お客さんが気にするところは中の詳しい部分問いよりも事故率だったり外の部分になるので、そんなにAIを使ったことが原因で何かという印象はない
  • 安全性担保に゙関してはAIであろうとそうでなかろうと基準遵守を必ず行う

会全体を通した感想

具体的にはさすがにかけないのですが、現在仕事で取り組んでいる内容との親和性も結構ある話だったのでイベント参加前に期待していたそこが聞けたのがまずはよかったです。
特に、ハードだからこそデザインの幅が広がりそこが面白くも難しくもなるというのは、個人的に印象的でした。

一方で、セッションに関しては企業紹介の色が少し強くて、あんまり今回の会のテーマが伝わるような話が少なめだったのは気になりました。

部門の垣根を越えて挑む業務改善のリアル - Encraft #20に参加してきた

部門の垣根を越えて挑む業務改善のリアル - Encraft #20 - connpass

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

会の概要

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

コーポレートエンジニアや情報システム担当が、業務効率化を横断的に推進するためには、当然のことながら他部門の協力をどう得るかが大きなポイントになります。しかし、他社がどのようなアプローチで連携を進め、効率化を達成しているかを知る機会はなかなかありません。

そこで、第20回目のEncraftでは「部門の垣根を越えて挑む業務改善のリアル」に焦点を当てます。ナレッジワーク、ビビッドガーデン(食べチョク)、Helpfeelのコーポレートエンジニアが具体的な取り組みを紹介。プロジェクト推進の過程で生じた課題や学びを率直に語ります。

会の様子

セッション1〜コーポレートデータマスタ構築への道〜

スタートアップ企業ではMDMが不在になりがちで、徐々にサイロ化や工数負担を生んだり自動化ビリティが損失されていきがちだという話が最初にありました。
これはそれぞれの部署の視界や関心事が違うがゆえに発生するということで、こういったときにコーポレートITだからこそできる話があると感じたということです。

そこで実際にコーポレートマスタを構築していったそうですが、そこではまずインセプションデッキで関係者との認識合わせをしたうえで、具体的なメリットや活用シーンをイメージしてもらえることや正確なデータを投入することに気をつけたそうです。

結果的に、プロセスが整備され手作業で仕事をしていた業務の自動化が促進されたそうですが、効果を定量的測定するというところは今後の課題だったということです。

セッション2〜情シスいらずで部署・チームが主体的に業務改善を進める世界線を作りたい話〜

「人と組織」にフォーカスすることで、部門やチームが主体的に業務改善を進めるためにやってきた取り組みの紹介がありました。(なるべくお金をかけないかつ持続的な改善組織を作りたかった)

具体的な取り組みの進め方として、以下の話がありました。

  1. 現状把握 : オペレーションを実際に体験し現状の苦しみを実感する
  2. 現状分析→課題特定 : 現場にヒアリングして部署ごとの業務特徴を掴み、ボトルネックを見つける。このとき、できる限り潜在的な課題にアプローチする
  3. 施策実行 : データ基盤の作成や研修の実施を継続的に実行する

特に、非効率業務に関しては実際にそれを見つけた後に体験し、改善を回すようなサイクルを作ることが重要だということで、みんなとの関係性を構築するうえでも欠かせないステップになると考えているということでした。

セッション3〜新機能をリリースするだけ、で終わらせない!「触ってもらう」から始める他部署業務効率化のはじめ方〜

Helpfeel社で実際に行っているWD向けに改善した機能を試してもらう会の紹介がありました。(Helpfeel社ではWDの人数が増えていく中で、機能に関する期待と現実のGapが生じやすくなってリリースまでの速度が遅くなることを課題に思っていたそうで、このような会を始めたそうです)

実際にやってみると、FBが直接もらえるというメリットの他にも、開発部とWDの機能利用に関する認識齟齬がその場で解消されていったことによる関係性強化や機能の理解度向上があったそうで、やはりユーザーの実際の声を聞いていく重要性を改めて実感したそうです。

パネルディスカッション

講演の後はパネルディスカッションがありました。以下、テーマごとに話されていた内容を箇条書きかつ常体で記載していきます。

組織全体で改善意識を共有・醸成するために工夫したことは?
  • 情シス以外に主体的に業務改善するメンバーを増やす(Slackとかでテーマをさりげなく放流する)
  • 期待に対する熱量に付き合い、実際に改善できるということを実感してもらう
  • 他部署で困っていることがある、という事実を知ってもらう
  • 個人的に始めて、うまくいった事例を周りに共有していく
小さな改善を大きな改善につなげていくために必要なことは?
  • 出入り自由なZoomを定期的に開くようにしている
  • 他部署の業務内容を理解して現場の声を聞く
  • まだその部署の仕事に慣れていないような人にインタビューして、なにか困ったことがないのか?をインタビューする
業務改善の効果はどのように判断しているのか?
  • 1時間あたりの売上/人
  • 手探りでありまだ決まっていない(定量的な判断が難しい)
部署横断の業務改善の醍醐味は?
  • 異なる視点の部署と話すことになるので、こんな仕事あるのか!みたいな発見があるし、他部署と仲良くなることで自分が苦手なことやその人が得意なことを利用できるようになる
  • 会社が変化している様子を目の当たりにできる
  • 少ない時間で高い効果を出す方法を考えること
KGI/KPIは?
  • まだ納得いくものが置けていない
Zendesk内のExploreよりもZendesk API × BQを使った理由を知りたい

どう集計しているのか?みたいなところの解像度を上げたかったのと対応が必要なドキュメントの数が大きくてカスタマイズ要素が必要なニーズが強くあった

業務フローの作図には何を使っているのか?
  • 箇条書きとかmermaid記法とか
  • Miro
  • Notionでmermaid
ガバナンスを利かせるための観点をどれくらい意識しているのか?

ガバナンスという言葉が広い気がするが、非生産的業務にはガバナンスが効いていないと思っているので業務改善をしていけば自然とガバナンスを強めることになると思う

改善意欲がない人からの「やって」にどう対応するのか?

どこで詰まったのか?を聞くようにしている

会全体を通した感想

タイトルから想像していたよりも人数規模としては小さめの事例だった(100人以下)のは少し驚きましたが、言葉としてよく聞く課題感みたいなところは大規模とそこまで変わらないというのが面白いなと思いました。

個人的には、非効率な業務はいきなり改善するのではなくまず自分で何回かやってみる、というのは自動化なりを検討する上でよく取りがちな戦略だったので、そこでもう一歩踏み込んで関係性構築までつなげていくという考え方は自分にとって実践しやすいな、と思いました。

【学生向け】HireRoo が作ったコーディングテストを freee のエンジニアが受験してみるに参加してきた

freee.connpass.com

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

学生ではないのですが、シンプルにコーディングテストの経験がない(と思っていた)のでどんなものなのか気になったのと、企画自体が面白そうだなと思ったので参加してきました。

会の概要

エンジニアを目指す学生なら 1 度は通るコーディングテスト。いざ受けるとなるとどんな問題が出るのか、どんな感じで回答するのか不安になる学生も多いのでは思います。

このイベントでは HireRoo さんが作問したコーディングテストを freee にて新卒採用面接官の経験もあるメンバーが実際にその場で受験し解説を行います。

会の様子

イントロダクション

一般論としてコーディング試験とはどういうものか?という話がありました。

  • 選択・自然文記述式の知識問題
  • プロジェクト形式の実装(ディスカッション含む)
  • 課題解決方法の提示
  • 設計図をその場で書く

といった多様な形式があり、正解といえるコードを書くことがゴールだということです。
コーディング試験はスキルのマッチ度だけではなく、プロセスを見ることで技術課題に対してどのような姿勢で向き合うのか?(楽しめるのか?)といったところも見れるため、有効な試験とされているということでした。

また、その後にコーディング試験は、

  1. 問題理解
  2. 解決の類推
  3. 方針検討
  4. 解答コードの実装

という基本的な流れを抑えて準備をすれば決して怖いものではないという話がありました。
(よくあるアルゴリズム試験を例とした)準備の具体的な方法としては、まずは有名なアルゴリズムやデータ構造を理解したうえでLeetCodeやAtcorderの問題を解いて実践を繰り返し、実世界のコードへ応用することが重要だという提案も出ていました。

コード面接を実際に解いてみる

続いて、実際にコーディングテストを受験してみる様子が公開されました。

  • まずはコメントベースで処理を書く
  • 最初は再利用性を意識するのは最低限にして、問題のハッピーパスを実現するために愚直なコードを書く
  • 入力例を見つつ図に落としながら問題解決方法を口頭で説明する
  • インターネットを検索することは自由なため、仕組みだけキーワードとして覚えておいているものであれば、細かい実装の仕方などは調べることで対応する
  • 用意されているテストは回せない

といった点が特に印象的でした。

結果ふりかえり

結果は見事満点でした。評価は今回のケースだと、(あらかじめ用意されていたテストケースの)正解率+パフォーマンス+コードの可読性で評価されていました。

会全体を通した感想

もともとはコーディング試験を受けたことがないと思って受けていたのですが、技術課題に対して向かう姿勢を見るために、何も知識も経験がない状態でプログラムを構築してみようとした試験を新卒時代に受けていたのを話を聞いている最中に思い出しました笑

態度を見ているという話を聞いて、そういえば何もプログラミングの知識がない状態ではじめてコードを書いた時にこんなことができるのかと感動したなあというのを思い出し、そういうのが自分から出ていたのを当時の採用担当の人は見ていたのかな?と初めて感じました。

当初想定をしていた参加目的とは少し逸れた体験になったのですが、プログラミングが純粋に楽しくてやっていた頃を思い出したりして、ここ最近なにか失われている感覚や自分の原点みたいなのが回想できる恵まれた機会になったので参加して良かったです。

yr-learning Vol45に参加してきた

yr-learning Vol45 - connpass

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

今日は実際のお題でモデリングをしてみることにしました。

codingdojo.org

イベントストーミング

とりあえずイベントストーミングをしてみました。
正規手順と少しズレている所はありますが、以下の手順で今回は実施しました。

  1. イベントを洗い出す(洗い出している最中に出た仕様に関する疑問は一旦Parking lotへ追いやる)
  2. イベントを並び替える
  3. 並び替えたイベントの間にリードモデルとポリシーと集約とコマンドを空の状態で配置する
  4. コマンドを記入する(イベントを現在形に直す)
  5. ポリシーを記入する
  6. リードモデルを記入する
  7. 集約の候補を考える(ここで時間切れになりました)

結果は以下の通りです。

ふりかえり

実施してみたうえでふりかえりをしていきました。以下のような意見が出ていました。

  • 今回のお題はシステムと言うより一つの関数レベルな感じがあって、イベントストーミングの効果を実感しにくかった。FizzBuzzをイベントストーミングしているみたいな感覚
  • イベントストーミングの手順みたいなところはなんとなく掴むことができた
  • コマンドをなぜ洗い出す必要があるのかが今ひとつわかりにくい
  • 集約はユビキタス言語になっていくようなイメージが湧いた
  • 複数人でやる効果を実感しにくかった。お題を見ただけでみんな処理のイメージができるような状態だったからかもしれない

Next Action

もう少し理解がずれそうなお題が良いのでは?という話になり、Trading Card Game Kataでリベンジしてみようという話になりました。