Values

LAYEREDではValues（価値基準）として下記4つを定めています。
それぞれはハイコンテクストなため、それぞれを制定した目的や内容を下記に記載します。

矛盾を歓迎する

私たちは医療者と生活者の間に立ったサービスを提供しています。それぞれの立場のみに立った改善活動や最適化は行なわれてきましたが、医療という国の制度としての持続性と国民に対するサービス向上の両方を成り立たせて全体最適をはかるためには、相矛盾するような事象に対峙して一つひとつ解決していく必要があります。

ひとの成功を喜ぶ

レイヤードは医療DXを通じて支援する医療機関・製薬会社・自治体の成功、およびその先にいる患者や生活者が良い医療体験を得られることを目指して仕事をしています。カスタマーサクセスは一部門の仕事ではなく、全社で目指すべき事項です。

同時に、レイヤードで働くメンバーにとっても上記の仕事を通じて自分たちが社会に貢献できていると感じられ、また物質的・内面的にも生活が豊かになることは、カスタマーサクセスのために重要な要素です。

自分のことと同じぐらい人の成功を望み、伴走してあげて、成功したときに一緒に喜んであげられること。そしてそのためには自分自身も心身ともに豊かであること。

よく研究し、よく実装する

私たちは世界をより良い世界にするために仕事をしています。優しい課題であればきっと誰かが解決してくれています。矛盾をはらむより難しい課題にこそ挑戦する価値があります。そのためには、失敗を恐れずにチャレンジすること。そしてPDCAを早く回すことでより多くのチャレンジができます。

そして、成果とは「顧客（社会）の成功への貢献」です。どんなことでも、顧客価値に寄与しない仕事は成果とはみなされません。いくら素晴らしいことを考えていても、最終的に社会実装されないと成果は出ません。そのために効率的に仕事を行い、それぞれは小さくても良いからなるべく多くの成果を出し、組織全体で学習サイクルを回して前進することを目指すべきです。

泥にまみれる

社会の多くの仕事は目立たない、地味な仕事です。しかしそういった誰も注目しない仕事によって社会は成り立っています。レイヤードは誰かの成功のために自らが泥をかぶったり、目立たない仕事を積極的に引き受けられるような精神性を大事にしています。

一方で、自分が脚光を浴びたとき、自分の仕事がうまくいったとき、そこには必ず誰かの陰ながらの貢献があります。そういう表舞台に立たなかった人たちにも感謝の気持ちを持ちましょう。エースも、ヒーローも、主役も、彼らを支える多くのチームメンバーがいて、チームが勝つための単なる役割に過ぎないのです。「One for all, All for one」

行動規範

ここからは、レイヤードとして大事にすべきルールを記載しています。それぞれのルールはValuesに紐づいているものもあれば、そうでないものもありますが、組織として仕事を円滑に進め成果を出していくための基本原則と言えるものを明文化しました。
レイヤードに属するメンバー（社員・スタッフ問わず）は、Valuesだけでなくそれぞれのルールを理解し、日々の行動として徹底することが求められます。

コラボレーション

オープンなコミュニケーション

レイヤードではオープンコミュニケーションを推奨しています。オープンコミュニケーションとは、情報のやりとりが個と個に限定されず、立場や部署、年齢、性別などに関わらず自分の意見をオープンな場できちんといえる環境およびその状態のことです。どんな人でもアイディアや意見を自由に言える環境があることで、議論が深まりより正しいと思える選択を組織として行うことができるようになります。

また、オープンな場でのコミュニケーションであれば、明らかにおかしな議論や、人への人格的な攻撃、一方的な視点による噂話などは最小化されます。組織として立場に関わらず良好な関係性を維持するためにも、オープンコミュニケーションは非常に重要です。

議論を歓迎する

人によって考え方は様々です。立場だけでなく性別、育ってきた環境、持っている情報などによっても考え方は影響を受けます。相手のことを理解するためにも議論が大切です。意見が異なれば衝突することもありますが、そうやって異なる意見をぶつけて議論することで、違う角度からの見え方や、自分が気づいていなかった視点に気づいたりするきっかけになります。議論を恐れず、積極的に、オープンな場でどんどん議論をしていきましょう。

