コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『Kaigi on Rails 2026』に行ってきたよメモ

今年は2日目だけ参加なので、見たやつメモです。

各発表の感想

※資料スライドは見つけたら貼ります。


I want both

感想

  • まつもとさんのRuby、Spinel、roundhouseの話
  • この大AI時代になると利用する言語が淘汰されていく未来をDHHが示してしまったので、それに対するRubyの父としての現状のような話だった。
  • 商売にRailsを使わせてもらっている人間としては頭抱える話だったが、多分避けられない問題なのでみんなの動きをウォッチしながら動かないといけない

関連リンク


作れる、でも消せるか?──安全に「枯らして消す」機能削除術

感想

  • 機能削除に関しての消し方ステップの話
  • 実例交えつつの話だったので、どのアプリケーション開発でもためになりそうな話でした。
  • 自分も最近同じようなことをやったな...と思ったので雑にメモを書いたりしました。

関連リンク


Zen and the Art of File Upload Maintenance

感想

  • CarrierWaveで遭遇するつらみポイントにどう向き合って来たかの話
  • 自由度が高いゆえに変なことがおきる、勝手にやってくれる部分があるのでそこがネガティブに働く、などEasyに仕上げたライブラリならではの痛みだったなと感じた
  • 割と踏むことは多そうな話題も多かったので、遭遇したら読み直したい資料だった

関連リンク

Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜

感想

  • 大量データに対しての向き合い方の事例
  • こうしたほうがいい!というようなタイプの話ではなく、こういうやり方で解きましたよという話
  • 題材がわかりやすかったので、どう解くといいかの訓練としてもよさそうな話でした。

関連リンク

その Valkey 使いこなしていますか?

感想

  • Redis改めValkeyのValkey自体が備える機能でアプリケーションに活用する話
  • ランキングの話などはソシャゲで活用していた事例などを思い出し懐かしくなった
  • Redis側に渡すことで境界を作るというのはいいアイデアだったのでフルマネージドサービスと比較して検討してもいいかもとは思った

関連リンク


3回つくってわかった、定期実行ジョブ基盤の本質情報

speakerdeck.com

感想

  • 定期実行ジョブを繰り返し実装して、何を考えるべきかという話
  • 「やりたいことは2時に動いてほしい、というだけなのにそれ以外に考える事が多い。なのでその部分を吸収してあげる」という話は納得感があった
  • この部分をどうやって定型化するかはドメインによって違ってくるので、だんだんそのあたりもフレームワークというよりかは各社LLMでハンドメイドしていくのかもなぁなどと思った。

関連リンク


Web Framework Benchmark Battle 2026, Any%

感想

  • 時代に振り回されている話
  • 今回のカンファレンスで一番感銘を受けたし、昨日までの話でRailsを使い続けることに気持ちが揺らいでいたがそれをニュートラルに戻してもらえるような発表だった。
  • 自分はテクニカルな出自ではないので、何も協力できることはないかもしれないが、何か支援できることがあればしたいと強く感じた。

関連リンク

全体を通しての感想

  • 9月ぐらいまでは、RailsとRubyは「理解のしやすさを保つ」という意味で最良の技術選択肢にはまだなるのかなと思っていました。だが先日のDHHの話から世界が変わってしまい、どうなるんだろうという気持ちをぼんやりもっていました。
  • そんな中で「RailsやRubyのコミュニティとしてはその世界を受け入れつつも、リアルワールドでどうにかしていく方法を模索している段階」というのがキャッチアップできたのが今回の一番の収穫だったのではないかなと思っています。
  • 話のバラエティとしても「Webアプリケーションの話」「Railsの素地を活かした開発の話」も聞けたし、技術に深く突っ込んだ話もあり、とても良かったと思います。
  • 私自信はTech寄りの話はあまりできないので、Webアプリケーションの話としてもっと喋れるように次回は頑張りたいなと思いました。
  • 懇親会の体験が過去最高に良く、話こんでいても料理を巡回してくれる人がいたのがとても体験がよかったです!運営の皆様お疲れ様でした!

Kaigi on Rails 2026 過去登壇勉強会で「入門『状態』補遺編」という内容で登壇してきました。

Kaigi on Rails 2026 過去登壇勉強会 - connpassで話をしてきたので登壇後記です。

発表したスライド

speakerdeck.com

