はてなブックマーク

はじめにはじめまして。2023年10月にキャリア入社した篠原です。 これまではシステム開発がメインでしたが、最近データ分析の業務に関わらせていただく機会がありました。そこで求められる成果物、注力すべきポイント、そして技術選定の観点など、従来のシステム開発とは異なる部分が多く、様々な気づきがありました。 自身の振り返りも兼ねて、その知見を共有したいと思います。 なお、データ分析の目的と流れについてはこちらの過去記事も併せてご覧ください。 データ分析で求められるものと意識すること会社や組織が意思決定を行う上で様々な手法がありますが、データを用いた定量的分析は重要な判断材料となります。 「どこに施策を打つのが効果的だろうか」「施策を打った結果、どのような効果があったのか。その結果を元に今後の動きを考えたい」こうした問いがある際、「正確さ」はもちろんですが、次のアクションへ繋げるために「スピード」

目的と定義本ドキュメントは、従来のプログラミング手法の限界を超えた、AI中心のプログラミング手法として、ラジカルAIプログラミングの概念を定義する。 2002年ごろにブームを起こしたeXtreme Programming (XP) は「昔からあるベストプラクティスを極端(eXtreme)なレベルで適用する」という思想で作られた。コードレビューが有効なら常にペアで開発を行う。テストが有効なら全てのコードでテスト書いてから実装する。ユーザーとの対話が必要ならいつでも会話できる場所にユーザーを座らせるといった具合である。それと同じようなチャレンジをAIを使った開発でもやってみようというのをモチベーションとして自分がAIを使った開発を半年ほど行って得た経験をもとに作成した。RadicalはeXtremeとは違う単語だが似たようなクレイジーさを表現できる単語として選んでいる。4つの価値と12のプラク

秋のブログ週間の5本目です。 3年前の秋のブログ週間でデータベースと向き合う決意というエントリーを書きました。3年経ちましたが、多少ベクトルは変わりましたが今も基本的な気持ちは変わっていません。むしろ、「生成AIによって自然言語で気軽に作れるようになった」ことで、SQLの敷居は大きく下がりました。 DFDのガイドライン作りを始めた今年はDFDの本が出ました。5月にブログも書きました。 データフローダイアグラム本の献本をいただきました本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気

秋のブログ週間の7本目です。TIG 真野です。 アーキチーム（アーキテクト）やテックリードなどからの設計/開発のレビューで、こんな経験はありませんか？ 「その実装は、この機能ID “BL310” の実装パターンでお願いします」「そのライブラリの採用は見送りでお願いします」「そのミドル（DB）のその機能の利用は原則禁止です。え？ はい、あー、、ガイドラインには…確かに今、書いていないですね。後出しで申し訳ないのですが利用はしない方向でお願いします。開発規約には私がこれから追記しますね。え？ あ、はい。そうですね、今度タイ料理でも食べに行きましょう」難しい要件・厳しい期限・不確実性・そして必ずしも満足とは言い難い体制の中、こっちはベストを尽くしていて、ましてより直感的で意図が明確な設計や実装だと思っていて、ていうか品質やスケジュールで遅延が生じた際に結局、矢面に立つのは自分なのに、否定されてか

PostgreSQL 18連載の3本目です。 PostgreSQL 18がリリースされ、仮想生成列についてまとめます。PostgreSQLで従来から利用できた格納生成列や、生成列自体と合わせて紹介します。 生成列生成列は他の列から計算される列のことで、テーブルに対するビューをつくるように、ある列に対してビューのような列を作ることができます。ビューにも、MViewと通常のViewがあるように、生成列も「格納生成列」と「仮想生成列」の2種類があります。格納生成列は、登録/更新時に計算されて物理的にストレージが割り当てられます（MVIEWに似ています）。仮想列は列が読み取られる時に動的に計算されます（Viewに似ています）。 PostgreSQL 12で「格納」生成列が利用可能となり、今回18から「仮想」生成列が利用可能となりました。ここまで説明した内容をざっと、表でまとめました。 特徴格納生成

