はじめに みなさん、こんにちは。今回は、私がプロダクトマネージャーとしてDIGGLEに入社した当初（2022年頃）のしくじり事例を通じて、プロダクトロードマップの作成と運用について考えてみたいと思います。 ある日、シリーズAフェーズのスタートアップのプロダクトマネージャーとして着任した私は「全力でプロダクトマネジメントするのだ！」という意気込みで、さまざまなプロダクトマネジメント本を読みあさっていました。 私は読みあさったさまざまな知識をもとに、さまざまなプロダクトマネジメントの手法をプロダクトに試していきました。 そんな形で業務を推進していた中、エンジニアやセールス、カスタマーサクセス（CS）チームと話をしていると、こんな声が聞こえてくるではありませんか。 「プロダクトって今後どう展開されていくんですかね？ いろいろ開発されているのはいいんですけど、どういう方向性なのかあんまり分かってな

テスト同士は独立して相互に影響を与えない（Independent である）ことが望ましいが、作成者が意図せず依存関係を持ちこんでしまう場合がある。 テストの順序を入れ替えると独立していないテストが発見しやすくなるため、テスティングライブラリにはテストの順序を入れ替える仕組みを備えたものが多い。また、順序を都度ユーザー側で指定するのは面倒なので、法則性を持たない（ランダムな）順序でテストを実行する機能を備えている場合もある。 加えて、法則性を持たない順序で実行したテスト失敗をきっかけに依存関係を発見した場合、その後に同じ順序でのテスト実行ができると修正が意図通りに行えたか確認が容易になる。一部のライブラリは、ランダムさを得るための初期値（Seed）を実行時に設定することで、法則性を持たないが、同じ順序でのテスト再実施が可能になる仕組みを備えている。 Ruby で利用されることの多い[1]テス

DIGGLEは、2023年に続いて2024年も継続してRubyKaigiスポンサーを努めました。5/15〜5/18に沖縄で開催されたRubyKaigi2024にnikuが参加したので、その際の感想を公開します。 RubyKaigiの発表は「Ruby自体をよくする、Rubyの適応領域を既存から押し広げてゆく」という観点で捉えると私にはすっきりとまとめられるものが多いように感じました。全部面白かったのでどの感想コメントにも「面白かったです」というのがついていると思ってください。 (参加していなかった時間帯もあります) 1日目(5/15) Writing Weird Code - RubyKaigi 2024 Weirdなコードを書くのは当人は楽しくやっていると思いますが、Rubyのコードってどこまで無茶なことできるの、変わったことできるのという探求は、Rubyのコードの(読み手からみた)整合性

はじめに Datadog API Clientによるデータの取得 パフォーマンス分析の概要 対象データ 分析方法 パフォーマンス分析基盤の構成の検討 データ保存先 構成 対応内容 サーバーサイド インフラ フロントエンド 最後に We're hiring! はじめに DIGGLEではすでにDatadogを導入してパフォーマンス指標のトレースデータ*1は取れていますが、以下の課題がありました。 ユースケースを分けてパフォーマンス指標を取得したい DIGGLEがターゲットとしたい企業やペルソナユーザーのデータのみを取り出すのが面倒 開発時点でCIが動いた時に、分析結果をプルリクのコメントに出力したい Datadogに保存されているパフォーマンス指標のトレースデータには有効期限がある 上記に対応する為にまずは調査を行いました。 Datadog API Clientによるデータの取得 Datado

はじめに DMARC対応作業を始めるまで それは一通の問い合わせから始まった そもそもDMARCって何だ？ 対応時の注意点 メール送信方法によって対応内容が異なる SPF、DMARCの対応は複数サービスで同じ場所に修正を加える必要がある SPF/DKIM未対応の状態でDMARCに対応してはいけない 定義を間違えると他のサービスにも影響を及ぼす危険性がある DMARC対応の流れ 自社で保有しているドメイン一覧を特定する メールアドレスに使用されているドメインを特定する ドメイン毎にDMARC対応が必要か判定する メール送信を行っているサービスを洗い出す 各サービスでSPF、DKIMの対応方法を確認する SMTPサーバを指定している SPF/DKIMを有効化するレコードをDNSに追加する サービス側のDNSサーバを参照するためのレコードをDNSに追加する 対応方法が何も書かれていない場合 DN

