11章 命じられた文化

命じられた文化というアンチパターンは、組織の文化が、メインロビーに飾られているくどい声明やプレートに記されているものの、実際には具体的な形では存在していない場合に発生します。

命じられた文化(Culture by decree)という名前が強烈(98lerr)

企業文化が持つ重要性と重みを示唆しています。しかし、面接官から返ってくる答えは、必ずしも真実ではなく実証できるものでもありません

面接官側をやることが増えてきたので、胸に刺さります。正直に答えているつもりではあるのですが。(hayase)

文化に関する最も有名な慣用句は、マネジメントの権威であるピーター・ドラッカーの「企業文化は戦略に勝る(Culture eats strategy for breakfast.)」というものです。企業が採用活動を行う際には、候補者が組織の文化に適合しているかどうかを確認することに、異常なほど執着します。

AWSの面接が OLPに照らして一緒に働けるかを見る話を前に聞いたことがありました。実際、技術的なところは一緒にやってみないと見えない部分が多くて、それよりも一緒に働きたいと思うか、自分たちの文化を一緒に盛り上げてくれそうと思えるかというのはありますね。(98lerr)

多くのテック企業では、面接の際にアルゴリズムを重視するあまり、候補者が会社の繁栄に必要な人間的資質を備えているかどうかのソフトスキルを評価できていません。たった一人でも間違った採用をしてしまうことで、築き始めた文化を台なしにしてしまう可能性があります。

11.1 文化とは何か?

文化的価値観: Cultural values

文化的習慣: Cultural rituals

信念: Underlying assumptions

11.1.1 文化的価値観

いずれにしても、文化的価値観は、その企業が重視する理想の姿を書き表したものです。たとえばエンロンのコアバリューは次の4つでした。

敬意, 誠実さ, コミュニケーション, 卓越性

原語Memo: Respect, Integrity, Communication, Excellence

11.1.2 文化的習慣

この習慣には2つの目的があります。まず新入社員が歓迎されていると感じることができます。また現役社員にとっては自己紹介や会話のきっかけになります。自己紹介メールの中で興味深い事実を紹介することで、最初の数分間の話題探しのような気まずい状況を避けることができます。

自己紹介を公開しておくのは、周りから見てその人をちょっと知ってる感がしていいですね。miro で自己紹介コーナーを用意したりします。(98lerr)

偏愛マップの話とかよくありますね。

最もよく見られる習慣はスタンドアップミーティングです。スタンドアップミーティングの背景にある考え方は、現在の担当している仕事について議論するために、チームメンバーと頻繁に共有する場を提供することです。

ふと気付くと、こういうミーティングが報告会になってたりする。議論できる機会がある、っていう捉え方を文化レベルで定着させるのが悩ましい。今時点、割り切って時々気付いた人が言うものと考えてます。(98lerr)

「報告会」にしないのは難しいですよね。逆に1人で長く話す人もいたりして。

とりとめのない報告を防ぐことができます。しかし、スタンドアップに参加したことがある人なら、大勢の人と話すのが好きな人にとっては、立っていることは何の妨げにならないことも知っているでしょう。

まさに今、悩んでいる事が書かれていたのですが、個人の性格ではなく文化に帰着するところが面白いです (hayase)

組織レベルで文化を設定はできないかもしれませんが、よりミクロなレベルで文化を調整する機会はたくさんあります。小さなチームの中で設定されている文化的習慣や規範を考えてみましょう。プルリクエストの作法、ユニットテストの要求、自動化などの小さな慣習です。

小さなとこからコツコツと……ですね。(hayase)

11.2 で、一回注意したらうまく言った感じになった話になってますが、実際そんなにうまくいかないことも。信念とかあって。

11.1.3 信念

信念は、組織の能力を最も制限する要因となります。

例に挙がっているのは、良い方向に変化できると思っているか、そうでないか……という内容ですが、他の種類はないのかなと思いました (hayase)

