どこに入ったの？
ファストドクターのtoBサービスを提供しているシステムの開発チームに入りました！🙆♂️
うちはAI駆動開発振り切るぜ！それができる人材は今後希少価値になっていくと思うぜ！
ってCTOの西岡さんとEMの宮田さんが面談の際に仰っていて
これは、自分も波に乗るいいチャンス！と思って参画しました。
ファストドクターのAI駆動開発環境についてはこちら👇
今の実情、入って1週間の仕事は
コードリーディング/実装や調査/AIに指示出しが
3/2/5 (今までなら5/3/1 + 1 ※直接仕様確認&ついで雑談ｗ)
くらいの割合になっています。
AIに聞く機会が増えましたね〜🤞
まぁ、これまではどうAIを頼ればいいか分からなかったのもありますね。
ぜひ以下も読んでみて、なんだか開発体験良さそうだなーと思ったら
ハートを押してくれたら、もっと記事書くモチベーション上がるので
お願いいたします。笑
どんな開発環境なの？
Railsがコアなシステムとして構築されています。
マイクロサービスも存在し、そちらはNestJSで書かれています🧐
フロントは元々はVueで書かれており、まだ残っているのですが、
最近のマイクロサービスや一部をReactで書いてる感じです。
今後はReactに寄せる方針のようです💡
ちなみにこのチームで今5つほどのタスクをこなしたのですが、
コード調査や実装、レビュー依頼にかける時間は
正直感覚値として今までの三分の一くらいになっています。
2018年頃から開発している、息の長いサービスかつ、
後述のシステムの複雑さを考えると破格のキャッチアップ速度
だと勝手に思っています。
もちろん、キャッチアップ含めたコードリーディングや
ローカル画面の動作確認を含めたらもう少し増えますが、
それでも、やはり不具合調査の特定の速度は今までより
簡単になっているなと感じています。
医療ドメインは業界特有の仕様がなかなかに複雑
仕様を理解するにはあまりにも把握しないといけない業界知識が多く
医療というドメインでも地味に色んなサービスを展開しています。
- 往診
- オンライン
- toB向け機能
- 外部カルテの操作
- 点数計算による決済
...etc
さらにそれぞれが絡み合ってサービスとして機能する
というケースも多いので、網羅すべき範囲がとても広いです。
1週間やそこらで把握できるほど簡単ではありません。
多分、1〜2年前のAIの力がない時代だったらサービスの
全体像を把握するのにフルフルキャッチアップでも
1ヶ月で足りるのか？という所感です。
さて、自分は一体いつになったら戦力になれるのか...?
と思っていましたが。🙄
Cursorのルールが充実してます
詳細はあまり見せられませんが、一例として。(一部ぼかしてます)
docの中にナレッジを溜め込んで行っています。
まだこれから充実させていくドキュメントもありますが、すでに結構な量の
仕様や、設計観点などを記述したドキュメントがあります。
もはやREADMEより充実している...w
ちなみに、Cursorのルールも結構細かく分けていました。
細かく分けることで、Cursorが読み飛ばしをしなくなるのかも、という点で、
今後自分の個人開発にも取り込んできたいと思いましたね。うん😊
後、なるほどと思ったのは、その仕様書も、Cursorに清書してもらって、
Cursorが読みやすい形式にしていることですね。
これをみて、さっそく自分のプロジェクトでもdoc/〇〇.mdを作成して、
doc/〇〇.mdをCursorが読み込んだ時に理解しやすい形式に
修正してください。
と指示を書いて書き直してもらいました✍️
PMもCursorでJiraのチケットを書かせてます
多分、いずれ記事を出してくれるとは思うのですが😇
同じチームのPMもNotionやSlackの中身を元に、
機能改善や不具合の内容をCursorで要約し、
Jira MCP経由で転載させているようです。
(渡邊さん、待ってますｗ)
そのため仕様のフォーマットがある程度揃っており、
こちらも読みやすい形になっています。
もちろん、Cursorに最適化したフォーマットなので
そのまま Cursorに読み込ませても正しく認識されます。
※ もちろん、まとめた仕様に誤りがあれば元も子もないですが、
そこは一応PMに都度確認して修正してもらっていますw
僕はチケット読み込んであとはCursorに調べさせてます
事前設定
1: ここでAPIトークンを発行 2: mcp.jsonに以下の記述追加
※ atlassian 公式 の MCPサーバーもβ公開されたので移行予定
{
"mcpServers": {
"mcp-atlassian": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"JIRA_URL",
"-e",
"JIRA_USERNAME",
"-e",
"JIRA_API_TOKEN",
"ghcr.io/sooperset/mcp-atlassian:latest"
],
"env": {
"JIRA_URL": "JiraのURL(https://(会社アカウント名).atlassian.net/)",
"JIRA_USERNAME": "Jiraのアカウント名(アドレス？)",
"JIRA_API_TOKEN": "発行したトークン"
}
}
}
}
以下のような指示を出して、Jiraに書かれた仕様を読み込ませ
実装方針を出してもらいます。（軽微そうなら実装までやってもらう）
use mcp-atlassian
【<https://JiraのチケットのURL>】
こちらを読み込んでください。
その上で、チケットの概要を要約してください。
その後、コードを俯瞰的に確認して修正箇所を特定してください。
そしたら、修正の実装方針を提示してください。
まだMCPの接続が不安定な時があり、たまに「設定がありません」とか
抜かしたこと言ってくる時があるので、その時はスイッチをON/OFF
切り替えて再度接続してみたり、Cursorを再起動してみてください。
(設定が問題なければ、画像のように青ランプがついていると思います)
そして、その内容を元に直したコミットをプッシュ。
まぁ、元々複雑なシステムになっていることもあり、
完全一発OKとはならないですね。
ただ、どこが修正対象のファイルか？あたりは
ちゃんと特定してくれるので、自分もコードを読んで
怪しい箇所を特定して、画面で動作確認とかしてみます。
やはりどこまでいっても、ある程度の仕様を把握していないと、
安心してレビューには出せないのはまだ変わらなそう。😅
「嘘を嘘と見抜けない人はインターネットを使うのは難しい」
とどこかの2ちゃんねる創設者が言ってましたが、
そのくらいの「目」を養うことは、AIが発展していっても
大事になってきますね。
そんで、動作確認も問題なさそうで、無事にテストが通ったら
GitHubでとりまサクッとドラフトのブランチを作ります。
CursorからGitHub MCP経由でPRも編集してます
事前設定
1: ここで事前にトークン発行
2: 権限はこんな感じで設定していました。
3: mcp.jsonに以下の内容を追記
{
"mcpServers": {
"mcp-atlassian": {
...(中略)
},
"github": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "発行したトークン"
}
}
}
}
以下の指示をCursorに出します。
use github
use mcp-atlassian
【<https://ドラフトブランチのURL>】
このPRを読み込んだ上で、実装内容を把握してください。
その上で、
【<https://JiraのチケットのURL>】
こちらを読み込んでください。
その上で、GitHubのPRのタイトルを、以下の形式にしてください。
feat: [【チケットID】] 【チケットタイトル】に変更してください
例:
feat: [TOB-〇〇] 開発環境の構築
descriptionも元のフォーマットに追記する形で、
レビュー観点とJiraのURLを添付していただけますか？
これで自分が頑張って書くより網羅されており、
フォーマットに沿ったPRの内容を担保できます。
レビュアーも、そのPRをそのままCursorに読み込ませてレビューすることも可能です。
毎回descriptionを書くのとかめんどくて適当になっていることも多かったので、
これやってくれるのはありがたい。🙌
これから、さらに自動化したいなと思う事
うちではreviewが通った後に、QAエンジニアに、Heroku上にブランチ単位で立ち上がった環境を伝えてQAを依頼しています。
なので、例えば
- Heroku MCPで、対象の環境のURL取得
- JiraとGitHubのMCPで実装内容とレビュー観点を要約
- Slack MCPでQA依頼の投稿
とかができたらいいなと思ってます。
あと、これを参考に、個人のプロダクトのrulesを以下のように書き換えました。
- Railsの実装に関する修正を行う場合には`doc/backend.md`を参照してください。
- openapiの実装に関する修正を行う場合には`doc/openapi.md`を参照してください。
# やり取りが発生し、修正した実装と異なる指摘がユーザーからあった場合
追加のやり取りで発生した指示の内容や実装に関しての結果を経て得たナレッジ、
規則やルールはdocディレクトリの適切なファイルに追記するようにしてください。
元々Cursorが.mdcファイルの操作をしてくれないので、
毎回書き込むのやりにくいなと思っていましたが、
こうすれば、勝手にナレッジを溜めてくれるやん！
そんで勝手に、溜めたナレッジ参照してくれるやん！
ええやん！
って一人で興奮していました😏
ちなみに、同じチームのTLがこの環境構築の裏話をしてくれています✨
p.s
まだ僕は1週間しかいないのである種フラットな状態ですが、
これからAI駆動開発をもっと推進できる側に行きたいぞ！
もっと自分が描かなくてもいい環境を作りたいぞ！
栗田さんと働いてみたいぞ！
って方がいたら、よければ覗いてみてはいかがでしょう？
Discussion