kntmr-blog

Devin使ってみてどうだった? ~活用事例と導入時のポイント~ に行ってきた #devin_findy

Devin使ってみてどうだった? ~活用事例と導入時のポイント~ に参加しました。簡単に所感をまとめます。

findy.connpass.com

所感

申し込みが1000名を超えてて生成 AI に関心がある人がかなり多いことが分かります。

やはり Devin の魅力としては、さまざまなタスクを非同期に進められるところや、エンジニア以外でも開発できるようになるところですかね。あと、話の中でもありましたが、タスクを着手するハードルが下がるため、優先度が低くて後回しになりがちなタスクを消化できるようになるのもよさそう。

個人的に面白かったのは、Devin などを活用することで開発リソースを必要なときに必要な分だけ増やせるという話。負荷に応じてオートスケールするインフラのイメージ。なるほど。人を採用するには時間やコストも掛かるし、仕事量の波によって手が空いたりみたいな心配がない。

あと、参考になったのは、情報をナレッジ機能に溜め込まないこと。ノウハウが Devin に閉じてしまうため。こういった情報をリポジトリ (READMEなど) やドキュメントに反映させるところまで Devin を活用できるとよさそう。

最後の方で言ってた「0→1 は人間がやる」「1→10 は Devin がやる」っていうのは今後の生成 AI 活用においても大事な視点になりそうかなと思いました。

あと、最近よく思うのは、Devin などの生成 AI を単なるツールとして捉えるのではなく、これまでのプロセスや思考を変えるきっかけにしたり、これらを活用して何ができるかっていう方向に考え方をシフトしていくといいんだろうと思ったりしています。

あとで読む。

scrapbox.io

note.com

zenn.dev

scrapbox.io

以下、メモから抜粋。

デモ

  • devin-runs
  • devin
    • 最初にコンテナ (ubuntu) を立ち上げる
    • plan (行動計画)
    • エディタ (VSCode)
    • リモートアクセス可
  • セッションごとに会話履歴は独立している
  • 覚えておいて欲しいことはナレッジとして記録できる
    • 必要に応じて自分のコンテキストに読み込む
    • コードフォーマットしたり
    • 動作確認してスクショ残してもらったり

Devin活用の成果と魅力

  • いろいろなタスクを非同期に進められる
  • スマホから作業を投げられる
    • 会議中に思い付いたタスクを投げて会議が終わることには何かができてる
  • 既存のコードを読んで仕事してくれる
  • タスクをスタートするハードルが下がる
  • 開発環境なしで開発できる
    • 普段コードを触らない人でも開発できる
    • コードが民主化された
  • 優先度が低くて後回しになりがちなタスクを消化できる

Devinの課題と実運用での気づき

  • 秘密鍵の一部が漏れる
    • コードに埋め込んで Push する
  • 開発中のスクショを全然関係ないところにアップロードしたり
  • private リポジトリの変更を public リポジトリに Push したり
  • 大きなタスクを投げて ACU 食いすぎる
    • タスク分解してから devin に投げる

Devinがもたらす未来について

  • multidevin (enterprise のみ)
  • 必要なときに必要な分だけ devin を使える
    • 人を増やすより簡単に開発リソースを増やせる
    • インフラのスケールアウトのイメージ
  • ナレッジ機能に溜め込まない
    • ノウハウが devin に閉じてしまう
    • リポジトリ (READMEなど) やドキュメントに反映させる
    • 人も devin もドキュメントからインプットにできるように
  • 人間の頭は他の人は検索できない
    • devin だとできる

QA

  • Playbooks
    • プロンプトをスニペットとして使ったり
    • コミュニティ内で共有したり
  • ナレッジの粒度
    • 細かく分けるとうまく反映されない可能性がある
    • 関連するナレッジはまとめる
    • リポジトリ (README) に書く
  • devin に向いているタスク/向いていないタスク
    • どうすれば devin が処理してくれるかを考える
    • 0→1 は人間がやる, 1→10 は devin がやる
  • 10ACU 超えるとパフォーマンスが落ちる
    • 10ACU 超える場合は PR 作成してセッションを変えて引き継いだり
  • enterprise/team
    • サポート
  • コラボラティブテクノロジー
  • Devin の思考にも ACU が掛かる
    • マウスオーバーで見れる

