こんにちは！株式会社MIMIGURI クリエイティブドメイン所属の横井です！
事業領域でUIデザイン・PdM役割を担っており、開発メンバーをはじめとした各ステークホルダーとコミュニケーションを取りながら自社の新規プロダクトを作っています。

この記事について

この記事はMIMIGURI（裏） Advent Calendar 2022の19日目の記事です。
ここが（裏）ということは（表）もありまして、毎日盛り上がっておりますので是非覗きにきてくださいませ！

MIMIGURI（裏） Advent Calendar 2022
MIMIGURI Advent Calendar 2022

ちなみにこれ、何が（裏）なのかというと、単純にMIMIGURI社内で書きたい人がたくさん集まって表に入りきらなかったので「せっかくだから裏も作っておくのでみんないっぱい書こうぜ！」的なノリ（と解釈）でできたAdvent Calendarです。
今回は裏話的な記事というわけではないので期待させていたら恐縮ですが…！MIMIGURI入社後の葛藤だらけな自分をそのまま正直にさらけ出そうと思うので、楽しんでいただけたら（？）幸いです。
（そういう意味ではこの記事は「裏」かもしれない。「裏」とは…？）

Advent Calendarのテーマは6つ

このAdvent Calendarには6つのテーマが設けられており、日替わりで記事が公開されております。
MIMIGURIに入社してからは、この6つのキーワードに対して意識的に向き合う機会がとても多いです。

2022年5月 MIMIGURIへ入社

私は今年の5月9日にMIMIGURIへ入社しました。
まだ8ヶ月しかたってなかったんですね！？というような、入社してからの時間は非常に濃いものでした。

ところで、葛藤葛藤いってるので「MIMIGURIやっぱ難しいんだ」的なイメージ持たれてしまうかもしれないので触れておくのですが、自分の場合は自身がストレッチした取り組みを行なっていることから起こる葛藤です。MIMIGURIでは自分の葛藤を開くことで、対話が始まったり、また柔らかく受け止めてくれたりと、とても寛容性の高い組織だと感じます。

とはいえ組織文化的に抽象度の高い話題があちこちで展開されており、MIMIGURIが解決しようとする経営や事業・組織にまつわる課題の難しさに加え、学術的な側面もやはり強いので、オンボードの難しさは実際あると感じます。
ただ、そこに向かう難しさはメンバーみんながそれぞれ感じていることであって、そういった眼差しがあるからこそコミュニケーションの柔らかさが出るのかなとも思います。

個人的にのMIMIGURI Advent Calendar 9日目の「わからない、に向き合う。」というTajimaさんの記事はとっても素敵だなーと思いながら読んでいました。
組織文化についてはMIMIGURI（裏） Advent Calendar 19日目の「MIMIGURIの日常をちら見せ！社内Slackの絵文字ランキング」というKuribayashiさんの記事からも、少し片鱗を感じていただけるかなと思います（絵文字並べると可愛いw）

入社のきっかけ

ごめんなさい、本題に入る前にいきなり脱線してるなという気はしつつ、MIMIGURIでの葛藤を書く前にもう少し「自分にとってのMIMIGURI」について掘り下げさせてください…！（よかったら飛ばしてください！w）

MIMIGURIの入社の決め手だったのは、面談で話した方全員から感じる「柔らかさ」「対話力の高さ」でした。もちろん組織が掲げるCCMの実践をはじめとした非常に骨太で共感性の高い取り組みや思想も魅力の一つでしたが、自分はヒトを軸に考えることが多いので、特にコミュニケーションの心地よさには惹かれました。

面談でも「対話」を大切にしている、ということについてはこちらの安斎さんの記事からも感じられるのですが、ぶっちゃけ面談は楽しくおしゃべり（めっちゃ緊張はしたんですが）した記憶しかなくて「面接」された覚えがないレベルなんですよね（私の認知に何かバイアスかかってるだけかもしれないですがw）

入社後のオンボード

