天の月

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

yr-learning Vol71に参加してきた

https://yr-camp.connpass.com/event/362198/

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

雑談

いつもどおりゆるりと雑談から話が始まっていきました。が、結局最後まで雑談していました笑

AIを信じすぎる人がいて、その人は他人が言っても聞かないけれどAIが言うと聞くみたいなことが起きるというお話でした。

また、開発生産性カンファレンスやその後のTDDyyxがめちゃくちゃ良かったという話をしていて、Kent Beckと会えたのが感動したし、t_wadaさんの講演を聞いてめちゃくちゃ良かったという話も出ていました。
TDDyyxはスタートからなんか異様な空気を感じて(やっとむさんやKiroさんやみほらぶさんや川口さんやt_wadaさんなどがいる)、これもしかしてKent Beck来るんじゃないの・・？となってたら本当に来たということでした。

www.youtube.com

上記の動画を生で聞いたり、テストの速さの重要性に関して力説するKent Beckの様子を見たり、RSGTにぜひ来てくれないかと勧誘している様子を見たりと、すごく贅沢な時間だったということです。

また、やっとむさんに関しては「すでに心のなかにKent Beckがいるから今からなにか改めて話そうとは思わない」と話していたようで、それはそれで面白かったそうですが、飲み会ではちゃんとKent Beckとめちゃくちゃ喋っていたということでした。

他にも、Kent Beckっぽいコードを書いてと生成AIに対して命令すると、本当にそんな感じのコードを書いてくれるんだよ、という話をKent Beckは言っていて面白かったという話を聞いたりしたそうです。

あと、冷静に考えるとどこもレジェンドみたいな人たちがうろうろしていて、Kent Beckがいなかったとしても大分おかしいチームだったということに気がついたと言っていました。

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

aki-m.hatenadiary.com

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

スポンサーメール返信

スポンサーからメールをいただいていたのでそちらに対して返信をしていきました。(今回はロゴの送付周りのお話でした)

最近定例会で必ずやるタスクとしてスポンサーメール返信は入れていて、一週間に一度になってしまうというデメリットこそあれど運営MTGの中で持続可能な形で返信できているのはいいことだなと思いました。

Keynoteスピーカーの更新

Keynoteスピーカーの情報をとりあえず趣意書で更新していきました。

ホームページに関しては、多くのカンファレンスだと自己紹介やこれまでの略歴みたいなのをかなりしっかり書いている印象があるので、Keynoteスピーカーのこれまでの略歴みたいなのを自分たちなりにまとめてみようと話したのですが、Keynoteスピーカーが自分自身でこういう風に自分をアピールしたいみたいな話もありそうだなと思い、一応聞いてみることにしました。

結果、カンファレンスのコンテキストに合わせた自己紹介を考えて欲しいというリクエストをいただいて、自分をアピールするみたいなつもりが一切ないんだなというところが分かりすごく良いなと思いました。

運営メンバーで回答が難しいメール対応

運営メンバー誰もが知り得ない情報があったので、分かりそうな人に対して質問をして、メールで確認するということをやっていきました。

結果返信が運営MTG中に返ってきたので、その内容をそのまま返信しました。

ドラフト会議の段取り決め

ドラフト会議当日は運営メンバーで集まってわいわいできると楽しそうだよねという話をして、当日都内で集まれる人だけ集まろうという話をしました。(それなりに集まれそうなメンバーも多かった)

遠方参加の方に関しては交通費は手当するとして、場所だけは決めてしまおうという話をし、会場予約だけしちゃいました。

レガシー産業で生成AIドリブンなプロジェクトをどう推進していくかに参加してきた

generative-ai-conf.connpass.com

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

会の概要

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

生成AI Confは生成AIのビジネスへの応用、及びそれを通した社会貢献を目的としたコミュニティです。
「生成AIのビジネスへの活用」をテーマに、実践ベースの体験や知見、ノウハウを幅広く扱います。

現在、急激に生成AIの市場が伸びており、特に日本においては政府も積極的に生成AIの導入を進めようとしています。 *参考　内閣府 AI戦略 - 科学技術・イノベーション

しかし、現状では特にデザイナーやPM、事業開発者視点での実践的な知見はあまり浸透しておらず、生成AIを活用したビジネスやサービスはまだまだ多くありません。

本コミュニティでは、エンジニアやマーケターだけにとどまらず、生成AIに関する豊富な知識や経験を持つデザイナー、PM、事業開発視点でもノウハウを共有し生成AIのビジネス活用を促進することを目指します。