DBeaver の SQL 補完がアルファベット順になってて不便

メモ。どこかのバージョンアップでデフォルトが変わったんだろうか...。

バージョン24.3.3.202501191633

設定 > エディタ > SQL エディタ > SQL 補完 > Sort proposals alphabetically

現場からは以上です。

現役ソリューションアーキテクトが語る〜失敗しない新規事業開発のはじめ方〜 に行ってきた

現役ソリューションアーキテクトが語る〜失敗しない新規事業開発のはじめ方〜 に参加しました。簡単に所感をまとめます。

techplay.jp

所感

「魅力的なものを素早く」「無数にある選択肢から成功パターンを探る」「課題への検討と選択を繰り返す」といったところはまさにアジャイルの考え方なのかなと思いました。

自分の場合、規模は小さいものの要件定義から設計、開発、保守運用までやってきたので多少は勘所があるかもしれないけど、わりと自己流なのと、多くのベンダーが関わるような案件はあまりやったことがないため、そのあたりのノウハウは知りたい。

要件定義の「やることを決める≒やらないことを決める」は大事。全体を俯瞰したり将来を見据えて QCDS のどれを優先するか (どれを落とすか) を的確に判断できるようにしないと。

以下、メモから抜粋。

レジャー施設の着券業務とそれを支える技術

  • ITデバイス普及
  • ITベンダー増
  • さまざまな技術スタック
  • 選択肢が広い
    • 新規事業を始める際の課題になりえる
  • 過去
    • 安定重視
    • 既存の成功パターンに乗る
  • 現在
    • 魅力的なものを素早く
    • アップデート前提
    • 選択肢から成功パターンを自ら探す
    • 日々の進化が必要
  • 個々のスペシャリスト
    • それぞれの専門性が高まる
    • 相互のコミュニケーションの難易度が高まる
  • ソリューションアーキテクト
    • 歯車役
    • 全体最適
    • 上流工程
    • 現場課題をビジネス目線に置き換える
      • ビジネスにどのような影響があるか
  • 新規事業開発を成功に導く3つのメソッド
    • 確実性
    • 一貫性
    • 安定性
  • 確実性
    • 正しい選択を繰り返す
    • 不確定要素による選択肢の広さ
    • リターンとリスクの定量
    • 選択の先にある未来を想像する
      • 過去の成功体験に囚われないように
  • 一貫性
    • フェーズの隙間で情報が欠落する
    • 隙間を埋めるアウトプット
  • 安定性
    • リスクの早期発見
    • 突発性リスク
      • リスク観点や課題を想定したプロジェクト計画
      • 受け入れ課題 → モックによる事前説明会
      • 性能課題 → 負荷テストなど
    • 変更/追加に伴うリスク
      • 影響範囲の見極めを誤るリスク
      • 変更管理
        • 優先度可視化
      • バックアッププラン
        • ワーストケース
      • 疎結合設計
        • 影響範囲を見極めやすくする
  • 失敗パターンから学ぶ
  • ボトムアップ構想
    • ビジネス構想に対してリスクと課題を積み上げてどこまでできるか決定する
    • スピードが損なわれる
    • 確実性を求められるプロジェクト
  • トップダウン構想
    • 理想像を業務フローレベルまで作成
    • 段階的リリース+成長を目指す
  • 制約と非機能要件
    • やることを決める
    • やらないことを決める
      • 費用対効果の低い機能は実装しない
      • 制約を定める

Tidy First? を読んでみた

Tidy First? を読んでみました。

www.oreilly.co.jp