MIMIGURIの特徴としてもう一つ感じたのが、オンボードの丁寧さです。
最初の1ヶ月は各チームとお茶会が実施されるのですが、そこでは全メンバーとお茶会で雑談することができます！
MIMIGURIに対しては「みんな優秀すぎて怖い」「学歴たっか…（偏見ごめんなさい🙏）」だったので、社内で知り合いがいるわけでもなく、かなり萎縮しつつの入社でした。ですが相手の顔を見てコミュニケーションできる機会を贅沢にもらえたことで、少しずつ強張った姿勢を緩めていくことができました。

また私のメインサポーターであったたけうちさんによるオンボードも、組織文化のことを丁寧に伝えてくれ、不安や懸念を即座に解決するために尽力してくれました。
オンボードの一方、入社後すぐに「自分がなにを目指しているのか、ゴールはどこなのか、なぜそう思うのか」などについて深ぼる機会をもらいました。改めて自分自身に向き合いつつMIMIGURIでどう振る舞い、行動していくか、ということについて考え、さらにそれについて対話させてもらい、自分自身の解像度やわからなさが少し明確になった気がします。

この一連の流れがとてもMIMIGURIらしいな、と感じたのでした。

ところでそろそろ前置き長くなりすぎてこれテーマ違うやんけと離脱する人が出てきてる気がしていてごめんなさいという感じなので、そろそろ本題に入ります！！

0→1の新規プロダクト開発にJoin

ここでは詳しく書けないのですが、現在MIMIGURIでは新規事業の立ち上げを行なっており、新しい自社プロダクトを開発中です。

入社後は理念浸透のワークショップ設計をデザインするコンサル業務を経験させていただき、ファシリテート文化を垣間見つつ2ヶ月目から徐々にこのプロダクト開発チームへ入り込んでいきました。

0→1フェーズの途中参加はハードルが高かった

当初役割としては、すでにプロジェクト内でゴリゴリデザインをし、プロダクトを具体化してくれているデザイナーがいたので、そのサポート的な立ち回りでスタートしました。

プロダクトが解決しようとしている課題の不確実性の高さ・難しさと、関わっている層のレベルの高さからハイコンテクストなコミュニケーションが成立しており、キャッチアップが非常に難しかった記憶があります。

なんとか追いつきたい思いから、既存メンバーのデザイナーと日次MTGをセットしてもらい、これまでの経緯やデザイナー自身のプロダクトへの想いや思想などを掘り下げつつ、具体UIや仕様の相談をして意思決定基準を合わせにいきました。

自分の立ち回り方

元々、この領域のプロダクト開発にはものすごく興味がありUIデザイナーとして関わりたい！と強く思っていたのですが、自分自身どういう立ち回りで動いたら良いのか悩みながらの関わりでした。

新規フェーズ、しかも検証段階のようなフェーズではUIよりもドメイン理解や課題解像度上げ、また初期フェーズでの検証ポイントの確定とそれに適した要件決めや仕様の落とし込みといった工程の方が圧倒的に重要です。
（ぶっちゃけ概念モデルやデータ構造が課題解決に即した形で成立していればUIはあとからどうとでもなる…と今になっては思います）

ですが元々自分はtoCのサービスUIをやっていたこともあり、ソフトウェアの設計知見はほぼなく上記の解決に対してほとんど力になれていなかったなと感じます…。
MIMIGURIの開発マネージャーがめちゃくちゃ対話的な方で、そのあたり沢山助けられながら上記に対しての相談を重ね、日々少しずつ進めていました。

UIは入った時点ですでにほぼ完成形の状態でしたが、インタラクションから考えられていたため開発とのコミュニケーションの中で出てくる仕様の疑問や矛盾について、考えれば考えるほど「わからない」ことが増えていきました。

UIデザインサポート→正式にPM役割へ

そんななかで、自分がこのプロダクトのPdM役割（兼UIデザイナー）をいただきました（いまだにできてるとは思えずぐぬぬな状態ですが。またその話はいずれ）。

めちゃくちゃありがたいと思った反面、「いや自分ドメイン理解何もできてないんですけど！？」みたいな状況で、まぁでもキャッチアップ続けてれば「なんとかなるかな…」くらいの気持ちでいました。

なんとかならんかった。

なんとかならんかった。

