日本におけるスタートアップエコシステムの活性化を目指して

田中：本日は「スタートアップに選択肢を──生成AIを活用したセカンダリー事業への挑戦」と題し、金融系の新規開発における開発プロセス改善とAI活用法、そしてそのノウハウを全社展開する取り組みについてお話しします。

前半は私、田中がプロジェクト概要と開発プロセスの変革を、後半は佐野が生成AIの具体的な活用と組織展開についてご説明します。



まず、私たちが取り組むセカンダリー事業とは、スタートアップなどの株式を非上場時に売買できる取引所を立ち上げる事業です。これによりストックオプションをもらった方が上場前に換金できるようになり、優秀な人材がスタートアップにチャレンジしやすい環境を実現します。

今回はそのプロジェクトの特徴というところですが、やはり金融系システムということで、さまざまな規制が厳格化しております。多くの法や制度をしっかり守らなければならず、それを証明するためのシステム監査も受けなければなりません。
そしてセカンダリー取引所を作るということで、前例があまりないため、そもそもどの要件が正しいのかを試行錯誤しながらゼロから作っていく必要があります。



※2024年6月時点

時間軸に沿ってお話しすると、昨年6〜7月に開発を開始し、11月頃に開発プロセスを大きく変えました。そして、今年1月からAIを本格的に導入したという流れになります。

不確実性が高い開発で選んだ、スクラムの透明性

まず、6〜7月頃にどのようなプロセスで進めるかを話し合いました。不確実性が非常に高く、時間も限られています。要件を確定してから進む方法では間に合わないため、オペレーション設計とシステム開発を並行で進める必要があります。そこでスクラムで進めるのが良いという結論になりました。

選んだ理由は透明性です。リファインメントで全員が状況を把握し、迅速に進める。ドメイン知識や理解度を全員で合わせて上げていく。2週間スプリントで方向修正し、変化に対応する。リスクも早めに見つけて適宜対応し、プロジェクト失敗リスクを最小化する。この理由で当時はスクラムを採用しました。



結果、前半はすごく良かったと感じています。例えばリファインメントでは、開発のバックログアイテムの見積もり精度や仕様をどうするかという点で全員の目線を合わせ、「こういう順番でやっていこう」という方針を明確化できました。どうしても認識のズレは発生しやすいのですが、リファインメントを2時間ほど取って「こういうことだよね」と全員で合意して進むことで、その後の仕様変更や認識ズレによる後戻りをかなり防げたと思います。

もう一点、レトロスペクティブでも振り返りを行い、プロセス改善を継続的に進めました。2週間に1回、月に1回の棚卸しのような形で実施し、「ここはうまくいかなかったね」「失敗しちゃったね」と失敗もさらけ出して改善案につなげることで、心理的安全性の確立にもつながったと感じています。
結果として「みんなで作っている」「みんなで前に進んでいる」という感覚が醸成され、かなり正解だったと捉えています。

しかし徐々に課題も出てきました。開発を2〜3ヶ月進めた頃にスクラムイベントの時間がボトルネックになってきたのです。週あたり全員が集まる時間が約5時間になり、開発時間の約15％を占めるようになってきました。特に扱うエピックの内容が進むにつれて複雑化し、リファインメントの時間も伸びていきます。

そのためチームから「会議ばかりで開発が進まないが大丈夫か」という意見が出てきました。情報共有の質や底上げはうまくいっていた一方で、開発スピードが出ないというモヤモヤが続いたのが昨年の10月くらいです。

11月の振り返りミーティングでは、後半エピック全体をもう一度見直し、残りの開発項目をストーリーポイントで詳細に算出し、それまでの開発速度実績を基に予測しました。その結果、もともとの目標より2〜3倍の工数がかかると判明し、「間に合わない」という現実に全員が絶句しました。当時の雰囲気は「終わったな」という空気だったと記憶しています。

スピード重視への変更と、継続した価値観とチーム体制

対応として、選択肢は2つでした。一つは、現状維持で突き進む――透明性やスクラムの良さは維持するが、確実に遅れます。もう1つは根本から変える。スピードアップの可能性はあるが、それは確かではないし、これまで構築してきた文化を捨てる覚悟が必要です。当然、複雑なドメインに対する属人化が発生するリスクもありました。

どうしようかという話になり、1つの例として中規模のエピックを挙げました。その開発見積もりは約2ヶ月という予測値でしたが、さまざまな会社で経験を積んできたメンバーが多く、「今回のやり方ではなく、以前のスピード感が出るやり方ならどのくらいかかるか」を検討しました。



例えばバックエンド1人、フロントエンド1人の2名で、仮にスクラムイベントをすべて省いて進めたらどのくらいかかるか――みんなの見積もりでは2週間から1ヶ月ほど。つまり、変えれば倍以上のスピードが出るという意見が多く出ました。いろいろな意見を出し合った結果、理想的に進めるよりも確実に成果を出す方を優先しようとチーム内で合意しました。

