はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、gitlogの
LLMの使い方で、よく使っているのが、人間が制作したものをAIに簡単にチェックしてもらう、ということ。 以前作った、ブログを批評してくれるイルカは毎日常用している。 1つの文章を見てもらうだけでなく、2つの文章間に齟齬や、矛盾がないか見てもらう、ということも、たびたびやっている。 人にドキュメントを見せる前などはとくにそう。 同僚にチェックしてもらう前に、ちょっとした誤字とか、ここが意味不明です、みたいなところにつっこんでもらうと、最低限の品質を保てると考えている。 2つの文章を見比べるシチュエーションは、以下のようにいろいろと考えられる。 実装とテストの内容に齟齬がないかチェックしてもらう 実装とドキュメントの内容に齟齬がないかチェックしてもらうエンジニア向けと企画メンバー向けのドキュメントを見比べてもらう 自分のもとに届いた、受け取った情報と、自分の返答の流れがおかしなことになってな
AI駆動開発勉強会 臨時回【Devin Meetup Japan #1】
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは。主に XにてAI駆動開発について発信している熊井悠 です! さて今回の記事ではAI駆動開発の組織を1年ほど運営してきた経験を踏まえて失敗や学びを共有したいと思います。 補足:AI駆動開発AI駆動開発とはAIソリューション(CursorやWindsurfなど)を利用したシステム開発の通称です。最近は書籍も増えており一般化しつつある用語ではあります。 主に2024年の春頃からAI駆動開発組織として受託開発プロジェクトを中心にシステム開発に取り組んできました。1人での開発ではなくAIコードエディタ(Cursor)を開
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?AI搭載エディタCursorを色々と試しているのですが、これが非常に興味深いです。 普段の開発業務はもちろん、少し工夫することで、要件定義のような上流工程も大幅に効率化できるのではないか?という気づきがありました。本日はその試みについて、私が行った具体的なプロセスと合わせて共有できればと思います。 概要不動産テック業界に限らず、SaaS開発などに携わっていると、日々さまざまな要望が寄せられますよね。 「ここにこんな機能を追加したい」「あの画面のここをこう変更してほしい」といった具合です。 そして、それらを適切に実現するためには、まず
今や、AIを活用してソフトウェア開発すること自体は一般的になり、一種のブームと化している。 しかし、Web上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。 俺たちが本当に知りたいのはテトリスの作り方じゃねえ!現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ! ということで、まずは弊社から現時点のノウハウを全公開しようと思う。 弊社ではCursorを1年以上活用(サービスがGAになったタイミングから全社員で利用)しており、一定のノウハウを蓄積してきている自負がある。ただ、あくまで一例ではあるので、ぜひみなさんの現場での活用事例も共有してほしい! 免責事項AIエディタでの開発は、LLMとAIエディタの進化に伴い、常に変化している。 そのため、この記事で述べる方法論は、現時点での、弊社での
※この記事は、2024 Speee Advent Calendar 22日目の記事です。 前日の記事はこちらになります。tech.speee.jp はじめに 初めまして、2022年度新卒でSpeeeに入社し、現在Housii(ハウシー)という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。 今回は、自分の実体験を元にした記事を書いてみました。 開発物を日々沢山リリースしているものの、イマイチ「事業の成果」に向き合えていないと感じるエンジニアの方々にとって、少しでも今後の動き方の参考となる記事になれば幸いです。 目次はこちら はじめに なぜか「事業成果」から遠ざかってしまう問題 「価値ある顧客体験」を軸にした成果定義へのアップデート 1. 事業の解像度の向上 2. 施策のプランニング周りの動きの改善 3. 「見るポイント」の変化 「事業成果」に
筆者自信、個人開発を長い間やってきた&toB含め多くの開発に携わってきました。もともと開発速度に自信があり力でねじ伏せるタイプでしたが、それでもこのCursorを使い始めて世界が変わりました。具体的には、よくあるAI驚き屋の「3分でLPが作れた」「24時間AIが自動で」とかではなく、実践的な開発で6~10倍程度のスピードが出せるようになりました。序盤は10倍どころかとんでもない速度で仕上がっていきます。 筆者はAI駆動開発にハマり、1500時間くらいCursorを使い込んできたので、その経験を踏まえて現状をしっかり解説します。 この記事を読むとわかるCursorの持つ可能性 「コードを書く」から「AIがコードを書き、開発者が補助する」すべての機能 基本はProプラン$20で何でもできる 0→1開発から複雑な大規模プロジェクトまで、Composer Agent がマジでやばい ここ数年でGi
はじめに こんにちは、UbieでQAエンジニアをしている ackey です。 昨年の12月よりアプリチーム全体の開発・運用生産性改善を担うチームに所属しています。本記事では、AIエージェントを使ったテストコード生成におけるちょっとした工夫事例をご紹介します。 2025年初頭時点での試行錯誤の記録として、また、生成AI時代を生き抜こうともがくQAエンジニアの取り組みとして参考になれば幸いです。AIエージェントとのやりとりで感じた課題UbieではCursorやClineなど開発AIエージェントのトライアルを一部のプロジェクトで開始しており、もはやAIエージェントなしの開発スタイルには戻れない状態になりつつあります。 アプリチームでもAIエージェントの利用は活発で、新機能開発からテストコードの生成まで幅広く活用されています。QAエンジニアの私も主にテスト作成文脈[1]でAIエージェントを活
Autify Genesisは、生成AIを活用してプロダクトの仕様書からテストケース・テストシナリオを自動生成するソリューションです。
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 (Vモデルが必須と明言しているわけではなく、極端な例ですが)例え
この話の重要なポイントは、 会社全体の機械をフルパワーで製造したほうがp2の製造能力は下がり、リードタイムも悪化してしまう ということである。そして、 フルパワーで製造してしまうほうが余計な在庫を持ってしまい、在庫コストも発生する ということである。したがって、ボトルネックを最初に特定し、そこから逆算ですべてを考えろ。というのが、制約理論の本懐である。 非ボトルネックの非経済性 ここには、もう1つの学びがある。 ボトルネックの処理能力を超えて、非ボトルネックを働かせるな。休ませろ。 ということである。 p2の製造ラインのみを取り出して考える。この時、Aを20個/時のフルパワーで製造する。しかし、Cが5個/時でしか製造できないため、Aは15個/時で在庫を作り続け、在庫の管理コストが発生し、非経済的になる。 また、フルパワーで製造した場合の、Dにかかわる部分だけを取り出してみる。Dは、B2から
From LLMs to LLM-based Agents for Software Engineering: A Survey of Current, Challenges and Future Haolin Jin, Linghan Huang, Haipeng Cai, Jun Yan, Bo Li, Huaming Chen Haolin Jin, Linghan Huang and Huaming Chen are with the School of Electrical and Computer Engineering, The University of Sydney, Sydney, 2006, Australia. (email: huaming.chen@sydney.edu.au)Haipeng Cai is with the School of Electrica
みずほフィナンシャルグループ(FG)は2023年6月、富士通と共同でシステム開発・保守における生成AI(人工知能)の利用を目指した実証実験を始めると発表した。システム開発および保守に関わる品質や、障害が発生した際の迅速な復旧(レジリエンス)力の向上を狙う。 「IT人材の不足が叫ばれる中、5~10年先に現在のようなシステム安定稼働の体制を維持できるのか」。みずほ銀行の山口和哉ITシステムグループ副CIO(最高情報責任者)は、危機感をにじませる。将来にわたる課題に対応するため、いち早くノウハウを吸収するべく手を打ったのが生成AIの活用だ。 具体的にはシステム開発段階において、設計書のレビュー業務を生成AIで支援する。過去のレビュー表やレビュー観点のノウハウを基に、生成AIが設計書の記載間違いや漏れを自動検出し、開発品質の向上を目指す。 「MINORI」の一部システムが対象 第1段階では、みずほ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く