第1部は「整頓」するためのプラクティスについて。このあたりは内容的には リーダブルコード とかの方が実践的で分かりやすいと思うけど、おそらくこの本はそういう実践的な内容を紹介する本ではないんだろうと思います。なので、そういうのを期待して読むとちょっとズレるというか的外れになる気がするので、個人的にはもう少し俯瞰した視点で読むといいのかなと思いました。そういう自分も最初はわりと実践的な内容を期待してたところはあるので、ちょっと視点を変えて (特に第2部以降を) 読み直してみようかしら。

以下、読書メモ。

実際にはそうなってしまうかもしれないけど、こういう本でリファクタリングをこのように表現されてるのは少し意外でした。

3章 シンメトリーを揃える

既存のコードに手を入れる場合に、自分は既存のコードに合わせて書くことがよくあるのでこのあたりは共感できる。

ただ、途中でよりよい方法を見つけたときに、途中からその方法に切り替えるか既存のコードもまとめて変更するかが悩ましい。結局、前者を選択して既存コードは追々修正しようってなることが多い気がする。けど、結局やらない...。

5章 読む順番

読む順番は確かに大事。だけど、読む順番というか、「このあたりはこう書いてあって欲しい」みたいな期待値は個々人で違うかもって思った。こういうのはどうやって認識を合わせるのがいいだろう。あまりコーディング規約とかでがっちり固めたくないしなー。

11章 ステートメントを小分けにする

空行を入れてステートメントを小分けにするのよくやる。ソースコードには空行大事。

16章 分けて整頓する

最近は、プルリクエストは大きさよりも他のプルリクエストとの依存関係がどれくらいあるかが重要な気がしている。もちろんあまりにも巨大なプルリクエストは困るけど。プルリクエストを小分けにしても他との依存関係が多くなると全体感が把握できなくてレビューしにくい。とはいえ、いわゆる「整頓のプルリクエスト」は基本的には他のものと依存しないはず。(と思いたい)

あと、「整頓のプルリクエストではレビューを必須にしない実験」「レイテンシーを減らして小さい整頓のプルリクエストを作るインセンティブにする」というのはなるほど。これはよさそう。だけど、おそらくこれをやるならある程度は自動テストの環境を整える必要がありそう。

21章

整頓のリストを「お楽しみリスト」って呼ぶのいい。確かに楽しいもんな。

28章

可逆的な変更と不可逆的な変更。見返りの特性が根本的に違うものに対して同じ投資 (コードレビュープロセス) をしてしまっているっていうのはいい表現だなと思った。

Will, Can, Must

キャリアについて考えるときに Will, Can, Must で考えたりすることがあるけど、自分の Will ってなんだろうかって考えると、(今の職種においては) 正直、特にないかもしれない。

というより、自分は先のことをあまり考えてない。考えられない。忙しくて考える余裕がないとかではなく単純に考えられない。5年先とか10年先なんてのはもちろんで、半年後に自分がどうなっていたいかなんてこともあまり考えてない。考えてるのは明日のランチのメニューとか今週末の予定くらい。

あえて言うなら、今、目の前にあることに全力で取り組む。Must に向かって自分の Can を総動員して立ち向かう。足りない部分はそのときに全力で補う。それでも厳しいときは周りに頼る。(こういうときに周りに頼れることもある意味では自分の Can なのかもしれない)

--

自分の Will ってなんだろうかって考えると、正直、特にないかもしれない。

というか、このあたりは昔から自覚していた。かつては自分の Will がないことに焦りもあったし、そんな自分を惨めに感じていたこともある。

でも、いつからかそれでもいいんじゃないかと思うようになった気がする。

Must と Can を持ち合わせて、少しずつ自分の領域を広げながら邁進する。小さなことからコツコツと。しばらくして振り返ると自分のキャリアがある。そういう感じでいいんじゃないかと。

