RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

TAM#1: IDEOに学ぶ、チームワークにおける「Self Awareness」

今期より、RAKSULでは、Technical Advisory Meetingをと称した、主にエンジニア・デザイナー・プロダクトマネージャーなどのものづくりメンバー向けのプログラムを開始しました。前期までは一般的な形で技術顧問の方をお招きしてましたが、今期から固定的ではなく毎回違う著名なデザイナー、エンジニア、プロダクトマネージャーの方をアドバイザーとしてお招きし、毎回異なったテーマでレクチャーとQ&Aを用意して開催しています。

そして、記念すべき第一回のTechnical Advisory Meetingでは、IDEO TokyoにてDirectorを務めている田仲 薫様をお迎えし、チームに各メンバーのパフォーマンスを最大化するためのトピックとして「Self Awareness」についてレクチャーして戴きました。

「チームが機能するためには、チームワークを考える前に実は個人が自分を理解するところから始まる。どのようにしてIDEOでプロジェクトメンバーがチームを機能させているのか?」

田仲さんが教えてくれる「Self Awareness」のトピックをベースに少し私見も足して解説させていただきます。

youtu.be

多様なメンバーがチームを作る

これはIDEOに限らずRAKSULでも、あるいは他の会社でも同じだと思うが、今日ものづくりを一人のみで行う場面は非常に少ない。

IDEOでも課題領域に合わせて、インタラクションデザイナー、リサーチャー、コミュニケーションデザイナー、ビジネスデザイナーなど非常に幅の広い専門性や職能のメンバーを集めて、プロジェクト毎にチームを結成している。

あらゆる時間を共有するチーム

このように結成されたチームは、約12週間に及ぶプロジェクトのブレインストーミングやアイディエーションをする時間はもちろん、様々な場所に行ってなにかを学んだり、共に食事をしたり、あらゆる時間を共有する仲間となる。

ただ、当然そこには様々な価値観のメンバーが集まることになる。

ワークライフバランスや高いパフォーマンスの維持に必要な環境や条件にも個人差がある。

例えば週に何回かは子供を迎えにいかないと行けないメンバー、週に3回はジムにいかないと生産性が下がるメンバー、あるいは夜が一番生産性が高いメンバー、仕事中になにかゲームをしないと気分転換ができないメンバー等。

自分の周りにもそういうメンバーは居ないだろうか?あるいは自分自身「こういう条件が揃うとベストパフォーマンスが出せる」といったものがあるのではないか?

必要なのは「ルール」ではなく「アグリーメント」

IDEOでは、このような様々な個人差を確認するために、プロジェクト前のキックオフの一部に「Preflight」という時間を設けてそのような「アグリーメント」の確認作業を行っている。もちろんプロジェクトの成功がベースにあった上なので、どこまで通用するかは個別議論だが、どのような条件や環境が整うと自分のベストパフォーマンスが出せるかを共有する機会がある。

一見それは「ワガママ」のように聞こえるかもしれないが、反対に自分の「求めること」をお願いするほうが、相手もお願いしやすくなる、という状況を作り出していることも重要なポイントだ。

また、チームワークに課題になりがちなのが「一人の時間」 vs 「みんなの時間」だ

  • 一日数時間一人で作業をする時間が必要
  • 夜みんなが居なくなって静かになった時に一番生産性が高い人
  • 数ヶ月に一回1週間休んで充電の時間を取らないとパフォーマンスが低くなる人

田仲氏は「自分の時間に何をやっているか」というのを周りにしっかりと申告することが大事だと言う。「戻ってきたときに何をチームに持って帰るのか?」というのを決めておくことが重要だ。

「Be Managed」から「Be Self Aware」へ

重要なのは、自分はどのような環境や条件が整うと「スーパーヒーロー」になれるのかを理解すること。一般的には組織において個人は「管理される」ということが多いが、重要なのは「自分自身を把握・認識」することが重要だと言う。正しい自己認識・把握を通じて初めて「管理」という状態ではなく、自由と責任の元「自律」ができるようになる。

正しい自己認識・把握を通じてはじめて、他者も同様に知り得ることに繋がる。そしてそこからチームメンバーとより強い関係性を作り、互いをエンパワーすることで成功するチームが生まれることに繋がる。

所感

ラクスルでも、IDEO同様、デジタルサービスの開発においてはエンジニアリング、デザイン、プロダクトマネジメントなどの要素が不可欠で、エンジニアリング一つ取ってもスマホアプリ開発からインフラ設計まで様々なレイヤーが存在し、多種多様なメンバーがチーミングされることでものづくりが進む。

ラクスルでのプロダクトメイキングの現場に置いてはチームには最大限の裁量をもたせ、課題に対して「どのようなプロダクトを作って解決するのか?」「どのような顧客体験を実現していくか?」はそれぞれのチームが決めることなので、非常に自律したチームがあると言える。

一方で、チームでの意思決定は割と民主的な「合議」によるやりかた多いと感じており、特に日本文化に置いてあまり「自分は~」と主語にして利己的な意見を言うのは「タブー」とされているようにも感じる。

「チームのパフォーマンスを最大化」といったテーマで考える時は、誰もが「自分なんかよりもみんなが~」と利他的に考えてしまう。それは一つの美徳だが、自分を最もよく知る自身がその言語化に悩んでいたのでは、当然他者からも理解されず、本質的な利他主義にはなり得ない。

「チームのパフォーマンスを考えるなら、まずは自分のワガママを理解する」

その一見矛盾した考え方が、今回一番驚かされた学びだ。