良い方向に進む、立ち止まる、その他？ ※5/27に改めて

その社員は人材であれ、能力であれ、政府の規制であれ、組織の何かが会社の変化を妨げていると感じています。社内で多くの人がこれを信じていると、その信念は事実となり、人々はその考え方に縛られます。

どうにも出来ない理由を最初に考え始める人はいるけれど、その人はの裏にある信念を見ようという考え方は足りてなかったなとこの話見て思いました。(98lerr)

土台になる価値観も変えないといけない、その人にとっての免疫を見つけていく

https://scrapbox.io/files/664ac78604d24b001d452a71.png

信念は必ずしもネガティブなものではありません。強い文化を持つ会社では、社員が持っている信念が、その会社の強さの一部になっています。たとえば、次のような信念です。

こういう信念を「できてること」として文字にしていくとか、何らかの形で組織内のそれぞれが認識できる状態になると、文化的習慣になっていく？(98lerr)

原語を見たら 文化的習慣 = Caltural rituals だったので、別モノだと理解しました。(98lerr)

11.2 文化はどのように行動に影響を与えるか?

これは、文化がいかに行動に影響を与えるかを示す例です。もしレビュアーが、ジャスティンにチームの文化的規範を満たすように主張していなかったら、彼は基準以下の変更を簡単にパイプラインに滑り込ませることができたでしょう。

他のコード見て雰囲気で、っていうやり方もモノによってはありますが、ある程度名言されてるのは大事ですね。一方で、余りにかぎ過ぎると形骸化したチェックリストになることもあって、バランスは悩ましいです。(98lerr)

たしかに。自分で勉強しては、教材も持ってないし、モチベーションも持っていないことが多い。

社内 loadmap.sh

高い基準は、先天的に有しているかどうかが決まるような資質ではありません。しかし、基準を教えるには規律と、基準以下のものは認めないという文化が必要です。

過去に聞いた、標準化とガイドラインの話を思い出しました。ミニマムを達成させるための標準化と、よりパフォーマンスを出せるようにするためのガイドラインを、別々に、だけれどもセットで考えないと片手落ちになる。(98lerr)

どこまでドキュメント化するか、悩ましい。

11.3 文化を変えるには?

まず最初にすべきことは、自分たちには文化を変えることができるという信念を確立することです。文化は、多くの場合1つのきっかけで変化します。

共感。諦めて、自分だけでも楽できるようにで動いてる人を見ると悲しい。 (98lerr)

+1 (hayase)

「転職するつもり」は既存制約リセットして考えられる

でも、転職したいわけじゃない気持ちも

文化を変えるためには、社会集団の中で文化がどのように伝達されるかを理解することが重要です。

今、ものすごく興味のあるポイントです(hayase)

11.3.1　文化の共有

言葉を使って物語やアイデアを共有します。言葉を通じて、文化の理想を促進するための制度を組織し、構築します。さまざまな集団の中で、共有された信念や価値観を表現するために、習慣を作り、伝えます。言葉は、文化を表現するすべての中心にあるのです。

文化は空気で醸成みたいな雰囲気はところどころ感じるときありますが、言葉、文章、物語にしてみるのは効果的ですね。怪しさ感じた時ほど、ここに立ち戻りたい。(98lerr)

案外ストーリーにしない。

数字やストーリー、恣意的になりがち？ストーリーはそこが露骨に出るのもよいかも。

11.3.1.1　言葉による文化の共有

すべてを知らなければならないというプレッシャーを克服して「わからない」と言えることは、仕事の場ではなかなか見かけられない、人の弱さをさらけ出します。この弱さは、ミスや偏見、誤った信念を持つ人間であってもかまわないという意味で、チームメンバーを人間らしくします。

自分で考える以上に、人は他人を人間と思ってないというのを最近周囲と話してました。相手は自分の見てないことで、持ってる仕事を淡々と消化しているマシンのように見ている。(98lerr)

