どうすれば組織で心地よく生きれるのか『Effective DevOps ―4本柱による持続可能な組織文化の育て方』を読んだ

DevOpsというワードを聞くときにいつも「DevOpsツール」という、CI/CDツールの話ばかりしているように思える。
だが、DevOpsは便利ツールであるというのは、枝葉のひとつでしかない。

仕事に対する個人の考え方を変え、仕事の多様性を尊重し、ビジネスが価値を実現するスピードを加速させる意識的なプロセスを支援し、社会的および技術的変化の効果を計測しようとしている。
DevOpsは思考の方法であり、仕事の方法である。
個人と組織が持続可能な作業習慣を生み出し、維持していくことを可能にするためのものだ。

今でいうところの働き方改革というワードの考え方に対してのひとつと考えても読める。
この本に書いていることはエンジニアに限った話ではないなと思えることが結構あった。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

個人の考え方という点でいうと、ミスした人が非難されて懲罰を受けるという環境は明解なコミュニケーションや透明性を阻むので、やるべきではない。

求められるのは、ミスした時に人が非難されるのではなく、失敗する何か原因（盲目的に守られている手順など）があるだろうシステムのもっと深いところにある問題としてとらえるかということ。

確かに、能力があってもミスはするし、失敗してしまうのは残業時間が多かったり、手順書などの不備などがある。
起こった問題を新しい学習機会、ヒューマンエラーをスタート地点とみて、どうしたらこの問題が突破できるのかをちゃんと共有されることによって、全体の意識が変わっていく。

• チーム内の透明性が増し、チーム内に信頼が生まれる
• 実際にダメージの大きいミスをする前に、それを防ぐ方法を同僚に伝えられる
• 新しい問題の解決に使える時間が増え、イノベーションが促進される

互いの信頼や、理解を求める人たちあろうというのがDevOpsで、それが構成されるチームがDevOps共同体となる。

結局DevOpsとは人に優しく、お互い（いろいろな職種や生活を超えて）に協力・協調しながら、仕事していこうということだと思う。
それだけどだと、当たり前なことを言っているわけだが、実際のところは仕事での立場や、その人が社会人になったときの当時の文化性などで変わっていく。

ドラマ『わたし、定時で帰ります。』であった、新人と就職氷河期の人間のすれ違いをDevOpsとしてはナンセンスとしている。
とはいえ実際問題、そういう話は文化として当人の知らぬ間に当たり前になっているので、意識の差は発生してしまう。

www.tbs.co.jp

nlab.itmedia.co.jp

DevOpsのアンチパターン

非難文化

ミスが発生したときに、個人レベルでも組織レベルでも、人を非難し処罰しようとする傾向のこと。犯人探し。

俺も遭遇したことがあるし、俺が新人だった時にテストの証跡取りは犯人探しが発生した際の対抗手段と聞いた。このマインドがそもそも非難文化を知らず知らずのうちに生んでいた。

非難されるのは誰だって嫌なので、ミスしないような動きがメインとなる。
そんな状態でみんな協力しようとか言われても、いやいやといってもミスったらディスって来るんでしょ？って言われて意に介してくれない。

サイロ

サイロとは

• 同じ企業のほかのチームと知識を共有する気がないチームの空気を表している。
• サイロ化されたチームでは、目的や責任を共有せず、それぞれバラバラの役割を重視する。
• これに非難文化が結び付くと、自分の安定のための情報の抱え込みが起きる。

これはつまり自分のことしか考えない状況だと思っていて、チームや組織だけじゃなくて個人でもこのマインドになってしまうよなと。
自分の安定、自身の席を譲らないために情報をシャットアウトしてしまう考え。仕事をしていてちょいちょいいる人だと思う。
あなたが、仕事を辞めず永遠にその席に座り続ける気でいるのなら、それでいいのかもしれないけど……。

周りの人は結構困る考え方で、他の人が苦労しているのに傍観してる、嫌な奴だったりする。

DevOpsの４本柱

コラボレーション

コラボレーションは、複数で対話したり、教え合ったりすることを大切にしながら、特定の結果に向かってものを作っていくプロセスである。