2023 年 10 月 30 日に『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』（以下 実践プロパティベーステスト本）という本が出版されました。 プロパティベーステストというのは、テストの一手法なのですが、これまでとは違う範囲をカバーするテストです。 今回はそれを Ruby に適用するとどうなるか検証、また似ている既知との概念と対比して理解を深めました。 これは Ruby Advent Calendar 2023 15 日目の記事です。 プロパティベーステストとはどのような形式か 既知の概念との対比 普段書いているテストと、プロパティベーステスト データ(テーブル)駆動テストと、プロパティベーステスト ファジングと、プロパティベーステスト 型と、プロパティベーステスト まとめ 実践プロパティベーステスト本は 2023 年 12 月現在、テストの一手

前置き プロダクト開発は人の手によって行われるものですから、開発サイクルの中で不要なコードを削除し忘れる人的なミスはどうしても発生します。 後から不要なコードに気づき削除する際には、慎重にチェックして本当にコードが使用されていないことを確認する必要があります。ただし、削除に自信が持てない場合、本番稼働中の Rails アプリに障害が発生する可能性も考慮しなければならず、何も影響しない場合はそのままにしておくことも多く、削除が難しい状況も少なくないと思います。 上記状況を打破するために DIGGLE では本番稼働中の Rails アプリのコードの使用状況を収集して不要なコードを発見するための仕組みを導入したので共有したいと思います。 前置き 不要なコードをどのように発見するか Ruby で コードカバレッジを計測する 仕組み導入にあたって悩んだポイント YJIT を有効化した状態で動作するの

