カギは「曖昧さの徹底排除」。樽石氏に聞くプロジェクトの「空中分解」を阻止する方法

「イオンの新しいネットスーパー」として、2023年7月にサービスを開始した「Green Beans」。日本でネットスーパーといえば実店舗から配送する形式が主流ですが、本サービスは最大5万品目を扱う巨大物流センターを建設し、倉庫から直接発送します。イオンネクストを含めたイオンのネットスーパー事業全体では、2030年度に6000億円の売り上げを計画しており、イオンネクストはその中で中核的な存在を担い、約4000億円を目指します。

このサービスを支えるシステム開発をリードしたのは、2022年3月にイオンネクストCTOに着任した樽石将人さん。Googleや楽天を経て、前職のRettyではCTOとして上場に導いた実績を持つ樽石さんですが、自社メディアで公開されたインタビューでは「オフショア開発に出していたソースコードを見るだけで3週間かかった」など、プロジェクト推進の苦労を率直に語っています。

困難の多い案件にも関わらず、予定通りにサービスをローンチできた要因はどこにあったのか。樽石さんに聞くと、そのカギは「曖昧さの排除」にあったことが見えてきました。ひとつ間違えば混乱が生じる可能性があるプロジェクトを完遂させた樽石さんに、プロジェクトの成否を分けた取り組みについて聞きました。

• keyboard_arrow_down ローンチ1年前に、ようやく全体設計を本格化
• keyboard_arrow_down 厳しい状況を打破するためのカギは「曖昧さの排除」
• keyboard_arrow_down まずは「世界地図」として、システムの全体像を正確に共有する
• keyboard_arrow_down 取り組むタスクの優先順位づけには「バージョンの命名」が効く
• keyboard_arrow_down オープンコミュニケーションの文化は、DMを減らそうとしなくてもつくれる

――樽石さんがイオンネクストのCTOに就任した段階で、すでに「Green Beans」の開発プロジェクトは始まっていました。当時の進捗状況を教えてください。

樽石：約1年後の2023年上期にサービスをローンチすることは決まっていましたが、その段階でシステムの全体設計が明確になっていないという状況でした。

それまでIT部門では、Green Beansのシステム開発に活用することが決まっていた「Ocado Smart Platform（OSP）」の調査を行っていたんです。これは英国Ocado社のソリューションで、同社は1カ国につき1社としか契約しない方針のため、日本で導入するのは今回が初めてかつ唯一のケース。そのため情報や資料が少なく、OSPのシステムを動かすために何が必要かを洗い出すだけでかなりの時間がかかっていました。

私が参画した頃には機能の洗い出し作業はほぼ終わっていましたが、アーキテクチャの全体像が正しく描けておらず、何をどうOSPにつなげばいいのかわからない状態。例えば、カスタマーセンターのシステムを導入するのはわかっていても、それをどうやってOSPと連携させるかは決まっていないという具合です。

たとえるなら、引っ越したばかりの家に段ボール箱が山積みになっているようなもの。必要なものは届いているが、何をどの部屋に置くのかは決まっていない。そんな感じです。

――その現状を知って「このままではまずい」と考えられたんですね。

樽石：正直言って、これがどれくらいまずい状況なのかさえわからなかったですね。それほど混沌とした状況でした。

そもそもイオンネクスト自体が、2019年12月に設立されたばかりの新しい会社です。私がジョインした時点で、開発を担うIT部門の正社員は、倉庫関連のシステムを主管していた技術責任者と、IT部長、コードを書くエンジニア1人、それとプロジェクトマネジャー3人の、合計6人しかいませんでした。当然組織体制も確立されていなかったし、CTOになる私の職務や権限の規定もありませんでした。だから自分で今やるべきことを考え、周囲を巻き込みながらどんどん物事を進めていくしかないと腹を括りました。

――課題が山積した厳しい状況だったと思いますが、状況を打破するために、樽石さんが最も大切にしていたことは何でしたか？