難易度高い、課題解像度が低過ぎる、よくわからない。何がどうわからないかもよくわからない。上流の会話に入れない。
でも目の前の、開発を進めるための仕様策定やUIデザインの調整業務も多々あり、そこを言い訳になかなか動くことができませんでした。

そもそも、このPdMという役割はどこまでを責務としているのか、何を期待されているのかがよくわからなかった。（後ほど詳しく書きます）
これが一番行動のネックになっていながらも一番聞くのが難しかったです。

わからなさに対する焦りと無力感を乗り越えて

この時期はプロダクトに入って1ヶ月・入社して3ヶ月頃でした。自分の理解のなさ、役に立てない感覚が押し寄せてきて結構凹んでいました。

前職ではtoCプロダクト、デザインマネジメント、PjM領域で一定成功していたりなんとかなっていたのですが、フェーズや領域の違いからほとんど通用しませんでした。

対話的な組織とわかっていても、「できない人間」と思われることに対する怖さ

前段でMIMIGURIの組織の良さには対話的であることや、寛容性の高さがあると書きました。
それがわかっていても、「自分より上の立場にいる人からの評価が下がってしまうかも」「わかっていない自分を曝け出す恥ずかしさや悔しさ」といった恐怖心は拭えていませんでした。

これはなんなんでしょうね。
そもそも自分が「できる人間」とは思っていませんが、それでも入社してから「早く活躍したい」「成果を出したい」「役に立ちたい」という気持ちは少なからずあり、それに相反する状況は受け入れ難かったのかもしれません。うーん！

変化のきっかけ

よくMIMIGURIでは「葛藤を開く」という言い方をされます。
MIMIGURIには「知を開いて、巡らせ、結び合わせる。」というバリューがありますが、「開く」という行為をとても大事にしていると感じます。（もちろん「巡らせ」「結び合わせる」ことに対する試行錯誤も日々各所で行われています）

ちょうどこの記事の（表）の公開をされているCCO（Chief Cultivating Officer）と1on1する機会があったのですが、そこで「自分いまめっちゃ悩んでるんですよ！（要約）」という話から「自分の前提を開く大切さ」について話をしました。

CCO自身もMIMIGURIに入社してから沢山悩み、葛藤していること。葛藤をぶつけ、自分の前提（なぜそう思うのか、そうするのか）に向き合い、しっかり言語化して相手に開くことで、自分がやるべきことの精度をあげていくのだ、というような話をしました。

そのCCOとの対話をきっかけに、あぁ、悩んだり葛藤するのは当然のことなんだよな、むしろそれを自分の中に閉じ込めたまま動かない方がダサいよな、と腹落ちしました。あの1on1には感謝しかないです。

PdM役割に対する葛藤を開く

まず自分の「わからなさ」を整理し、それに対して自分が今どう考えているか、という前提を考えました。

PdM役割については少し具体的に書いてみようと思います。

===============
■PdM役割に対して自分の認識
・現場意思決定→要求定義と仕様策定、その整理
・リリース責任、品質管理、マニュアル作成、ユーザーインタビュー
・コンサル（ビジネス）連携
・現場からのボトムアップをまとめ、必要に応じ各所と連携
・バックログ管理、ボール拾い
===============
↓↓↓↓↓↓↓↓↓↓
自分の中でPMという役割はもっと幅広く、上流で、長期視点をもつ必要がある認識でした。これで事足りるのか（でもその責務は今の自分では果たせない）、これではPjMに近い立ち位置なのでは…と考えており、自分のアクションに自信がありませんでした。
結果、上記方針で相違はなく「この状態にするためにボトルネックになってることを処理しまくる人（チームのアジリティを強める人）」という回答と、プロダクトの性質として不確実性への対処や処理、仕様一歩手前の前提言語化の重要性が高いといった話をもらいました。

このことで自分のやるべきことが明確になり、確信を持って動けるようになりました。
そもそも、PjMやPdM、POといった役割は組織やチームのあり方、さらには人によって多少のブレがあったり、領域が交わっていたりするものなので最初から役割定義の認識を揃えておけばよかったんだよな、とふと気づきました。遅い！