エンジニアであれITコンサルであれ、抽象的で不確実性の高い、要は「いい感じに進めて！」的なフワッとしたタスクは避けて通れません。 目的: 目指したい姿は決まっている 仮説: 現状の課題はヒアリング結果からざっくり候補はある。正解とは限らない 方針: どう解決するか未議論 例えば、データガバナンスの文脈で説明すると、「全社でデータ利活用促進させたい」というゴールに向けて、現状の「データ権限管理が厳し過ぎるかも」とか、「データ共有文化が無いから」などの仮説があり、「どう持っていくのが良いんだろうね？」とチームで議論が始まったような状況を、ここでは想定します1。 「目的」自体を否定しないのでなければ、よくある進め方は、やるべき「具体的な課題」が何であるか分析・分解・仮説を立てること。そして仮説の真偽を、ヒアリング・実データ・試行などから検証する流れ。課題さえ明確にできれば、対応方針はよりクリアに

PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ

PostgreSQL: 4億件のテーブルでSeq Scanが選ばれる問題を、統計情報(n_distinct)の改善で解決するまでのプロセス PostgreSQL18連載の5本目の記事です。 はじめにこんにちは、CSIG (Cyber Security Innovation Group) の市川です。 本記事では、私が現場で行った PostgreSQL のパフォーマンスチューニングについて、原因調査から解決までのプロセスを共有します。この記事が、「なぜか適切な実行計画が選ばれない、インデックスが使われない」といった同様の問題に直面している方の助けになれば幸いです。 また、今回の鍵となった n_distinct という統計情報の計算方法について、Appendix に考察を記載しているので、合わせてご一読ください。 (不適切な記載がある場合は、ご指摘いただけますと幸いです) まず本記事の要点とし

リモートの会議が終わったら即「退出」ボタン。昔は会議室から出る時に自然と生まれていた「ちょっとした立ち話」も工夫なしでは生まれません。 また、チームには雑談が大事とは言うものの、「さあ雑談しましょう」と言われると、何を話せばいいか分からず、構えてしまう人もいます。目的無しに色々な話ができるほどコミュ力無いし、そもそも、業務で忙しいんですけど？みたいな。 そこで提案したいのが、顧客との会議など、ちょっと緊張感のある打ち合わせの後に「ラップアップ」の時間を設けること。個人的に強く推奨したい習慣です。 ここでいう「ラップアップ」って何？単純に言うと「会議の振り返り」。 顧客との定例会議など「一戦交えた」後、熱が冷めないうちに連続で15-30分の会議通知を 社内メンバー限定別枠で 入れ、アジェンダをガチガチに固めず、「今日のあれ、どうでした？」くらいの、ゆるい雰囲気で話すこと。 一般的なラップアッ

UUID v7PostgreSQL 18ではUUIDv7生成に対応しました。今までのUUID v4(完全ランダム)は主キーとして使うと、ソート順で扱おうとするPostgreSQLの内部構造のB-Treeと相性が悪く、さまざまなノードへのアクセスが必要になるため、相性が悪いとされていました。RFC-9562で標準化されたUUID v7は先頭がタイムスタンプであり、キーをソートすると、必ず作成した順序になります。そのため、生成順にデータを挿入したとしてもパフォーマンスが落ちにくくなる、だからいいんだ、ということのようです。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

はじめにこんにちは。TIG-DXの藤井です。 当社の有志メンバーの協力により、アーキテクチャ設計ガイドラインというものを作成・公開しています。 各分野におけるアーキテクチャ設計の指針となるべく作成されているガイドライン集ですが、この度、新たにメール設計ガイドラインを作成しました。 本記事では、このメール設計ガイドラインについて、内容にも触れつつご紹介をしていきます。 メール設計ガイドライン概要皆さん、普段からメールは利用されているかと思います。その手軽さ・利用者の多さから、純粋なコミュニケーションツールとしてはもちろん、webシステムにおけるユーザ認証や、販促・各種取引など、多岐にわたって活用されています。 一方、実際にメールという通信手段がどのように実現されているのか・どういった技術が利用されているのか、等を意識することはあまり無いのではないでしょうか。 当然のことではありますが、メール

はじめにJava 24 & 25のリリース連載第 2 弾の記事です。 第 1 弾の記事 に引き続き本記事では Java 24 のアップデートを取り上げます。 JEPsJava 24 で対応された主要な 21 の JEP（Java Enhancement Proposals）は次の通りです。 Oracle の プレスリリース をベースにカテゴライズしています。