登壇後記

  • 過去の登壇になぞらえたやつをお願いします!ということで喋ってきました。
    • たまたま有給期間中なので、つくる時間を確保できました
  • 以前の補遺編 の部分を肉付けする形で喋りました
    • 状態論 (1) | lacolaco's marginalia が話のベースにはなっています
    • ただ当時と情勢(主にLLM周り)が変わりすぎていたのでそのあたり考慮したないようにリアレンジ
    • ステートマシンまわりの話みんな食いつきがよかった
  • 他の人が割と当時の話と今年のKoRに絡める話をしていたのでちょっとそういうパート入れればよかったと反省...

大吉祥寺.pm 2026で「それでも、技術なブログを書く理由」という内容で登壇してきました。

「大吉祥寺.pm 2026」で喋ってきたので、その登壇後記です。

発表したスライド

登壇の背景

表題の通りなのですが、私が技術ブログを書いてきた背景と私が見つけた切り口を場に出すことで筆を置いていた人がまた再開してほしいなーという気持ちで発表しました。

また、大吉祥寺にあつまる人たちは特定の技術スタックではなく様々な人がいるので場にもフィットするかなと思いセッションに応募しました。

補遺編

  • 実際にアクセスログもなだらかに低下しており、投稿数の削減が起因してるのかAIの台頭が原因かはわかっていないです。ただ技術Tips系へのアクセスは減っている気がしているのがそのあたりはオミットしました。
  • 自分自身技術系の記事をかかなくなってからなんとなく物覚えが悪くなっているのでプロテジェ効果は実際にあるのだろうと思っています。
  • 575のパートで止めて終わりにしようと思ったのですが、技術記事を書く技術の良さを伝えたかったので1枚追加してしまいました。
  • ちなみにプロテジェ効果の元ネタはt_wadaさんの対談動画なので、こちらもオススメです。

登壇後記

LTだけど記念品もらえた!嬉しい!

— しんくう (@shinkufencer.bsky.social) 2026-07-25T08:46:00.222Z
bsky.app

  • 実は仕事と私事がとんでもなくバタバタしており、話すテーマはしっかり決まっていたのですが、開催日当日も調整をしてしまったのですごく反省。
  • トップバッターだったのですが、他の人のLTがそれぞれ光まくっていて、最初で本当に良かった。
  • 当日のランチイベントでブログを見たことある人と喋れたので、実際に読んでくれている人がいて嬉しい気持ちになりました。
  • 会自体の感想でも書きましたが、LTとはいえ2024年の大吉祥寺から参加している側からすると登壇できたことはとても嬉しかったです。
  • 私のブログ執筆におおきく影響を与えているお二方からも言及していただき、思わぬ角度で感想いただけてびっくりでした。

関連リンク

『技術記事を書く技術』を読み終わったよメモ

読んだ本

読むきっかけ

自分自身も技術メモとしてこのブログを書いてきたのですが、モチベーションが下がっているなかで、改めてブログを書くことについて見直したいと思っていました。そんなところで発売の報を聞き、RubyKaigiでご本人のサイン会があったこともあり、購入させてもらいました。

本について

自分がRailsを深く知るきっかけとなった、Everyday Rails - RSpecによるRailsテスト入門の訳者でもあり、プロを目指す人のためのRuby入門、いわゆるチェリー本の著者でもある伊藤さんの新作です。

タイトルの「技術記事を書く技術」にあるように、ITエンジニアでアウトプットをしてみたいという人のための本となっています。

読後の感想

自分が普段無意識に気にしていることが言語化されていた

全編を通して感じたのは、自分が普段書いている技術Tipsで意識していることが言語化されていたことです。

具体的な例として、自分はTips記事を書くときに、どのような環境や状態で検証したのかを書き残すようにしているのですが、その点についても書籍内で触れられていました。

個人的には、見出しについてぼんやりと意識していたことが、きちんと理屈立てて説明されており、大変参考になりました。

押さえておいたほうがいい鉄板の事項が具体的に書いてある

アウトプットに関するガイドとなる読み物はたくさんあると思うのですが、この書籍の特徴は、2026年現在から始めるうえで気をつけるべき部分が具体的に記載されていることです。

例えば、Qiita、Zenn、はてなブログなどのサービスを使うときに気をつけるべき事項が、手厚めに書かれています。内容としては変化の激しいトピックなので、今だからこそ活きる部分はあるかもしれませんが、これからアウトプットを始めてみようと思っている方には、具体性があって良いのではないかと思っています。

