こんにちは、デザイナーの長尾です。
最近は暖かくなってきて、子どもと一緒に外でアリを探すのがブームです。
久しぶりの行動指針記事ですが、その間にエンジニアメンバーが5人加わり、プロダクトチームは一段と賑やかになりました！ また、MVVの変更や行動指針も一部アップデートがありました。また別の記事でご紹介します。
ここからはいつもどおり、今月の取り組みを行動指針の視点から振り返ってみたいと思います。
初のAssured・yamory プロダクト交流会！（内山）
嬉しいことに、Assured・yamoryともにメンバーが増えてきました。しかし、組織が拡大していく際に工夫しないとチーム間のコミュニケーションが今後難しくなってきてしまいます。そこで、チーム間でカジュアルに知見を交換できる場を作るべく、Assured・yamoryのプロダクト交流会を立ち上げました！
毎月、勉強会 + 懇親会という形式で、LTやアンカンファレンス形式でお互いの知見を共有しつつ、チームをまたいだ交流が生まれ続けて欲しいという気持ちのもと、実施しています。
すでに3回実施してみましたが、多くの方が参加してくれて、バイナリの話から、AIの活用の話や、筋肉の話(？)までお互いの知見を共有しあっています。
「信頼で、未知を拓く。」というミッションのもと、アシュアード社としてお客様に価値を届け続けるチームを作るべく、今後もプロダクト交流会を続けていきたいと思います！
アーキテクチャを語るランチを開催（岩松）
Assuredは正式リリースから3年が経ち、多くのお客様にご利用いただけるサービスとなってきました。しかし、サービスの急成長に伴いこれまで考慮しきれていなかった課題も見えるようになってきました。
Assuredがさらに成長していくためには、システムの複雑性やパフォーマンスの懸念といった課題を解消できるアーキテクチャに変化していく必要性があるものの、そもそも今後の5年10年をサバイブし、スケールするアーキテクチャを考えるというのは非常に難しいことです。また、セキュリティ要件や顧客の要求、AIコーディングの台頭など変数も多く、一人で考えきれることではないなと思いました。
そこで、エンジニアチーム全員で考えを広げ深める場として「アーキテクチャを語るランチ」を始めてみました。考えを広げるのはもちろん、全員が主体的にアーキテクチャについて語れる状況を作り、オーナーシップを醸成する目的もあります。ただし大人数では意思決定が難しくなるので、具体的な意思決定は各チーム(レポジトリオーナー)に委ねることとしています。
この場では
- これまでのシステム課題は何だったのか
- これからどんなアーキテクチャで何を実現していきたいのか
- どんなプロダクト、サービス、組織にしていきたいのか
といったテーマで会話し、必要とあらば技術検証もしていく場にしています。この取り組みによる成果はまだまだこれからですが、乞うご期待ください！
Devin動きました（山口）
4月から、開発チームにDevinが加わりました🎉
今はまだ検証フェーズではありますが、1ヶ月間利用してみて使い勝手や実用性が見えてきたので、簡単に共有できればと思います。
Devinを使い始めるにあたって、まず立ちはだかるのは環境構築の壁ですが、普段から慣れ親しんだVSCodeの画面でクラウド上の仮想マシンに環境構築できるので、ローカルと同じ感覚で環境構築を進めることができ、約1時間ほどで作業を完了させることができました（この工程で作成した仮想マシンのスナップショットを元にDevinは作業を行います）。
環境構築を終えて、実際にタスクを依頼してみると、「このチケットお願いします」と一言を添えてGitHub Issueのリンクを渡しただけで、修正からPR作成まで見事に自走してくれました。 最初は何往復かやり取りが発生すると思っていたので、正直かなり驚かされました（タスクが具体化されており、かつ小さめのタスクだったため相性が良かったというのもあります）。
あとから知ったのですが、Devinはリポジトリ連携後に自動的にWikiを作成し、コードベースを体系的に理解することで、専門知識もかなりの精度で認識してくれるようです。
その後もいくつかタスクを依頼してみましたが、タスクが詳細化されていれば期待通りに動いてくれる印象で、最低限のプログラム知識が必要であるものの、ノーコードで開発ができる段階まで来ていると思います。
少し工夫は必要ですが、Playwrightを用いたE2Eテストを書いて、テストを実施させることも可能なようです。
実際にE2Eを動かして、テスト結果をHTMLとして出力してもらった結果がこちら
試行錯誤を重ねる中でDevinに期待値を正しく伝えるためのコツが掴めてきたので、参考までに共有させていただきます。
- Lint/Build/CI等のエラー検知の仕組みをつくる。
- シフトレフトテストの文脈で言われるように、早い段階でテスト実施することで手戻りが減り、トータルの作業時間が削減します。
- 仕組み化できなかった場合でも、作業完了時に期待される完了条件を文章で伝えることも大切です。
- 具体的かつ小さなタスクを心がけて依頼する。
- Devinは大規模なコンテキストを必要とする複雑なタスクに向かないため、タスク分割することが推奨されています。
- 同じ説明を何度も繰り返す場合はセッションを作り直してみる。
- 公式ドキュメントでも言及されている通り、Devinは 5 ACUs を超えるタスクに向きません。
- 同じ説明を繰り返す場合は、セッションを作り直して依頼内容を整理したほうが早く解決できる印象です。
- 全てをDevinに任せるのではなく、適切に介入して作業をフォローする。
- Devinに追加依頼を出すよりも自分で作業したほうが早いケースもそれなりにあります。
- Devin IDEを使ってブラウザ上でDevinの作業環境に入ることができるので、必要に応じてサポートに入ることも大切です。
- 提案されたナレッジは積極的に登録する。
- Devinは新しい知識を見つけたときにナレッジ化を提案してくれるので、共通ルール化できそうなものは積極的にナレッジ登録しています。
- 提案されるナレッジはデフォルトだと英語ですが、日本語で提案するようナレッジに書いておくと日本語になるのでオススメです。
AIの成長速度には日々驚かされるばかりですが、全部をAIで完結させようとするとかえって効率が落ちるケースもあります。人とAI、それぞれの強みを活かした運用方法を今後も模索していきたいと思います。
おわりに
この3ヶ月は、組織やプロダクトを取り巻く環境の変化に対して、「先回りして動く」ことが多かったように思います。 「プロダクト交流会」や「アーキテクチャを語るランチ」は、将来の課題を見越して動き始めた取り組みであり、「Devinの導入」は未知の領域へのチャレンジです。
できることをいまできる形で始めるという姿勢で、小さく試し対話を重ねてきました。 私たちのミッションである「信頼で、未知を拓く。」に向けて、まだまだやるべきことはたくさんあります。共に考え、手を動かしながらプロダクトを育ててくださる仲間を募集しています。 今回のブログを読んで少しでも興味を持ってくださった方は、ぜひ採用情報をご覧ください。