議論を上手に進めるためには、意見が対立した際にお互いなぜそのように考えるのか、理由や背景情報も含め説明する義務があります。また、自分と違う意見が出されると攻撃された・非難されたと感じることもありますが、そうではありません。議論と人格は別次元です。

非同期コミュニケーションを優先する

まず同期コミュニケーションと非同期コミュニケーションを理解しましょう。

同期コミュニケーション	対面の会話、電話、会議（WEB、対面限らず）等。リアルタイムで行われるコミュニケーション
非同期コミュニケーション	個々人が都合の良いタイミングで情報を共有したり議論をおこなうような方法。Slack、Mail、Github、ポータルでの情報共有 等

レイヤードでは複数の拠点にわかれて様々な職種の人が多様な働き方をしています。また出社している人もいれば在宅勤務の人もいます。そのため同期コミュニケーションは、一部の人に限定されたクローズドコミュニケーションとなりやすい側面があります。また、同期コミュニケーションは相手の時間を強制的に奪うことになります。

仕事に関する情報共有・依頼・議論はなるべく非同期コミュニケーションを優先させましょう。非同期を優先させることで、多くの人が対等に情報に触れることができるとともに、より深い・質の高い議論やソリューションを生み出すことも可能となります。（自分のペースで時間をかけて情報を咀嚼し、考えることができるため）

一方で、非同期コミュニケーションで何往復もすることは逆に非効率な場合があります。アイディアを持ち寄って議論を行うような場合や、即時性を強く求めるような場合にはリアルタイムの同期コミュニケーションが有効です。適切に最小限な範囲で同期コミュニケーションを選択しましょう。ただし、必ず同期コミュニケーションを行う前に、それは非同期コミュニケーションでは難しいのかを反芻するようにしましょう。

情報をシェアする

自分が得た情報は意図的にシェアしていきましょう。レイヤードでは日報はなく、その代わりデモ報告などをオープンなチャンネルで共有する仕組みとしています。上司だけが情報を持つような非対称性を避けるためです。発信する情報が間違えているかもと恐れないでください。意見が分かれるようなテーマでも積極的に共有していきましょう。オープンな場（Slack等のオープンチャンネルなど）で情報が公開されることで様々な視点からの発見や学習の機会につながります。

横からすみません

自分宛てでないSlackコミュニケーションでも、自分が別の意見がある場合や賛同する場合には積極的に議論に横入りしていきましょう。新しいアイディアや気づきは得ていてそのような当人同士以外の視点から生まれます。自分は関係ないからと思わず積極的にいろんな議論に絡んでいきましょう。賛同の意を示す 👍 や 😄 のようなスタンプだけでも構いません。

感謝を示す

褒められたり感謝されて嫌な気持ちになる人はいません。Slackや会議など、同僚・部下・上司に対して、たくさんの人が目にする場所でたくさん感謝の意を示しましょう。ただお礼を伝えるだけでなく、具体的にどんなことが嬉しかったのかが受け取る側やみんなに伝わるように、状況や具体例を織り交ぜるようにしましょう。Pay it Forward!

部門やチームを超える

レイヤードでは、様々な部門やチームが積極的にコラボレーションすることで、顧客価値を生み出しています。質問や情報提供、チャンネルへの参加など、部門やチームの垣根を超えて積極的に行いましょう。部門やチームを超えた貢献ができる人こそレイヤードで評価されるべき人です。

インフォーマルコミュニケーションを
積極的に活用する

インフォーマルコミュニケーションとは、業務とは関係ない非公式なコミュニケーションです。オフィスでの雑談や、coffee_breakでの会話、メンターとの1on1やランチ会、チームでのランチ会、趣味の合う人との課外活動、歓送迎会、全社会議後の懇親会、などはすべてインフォーマルコミュニケーションです。業務に関係ないコミュニケーションが必要ではないと考える人もいますが、普段顔を合わせることが少ないからこそ、レイヤードではインフォーマルコミュニケーションも非常に重要と考えています。