このとき、スクラムのプロセス自体はやめましたが、スクラムで大事にしていた価値は変わりません。教科書通りにやるよりも状況に応じて柔軟に方針を選ぶことが本質だと感じました。そこで継続した3つの価値は、常に継続的に改善する姿勢、意思決定を早く行うこと、“Bad News First”（悪いニュースを早めに共有すること）です。

チーム体制もエピック単位でチーム分割、関連機能をまとめて各チームに割り当て、固定化するのではなく毎月の振り返りで状況や優先度に応じて柔軟に変更できるようにしました。各チームに明確にリード役を設け、意思決定をそこに集中させる編成を組みました。

ここでトレードオフとなる属人性のリスクは飲み込もうと判断しました。今はスピードを優先し、知識の共有・底上げは後で行うという明確な優先順位をチーム内で意識しました。各チームは担当する領域に特化して深い知識を得て、その共有は別途時間を取って行う方針としました。その担当領域に関しては、チーム内で合意形成して判断していきましょう、という進め方をしました。



このとき、PdMが1名だったのですが、PdMが要件を決める役割を担い、3チーム並列で動くと負荷が集中してボトルネックになるリスクが最初から見えていました。そこで、エンジニアの役割を広げました。例えば、要件を決めるところや「法の解釈はどうなんだっけ？」「オペレーションはどうなんだっけ？」という他チームとのやり取りにもエンジニアが参画し、「そもそも実装しなくてもいいよね、アナログ対応で大丈夫だよね」「考え方を少し変えれば実現することは変わらないけど開発工数は減るよね」といった企画段階から入り込むことで、後々の仕様変更を大幅に減らし、そもそもの開発工数を減らす判断ができたと思っています。

その結果、年末時点でやっとうまく回り始め、月次で行っているスケジュールの棚卸しでは、3〜4カ月前は不安ばかりでしたが、全体の雰囲気も良くなり「なんとかなるんじゃないか」と皆が思えるようになったのです。

この時の数値的な改善効果としては、開発速度が倍以上になり、意思決定も早まったことです。それまではスクラムイベントがあると「この議題は数日後のイベントに持っていこう」と自然に意思決定が遅れる仕組みになっていましたが、デイリーミーティングなどで「すぐ決める」を大切にしたことで、早く進み出した成果が見えやすくなりました。結果、チームの満足度も大幅に改善しました。

前半のまとめとして学んだことは、目的に応じて手段を柔軟に変えていくことがやはり大事だということです。一方で、2024年末時点で、プロセス改善により成果はあったものの、依然として不確実性が高く、多くの課題が予測される状況でした。機能開発以外にも、金融システムをリリースするために多くのシステム監査やテスト対応が必要で、要件変更もまだまだ見込まれました。

プロセス改善を経たとしても、このやり方ではこれ以上の成果は望めず、単純に人を増やしてもうまくいかないだろうという不透明さと高いリスクは依然として残っていました。当時は「どうにか頑張るしかない」と考えていましたが、年末から様々なAIエージェントやツールが登場し始めます。

後半のパートでは、それらを取り入れて、これまで不可能だった生産性向上を目指す話を続けようと思います。

生成AI活用の歩み - Nstockで実践してきたこと

佐野：後半は、Devin・Claudeを中心とした開発効率化の具体事例や、それを全社展開していく際の戦略・実践、そして学びについてお話しできればと思います。

まず、Devin・Claudeを中心とした開発効率化の具体事例ですが、最初に年末時点でどのような生成AIを導入していたかをお話しし、その後、現在までにどのようなツールを入れてきたのか、最後に導入による学びをご紹介します。

年末時点では一部の生成AIツールをすでに使い始めていました。LLMでは、例えばChatGPTでベストプラクティスを相談したり、Claudeで簡単なコード生成を行ったりしていました。また、コード補完系ツールも出ていた時期で、私たちはJetBrainsのIDEを使っているため、GitHub Copilotでコード補完も行っていました。

ただ、振り返ってみると、人が駆動し続ける必要性があったと感じています。コード補完でも、ある程度コメントを書いてタブを押すのは人間がやらなければならず、すべてを任せられるわけではありません。ChatGPTで調べてコードが生成されても、最終的にリポジトリへ入れるのは人間でした。

Devinの導入の3つの効果- テストカバレッジ、生産性向上と仕様確認の柔軟性

これらを踏まえ、1月にDevinを導入し、3月にClaudeを全社展開、5月にClaude Codeを導入しました。いわゆる生成AIエージェントを金融事業でどう活用したか、これからお話しします。

