アーカイブ動画

生成AI活用プラットフォーム「athenAI」の内製開発でアジャイルのプラクティスを活用

株式会社 野村総合研究所
デジタルインテグレーション推進部　徳永 翔太氏

最初に登壇したのは、2019年に新卒で入社した徳永翔太氏だ。金融業界の顧客向けスマホアプリの開発や基盤構築などに携わった後、入社5〜6年目のタイミングで今後のキャリアにおいてアジャイルやAIのスキルをさらに伸ばしたいと感じるようになった。そこで、社内公募制度を利用してAIを活用した開発支援プラットフォームの開発チームに参画し、現在は、「athenAI（アテナイ）」の開発に従事している。

「athenAI」は、NRIが自社向けに独自開発する、生成AIを用いたワークフローを作成・実行できるプラットフォームである。

同プラットフォームには「3つの価値がある」と徳永氏は説明する。まず、手軽にそして「セキュアに」AIの処理ができること。2つ目は、AI活用事例をワークフローのように実行可能な状態で社内共有できること。そして3つ目は共有されたナレッジを、目的に合わせて修正・アップデートして活用する、流用可能なナレッジ共有が実現できる価値だ。

NRIでは、2024年6月よりスクラムのプロセスを活用して開発を進めてきた。ふだん同社では、多くの開発パートナーとともにプロジェクトを進行するが、「athenAI」の開発プロジェクトにおいてはプロダクトオーナーはもちろん開発チームも社員が中心に。「そもそもこういったコンセプトのアプリにニーズがあるかがわからなかったので、とにかく迅速に開発していち早く検証するために、少数の社内メンバーで進めることにしました」と背景を説明した。

だが、この体制には課題もあったという。プロジェクトへの専任メンバーを確保できなかったことだ。そのため、固定メンバーでチームを編成する一般的なスクラムで進めるのは難しいと判断。AIコーディングツールを活用して生産性を上げるなどの工夫をしながら乗り越えたという。

NRIではすでに、「GitHub Copilot」と「Cody」が社内で利用できる環境が整っている。今回のプロジェクトでは、チームの立ち上げ時期からAIコーディングツールを活用し始めており、主に「GitHub Copilot」を活用していた。

具体的には、AIコーディングツールに仕様を説明させることで、引き継ぎ設計資料の作成を最小限に留めてチームの入れ替わりに柔軟に対応したり、テストを自動化してプロダクトの品質を担保したりしてきた。とくに、「E2E（エンドツーエンド）テスト」においては、単体テストツールのほかテスト自動化フレームワーク「Playwrite」を使って自動化を実現した。生成されたテストがユースケースに即していないこともあったそうだが、適宜チームでチェックする体制を整備。「人の介在を加味しても、テストコード生成の生産性は向上したと捉えています」と、成果を述べた。

また、本プロジェクトでは開発に関する情報をオンラインホワイトボードツール「Miro」に集約し、開発カンバンやスケジュール、設計方針などをここで管理したという。このように様々なツールの活用を進めてきたが、実際にチームで開発を進めてみると「課題はたびたび発生しました」と徳永氏は明かし、代表的なものを３つ紹介した。

まずは前述したとおり、メンバーの大半がプロジェクトに専任できなかった点だ。「専任できないのは、それだけ優秀なメンバーが集まっているから。だから、仕方のないことだとまずは割り切りました」と、徳永氏は語る。

そのうえで、いくつか対策を講じた。まずは、デイリースクラムの廃止だ。チームメンバーの多くが兼務で、稼働日がバラバラだったことから、より効率的にプロジェクトを進行するために週に2回のペースでペアプログラミング（ペアプロ）を実施した。徳永氏は「これが専任チーム不在の開発チームにとって、メンバー間の状況やナレッジが共有できる機会となり、チームの一体感を醸成する有効なプラクティスになりました」と振り返る。

2つ目は、見積もりが合わなかったことだ。今回のプロジェクトはAIを組み込んだプロダクト開発だったこともあり、工数や見積金額の予測精度に課題があった側面がある。「ゴールが未達になる」ことでメンバーに焦りが出たり、チームの信用を失ったりすることは避けたいと考え、対策を検討したそうだ。