はじめにこんにちは。TIG（Technology Innovation Group）の本田です。 フューチャー社内の有志メンバーでバッチ設計ガイドラインを作成し、公開しました。 本記事ではガイドラインの作成の経緯や想いなどを簡単に紹介します。 本ガイドラインの対象読者本ガイドラインは、以下のような方を主な読者として想定しています。 バッチ開発を行う初学者 バッチ処理を含むシステム設計を行う人 自身のメイン領域はバッチ処理ではないがバッチ処理設計の勘所を知っておきたい人 特に初学者の方はジョブ設計の章だけでも読んでいただくことをオススメします。バッチ処理のプログラムを実装する上で留意するべき冪等性や性能といったポイントが紹介されています。 本ガイドラインの作成経緯フューチャーでは様々な規模のシステムを構築しており、その中には多種多様なバッチ処理も含まれます。 cronのようなシンプルなスケジ

はじめにこんにちは。TIGの長谷川です。 フューチャー社内の有志メンバーでWebフロントエンド設計ガイドラインを作成し公開しました！ 本ガイドラインではガイドライン策定の背景やガイドラインの特徴に加えて、内容の一部をピックアップしてご紹介します。 本ガイドラインの背景昨今のWebフロントエンド領域は、単なるHTML、CSS、JavaScriptでのページ制作から大きく変化しました。React、Vue.jsなどのモダンなフレームワークを活用した大規模かつ動的なWebアプリケーションの構築が主流となっています。 これにより開発の効率化とユーザー体験（UX）が向上しています。しかし一方で、設計の考慮点も多様化し、セキュリティやアクセシビリティなど、より多面的な品質も求められるようになりました。 本ガイドラインでは、Webフロントエンド設計における考慮点・設計パターン・推奨手法を提示し、開発チーム

こんにちは、starswirl_kです。 今回は、チーム開発でMermaid図を頻繁に利用している中で、「もっとこうなったら良いのに！」という現場の声を形にした自作ツールをご紹介します。 特に、フローチャートやクラス図の矢印の長さ（ノード間の間隔）や垂直方向の間隔といった細かい調整に悩んでいる方には、きっと役立つはずです。 ツールはこちら：GitHub Pages/MermaidViewer.html なぜこのツールを作ったのか？Mermaidは手軽に図を作成できる非常に便利なツールですが、デフォルトの設定では図の要素間の間隔が固定されているため、複雑な図になると矢印が短く見づらかったり、全体のレイアウトが窮屈に感じられることがありました。 特に、以下のような課題がありました。 矢印が短い: 図の要素が増えると、関係を示す矢印が短くなり、どこからどこへ繋がっているのか視認性が悪くなる。 レ

夏の自由研究2025ブログ連載の7日目です。 フューチャー技術ブログの「関連記事」の表示ロジックの変遷と今後についてまとめます。 背景フューチャー技術ブログは開設以来、Hexoという静的サイトジェネレータを利用しています。そのため、サイトの構造や記事のレイアウトは完全にフルスクラッチで自由度が効く反面、全てを自分たちで（できれば、手間と時間をかけずに）行う必要があります。 創設が2016年、9年半が経過し現在1300ほどの記事が投稿されています。中にはバズって数万PVに届く記事もあります。せっかく、ある記事を見てもらったのであれば、他の記事をついでに見てもらうことで回遊率を上げたいという気持ちがあります。また、社内のナレッジ管理の側面では「know who」が重要なので、似たような記事を書いた人を辿れるようにしておくことは、ポリシー的に大事にしたいポイントです。 1300記事もあるとユーザ

