はじめまして | trueの技術日誌

個人日誌を始めることにしました。

学んだことを言語化する習慣をつけたいというのが理由です。頭の中で「なんとなくわかった」で止まってしまうと、後から何も残りません。書くことで輪郭をはっきりさせたいと思っています。手始めに、先週を振り返ります。

Uzabase — チーム開発でのTDD実践

インターン2週目。チーム開発でTDD（テスト駆動開発）を実践しました。

仕様書を書く段階が特に難しかったです。「何を実装するか」ではなく「何が満たされれば完了か」を先に定義する作業は、普段の開発とは思考の順序が逆になります。

ただ、仕様策定を通じて要件と周辺の文脈をかなり深く理解できた結果、AIエージェント（Claude）を並列で走らせられる程度には全体像を把握できました。要件が曖昧なままAIに頼ると出力がブレるので、これは自分の理解度の指標として使えると気づきました。

一方で、実際に作ったものをどの程度運用するか——つまりプロダクトの将来性——はまだ不確定で、何によって決まるべきかも自分の中で整理しきれていません。

アプリのホスティング環境の一部移行に関わりました。

ここで学んだのは、流用するものと新規作成するものを最初に分けて考えるという設計の切り口です。APIやCSSなどクラウド上で複数サービスから共通利用されるリソースを「共通項」として括り、移行対象と非移行対象を整理しました。

保守性の方針についてはまだチームとして議論できる段階にありませんが、この「共通と固有の分離」という考え方は、今後の設計でも繰り返し使えそうだと感じています。

GNN（グラフニューラルネットワーク）のアルゴリズムが、金融業界における企業間の依存関係分析に活用されていることを知りました。

直感的に面白いと思ったのは、この手法をuzabaseの顧客ペルソナ設定にも転用できるのではないかという点です。企業間の関係性をグラフ構造で捉え、顧客セグメントを動的に更新するようなアプローチが考えられます。まだ仮説の段階で、検証は今後の課題です。

Kaggleの勉強を始めました。ゲーム的なインターフェースで取り組みやすいです。

アンサンブル学習を学んでいて、過去データが正解ラベル付きで存在する状況では、意思決定プロセスのシミュレーションが成立するのではないかと考えました。たとえば、経営会議への参加を希望する人物の過去の判断履歴をもとに信頼性を定量評価する、といった応用が思い浮かびました。

一方で、loglossなどの評価指標の数式については、まだ直感的に理解できていません。uzabaseでも数値感覚の欠如を課題として実感しているので、ここから逃げずに向き合っていきたいと思います。

以上、先週の振り返りでした。