体調不良など不測の事態は割り切る一方で、スプリントレビューの前日にバグに気づくということがないようにCI/CDを高速に回す、実装の品質を向上させるためにテストコードを整備、リファクタリングする、など工夫した。

3つ目はプロダクトの品質である。前述したように、プロジェクトが始まった段階ではニーズを探りながらの状態であったため、プロダクトの投資価値を示し続けられなければローンチすることなくチームが解散する未来もあったという。そのためプロジェクト開始後2〜3ヶ月は、機能開発に注力していた。

「プロダクトの価値が認められ、全社展開が現実的になったタイミングで、ようやく品質面の改善活動に力を入れるようになりました」と徳永氏は話す。とくに、PBI（Product Backlog Item）が早く消化できて余裕があるときや、スプリントが乱れる長期休暇などを利用し、「リファクタウィーク」としてテストコードの拡充やリファクタリングに集中的に取り組むなどと工夫したそうだ。

プロジェクトでは、スプリントで定期的に振り返りをしたそう。その際にも活用したのが「Miro」である。「AIによるコーチングや振り返り用テンプレートなどが提供されているのでおすすめです」と、紹介した。

講演後半ではプロジェクトを振り返り、徳永氏が考えるプロダクト開発の今後の展望を紹介。「ここまででお話ししたように今は、IDE内蔵型のコーディングエージェントを活用した開発が主体。ただツールを使うなかで、ここ半年間だけでも（出力の）精度が高まってきた実感があります。現段階ではAIアシストによる開発の時代ですが、今後のモデルの進化や新技術の登場により、AIが1人の開発者として数えられるような未来もそう遠くないのでは」と述べた。

また、アジャイルと生成AIの相性のよさについて改めて強調する。「生成AIを用いた開発プロセス自体にまだ不確実性があるため、不確実性に向き合うことを前提としたアジャイルの考え方を採用した方が都度計画が修正できて運用しやすいのでは」と見解を示した。

さらに生成AIの進化により「生成AIが大量のコードを書いてくれるので、少人数で大きなものが開発できるようになると思います」と、大規模開発への向き合い方が変化する可能性を示唆する。他方で、「開発方式や生成AIのマネジメント方法などは未確立であるため、今後はそこを試行錯誤していくことになりそうです」と述べた。

最後に徳永氏は、開発現場で求められるエンジニアのスキルセットの変化について言及。

「今回のプロジェクトで、わかりやすいコードを書く方にバックグラウンドを尋ねると、エンジニア歴2〜3年で言語経験も少ないとのこと。ただ、AIがアシストしてくれたそうです。こういった話を聞くと、従来はプロジェクトにフィットしたスキルセットを持つ人材を複数確保しなければなりませんでしたが、AIの登場でそんな世界が変わり始めている、と感じています」と今後の展望を示し、セッションを締めくくった。

アジャイル要素を取り入れた“出島チーム”により、レガシーなエンハンス開発の工数を削減

株式会社 野村総合研究所
産業ソリューション事業本部　小林 良至氏

続いて、大手SIerにてWebシステム開発アプリケーションエンジニア、プロジェクトマネージャーを経験し、2021年にNRIへ入社した小林良至氏が登壇した。現在は、不動産情報サイトのエンハンスチームにプロジェクトマネージャーとして参画するほか、保守開発チームのチームリーダーとして活躍している。

※スライド内、KR＝戸建流通領域

小林氏はまず、自身がリーダーを務める戸建流通領域（KR）※チームの担当業務や体制、特徴などを紹介した。本チームでは、月間1000万人以上が訪問し、月間2億PVを超える大型不動産情報サイトにおいて、物件情報の入稿作業からフロントまで一括して保守・運用を担当している。NRI社員7名と開発パートナー35名の総勢42名からなるチームで、年間433人月以上ある大規模プロジェクトである。

長年続くプロジェクトであるため、開発手法はもともとあるルールやフローに則って行うウォーターフォール型を採用しており、常時15〜20件のエンハンス案件が並行して走っている。「年間障害数などが少なく品質は安定しており、顧客との関係性も良好」である一方、「カスタマーサーベイを実施すると、なんらかの新しいことを求める声が挙がっていました」と課題を挙げた。