人間いろいろなバックボーンを持っている人がいるし、技術力だって違う。その違いを尊重しようという考え方。
そのいろいろな人の中で、共通のビジョンや目標も設けてそれに突き進んでいくのが共感や信頼を築くために必要。
じゃあ共感ってどうするのかっていうと、「話を聞く」、「質問する」、「他者の視点を想像する」、「個人的な違いを尊重する」の4点。

俺はあまり人の話を聞かず自分の意見を言う傾向があるので、以下は意識したい。
自分を落ち着けて強いて話に耳を傾けるように仕向け、相手が話し終わるのを待って、自分の返事を考えるようにしよう。
アクティブリスニングも優れたスキルだ。他の人が言ったばかりのことを反芻し、言い換えたり要約したりすることで、聞いて理解したことをがその人の意図にあっていることを確認するのだ。
こうすうと両者が同じ土俵に立って同じテーマについて話せるようになる。

信頼を育てるためには、「迅速な信頼」、「自己開示」、「信頼しつつ確認」、「公平と感じる環境」の４点が必要らしい。
迅速な信頼とは、最初から他人を信頼することが前提で、時間とともにその信頼が確かであったことを答え合わせする状況。

アフィニティ

個人の協力関係を育てて維持するに加えて、組織のチームや部門や業界全体でも関係の強さが必要になる。
アフィニティとは、チーム間の関係を構築し、組織の共通目標を念頭に置いて個々のチーム目標の違いを乗り越え、共感を育て、他のチームの人たちからも学習するプロセスである。

ツール

DevOpsを加速させるためのツール

エンジニアなので、outputはソースだったり製品だったりする。
開発、リリース、デプロイのリスクを低下させることができれば、もっとDevOpsを有効にすることができること。これが主軸ではない。
それが、リソースのバージョン管理だったり、テスト駆動開発だったり、継続的インテグレーション（CI）だったり、継続的デリバリー（CD）だったり継続的デプロイだったりする。

スケーリング

スケーリングは、組織がライフサイクル全体で導入しなければいけないプロセスや軸に重点を置いている。
スケーリングでは、単に大企業でDevOpsに取り組む意味を考えるだけでは不十分だ。
組織の成長や成熟、縮小にあわせてほかの柱をどう適用すればよいのかも考える。

要は組織やチームが巨大化等スケールする場合に考えるべきことということ。

どうやれば社員が定着するのかっていうのもスケーリングの要素のひとつ。
報酬だったり、ワークライフバランスだったり、有給休暇だったり。ここが日本で言われている働き方改革の要素なんだろうなと思う。

燃え尽き問題

読んでいて一番気になった個所といえばこの問題。
俺もちょいちょいあるんだけど、仕事の不安感や極度の疲労、自分自身に対する満足度の低下などから燃え尽きる、バーンアウトしてしまうことがある。
もう何もしたくない。自分を守る（下手したらサイロ化）してしまう行動を多くとってしまう。

短期的な対策としては

• 仕事関係のメールやチャットを見ない時間を確保する
• 事後とを人に任せたり、断ったりする
• プロの助けを借りる。精神的な健康は、肉体的な健康と同じくらい重要である

長期的な対策としては

• 個人の責任について、そこからくるストレスを軽減するためにできることを考える
• 燃え尽きかかっているときには、全体的なストレスや不快感といった形の兆候が出ている場合がある。自分で思っている以上にストレスや不安の大きな要因がないかどうかを考えてみるとよい

いい意味で自分の持ち物を整理して、自分でなくてもできるものは相手にお任せる考えが必要ということ。
そのためにはコラボレーションの「迅速な信頼」でこの人は信頼すると最初から決めてしまわないと、信頼できるかわかんねえしで自分の荷物でつぶれてしまう。
俺も自分の荷物を誰かに譲らない性格なので、誰かを信じるということが大切。
じゃないと、「仕事を辞めず永遠にその席に座り続ける気でいるのなら、それでいいのかもしれないけど……。」な感じになる。循環が必要。