また、最後には実際の記事をもとにした添削例のパートがあるので、その部分も実践的に読めるのではないかと思います。

書き始めたい人にも、これまで書いてきた人にもオススメ

「アウトプットっていうけど、どうやって始めればいいかわからない」という人は冒頭から読んでいくと良いですし、普段技術ブログを書いている人でも、「なるほど、こういうふうに考える切り口もあるのか」という発見があると思います。私自身も、書き方について改めたほうがいいと思う部分を発見できました。

まだアウトプットの型が決まっていない人にとっては、最初にインストールする雛形のような情報として、既に自分なりの型がある人にとっては、その型をアップデートするための材料として使える本だと思っています。

関連リンク

『ひとりひとりが頑張りすぎない、成果を出すプロダクトチームの動き方』に行ってきたよメモ

『ひとりひとりが頑張りすぎない、成果を出すプロダクトチームの動き方』に参加してきたのでそのメモです。

各発表の感想


堅牢でスケーラブルな働き方を構築する技術

感想

  • 書籍からの「堅牢」で「スケーラブル」な働き方の話。
  • 自己管理できるメンバーがいるとチームも自然にそうなっていくという話。
  • 外からの不確実性を減らす話は自身のチームでもやっているので効果があることはかなり実感できていた。
  • 自己管理できるメンバーを増やしていくのも大事だが、チームのカルチャーを守るのも大事というのはすごく大切な考え方だなと思った。

関連リンク

パネルディスカッション

メモが取れた部分だけまとめています

疲れ切ってしまう前に、自分の状態を知る

最初のテーマは、「もう疲れちゃって 全然動けなくてェ」という状態に陥らず、機嫌よく働き続けるにはどうすればよいか、というものだった。

疲れを予防するためには、自分がどのようなときに疲れるのか、疲れてきたときにどのような兆候が表れるのかを知っておくことが重要だという。

たとえば、疲れて帰宅したにもかかわらずSNSをだらだらと見続けること、普段は楽しみにしているものを楽しめなくなること、「これをやらなければならない」「誰かに怒られるかもしれない」と他人の目を過度に気にすることなどに陥ると危険で、完全に疲れきってしまう兆候として挙げられていた。

そうなる前にどうなると疲れてしまうのかの分析をする必要がある話がされた。その中で自分の感情や状態を把握する方法としては、内省する時間を取ることが紹介された。一日の中で感情がどのように動いたかを振り返り、「なぜそう感じたのか」を考えるとよいとのことだった。

同じ出来事でも感じ方は人によって異なるという。出来事と感情が直接結びついているのではなく、その人の価値観や過去の経験を介して感情が生じているためだと説明されていた。感情が動いた理由をたどることで、自分が大切にしている価値観や、疲れにつながりやすい状況を知ることができるとのことだった。

自分で仕事のハンドルを握る

疲れにくく働くためのもう一つの観点として、「自分でハンドルを握る」ことが取り上げられた。

仕事では、上司から指示を受けたり、あらかじめ決められたタスクが渡されたりする。そのような環境で、どのように自分がハンドルを握ればよいのか、という疑問が示された。

議論では、上司の指示に従うだけでは、最終的に自分を守ることはできないという話があった。自分の給与がどこから生まれ、会社がどのような働きに対して対価を支払っているのかを理解する必要があるとのことだった。

上司の期待に応えることが対価を貰う方法と捉えるのであれば、その期待を把握したうえで、自分がどのように貢献するかを考える必要があるという。一方で、そこまで考えても自分の働き方と会社の求めるものが合わないのであれば、会社自体が自分に合っていない可能性もあると語られていた。

また、上司の言うことを聞かなければならないという恐怖から、自分で考えることをやめ、ハンドルを手放してしまうことがあるという。

特に、これまで「言われたことを行う」ことで成果を出してきた人にとって、自分でハンドルを握ることは簡単ではないとのことだった。その場合は、いきなり主体性を求めるのではなく、ハンドルの握り方そのものを身につけていく必要があるとされていた。

どのような環境でも無理に踏ん張るべきだという意味ではないという。強いストレスを感じる場所から離れたほうがよい場合もあれば、踏ん張る必要がある場合もあるとのことだった。重要なのは、自分に合わない場所で無理に頑張り続けるのではなく、自分がハンドルを握り、自分なりに頑張れる場所を見つけることだとまとめられていた。