真摯に誠実に物事に向き合っていると周りから信頼されるようになる。信頼は新しい Must に繋がり、その機会から新しい Can を得る。自分には Will も Will not もなくて、目の前の Must に、Can を片手に立ち向かうだけ。それでいいんじゃないかと思う今日この頃。

2024年のふりかえりと2025年に向けて

ここ数年は帰省先で年末年始を過ごしてましたが、今回は家族の体調不良により帰省を断念。久しぶりに我が家での年越しでした。

2023年のふりかえりと2024年に向けて - kntmr-blog

今年からまた組織体制が変わりチームリードとテックリードを担う感じに。プロジェクトは去年から継続する感じだけど領域は少し変わる。メンバーは10名程度で、参画して間もないメンバーもいるので改めてチームビルディングからやっていきたい。

2024年初頭は、前年から続いたプロジェクトの次フェーズに向けてチームビルディングなど、いろいろと準備のために動き回っていた気がする。が、事業方針の都合でなかなか次フェーズが始められず、結局、別部署の新チーム立ち上げや技術面のサポートに回ることに。

ここでは、明確にタスクをアサインされるわけではなく、自分で課題を見つけて解決に向けて動くような感じ。具体的には、SLO の運用改善やシステムの負荷テストとか、機能開発に注力しているとこぼれがちなボールを拾って対応した。あとは、アーキテクチャや設計のレビューとか。

他にも、設計標準とか開発ガイドラインみたいなものを整備しようかと思ってたけど、そんなこんなでもともとのプロジェクトの次フェーズが始まるということでそちらに戻り、2024年中盤から現在もプロジェクトが続いている。

基本的には現行システムの機能移行がメインで、ある程度は作るものが決まっていたため、プランニングやリファインメントなどのスクラムイベントにはあまり時間を取らず、とにかく手を動かして作ることに注力した。開発自体は機能単位で分担して進めたかったけど、チームメンバーが BE メインの方だったため、とりあえずは効率重視で FE / BE で分担。結果的に自分は FE を担当することが多くなり、途中、2ヵ月くらいは FE ばかり書いてた気がする。半分以上は GitHub Copilot のおかげだけど。ただ、FE の知見は増えた。

ただ、機能開発だけでいっぱいいっぱいの状況で、SLO の運用やパフォーマンス改善ができていない...。主要な機能開発がひと段落したらそのあたりもやっていかないと。

--

2024年はあまりインプットに時間を掛けられなかった気がする。ので、2025年はもっとインプットを増やしたい。積読を消化したい。

あと、自分のキャリアを少し見直してもいいかもしれない。具体的にはそこまで考えられてないけど、これまでとは別の役割を担ったり別の道を視野に入れてもいいのかもしれないと思ったり。そんなことを考える今日この頃。

プライベートでは、2024年の夏頃から陸上部時代の友人と陸上の大会に出たりしてた。まさか約20年ぶりに400mリレーを走ることになるとは思わなかったけど、久しぶりにトラックを走ると気持ちいい。体を鍛え直してるのでたぶんここ10年くらいでいちばん体が仕上がってる気がする。2025年も続けよう。

エンジニアが一生困らない ドキュメント作成の基本 を読みました

会社の輪読会で『エンジニアが一生困らない ドキュメント作成の基本』を読みました。

www.socym.co.jp

ドキュメントを書くときにどういうステップがあって何に気を付けるかが詳しく解説されていて参考になりました。まず、読み手がこのドキュメントをどういう目的で読むのかを想定することが重要。それに合わせて構成を組み立てる。

自分は文章を書くのはどちらかというと好きな方で、あまりドキュメントを書くのを苦に感じたことはない。このブログを書いているのも、半分は文章を書く練習を目的にしている。ただ、これまではわりと自己流で書いてた感じなので、改めてこういうノウハウとして知ることができたのはよかった。

とはいえ、ノウハウを知るのも大事だけど、文章を書くことに慣れることも大事。このあたりはプログラミングも同じかもしれない。