1月にまずDevinを導入しました。Devinを導入してできたことは大きく3つあります。第一にテストカバレッジが大幅に向上したこと、第二に普段の開発の生産性が大きく上がったこと、第三にデザイナーやPdMが仕様確認に利用できるようになったことです。

我々は、金融システムに類するプロダクトのため、外部システム監査を見据えて一定のテストカバレッジを求められていました。ドメイン層のテストは充実していたものの、チームを分けたこともありユースケース層のテスト方針がばらつき、カバレッジはそこまで高くありませんでした。

そこでDevinを使い、Devin Searchでリポジトリ全体を解析し、テスト不足箇所を洗い出してナレッジ化しました。たとえば「ユースケースはこういう書き方でテストする」といったガイドを整備し、足りない部分のテストをDevinを並列実行して追加しました。手書きだと1か月程度かかる見積もりだった作業が、エンジニア1人で1週間ほどで完了し、テストカバレッジは75%まで、ユースケース層も同程度まで向上しました。



もう一点目ですが、通常の開発を高速化した事例です。私たちには「オペレーター」という業務担当者がいます。証券会社の裏側にいるイメージで、本人確認の承認や取引情報の登録を行います。この業務が複雑なため、支援する社内管理サービスを開発しています。

このサービスは年末時点で一部開発が進んでおり、開発方針や規約も決まっていました。単純なCRUD 処理が多いものの、開発対象が多いタイプのサービスです。そこで、理解する文脈が少なくて済むようにタスクをできるだけ分割し、指示を出して並列に進めました。

Devinは、タスクごとに必要な情報量が多いと最大使用リソースを使い切りプルリクエストを出さずに失敗するバグのような挙動があります。そのため、たとえばDBを変更するならまずDB、次にバックエンド、最後にフロントエンドと、依頼タスクを細かく分割して依頼し、並列化しました。また、類似のAPI や画面のファイル名を「参考にしてください」とプロンプトに書くと類似コードを生成しやすくなります。外部サービスを使う場合はサービス名を具体的に入れると、そのまま使えるコードが生成されます。



このように活用した結果、今年に入ってからのコミット数の30.5%を生成AIが占めています。副次的効果として、SlackからDevinを呼び出せるため、デザイナーが簡単なUI修正を依頼したり、PdMが「今どこまで実装できているか」を確認しています。

Claude,Claude Codeの導入 - レビューコストの削減と進化への対応

3月にはClaudeを全社展開しました。以前から一部エンジニアがトライアルしており、特にコード生成で大きな効果があったため全社契約に踏み切りました。通常開発でも活用していますが、金融系ならではの事例として「規程の作成支援」に利用しています。

金融事業では多くの規程を作成する必要があります。例として「システムリスク管理規程」があり、7ページ・約7,000文字規模の文書を同程度の規模で5本ほど作成しなければなりません。ネット上のテンプレートもありますが、内容が古かったり網羅性が低かったりすることが多いのが実情です。


ステップに分けて素案を作成し、その素案から詳細を作成し、最後に整形するという3ステップでClaude に指示を出すことで、ほぼ作り上げることができました。2〜3か月かかる想定でしたが、1人のエンジニアが約2週間で対応しました。おおまかなプロンプトで草案を作り、「こういう前提でシステムリスク管理規程を策定する」という形で進めています。

5月に入りClaude Codeを導入しました。即座にマージ可能なレベルのアウトプットを出してくる点が驚きでした。現在はフル機能が使えるMaxプランを希望者に付与しています。
Claude Codeは開発だけでなく、レビューコストの圧縮にも役立っています。自律プログラムでプルリクは増えますが、レビューは人間が行うため負担が大きいという課題がありました。そこでGitHub Appを使い、コメント欄でClaudeと呼び出せるようにしました。Claudeが用意するテンプレートを通じて、アーキテクチャ評価や不足箇所の指摘などを自動でレビューしてくれるため、おすすめです。

導入の工夫として、以前からClaudeを設計の壁打ちに使っており、抽象度の高い知識を渡すと強力に機能することが分かっていました。この知見がClaude Codeの立ち上げにも役立ち、すぐに有効活用できたと感じています。

なおDevinも引き続き使用しており、Slackから修正依頼を出せるためPdMやデザイナーが活用しています。学びとしては、進化が非常に早いので切り替えやすくすることが重要だと感じています。この3 か月でも新しいツールを導入したり、新たなパラダイムのツールを試したりしています。

そのため、生成 AI予算を人件費のように捉え、ツールを切り替えやすくする──「このツールを入れるからこれだけください」ではなく、ざっくり予算を確保しておく──ほうが良いと考えています。もう一点、ツールが変わるため、知識はできるだけ自前のリポジトリで管理したほうが良いと思います。

