DevOps部の本棚
devops は、情報のサイロを壊し、関係を観察し、 チーム間で発生する語会を解消するための反復的な取り組みを強調する プロフェッショナルで文化的な運動だ（本書 p.xv）。
こうはいいながらも、本書は、devops の厳格な定義を提供するものではない —そもそも devops の実践に唯一無二の方法などないからだ。 本書が devops ジャーニーという言葉を用いていることからも（p.xvi）、 組織改革には自分たちで道を探していく覚悟が必要なことがわかる。 本書は、そんな気概をもつ人々のよい指針となるだろう。
効果的な devops の4本柱として、本書は以下のトピックに着目している:
本書が他の「devops 本」と異なるのは、人間的側面について真っ向から議論しているところ。 対象読者は経営者・管理職・リーダーのようなので、下っ端はさっさと読み終えて、上司に勧めよう。
週の大半をともに過ごすことになる同僚との間のコラボレーションについて考えてみよう—カギは対話、教育、支援だ。
仕事をすすめていく上で、技術的判断をせまられる場面がある。 メンバー間で意見が対立することもあるだろうが、これをチームとしてうまく解決していくことは立派なコラボレーションだ。 そのやり方次第で、共同体は強くもなれば、弱くもなる。
パフォーマンスが高いチームには、次の三つの特徴があることがわかっている:
このうち心の理論とは、考え方の違う他者を尊重すること。 相互理解を築き、対立を解決にみちびくために必要な能力だ。
メンバーの多様性が高いほど、チームは強くなる。 しかし、多様性は短期的には対立を生むことがある。 人びとの多様性を理解するうえで重要な事項を見てみよう。
対立をうまく解決するには、ともに仕事をする人びとについて、プロとしての経歴だけでなく、個人としての経歴も理解することが必要だ。 長時間労働や勤務時間外のイベントなどを当然のこととしてしまうと、 家庭の事情で参加できないメンバーが肩身の狭さを感じてしまう。 無意識の偏見は、いたるところに生じうる。これは誰もが自覚すべきことだ。
チームはもちろん目標を共有しているが、実は職業人としての目標は人によって違う。 次のキャリアのための重要な仕事と考えているかもしれないし、生活の手段として割り切っているかもしれない。 一人でもくもくと作業するのが好きな人もいれば、共同作業が好きな人もいる。
認知スタイルの違いが対立をもたらすこともある。 認知スタイルは色々な軸があり、とても全ては列挙できないが、例を挙げれば次のようなものだ:
—要はいろんな人がいるということ。
企業が業界で繁栄しつづけるためには、社員に資金とリソースを投入する必要がある。
かならずしも上位から下位へ、というわけではない。 |メンタリングの種類|特徴|おすすめ度 |–|–|– |上位から下位へ|上位者に十分なコミュニケーションスキルがあるならば機能する|△ |上位者どうし|知識を深く共有できる可能性はあるが、新たな視点は得られない|△ |下位から上位へ|あらゆる人から学ぶことの重要性を皆が認識するきっかけになる|○ |下位者どうし|指導者がいない場合、学習効果が上がらないこともある|△
人は成長できる。このことを理解していれば、困難な状況においてもよい振る舞いをできるようになる。
人や組織は成長できるという健全なマインドセットは、企業全体の利益になる。
固定思考に特有の悪い考え方は、「だめなやつは何をやってもだめ」と言うものだ。 この考え方が自分に向くと、挑戦から逃げるようになり、成長が止まってしまう。
成長思考で仕事に取り組めば、困難な状況はレベルアップの機会になる。 失敗を恐れずリスクを取れば、大きく成長刷ることができる。
ここまでは、個人レベルの成長の話だが、 チームレベルでの成長に必要なものを見ていこう。
組織として成長思考を採用することで、つよい組織を作ることができる
フィードバックの仕方を工夫すれば、受け取り手を成長思考に向かわせることができる。 資質を褒めるのではなく、努力の結果として褒めるようにすれば、受け取り手を固定思考から開放し、さらなる成長を促すことができる。
評価は、組織のためでなく、社員のためにやるべきだ。
小さく、頻繁なフィードバックが効果的なのは、なんにでも言える。 宇宙船の軌道修正、カラオケの音程、数当てゲーム—仕事の目標への到達にも、同じ力学が働いている。
相対評価システムなんてものは、つよい組織づくりにとってはむしろ害だ。 スタートアップ企業では、評価システム自体がないところもある。 ただし、評価とフィードバックは違う。 目標達成の課程におけるまめなフィードバックは、社員が効果的に働くことの助けとなるだろう。
生産的なチームを作りたいときに、スーパーマンばかりを集めるのは短絡的な方法だ。 長期的には、多様性に富んだメンバーを集め、連携スキルを磨くほうが、チームの生産性は向上する。
チームに必要なのは、なによりも信頼関係だ。 信頼関係の構築には時間がかかるが、皆で協力して育てていかねばならない。 いくら個人での生産性が高かろうと、チームの信頼関係に悪影響を与える「スーパースター」には、行動を改めてもらわねばならない。
摩擦や対立を解決し、合意に達するために注意すべきことがら。 権力関係などのコンテキストも考慮する必要がある
コミュニケーションの方法にはいろいろあるが、TPOをわきまえることが必要だ。
電子メール、会議、チャット、書籍…コミュニケーションの手段はさまざまだが、それぞれ特性がある:
交渉や対立を解決するスタイルにも色々ある。 悪い方法の典型例は次の4つだ:
devopsチームを名乗るなら、コラボレーション・協調・協力によって解決しよう。
コンテキスト次第で、コミュニケーションは違った意味を持つ。 チャットシステム上で、ジョークと障害情報が入り乱れている状況は好ましくない。 チャネル機能をうまく使って交通整理しよう。 リモートワークのメンバーがいるときにはコミュニケーションの機会が平等に与えられているか、注意を払おう。
発言内容が同じであっても、権力関係次第でコミュニケーションは平等でなくなることがある。 権力関係という言葉の意味するところは、肩書きのようにわかりやすいものから、性別、人種、性的嗜好のように微妙なものまで幅広いことに注意しよう。
円滑なコミュニケーションには、信頼や共感が不可欠だ。
共感力は、大人になってからも育てることができる。 話を聞き、質問し、他者の視点を想像し、個人的な違いを尊重すること。 相手の言葉を反芻したり、言い換えたりするアクティブリスニングも効果的だ。 質問も、相手への興味を示し、共感を育てるよい手段だ。 いずれにせよ、相手の気持ちを考えた振る舞いが大切だ。
信頼関係のないチームには、単一障害点ができてしまう。 信頼を築くための方法にはいくつかある:
ソフトウェア業界全体がブラックだったころ、運用の人々は、24時間365日いつでも仕事に対応できて当然と考えられていた。 継続的インテグレーションやInfrastructure as Code などの概念によって、彼らの仕事はかなり楽になったが、それでもまだ、健全な労働環境の実現のためには、注意を払うべきポイントは多い。
時間外労働には、手当や振替休日などによる十分な補償が必要だ。
時間外労働が必要な状況はあるかもしれないが、それに対応できるかどうかは、社員の家庭環境や健康状態によって差が出る。 これが無意識の偏見につながることは、認識しておくべきだ。 多様性なメンバーからなる組織を健全に運営するには、時間外労働が生じないように組織として配慮する必要がある。
常時応答可能な体制をつくるには、人手が多い大企業が有利だ。 世界各地に支店を持つ大企業なら、太陽を追いかけるようにシフトを組むだけで、かんたんに地球全体で24時間体制をつくることかできる。 人手が足りない中小企業でも、当直にはできるだけ多くの人を配備し、相互に体力回復の機会を与えることが必要だ。
さて、本章の冒頭で不穏な空気を醸していたミーティングはその後どうなったか。 実は、Sparkle Corpは、devops文化が浸透した企業だった。 対立意見のどちらか一方を採用する材料が足りなかったため、リーダーは、対立意見を出した二人にチームを組ませ、協力して調査をすすめるよう命じた。 またリーダーは、本件に関して意見を言っていないメンバーがいることにも気づいていたので、メールでも引き続き意見を受け付ける旨を付け加えて、会議を解散した。 会議の場でタイムリーに言えない内向的なメンバーへの配慮である。
devopsは技術を重視した概念ではない。 もともとの目標は、2つの異なるチームに属する人たちを対話させること、つまりコミュニケーションだった。 本章からもわかるように、devopsが重視するのは、組織全体として連携することだ。
優れたリーダーとは、周りにいる全ての人たちから最良のものを引き出せることである (p.91)
チームとして人間を集めて仕事を行うとき、さまざまな問題が発生する。本章では問題を引き起こす誤解と、解決方法について紹介する。
チームが成長していくにつれて、コラボレーションをめぐる問題が発生する。それらは、偏見や短期的な視野などから引き起こされる誤解であることが多い。
個人間の問題に対処するのは確かに難しい。対立や難問を乗り越えることは、devopsという考えを生み出す要素のひとつであった。(p.93)
燃え尽きには注意しよう。社内の肉体的な健康と精神的な健康はどちらも重要だ。燃え尽きは本人だけの問題ではない。作業環境に問題がある兆候でもある(p.95)
社員と別の道を歩む必要があるなら、それは否定的なことではない。しかし、パフォーマンスを理由にポジションから外すのであれば、その前に長期間のトレーニングや改善計画を与える必要がある。
社員と会社の価値や目標のずれが一致していない場合、対話などを行い、「ずれ」を確認する必要がある。会社の方向性の変化を受け入れられない場合、良い条件で早い時期に辞められるようにするほうが、問題を抱えるより良い。
自分の健康を犠牲にするほどの価値があるプロジェクト、仕事、企業など存在しない(p.96)
仕事の疲労からくる燃え尽きは、自然には治癒しないため、長短期的な対策を用いて行動をおこす必要がある。周りの人たちの間で働きすぎが話題になるようなら、より広い範囲での対策が必要となる。
特定のツールに対して頻繁にストレスを感じる場合、そのツールを使うワークフローを改善できないか、他のものに変えられないかを考えた方がよいかもしれない。組織の外にアイデアを求めれば大幅に改善できる可能性があることを頭に入れておくとよい。
多様性のある職場でも、チーム内で軽く見られている人たちが出てきてしまうことがある。
模範的な行動をトップダウンで示し、ハラスメントなどの問題に対してのトレーニングや教育を推奨・義務化する必要がある。ハラスメントの解決は以下の事に貢献する。
非難文化はチーム内の信頼を欠如させ、コミュニケーション不足につながる。また、他者を尊重しない人間がいると、組織文化とのずれが生まれてしまう。
多国籍・多様性のあるチームでは、文化の違いがコミュニケーションに影響を及ぼすことがある。チーム内でコミュニケーション文化のコンセンサスを得ることで大きな効果が生まれる。
優秀さがマイナス効果を補って余りあるようなエンジニアが存在する場合、問題行動について考える必要がある。
多くの場合、上記のような人物の採用は技術的・文化的・評判の面でチーム・企業のためにならならい。
同質的な人間を優遇してしまう、上司が業績に気づいてくれない、という環境ではキャリアの前進について不安を覚えてしまうだろう。その際に以下の2制度が効果的だ。
自らが気づいていなかった自身の問題点がある場合も考慮すべきである。成熟したエンジニアであれば、内省と自分に対する率直な評価が大事だ。
どのように状況を改善するかは、直接の上司からどれくらい支援してもらえるかによって変わる(p.101)
企業の成長や再編などにより、自分の意見が聞き取られにくくなることがある。
ライフサイクルの後退局面では、組織再編や人員整理（リストラ）が行われることもある。その場合、以下の事について考えてみることが効果的だ。
最終的にはどこでなぜ働くかを意識的に選択する必要がある。（高給）だけを目的にすると、ストレスが溜まって健康を害するという代償を払うことになる(p.103)
すべてのチームや組織がすべての人に合うとは限らない。devopsや自分が大事と思う事を受け入れてくれる、自分に合った新しい場所を見つけることがベストという場合もあることを忘れてはならない。
… devops にはほんとうの意味での終わりはない。継続的で反復的なプロセスである—p.325
切り花のブーケを買ってきてもガーデニングにはならないように、 単純に「devopsソリューション」と称するツールを買ってきても devops にはならない—p.325
@book{davis2018-effective-devops,
title = {Effective DevOps---4本柱による持続可能な組織文化の育て方},
author = {Davis, Jennifer and Daniels, Ryn},
translator = {吉羽, 龍太郎 and 長尾, 高弘},
supervisor = {吉羽, 龍太郎},
year = 2018,
language = {Japanese},
publisher = {オライリー・ジャパン},
location = {Tokyo},
url = {https://www.oreilly.co.jp/books/9784873118352/},
isbn = {9784873118352},
}