頑張りすぎずに成果を出す

続いて、「頑張りすぎないチームが、どのように成果を出すのか」が話題となった。

ここで否定されていたのは、朝から夜遅くまで働き、私生活を犠牲にすることを「頑張る」と捉える働き方だった。

本人が望んで長時間働いているのであれば、それ自体を否定するものではないという。ただし、チーム内にそのような人がいると、周囲も同じ働き方を求められていると感じる可能性があるため、好きで長く働いている人は、それが自分の意思によるものだと明確にしたほうがよいとのことだった。

人によって働ける時間は異なり、長時間働ける人もいれば、8時間働くことが難しい人もいるという。労働時間を増やすのではなく、目の前の仕事をうまく進めるために、限られた時間をどのように使うかが重要だと語られていた。

働く時間を減らしたことで、チームが効率的な働き方を考えるようになったとのことだった。重要なのは、長時間働くことではなく、成果に焦点を当て、そのために必要な努力をすることだと語られていた。

モヤモヤを精神論ではなく技術で解決する

仕事上のモヤモヤに対して、解決するための技術を身につけることも議論された。

自分やチームでハンドルを握るために利用できる技術として、インセプションデッキやワーキングアグリーメントなどの手法が挙げられていた。

こうしたフレームワークに対しては、「作っても意味がない」「うまく機能しない」という評価が出ることがあるという。しかし、フレームワーク自体に意味がないのではなく、使いこなすために必要な練習や、道具を磨く時間を取っていない可能性もあるのではないか、という指摘があった。

手法を形式的に導入するのではなく、チームが抱えている問題を起点に利用することが重要だと語られていた。

「アジャイルだから」「スクラムだから」という理由だけで導入するのではなく、「チーム内にこのような衝突があるため、ワーキングアグリーメントを作る」といった順序で考えるとよいとのことだった。

チームが自分たちでハンドルを握るために

チームで手法やフレームワークを使うときには、それをなぜ行うのかを自分たちで理解する必要があるという。

「なぜこのチームはスクラムを採用しているのか」「なぜ朝会を行うのか」といった理由を言語化し、腹落ちさせることが重要だと語られていた。ADRのように、何かを始める際の理由を書き留めておく方法も紹介されていた。

朝会は、当初の目的が失われ、形骸化しやすいものの一例だという。目的を記録しておかなければ、いつの間にか「決まっているから行う」ものになってしまうとのことだった。 振り返りについても、単発で実施すると、その場で改善策を出すだけの活動になりやすいという。定期的な場を設け、継続的に扱うことで初めて意味を持つと語られていた。

フレームワークや手法を使う際には、その手法によって何を得たいのかを考え、常に「なぜ行うのか」を問いかける必要があるとのことだった。

振り返りの成功体験をチームに根づかせるには

振り返りの経験が少ないチームでは、「行う理由が分からない」「効果が感じられない」という理由から、振り返りそのものをやめてしまうことがあるという。まず考えるべきなのは、どのような状態になれば振り返りが成功したと判断できるのか、という点だと語られていた。

チームに課題が山積みになっている場合は、振り返りの中で課題を発見できる仕組みを作る必要があるという。振り返りに求めるものは、チームの状態によって変化するため、「何を解決できたらうれしいのか」を確認するとよいとのことだった。また、大きな問題を一度に解決しようとするのではなく、小さな問題から扱うことが重要だとされていた。

問題を直接分析して改善策を出すだけではなく、リフレクションとして振り返る方法も紹介されていた。個人が自分の経験や感情を内省するのがリフレクションだという。ただし、チームでリフレクションを行うためには、メンバー間にある程度の共通認識が必要になるとのことだった。

お互いが何を嫌がり、何を大切にしているのかを知ることは、成果に直結しないため無駄に見えるかもしれないが、個人を知ることはチーム内の関係を築くうえで必要だと語られていた。

ワーキングアグリーメントの作り方

ワーキングアグリーメントは、単なるルールブックになってしまいがちだが、チームの働き方やスタイルを合わせるためのものだと説明されていた。最初から理想的なルールを並べるのではなく、一定期間一緒に働き、お互いがどのように働く人なのかを知ったうえで作るとよいとのことだった。