お互いのことを知ることで信頼関係が生まれたりチームワークや異なる部署間での連携があがるなど、インフォーマルコミュニケーションを適切に設計することで生産性に寄与することも様々な研究で明らかになっており、また新しいメンバーが早期に組織に馴染めたり、組織への帰属意識を高める、他人との会話によるメンタルヘルスケアにも寄与します。

経営層、マネージャーやチームリーダー、在籍歴の長い人ほど、組織に新たに加入したメンバーとのインフォーマルコミュニケーションを意図的に設計していきましょう。いつものメンバーで固定化され新しい人が入りづらい雰囲気を避けるよう注意しましょう。

悪い報告こそ早く報告する

仕事のミスや顧客からのクレームなど、なにか問題が起きたときには影響範囲や原因を探る前に、まずはいち早く上司や同僚にすぐ報告しましょう。まずはわかっている事実と、現状わかっていないことをそのまま報告しましょう。すべてが分かっている必要はありません。なにか問題がおきたときこそ、個人で対応するのではなく上司も含めたチームで対応すべき事象です。

成果を出す

顧客価値にこだわる

私たちはプロダクトを作り、顧客に届け、サービスを提供し、顧客や社会がうまくいくこと（成功する）を価値として提供しています。サービスの安定性を上げること、組織としての脆弱性を塞ぐこと、効率よく仕事を行える環境を整えることも全て顧客価値に繋がります。反対にいうと、顧客価値に貢献していない活動は成果を生んでいないと言えます。知識を得ただけでは顧客価値につながりません。アウトプットがサービスに活かされて初めて顧客価値となります。成果が良かったかを判断するのは、ユーザーであり、チームであり、投資家です。顧客・ユーザー・チーム・投資家に対して成果をコミットし、責任を果たし続けることで、サービスが支持され、組織が存続していくことに繋がります。自分の一つ一つの仕事が、本当に顧客価値に繋がっているのか、日々確かめながら進めましょう。

プロフェッショナルであると認識する

組織として顧客に価値を提供するためには、各々の領域でプロフェッショナルである必要があります。プロフェッショナルとは自らの領域に対する専門的知識や技術を持ち、期待以上のアウトプットにより顧客に貢献することだと考えます。そのために日々新たな知識や技術の習得を行うこと、期待される以上のアウトプットを出すことへの意識を持つこと、高い職業倫理感を持つことが大切です。たとえ新人であっても顧客にとってはプロフェッショナルとしての働きを期待されていると認識しておきましょう。

リーダーシップを持つ

レイヤードでは、リーダーシップはトップに立つ人だけが持てば良いものではなく、全員がリーダーシップを発揮できる組織が強いと考えています。リーダーシップとは、目標を掲げ、自らが先頭を走り、物事を主体的に決定し、情報を発信し、多くの人を巻き込んでいくことです。自分の仕事にリーダーシップを持ちましょう。そして、リーダーシップを持って物事を動かそうとする人がいたら、支援してあげましょう。そうやって、決まった人だけでなく、色んな人が交互にリーダーシップを発揮できる組織が最も強いと信じています。

小さなリリースを最速で行う

機能は開発しただけでは顧客価値には繋がらず、リリースされ、顧客に適切に周知され、顧客が使うことで初めて成果（顧客価値）となります。大きな計画を綿密に立案するのではなく、できる限り小さな単位でリリースし、その後に得られたフィードバックによってその後のアクションを決めましょう。リリースは、ユーザーに価値を提供するために可能な限り小さな変更を目指します。小さくステップを刻んで、よりシンプルな機能をリリースすれば、より早くフィードバックが得られます。これにより間違えた機能開発に時間を費やしたり、間違えた方向に進んでいても迅速に軌道修正できます。最初から拡大したときのリスクを考えすぎたり、どうやって拡大するのかを心配するのはやめましょう。リリースとは機能開発に限らず営業資料やセミナー、ユーザー向けFAQ、規約や契約書、ブログに至るまですべてのアウトプットを指します。

