AI時代に始める大企業での内製開発──知識を土台に、小さなチームが挑む

AI時代に始める大企業の内製開発
知識を土台に小さなチームが挑むと題しまして
株式会社マルイユナイトの中島が発表させていただきます
簡単に自己紹介させていただきます
改めまして中島と申します
経歴としてはスマホゲームの共通基盤サーバー開発であったり
モバイルオーダーのプラットフォーム開発であったり
サーバーサイドエンジニアとして基盤系開発をやっていた経験が長いです
フリーランスで01開発の案件を何件かやった後に
マルイユナイトに入りました
ちなみにこのアイコンは15年くらい前に
お絵かきソフトで書いたものなので
非常に解像度が荒いのですが結構気に入って使っています
名前はペリー君という名前です
本日はよろしくお願いします
まず弊社マルイユナイトの紹介をさせていただきます
聞きなじみがない名前かなと思うんですけど
マルイユナイトはマルイグループのテックカンパニーとして
去年の9月に設立しました
マルイというとまずこのような商業施設を想像される方が多いかなと思います
ちなみにこの画像はこの近くにある中のマルイの写真です
もしこの後お時間ありましたら立ち寄っていただけると嬉しいです
またエポスカードも事業の柱になっていて
以前からフィンテック事業をやっている会社であります
左のエポスカードだったり
自分のペットの写真を印刷したエポスペットカードだったり
ちょっとユニークなカードだったり
エポスアプリといった事業をやっています
というようにマルイグループは
フィンテックと小売を事業アセットとして持つユニークな会社です
マルイユナイトはそれぞれの領域の
フィンテックと小売のDX推進をミッションとして立ち上がった会社で
今回は小売側のお目見えというサービスでの開発について
お話しさせていただければなと思っています
お目見えはマルイへの出展をオンラインで簡単に完結できるサービスです
マルイの店舗内に出展できるスペースというものを検索ができて
そこから問い合わせ契約までのリーシングフローというものを担当します
スモールプロダクトとして立ち上がったものなので
現在はサースで動いています
そんなお目見えなんですけど
プロダクトの事業検証も進んで
店舗ビジネス全体のDX化をさらに推進していこうとなったときに
サースではカバーしきれない課題が出てきました
マルイグループはフィンテック事業をもともと持っていて
システムを持っているんですけど
開発は外注してきたんですが
このタイミングでマルイユナイトが立ち上がったため
思い切って内製開発することを決定しました
こうしてマルイでの初の内製エンジニアによる新規開発がスタートしました
4月から始まったこのプロジェクトですが
エンジニア組織が立ち上がって間もないので
エンジニア2人と少数体制で
それに対して作るものが結構たくさんあって
かつスケジュールが厳しい
生産性を上げてくれるような開発基盤なんてもちろんないという状況でした
さらにCPUからはゆっくゆっくはお目見えを
新たな機関システムにすることも見据えているので
いいものを作ってねという
ワクワクするようなミッションを与えられました
正直数年前だとかなり厳しい開発になるというのが
予想される状況なんですが
今はAIがあります
マルイエナイトではエンジニア組織全体で
AI駆動開発を行っていこうとしています
AI前提で開発フローを組んで
少ない人数で成果を出すということを目指しています
既存の組織だと一気にAI中心に変えるというのは
ちょっと難しいところもあるかなと思うんですが
AIが当たり前になった後に立ち上がった組織だったので
そのあたりは共通認識を取りやすかったです
ツールとしてはクロードコードとカーソルを使っています
いわゆるJTCと呼ばれる伝統的な日本企業であったので
初めの頃はAI2の利用許可を通す
簡単ではなかったんですが
このあたりはCTOの頑張りで
これらがある状態で開発がスタートできました
そうやって手に入れたクロードコードカーソルは
リポジトリをしなに読み込んでくれるらしいと
とにかくいろんな情報をマークダウンファイルで
リポジトリに集約すれば
バックスク開発ができるはずと思って
しばらく開発してたんですが
さすがにこれでは甘くて
期待していたような成果は出ませんでした
まずシンプルに開発速度が期待よりは上がりませんでした
よく言われることなんですが
7、80点くらいのクオリティのものまでは
生成されるのですが
その後結局人間による手直し
が必要になって
トータルでそこまで早くならないという状況でした
ドメインエキスパートからの
ヒアリング内容を
そのまま雑多に貯めるだけでも不十分で
使えるドメイン知識になっておらず
AIに理解できる形で
情報が構造化されていない
というようにもなっていました
またチーム内でも
AI利用のやり方もバラバラで
共通のルールや基準がなくて
品質のばらつきが多いという問題もありました
そんな中であったのが
コンテキストエンジニアリングという考え方でした
コンテキストエンジニアリングとは
AIが高品質なアウトプットを出すために
適切な形で
適切な知識を適切な形で提供する技術です
AIを使うテクニックとして
プロンプトエンジニアリングが有名かと思うんですけど
直接的な指示をどういう表現で与えるかというのが
プロンプトエンジニアリングですが
コンテキストエンジニアリングは
AIが自律的に動けるように
必要な知識を整えて
命令を実行するときに
何を使うべきかを指示するものです
こういうコンテキストエンジニアリングという考え方に触れたんですが
これを実践するとなったときに
実践の仕方は様々あるかなと思っていて
自分たちに合った形は何かということを考えた結果
AIにいい仕事をしてもらうために
コンテキストを整える
コンテキストを使い分けるということをやりました
どういうことか一つずつ説明していきます
一つ目のコンテキストを整えるについてです
AIに開発してもらうために
コンテキストとなる知識を揃えていくということなんですが
具体的には開発ルールとアーキテクチャを明確化する
要件や設計をまとめる
ドメインモデリングにより知識を構造化するという
この3つに取り組みました
まず開発ルールとアーキテクチャを明確化するということで
既にやられている方は多いのかなと思うんですが
コーディング規約や設計方針を言語化して
クロード.mdやカーソルルールズとして
まとめることをやっています
例えばバックエンドだとアーキテクチャ
コーディングルールエラーハンドリングテスティングと
流度様々なんですが
割と詳細に定義してルール化しています
また一般的なアーキテクチャを採用することも大事だと思っていて
バックエンドだったらオーニングアーキテクチャや
フロントエンドだったら
アトミックデザインというものを選定しており
オレオレなものではなくて
一般的に知られているものをできるだけ採用することで
AIへの説明コストを下げる狙いがあります
要件や設計をきちんと
要件定義書とかデザインドックとして
言語化してテキスト化するということもやっています
キロなどを使った使用食堂開発が
トレンドになっていると思うんですが
現状は機能要件の決定は
分担としてビジネスチームがやっていることもあって
まだその点はAIが活用できていないというのが現状です
ただ人力でもマークダウン化しておくことには
価値があると思っていて
例えばテキストにした画面仕様をもとに
デザイナーがカーソルで
フロントエンドのマークアップを作っていたりもします
次はドメインモデリングにより
知識を構造化するということですが
マルイにおいて私たちが関わっているゴール事業は
長い期間をかけて培われてきたもので
豊富なドメイン知識や確立された業務があります
この複雑さに立ち向かって事業にとって役立つシステムを構築するために
ドメイン駆動設計の考え方を取り入れて開発しています
かの有名なDDB本にはモデルとは選び抜かれてシンプルにされ
意図的に組み立てられた知識の表現形式であるとあります
私たちの開発ではドメインキースパートからイヤリングした
ドメイン知識が開発の源泉となります
プロダクトに必要な知識を下選択して
ドメインモデルを作ることで
AIが理解しやすい構造化された知識になります
このドメインモデルが
ドメイン知識とAIによる実装をつなぐ
接合点になるのではないかなと思い
ドメインモデリングを丁寧にやっています
細かい話なんですが
画像よりもテキストの方が
AIは理解しやすいので
こういったマーメイド記法で
モデルを書いています
左のものはテキストで
右はビジュアル化されたモデルなんですが
これをすることで
左のテキストでAIが理解しやすいようにして
右側のモデルで
人間も理解しやすいようにしています
以上がコンテキストを整える
ってやっていることでした
おさらいなんですが
開発ルールとアーキテクチャを明確化する
要件や設計をまとめる
ドメインモデリングにより
知識を構造化する
ということについて説明しました
次にコンテキストを使い分けるについてです
ラングチェーン開発者の
ブルーブルーニングさんによると
AIエージェント構築には
コンテキスト中毒
コンテキスト注意3万
コンテキスト混乱
コンテキスト衝突
という4つの失敗モードがあるそうです
このうち2つ目の
コンテキスト注意3万
は
コンテキストが長くなりすぎて
AIが重点をつかめない失敗
3つ目のコンテキスト混乱は
関係ない情報が無駄に混入し
出力の失敗が落ちる失敗
出力の品質が落ちる失敗
コンテキストが少なすぎるのも問題ですが
多すぎても良くないという問題があります
それを避けるために
要件定義 設計 実装
そういった各工程で
必要なインプットとアウトプットを定義して
やることをシンプルにしてあげることが
大切だと思っています
工程が進むにつれて
曖昧な知識を
逆三角形的に
制約された知識へと
落とし込んでいくイメージです
要件定義フェーズだと
ドメイン知識や要求といった
曖昧な情報を与え
要件定義書として
アウトプットする
その要件定義書を
設計フェーズで
開発ルールと一緒に
インプットとして与えて
デザインドックや
ドメインモデル
APIスキーマとか
DBスキーマとか
をアウトプットし
ある程度構造化された
このような知識を
実装フェーズで与えて
実装してもらうという感じです
こちらのコンテキストエンジニアリングイントロ
というリポジトリは
最近見つけたものなんですが
コンテキストエンジニアリングの
考えに沿った
開発のワークフローを実現する
ツール群が揃っている
リポジトリです
要件に対して
必要なコンテキストの参照先を
きれいにまとめた
プロンプトを作ったりできます
実装フェーズだと
どうしても
インプットが与える
コンテキストが多くなってしまう
言いがちなので
この辺りをうまく整理してくれるので
なかなかいいなと思って
使っています
AIには
伴奏と
委託の2つのモードがあると
言われていて
伴奏は対話しながら
直列開発
コントロールや状況把握の度合いが
高いもので
委託はAIにお任せして
並列開発
コントロールや
状況把握の度合いが
低いという特性があります
私たちの開発では
要件定義と設計は
伴奏
人間が中心となって考える
AIは壁打ち相手として
カーソルを主に使ってやっています
実装は
実装は委託の使い方をしていて
実装できるコンテキストを与えて
少ない指示で
並列に開発することを目指しています
実装は主にクロードコードで
並列に作業させています
こうすることで
人間が考えて
AIに任せるといった分担ができて
品質を担保しながら
開発生産性の向上を
実現できました
以上が
コンテキストを使い分ける
ということでした
具体的には
開発工程ごとに
必要なコンテキストと
成果物を定義する
伴奏と委託を使い分ける
ということをやりました
このように
コンテキストを整える
コンテキストを使い分ける
といった
AIにいい仕事をしてもらうために
いろいろやってきたんですが
その結果
なんとか3ヶ月ほどで
ファーストリリースに
間に合わせることができました
ちゃんと測ってないんですが
体感で
AI使うと
2,3倍くらいのスピードが
出ている気がします
ここまでいろいろ
説明をしてきたんですが
コンテキストを整備して
ドキュメントとか
コンテキストを整備して
フローを整える取り組みは
AI関係なく
行われているものではあります
ただ
暗黙地を明文化する作業は
一定のコストがかかり
ある程度の規模化にならないと
価値を発揮しづらいものでも
なりました
しかし
AIによる開発が一般的になった今
コンテキストを整えることは
早い段階から
価値を発揮するのではないかと考えています
今回のお目見えの開発でも
強く実感できました
また
開発の過程で
作成した知識は
AIにとって
高品質なコンテキストとして
蓄積できて
将来の投資にも
なるとも思っていて
AI時代において
知識がプラットフォームになるのではないかなと
思っています
今回揃えた知識は
AIの開発生産性を上げるための
プラットフォームにもなりますし
知識を蓄積していくと
繋がりのあるコンテキストになるとも思っています
例えばドメインモデルは
システム全体を表現するコンテキストマップに
要件定義書やデザインドックは
過去の連続した意思決定の記録になります
このような繋がりのあるコンテキストを
AIに与えることができると
設計時など
高品質なアウトプットを
出してくれるのではないかなと思っています
またこのように蓄積された知識は
AIだけではなくて
プロダクトに関わる全ての人が
アクセスできる
組織の知識ベースになっていくのではないかなと
考えています
まとめです
AIにいい仕事をしてもらうテクニックとして
コンテキストを整える
コンテキストを使い分けるということを
私たちはやってきました
コンテキストを整えるについては
開発ルールとアーキテクチャを明確化する
要件や設計をまとめる
ドメインモデリングにより
知識を構造化する
コンテキストを使い分けるについては
開発工程ごとに
必要なコンテキストと
成果物を定義する
伴奏と委託を使い分ける
ということをやりました
もしAIが思ったように動かないなだったり
コンテキストエンジニアリングやってみたいなという方がいらっしゃいましたら
これらのどこから始めてもいいかなと思いますので
よかったら何かしら持ち帰って
実践していただけると嬉しいです
私たちのチームは
コンテキストエンジニアリングを実践することで
少ない人数でも品質を担保しつつ
生産性の向上が図れています
AI活用といったら
AIレビューやテスト
ガードレール設計など
まだまだやれる領域は
たくさんあるかなと思っているので
様々な分野で
AI活用を挑戦していきたいなと思っています
最後にエンジニア絶賛募集中です
AIを使って少ない人数で成果を出す仕組みづくりは
頑張ってやっているんですが
やはりエンジニアが溢れると
やれることが多くなるので
今回の話で
少しでも興味を持っていただけたり
方がいらっしゃったら
カジュアル面談からでも
お気軽に応募していただけると嬉しいです
発表はこれで終わります
ありがとうございました
はい ありがとうございました
ではですね
QAが何点か来ているので
ご回答いただきたいなと思っております
まず上からですね
カーソルクラウドの方が
GitHubコパイロットよりも
マークダウンからコンテキストを読み取る力は
上なのでしょうか
コパイロットではマーメディを読み込ませるという
例を聞いたことがないので
というところをちょっと教えていただきたいなと思っています
はい ありがとうございます
そうですね
実際ちょっとちゃんと比較はしたことがないので
ちょっとやってみないとというところがあるので
ちょっと上
GitHubコパイロットより
カーソルクラウドの方が
上だから使っているというわけではないんですが
そうですね
どの生成AIでも結構
うまく読み込んでやってくれるのではないかなと思っています
ありがとうございます
はい テストコード生成とかもAIが得意なものだと思っていますが
テストのAI活用はされていますでしょうか
はい テストは
そうですね 単体テストとかインテグレーションテストは
常に書くようにしていて
そのテストコードを生成の時に
もうアプリケーションコードを書くのと一緒に
テストコードも一緒に生成させているので
自然と書いてくれています
すごく助かっています
あとはテストコードのルールとかもある程度決めていて
参考コードみたいなものは結構作り込んで書いて
これを参考に作ってっていう風にすると
ある程度精度良くあまり手直しがない状態でできるような体制にはしていますね
はい ありがとうございます
では次の質問としてコンテキストの整備
その例自体にAIを使うことはありますでしょうか
はい そうですね
要件定義とかデザインドック
要件定義は結構ビジネス側にお願いしているところもあるんで
そこまでできてないんですけど
デザインドック作るときは
もうAIと対話しながら
最初に叩きを作ってもらって
それを修正していく
最後仕上げるみたいなところで結構使ってますね
はい ありがとうございます
次に要件定義や設計と開発にかけたリードタイプの割合はどれくらいでしたかと
私の印象では開発よりも要件定義や設計に多くの時間を使っているように思いますが
実際の体感としてどれくらいの比重だったのか可能な限り
可能な範囲で教えていただけたらというところです
そうですね
確かに要件にかける時間の方が結構多かったなという体感はあって
6対4か7対3かそれぐらいのイメージですね
ありがとうございます
本社ではドキュメントはどのくらいため込んでAIに読み込ませていますか
コアドメインに関わるような一定性の一屈性のあるような情報を読み込ませることに躊躇しています
プラットフォームエンジニアリングとしてAIをラップして情報を守るようなケースもあるかと思いますが
いかがでしょうか
はい
そうですね
あの
コアドメイン
そうですね
人屈性の高いような情報とかはあまりドキュメント化するということはしてないので
このあたりはちょっとまだ今日使ってやっていることはないですね
はいありがとうございます
では次に
少人数で開発できたという事例として
経営層が上々だったと思いますというところで
その中でエンジニア募集されているのは印象的でした
間隔あと何人ぐらい必要でしょうか
そうですね
やっぱりいればいるだけ嬉しいなと思っているんですけど
そうですね
数十人規模ぐらいにはとりあえずなれると嬉しいなと思っていて
今
小売側は2名とかなんですけど
もう片方のフィンテック側も数名という体制なので
もっと増えるといいなと思うのでよろしくお願いします
はいありがとうございます
次にコーディング規約開発ルールを明文化して
チームウェアと合意するために何か工夫したことはありますか
そうですね
これはもともとどんどんAI使っていきましょうという
合意は最初から取れていたので
個人で使うんじゃなくてチームで使うために
ルールとかを一つのリポジトリに集約して
全員でそれを使うという
合意は取って
あとその一回作っただけじゃなくて
何ですかね
改善ループを回してやっていきましょうということでやってます
はいありがとうございます
要件定義や設計のMDファイルは
どのような流度で作成されていますか
機能単位やタスク単位などというところになります
そうですね
今は結構新規開発の経路が強いので
機能単位である程度まとまった単位でやってます
もう少し開発が進んで
メイン機能じゃなくて追加の機能とか
タスクが生じたときは
そのタスク単位でやることにはなるかなと思います
ただ小さい
結構もう要件定義とかせずに
サクッと終わらせちゃえるようなタスクとかは
ここまでしっかりしたフローを組まなくても
もうバシッといきなりクロードコードに任せちゃうとかも
ありなのかなと思っています
はいありがとうございます
まだ少しお時間ありますが
何か質問されたい方とかいらっしゃいますでしょうか
はい
ではですね
ご清聴ありがとうございました
改めて拍手をお願いいたします
ありがとうございました
会場 拍手