さらに、試せる体制を用意することが重要だと思います。Devinもそうでしたが、新しいパラダイムのサービスが増えてきており、試して初めて進化が分かる場合があります。ただし「新しいパラダイム」と感じるポイントはエンジニアによって違うので、誰でも試せる体制を用意するのが良いと考えています。

以上がプロジェクトでどのような AI ツールを使ったかという話です。次に、これを全社展開するお話をしたいと思います。

どのように全社にAIツールを展開したのか？

社内で試行錯誤を重ねた結果を振り返ると、最初から筋道立ててポイントが分かっていたわけではありません。「これはうまくいった」「これはいまひとつだった」という経験を集め、うまくいった事例だけを共有しています。私ひとりがリードしたわけではなく、複数メンバーが試した内容をまとめたものです。

社内を観察すると、生成 AIツールを渡してどんどん試す人が一部いました。その人が実際の仕事で生成 AIを使い問題を解決する様子を周囲が見ると、一気に広がる――そんな現象があったため、事例が伝播する場を設けることにしました。

具体例として、マーケティングチーム（オウンドメディアの記事制作担当）がインタビューの文字起こしデータをClaudeに読み込ませ、記事の初稿を生成したところ高品質な原稿が得られました。これをマーケティングチームの定例で共有した翌日、社長が早速プレスリリース作成にClaudeを使い始めた、という連鎖が起きました。

ツール配布と説明会だけでは実務への応用が進まないため、「日常業務で生成 AIをどう使うか」を考えるワークショップをオールハンズで実施しました。各職種の参加者が自分の業務を棚卸しし、LLMを使いこなすメンバーと6チームに分かれて壁打ちを行い、「このタスクはこう自動化できるのでは？」とアイデアを具体化しました。生まれたアイデアの中には、すでに実運用に入っているツールもあります。

複雑なドメイン知識（ストックオプションや金融商品取引法など）が必要になるため、ドメインエキスパートへの質問が集中し、同じ質問が繰り返される課題がありました。そこでNotebookLMで、ドメインエキスパートQ&Aの自動化をプロトタイプ開発し、既出の質問に自動で回答を返すサービスを試作しました。

ただ、NotebookLMではまだAPIがないので、そのデータを出すのが大変です。そこで今、SlackBotにしようとしています。左側がNotebookLMで、「domain」という名前のノートブックにいろんな情報が入っています。右側がSlackボットで、レスポンスを返したり、Slackのスレッド内を読んだりできるようにしています。

また、全社向けの生成AIチャンネルを作りました。情報をキャッチアップするのは大変ですが、必要な人が見ないままでは機会損失になるため、投稿に縛りを付けたSlackチャンネルを用意しています。加えて、生成AIオフィスアワーを設けています。全社に利用状況をヒアリングしたところ、「やりたいことはあるが、どう使えばいいか分からない」という声がありました。そこで週1回、1時間のオフィスアワーを設置し、相談を受けてその場でやり方を見せています。解決に時間がかかる場合は「この方法とこの方法を組み合わせればできると思うので、一旦持ち帰ります」と道筋を示し、どこまで解けるかを伝えています。

対応する組織、文化と経営層のコミット

ここまでの反省点として、専任チームを早めに作ったほうがよかったと思っています。当初は有志の会で進め、詳しい人が説明会をしていましたが、手を動かす時間が必要になるため、専任でないと対応が後手に回ります。浸透が進むと他のニーズも出てくるので、支援を継続的に行うためにも専任チームを置く予定です。



3点目のポイントは、文化・経営層のコミットです。会社のカルチャーとして、新しいものを試し、得た知見を共有する文化があります。こういった文化が、生成AIの浸透に寄与したと感じています。

経営層のコミットについては、たとえばDevinを導入するとき、500ドルからの従量課金で躊躇していましたが、ただそこで社長が他社事例を持ってきて「意外と効果が出ているらしいよ」と話してくれたことで、「じゃあ導入してみよう」と一気に進めることができました。さらにClaudeやDeep Researchを積極的に試す人の姿を見て、「どんどん使ったほうがいいんだ」と浸透が早まったのも大きかったと思います。
ツールをツールとしてではなく人件費と考える予算についても、エンジニアと一緒に考えたかどうか忘れるほど自然に決まりました。こうした新しいものを取り入れやすい土壌がある点は、会社によって違うかもしれませんが、大きな影響があったと感じています。



私たちの軌跡を今日はお話ししました。事業の制約や特殊性を踏まえて開発プロセスを大きく転換し、生成 AIを取り入れて加速し、全社展開で組織全体の生産性向上を目指しました。問題を一つひとつ観察し、分析し、愚直に対応してきた結果だと思います。不確実なことがあっても一旦試す姿勢を貫いてきました。今後も変化は続くでしょうが、この姿勢を保って取り組んでいきたいと思います。



本日の発表は以上です。ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です