コンテンツへ移動
株式会社グレリア
LATEST UPDATE

NEWS & BLOG

BLOG

楽天の「24営業日から5営業日」をどう読むか

楽天の「24営業日から5営業日」をどう読むか

Anthropic の事例ページで、楽天が開発に Claude Code を取り入れた結果が紹介されています。新機能を市場に出すまでの平均期間が、24営業日から 5営業日になったそうです。79% の短縮にあたります。

日本の企業の事例でもあり、お客様との打ち合わせで話題に上りそうな数字です。ただ、この数字をそのまま「うちも 5日に」と受け取るのは危ないと考えています。

何が書かれているのか

事例ページに並ぶ数字

事例ページには、いくつかの数字が並んでいます。

項目 内容
新機能の市場投入までの平均 24営業日から 5営業日(79% 減)
自律的なコーディング 大規模なオープンソースの改修で、Claude Code が 7時間にわたり作業を続けた
精度 複雑なコード変更で 99.9%(参照手法と比べた数値精度として説明)
働き方の例 1人が 5つのタスクを進め、そのうち 4つを Claude Code に任せる

これらは楽天と Anthropic が公表した数字で、第三者が検証したものではありません。また、24営業日から 5営業日のうち、どの工程がどれだけ縮んだのかは、事例ページに書かれていません。テストの作成や、AI によるプルリクエストのレビュー、複数セッションの並行開発といった使い方は紹介されていますが、内訳までは分からない形です。

事例ページには、もう一つ気になる記述があります。Claude Managed Agents を、製品、営業、マーケティング、財務の各部門に 1週間以内に展開した、というものです。開発部門だけでなく、ほかの部門にも広げている様子がうかがえます。ここでも、広げる速さを決めているのは道具より、各部門が何を任せ、何を自分で見るかを決められているかどうかだと思います。

数字の読み方

ここから先は、私たちの見方です。

「市場投入までの期間」は、要件の整理、設計、実装、テスト、レビュー、承認、リリースの順番待ちまでを含む長い線です。実装の速さだけで決まるものではありません。5日になった背景には、AI が書くのが速くなったことに加えて、レビューや承認の流れを、AI の速度に合わせて組み直したことが含まれているのではないかと想像します。ただ、これは事例ページから確かめられたことではなく、私たちの推測です。

もう一つ、見落としたくないのは、楽天の開発体制が一般的な会社とは違うことです。エンジニアの人数も、コードの規模も、これまでに積み上げてきたテストの量も違います。テストが厚い開発現場ほど、AI が書いたコードを機械的に確かめやすくなります。反対に、テストがほとんどない現場では、AI が速く書いたぶん、人が目で確かめる量が増えます。

同じ道具を入れても、結果が現場ごとに違うのは、このためだと思います。だから「平均 5日」は、楽天の現場の結果として読み、他社に当てはめる目標にはしないほうがよいと考えています。

もし社内に「AI で速くなった」という話があっても、その速さが次の工程で詰まっていないかは、別に確かめる必要があります。速く書けたコードがレビュー待ちの列に並ぶだけなら、全体の期間はあまり変わりません。そこで私たちは、実装だけでなく、レビューと承認の持ち方も一緒に決めておくようお勧めしています。

その時点で論じる

ご相談をいただいたときも、一般論を先に出すことはしません。案件ごとに、いまの流れがどこで滞っているのかを一緒に見ます。

見るのは、たとえば次のような点です。要件が固まるまでに時間がかかっているのか。実装そのものに時間がかかっているのか。レビューの待ち時間が長いのか。リリースの承認が止まっているのか。滞っている場所によって、AI に渡す作業は変わります。要件が曖昧なままなら、実装を速くしても全体はあまり縮みません。

たとえば、受託開発の現場を考えてみます。お客様との仕様の確認に 1週間、実装に 2週間、お客様の確認待ちに 1週間かかっているとします。実装を AI で半分にしても、全体は 4週間から 3週間になるだけです。確認待ちの 1週間を縮める工夫、たとえば動くものを早く見せて確認を前倒しするほうが、効く場合もあります。どちらが効くかは、その案件の流れを見てみないと分かりません。これが「ケースによる」と考える理由です。

私たちが大切にしているのは「判断は人、作業は AI」という線引きです。実装やテストの下書きのような作業は AI に渡せます。何を作るか、どこまで任せるか、出てきたものをリリースしてよいかという判断は、人が持ちます。この線をどこに引くかは、チームの経験や、扱うシステムの重さで変わります。

数字を持ち帰るなら、最初に自社の「いま」を測ることを勧めます。新しい機能を一つ出すのに何日かかっているのか。そのうち、実際に手を動かしている時間はどれくらいで、待っている時間はどれくらいか。ここが分かれば、楽天の事例を自分たちの話として読めるようになります。測るだけなら、道具の導入前でもできます。記録は付箋や表計算で十分で、完璧な数字は要りません。

まとめ

楽天の数字は、AI を開発に入れたときの伸びしろを示す、参考になる事例です。同時に、公表されているのは結果であり、そこに至る工程の内訳ではありません。

自社でどの工程を AI に渡し、どこを人が見るのか。それを決めるところから始めるのが、近道だと考えています。同じ整理を自社でやってみたい、という方は、工程の洗い出しからご相談ください。

出典

関口 篤史

Author

関口 篤史 代表取締役

プロフィールarrow_forward
CONTACT

プロジェクトの
ご相談はこちらから