たとえば、働き方が競合する部分について、「ここはルールとして決めておいたほうがよい」と話し合い、全員がスムーズに働くための約束にしていくという。決めた内容は不変ではなく、状況に応じて変更するものだと語られていた。また、一般的に良いとされることを書くよりも、メンバーが嫌だと感じることや、「自分はこれは守れない」と思うことを率直に出すことが重要だとのことだった。

こうした小さなストレスを減らすことが、スケーラブルで成果を出せるチームを作る出発点になるとされていた。

高い成果を求めることと、メンバーの不安をどう両立するか

チームに高い成果を求めたいと思っても、「このようなことを言うと、メンバーが不安になるのではないか」という懸念から、推進する側が発言を控えてしまうことがあるという。その場合は、個人に対して厳しい要求をしているのではなく、ゴールを達成するために必要な働き方を話していることを明確にするとよいとのことだった。場に求めるものや成果の基準を定義したうえで、意見が一致しなくても決定後は協力する「disagree and commit」という考え方も紹介されていた。

その際には、単に気持ちの面で納得できないのか、現実的に実行できないのかを切り分ける必要があると語られていた。

成果と期限を明確にする

成果について合意していても、それを1か月で出すのか、3か月で出すのかについて認識が異なれば、チームの動きはずれてしまうという。目標が曖昧だと、何に時間や努力を費やせばよいかが分からないとのことだった。

期限を守る重要性を示す例として、冷やし中華の話が挙げられていた。冷やし中華は6月下旬ぐらいに出すのがよく、遅くなって冬に出しても意味がなく、最速で4月に出せばよいものでもない。必要とされる時期に合わせて出す必要があるという。

目標を精密に設定するほど、チームは動きやすくなると語られていた。一方で、「業界ナンバーワンになる」「売上を20倍にする」といった目標だけでは、いつまでに何を行うのかが分からないという。 大きな目標に対しても、「実際に1年後はどうなっているのか」という冷静な視点を持ち、時間軸を定義する必要があるとのことだった。

Why nowを考える

期間と成果のバランスを取るための考え方として、「Why now」が紹介されていた。今その仕事を行うことによって得られる利益が最も大きいのであれば、今取り組むという考え方だという。将来の目標から逆算し、時間軸の中で現在何を行うべきかを考えるとのことだった。

時間軸が不明確なままでは成果を定義しにくく、目標がアウトカムではなく、単なるアウトプットの列挙になってしまうこともあると語られていた。何を行うかだけでなく、なぜ今行うのか、どの期間でどのような成果を出すのかを合わせて考える必要があるとのことだった。

目標と疲労の関係

疲れは、単に活動量の多さだけによって生じるものではないという。

インターハイを目指している人にとって、ハードな練習は必ずしも苦痛ではない。一方で、目指すものが明確でなければ、同じ練習でもネガティブなものとして感じられるとのことだった。明確な目標があれば、取り組みがハードであっても心は疲れにくいという。

反対に、「何のためにこれを行っているのか」が分からないことや、達成できる見込みのない目標に向かい続けることが、疲労につながると語られていた。頑張りすぎずに成果を出すためには、目標と行動の意味を明確にすることが必要になるとのことだった。

与えられた目標と自分の関心を結びつける

人によっては、自分で目標を決めるより、誰かに決めてもらったほうが安心できるという。

ハンドルを手放したい人に、どのように主体的に関わってもらうかという問題も取り上げられていた。誰かが作った目標であっても、自分の言葉で説明できるかどうかが重要だとのことだった。「偉い人が言ったから行う」という状態では、自分でハンドルを握っているとはいえないと語られていた。

同じチーム目標でも、人によって関心を持つ部分は異なるという。販売目標に関心を持つ人もいれば、技術的な目標に関心を持つ人もいるため、上から与えられた目標を、個々人が興味や意欲を持てるものと結びつける必要があるとのことだった。

自分が何に興味を持てるか分からない場合は、頼まれた仕事の中で、つい没頭してしまうものや、必要以上に作り込んでしまうものを振り返るとよいという。それが、自分に適性のある仕事や、関心を持てる領域を知る手がかりになると語られていた。

また、チーム内に楽しそうに仕事をする人がいると、周囲も元気をもらえるという話もあった。個々人が自分の関心を見つけ、楽しみながら働けることは、チーム全体の力にもつながっていくとのことだった。