夏の自由研究2025ブログ連載の4日目です。 技術コンサルをしているお客さんとPrismaのドキュメントの読書会をしていて、全文検索機能がPrismaにも、PostgreSQLにも標準で用意されているということを知りました。PostgreSQLで全文検索はというと、PGroongaとか、pg_bigmを使うとかがトップ出てくるし、そもそも検索をしたくなったらElasticSearch使う、みたいに思っていました。 標準で全文検索もできるなら運用コストもだいぶ下げられそうです。かつて、Python製ドキュメントツールの、ブラウザで動く全文検索エンジンの日本語対応をやってみたり、FM-indexという高速文字列解析の世界という書籍で紹介されていたアルゴリズムを使ったブラウザで動く検索エンジンを作ったり、転置インデックスをS3に置く検索エンジンを作ってみたり貧乏低コスト検索エンジンの第一人者(自

夏の自由研究2025ブログ連載の2日目です。 はじめに人生は選択の連続ですが、何を選択するかどうやって決めていますか？ おそらくはメリット/デメリットを鑑みて方向性を決める方が大半だと思います。時には、どう転んでも結論は一緒の場合やメリデメで考えない場面もあるとは思いますが、巨額マネーが動くケースではそうもいきませんよね。 今回は、サイバーセキュリティ界隈の文脈で「リスクの可視化～意思決定」がどのように行われるのかをお話します。これはプライベートでも仕事でも、おおよそ生きていく上で役立つ考え方にも応用できると思います。 リスクアセスメントとはビジネスはいかに精度よく予測して経営計画を立て、調整力と実行力で推進し、残りは運、そんな感じのポートフォリオかと思います。もちろん経営者の方の中には長年の勘やデータからは読み取れないが物理的な何某か（ex. 生きている消費者から直接感じ取る波動や世間の

ブログ運営の立場として、この生成AIブームな時代に「◯◯について技術ブログを書いてください！」と依頼し続けて良いのか？そんな疑問が湧きました。 情報収集はAIに聞けばいいし、書くこと自体もAIが手伝ってくれます。それでもなお、個人として技術ブログを書き、そして人に勧めるの理由を言語化しておきたい。 今回は、なぜ今あえて技術ブログを書いた方が良いのか、会社Slackのブログ寄稿者チャンネルで太田さん、澁川さん、枇榔さん、山本さん、橋本さん、村田さん、村瀬さん、柏木さんと相談した結果をまとめました。 自分のため結局のところ、一番大きいのは自分のため。 スキルアップ 書く過程で、曖昧だった知識が整理される。疑問を調べて解消することで、より深く理解できる アウトプットすることで、社内外からフィードバックをもらえて、さらに詳しくなれる 地味に文章力も上がる。どんな仕事でも役立つ セルフブランディング

Slack、便利ですよね。フューチャーでも2020年の本格導入以降、多くのプロジェクトで使われており、もはや仕事に欠かせない空気のような存在です。 先日、Slack利用ガイドラインを考えるチャンネルで、Slackの「困った使い方」について話しました。オープンな文化を守るために大事だと思ったので、ブログにまとめました。 探せばありそうな残念な光景発端は、mizchiさんのとあるXのポストでした。これをきっかけに、こんな感じの会話をしました。 Aさん: @channel を連投する人がいて、結局ミュートされて機能不全になるの、不謹慎ながらちょっと笑ってしまいました。幸い、自分の周りにはそこまでの人はいなかったし、DM（ダイレクトメッセージ）を多用して情報の非対称性を作るなどで、社内政治する人も見たことないです。 Bさん: 昔、大きめのプロジェクトで @channel を連投に近いことをする人な

はじめにコアテクの山口です。 フューチャー社内の有志メンバーでI/F設計ガイドラインを作成し、公開しました。 I/F設計ガイドライン | Future Enterprise Arch Guidelines システム開発、特にエンタープライズ領域においてシステム間のデータ連携は避けて通れません。 本ガイドラインは、クラウドネイティブな環境におけるモダンなシステム間連携の設計指針を提供することを目指しています。 アピールポイント連携方式の選定といった上流のアーキテクチャ設計から、ファイル形式や冪等性といった下流の詳細設計、そして結合テスト計画の指針まで網羅されたガイドラインになっています。 ピックアップコンテンツ今回のガイドラインもボリュームがあるため、一部コンテンツを抜粋してご紹介します。 統合パターンシステム間連携の方式として代表的な4つの統合パターン（DB共有、RPC、メッセージング、フ

Go 1.25 リリース連載 の5本目です。 はじめにこんにちは、CSIG FutureVuls の市川です。 testing/synctest パッケージについて紹介します。Go の testing/synctest は、Go1.24 で experimental として追加され、 Go1.25 で正式なパッケージとなりました。 過去のリリース連載で棚井さんが詳しく解説した記事を書いてくださっています。synctest の基本的な説明についてはぜひご参照ください。 本記事は以下の流れで説明し、具体例を用いて durably blocked と synctest.Wait() についての理解を深めます。 synctest の概要とメリット experimental からの変更点 durably blocked の定義 synctest.Wait() の挙動 synctest の概要とメリッ

はじめにこんにちは。ペンギンになりたいエンジニアの島ノ江です。 現在は FutureVuls という脆弱性管理サービスの開発・営業などを担当しています。 Go 1.25リリース連載の4本目、マイナーアップデートの net/http での CSRF 対策の強化について触れます。 この記事では、以下の内容について触れていきます。CSRFについて既知の場合はリリースの実装内容の項目を参照してください。 今回のリリースの概要 CSRFの概要 issue提案の背景 リリースの実装内容 関連する issue はこちらです（issue） 今回のリリースの概要新たに net/http に CrossOriginProtection が実装され、安全でない Cross-Origin ブラウザリクエストを拒否することで、CSRF から保護するようになりました。これまでの Go では、標準ライブラリの net/

はじめに製造エネルギー事業部の辻です。Go1.25 リリース連載 の3本目です。 マイナーアップデートから sync パッケージを取り上げて紹介します。 アップデートサマリ The new method on WaitGroup, WaitGroup.Go, makes the common pattern of creating and counting goroutines more convenient. https://go.dev/doc/go1.25#syncpkgsync sync パッケージに新しく WaitGroup.Go() というメソッドが追加されました。ゴルーチンの生成と完了を集計する一般的なパターンを便利に記述できるようになりました。 var wg sync.WaitGroup tasks := []string{"task 1", "task 2", "task

はじめにGo 1.25 リリース連載 の 2 本目です。 本記事では log/slog パッケージ のアップデートについて紹介します。 Go の log/slog パッケージは、Go 1.21 で導入された構造化ロギングをサポートする標準ライブラリです。 本記事では slog についての基本的は割愛しますが、slog の概要やこれまでのアップデート経緯をつかみたい方は、過去のリリース連載記事を参照してください。 Go 1.21 連載始まります＆slog をどう使うべきか Go 1.22 リリース連載 vet, log/slog, testing/slogtest アップデートの概要リリースノート を参照してみましょう。 GroupAttrs creates a group Attr from a slice of Attr values. Record now has a Source m

Go 1.25 更新のオーバービュー執筆時点では現在 RC2 が最新です。この時点のリリースノートを参考にしています。たまに直前で一部の機能のリリースがキャンセルになったりしますが、今回はどうでしょうか？ go build -asan オプションでプログラム終了時のリークのチェックが行われるようになった。C で割り当てられたメモリが C からも Go からも参照されなくなった状態で残っていたらエラーに インストーラでバイナリとして提供されるツールが減って必要に応じてビルドすることでインストーラのサイズが削減（ARM の mac 向けで 73MB→56MB） go doc -http で HTML で見るドキュメントサーバーが起動 go コマンドがリポジトリのサブディレクトリをモジュールのルートとして扱えるように go vet が強化(取り扱い予定) GOMAXPROCS が cgroups

子どもを寝かしつける際にふと、「伸びる人の条件ってなんだろう？」と考えだしたら止まらなかったので、会社Slackのスーパー雑談チャンネルで投げかけてみたところ、有益かつ面白いやり取りができたので議論をまとめました。 新卒採用の面接でよく聞かれる話題でもありますね。 最初に出た「伸びる人の条件」たちまず、みんなから出てきたのはこんな感じです。 素直である（言われたフィードバックをプライド邪魔せず受け取れる、理由もなく自分のやり方に固執しない） ロジカルシンキング / クリティカルシンキングができる 手が早い、まずやってみる精神 壁を作らず、越境できる 与えられた役割を全うし、さらに広げようとする 業務を通じて勝手に学べる（関連領域への興味関心） ゴールイメージが持てる、またはそれが分からなければ端的に聞ける どれも「たしかに」という感じです。特に「越境」や「戦場で強くなるタイプ」は、実務での