カミナシ入社3ヶ月のデザイナーがもがいたこと
こんにちは！べっちと申します。
1月に株式会社カミナシへ入社し、今月4月で4ヶ月目となりました。新規プロダクトの2人目デザイナーをやっております。
思い返せば入社前の12月は「自分は役に立てるのだろうか…」と不安な日々を過ごしていました。正直、カミナシに入社する嬉しさよりも不安が勝っていました。
この記事は
カミナシのデザイナーって入社してすぐ何をやるの？悩みは何だったの？
まだプロダクトがローンチされていない開発チームの2人目デザイナーがどんな”もがき”をしたの？
そのような気持ちの方に向けた1人のデザイナーのもがき共有記事になります！
ここから入社3ヶ月目まで1ヶ月ごとに振り返っていきます！
1ヶ月目
アウトプットできないもがきとインプット祭り
1ヶ月目は、守破離の守の時期でした。ドメイン、サービスチーム、デザインの考え方、会社のカルチャーなど、色々なことを理解していく時期でした。
😶🌫️ 悩みポイント
私はインプット中心の時期はあってよいとしても、アウトプットをしていないと会社に貢献できているのか不安になることがあります。いち早くUIデザインに入って役に立ちたい、けどインプットの大切さもすごくわかるのでやらねば、そんな心持ちでのスタートでした…。
緊張の初日はリモート。ゆるやかに多忙
カミナシはリモート勤務がメインです。入社初日は出社かなと思っていたら、リモートでした。
午前中は人事やコーポレートの方々が、会社の仕組みや制度を紹介してくれました。
ゆるやかな雰囲気で、私に合っているな〜と思ったのを覚えています。
「できれば初日に、自己紹介Notionを共有してね！」とおっしゃってたので、午後はせっせと自己紹介を作ってました。
食品製造業、機械製造業を業界勉強をする
カミナシは特に食品製造業・機械製造業のお客様のご利用が多いです。そのため、社内にあるオンボーディング資料も充実しています。
その資料をチェックしたり、その業界で働く友人へのインタビューをする、「食品製造 組織構造」「食品製造 インタビュー」等で検索する、そしてなんといってもカミナシの醍醐味である”現場訪問”を行い、業界勉強を繰り返しました。
各職種の役割や組織構造の関係図を書いて、先輩に合ってるか質問したり…
現場訪問に同席させてもらい、お客様が働く環境を五感で体感しました。
耳：現場ではどんな音がなっているか、現場で使われる言葉はなにか
目：どんな服装で働いているか、デバイスは共用か・何人で共用するか
特に、現場訪問したときの記録 服装と手や床の状態（水があるかどうか）に着目しました。
訪問前から「ゴム手袋」をしている、ということは他の人の現場訪問レポートでわかっていたのですが、より情報が増えました。
例えば、水が扱われている作業室ではゴム手袋も足元も水でしたたっているので、とてもタブレットを持ち込みたい環境ではないこと、それにより記録はリアルタイムではなく、お昼や退勤時など「タブレットが保管されているところに立ち寄るとき」であることがわかりました。（とはいえ、その記録はリアルタイム性が求められないので上手に運用なさっていると感じました。）
他にも、機械音が大きいためヒト1人分離れると相手の声が聞こえないことなどを知り、「使い方がわからなくてもちょっと遠くの人にすみませーんと気軽に呼びかける」環境ではないこともわかりました。プロダクトの中で操作がわからない状況が0であることを目指す必要があるな、と自分の中の仮説も生まれました。
😊 もがき終わり！
元々「自分の中の仮説が生まれるところまでインプット祭りを頑張ってみよう」と区切りを決めていました。そのほうが大好きなアウトプットの準備が完了したぞ！の定義としてわかりやすかったからです！
2週間がっつりインプットしたおかげで無事仮説も生まれてきたので、この頃から先輩デザイナーやマネージャーに「少しUIデザインに入りたい」ことを伝えて、軽いデザインチケットにアサインしてもらいました！
軽いデザインチケットを担当し、チームメンバーにレビューしてもらい始める
完遂までにチームメンバーと「私はこうがいいと思うんですけどみなさんから見てどうですか？」「私はこう思いますよ〜」「こういう案もどうですか？」を議論し始められました。
2ヶ月目
チームにある小さな問題解決へのもがき
この頃には所属するデザイナーチームやサービスチームの人たちとの会話にも慣れてきて、チームの中に存在する問題に気がつくようになりました。
😶🌫️ 悩みポイント
ディスカバリー、デリバリー、それぞれの中でも複数タスク走っているので、あっちで決まったことをこっちの人が知らない、のようなことが起き始めていました。何がどこでどのように決まったか全てキャッチアップできていない違和感を感じ始めます。ただ、PJも開発が佳境に入っているタイミングだったので、仕方ないのかな..と思っていました。
ただ日々を過ごす中で、この小さな認識ズレが目標未達につながりかねないなと考え直し、まずは自分だけでもできる”ドキュメンテーション”を心がけはじめました。
チーム内で知っている人/知らない人がでないように、口頭で話したことをドキュメントに残す
この頃からチームが本格的な開発に入ったこともあり、朝会やちょっとした時間で決まったこと、ネクストアクションを切れずに時間切れになったこと等のドキュメンテーションが不足しはじめていました。
別予定で不在の人もいるため、口頭で話しただけではチームの中で情報格差が生まれてしまい、結果的にお客様に提供される情報やプロダクトもちぐはぐになるだろうなと考え、同期的に話したことはドキュメントを残して「認識合ってますか？」を確認し始めました。
私はまだPJの全体像を把握しきれているわけではなかったので、ドキュメンテーションしながら私自身PJ理解にもつながっていきました。
スプリントレビューが受入検査の場になっていたので、スプリントレビュー前に受入検査をする
スプリントレビューは受入検査が完了している前提で、ステークホルダーにデモを実施したりデモ環境を利用してもらい、サービスチームが新しい発見を持って変える場にしたいと思っています。このときは、スプリントレビュー自体が受入検査の場になっていたため、新しい発見というより仕様どおりか確認する場にもなっていました。かつ、スプリントレビューが15分開催だったので時間が足りず…。
せめて受入検査自体をちゃんとレビュー前に終わらせるようにデイリースクラムで声をかけたり実際に受入検査を実施するようになりました。
受入検査時には、どの項目は受け入れOKで、どの項目は受け入れNGかJiraチケットに残すようにしています。誰がみても受入検査が全項目正常に行われたことがわかるようにするためです。
今では当たり前にそのような文化になってます！
受入検査が無事完了したとき、頑張ってくれたエンジニアさんを慰労する&チームで喜べる雰囲気にするようにしています👏
「どういう役割をもった人が、どういうシーンで使う？」を機能のデザインに入る前に絵にしてPMと認識合わせする
この時期は担当しているプロダクト開発が多忙な時期だったため、必要十分な機能開発のみに絞りたいというサービスチーム全体の方針がありました。
そのため、この機能って本当に今作る意味があるのだろうか？過剰すぎないだろうか？という問いかけをするために、「どういう役割をもった人が、どういうシーンで使う？」をフロー状の絵にしました。
そうすると、「ん、この機能は必須なのか..?必須だとしたら私まだその理由を言えないな..」がわかってきましたので、一度PM(プロダクトマネージャー)の考えを教えてもらいました。
結果的に「作る意味あるね。必要十分だね。」とサービスチームで意思決定できました。
😊 もがき終わってわかったこと
私は、デザイナーはUIデザインをすることだけでなく、言葉だと難しいことを図解して伝えることが得意な職業だと思っています。そしてその力を持っていろいろな形でチームに貢献すべきとも思っています。
前職などでの経験から、難しいことを説明していても図解や絵が見て楽しいものになっていると、Slackに流れているだけで自然と関心が集まってくることがわかりました。（上記の件も、最初はPMに質問していたので反応はPMからのみを期待していたのですが、デザイナーさんやエンジニアさんからも関心が集まりました。）
関心が集まるということは、チームへの共有はもちろん、意見も集まってくるので多面的な判断もしやすくなります。「デザイナーは図解化でも貢献できる」ことに自信が持てた出来事でした。
【3ヶ月目】
人/チーム間の認識ズレを埋めるためのもがき
担当しているプロダクト開発も佳境が続きましたが、そろそろ顧客に利用しはじめてもらうことが視野に入ってきました！顧客に利用してもらう前の最後の仕上げが始まりました。
😶🌫️ 悩みポイント
デザインも2人で各チケットを進めているため、徐々に「協働の結果、認識がズレてることがわかった」ことが増えていきました。
3ヶ月目はおおよそ「認識のズレを埋めていく / ズレが起きないようにする」ための仕組みを作ることが多かったです。
UXライティングガイドラインを作る
削除した◯◯は復元できません。
◯◯を削除してもよろしいですか？
◯◯を削除してもよろしいでしょうか？
削除した◯◯は復元できないため、ご注意ください。
気がついたら、この「同じ意味だけど口調が違う」Dialogが散乱してました。
デザイナー2人いることはもちろん、毎週の機能追加により徐々に表記ゆれが発生しやすくなってきていたのです。
別のデザイナーさんが提案してくれて、システムメッセージ(Dialog,Snackbar etc)やButton等のUXライティングガイドラインを定義しました。
このとき機能開発のデザイン真っ只中だったため、重要度[高] x 緊急度[低] なUXライティングガイドラインの定義は、30min MTGを週3回やって完成しました。
お互いの認識のズレや理想の状態についてディスカッションできて、直近の機能開発で表記揺れが発生しない程度のUXライティングガイドラインを作ることができました。
この話は語りたいことがたくさんあるので、また別の記事でお話させてください！
自社の他サービスとの結合テストの提案と全体進行
私の担当サービスは、自社の別サービスと併用する必要があります。別サービスの開発と足並み揃えている必要があるため、それぞれが目標日までにあるべき姿になっていられるように交通整理をしました。
このとき「そもそも具体的な目標日がある / そんなこと知らなかった」というPMと自/他サービスチーム間での認識ズレが発生していました。
その目標日はどうしても動かせないものだとPMとの議論でわかったため、チームで乗り切る作戦を立て実行していきました。
このとき難しかったことは、自チームの話だけならまだしも、他チームにも目標日までに理想状態に到達するために認識を小さく繰り返し揃えていくことです。
残された時間が約3週間だったため、すぐに他チームに相談し、1週間に1回sprintごとに出来上がる予定の成果物をsyncし合う仕組みを作りました。
(マスキング広すぎてなんの情報もなくてすみません)
結果・・・・4月上旬に担当サービスのベータ版リリース！🎉
入社して3ヶ月、このサービスのリリースに力を注いでいたので嬉しいです！早速お客様にも利用し始めていただき、様々なフィードバックをいただくことができはじめて、いよいよ始まった！感を感じています。
（ですがこのとき、そもそも具体的な目標日をつくることの危険性を知ります。ビジネスコミットメントはしたいものの、かなりチームも疲弊したためです。現在はチームで改善策を検討&実施中です。）
😊 もがき終わってわかったこと
特に3月はUIデザイン半分、プロジェクトマネジメント半分で過ごしていたので、自分はデザイナーとしてチームに貢献できているのか不安になることが多々ありました。 ただ、チームメンバーから「交通整理ありがとう」感謝してもらったり、弊社バリューである「外向きベクトルで良いね」と言ってもらったことで不安は無くなりました。「デザイナーとして」というよりも「サービスチームの一員」として、誰がボールを持ってもよい役割を遂行したまでだな、と解釈し直したからです。
また、自分はデザイン活動 = 「環境づくり」と思っていることもあり、対象がプロダクトではなくチームに向けることができた、ただそれだけのことだなと腑に落ちたこともあります。
もがきおわりまして
以上が、入社して3ヶ月のデザイナーの動きです！
今回はきれいなところをピックアップしましたが、実際はきれいなことばかりというわけではありません！笑
ココに書いてないことでいうと、タイトなスケジュールでCSV import/exportの仕様とデザインを決めきる等、とてもスリリングなこともありました。が、それを乗り越えたおかげで自分は「プロダクトやチームの混沌をほどいて、流れを円滑にしていく」ことが好きだということがわかりました。今はサービスチームで、健康的に長く走っていけるやり方を模索しながら、デザイナーもスクラムチームの一員としてどのように貢献していけばもっと目標達成に近づけるのか楽しく考えている最中です。
笑顔ばかりの3ヶ月ではなかったですがｗ、いい”もがき”ができたおかげで、チームも強くなりましたし、自分が潜在的にもっていた興味関心やポリシーにも気づくことができ、楽しく仕事をしています。
もしご興味をもっていただけましたら！
カミナシはプロダクトデザイナーはもちろん、様々なポジションで募集中です。ぜひカジュアル面談からお話させてください！
この記事が気に入ったらサポートをしてみませんか？