会の様子

本イベントはパネルディスカッション形式で進められました。以下、テーマと内容を一問一答形式かつ常体で記載していきます。

レガシー産業でリープフロッグが起きるときの共通の条件とは？

  • 文章の生成というレベルだと現場のニーズにテクノロジーが追いついてきた印象がある
  • ゲーム産業の現場という意味だと、情報検索/文章構成/新しいものの生成というものがある。枠組みを作ればAIがやってくれるみたいなところがあるので、その分色々なことに手を伸ばせるようになったという話はある
  • 見立てと実績みたいなところをAIに設計させるのが難しかったというのがあり、個性化ができないというのはある。すごい賢いけれど中央値の人、という印象がある
  • 少人数のチームで大きなパフォーマンスが出せるようになる。また、20-30人くらいのPull Requestをすべて見ることができたりする

産業内の生成アレルギーをどうやって解消するか？生成AIに馴染みない組織や人材とどう向き合えばいいのか？

  • まず法律をいじる人は基本的なドキュメントツールがWordやExcelになる。AIフレンドリーなmarkdownにしたいのだがそれが難しい
  • AIのTPがあまりない人にどう接点をもってもらえるか？一度触りだすとAIをどんどん使うようになる
  • 4o出たあたりからどんどん使えるようになった印象がある
  • カジュアルな内容だったりくだらない内容をもっと発信できると良いんだろうなと思う
  • AIを触る以外はやらないという時間を作って、そこでやったことを各人が発信するようにしている
  • 最初はプロトタイプを作るところからスタートできるようになった
  • 絵を書いたりパラメータ設計したり細かいニュアンスを判断するというのは難しい印象がある。ユーザーからの問い合わせを定量化するとかはできる
  • AIがやる部分と人がやることを明確に分けるようにする
  • In/Outが明確化されているものは使いやすい印象がある
  • お問い合わせできた乱雑なコメントをいい感じに処理するというのがすごく上手になった
  • 単純なルールベースなのか？人間がやるべきところなのか？を見てみる
  • 軽く触れてさえいれば人がなくなるとかはないと思う

会全体を通した感想

あんまりレガシーに対してどうこうという話はされておらずどちらかというとフリートーク的なイメージを持ちましたが、一度触ってみるとそこから離れられなくなるというのは感覚的も非常にわかる部分なので、きれいな言語化がされているなと思いました。

AI時代のナレッジマネジメント最前線 - Obsidianではじめる、知の構築 -に参加してきた

https://findy.connpass.com/event/357742/

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

会の概要

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

生成AIの普及により、個人の知識管理の在り方が大きく見直されつつあります。 特に「Obsidian」のようなPersonal Knowledge Management（PKM）ツールは、AIとの連携を前提とした運用で再注目され始めています。

本イベントでは、「Obsidian」を活用した「自分に合った知識管理の方法」や「AI時代の知との向き合い方」を探るヒントをお届けできる場を目指します。

会の様子

増井さんの講演

Obsidianを使っていくうえで大切なのはふりかえりだという話がありました。(とはいえノート自体がまずないならそれはノートを書くことから)
ノートを書く際にはできる限り小さく作って階層ではなくタグで管理するということが重要だそうで、何も書いていない人はまずデイリーノートから作成していくのがおすすめだということでした。

このデイリーノートをSmart Composerでふりかえりするのがおすすめだということで、Dataviewでデータベース化すると更に効果が出てくるそうです。

説明のあとは実際にこれらのプラグインを使ってデモをしてくれました。

松濤Vimmerさんの講演

Obsidianはプラグインが非常に充実しているうえにAIとの親和性が非常に高いという話がありました。

発表では特にCoding Toolとの相性の良さに関して言及があり、CursorやClaude Codeと連携した例などの説明がありました。(並列実行で長文執筆や複数の文章パターン生成などができるようになった)
同期はGoogleDriveやGitHubと連携方式がおすすめだということで、MCPを使うことでObsidianプラグインを使わずに他ツールとの連携が可能になったのが最近のおすすめポイントだということです。

Q&A

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

階層タグの使い方をもっと教えてほしい

書籍なら著者、発売日、出版社などを使っている。あとは記事ならnote、エンジニアスタイル、gihyoなど

タグの規則性で工夫していることは？

タグの一部で検索できるので、特別なにかやるというよりはたまに見直すくらい。