一方で、「わからない」といえばいいような振舞で、思考を止めてしまうタイプの人もいると思っています。そういう人への「わからない」のハードルの下げ方は悩ましい。分からない理由を掘り下げる支援もやり方がうまくいかないと「わからないというと詰められる」という印象を与えてしまう。(98lerr)

これを読んで、「わからないので」に続ける言葉が大事だな……と思いました (hayase)

気づかないうちに言い訳になる。だからこそ続ける言葉が大事。

彼の特徴的な言葉は「どういった助けが必要ですか？（How can I help?）」です。

1on1をする際などに大事なキーワードになるな、と思いました(hayase)

わからないの思考停止への回避につながりそう。

11.3.1.2　物語による文化の共有

たとえば、あなたの会社で起こった障害の話を考えてみてください。これらの話は単なる伝承ではありません。その物語は現在の行動を正当化するために使われます。

こういう、障害のつらみを伴う社内のルールが、物語なしでルールだけ残って形骸化するのは避けたい。物語をうまく残していきたいけれど、「残したい」だけだと飲み会話くらいでの伝承になってしまうのが悩ましい。(98lerr)

+1

ポストモーテムも、アクションだけじゃなくて過程を紐づけて残し続けたい。

インパクトが分かると気持ちにつながる、アクションだけだと形骸化しがち。

11.3.1.3　習慣による文化の共有

あなたの習慣は、純然たるプラスの効果を生んでいますか、それともマイナスを拡大していますか？

あなたのチームが求めている文化的影響を生み出す習慣を育てるようにしましょう。

これは厳しい指摘だなと思いました。今の仕事の進め方、コミュニケーションの方法、定期イベントは、本当に「プラス」の方向に向かっているだろうか。「プラス」とは何かを明確に意識できているだろうかと振り返ってみます (hayase)

習慣化したものほど、無意識になって、ふりかえり対象から漏れる

ふりかえり方法変えるとか、外部からのインプットでメタ認知してみるとか、困りごとから掘り下げて習慣の問題に気づくか

外部からのインプット、新人とかも効果的

11.3.2　個人が文化を変えることができる

このようなパーティでは、同僚たちが「あの優秀な人がいなくなったら、この会社は変わってしまう」という思いを共有しています。私はこのような人たちを文化チーフと呼んでいます。

自分で何かを変えようとすると体感で変わらないもどかしさを感じたりするけれど、人が去ったときに「あの人が去ったダメージあるな」と思うときがある。文化チーフって言葉にして考えてみると、思いのほか個人の影響ってあるのかもと思いました。(98lerr)

一方で「自分が去っても大丈夫かな」と思うくらい影響与えてるような気持ちになったときは、去ってみると案外誰かがうまいこと補ってくれる状態だったりする。思ってるに、動き方まで周りに伝搬してるんだなと感じました。(98lerr)

「その人が言ってることは正しい」って思われる状態の危うさ

11.3.3　会社の価値観を調べる

まずはじめに、会社の価値観をしっかりと理解しておく必要があります。文化を変えるというこの旅を始めるとき、会社の価値観があなたの行動の盾となります。

会社の価値観、組織の価値観、チームの価値観。迷走しないために、明にしておきたい。暗黙で済ましてしまっているのもたびたび見る。(98lerr)

+1(hayase)

チームの価値観を話さずに済んでいるチームは、価値観を伝え続ける個人の依存もありそう/あるいはいうまでもなく浸透してるか(98lerr)

チーム内では、相手を侮辱したり傷つけたりすることを恐れて、率直な会話が行われません。チームメンバーとの関係がうまくいかないと、仕事から得られる幸福度に大きな影響を与えます。多くの人は対立を避けようとします。これでは組織が麻痺してしまいます。

心理的安全性の誤解で起きがちなので、対立できることも大事だっていうのは意識的に伝えています。(98lerr)

従業員エンゲージメント、Work Life Balance とかも誤解多い

エンゲージメント、自身が手応えを感じてこそ