リリースの顧客価値を評価する

最も重要なプロセスはリリースの評価です。リリースを評価するために、あらかじめそのリリースがどんな顧客価値を提供するのかを明らかにしておきましょう。現状から改善する部分や、何を達成すべきかの要点を整理します。大切なのは美しい計画やビジョンではなく、ユーザーへどんな価値を提供しているのか、です。また、事前にリリース後に何を検証したいのか、どのようにフィードバックを集めるのか、リリースが顧客価値を提供できるためにユーザーに届ける方法など、調査方法・評価方法などを予め決めておきます。できるだけ早く・多くのフィードバックが集められるようにしましょう。

要望の背景を知る

顧客の要望には必ず背景があります。何を実現したいのか、なぜそれが必要なのか、手段ではなく目的を探るようにしましょう。その要望は別のもっと簡単な方法で実現できるかもしれません。人に伝える場合も、手段ではなく、背景や目的から説明して、手段を議論しましょう。それが無駄な作業を減らすことに繋がります。

まとめてしまいたい欲求に抵抗する

一連の小さな改善や課題をより大きなプロジェクトや施策にまとめてしまいたい衝動に抵抗してください。小さな課題への網羅的なプロジェクトは魅力的に見えますが、コストが肥大化しいつまでもリリースできない事態に陥りがちです。小さな課題を一つずつ解決していくことを目指しましょう。

変化を歓迎する

社会や競争環境は変化し、ユーザーの要望も人の感性も変化します。変化の激しい環境の中で成功している企業は社会の変化に対して組織や計画・実行機能を整合させ続けています。一方で変化は人にストレスを与え混乱を生む原因となります。そうしたマイナス面に直面すると変化に抵抗したくなりますが、生き残るため、そして個人としても組織としても学習のポジティブな機会であると捉え、変化にチャレンジしていきましょう。

また、経営陣やマネージャー陣は組織に変化を与えていくことが責務です。環境変化を注意深くウォッチし、変化を恐れず、メンバーに変化する意味を丁寧に説明する責任があります。”唯一、生き残るのは変化できる者である（チャールズ・ダーウィン）”

一定のミスを許容する

あらゆるトラブルに対して、必ずしも新しいプロセス（再発防止策）を用意すべきではありません。何か新しいプロセスを追加すると、業務が一段階非効率になります。一方で発生したミスはそのときしか影響しません。そのミスが致命的ではなく頻度も限定的であるならば、イレギュラーな間違いは発生することがあると受け入れて、そこから学びを得ましょう。

みんなプレイヤー

レイヤードでは社長も本部長も全員がプレイヤーであり続けたいと願っています。立場に関わらず手を動かしましょう。指示だけを出す人間はいりません。マネジメントはチーム全体の成果によって評価をされるべきですが、チームが窮地に陥ったときに戦局をひっくり返せるプレイヤーとしての腕力も重要だと考えます。

意思決定

DRI（直接責任者：
Directive Responsible Individual）を
設定する

Apple社で生み出された制度で、すべてのプロジェクトや施策単位で責任を負うべき一人の人物を定めます。それぞれの施策やKPIごとに誰がその数値や成功・失敗に責任を負うべきなのか定めましょう。DRIはプロジェクトの大小に関わらず、プロジェクトの推進や必要なリソースの確保に責任を持ちます。DRIはそのプロジェクトに関わる決定を司ります。DRIは最終的な責任を負いますが、必ずしもプロジェクトのすべての作業を一人で行うわけではありません。DRIは関係するすべてのチームや利害関係者と協議し、協力して、関連するすべての状況を把握し、他の人から意見やフィードバックを集め、関係者間でアクションアイテムやタスクを分担する必要があります。

意思決定にはコミットする