ちなみに、こういうノウハウを解説する系の本を輪読会で読んでも、なるほどね〜くらいで話が終わってしまうことがあるような気がする。一方で、設計手法やアーキテクチャのようなテーマだと、個人の思想や過去の経験によっていろいろな解釈が生まれて議論に発展したりして、そこから得る学びも多い。

あと、本書では語彙力はなくてもいいと書かれてるところがあったけど、個人的には語彙力は重要だと思う。ないよりはあった方がいいとかではなく。読み手に合わせて表現を変えたいときに、語彙力がないと適切な言い換えが出てこないし、そもそも、語彙力が不足していると読み手に合わせて表現を変えたいという発想にならない気がしている。

以下、読書メモ。

Chapter1

感想 / 意見 / その他

  • ドキュメントを書く目的
    • 説明型 (知見や手順を説明する)
    • 報告型 (知見や活動を報告する)
    • 説得型 (意見や提案を伝えて相手の行動を促す)
  • バックログを要件定義書の代わりと捉えるのはなるほど
    • プロダクトが満たすべき要件をユーザー視点で説明する
  • ドキュメントの種類ごとにテンプレートを使う
    • 設計のコンフルは過去のものを使い回したりしてる
  • 想定読者を絞り込む
    • 目的で絞り込む (ex. トラブルシューティング)
    • 知識レベルで絞り込む (ex. 初心者向け)
    • 立場で絞り込む (ex. システム管理者向け)
  • テーマを分解する
    • なぜ (Why) / 何を (What) / どうやって (How)
    • 具体例か構成要素のいずれかで分解する

イデア / 今後こう生かせそう

  • ドキュメントを書く前にどの分類のドキュメントかを明確にする
  • タスクを作成する際はユーザー視点でのゴールを書く
  • ドキュメントを書くときは目次 (TOC) を付けよう
  • 語彙に敏感なろう (語彙に敏感になると誤字脱字にも敏感になると思う)

Chapter 2

感想 / 意見 / その他

  • ドキュメントの階層構造を理解すると効率よく読める
    • タイトル, 見出し, リード文, パラグラフ, 中心文
  • 階層構造はいいけど同階層の粒度を揃えるのがキモになりそう
  • パラグラフごとに1つの言いたいこと (+ 理由や説明) を書く
    • 言いたいこと = 中心文
  • 辞書形式, 読み物形式
  • 中心文をパラグラフの冒頭に書く

イデア / 今後こう生かせそう

  • 階層構造の階層を行ったり来たりして俯瞰しながら粒度を揃えるといいと思う (おそらくトップダウンでスムーズに最下層まで書き出せることはそれほど多くないのかもしれない)
  • ドキュメントが検索にヒットしやすいようにするとよさそう (いい感じにキーワードを含めたりコンフルだとタグとかラベルとか付けたらよさそう?)

Chapter 3

感想 / 意見 / その他

  • 読者を理解する
    • 知識レベル
    • 目的
    • 立場や役割
  • 読者の目的を絞ることで読者に合わせた構成を組める
    • 機能別, 用途別, ...
  • 誰に何を伝えようとしているのか
  • 知識は3つに分類できる
    • プロダクトに関する知識
    • 技術に関する知識
    • 業務に関する知識
  • ドキュメントの階層は4階層に収める
    • タイトル, 章, 節, 項

イデア / 今後こう生かせそう

  • ドキュメントを書く前に想定される読者と目的を明確にする
    • 知識の分類による絞り込みはよさそう
  • 構成を考える際にページを分割できるかどうかを考える
  • あるテーマに対して複数の目的 (用途) があるならページを分割する

Chapter 4

感想 / 意見 / その他

  • テーマを分解する
    • タイトル, 見出し, パラグラフ
    • テーマ, サブテーマ, 話題
  • 読み手が納得感を得られるように
  • 適切な分解方法は読み手によって変わる
  • 情報を探しやすい構成になる
    • 読み手はタイトルや見出しから当たりを付ける
  • なぜ (Why) / 何を (What) / どうやって (How)
  • 構成要素で分解する (全体から部分へ)
    • 機能の構成要素で分解する
    • 機能の用途や使い方を知りたい
  • 具体例で分解する (概要から詳細へ)
    • 利用目的で分解する
    • 自分の目的をどうすれば達成できるのか知りたい