↓ 次はここから

確固たる事実と、その事実から導き出された視点や意見を明確に分ける。

議論の余地のある表現を使う。

自分の行動の最終目標を明確にする。

改善後は，事実 → 評価 → 意見 → 最終目標、の順に端的に述べていますね。ただこの順序で話すと、わりと「結論が遅い．わかりにくい」と嫌われがちな気もします(hayase)

エンジニア同士の議論なら、デフォルトがこれで良いような気がしてきました(hayase)

ビジネスの話でマストの意識！

自分のメッセージに関する理由や文脈を提供しなければ、メッセージの受け手がそれを補います。しかし、彼らが正確に補うとは限りません。

上の項目との関係で、言わないと伝わらないですよね．(hayase)

11.3.4　習慣を作る

新しい習慣に取り組む際には、次のような質問を自問する必要があります。

1. 習慣の目的は何か？

2. どのようなスタイルの習慣を作るのか（社会的習慣か、プロセス的習慣か）？

3. 習慣で期待されるアウトプットは何か？

4. 何が習慣の実行のきっかけとなるか？

定例会みたいなものを話す最初に使うのにいい質問(98lerr)

11.3.4.1　習慣によって失敗を受け入れる

新任のエンジニアリングマネージャーであるサーシャは、この状況を変えたいと考えています。彼女は、失敗を祝福し、知識を共有する習慣を行うことにしました。彼女はチームに、失敗は起こるものであり、チームは適切な方法で失敗に対処すればよいのだと理解してもらいたいと思っています。彼女の目標は、なぜその失敗が起こったのかを理解し、再び失敗が起こる可能性を減らすことです。

彼女はこれをプロセス的習慣に分類していますが、社会的な側面も織り交ぜたいと考えています。キャッシュ層に対するコード変更が原因でシステム障害が発生すると、チームはそれを祝うようにしました。彼女は、この習慣を楽しんでもらおうと考えました。

失敗の理解を社会的習慣として捉えようとするのが面白い。確かに、プロセス的習慣で捉えるよりも「良くしよう！」という気持ちが広がりそう。(98lerr)

障害を起こしてしまったときに、プレゼンテーションさせるだけでなく、ピザパーティをするのですね。ポストモーテムの空気がかわりそうです。(hayase)

モードの使い分けで、一度笑い飛ばすくらいに話して、そこから真面目に取り組むというのもひとつのカタチになるのかも？

一回お昼ご飯たべにとか？？

ピザを職場で食べて、リラックスしながら考える効果かも。

リモートワークだと実現が難しそう．どうしたらいいかな

11.3.5　習慣と言葉を使って文化的規範を変える

ある意味では、アーキテクチャレビューの遅さによって、チャドはそのレビューを回避したいというプレッシャーを感じたわけです。だからといって、それをスキップすることが許されるわけではありませんが、アーキテクチャレビューチームが組織全体のニーズ、つまり開発者のニーズを満たしていない可能性を示唆しています。

属人化が悪化した時に起きてしまう例かもしれない。レビューできる人が限定的になり、その人が忙しくなり、レビュー日程が組めず、スキップできないかという動きに走る。全部は解消できないけれど、linter とかの自動レビューはレビュアーの時間を作る(レビュー時間を縮小する)のには欠かせない。(98lerr)

逆に、シニアの前にレビューを積んで満足というケースも

シニアのレビュー、どこまでジュニアが巻き取っていく？という考えがないときつい。

11.4　文化に合った人材

11.4.1　古い役割、新しい考え方

共感はDevOpsに強さを与える核です。

「分かってくれない」という言葉がでたとき、ちょっと危険信号ですね。チーム内の協調性は高まる一方、チーム内に閉じていくサインでもある。(98lerr)

敵がいると結束する

結束すれば、それでいいのか？　壁を高めてる。

「その人の靴を履いて1マイル歩いてみないと、その人を理解できない」という格言は、DevOpsにおける共感にも当てはまります。