樽石：チームが一丸となってプロジェクトの完遂に向かって進められるよう、認識のずれにつながるような「曖昧さ」を徹底的に排除することを、何よりも大切にしていました。

関係者が多いプロジェクトでは、ちょっとした曖昧さから生まれた認識のズレが、気づかぬうちにどんどん大きくなり、収拾がつかなくなってしまいます。関係者同士が健全に協力し続けるためには、プロジェクトの目標や今やるべきことはもちろん、プロジェクトの中で使う言葉ひとつに至るまで、全員が同じ認識を正確に共有しておかなくてはいけません。それができてこそ、関係者全員が目標に向かってブレずに協力し合い、課題を1つ1つ倒していけるのです。

とくに今回は社内外問わず関係者が多く、プロジェクトの途中で新しいメンバーを採用する予定もありました。そのため、「誤解しようがないほど短く、直感的に伝わる言葉」すなわち「ショートメッセージ」を用いて、曖昧さを排除し、常に正確に情報を共有していくことに特に力を入れました。

――曖昧さを排除するための「ショートメッセージ」を使った取り組みとして、最初に何をしたのでしょうか。

樽石：内製開発ができる体制を確立してから、これからつくるシステムの全体像について、エンジニア全員との共通認識を正確に形成するために、統合すべき要素を全て書き出し、それぞれのつながりを示した「世界地図」を作成しました。これは全員が則るべきアーキテクチャの全体像をまとめたもので、私が自らクラウド環境のリソースを1つひとつ確認して正確に図に表すと共に、リソースのコンソールとソースコードのリンクを統合しました。設計に困ったらここに立ち返ろう、という趣旨で用意しています。

樽石：「世界地図」という呼び名にしたのは、いわゆる世界地図の「世界の全体像を示す」という用途と、今回つくったものの「システムの全体像を示す」という用途が似ていたからです。このニュアンスを正確に、曖昧にならずに伝えられる「ショートメッセージ」として、「世界地図」という誰しもが同じ形状、同じ用途のものを思い浮かべるような言葉を使いました。

――統合する要素が多いと世界地図も複雑になると思います。認識のズレや解釈の違いを生まないために工夫したことはありますか。

樽石：機能ごとに地図の空間を明確に切り分け、名前をつけました。

Green Beansの開発で肝になるのは、Ocado社のプラットフォーム上で用意されている様々なシステムなどを統合し、一つのプロダクトに仕上げること。つなぎこむべきシステムがたくさんあるので、それらを指す名前が曖昧だと、エンジニア同士の会話でもコミュニケーションエラーが起こりやすくなります。それにより開発の過程で機能の重複や混同が発生すれば、いざ統合した時に1つのプロダクトとして正常に稼働しない恐れもあります。

こうしたリスクを避けるために、適切な分離（名前空間）と命名による定義づけが必要でした。このときも「ショートメッセージ」の考え方に則り、短い言葉で、曖昧さを排除し正確に伝えられるように名前をつけていきました。

例えばサプライチェーンに関するものは「サプライチェーンコンポーネント」というグループ名をつけ、その中に含まれる個別のシステムを「商品マスタ登録」「発注」「入荷」「取引先ID管理」などとそれぞれ命名して、「『発注システム』といえばこのことだよね」とメンバー全員の認識が正確に揃うようにしました。

樽石：この時行った「世界地図の作成」と、その下準備となる「分離と命名による定義づけ」は、誰もが同じ視点に立つための整地作業のようなもの。山積みになっていた引越しの段ボール箱を整理整頓して、どの部屋にどの箱を置くかをわかりやすく示したわけです。

――つくるシステムが巨大だからこそ、構成要素を適切なサイズに切り分けて名前をつけると、全体像がクリアになりますし、コミュニケーションもとりやすくなりますね。

樽石：チームで物事を進める上で、名前をつけるってすごく大事ですよね。

名前をつけることで、できあがっていないまだ世の中にないシステムの構造や設計について語る際に使う言葉の曖昧さを排除し、全員が共通言語で正確に情報を共有できます。そうしてコミュニケーションをとっていければ、開発途中で設計方針がブレることもありません。