フォルダの運用ガイドラインは？

作らない。

会社PCで利用したいと思ったときにはどうするといいのか？

商用利用は可能だが、共有という意味では難しいところがあると考えている。

会全体を通した感想

思っていたよりは大分初心者向けな内容でしたが、フォルダを一切作らないとか、Obsidianの良さを活かすために割と極に振り切るというのができるといいんだろうなあというのは感じました。

スクラムフェス金沢2025のスタッフ打ち合わせ(最終回)に参加してきた

今日はスクラムフェス金沢2025の最終回(ふりかえり)をしてきたので、会の様子と感想を書いていこうと思います。

情報保障

スクラムフェス仙台では情報保障に関しては業者に頼んでおり、その業者の方が専任で修正をするようにしているという話がありました。
それなりにお金がかかるということもあるのですが、スクラムフェス金沢の最終収支を見ると赤字にはならない範囲だったということで、来年やるならそのような手立てをすることも大切なんじゃないか？という意見が出ていました。

議事録

Discordでやっているとどうしても議事録を自動でとるみたいなことができないので、Zoomなどの併用も検討したいという話がありました。

タスク整理の仕方

優先度や順序性が分からないので、それなりにマイルストーンを立てたりとか、特に初参加メンバーに対してはもう少ししっかりと伝えられると良かったよね、という話が出ていました。

会場とオンライン

会場は音響という意味ではやや課題が出ていたものの、また会場を変えるというのはなかなか大変なので、次回は少なくとも変える必要はないのかな、という話をしていました。

また、オンラインはなかなか状況が見えてこなかったので、オンラインスタッフみたいな人がいても良かったんじゃないか？という意見があがっていました。カメラマンと同じように広く募ってもいいかもということでした。

オンラインはFBがあまりあがってこなかったというのも課題の一つとして出ていましたが、ネガティブなフィードバックが多数集まるような状況もあり得るのでそこは避けたいという話が出ていました。

スポンサーチケット

手間としては今回は前回よりも減ったものの、スポンサーチケットを他社に譲った場合に、「あれ、この会社ってスポンサーだったっけ・・・？」となってしまった節があったため。そこは来年以降どっちがいいのかを考えたいという話がありました。

次回開催時期

来年も同じくらいの時期でやれたらいいよね、という話をしました。

本格的な時期に関しては10月に決めたいという話が出て、スクラム祭りが終わったあとに一度皆で集まって11月には日程確定させたいということで決まりました。

また、次回のふりかえりはちゃんといつふりかえりするか決めておこうねという話をしました。

Claude Code Deep Diveに参加してきた

https://cartaholdings.connpass.com/event/360380/

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

会の概要

第一線でAI Coding Agentを使い込むエンジニアたちがClaude CodeにDeep Diveするイベントです。

会の様子

hiragramさんの発表

最初に.~/.claude/projectsの構造に関する話があり、シンプルな会話が行われているときに起きているJSON Lines形式の情報の紹介があり、ここ最近はコストがみえるPropertyがいつの間にかなくなっていたという話がありました。

その後は、複雑なタスクを指示したときにサブエージェントが何をどういう風に実行しているのか？という話があり、Slash commandや組み込みコマンドの紹介が出ていました。

パネルディスカッション

講演のあとはsuzu_vさんとt-wadaさんとmizuchiさんとhiragramさんでパネルディスカッションがありました。以下、内容を常体で記載していきます。

Claude Codeの使い方

  • ADRの作成によく使っている
  • 色々あるが、実装の下調べやアイデアの壁打ち相手として使っている
  • リファクタリングなどは幾つか案があるものなので、それを並列で検証するときに使っている。なお、検証するときはタスクの指示はスコープを少なめにする(Claude Codeは放っておいてもタスクを分割するということはない。分割の粒度まで細かくして自己プロンプティングのようなものをしている)
  • E2Eから読むようにしていて、内部のデバックなどはなるべく読まないようにしている
  • AIと共有する際に自動テストを書くとレビューできなくなる(どばっとテストが出てきてしまう)ので、単機能のRed/Green/Refactorを指示するようにしたり、テストケースの雛形を1件だけ自分で作るようにしている
  • 初期ボイラープレートから破綻するまでの速度がすごい速いので、破綻する前提で仕事を進めるようにしたりしている
  • Figma公式のMCPには期待している。FigmaのIssueを読み込んでもらうようにしているが、まだボタンの配置が指示とずれることはあるので、HTMLだけ自分が書いてCSS装飾はFigma見てみたいな感じにしている
  • 今の技術的制約なのかもしれないが、視覚的な解釈能力とかリッチドキュメントでドキュメントを使っている会社は不利になっている印象がある
  • Claude Maxは10万円くらい使っている人たちもいるし、コンテナ形式みたいなやり方(いいから全部作れって言って後ですべて捨てるみたいなことが平気にできる)もできるようになっている