※戸建流通領域（KR）：不動産のうち、新築の分譲住宅や中古住宅を扱う領域を指す

※スライド内、KR＝戸建流通領域

その理由の1つは、長年続く重厚長大な開発フローが整備されており、品質は安定する一方で、軽微な改修でも時間がかかるイメージが定着していたことが挙げられる。そういった背景もあり、ビジネスモデルを大きく変える新プロジェクトが顧客最重要施策に。要件が固まりきらない状況でも「いち早くリリースしフィードバックを受けたい」顧客ニーズを感じながらも、エンジニア1名あたり複数の案件を担当している現状の体制のまま、随時変更が発生するプロジェクトを進行するのは厳しかったという。

そこで小林氏はアジャイルの要素を取り入れた「出島チーム」を構成し、マンネリ化の打破ならびにさらなる顧客のニーズに応えようとする。

※スライド内、KR＝戸建流通領域

「出島チーム」について小林氏は「もともとあった戸建流通領域（KR）チームから何名かを選び、チームの外に元のチームとは方針が異なる全く別のチームをつくりました。長崎の出島をイメージしていただければ」と説明する。

「出島チーム」では、メンバーを固定し、複数案件が同時に走る体制ではなく、常に1案件だけを担う体制とした。さらに、通常業務でルール化されていた「Microsoft Excel」などによるドキュメント管理を踏襲せず、品質を担保したうえで独自のルールやフローでプロジェクトを進行して良いとした。「自発的に考えて改善していくチームであることを期待しています。その意味で、『出島チーム』はチームのあり方そのものがアジャイルです」と語る。

ここで小林氏が強調するのは、「アジャイルは、状態である」ということだ。

「アジャイル＝スクラム、というイメージを持っていた時期が私自身ありました。しかしながら、より良い方法を見つけ出そうとしている『状態』こそがアジャイルであり、アジャイルは、ソフトウェア開発だけでなくさまざまな場面で適用できるものです」。

また「出島チーム」の構成は、ベストプラクティスや社内メンバーのアドバイスを参考に、固定メンバー3〜4名とした。

ここで小林氏は、初期検証を半年間行ってきた結果を明かす。

「出島チーム」には、戸建流通領域（KR）のシステム開発経験があるリーダー格の人材1名と、エンジニア経験数ヶ月〜数年のメンバーをアサインしたといい、「けっして戸建流通領域（KR）に詳しい人材ばかりではなかった」と説明。

「出島チーム」では、これまでに3つプロジェクトを進行してきた。すると、開発手法は従来通りウォーターフォール型を採用していたにもかかわらず、2つのプロジェクトで、約7日の大幅な開発リードタイム短縮に成功した。

小林氏は、「出島チーム」での半年間の活動に対してメンバーへのアンケートや振り返り会を実施。ここでは、その内容を紹介した。

「出島チーム」メンバーだけの朝会を日次で実施したり、週に4日のリモートワーク中に常時ビデオ通話を接続したりと、小林氏の提案でコミュニケーションがとりやすい環境づくりに取り組んでいたという。一方、カンバンでの進捗見える化やレビュー頻度の見直しなどは、プロジェクトを進行するなかで小林氏以外のメンバーが自発的に提案し、方針として取り入れたものだという。

その結果、課題解決スピードやモチベーションがアップするといったプラスの効果を実感する声が得られた一方で、実際の数値を見ると残業時間が増加してしまった、という新たな課題も浮き彫りとなった。

そこで残業増に対して、小林氏は意識改革に取り組むことに。「最終的なゴールは、いち早くニーズに応えて価値を届けること。工数や現実性を考えて臨機応変に納期や要件を調整しながら、お客さまとともにつくっていこう」という考え方をチームメンバーに訴えた。

ここで、意識改革後の次の半年における検証結果が明かされた。前回の検証（最初の半年間）と比べると2つのプロジェクトでは開発リードタイムが約2日延びたものの、従来のプロジェクトと比べれば依然として約5日短縮できており、改善効果を維持できていることが確認された。加えて、1年間通して「出島チーム」が担当した5案件すべてで障害が発生せず、品質面での評価も高かったという。