そもそもの「言葉」の前提を揃える重要性は開発やビジネスとのコミュニケーションでも強く感じることがこのプロダクトでは多々あり、そのうち書きたいなと思ったりしてます。

プロダクトに対する葛藤を開く

もうひとつ、課題解像度低過ぎる問題に対しては、わからないなりに未来図を作ってしまえ！それをぶつけてみよう！と半ばヤケクソみたいな気持ちで整理しました。

結果的には方向性は違和感ないものの、このままでは使えないというフィードバックでした。そこでふと気づいたのですが、割とそれまでは既存メンバーの方から情報を受け取り、準拠し、整理する姿勢で取り組んでいたことを自覚しました。その役割も必要だし重要だと思うのですが、それだけじゃ不足していたのかもな、とそのときに感じました。

事業の立ち上げフェーズからプロダクトに向き合ってる人たちに対して、解像度が高いという安心感…依存ともいえるかも、そういった人たちに答えを出してもらうことを期待していたともいえるかもしれません。
途中で入ることの難しさでもあるのかも。

プロダクトとどう向き合い、行動するか

プロダクトに対する「わからなさ」や「居心地の悪さ」みたいなものに対して敏感になること。それを言語化して違う景色をもつメンバー同士で共有しあい、チームで形を探りながら具体化してアウトプットに繋げて行くこと。考え続けること。

これは特に0→1フェーズやソフトウェアのような複雑な開発実現に関わる上では特に大事なスタンスだと感じます。

ドメイン理解をいきなり完璧にこなすのは不可能という前提で、詳しい人と協力し、コミュニケーションの土台を作ってヒアリングしながら構造化してUIと開発に落とし込んでいく、というのが今の自分の具体取り組み方です。

その観点ではUIデザイナー文脈での気づきも大きく、インタラクション手前でそういったコミュニケーションをするための概念モデル図（UML）やオブジェクト抽出といった手法の重要性に改めて気づきました。
このあたりは本格的にこれからインプットしていきたいと思っています（来年の目標）

葛藤ってなんだろう

「葛藤がある」ということは「自分が変容する種がある」ことなんだな、と今回このnoteを書きながらなんとなく感じました。

葛藤を自分の中で守るんじゃなく、葛藤と素直に向き合い、丁寧に言語化して開き、他者と対話することで自己理解に繋がり変容が進んでいくものなのかもしれません。それはオンボード時にも感じていたことでした。

「言語化」の重要性

最後になりますが、

冒頭でも「MIMIGURIに入社してからは、この6つのキーワードに対して意識的に向き合う機会がとても多い」と書きましたが、意識的になった要因として、それらをテーマに月1回、5時間！の全体会で対話したり、個人の解釈を聞いたり、もはや当たり前のように日常会話に出てきたり…と、MIMIGURI内の文化の一つとして根付いているからだと感じます。

前職もデザインマネージャーでありUIデザイナーでありPMでもあったので、意識せずともやってきたことは今思い返すと色々ありました。

でも、そういった行動や思考、概念について「定義」「言語化」されることで形となり、自分の行動をメタ認知することができたり、共感ができたり、さらにそういった行動に対する再現性を持たせることもできる可能性があるんだよなぁ、と感じます。

組織のミッションバリューや行動指針はそういったところからきてるのかもな、と思ってみたり。プロダクトビジョンもそうかもしれない。

今回も自分自身が「前提言語化」というキーワードを認知し、重要性を認識したことで、明確にコミュニケーションの仕方が変わった感覚があります。そして、それは自分がUIデザイナーであってもPMであっても、必ず発生する「チームでのコミュニケーション」において、どんな立ち位置でも変わらない重要なことだなと感じます。

おわり

いつのまにか想定以上のボリュームになっていましたが（笑）、こうやって時間をかけて自分自身の入社後を振り返る機会ができたのでとてもありがたかったです！

ここまでお付き合いいただいた方、ありがとうございました🙇‍♂️

明日の（裏）は社内のEXを力強く推進する、みんな大好きおがわんさん！（いつもありがとうございます！！）
「オフライン空間魔術師！」ということでどんな記事がでてくるのか楽しみです👀