全体を通しての感想

  • 様々なタイミングで小田中さんの発信を見てきたので、進研ゼミで見た!的な気持ちになりながらパネルディスカッションを聴いていました。
  • パネルディスカッションのなかでも「目標には期間が大事」という話があり、良い目標を掲げてもそれをどの時間軸で叶えるかがセットでないとダメだなとは感じました。
  • 全体的に「何故やるのか」という話を中心に据えており、フレームワークの類は形骸化しやすいので、そこを日常的に考えることをチームに根付かせないといけないなと改めて思いました。
  • ワーキングアグリーメントの考え方はハッとさせられて、お互いがすりあえるものを探すための枠組みなんだなと改めて思いました。うまくワーキングアグリーメントを決めているチームの話とかを改めて聞きたいなと思いまいした。

『大吉祥寺.pm2026』に行ってきたよメモ

『大吉祥寺.pm 2026』に参加してきたのでそのメモです、

各発表の感想

私が見れたものだけ感想とセットで


キーノート

感想

  • 大井町.pmの@ytnobodyさんと @myfinderの掛け合いセッション。
  • 事前に用意されたマシュマロ投稿に答えていくスタイルでした。
  • 質問はキャリアに関する物が多かったですが「何者になろうとしていたがそうではなくなった」「人と比べすぎない」というような内容が多かったように思います。
  • 幸せは個々人によって尺度が違うのはそのとおりなので、あまり突き詰めすぎないように生きるのが肝要なのかなと思ったりしました。

関連リンク


AI時代に、なぜエンジニアはまだ集まるのか

感想

  • 自身の身の回りの方たちの感想から社会学の話に当てはめていった話
  • 「実践共同体」や「正統的周辺参加」など、技術コミュニティにかかわらず頭に入れておくと良い話が聞けてよかったです。
  • 自分の若い頃は技術コミュニティの入口が見えにくかったので良い時代だなと思います。

関連リンク


そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造

speakerdeck.com

感想

  • 登壇者の方が実際に作ったプロダクトをもとに、何故広まらなかったのかを某博士風に紹介。
  • 作ることも大事だが、広める戦略も大事というのを改めて感じた。
  • ハッカソンきっかけでプロダクトを作っている話でしたが、それでもハイペースでつくれててすごいなと思いました。

関連リンク


分割統治できない世界の歩き方

感想

  • 還元主義で局所最適解をしていく解き方だとダメなシーンもあるので、それを理解して進めるべき的なニュアンスの話
  • 還元主義vsシステム思考というのは全然知らないジャンルだったので新たな切り口を得ました。
  • 別のところでもウォードリーマップの話は見たので、ウォードリーマップをちゃんと追いたい

関連リンク


人間の目はかわらない、だからJPEGは30年もつ

感想

  • 丁寧なJPEGの仕組みのお話。丁寧に順を追って説明してくれたのでそのまま聴き続けたいような話でした。
  • 雰囲気でJPEGを使っていたので、どういう理屈で圧縮を実現しているのかわかってよかった。
  • 人間の目向けなので、ほかの生物だと劣化激しいのかも?とか同時に思ってしまいました。

関連リンク


reFACToring

感想

  • どこからリファクタリングすべきかという話
  • この話は「テストを手厚くする箇所はどこか?」という話と大変似ていてすごいデジャヴュ感がありました。
  • 生成AIの力で可視化がめんどうだったものがやりやすくなっているなというのがすごいあります。

関連リンク


仕様書のない組織を運営する 〜 エンジニア、PTA会長になる 〜

感想

  • PTA活動とエンジニアリングをかけあわせた話
  • IT関連の仕事をしているとITリテラシーの世間基準値がわからなくなるなというのを改めて感じました。
  • 信頼を得るには場に顔を出すっていうのは本当に大事なんだなと改めて実感しました。

関連リンク


変わらないものが、変わるものを決める

感想

  • イベントソーシングの考え方+意図駆動開発のセッション
  • 改めてイベントソーシングの考え方自体が記録がものをいう時代においては存在感を増してくるんだろうなと改めて思わされました。
  • 普段Railsを生業にしているので、このあたりうまく使う機会に恵まれない...

関連リンク


テックカンファレンス三大ステークホルダーの文化人類学 ─ 違いを認め合う関係性作り

感想

  • カンファレンスの三大ステークホルダーに関しての話
  • 高橋会長の「コミュニティ」という考え方はすごく好きで、RubyKaigiに参加してからその思想がなんとなくわかってきた気がしている。
  • 「商取引」ではなく「贈与経済」として考えるというのはなるほどなーと思いました。
  • 前半にあった「AI時代に、なぜエンジニアはまだ集まるのか」とつなげて見るとかなりいい話でした。