このような成果が得られた背景をふまえ、小林氏は「私のなかで最も嬉しかったのは、アジャイルという『状態』がどんどんチーム全体に勝手に伝播していったことです。各メンバーが自発的に行動し、改善できていたことが成功の秘訣だと思います」と強調する。「出島チーム」外でも同様に行動できるようになったチームメンバーもいるといい、「『出島チーム』以外でもポジティブな雰囲気が出てきた」実感があるそうだ。

一方で、専任チームはポジティブな結果をもたらすものの「出島チーム」においてもNRI社員だけはどうしても専任にできなかったとし、「『出島チーム』にすべてを置き換えるのはコスト面で難しい。リソース効率優先型のチームと『出島チーム』のハイブリッド型運用であれば、コストとのバランスを取りながら顧客のニーズに応えられそうです」と所感を述べ、セッションを締めた。

社内外に向けアジャイル支援を専門に担うNRIのチーム「bit Labs」

株式会社 野村総合研究所
生産革新ソリューション推進部　原田 佳明氏

続いて、情報関連企業でBtoB領域のSaaS開発や運用に携わるとともに、アジャイルプラクティスの1つであるエクストリームプログラミング（以下、「XP」）を実践してきた原田佳明氏が登壇した。

NRIへの入社は2023年。社内外どちらに対しても、アジャイル支援を専門に担うNRIのチーム「bit Labs（ビットラボ）」のアジャイルコーチに着任した。現在はアジャイル導入支援はもちろん、アジャイルやAI開発に資する人材の育成にも従事している。

「bit Labs」では現在、イノベーション、トランスフォーメーションと2つのサービスを提供しており、本セッションではトランスフォーメーションについて紹介した。

トランスフォーメーションにおいては、ビジョン、リーダー、チーム、カルチャーと4つの観点が必要だと原田氏は述べた。

チームとカルチャーの観点に関連する取り組みでは、アジャイルチームの強化を行う。具体的なサービスとしては、「bit Labs」が技術やプロセスをコーチングしたり、伴走するなどして、アジャイルチーム強化を実現するためのノウハウを伝授する。

ビジョンとリーダーの観点での取り組みでは、経営を巻き込んだビジョンやシナリオの策定を行う。

「既存のルールなどをそのまま適用すると、アジリティが下がる可能性があるからです。NRIのコンサルティング部門と協力しながら、変革の骨子を策定します」。

原田氏はこのように、提供しているサービスに取り組む意義ならびに、サービスの詳細を説明する。

関連する研修やアジャイル開発コーチング、伴走支援など、社内で提供するサービスも紹介した。アジャイルの入門研修から、各スクラムのロール別でプロダクトオーナー、スクラムマスター、開発者のようにターゲットごとに研修を提供するなど、アジャイルを自社で普及することに挑戦しています。

研修は社員であれば誰でも受講でき、スライドで示されている研修はあくまでその一部である。

なお、先述した社外向けサービスであるアジャイル開発コーチングや伴走支援においては、社内向けにも提供している。

「bit Labs」ではさらに、登録者数が800人を超えるアジャイルコミュニティ「あじゃはぶ」の運営も手がける。ここでは、毎週アジャイルに関するトピックをラジオのように配信したり、チームビルディングをテーマにしたオフラインイベントを実施したりしている。

さらに「bit Labs」では、エンハンス案件にウォーターフォール開発で取り組むチームに対して、アジャイルのプラクティスを導入する取り組みも推進している。実際に2番目の登壇者である小林氏とともに「出島チーム」プロジェクトもサポートしたようだ。

最後に原田氏は「アジャイルの本質は、より良い開発を目指すマインドです。ウォーターフォールを採用するチームであってもその考え方は役立つと思います」と活動の意義を改めて強調し、講演を締めくくった。

【パネルディスカッション】アジャイル活動のリアルな話を赤裸々に語り合う

ここからはモデレーターに原田氏、パネリストに徳永氏と小林氏を迎えたパネルディスカッション。

