ユーザーストーリーマッピングの5工程|作る順番を決める地図

「各部署から要望を集めたら200行の一覧になりました。どれから作るかが決まりません」「予算に収まる分だけ出したいのですが、削ろうとすると必ず、それを外すと動きませんと言われます」——社内システムやサイト、AIの導入を発注する立場の人から、この2つはほぼ同じ形で出てきます。行数が多いことが問題なのではありません。本当は、要望を一覧にした瞬間に、使う人の行動の順番という手がかりが捨てられていることが原因です。この記事では、行動を左から右に並べて量を見えるようにし、最初に出す範囲を自分たちで線引きするまでの5工程を整理します。
カメ先生要望の一覧は、長くなるほど優先順位がつけやすくなると思われがちだね。でも実際は逆で、平らな一覧にした時点で、どれが先かを決める手がかりが消えてしまうんだ。
カメ子一覧にすると手がかりが消える、ということですか。
カメ先生消えるのは並び順だけではないんだ。どの要望がどの要望と一緒でないと動かないのか、という関係まで失われる。だから並びを残したまま置く。それがこの地図の役目だよ。
カメ子置き方を変えるだけで、線を引ける場所が見えてくるのですね。
- 使う人の行動を左から右に並べ、その下にやることを積むと、量と順番が同時に見える
- 最初に出す範囲を決める横線は、作り手ではなく発注する側が引く判断
- AIは聞き取りメモから並びとやることの候補を起こせるが、線をどこに引くかは人が持つ
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
要望の一覧を前にして、どれから作るか決められない
発注の準備は、たいてい要望集めから始まります。関係部署に聞き取りをして、上がってきた項目を表にする。ここまでは誰でもできます。詰まるのはその次です。200行の表を前にして、どれから作るかを決める手がかりが、その表の中にない。優先度の列を作ってAとBとCを振ってみても、各部署は自分の要望をAに置きます。結果としてAだけで150行になり、線が引けません。
この地図の提唱者であるジェフ・パットン氏は、優先順に並べただけの平らな一覧を「文脈のない腐葉土を詰めた袋」と表現しています。1列に並べ替えた時点で、どの項目とどの項目が一緒でないと成り立たないのか、どれが欠けると全体が止まるのかという関係が消える。だから1行ずつ読んでも軽重が判断できず、削ろうとするたびに、それを外すと動きませんという反論が返ってくる状態になります。反論している人が正しいこともあります。関係が見えていないので、正しいかどうかを確かめる手立てがないのです。
そして範囲を切らずに進めると、何が起きるかは数字に出ています。日本情報システム・ユーザー協会の「企業IT動向調査2025」は、4,500社に配布して981社から回答を得た調査です。2024年度分の開発規模別の工期を見ると、100人月未満のプロジェクトは「予定どおり完了」が31.0%、「予定より遅延」が16.6%。これが500人月以上になると、「予定どおり完了」は11.0%に下がり、「予定より遅延」は43.7%に上がります。品質の満足度も、500人月以上では「満足」が8.2%、「不満」が28.6%。範囲を大きく取ることそれ自体が、遅れと不満の確率を押し上げているという読み方ができます。だから、決めるべきは順位の付け方より先に、一度に出す量です。
ユーザーストーリーマッピングとは、行動の並びの下にやることを積んだ1枚
ユーザーストーリーマッピングは、使う人の行動を横一列に時間順で並べ、その各行動の下に、それを成り立たせるためにやることを縦に積むという置き方です。横は時間、縦は必要度。この2方向にするだけで、一覧では見えなかった2つのことが同時に見えます。ひとつはやることの総量。もうひとつは、どの行動が重くて、どの行動が軽いかという偏りです。
パットン氏は上段に並ぶ大きな行動を背骨、その下にぶら下がるやることをあばら骨にたとえています。並べる順番の決め方も明快で、システムの振る舞いを人に説明するときに話す順番が正しい順番だとしています。順位ではなく、時間が左から右へ流れていると考える。この基準があるので、並べ方について社内でもめることがほとんど起きません。誰が偉いかではなく、実際にどの順で手を動かすかだけを聞けばよいからです。
そして、この置き方の本当の用途は横線です。パットン氏は、長い養生テープで地図を横に区切り、出す回ごとの帯を作ると書いています。テープの上に来たやることが今回作る範囲、下に来たやることが今回は作らない範囲。一覧のままなら「どこまで」という話は行数の争いになりますが、地図の上では線の高さの話になります。線を1本引くだけで、範囲の合意が一目で共有できる形に変わります。
業務フロー図は「いまの流れ」、この地図は「これから作るものの並び」
この地図は、よく業務フロー図と混同されます。混同したまま作ると、いまの手順をそのまま機能に置き換えた一覧ができ上がり、結局量が減りません。両者は描く対象が違います。業務フロー図はいま実際に起きている仕事の流れを写した図で、この地図はこれから作るものの並びを置いた図です。前者は現状の観察、後者は設計前の意思決定に使います。
| 3つの図 | 描くもの | 何を決めるために使うか |
|---|---|---|
| 業務フロー図 | いまの仕事の流れ。担当・道具・分岐・戻り | どこが詰まっているか、どこを自動化できるか |
| この地図 | これから作るものの並び。使う人の行動と、その下のやること | 最初に出す範囲をどの高さで切るか |
| 画面の一覧 | 作る画面と、画面の中の部品 | 画面ごとの中身と、作る手間の量 |
入口として、動かせない前提の整理は地図より先に済ませておきます。法令、既存システムとの接続、締め日、予算の上限といった変えられない条件と、変えられる要望を分ける作業です。ここが混ざったまま地図を作ると、線を引く段になって「それは法令で必須なので下げられない」という話が後から出て、並べ直しになります。前提と要望の切り分けそのものは別の記事の主題なので、ここでは動かせない条件は地図に載せず、別紙で押さえておくという置き方だけ覚えてください。
提案依頼書との関係も整理しておきます。地図は、提案依頼書を書く前に社内で並べる作業です。地図がないまま提案依頼書に入ると、機能の一覧をそのまま貼ることになり、受け取った側は全部を見積もるしかありません。地図があれば、必ず作る範囲と調整してよい範囲を分けて書けます。この分け方は、政府のガイドブックが調達仕様書に求めている形とも一致します。
5つの工程を、先に通しで見る
作る手順は5つです。全体を見てから細部に入ると、どの工程で何を決めているのかを見失いません。所要時間は、参加者が5人前後で、対象が1つの業務なら半日から1日。2日かけても終わらないときは、対象にした業務が大きすぎるか、使う人を絞れていないと考えて、工程1に戻ります。
誰のどの困りごとを解消する地図なのかを1つに決めます。複数の役割を1枚に混ぜないことが、この工程の唯一の仕事です。
その人が最初にすることから最後にすることまでを、動詞で1枚ずつ書いて横に並べます。まだ、やることは書きません。
行動を成り立たせるために作るものを、その行動の真下に縦に積みます。上に置くほど、それがないと行動が完成しないもの。
端から端まで一通り動く最小の組み合わせを線の上に集めます。線の下に落ちたものは、次以降に回す範囲として明記します。
行動の間が飛んでいるところ、戻る動きが書かれていないところ、下が異常に厚い行動を探して直します。
この5つのうち、外部の力を借りてよいのは工程2と工程3の下書きまでです。工程1の絞り込みと工程4の線引きは、発注する側が自分でやらないと意味がありません。作り手に決めてもらうと、作りやすい順に線が引かれます。それは悪意ではなく、目的を持っているのが発注側だけだからです。
工程1:使う人と目的を1つに絞る
最初に決めるのは、この地図が誰のためのものかです。1枚に複数の役割を混ぜると、行動の並びが途中で分岐して、横に並べられなくなります。受付をする人と承認をする人と月末に集計をする人は、別の地図にする。関係する役割が3つあるなら、まず件数が最も多い役割の地図を1枚作り、残りは後から作ります。1枚目を作る過程で書き方が固まるので、2枚目以降は半分の時間で終わります。
目的は、道具の言葉ではなく業務の言葉で書きます。「問い合わせ管理システムを導入する」は目的ではありません。「問い合わせが届いてから担当者に渡るまでを、いまの平均40分から10分にする」「取りこぼしによる再連絡を、月18件から5件以下にする」のように、あとで達成できたか確かめられる形にする。この一文が、工程4で線を引くときの物差しになります。物差しがないと、線は結局「予算に入る分」で決まり、目的に届かない範囲が選ばれます。
決める人も、この工程で1人に固めます。政府の「アジャイル開発実践ガイドブック」は、意思決定が混乱しないよう、1つのプロジェクトに置く決定役は原則1名としています。同じガイドブックは、その役割が「何から形にしていくべきか」という判断の中心だとも書いています。地図の前に立って線を引くのは、この1人です。複数部署の合議で線を引こうとすると、全員の必須が集まって、また同じ長さの一覧に戻ります。
工程2:行動を時間順に左から右へ並べる
次に、その人が最初にすることから最後にすることまでを、1枚1動作で書いて横に並べます。書き方の決め手は動詞です。「問い合わせ一覧画面」は画面の名前であって行動ではありません。「届いた問い合わせの内容を読む」「担当部署を判断する」「担当者に割り振る」のように、必ず動詞で終わる形で書く。名詞で書くと、その裏にある判断や確認が丸ごと抜け落ちます。
粒度は、一息で終わって次に移れる単位にそろえます。細かすぎると枚数が増えて並べ替えができず、粗すぎると下に積むやることが混み合います。目安は、最初と最後を先に置いてから間を埋める進め方です。始まりの合図と、終わりの状態を先に決めてしまうと、間に入る行動の数が自然に決まります。始まりは「問い合わせメールが届いたとき」、終わりは「担当者が回答を送り、記録が残った状態」のように書きます。
- 行動の枚数は8枚から15枚くらいが扱いやすい。20枚を超えたら、1枚の地図に目的が2つ混ざっていないか見直す
- 紙でもオンラインの共同編集でもよいが、並べ替えが1動作でできる道具を選ぶ。並べ替えに手間がかかる道具だと、直さなくなる
- 地図は納品物ではなく決めるための道具。清書に時間をかけず、線を引いたあとの写真か書き出しだけを残す
工程3:各行動の下に、やることを積む
行動が並んだら、それぞれの真下に、その行動を成り立たせるために作るものを積みます。積む順番には意味を持たせます。上に置くほど、それがないとその行動が成立しないもの。下に置くほど、なくても行動は完成するもの。「担当部署を判断する」の下なら、上から順に、判断の材料になる情報を画面に出す、担当を選んで登録する、過去の似た問い合わせを参考として並べる、判断の傾向を月次で集計する、といった積み方になります。
1枚の書き方には決まった型があります。誰が、いつ、何をして、どうなれば終わりか、要るデータの5つです。この5つがそろわない枚は、まだ決まっていないことがある証拠として、赤い付箋などで印を付けておきます。特に「どうなれば終わりか」が書けない枚は、線の上に置いてはいけません。終わりの条件が曖昧なままだと、作り手と発注側で完成の判断が食い違い、検収で止まります。
積み終わったところで、行動ごとの枚数を数えます。1つの行動の下に10枚以上たまっているところは、その行動が大きすぎるか、そこに一番の困りごとが集まっているところです。前者なら行動を2つに割ります。後者なら、そこが投資の主戦場だと分かるので、線を引くときに他を削ってでも残す候補になります。数えるだけで、感覚で語られていた重さが数字になります。
工程4:横線を引いて、最初に出す範囲を決める
いよいよ線を引きます。基準は1つです。端から端まで一通り動く最小の組み合わせを、線の上に集める。パットン氏はこれを、端から端まで機能する最小のシステムと呼び、歩く骨格という言い方に結び付けています。骨格ですから、細部は貧弱でよい。ただし左端から右端までつながっていることが条件です。途中が欠けていると、使う人は誰も業務を完了できず、出しても使われません。
この線引きは、そのまま発注の文書に落ちます。政府の「アジャイル開発実践ガイドブック」は、実用的で最小限の範囲で動くものを、課題を解決するために重要でかつ極力範囲を絞った領域と定義し、その時点で必須もしくは優先度の高い範囲と、開発対象としたいが実現範囲と内容は調整可能な範囲という、少なくとも2つの領域を設けて調達仕様書に示すよう求めています。地図の線の上が前者、線の下が後者。地図を作っておけば、この2区分は書き写すだけで済みます。
線は1本だけ引くものでもありません。1本目の下に2本目、3本目を引いて、出す順の帯を作ります。ここで効いてくるのが、先に見た調査結果です。同じ「企業IT動向調査2025」で、工期・予算・品質のいずれかが悪化した企業にその背景を聞くと、最も多く挙がったのは「要件定義の難易度向上」で、3つの回答群のいずれでも47.2%から51.0%。次が「システム影響範囲の拡大」で44.6%から46.1%でした。難しさと影響範囲は、範囲を小さく区切ることで直接下げられる数少ない要因です。帯を作ることは、腕を上げる代わりに条件を変える打ち手だと言えます。
工程5:抜けと重さを見直す
最後に、地図を使って抜けを探します。この置き方の効き目が一番出るのがここです。探し方は2つあり、どちらも目で見つかります。ひとつは行動の間が飛んでいるところ。「申請する」の次が「承認される」になっていたら、その間にある「内容を確認する」「不足を問い合わせる」が抜けています。時間順に並んでいるので、間隔の不自然さが形として見えます。
もうひとつは戻る動きが書かれていないところです。差し戻し、取り消し、間違えて登録したときの修正、締めたあとの訂正。一覧で要望を集めると、この種の行動はほぼ全部抜けます。誰も要望として言わないからです。それでも運用が始まれば必ず発生し、あとから追加すると影響範囲が広い。地図では、左向きの矢印を書き込む欄を作っておくと、戻る動きが1本もない地図はおかしい、と気づけます。締め処理、月をまたぐ処理、担当が変わるときの引き継ぎも、同じ理由で抜けやすい行動です。
重さの見直しは、線をまたいで行います。線の上に置いたやることのうち、1枚だけ極端に重いものがあれば、その1枚のせいで最初の出しが遅れます。その場合は、その枚を2つに割って、簡易な形を上に、作り込んだ形を下に置き直します。たとえば「担当を自動で振り分ける」を、「担当を手で選んで登録する」と「過去の実績から候補を出す」に割る。最初の出しに自動化を含めないと決めるだけで、公開までの日数が大きく変わります。
1枚に書く項目の実務仕様
やることの1枚に書く項目を、実務で使える形に固定しておきます。書式を毎回考えると、参加者ごとに粒度が変わり、あとで並べ替えができなくなります。5項目に絞るのが実用的です。誰が、いつ、何をして、どうなれば終わりか、要るデータ。この順に一文ずつ書きます。
| 1枚に書く項目 | 書き方の決まり | 記入例 |
|---|---|---|
| 誰が | 役割名を1つ。部署名ではなく、その場で手を動かす人 | 受付担当 |
| いつ | その行動が始まる合図を1つ | 問い合わせのメールが届いたとき |
| 何をして | 動詞で1つ。2つの動作を書かない | 内容を読んで、担当部署に振り分ける |
| どうなれば終わりか | 外から見て確かめられる状態 | 担当者に通知が届き、一覧の状態が受付済みになる |
| 要るデータ | その行動で読むもの、書き込むもの | 問い合わせの本文、部署と担当の対応表 |
この5項目には、それぞれ後工程での使いみちがあります。「誰が」は権限設計の材料、「いつ」は連携や通知の条件、「どうなれば終わりか」は検収の合格条件、「要るデータ」は既存システムからの持ち出しや個人情報の扱いの検討材料になります。地図の段階で書いておけば、要件を書き起こす段になって聞き直す往復が消えます。特に「要るデータ」は、書き出してみると社内に存在しないデータが見つかることがあり、その時点で範囲の判断が変わります。
なお、この5項目は、いまの業務の流れを書き出すときの行の項目とは別物です。業務の流れを書くときは、件数や1回あたりの時間、使っている道具まで含めて記録します。こちらは、これから作る1つの単位として過不足なく発注できるかどうかだけを見ます。同じ紙に両方を書こうとすると、どちらの目的にも足りない中間物ができます。
作る前に確かめる項目の一覧
地図を作る会議を開く前に、この一覧を通します。ここが埋まっていないまま集まると、その場の議論が前提の確認だけで終わり、並べる作業に入れません。特に上の4つが空欄のまま集まった会議は、ほぼ必ず作り直しになります。
- 使う人を1つの役割に絞ったか。承認する人や集計する人を同じ1枚に混ぜていないか
- 目的を業務の言葉で書いたか。あとで達成を確かめられる数か状態になっているか
- 動かせない前提(法令、既存システムとの接続、締め日、予算の上限)を別紙で押さえたか
- 線を引く人を1人に決めたか。その人が地図の前に立てる時間を日程に入れたか
- 最初にすることと最後にすることを、先に文章で書いてあるか
- 戻る動き(差し戻し、取り消し、訂正)を書き込む欄を用意したか
- 月をまたぐ処理、締め処理、引き継ぎを書く場所を決めたか
- 出さないと決めた範囲を、出す範囲と同じ分量で書き残す欄を作ったか
- 地図を置く場所と、次に見直す日を決めたか
- 社外の制約(取引先の運用、利用中のサービスの仕様)を書き出してあるか
この一覧のうち、4番目と8番目は体制の話です。決める人が1人いること、そして出さないと決めたことが文書として残ること。政府のガイドブックも、調達仕様書に「アジャイル開発を採用すること」と書けばあとは事業者がうまく進めてくれると考えてはいけないと明記し、発注側が日次ないし週数回以上の打ち合わせの時間を確保する必要があると書いています。地図は作れば終わりではなく、線を引き直す場を持ち続ける前提の道具です。
横線を引くときにやりがちな失敗
線引きは、地図を作る中で最も判断が要る工程です。ここで型どおりの失敗をすると、地図を作った意味がなくなります。よく見る形を挙げます。
- 全部を1回で出す:最下段に線を引くのと同じで、範囲を切っていない。規模が上がるほど予定どおり終わらない確率が上がるという調査結果に、そのまま乗ることになる
- 部署ごとに縦に切る:営業部門の分だけ先に出すと、使う人の行動が途中で切れる。左端から右端までつながっていないので、誰も業務を完了できない
- 画面の数で切る:画面3枚分と決めても、1枚の画面の裏に重い判断や連携が隠れていれば量は読めない。画面は行動の器であって、量の単位ではない
- 期間で先に切る:3か月でできる分と決めてから中身を選ぶと、軽いものだけが残る。目的に届かない範囲が出来上がり、次の予算が取りにくくなる
- 線の上を全部必須にする:外せないものだけを集めた結果、また同じ長さの一覧に戻る。線の上は、目的の一文に直接効くものだけに絞る
2番目の縦切りは、社内の力関係が強い組織でとくに起きます。声の大きい部署の要望が先にまとまって出るためです。防ぎ方は工程1に戻ることで、使う人を1つに絞った地図を役割ごとに作り、地図の単位で順番を決める。部署の中の一部だけを切り出すのではなく、ある役割の業務が端から端まで通る形で1つ出す、という切り方にします。
政府のガイドブックには、この種の失敗の実例も載っています。ある情報システムでは、初期に優先度がそれほど高くない機能に工数を使い、後々優先度の高い機能の実現に支障が生じたという記述です。同じ資料は、重要な範囲を明らかにしていても、残りの回数を常に見ていなければ本当に重要な範囲を実現できなくなる恐れがあると付け加えています。線は引いたあとも守られているか確認しないと、意味を失います。
使われない機能に、いくら払っているのか
線を引くことに気が引ける人は多いです。削ったものが本当は必要だったら、という不安があるからです。ただ、逆側の損も見ておく必要があります。ソフトウェアの利用状況を分析する米国企業が2019年に公表した調査では、1年以上の利用実績がある615件の契約について3か月分の利用データを集計し、平均的な製品の機能のうち80%はまれにしか使われない、または一度も使われていないと報告しています。内訳は、一度も使われないものが56%、まれにしか使われないものが24%。日常的に使われているものは12%で、この12%が1日あたりの利用量の80%を生んでいました。
同じ調査は、上場しているクラウド企業がこうした機能の開発に投じた額を、研究開発費の8割にあたる295億ドルと見積もっています。この数字はクラウド型の製品を対象にした集計で、社内システムの実測ではありません。ただ、傾向として押さえておく価値はあります。政府のガイドブックも、多くのソフトウェアで開発した機能の半分以上がほとんど使われないという統計を根拠に、いま本当に必要なものだけを作ろうという考え方を紹介し、使われない機能でもテストや保守、手順書の作成に費用がかかり、複雑さも増すと書いています。
この視点で見ると、線を引く行為の性質が変わります。線は我慢ではなく、使われるか分からないものへの支払いを、確かめてからに変える判断です。線の下に落としたものは捨てるのではありません。最初の出しを使ってもらったあと、実際の使われ方を見て、上げるか下げるかを決め直す。そのための判断材料が手に入るのが、小さく出す最大の見返りです。地図が残っていれば、この見直しは線の高さを動かすだけで済みます。
生成AIに任せてよい3つの仕事と、渡し方
この作業で生成AIが効くのは、手を動かす量が多くて判断が要らないところです。任せられるのは3つあります。ひとつは聞き取りメモから行動の並びの候補を起こすこと。会議の記録や、担当者に手順を話してもらった書き起こしを渡し、動詞の形にそろえた行動を時間順に並べさせます。人が最初から付箋に書くより速く、抜けの多い草案が短時間で手に入ります。
2つめは各行動の下に積むやることの候補を出させること、3つめは抜けている行動を指摘させることです。3つめは特に有効で、戻る動き、締め処理、担当が変わるときの引き継ぎといった、社内の要望には出てこない行動を挙げさせます。渡し方には条件を付けます。次のように、根拠と粒度と、書いてよい範囲を先に指定します。
次の聞き取りメモから、使う人の行動を時間順に並べた候補を作ってください。
条件:
・1行1動作。必ず動詞で終える形にする
・各行について、メモの何行目を根拠にしたかを併記する
・メモに書かれていない行動は、推測欄に分けて書き、本編には混ぜない
・各行動の下に、やることの候補を3つまで。優先度は付けない
・回答の最後に、メモから読み取れなかった項目を質問として列挙する
要点は、推測した部分を分けて書かせ、どこから起こしたかを言わせることです。混ぜて出されると、確かめる作業が全文の読み直しになります。分けさせておけば、人が見る範囲は推測欄と質問欄だけになり、確認の手間が数分の一で済みます。人が確認する範囲を先に決めておくのが、生成物を実務で使うための条件です。
AIが起こした並びを、そのまま地図にしない理由
では、なぜそのまま使えないのか。この点は研究で測られています。要求の起こし方を扱った論文では、10種類の言語モデルに聞き取りの場を再現させ、合計13,958本のユーザーストーリーを生成させて、品質を13項目の枠組みで評価しました。結果は、網羅と文体は人と同等だが、多様性と独自性が低く、受け入れの品質基準を満たす頻度は人より低いというものでした。しかも、この傾向はモデルの規模を上げても変わらなかったと報告されています。
多様性の数字は分かりやすい形で出ています。人が書いた組の多様性は98.58%で、モデル側で最も高かったものは74.74%。同じ聞き取りを渡しても、人は解釈や表現がばらけるのに対し、モデルは似た並びを繰り返すということです。一方で網羅は得意で、判定を厳しくしても上位のモデルは84.91%から88.68%の網羅を保ちました。つまり、広く並べる仕事は任せられるが、自社にしかない事情を拾う仕事は任せられないという分担になります。
実務で最も注意すべきは、実際には起きない行動をもっともらしく並べてくる点です。一般的な業務の型を学んでいるので、その会社では省略されている確認や、そもそも存在しない部署の作業が、自然な文章で混ざります。判定の方法は1つで、起こした行動を、その業務を毎日している人に読ませて、やっていないものに印を付けてもらう。ここを飛ばすと、架空の行動の下にやることが積まれ、線の上に入り込みます。線をどこに引くかと、出さないと決めることは、最後まで人の判断として残してください。
まとめ
ユーザーストーリーマッピングは、使う人の行動を左から右に並べ、その下にやることを積んで、横線で最初に出す範囲を切る置き方です。使う人と目的を1つに絞り、行動を動詞で並べ、下にやることを積み、線を引き、抜けと重さを見直す。この5工程で、要望の一覧では見えなかったやることの総量と、削ってよい場所が同時に見えます。1枚には、誰が、いつ、何をして、どうなれば終わりか、要るデータの5項目を書く。線の上と下は、そのまま調達の文書の2区分になります。生成AIには聞き取りメモから並びと抜けを起こさせ、推測した部分と根拠を分けて書かせる。そのうえで、線の高さを決める判断だけは自分たちで持つ。まずは、いま止まっている一覧の中から使う人を1つ選んで、その人の行動を10枚ほど並べてみてください。
※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。
AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?
デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。