私たちは Ruby on Rails の主要なマルチテナントライブラリ apartment を使ってサービスを提供しています。 Ruby のバージョンを 3.1 系から 3.2 系に上げたときに CSV ファイルを処理する部分でこのテナントの切り替えが意図通りに動作しませんでした。 この事象が興味深かったので共有します。 現在はこの事象に対応済で、私たちの環境は Ruby3.2 系で動作しています。 apartment ではマルチテナント対応部分をほとんど吸収してくれるので、アプリケーションのコードのほうにはあまりマルチテナント特有の処理が出てこず、個別処理のコードに集中できるメリットがあります。 事象が発生したコードは以下のような形式でした。 CSV.parse(filename, headers: true, header_converters: ->(header) { curren

こんにちは。にくといいます。github だと niku です。2022 年 12 月に DIGGLE に入社しました。 さて Ruby 3.2 からは Data というクラスが使えるようになりました。 Ruby の日本語リファレンスるりま*1（以下「るりま」）にも class Data (Ruby 3.2 リファレンスマニュアル) というページができていますね。すごい！ 「るりま」は GitHub の Pull Request を用いてメンテナンスされています。今回 Data のリファレンスも github.com で作られた PR が元になっています。 この PR のレビュアーとして私も参加したので、その時の様子も交えて「るりま」のドキュメントのメンテナンスの雰囲気をお伝えしたいと思います。 Data クラス この記事を楽しむために、まずは Data クラスというのがどういうものなのか

東京ではないところで勉強会を続けるにはどうしたらいいかを考え、札幌でサッポロビームという勉強会の開催を試してみたところ、2014年4月から2019年11月まで5年半ほぼ毎週続けられて、もうすぐ300回だ。 以下の記事を読み、素敵な取り組みをしているなと感じ触発されたので、私が長く続けられている勉強会というものについて書くことにした。 多くの人の役にたつ勉強会については取り上げない。なぜならサッポロビームはたぶんそういう観点ではうまくいっていないからだ。最近はオンライン/オフライン含めてだいたい数名で、私の記憶では最高でも10人未満だ。 自分が勉強する会と考えれば誰もこなくても自分にお得だし、誰か来てくれればさらに自分にも(相手にも)お得だ 勉強会を主催して自分以外に参加者がいなかったら「 需要ないのかな……」と悲しくなる気持ちが出るのは仕方ないかもしれない。こうしたらどうだろう。自分が毎週

NTTは14日、米航空宇宙局（NASA）や米スタンフォード大学などと共同で、光通信技術を応用した新しい方式の量子コンピューターの開発に乗り出すと発表した。量子技術の開発では、日本は基礎研究では先行していたが商用化で後れをとった。グローバルな開発体制を整え、米グーグルや米IBMや中国勢などを猛追する。研究には、光レーザー技術に強い米カリフォルニア工科大学など米国とオーストラリアの6つの有力大学と

ここ4ヶ月ほど、ほぼ1日中、3人で同じモニタに向かって仕事をする、いわゆるモブプログラミングやモビングと呼ばれるスタイルで仕事をしている。 note.mu この中の一人が僕だ。 僕達は常にこの3人で仕事をしているので、その結果がモビングの効果なのかそれともこの3人だからなのかはわからないけど、これまでの経験で感じたことを書いてみたい。また、既に2人は感想を書いているのでそちらと見比べるのも面白いかもしれない。 niku.name note.mu アイディアが沢山出てくる 何をしたらいいのかさっぱりわからないということがほとんど無くなったし、これ以上できることは無いと思ったときも、何か他にできることが無いか、という「もう一押し」の案が出てくる。自分が何かをうっかり忘れていて、他の誰かが指摘してくれるということも多い。自分が何かを思いついたときは「めっちゃそれいいっすね！」みたいなフィードバッ

記事では「モブプログラミング」に焦点を当ててありますが、実は僕たちはプログラミング以外もほとんどの時間を「モブ」で作業しています。これは「モブワーク」と呼ばれているやり方のようです。 そこでこのエントリーはこの記事の補足とともにモブワークを4ヶ月ほどやってみたチーム内部の人間から「モブワークなかなかいいよ」という話をするエントリーになります。 「確実に前に進むことができる実感」がある僕たちのやっているモブワークについて、僕の感じている一番のよさはここです。車でいうとギアをローに入れて進むようなもので、道が整っていない荒地でも進むことができ、多少の障害物でも止まることがありません。 障害物には例えば、どこから取り組んでいいのかわからない困難な問題、メンバーの疲労の蓄積、病気、割り込み作業、簡単な作業だと思ったら思いの外大変なやつだった、みたいなさまざまなものがあります。 "1 + 1 + 1

情報システムが適用される領域は年を経るごとに広く、複雑になってきている。 適用される領域が広がっているために、かつては専門の教育を受けた人が触るものだったのが、近年は専門の教育を受けていない人も触るようになっている。 さらに複雑化により「専門の教育を受けていない人に 全て を説明する」ということがかなりの困難をもたらしている。 IPAが作成した 非機能要求グレード では、これらを解決すべく提供されている。 Disclaimer: 以下は開発者である私の立場から書いてある。非機能要求グレード自体は情報システムを必要としている立場の人が使っても有用なように提供されている。 非機能要件の合意の難しさ 情報システムに対する要求には大きくわけて二種類ある。 機能要求業務の実現に関する要求 例)「営業情報をシステム上で共有し把握したい」 非機能要求機能要求以外の要求 例)「システムダウン時は3時間以内

Elixir 製チャット Bot フレームワーク （以降 Bot フレームワークと称する） Hobotを作った． 以下のとおり bot_name adapter_conf そして handlers_conf を Hobot.create/3 に渡すと動作する．例では入力した内容をそのまま返すエコー( Handler.Echo ）をコンソールから動かして（ Adapter.Shell ）いる． iex(1)> bot_name = "EchoBot" "EchoBot" iex(2)> adapter_conf = %{module: Hobot.Plugin.Adapter.Shell, args: []} %{args: [], module: Hobot.Plugin.Adapter.Shell} iex(3)> handlers_conf = [%{module: Hobot.Plu