Please enable JavaScript.
Coggle requires JavaScript to display documents.
EC・EC部隊 (WEBマスター不在 (Rubyとうまく コミュニケーション とれない (工数感把握できてる？…
EC・EC部隊
WEBマスター不在
Rubyとうまく
コミュニケーション
とれない
工数感把握できてる？
工数見積に対しても工数がかかること、わかっている？？
ロードマップ描ける？（現状ない筈）
連絡用テンプレつくったら？
バックグラウンドある人でないと非常にきついんじゃ？
Backlogが整備されない
「運用課題/連絡」なのか「バグ」なのか「機能開発」なのか、ワケがワカラナイ
「運用系」と「バグ／機能開発系」で分けたら？
（閲覧制限はなくてもよいと思うが）
書込制限はつけてよいのでは？
（制限はバグ・機能開発の話）
（運用は多分馴染まないかと）
スペースが分かれたのは認識したが、用途が不明
ウェブマスタがいないから
優先度と重要度の仕分けがイマイチ？
デサント内の連絡の出本がバラバラ
「Backlogにあがってこないけど助けられる課題」
があるんじゃないかと思う（推測レベルの話）
Backlogにあがってこないから拾えない
何が課題かわからないうちから拾えるとは言えない
席も遠くて何で困っているのか把握しにくい
Backlogにあがってきたもの、かつ、担当設定されたものは解決してきた...と思う
(少なくとも３、4例は存在）
イメージでは、作業系の課題。
ルールチェック系の作業とか。
ブランド別担当を続ける？
機能別に分けたら？
多ブランドの組み合わせ、できる／やる見込みあるの？
今まで見たことあるのは単一ブランドでの特集・メール（な気がする）
※SFMCが発射しているメールを除く
効率的に業務できているの？
（とりわけ手を動かすことについて）
EC側の担当・デジマの担当・各ブランドの担当の切り口がイマイチなのでは？
コンテンツ盛るのに専心する人がいるのもアリでは？
（ブランド側と話をできる人も立てる必要があるが）
（完全に別課題...BPR側で進行中）
（例）
・週に3日かけてエクセル資料作成している人もいる
・出力できる情報に制約があり、何とかやりくり
ルールを作るなら、機能別のほうがよい（と思う。どうしてもブランド側見てると、ウェブページ側のルールまでは見てられないだろうし）
期待値調整が大変？
メールを送りすぎ
（crosspoint, SFMC, 旧オンラインショップ）。
crosspointみたいなDBは、デジマで見るほうがよいのでは？
ただ、各店舗が（独自で？）取得しているメールアドレスへのメルマガ配信にcrosspointが必要だから、EC部隊が見るほうがよい？
白上業務
SFCC研修を活かす機会があまりない
とはいえ
一人で運用改善開発は
かなりムリある
ミニマム３人は欲しい・・・（それ以上必要な場合は、うまく外を使えたら・・・）
５人とか１０人とか、いたらいたでいいけど、その人件費に見合うかたちでの貢献が大変になるのが明らか
塩梅難しい
高い研修行かせてもらったのに、
これで良いのか？感
で、白上はやりたいの？ → やりたい
Rubyまで行って仕事するのはアリ？
（仮に実現できたとしても、どれだけRuby側からみて戦力になるか、ちょっとわかんない。「いるだけジャマ」になったら悲しい．．．）
MAツールを活かしきれていない
色表記がバラバラ
→学習データとして☓
パーソナライズされたオートメーションは夢状態
（行動履歴からのオートメーションはできるけど）
（もっとも、カラー・サイズまでバッチリピッタリのパーソナライズは難しいのはわかるけど、やれたら素敵じゃない？）
サイズ表記がバラバラ→学習データとしてX
表記のおかしなメールが配信される可能性
Backlogがカオス。助けられない。
（白上視点）
何が論点なのかワカラナイ
ありたいかたちが記載されないまま課題としてあげられているのを見た
「で、結局、どうしたいの？？？」
がわからないのが一番困る
（と思う。開発側からすると。）
白上視点だと、どこまで踏み込めるか見当つかない
（ので、言われたらやるスタイル）
このスタイルで良いか悪いかは別としてそれなりに回っている？
終わった（？）課題が完了ステータスとされていない
ちゃんとクローズしたらクローズさせましょう！！！
「優先度：高」の課題が、課題を立ててから数ヶ月経過しても存在
優先度と重要度は別物でしょ！！！
つまらない写真エラーや文言エラーばかり指摘している気がする（EC）
若干心苦しい。手間生むけどお金産まない。多少の質には貢献するだろうけど、あんまり意味ない。
「このぐらい、自分でやっちゃいたい」感
会社全体
ITリテラシーに課題
可笑しな表記のままの製品がECにあがる
チェック機構はどうなっているの？
ＥＣ内検索でもヒットしない...
チェックはしているのだろうけど精度がどうなんでしょうか・・・
OCRの設定見直したら、直るんじゃない？
リテラシー低くとも、
見え様は画面見ればわかる
（中身はわからなくても）
よくわからないまま、知らず知らずのうちに無茶要求？
画像サイズ・質がバラバラ
質が良すぎても意味ない
（ページロードに時間かかるだけ）
圧縮・リサイズなどをルール化すればいいだけでは・・・？
データ整理に課題
確固たる
商品マスタがない
（もしあれば、個人作成マスタなんてものはいらないんじゃ？）
とはいえ若干は残ると思うが...
商品情報が云々、という問題が起こるんじゃ？
担当領域が明瞭でないから、全員で調整している？
何にせよ調整に時間をさかないといけなくなる状況？
あんまり正確にわかっていないけど、なにかあったような・・・（うろ覚え）
品番もルールに沿いきっていない（過渡期だから？であれば、いつからルールに沿う？）
カテゴリも、なんだかよくわからん状態
ECで使っているカテゴリは認識している
ECカテゴリは部門側と共通認識あり？
（必ずしも揃える必要はないのかもしれないが、そうすると全社で俯瞰して数字を見たいときに、かなり困るはず）
では、基幹システムが持つ商品のカテゴリ情報はどうなる？？
データを利用する環境が整備されていない
恐らく、
・過去に会社がくっついてできた
・ブランドが増減した、
ということの残課題
（会社はくっついた、
でもシステムはちがった）
過去がどうであったとしても、今の情シスの仕事はとても微妙
メール配信機能兼データベースのcrosspointが、イマイチ
配信後に開封率などの指標を見ることができない
入会日か何かのデータが上書きされる問題があったはず。ただ、現状、crosspointはECが主で見ているので、何が上書きされるのか正確にわかっていない。
（隣の席で話をしているのを又聞き状態だったので、なおよくわかっていない）
要望を全て満たすようなことは難しいのは理解しているつもり
商品購入後、返品された場合のデータの持ち方がイマイチ。
売上取消のレコードに、元の売上の伝票番号の記載がないので、どの伝票番号のものが取り消されたのかわからない
品番体系等、全商品またがるものは、
・企画管理部隊が整理して
・システム部隊が整理された要望に沿ってシステム構築
するような話ではないのか？
ブランドサイト・デジマ部隊
上から数字が降ってきたり、
急な依頼来たり