イデア / 今後こう生かせそう

  • 3つの型 (説明型, 報告型, 説得型) ごとの なぜ, 何を, どうやって の具体例が分かりやすい
  • タスク起票するときも why, what, how で書くことある
  • 説得型はさらに when とか how much とか分けてもよさそう
  • 構成要素による分解と具体例による分解を組み合わせたい場合は、先に構成要素で分解したドキュメントを作成しておいて、具体例が関連している構成要素を参照させる形がよさそう

Chapter 5

感想 / 意見 / その他

  • 急がばアウトライン
  • アウトラインを笑う者はアウトラインに泣く
  • アウトライン
    • なぜ, 何を, どうやって
    • 何をとどうやってはどちらを先に書くか
      • 読み手にとって重要なものから書く
    • 順列
      • 内容に依存関係や順序関係があるか
      • 既知から未知へ
      • 時系列
    • 並列
      • 重要度
      • ニーズの大きさ
  • ゴールデンサークル理論
    • なぜ, どうやって, 何を
    • なぜから先に読み手に伝える
  • 書けるところから先に書くことで知識や考えが整理できる
  • 書く内容が多い要素や重要な要素には見出しを付ける

イデア / 今後こう生かせそう

  • 見出しを簡素に書きたくなるが、簡素にしようとすると見出しの抽象度が上がって結果的に本文の内容が膨らみがち
  • もう少し本文の内容を表す見出しにして本文もコンパクトにしていきたい

Chapter 6

感想 / 意見 / その他

  • パラグラフ
    • 言いたいこと (中心文) + 理由/説明/具体例 (支持文)
    • 理由/説明/具体例で読み手の納得を得る
    • 結論文で言いたいことを強調する
  • 理由や詳しい説明が必要な要素だけにパラグラフを割り当てる
    • 内容が少ないものは1つのパラグラフにまとめる
  • 並列の情報は表現を揃える
    • 箇条書きも同様 (文末や句点ありなしを揃える)

イデア / 今後こう生かせそう

  • 中心文に対してどういう支持文 (理由/説明/具体例) を付け加えるか
    • 読み手の前提知識やドキュメントの目的次第?

Chapter 7

感想 / 意見 / その他

  • 日本語スタイルガイド
  • 重要なことから書く
  • 読み手の視点で書く
    • 読み手にとってどのような価値があるか, どのような影響があるか
  • 能動態と受動態を使い分ける
    • 読み手の視点
  • 一文一義
    • 箇条書きも有効
    • むやみに箇条書きを多用しない (重要な情報に絞る)
  • 係り受けを明確にする
  • 通俗的な表現わりと好き (もちろん内部向けのドキュメントだけど)
  • 明確で簡潔で具体的な文章を書くにはやはり豊かな語彙は必要だと思う

イデア / 今後こう生かせそう

  • 係り受けを明確にする
    • 読点を多用すると歯抜けな文章になりがちなのでまずは語順を入れ替えて明確にできないかを試すといいと思う
    • 書いた文章を読み直す習慣を付けましょう

Chapter 8

感想 / 意見 / その他

  • 生成 AI の出力結果をどう評価するのかが分かりやすくて参考になった
  • この前、全社に流したリリースアナウンスは ChatGPT に書いてもらった
    • 文章と箇条書きをバランスよく使い分けてくれてよかった
  • 合成名詞を多用しない
  • 情報の構造化が大事
  • 文章の校正で修正箇所を太字にできるの知らなかった
    • どこが変わったのかが分かりやすくなっていい

イデア / 今後こう生かせそう

  • 文章を書くときは生成 AI を通すのを標準にしてもよさそう