関連リンク


論語・武士道・産業革命から見る かわるもの、かわらないもの

感想

  • 産業革命の話を交えつつ、AIというシンギュラリティ真っ只中をどう動くべきかを考えさせられた話
  • 日本人として無意識に備えている特性は意識しつつ、それを活かせるようになっていきたいなとも同時に思いました。
  • 技術を身につける技術は広範囲で役立つ話で、うまく自分の中でも扱えるようにしていきたいなと感じました。
  • ナカミチさんの話は話題のチョイスがうまく、色々絡めつつ人の記憶に刻んでくるなと感じました。

関連リンク


全体を通しての感想

  • 3回目の大吉祥寺、年々バラエティが豊かになっている気がします。また、Magnoliaさんのおかげでいい話が聞けているので感謝しかないです。
  • 私が年齢を重ねてきたせいもあってか、ヘルシーに機嫌良く生きることが何事においても肝要なのではないかなと思っております。
  • LT作成がギリギリのギリだったため、懇親会などで体力切れを起こしておりもっと交流をすべきだったと反省...。イベントソーシングの話とかはしにいければよかった...。
  • 自分自身もLT登壇していたので、それはまた別のタイミングで。

関連リンク

『機能を作るな。楽して作るな。」作れる時代に作らないを選択する等身大プロダクト開発Meetup』に行ってきたよメモ

『「機能を作るな。楽して作るな。」作れる時代に作らないを選択する等身大プロダクト開発Meetup - connpass』に参加してきたのでそのメモです。

各発表の感想


機能を作るな。楽して作るなの再演

speakerdeck.com

感想

  • 資料をもとにした再演が行われた、一部公開資料にもないものが加わっていました。
  • 話の中でかなり気になったキーワードとしては「お客さんを幸せにできるか」「よい体験が作れるか」というようなところでした。
  • おそらくAIの時代で不要なものを作らないことが前提にあったとしても「点」としてプラスになるものを作りがちなので、継続的にプラスでありマイナスを引き起こさない「線」での考え方が重要なんだなと思いました。

関連リンク


パネルディスカッションメモ

書き留められたものだけメモで

Q. 「体験が大事」という点には共感しています。バクラクにおける「体験」とは、具体的に何を指していますか?

チーム内では、「体験」という言葉について一定の共通認識が形成されているとのことでした。 明確に分解して定義したことはないものの、「迷わず使えること」や「直感的に操作できること」などが含まれているそうです。

「この方法であれば業務をなくせる」「この仕組みであれば確認作業自体が不要になる」といったように 業務の在り方そのものを変える方法を示すことが、目指す体験の一つだということでした。

Q. 要望や要求を整理していく過程で、開発者として意見を出すことはありますか?

PdMが顧客の要求を仕様に落とし込んでいく過程で、開発者も顧客がどのような課題を抱えているのかを捉え直しているとのことでした。

顧客が実際に困っている状況を自分たちでも体験し、理解を深めたうえで、次のような観点から意見を出すそうです。

  • この機能は、そもそも開発しないほうがよいのではないか
  • 別のプロダクトで解決したほうが、顧客にとってよいのではないか
  • 機能を作らなくても、別の回答や運用を提示すれば納得してもらえるのではないか
  • ほかの方法のほうが、顧客に価値を感じてもらえるのではないか

こうした議論を行ったうえで、それでも必要だと判断した場合に機能を開発するということでした。

Q. 顧客や業務への理解を深めるために、どのようなアプローチをしていますか?

社内には、日常的に顧客と向き合っているメンバーがいるため その人たちの仕事や顧客との関わり方を見ることで理解を深めているとのことでした。

また、商談の録画を見るなどして、顧客の課題や業務に関する知見を蓄積しているそうです。

Q. 新規プロダクトを継続的に立ち上げるなかで、業務理解はどのように進めていますか?

新しい領域に取り組むたびに、業務をキャッチアップするのは大変だという話がありました。 そのため、まずは対象となるドメインの中に入り込み、現場の人たちが実際にどのような方法で仕事をしているのかを理解しているとのことでした。

社内のコーポレート部門の業務を実際に体験し、業務への解像度を高めることもあるそうです。