「相手の立場に立って考える」は想像以上に大変なこと、というのがこの本通して良くわかる。(98lerr)

11.4.1.1　会話を通して問題を共有する

共感を生むには、対話や会話が大切です。一般的に、お互いの問題を理解していないチームメンバーは、お互いにあまりコミュニケーションをとっていません。

結果につながる会話でないと業務中に... って意見は良く見かけますが、普段からの対話がないと急に話しても内容は薄くなりますね。これもなかなか伝わらない。社内イベント開いて、話す機会を増やして実感してもらうくらいがやれることと思っています。(98lerr)

リモートが多い、リモートだと話が始まらない。

はばひろい課題の共有だけなら，振り返りの工夫で話せるのだけど，課題として認識していないものは振り返りに上がらないのが悩みです (hayase)

- チームの現在の目標と、達成しようとしていること

- チームが直面している現在のペインポイント

- ほかのチームが支援できる可能性のある領域

この3点に、他のチームが支援できる可能性のある領域があるのがいい。助けてもらえるだけじゃなくて、他のチームを仲間として見続けることにもつながりそう。(98lerr)

ペインの厳密さもひとそれぞれ。「想定と違ったこと」とか。

ここで重要なのは、このセッションは、各チームが作業を交換したり、追加のタスクを渡したりするためのものではないということです。このセッションは、気付きを与えることだけを目的としています。もしチームがお互いに助け合うために仕事を引き受けることにしたら、それはすばらしいことです！　しかし、このミーティングが情報提供のみを目的としていることは、前もって伝えておくべきです。

その理由は簡単です。誰も自分に割り当てられる仕事が増えるようなミーティングには参加したくないからです。

もう「ミーティング参加」にこの先入観がめいっぱいついてるので、事前にも、会の頭にもこの話はしておきたい。(98lerr)

別の時間をくむ計画がないと、話してるだけで何のため？になる

ほとんどのチームはすでにキャパシティぎりぎりで活動しており、仕事のバックログが残っています。いかなる新しい仕事も、チームが通常の仕事を受け入れるやり方で受け入れる必要があります。

みんな帯域外で小さな仕事をねじこもうとしてくるので、とても大事。(hayase)

でも、ほんとうに小さな仕事だったら、その場でぱっとやってしまったほうが早い

これを使うかはともかく、こういう対話支援のツール類は面白い。オンラインになって、会話相手固定されがちというのがたびたび課題に挙がるので。(98lerr)

11.4.2　シニアエンジニアへのこだわり

私の経験では、企業はシニアエンジニアを採用しようと躍起になっています。採用できるのであれば、経験豊富な人に来てもらって、入社初日から価値を発揮してもらいたいと考えています。シニアエンジニアへの需要は高いです。

ここのシニアではないけれど、定年した人を「再雇用」として話すのがいつまで続くかは気になる。個人差はあるけれど、これもエンタープライズ企業で優秀な人を逃がしてる一つだと思ってます。(98lerr)

11.4.2.1　経験年数の記述を捨てる

経験年数が活きるときもありますが、履歴書ベースだと「未経験かどうか」くらいの情報にしかならないと捉えた方がいいことが多いと思ってます。(98lerr)

11.4.2.2　ジュニアエンジニアの採用

またジュニアエンジニアを採用することは、シニアエンジニアがメンターとなる機会にもなります。これによって、シニアスタッフに管理職に就くよう強いることなく、責任の範囲を広げることができます。

ジュニアの下にジュニアをつけて、もと居たジュニアに脱ジュニアの気持ちを持ってもらう、っていうのもチームの成長に大事だと思ってます。(98lerr)

+1 (hayase)

職務上の必要性を満たす技術やスキルに集中的に触れている成長が早いタイプの候補者を獲得することに時間を費やしましょう。

似たことを強く感しています。スキルリストより、技術に対する態度とか、様々な種類の問題にどう立ち向かってきたかのほうが大事だと。(hayase)