ちなみに、今回つけた名前の中には、私の造語も多くあります。たとえば先ほどの「マイクロカンパニーアーキテクチャ」。これは「Green Beans」における設計方針を表す言葉です。「グループごとに分離した上でシステム開発を進める」という全体設計の方針をこの一言で表現して、細かな定義はデザインドックにまとめました。

名づけの際、よく使われている既存の言葉を流用すると、プロジェクト内での言葉の定義と既存の言葉の意味が混ざり合い、曖昧な表現になってしまう場合もあります。そういうときは、既存の言葉を組み合わせて、新しく言葉をつくっています。

――世界地図の作成でやるべきことの全体像は把握できましたが、何をどの順番で進めるかという優先順位づけで迷うことはありませんでしたか。

樽石：優先順位を決めるのに最も重要な判断軸は「最終的な目標」です。

今回のプロジェクトで目指す目標は、「2023年7月10日にサービスをローンチする」という、正確かつシンプルで曖昧さのない「ショートメッセージ」にまとめ、それを業務部門とも共有していました。

目標をシンプルにしたからこそ、タスクの優先順位を決める際も「ローンチに影響するものから着手する」というシンプルな軸で判断できたし、その判断への納得感も醸成しやすくなりました。ローンチに直接関与しないタスクは、たとえ業務部門からの依頼でも手をつけなかったし、サービス開始後に調整しても問題ないものは後回しにして、今やるべき作業を絞り込みました。

樽石：同時に考えなければいけないのが「最終目標にたどり着くまでに、何をいつまでにやるか」です。そこでゴールから逆算して3ヶ月ごとに中間目標を設定し、段階的な目標を設定しました。

ここでのポイントも、中間目標やその時点での進捗にまつわる曖昧さをなくすために、名前をつけたこと。中間目標ごとに目指す進捗状況を「バージョン」として表すことにしました。

バージョン名AEON NEXTの綴りを省略する形で「ANX（読みはエー・エヌ・エックス）」とし、2022年12月末までに「ANX.0」、2023年3月末までにRelease Candidateとして「ANX1 RC1」、6月までに「ANX1 RC2」を完成させ、7月10日に正式リリース版となる「ANX1」をローンチする。そして「ANX0」はグダグダでもいいから動く状態、「ANX1 RC1」は本番テストができる状態、「ANX1 RC2」は本番リリースができる状態と定義しました。

中間目標をバージョン名で呼ぶと、機能開発の要望をもらったとき「いつまでにその機能をつくるべきか」の相談をしやすくなります。ローンチ後のバージョンにも名前をつけると、早めの対応を希望されたものは「ANX1.1」で、少し遅めでもいいものは次の「ANX1.2」で実装しましょう、などと合意形成をしていけます。このおかげで、希望された機能を実装できそうなタイミングを、相手と正確に共有できるようになりました。

――優先順位をつけたりその合意をとるシーンでも、「曖昧さの排除」が効いてくるのですね。ちなみに、中間目標を3ヶ月ごとに設定したのはなぜですか？

樽石：大きな目標をブレイクダウンして小さな目標を設定する場合、3ヶ月がちょうどいい単位だからです。これが1ヶ月単位だと、1週目は目標を考え、4週目は後処理に使うとして、開発に使えるのは実質的に2週間しかない。集中して何かをやるには短すぎます。

かといって半年単位だと、次の中間目標までの期間が長すぎて、その間に状況が変わってしまい、目標と現状が乖離して、「これはもうやらなくていいよね」と途中で放り出すことになりがちです。それではメンバーにやり切る習慣がつかないので、マネジメントの立場としては避けたい。

3カ月、つまり12週間なら、1週目に目標を考え、12週目に後処理するとして、実装に10週間使える。この10週間が、インパクトの大きい中間目標を達成するのにちょうどいい期間なんですよね。

――樽石さんが「曖昧さ」を徹底的に排除する上で意識していたという「ショートメッセージ」で表現する力は、どうトレーニングしたら身につきますか？