意思決定のためには様々な視点の意見が必要です。DRIは意思決定に必要な様々な情報を収集し最も適切な意思決定を行う必要があります。DRIが意思決定されたことが自分の意見と異なる場合があるかもしれません。しかし、その場合でも最終的にDRIが意思決定したことにはコミットする必要があります。決定されたことにあとからグジグジ文句言わない。

ただし異論を述べて良い

すべての決定は変えることができます。DRIが意思決定をしたあとも異論を述べることはできます。決定が覆るまでは、異論を述べることはできても、決定が変わるまでは決定事項に従う必要があります。

過去の議論を再開したいときは、以前の議論をふまえて論点を提示してください。過去の決定が最善の意図でなされたと尊重してください。

障害を取り除くため上司を利用する

DRIは、自身のプロジェクトや施策・KPI遂行のために障害となるものを排除するために上司や役員に働きかける権限と責任が与えられます。マネージャーはチームメンバーのアウトプットを増やすことが役割です。DRIは発生している問題を早期にマネージャーに共有し、マネージャーは問題解決の支援を提供します。成果を出すためにマネージャーや役員を動かすことはDRIの重要な役割です。

不確実性を受け入れる

やる前からすべてのことを知ることはできないと認識してください。事前に分析や推測を繰り返すのではなく、前に進みながら不確実なことをひとつずつ確実にしていきます。解決策が間違っていてもあとから修正することはできますが、何もしていないのに軌道修正することはできません。

たたき台や提案を用意する

何かを決定する必要があるときに会議を開いて全員の意見を集めるのではなく、具体的なたたき台や提案を用意しましょう。すべての会議は提案のレビューであるべきです。また会議でレビューをもらうときも他の参加者が効果的な改善策を提案できるよう、解決したい本質的な課題の詳細、現状とのGAP、前提条件などを丁寧に説明するようにしましょう。

良いたたき台や提案が見つからなかった場合でも、思い付いたアイディアを列挙しましょう。レビューをする側も単に反対するのではなく、より良い改善策や、思い付いたことの列挙でも構わないので代案を提示するようにしましょう。

後戻りができるならすぐ決断を行う

決断して進んだとしても、大きなリスクなく後戻りができるような場合は承認を得ずにすぐに意思決定をしましょう。どうしても覆せないリスクや大きな意思決定の場合のみ、より綿密な議論を行うようにします。

完璧を求めない

80点の達成と、90点から100点を目指すには大きなコストの隔たりがあります。完璧を目指さずにある程度のリスクやあいまいさ、未完成を許容し、意思決定のスピードと早いリリースを意識しましょう。同様に、レビューのたびに修正事項が発生し、一向にリリースできないようなシーンがありますが、「どこまでできたらリリースするか」の認識を共有し、ある程度のあいまいさは許容しましょう。

倫理観を意識する

すべての意思決定は最終的に倫理観に照らし合わせて行うべきです。倫理観とは『人間が、より良い集団活動をおくるために必要なルール』と定義できます。倫理観は時代や社会環境によっても大きく変わっていくのでアップデートすることが重要です。レイヤードの倫理行動規範はこちらに定義されています。

教育・育成・定着支援
・成長

成長することは義務である

企業経営は競争環境である以上、現状維持は衰退を意味します。レイヤードも仕事を通じてより大きな領域での医療の変革や顧客価値の創造をしたいと考えており、会社としての成長を目指しています。そのために、1人ひとりのメンバーも成長して貰う必要があり、成長は義務だと捉えています。

成長意欲が乏しい人にいくら会社側が研修や支援を行ったとしても、大きな効果は見込めません。成長には個成長意欲が乏しい人にいくら会社側が研修や支援を行ったとしても、大きな効果は見込めません。成長には個人の「成長責任」と会社の「育成責任」の両方が必要です。人の「成長責任」と会社の「育成責任」の両方が必要です。

育成は全員の仕事