11.4.3　候補者との面接

11.4.3.1　パネル面接

複数人いるのが、面接者に複数のポジションの視点を得てもらうためというのが、面接の在り方の前提としても大事そう。採用者側だけの視点に寄り過ぎない。(98lerr)

現実には、ポジションが決まった前提だったり、各ポジション/チームの人ではなくそれらを束ねる立場の人が出たりするイメージは強い。(98lerr)

単純に，面接担当者の人数が多いな……と感じました．過去、自分が受けた面接でも、4人も出てくる面接はほとんどなかったので。(hayase)

新卒の最終面接とかこういう感じありますが、ちょっと違いそうですね。みんなでGo/No Go というより、誰がとりたいって話をしている。

「面接後の部署」という話だけでなく、その後の異動とかふまえていろいろ知れるのよさそう。

11.4.3.2　面接での質問の構成

私は、技術的な面を重視して採用し、組織やチームとの適合性を十分に考慮しなかった結果、そのようなことが起こるのを実際に見てきました。その結果、チームに癌のように蔓延し、チーム全体の士気が低下し、チームの勢いが阻害されてしまいました。

「こわいな」と思うのだけど、経験や実感をともなっていないので、具体的なエピソードを知りたい(hayase)

ピンポイントの技術の入れ方は、採用以外もある

契約で話した方が、その技術の話をしたい側も、技術を取り込みたい側にも win-win かも

11.4.3.3　情熱を見極める

情熱を持っているかどうかは、言葉で説明するものではなく、行動に表れるものです。候補者が何かに情熱を持っていると言ったら、その情熱がどういった行動に表れているかを尋ねてみてください。

ここの引き出し方、気になります。得意な技術を話してそうだったら「その技術の好きなところは？」と聞いてみるの、結構その人の考え方が出てきて好きです。(98lerr)

プライベートで勉強の時間を取れていません……(hayase)

11.4.3.4　面接における技術的な質問

声に出して問題を考えるように候補者を促しましょう。真っ白なホワイトボードの前で大声で話している候補者からは、黙って解決策を書いている場合よりも多くを学ぶことができます。その解決策は候補者が自然と思い浮かんだものか？　以前にこの問題を解決したことがあるか？　なぜそのような答えを選んだのか？　エンジニアが自分の中で考えをまとめるのを聞くことで、彼らの経験を知ることができます。

面接の話ではないですが「思考プロセスを声に出そう」という話の講演を社内で視聴会したら好評でした。(98lerr)

11.4.4　候補者の評価

面接官が全員そろったら、同時に候補者を採用したいのか、したくないのかを明らかにしましょう。

いったん、必ずどちらかに投票するのは良いなと思いました。(hayase)

11.4.5　何人の候補者と面接をするか？

チームは、DevOps文化を構築するための重要な構成要素です。しかし採用は常に努力が必要です。

この文脈とは違いますが、チームを分解して、ひとりを抜いて別の場所に入れるという話もあります。これ、しばらくはどんどん出来上がったチームを台無しにしている感ありましたが、数年たって組織としてより良いチームを作ろうという動きにつながったのを見て、チームの解散とか、のれん分けとかも効果的だなと感じてるところです。(98lerr)

人は辞めたり、昇進したり、成長したり、ほかのことに興味を持ったりします。現在チームにいる誰であっても、いつかはその人がいなくなる時が来ます。

先週末 Google Cloud の Kelsey Hightowerさんの講演動画を見ていて「自動化は理解の副産物」と言っていたのが印象的でした。人はいなくなる前提で、運用の自動化は人の理解を残すものにしたい。(98lerr)

いいはなし (hayase)

理解を遺す場所が難しそう……？

ADR をリポジトリ内に置く

ADRとして残す、

「最初に自動化を前提にすると、方法に走りがち」

11.5　本章のまとめ

みんなからのコメント

実践する/伝えるためのハードルはなにか？

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

どれくらい効果がありそうか？