登壇者3名がNRIのアジャイル活動のリアルを赤裸々に語り合った。要約して紹介する。

活動に取り組んだことで、アジャイルに対する印象は変わったか？

原田：まずは、お2人の意見をお伺いしてもよろしいですか？

徳永：チームにアサインする前から勉強していたので、個人的にはとくに変わっていません。

一方で、NRIのこれまでのプロジェクトはウォーターフォール型がほとんどでした。アジャイルは、手法どおりに進めなければならない、というものではありません。コミュニケーションの取り方や考え方など、開発過程における重要なエッセンスに気づけたのが、変化した点だと感じています。

小林：アジャイルはルールや答えではなく、実践して上手くいったものをお互いに共有し合うベストプラクティスです。この「アジャイルは、手法ではない」という考え方に気付くきっかけとして、「あじゃはぶ」のような場所の存在意義があるのではないでしょうか。

原田：スクラムというわかりやすいプロセスがあるため、どうしてもスクラムを実施することがアジャイルだと捉えられがちですよね。このような価値観を崩したいと、社内の研修コンテンツを考えているつもりです。ところで、アジャイルに対する考え方が変わったきっかけは、何かありましたか？

小林：何かきっかけがあったというよりは、徐々にアジャイルの考えが醸成していった印象です。

徳永：アジャイルを実際に体験し、アジャイルを自分のなかで言語化できるようになったタイミングで、考え方がシフトしたように思います。

原田：私はアジャイルコーチとして入社しましたが、XPに従事していたバックグラウンドがあります。XPは、テスト駆動開発やペアプロ……のようにルールがたくさんあります。NRIに入社して「出島チーム」の活動などを経験するなかで、アジャイルの本質はやはりマインドなのだと、実感するようになりました。ウォーターフォール型開発のなかでアジャイルができている、むしろこの方がアジャイルだ、と今では感じます。

アジャイルな活動を通じて感じたチームの成長ポイント

小林：まさしく私が今日、セッションでお話したテーマですね。戸建流通領域（KR）チームの変化を客観的に見ていて、原田さんはどう感じられましたか？

原田：小林さんのいらっしゃる戸建流通領域（KR）チームは、「アジャイルとは」の最初の研修からサポートさせてもらいましたが、研修後にチーム内で取り組みたい案が早速チャットで出てきていましたよね。この様子を見て、もともと素養がある皆さんだと感じていました。実際に複数のプロジェクトでリードタイム短縮の成果を出された結果を拝見して、さすがに驚きましたよ。

先ほどの講演では、アジャイルがチーム全体に広がったと仰っていましたが、それは小林さんが意識的に仕掛けていたからでしょうか？

小林：半分は自然に、もう半分は意識的に仕掛けていた部分もあります。というのも、私がチームの立ち上げ時期から期初のキックオフや飲み会などでアジャイルの話をしていましたし、「『出島』がチームを変えるぞ！」と意気込みもメンバーと共有していたからです。

半年経った段階で、提供価値はそのままに生産性を上げ、残業を減らすためには、どうすべきかを各々が考えるようになり、徐々にチーム全体にアジャイルが広がっていったように思います。

徳永：私の場合も、チームメンバーが主体的に動くようになった点がチームの成長を実感したポイントです。NRI社員と開発パートナーの間にある壁を取っ払うために、ペアプログラミングを同じ部屋で実施するなど工夫してきました。これが功を奏して、心理的安全性が担保でき、1人ひとりが少しずつ変われたのかなと思います。

アジャイル活動を高めるうえでのハードル

原田：今度は徳永さんからお願いします。

徳永：専任メンバーを設けることが難しいのが、ハードルだと捉えています。

原田：そうですね、同じ意見です。

小林：専任メンバーの配置が難しいのには、コスト面のハードルがありますよね。早く開発できたとしても、お客さまにどれだけその価値を理解していただき、お金に換算していただけるかは現実的に難しいのではないでしょうか。

原田：お客さまにとっても私たちにとっても、より良い開発手法や体制を模索し続けることが大事なのかもしれませんね。