誰しもが若い頃に多くの人に育ててもらっています。育成とは単発の研修や上司の指導のみで成り立つものではなく、社会全体・組織全体で育成を行うものです。部下がいない人でも自分が学んできたことを組織にアウトプットしていくことや、異なる部門のメンバーであっても気づいたことがあれば教え合い、フィードバックを行う。上司や役員もまた、メンバーによって教えられ成長することがたくさんあります。育成は全員の大切な仕事であると認識しましょう。

入社オンボーディング

組織の成長のためには常に新しいメンバーを増やしていく必要があります。新しいメンバーが早期に戦力化するために入社オンボーディングは非常に重要です。

オンボーディングプロセスに関わっていないとしても、新しい人が早く組織に馴染んでもらうためにできることは少なからずあります。積極的に声をかけたり、挨拶をしたり、グループに誘ってあげるなどです。新しく組織に入る人は不安を抱えています。既存メンバーがすっと手を差し伸べてあげることが大きな安心感に繋がります。

1on1とxylitol

レイヤードでは成長のためのフィードバック、育成、オンボーディングのために1on1を大切にしています。年度の目標設定、半期での振り返りと目標設定、月次面談、年度末での評価面談、それぞれで自身の業務管理者との1on1を行う必要があります。これは社員・スタッフに関わらず必要です。1on1を行ううえではxylitolを記載したうえで面談を実施するようにしましょう。これは議題を明確にすること、伝え忘れなどをなくすこと、言いづらいことでも先に記載することで伝えやすくすることなどを目的としています。

学びを積極的に共有する・
みんなで学ぶ

組織全体で学習サイクルを回すために、自身が業務・非業務に関わらず学んだことはできる限り積極的にシェアしましょう。シェアする方法として、社内勉強会の開催やレポートのSlackでの共有、ブログ、Mtg内での共有などです。

課題のあるメンバーへ
タイムリーにフィードバックする

育成が想定通りうまくいかない、問題のある行動や発言が多い人がいた場合には、なるべく時間を空けずに率直なフィードバックを行いましょう。その場合に、どんな行動や発言のどこに課題を感じたのか、どうしてほしいのか、をなるべく1on1の環境で伝えるようにしましょう。その場合に注意してほしいのは「普通は」「常識から考えて」「考えればわかる」などの発言は避けるようにしましょう。人によって普通や常識、知識のレベルは異なります。

レイヤードでは、上司に対しても部下からフィードバック（良い・悪い問わず）をできるようxylitolでもフィードバックの項目を設けています。積極的に活用しましょう。

本人に改善する意志がない、繰り返し伝えても改善されない、複数のメンバーを巻き込んだ人間関係に問題が起きている場合には、速やかに上長に相談しましょう。その際に自分はどう感じたか？ではなく、まずは「事実」をありのままに報告するようにしましょう。

すべての人が昇格を目指す必要はない

昇格とは、会社で求められる役割が変わったり上がったりすることです。成長と昇格は別です。レイヤードではすべての人が昇格を目指す必要はないと考えます。役割に求められるパフォーマンスを発揮しているのであれば組織にとって貴重な戦力であり、本人が望んでいないのにより大きな役割を強制的に求めることはお互いにとって不幸となりえます。昇格は、昇格をするに十分足りえる能力と、本人の強い意欲が表明されていることが大切です。

しつこいですが、昇格をしない人にも成長は求められます。

多様性の許容

異なる価値観を許容する

多様性（ダイバーシティ）とは、単なるCSR的お題目ではなく、組織的学習と積極的な議論、ひいてはイノベーションを担保する大切な要素です。人種・国籍・年齢・性別・趣味嗜好・育ってきた生活環境・持っている病気や障害に関わらず平等に扱われ、尊重されるべきです。自分と異なる価値観があることを理解し、相手の価値観を尊重しましょう。

多様性とは組織的ストレスでもあります。お互いが前提となる価値観が異なるということです。しかし、多様な価値観を認めたうえで、適切に議論して、最もよい方向性を模索していくことでしか、社会は成り立ち得ません。