樽石：身近ですぐできることとしては、Xでの投稿がおすすめです。140字という文字数制限があるので、言いたいことを短い言葉で伝えるトレーニングになります。

日々の業務中では、Slackで話すときに長文を送らず、1文ずつ送り合うようにしています。長文を送りたいと思った時は、とりあえず書きなぐった言葉を生成AIに短くしてもらうのもいいですよ。短く端的に伝えるためのポイントの絞り方を学ぶことができます。

――すぐできる取り組みもたくさんあるのですね。今回のプロジェクトで、「ショートメッセージ」で解決した課題のほかに、プロジェクトを進める上でどんな課題がありましたか？

樽石：オープンコミュニケーションの少なさです。物事を決めるのは主に会議の場で、あとはメールでやりとりする程度。チャットでの日常的な議論や、議事録による情報共有はほとんど行われず、特定の人だけに情報が偏っていました。

そこで入社してすぐに、IT部門にSlackを導入し、「オープンコミュニケーションを実践しよう」とメッセージを打ち出しました。「Slackはいわば“タバコ部屋2.0”です。ひと昔前、皆がタバコ部屋に集まって情報交換や世間話をしたように、誰でも参加できるパブリックチャンネルでどんどん会話してください」と。

全員に見える場所で非同期的に会話する文化に慣れていない人に、オープンコミュニケ―ションの意義を伝える際にも、「ショートメッセージ」の考え方が役立っています。

――なるほど。たしかに、わかりやすいメッセージですね。

樽石：さらに各チャンネルの使用率を毎週スクリーンショットで貼り付けて、「先週のパブリックチャンネル投稿率は80％でした。90％を目指してどんどん書き込みましょう」などと促しました。

最初のうちはDMでやり取りするメンバーも多かったのですが、「DMを減らすべきだ」とは思ってなくて。DMの数自体は減らなくても、同じ内容をパブリックにも投稿すれば、パブリックの比率が上がります。すると相対的にDM率は下がりますよね。

パブリックチャンネルでの投稿に慣れてもらうために、最初は「『眠い』でも『お腹がすいた』でも何でもいいから書いてね」と伝えていました。今ではメンバーもパブリックチャンネルで積極的に発信してくれるようになって、部門内のコミュニケーションも活発になったと感じています。

――課題が山積する中、1年というタイムリミットを背負いながらローンチに漕ぎ着けるのは、相当なプレッシャーがあったと思います。それでも心が折れることなく、目標を達成できたのはなぜでしょうか。

樽石：入社時に「ローンチまでは必ずやり切る」と決めていたからでしょうね。あとのことは考えず、とにかくサービスを立ち上げることに集中していたので、どうやってローンチするかということしか頭にありませんでした。入社後は怒涛の日々だったので、しんどいとかつらいとか考える暇すらなかったというのが正直なところでもあります。

でもピンチの時って、逆にモチベーションが上がりませんか？　この局面を何とか乗り切ろうとやる気に火がつき、むしろ普段以上に意欲的になるでしょう。だからこそ、状況の困難さに気圧されず、着実に進んでいけたのだと思います。

とはいえ、そもそもこのローンチは私1人でやり遂げたわけではなく、周囲も協力的だったからできたこと。IT部門のエンジニアはもちろん、小売の現場に精通したたくさんの仲間に助けてもらいながら、ゴールまで走り切ることができました。

「関係者同士の共通認識をつくることが重要」とわかっていても、「きっと皆自分と同じ認識を持っているだろう」という思い込みから、日頃そこまで強く意識するタイミングは多くないかもしれません。でも、困難な状況を打開するために、ひとつひとつの言葉の定義から合わせていくと、後々大きなパワーにつながる。そう改めて実感したプロジェクトでもありました。

これからもっと多くの方にGreen Beansを知ってもらい、便利なサービスとして選んでもらえるよう、メンバーとコミュニケーションをとりながら、その価値を高めていきたいですね。

取材・執筆：塚田有香
編集：光松瞳・王雨舟
撮影：赤松洋太