小林：お客さまを巻き込んで、一緒に目標に向かっていくことが必要ですよね。たとえば、お客さまには「出島チーム」のような1つの開発チームをチームごとご購入いただく、のような形で専任チームの価値が提供できるようになれば良いな、と思いました。

NRIの文化とアジャイルの相性

原田：まずは、他社から転職してきた小林さんの意見を聞かせてください。

小林：無駄を放置しない。PDCAを自分のなかで回せる。会議では若手からベテランまで発言する。NRIにはこのような文化があり、アジャイルらしいと個人的には感じています。金融部門でも同様でしょうか？

原田：私もPDCAを自ら回せる点で皆さん優秀だと感じていました。ただ施策を加えて現状を改善するのは得意な一方で、何かをやめたりスリム化するのが苦手な側面もありそうです。

徳永：個人的に「現行踏襲は悪だ」というマインドで仕事に取り組んでいます。また、開発プロセスにおいては設計書に書かれていない背景がやはり大切です。そこを理解して取り組む人がNRIには多いと思うので、NRIの文化とアジャイルの相性は良いと考えています。

ただ、これまでNRIではウォーターフォール型の開発で成功してきたので、新しいプラクティスを導入するハードルが高い側面があるのは事実です。世の中やビジネスの変化に追従するために、新しいことにもチャレンジしていかなければならないですね。

【Q＆A】参加者から寄せられた質問に登壇者が回答

パネルディスカッション終了後は、Q＆Aタイムが設けられた。抜粋して紹介する。

Q．「bit Labs」の組織体制やメンバーの属性

原田：「bit Labs」は、グループ横断のバーチャルな組織。全部で10〜20名ほどで、技術のバックグラウンドを持つアジャイルコーチが多く、自ら手を動かしながら伴走支援できるのが特徴です。ぜひ、ウェブサイトを見てみてください。

参照　https://bit-labs.nri.co.jp/

Q．アジャイル推進チームが機能しているかを判断する指標はあるか？

原田：「Four Keys（※）」がわかりやすいですが、ここでの評価が低いからといってアジャイルが推進できていない、とはいえないとも思います。アジャイルコーチは、コミュニケーションが取れているか、心理的安全性が担保されているかなど、数字で表せないところまで見てサポートする必要があると思っており、私自身も大切にしています。

※Four Keys：DORA（DevOps Research and Assessment）が提唱した、ソフトウェア開発チームのパフォーマンスを測る4つの指標。デプロイの頻度、変更のリードタイム、変更失敗率、デプロイ失敗時の復元までの時間から成る

Q．「GitHub Copilot」から明確な回答を引き出す工夫

徳永：以前はプロンプトエンジニアリングが大事でしたが、最近は多少雑に「ここの仕様を教えて」程度に指示するだけでも精度の高い回答が上がってくることが増えてきたと感じます。ですので、まずは難しいことを考えずにちょっと雑に試してみる、それで良い回答が得られなかったらその時に関連資料や情報を提示して一緒に回答の精度を高めると良いと思います。

あとは設計自体は明確だが、手を動かすのが面倒な場合は、関係するコンテキスト情報、我々の場合はソースコードが書かれたファイルを指示と一緒に添付してコードを生成してもらっています。多くの人がこの使い方をしていると思います。

Q．アジャイル導入が難しい組織の特徴

原田：「より良くする」というマインドがアジャイルだと定義するなら、マインド面が最も難しく、変えづらい部分です。既存の進め方を変えたくない、あるいはかっちりとプロセスを決めてから進めたいと思う方がいらっしゃる組織ではアジャイルの導入に苦戦しそうです。

小林：そうですね。「とりあえずやってみよう」という意見に対して、反発がある環境では難しいかもしれません。失敗したらその時に反省して改善していこう、と考えられる組織であると良いですね。

徳永：上長などがアジャイルに対して抵抗感がある場合は、導入ハードルが高そうです。やはり、アジリティの高い組織を構築するためには上位レイヤーの協力が欠かせません。昔ながらの企業や製造業などの組織であっても、そこに協力的であれば、アジャイルが推進できる可能性は十分にあるはずです。

株式会社野村総合研究所
https://www.nri.com/jp/

株式会社野村総合研究所の採用情報
https://career.nri.co.jp/