情報は可能な限りオープンに

一般的に、指摘やリスクを避けるために情報は非公開にしたくなるものですが、情報の透明性はコラボレーションを促進し組織を健全に保つ効果があります。情報を共有する際はできる限り公開設定をデフォルトとしましょう。

なおプライバシーに関わる情報や契約上の顧客情報、業績予測につながる可能性がある情報など、非公開にすべき明確な理由があるものもあります。

考えが変わることもある

人は経験や議論、得た知識によって考えが変わることが容易にありえます。むしろ考えが変わるということは柔軟性の証でもあります。自分の考え方が変わることを積極的に受け入れていきましょう。ただし、考えが変わった場合には周囲にその理由をきちんと説明する義務があります。あわせて、同僚や上司の考えが変わることを非難すべきではありません。人のことを非難することは結果として自身の思考性を狭める要因にもなります。

平等でなく公平である

平等とは皆が同じ権利を持つことであり、公平とはズルや不正がなく偏りがないことです。レイヤードでは誰しもが公平に扱われるべきと考えます。立場や経験の異なる人に同じ態度や結果を求めてはいけません。

また、会社と個人も公平であるべきです。どちらか一方が犠牲を強いられない関係性を保ちたいと考えています。

心身の健康

健康な心身に健全な仕事は宿る

仕事に全力で打ち込めるのは、心身ともに健康だからです。健康を維持することはプロフェッショナルとして大切な仕事であると捉えてください。しっかりと睡眠および食事をとり、運動習慣を生活に取り入れること。体力をつけること。ストレスマネジメントを行うこと。また、心身に不調をきたしたときには周囲に助けを求めましょう。

休みは自己判断で

レイヤードでは、休みをとることに理由はいりません。休みをとることに、申し訳無さを感じたり謝罪は必要ありません。ただし、自分が休んでいる間にそれをサポートしてくれている仲間がいることを忘れないようにしましょう。仲間への感謝の意を示しましょう。

コミュニケーション
ガイドライン

ここからは、レイヤードでのコミュニケーションや会議におけるガイドラインです。

Slackでの
コミュニケーション
ガイドライン

レイヤードでは複数拠点や多様な職種・働き方を行う上での社内のコミュニケーションの基本はSlackとしています。Slackを円滑に利用するためにいくつか守るべきガイドラインを記載します。

DMは必要最小限に

DM（ダイレクトメッセージ）は、オープンコミュニケーションの対極にあります。DMの利用は必要最小限にとどめましょう。DMを利用して良いのは機密情報（ID/Pass等）を送るとき、個人のプライバシーに関わる非常にセンシティブな内容のやりとりをするときのみです。それ以外の仕事に関わるメッセージのやりとりは基本的にオープンチャンネルを利用しましょう。個人的な要件であっても、オープンチャンネルを利用することをためらう必要はありません。

相手がDMでメッセージを送ってきて、やりとりがDMで続いてしまう場合があります。勇気を持ってDMではなくオープンチャンネルでコミュケーションをするよう誘導しましょう。

なるべく広いチャンネルで発言する

どのチャンネルで発言してよいか迷う場合があります。迷った場合にはできる限り広いチャンネル（参加者が多いチャンネル）の方を選びましょう。適切にメンションを使いましょう。

レスポンスは可能な限り早く

自分宛てにきたメッセージは可能な限り早くレスポンスしましょう。回答に時間を要する場合や、今すぐ返信できない場合は簡単にスタンプをつけるだけでも良いかもしれません。まずは相手に「見てるよ」と伝えることが大事です。

とはいえ、ミーティング中ですぐ返信できないこともあります。メッセージを送る側もその点は理解して送るようにしましょう。

助けを求める・気づいたら助ける
（担当範囲外でも）

わからないことがあって、誰に聞けば良いかわからないときがあります。そのときには、なるべく広いチャンネルで、@channelでみんなに助けを求めることを厭わないでください。