Claude Codeの限界

  • 根本的な話をすると、プログラミング言語自体がAIフレンドリーになると良いと思う(素朴な弱点としてワードカウントができないとかがある)
  • コード重複をヒューリスティックに検知してゴリゴリコードを消すようにしている(意味的に異なるかどうかの判断はAIがやるし割としっかり残せる印象がある)
  • bashツールが権限強すぎるのでデータポイズニングされたときの対策が急務だと思っている
  • 普通それ知っているならこれできるよね、が通じないので、再現性のあるツール開発や人間が当たり前にやっているところをAIに教えていくというのが大切。明確な数字を与えるというのはすごく大事で、このラインを引くのはドメイン知識になってくる
  • 非機能要件や保守性に対するリフレーズなどが必要

「良いコード」の指示

グランドルールはCLAUDE.mdに基本書くようにしようと思っているが、ばっとAIが書いたことに対して自分がレビューするみたいなことをしている。

会全体を通した感想

めちゃくちゃわかるなーと思う話が多かったのですが、未来を見据えるというよりも今とにかく使い倒すみたいな感覚が強かったところは特に印象的でした。

これまで自分がやってきたことをどうAIにやってもらうのか？みたいな部分で考えることも元々は多かったのですが、話を聞いていて、リソース的な観点で到底採用できなかったやり方を実行してしまうというのもあるんだなあというのは聞いていて思いました。

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

https://agile-studio.connpass.com/event/358698/

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

会の概要

アジャイルコーチのお三方がアジャイル実践者から寄せられる悩みに答えていくイベントです。今日のテーマは「組織やチーム内で「アジャイル」への認識を揃えるための方法」でした。

会の様子

1on1やワークショップを実施

1on1やワークショップを実施して、アジャイルとはなにか？というのを聞いてみてどういうところがずれているのかを探っていくという話がありました。
ワークショップでは、アジャイルソフトウェア開発宣言を優先順位順で並べてもらって、そのうえで自分たちはなんでその価値観を大切にしているのか？やどういうところが自分たちの組織では適用難しいと思っているのか？といったところを話すようにしているそうです。(さらに5つめの価値を追加するなら？というのを聞いてみることもある)

ずれがあることを明らかにするという狙いや、お互いに何を大切にしているのか？というのを考えるようにする狙いがあるそうです。

用語のずれ

心理的安全性やスプリントゴールに代表されるように、一つの言葉でも全然違うイメージをお互いに思っているというのが多いので、そういうときになにか定義を共通で決めるという過程を大切にしていくのが良いのではないか？と考えているという話がありました。

また、そういった言葉へのこだわりはアジャイルが好きな人ほど強い印象があるそうで、そういう人ほど他の人の考えに耳を傾けて欲しいということです。

アジャイルへの認識を揃えないほうがいいのでは？

今回の問いのたて方はアジャイルに関して組織やチーム内の対立を招きやすいという話があり、チームの中で話をしながら組織で納得できるアジャイルというのを考えていくのが良いという意見がありました。

タイムライン

アジャイルの認識を揃えるという話ではないかもしれないけれど、タイムラインの形でそのチームの歴史を残していくというのは、盛り上がりもするしこれまでの話をナラティブに伝えていくというメリットがあるというお話がありました。

組織でアジャイルの認識を揃える方法

社内コミュニティや勉強会、社内交流会といったものを活用して、そこで議論するのが良いという話が出ていました。

チームが全然違うなら、アジャイルに対する期待や認識が違うのは全然いいことだし、孤独になりがちなスクラムマスターやアジャイル実践者がつながる事例ができるというのもすごく良いことだということです。

会全体を通した感想

テーマを聞いたときに、そもそも危険な匂いがする考え方だなあと思っていたのですが、そのあたりにもしっかり触れられたうえで、共通認識を作ることよりもその過程を大切にしているという話が聞けたのがすごくよかったです。

手法へのフォーカスというよりはプロダクトだったりへのフォーカスがもっと強くなっていくといいなあと思いました。