❓
AppBrew のバリューに関するFAQ
(※外部公開中)
概要FAQ全体AppBrewのバリューとはなんですか？バリューについて意見やわからないことがある場合はどうすると良いですか？ポジションによって評価されやすい・されづらいバリューがあると感じますOPENいつDM・プライベートチャンネルを使って良いですか？分報で業務に関するやりとりをしても良いですか？Slackでの発言量が多ければOPENですか？OPENなので何でも言って良いですか？言っていけないことはありますか？OPENと心理的安全性にはどのような関係がありますか？情報にたどり着けません知らないところで話が進んでいる / どこで話が進んでいるのかわからないのはOPENですか？情報が十分に公開されており自分でキャッチアップできるはずなので、共有は少なくても良いですか？OPENにすべきでない内容がOPENになっていますLEANLEANとはそもそもどういう意味の言葉ですか？慎重な意思決定が必要な場面もあると思うのですが、本当に「最も重要なのは速く決めること」ですか？速く決めるためにできることはありますか？「許可より謝罪」とはなんですか？可逆な意思決定とはなんですか？壊す必要はありますか？検証ができない職種もあると思うのですが、カルチャーブックのLEANの内容は検証に偏りすぎていませんかLEANを意識して、説明を省いたり雑にお願いしたりしてもいいですか？LEANを意識して、（主に技術的な）負債を残しても良いですか？USERFIRSTユーザーとは誰ですか？ユーザーのための改善が十分に行われていないと感じますユーザーに直接関わらない職種に何かできることはありますか？ユーザーを蔑ろにしていると感じることがありますOWNERSHIP本当に「私の仕事ではない」と言うべきではないですか？提案だけして人に任せるのはOWNERSHIPのない行動ですか？本当に「全員がリーダー足り得るべき」ですか？サイドプロジェクトのオーナーを持ちすぎてつらいです批判されるのでオーナーになりづらいと感じます対話しても納得できない場合はどうすればよいですか？
概要
AppBrewのバリューに関するFAQをまとめた資料です
FAQ
全体
AppBrewのバリューとはなんですか？
AppBrewにおける価値基準であり、AppBrewに所属する全員の行動指針となるものです。
現在OPEN, LEAN, USERFIRST, OWNERSHIPの4つが定められています。
これらのバリューを理解し実践することにより、個人・チームとしてよりパフォーマンスを発揮できるようになることを目指しています。制限し縛るためのルールではなく、個々の行動の基盤や裏付けとして機能し、全員が自信を持って働けるようになるための指針です。
バリューについて意見やわからないことがある場合はどうすると良いですか？
以下の手段があります。
ドキュメントを読んでみる
人に伝えてみる・聞いてみる
- #general_organization
- 上長や近くの相談しやすいメンバー、長く会社にいるメンバー
ポジションによって評価されやすい・されづらいバリューがあると感じます
前提として、バリューは行動の指針となるものであり、評価のために存在するものではありません。バリューは評価制度と密接に関わっていますが、評価制度に合わせたバリューにするのではなく、バリューに合わせた評価制度にするべきです。
また、バリューに限らず、ポジションによって偏りを産まないような評価制度を設計すべきであり、積極的にアップデートを行っています。
評価制度のアップデートについては現在明確なフローが設定されていないので、まずは上長に相談してみてください。
OPEN
いつDM・プライベートチャンネルを使って良いですか？
前提として、OPENにできない理由がないのであれば、可能な限りOPENにすべきです。
しかしOPENにするのがふさわしくない内容も当然存在し、それらについてはプライベートなやり取りも許容されます。具体的なケースとしては【社内向け】Slack・チャットツールに関する注意点 で説明されています。
上記に無いもので、OPENにするべきでない項目については個別判断となりますが、できる範囲で公開しつつ、プライベートなやり取りを行ってください。「できる範囲での公開」の具体例としては、プライベートチャンネルの存在明示が挙げられます。
また、他メンバーからDMが来たが後述の例外に当てはまらない場合、「パブリックチャンネルでお願いします」と言う責任が受取側にもある で説明されているように、受取側の責任として、プライベートな場でやりとりをすべきでないと感じた場合には、相手に伝えてパブリックな場に移動することを相談しなければなりません。
もし迷ったり違和感を感じるものがあれば、積極的に議論し基準を更新することを推奨します。
分報で業務に関するやりとりをしても良いですか？
ケースバイケースです。
Slackに関するルールや活用法 にあるとおり、分報にはOPEN文化を阻害しうるリスクがあります。業務に関するやり取りが分報で始まった際には、適切なチャンネルに移動する責任と、それをきちんと指摘する責任があります。
ただし、どこまでが業務に関するやり取りなのかが曖昧であったり、どのチャンネルが適切なのか難しい話題もあるでしょう。すべてのケースをカバーできるわけではありませんが、以下のような指針を示します。
- やり取りの起点になる場合（業務に関する依頼のためにメンションする等）は、分報ではなくはじめから適切なチャンネルで行う。なお1on1に関する連絡などは、そもそも適切なチャンネルが分報であるため特に問題ない。
- 分報で業務に関する考察などを記録することは、情報をOPENにするという意味で推奨される。またそれに対して簡単なコメントを分報で行うことも、スムーズなやり取りを優先するため許容される。
- 簡単なコメントから、他の多くのメンバーを巻き込んだ議論に発展する場合は、それらのメンバーを巻き込む前のタイミングで、他の適切なチャンネルに移動することが望ましい。
- 分報で何らかの事項が決定された場合には、そのやりとりを参照できる形で、関連するチャンネルやGithub・Notion等により共有しなければならない。
Slackでの発言量が多ければOPENですか？
整理された情報を適切に届けるところまで含めてOPENであり、ただSlackで多く発言するだけではOPENは達成されません。他のストック型のツールも併用しつつ、適切なチャンネルで、適切なメンションを付けて発信することが重要です。
しかしあらゆるアウトプットを丁寧に行うコストも無視できないので、Slackのようなフロー型のツールをメインに活用し、そこで得られた結論を整える、というスタイルがOPENとLEANを同時に達成する方法の一つとなるでしょう。
例えば、分報で考えていることを整理しながら垂れ流したり、業務チャンネルのスレッドで細かい議論を残したりした後、最終的な結論をNotionで整えた上で、Slackの適切なチャンネルでチームにメンションを付けて共有する、といった流れが考えられます。SlackやNotion等のツールをまたぐ際には、相互に参照できるようリンクを貼っておくとより良いです。
OPENなので何でも言って良いですか？言っていけないことはありますか？
前述の通り、DM・プライベートチャンネルを使うべき内容も存在します。
OPENと心理的安全性にはどのような関係がありますか？
心理的安全性とは、「対人関係においてリスクのある行動をしてもこのチームでは安全であるという、チームメンバーによって共有された考え」と定義されています。
この概念とOPENとにはいくつかの関係があります。
まず、心理的安全性を保つ発言を心がけるべきという点です。OPENなので何でも言って良いですか？言っていけないことはありますか？ にあるように、相手を不安にさせるようなコミュニケーションは控えるべきであり、その基準の一つとして心理的安全性を保てるか、という観点が役立ちます。
次に、情報がOPENになっていることと、情報を知らないことは両立するという点です。多くの情報が公開されていることは、その情報に独力でたどり着けることが求められるように感じるかもしれませんが、情報が多ければ多いほどそれは困難になっていきます。必要な情報が不足している際には、質問することをためらわないでください。
質問に対して、ドキュメントのリンクを貰ったら、それは「このドキュメントは自分で探し出せるはずだ」といった意味ではなく、「このドキュメントに書いてあるので参考にしてみてください」という単なる親切な共有です。知らないことを恥じたり怖がったりする必要はありません。
さらには、自分がわかっていないことをOPENにするという意味もあるでしょう。周りから見て、あなたが何を知っているのか把握するすべは限られています。現状を公開し適切なサポートを受けられる状態が保たれていることは、OPENであり、心理的安全性が高いことの証拠でもあります。心理的安全性が高いことを示すふるまいは、リスクのある行動をしても安全であることを明確にし、周囲の心理的安全性にも良い影響を与えるでしょう。
知らないところで話が進んでいる / どこで話が進んでいるのかわからないのはOPENですか？
いいえ、情報が整理され誰もがアクセスしやすくなっている状態が、理想とするべきOPENの形です。気をつけるべき点として例えば以下があります。
発信
決定事項だけではなく、議論の過程についても共有し、意見を取り入れられるようにする
口頭でやり取りした内容はテキストで残し、適切な人にメンション等できちんと共有する
定期的な情報共有の場を設ける
共有不足を指摘された際には、上記の点について見直し改善する
受信
適切なSlackチャンネルに入ったり、ミーティングに参加したり議事録を確認したりする
欲しい情報があれば知っていそうな人に積極的に聞きにいく
必要な情報が届いていない人を見つけたら自分がハブとなってさらに届ける
知らないところで話が進んでいて困ったときには、どこで話が進んでいたのかを確認し、上記の点について見直し改善する
情報にたどり着けません
以下を参考にしてみてください。
情報が十分に公開されており自分でキャッチアップできるはずなので、共有は少なくても良いですか？
いいえ、適切な人に情報を共有することは常に意識されるべきことです。
そもそも情報の存在を知らなかったり、どこに何があるのか把握できていないという状況から、すべてを把握するのは困難ですし、分かる人から共有を受けたほうが全体として効率が良いことが多いです。
例えば入社直後のメンバーや、新しくチームに所属することになったメンバー、新しいトピックに関する情報共有などについては、特に上記が当てはまるでしょう。
もちろんある程度慣れてきたら などを参考にしつつ、自分でさらにキャッチアップできることが期待されます。
OPENにすべきでない内容がOPENになっています
明確にOPENにすべきでない場合は、すぐに指摘して削除したり移動したりしましょう。
グレーゾーンである場合や、直接伝えづらい場合には、上長や などを活用してください。
LEAN
LEANとはそもそもどういう意味の言葉ですか？
大雑把に言えば、起業や新規事業を成長させるために、素早く無駄なく改善サイクルを回す、といった方法論を指しています。
LEANに関する関連書籍は を参照してください。
弊社のバリューにおいては、カルチャーブックで説明されているように、悪くなることを恐れずに素早く行動・意思決定することを意味します。
慎重な意思決定が必要な場面もあると思うのですが、本当に「最も重要なのは速く決めること」ですか？
そうです。もちろん速く決めることと同程度に重要なこともありますが、速く決めることは常に重要だと認識するべきです。
ただし、この「決める」は必ずしも最終決定を意味しないことに注意してください。例えば、可逆な場合なら「一度試すと決める」ことや、十分に可逆でない場合にも「ネクストアクションを決める」ことなどが挙げられるでしょう。そのような決定を先送りにするメリットはありません。
もちろん最終決定が速いことも重要です。ためらう要素がないのなら、大胆に決定しましょう。
様々なバイアスにより決定は先送りにされがちです。意識的に「最も重要なのは速く決めること」であるという指針を持つことは、意味のない先送りを防ぐためにも、大胆な決定によって競争力を維持するためにも、非常に重要です。
速く決めるためにできることはありますか？
以下が考えられます
- 可逆的な意思決定であれば、最低限共有をしつつ、誰かの許可を取ったりすることなく進める
- 根拠を必要とする意思決定でも、万全の状態は目指さず7割程度の情報を集めたら決める
- 参考：2016 Letter to Shareholders - Amazon の High-Velocity Decision Making
- 非同期で進められる部分は進め、不必要に定例等の機会を待たない
「許可より謝罪」とはなんですか？
許可を求めずに動きもし失敗したら謝れば良い、といった意味の標語で、弊社のバリューであるLEANやOWNERSHIPに通じるところがあるものです。
もちろん謝罪を要求する標語ではありませんが、そういった誤解を招きうるので正式にはバリューやカルチャーに加えていません。ただし、わかりやすい言葉としてある程度浸透しているため、裏カルチャー的な扱いになっています。
可逆な意思決定とはなんですか？
あとからその意思決定と反対のスタンスを、少ないリソースで取ることができるなら、十分に可逆と言えます。もしネガティブな影響があっても、ほぼ元の状態に戻すことができるなら、それは可逆です。取り返しのつかないことが起きないのであれば、多くの場合で可逆とみなして良いでしょう。
壊す必要はありますか？
壊す必要はありません。築き上げてきた信頼関係や基盤、ユーザーの体験などを無意味に破壊する理由はないでしょう。
ただし2つの意味で壊すことは重要です。
第一に、素早く決定し進めることが最も重要であり、壊さないことよりも優先される場面が多いという点です。壊す必要はありませんが、壊れるくらいのリスクを負ってでも、まず速く進めることを意識するというメッセージになります。また壊れる可能性があっても、それが可逆な壊れ方であれば素早く進めましょう。
第二に、今あるものを壊して新しくできないかという点です。同じようなことを続けているだけでは、競争力は落ちていき、ユーザーは離れていくでしょう。当時たまたまその意思決定が最善だっただけという状況は多々あります。既存の枠組みを壊して、大きな価値ある行動・意思決定をすることは重要なことです。
検証ができない職種もあると思うのですが、カルチャーブックのLEANの内容は検証に偏りすぎていませんか
たしかにそのようです。アップデートを検討中です 2022/11/2
LEANを意識して、説明を省いたり雑にお願いしたりしてもいいですか？
また、説明を省いて何も情報を残さないことは属人化を招き、OPENな文化を阻害します。
他のカルチャーと両立できる範囲で、スピード感を持った業務の遂行を心がけてください。
LEANを意識して、（主に技術的な）負債を残しても良いですか？
望ましくありません。一時的に素早く動けたとしても、その後が続かないことがほとんどでしょう。最終的にはLEANに繋がらない結果になってしまいます。負債であることがその時点でわかっているなら、別の方法を取るべきです。
しかし、その時点では最善の選択だったものが、結果として負債となってしまうことはしばしばあるでしょう。負債になってしまったときに放置せず、素早く回収することが肝心です。
また逆に、負債を一切残さないことを意識してスピードを落とすこともLEANに反しています。非常に塩梅の難しい問題ですが、ケースバイケースとなるので認識を他のメンバーとすり合わせつつ進めるのが良いでしょう。
USERFIRST
ユーザーとは誰ですか？
AppBrewがサービスを提供する対象をユーザーとします。toC, toBは問いません。
具体例としては以下があります。
- LIPSのユーザー
- LIPSに広告を出稿しているメーカー・ブランド
- For Brandsを利用しているメーカー・ブランド
- 新規事業で開発するサービスのユーザー
ユーザーのための改善が十分に行われていないと感じます
改善点に関する意見が十分に届いていないかもしれません。適切な人に声を届けることはOPENで推奨されていることです。またすでに検証が行われ、失敗したという事例があるかもしれません。
活用できるツールとして以下があります。
- Slackの各チャンネル
- #dev_lips_idea 等のアイデアを気軽に投稿できるチャンネルがあります
- Githubのissue, Notion等
- 過去の記録や議論がまとまっています
また、定量的/定性的な根拠やヒアリング記録があるとより改善が進みやすいです。もしアクセスしやすいところにそのような情報がある場合には、改善を直接行いづらいポジションであっても、OPENに共有していくことがUSERFIRSTに繋がります。
ユーザーに直接関わらない職種に何かできることはありますか？
すべての業務が最後にはユーザーへの価値提供に結びついていると意識することは、直接関わらない職種のメンバーであっても重要なことです。
また前述の通り、改善点に関する情報を持っている場合はぜひ適切なメンバー・チームに積極的に共有してください。さらに、そのような情報がない場合には、自らがユーザーになったり身近なユーザーからヒアリングする機会を作ったりして、フィードバックを行うといったことも考えられます。
ユーザーを蔑ろにしていると感じることがあります
明らかに問題となる言動がある場合には、 などを活用してください。
OWNERSHIP
本当に「私の仕事ではない」と言うべきではないですか？
結果としてあなたの仕事ではないことは当然あります。例えば専門性を要する仕事や、別の人がオーナーである仕事は、あなたの仕事ではないこともあるでしょう。
だからといって、はじめから「私の仕事ではない」というスタンスでいることは誤っている、というのが「『私の仕事ではない』などと言わない」に込められたメッセージです。
はじめに何かできることがないか検討することは、あなたの仕事に含まれます。
提案だけして人に任せるのはOWNERSHIPのない行動ですか？
いいえ。提案には価値があり、それを実行するのが本人であるかどうかとは関係がありません。また、やるとよい思っていることがあるのに適切な人に伝えないことはOPENに反します。
ただし、それを本当にやるべきだと思っていて、やれる人がいないのであれば、自ら進んでやるか、誰かにボールをきちんと渡すか、それも無理なら今後のTODOとして共有し状態を明確にしておくべきです。せっかく価値のある提案であっても、曖昧な状態にし続けてしまうのは非常にもったいないです。そこまでやれば十分にOWNERSHIPがある振る舞いだと言えるでしょう。
本当に「全員がリーダー足り得るべき」ですか？
はい。カルチャーブックにもある通り、理想的には全ての人が独立し責任を持って意思決定できるべきで、そうしない理由はありません。
チームをまとめたりするだけではなく、専門性と責任を持って取り組み、その領域を牽引することもリーダーの要素であり、役割分担と全員がリーダー足り得るべきであるということは両立します。
サイドプロジェクトのオーナーを持ちすぎてつらいです
まず、あなたのような人のおかげで様々なプロジェクトが進み、価値を生み出しているという点について心から感謝します。
誰がどれくらいボールを持っているのか見えづらく、進んでオーナーになる人に役割が偏っていくという傾向はあるので、積極的にボールを手放す機会を作ると良いです。またそういった機会を作ったり、ボールを受け取ったりして協力することも、ONWERSHIPを体現する行動であり推奨されます。
例えば、プロダクト部の一部では棚卸し会をQごとに実施し分担を試みたりしています。そのような制度を活用したり、上長に相談してみるところからはじめてみてください。声を上げてもらえれば、周囲は協力を惜しみません。
批判されるのでオーナーになりづらいと感じます
まず批判は非難ではなく、より良い意思決定を目指すためのものであり、あなたの人格を否定しているわけではありません。たしかに自分の意見が通らず傷つくこともあるでしょうが、全く批判を受けない人はいないですし、批判を受けない意見というのは、非常に稀かあまり意味のないものでしょう。あなたの意見に価値があるからこそ批判を受けていると、ポジティブに受け取るのが肝心です。
いきなり大きな場所に出すのが心配なら、他のメンバーに壁打ち相手になってもらいブラッシュアップするのも良いでしょう。一度出した意見を修正することはおかしなことではありません。大胆な方針転換を決定するのもOWNERSHIPです。
とはいえ攻撃的なコミュニケーションも少なからず存在するでしょう。もし明らかに攻撃であると感じたら改善が必要なので、あなたのためにもその人のためにもAppBrew全体のためにも、上長や に早めに相談してください。
対話しても納得できない場合はどうすればよいですか？
議論が平行線になってしまうということはありますが、結論に合意できなくても、結論のために必要な情報を集めたり、次に何をすると良さそうか決めるところまでは合意できることがほとんどです。食い違っている点を明確にして、判断できる材料を集め、検証できるなら検証しましょう。
納得できるプロセスで議論を進め、そこまでやっても結論が得られないのであれば、OWNERSHIPで要求されている範囲は十分に達成されています。プロセスに納得しているのであれば、異なった結論となってもきちんとコミットしましょう。
また一対一の議論だと平行線が続くので、他のメンバーに入ってもらい新しい視点から意見をもらうことも有効に働くでしょう。問題によっては社外のプロフェッショナルを呼ぶという方法も考えられます。LEANと反する部分もあるためやりすぎには注意が必要ですが、素早く広く情報を集めて意思決定に役立てることは重要です。