メッセージを見た人はみんなで助けてあげましょう。たとえその内容が自身の担当範囲外だったとしても、助けれることはあるかもしれません。担当者にメンションを入れてあげたり、自分がわかっている範囲を教えてあげたり。相互扶助の精神です。

通知を使い分ける

土日や休暇中はレスポンスする必要はありません。ただメッセージを送る側には誰が休暇中なのかはわかりません。休暇中に通知を受け取りたくない場合は、自身で適切に通知を切るようにしましょう。Slackステータスなどで休暇中であることをわかりやすく周りに知らせましょう。

公式な決定事項等は
ポータルに必ず文書化する

正式な決定事項や会議の議事録、資料、録画したMtgの動画などは必ずポータルに文書化・整理・格納しましょう。Slackは通知として利用しましょう。ポータルが誰でもわかりやすく整理され、古い資料がない状態を担保するのは全員の仕事です。古い情報やファイルが格納されていることに気づいたら、自ら整理しましょう。

会議の運営と進行
ガイドライン

会議を招集するための準備

会議を招集する場合には必ず議題および会議のゴールをスケジュールに記載するようにしましょう。会議の議事進行・運営責任者を必ず決めましょう。議事進行・運営責任者は、時間内に会議が終わること、会議のゴールが時間内に達成されることに責任を持ちます。上司であっても会議中は議事進行・運営責任者に従ってください。

WEBミーティングのルール

WEBミーティングでは必ず映像（ビデオ）はオンにしましょう。セキュリティ的な観点とともに、表情など多くの情報が得られるとともに、話している方も安心感を持てます。どうしても外で移動中などで映像をオンにできない場合は、その旨最初にチャット等で申し出ましょう。

また、なるべく周囲が静かな環境でミーティングに入るようにしましょう。どうしても難しい場合は、自分の発言以外ではこまめにミュートを使うようにしましょう。

会議の資料はGoogle Docs等で共有し
スケジュールにURLを貼る

会議の資料がある場合には、Google Docs等で共有した上で、会議のスケジュールに貼るようにしましょう。複数の参加者から資料を集める場合は、Google Driveのフォルダを用意しそこに資料を格納してもらうようにしましょう。資料を共有したタイミングで参加者に通知し、会議前に目を通しておいてもらえるようにアナウンスしましょう。

決議方法を決める

会議中に何かを決める必要がある場合でも、容易に結論が出ない場合があります。その場合には「どうやってこの議題を決めるのか」を決めてください。DRIを任命したり、どの部門の誰に決めてもらうことが適切なのかを話し合いましょう。あるいは自分で決定することを厭わないでください。決定したことには、みんなで全力でコミットしましょう。

必ず発言する

勉強会や情報共有のための会議を除き、基本的には会議は話し合いを行うために行います。会議では必ず発言することを意識しましょう。たとえ異なる意見がない場合でも、誰々と同じ意見である、のように自分の意見を表明することは大切です。

チャットやリアクションを活用する

会議の進行上、発言すると邪魔になってしまうのではないかと発言をためらう場合には、適切にチャットを使いましょう。議題・話題の中で気になったことのメモや小さな疑問点、思ったこと、賛成の意を表明するなど、会議のチャットを活用してください。会議議事進行者は会議前にチャットでの発言を促し、適切に取り上げてあげてください。

必要ない会議に参加しない

会議の議題において自身が関与する部分が少ない、意見をあまり持たない場合には、無理して会議に参加する必要はありません。会議に参加しない旨と理由を会議招集者・会議責任者に伝えましょう。どうしても参加できない場合や、情報共有だけ必要な場合には、会議の録画の要請や、議事メモの共有を会議責任者に要請しましょう。

会議は最小限に

とはいえ、非同期コミュニケーションを優先し、会議の開催は最小限としましょう。テキストコミュニケーションであれば、会議に参加していない人でもあとから議論を辿れ検索も可能です。人の時間を中断することもありません。会議を招集・開催するときは、本当にその会議は同期コミュニケーションでやらないといけないか、改めて見直しましょう。