特に重視しているのは、一次情報や一次情報源に直接触れることだと説明されていました。 実際の担当者にヒアリングし、先入観を持たず、まっさらな気持ちで話を聞いているとのことです。

既存の理解をそのまま正しいものとせず、疑問を持ちながら確認する姿勢も大切にしているという話でした。

Q. 「業務自体をなくせないか」という視点は、どのように持つようにしていますか?

誰かが困っているのであれば、できる限り楽にしてあげたいという考えから 現在の業務やルールを当然のものとせず、さまざまな前提を疑って考えていると説明されていました。

たとえば新しい法律への対応が必要になったときも、単に現場の経理業務を厳格にするのではなく、次のような点まで確認するとのことでした。

  • 本当にその対応をしなければならないのか
  • 法律上、どこまで対応すれば要件を満たせるのか
  • 過度に厳格な運用にせず、どこに落としどころを置けるか

金融業務では、表からは見えなくても、裏側で多くの人が作業していることがあるそうです。 そのため、必要に応じて法律まで読み、どこまで対応するのかを明確にしているとのことでした。

業務をそのまま機能に置き換えるのではなく、まず業務を十分に理解し、何を作らないかを吟味しているという話でした。

「一つの業務に対して一つの機能を作る」と考えがちですが 複数の業務を一つの機能で解決できないかという視点も持っているそうです。

また、業務に詳しい人になることと、まっさらな視点で考えることの両方が重要だという説明がありました。

顧客の要望は、多くの場合、現在の業務や既存の前提をもとに出されるため そのコンテキストをいったんリセットし、前提を取り払って考え直す必要があるとのことでした。

Q. 一部の顧客だけが必要としている機能は、どのように扱いますか?

一部の顧客だけが必要とするケースは、完全には避けられないとのことでした。 その場合、個別設定として提供すべきなのかを徹底的に考えているそうです。

まずは、一部の顧客だけでなく、すべての顧客に提供できる機能として設計できないかを検討するとのことでした。 それでも「必要な人しか使わない」と判断した場合は、設定項目として提供することになるそうです。

設定として提供する場合は、その機能を必要とする人が、設定の存在にきちんと気づけるようにすることも重要だと説明されていました。

既存顧客にとっては、UI上に機能を追加したほうが分かりやすい場合がある一方で 多くの顧客はその画面や機能を初めて見るため、既存顧客だけを基準にUIを考えないようにする必要があるという話でした。

Q. 仕様相談会やレビュー会では、どのようなことをしていますか?

その週に作ったものを共有する、お披露目会のような場があるとのことでした。

また、振り返りの後に残り、「この機能をもっとよくするにはどうすればよいか」を議論することもあるそうです。

負荷のかかる取り組みではあるものの、細部まで品質を高めるために続けていると説明されていました。 議論は大きな仕様だけでなく、トースト通知のような細かなUI表現にまで及ぶとのことでした。

レビュー会や仕様相談会は、不要な機能や不十分な仕様がそのまま開発・リリースされることを防ぐ役割も担っているという話でした。

Q. 顧客の「思いつきの要望」と「本当に解決すべきペイン」を見極める際、どのように問いを返してコアの課題にたどり着いていますか?

まずは顧客の業務への解像度を上げているとのことでした。 顧客が行っている作業を一緒に行い、どの程度の頻度で発生しているのか、定量的にどれほどの負担があるのかを確認しているそうです。

ヒアリングでは、できるだけフラットに話を聞くことを意識しているという説明でした。

質問のパターンをあらかじめ決めすぎると、聞き手が期待する回答へ誘導してしまうことがあるそうです。 そのため、冒頭では何も知らない状態に近い姿勢で、「何か困っていることはありますか」と広く尋ねているとのことでした。

ヒアリングの途中にもオープンクエスチョンを挟み、顧客が自由に話せる時間を設けているということでした。


全体を通しての感想

  • 機能として何をつくるかをすごく吟味しているし、かなり突き詰めて考えている姿勢がすごく伺えた
  • 適当に出したものを試しにつかってもらう、などではなく全力で考え抜いた結果を出していくという姿勢がすごい
  • いままでは作る時間が長くかかったので、その間に考えることもできたが、だんだんタイムスパンが短くなっているのでより濃度高く顧客のことを考えることをしないとダメそうだなと改めて思いました。
  • toBにおいてもtoCと同じぐらい顧客を考えることが大事という言葉もでてきており、大事にしたい考えだなと思いました。