ヌーラボさんと共同でやってたEffective DevOps読書会、やっと読了した

ゆっくりゆっくりと弊社とヌーラボさんで続けていた、Effecitve DevOps読書会がやっと読了しました。

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

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

本当に長かった...いつ読み始めたのか忘れるくらいに長かった。 最初の読書会の記録を見返したところ、2018/6/15でした... 1年以上かけて1冊の本を読み切りました。

まず、これまでに読書会に参加していただいた皆様に感謝を申し上げます。 僕にとっては学びの多い会を最後まで続けられたのは、参加していただいた皆様の協力のおかげです。 本当にありがとうございました。

今のタイミングで、この読書会の経緯とこの会から学んだものを、僕の視点から整理してみます。

読書会を始めるきっかけ

たしか、読書会を始める数ヶ月前からEffective DevOps読みたいなーと個人的に考えてたと思います。 チームビルディングについて悩んでたのもあったし、「組織の文化」というものが何なのか、 何を重視したらいいのかとか、どうしたらいいのかもわからなかったし、そういうことへの解答が あるんじゃないかと期待していました。

それで2018年の5月くらいに、品質管理のリーダーとして福田さんが入社して、福田さんと今後の会社の方向性について話し合ったときに、「すぐに効果を出す目的じゃなくて 長期的に見ていい方向に会社を持っていくときに役立つ知識を学びませんか。ぼくはその知見が Effective DevOpsっていう本に書いてるんじゃないかと思ってます」みたいなアプローチをして、 Effective DevOpsを一緒に読んでいくことにした、んだったと思います。

せっかく2人で読むなら他の人も誘いましょうか、ということで社内チャットで呼びかけをして、 読書会が始まりました。

f:id:kmdsbng:20190713094939p:plain
最初の読書会開催の記録

初期

初期はもの珍しさも手伝って、まあまあ参加者が集まりました。 「DevOpsっていうタイトルからは想像できないけど技術者以外の人にとっても役に立つ」 みたいな誘い方をして、事務や営業の人にも参加してもらいました。

読書会を始めた頃に、興味を持ってもらおうと思ってまとめたDevOpsとは何かっていう箇条書き。 これを書いた頃は、組織の文化って何？みたいな感じだった。

最初の方は結構飛ばしながら読んでいて、記録を見返すと1ヶ月くらいで半分くらい読んでた。超速い！

進め方は模索しながら進めていて、その中でペースが早すぎてあまり理解できてない、というフィードバックが あって、じゃあ1センテンスだけ読んだら感想をみんなで語り合うようにしよう、みたいなやり方に変えたのが 大きな変換点だったと思います。ちょっとずつ読み進めるように変えたところ、いくつかいいところが ありました。

  • 言葉の意味や、書いてる内容がわからない点についての質問がいっぱい出てくるようになった。
  • 自分の経験や気付きなどが語られるようになった。

これらの点は、僕にとってはすごく貴重なフィードバックだ、と感じました。 みんなが考えてること、不安に思ってること、懸念してることを、 書いてる内容ごとのテーマで表明してもらえるようになったので、これは効率性を犠牲にしたとしても ぜひ得たい情報だ、そこでお互いに情報交換することが、DevOpsにとって重要な「自分たちのことを知る」ことに 向かっていくのですごく質の高い学習だと感じました。

参加者に聞いてみても好感触だったので、以降はこのスローペースでずっと読み続けました。 Effective DevOpsっていう本が、こういう読み方に向いていたなーとも思います。 みんなでワイワイと俺はこう思う、僕はこうだ、と情報を交換し合うことで理解が進む本だった、と感じています。

ヌーラボさんを誘う

半分くらいまで社内で読み進めたあたりで、組織間の交流についての話が出てきて、 他の会社の人を読書会に誘うのはどうだろう、というアイデアが出てきました。 他社の参加者もいたほうが、フィードバックにより広がりが出るんじゃないか、という 期待もあってぜひ実現したかったのですが、前に弊社に務めていてヌーラボに 転職された中伏木さん経由でヌーラボさんに話を通していただき、リモートでの 読書会が実現することになりました。ヌーラボさん、本当にありがとうございました！

新しく参加される人も増えるので、その時点でまた最初から読み直すことにしました。 事例ごとにみんなの感想を聞くのが有益だとみんなが感じてたので、最初から読み直して 新しい感想が聞けるならいいんじゃないか、とということになりました。

ヌーラボさんからも興味を持った方に参加いただけて、フィードバックの幅がぐっと広がりました。 会社がちがうと抱えてる問題や文化も違って、自分たちの無意識の前提にも数多く気づくことができました。

時間も毎日 12:00から30分というルールにして運用していきました。

2018年8月から年末くらいまで

このころから、読書会ができない日が多くなりました。 初期はたまたま僕が時間が取れてる日が多かったのですが、このころ時間があまり取れないことが続いて、参加者もあまり集まらず、休会が多くなりました。

この時期は読書会の進め方について悩んでた時期で、僕が会に時間を割けないせいで、読書会というコミュニティのエネルギーが損なわれてるのではないか、と感じていました。

がんばって時間を割くようにテコ入れしようかと思ったこともあったのですが、結局は「休みが多くても良い」というポリシーにすることに決めました。

その理由は、この本で学習しているDevOpsというものが、ずっと続けられる文化を目指すものだというのが一つでした。 継続可能な体勢を作るための学習が、誰かのがんばりに依存するようなものであってはうまくいかないはずです。 であれば、目指すべきは無理をして短期間で終わらせることではなく、自分たちのペースでずっと学び続けることだ。 なので休むことに罪悪感や引け目を感じることなく、堂々と「今日は参加できない」と言えるようにしようと思いました。

f:id:kmdsbng:20190713131220p:plain
堂々と不参加表明する(堂々と...?)

また、この頃読んでた箇所に学習時間についての考え方のヒントがあって、学習時間を遊び(作業として割り当てない時間)として設定し、 緊急作業が入ったときにはこれを消費するのが良い、ということが書かれてました。 これを読んで、僕らの読書会は学習のための遊びの時間とみなして、作業が入ったらそちらに時間を割り当てるのは 問題ないよね、ということをメンバーで共有して、会の開催形式についても会自体で調節していきました。

2019年以降

あいかわらず休みは多かったですが、特にそれは問題ではないと考えて運用を続けました。 他に参加者がいないときは一人で読み進めることも考えたこともありましたが、それは採用しませんでした。 この本については知識をえることよりも、それぞれのテーマについて参加者のフィードバックを得ることこそが 有益だと考えていたので、ゆっくりとみんなで学習することを楽しもう、と思って一人で先に読むことはがまんしました。

あせらず、自分が楽しいと思える状況を維持することに気を付けて続けました。 自分が面白いと感じることは、きっと他にも面白いと思う人はいるはずだし、そこを損なわないことに気をつければ この活動は続けられる。そう自分に言い聞かせつづけました。

そんな感じで読み進めてきた結果、ペースを保ったまま、なんとかこの分厚い本を読了することができました。

学んだこと

いろいろと学んだことは多かったのですが、今思いつく範囲でこういうことを話したよなー、ということをせっかくなのでいくつか書いていきます。

組織の文化とは何か

組織の文化というのは、組織が内外について伝えたり、メンバーが実際に行動によって作られる価値観やみんなが信じること。

主に文化について語られるのは組織の健全性について話すときで、メンバーが安全と感じているか、そうでないかというのが重要な観点になる。 メンバーが安全と感じていれば、リスクを取って行動しようと考えるようになるし、安全でないと考えていれば、自分の身を守ろうと行動するようになる。

リスクを取ることを組織が奨励しているか、それが口だけでなく実際の行動でもリスクを取ったことを責めないようになってるか、という点が心理的安全性に影響を与える。

あとは何が重要かをはっきりさせていることも文化を作るのに重要。

それがないと、みんななにが目標で仕事しているのかわからないまま仕事することになる。 そんな状況はまずいだろ、と感じるかもしれないが、そういう組織は結構ある。

固定思考と成長思考

固定思考は「人の能力は生まれつき決まったもので、行動によって変わらない」と信じること。 成長思考は、人の能力は後天的に獲得できると考えること。能力の獲得だけじゃなくて、自分の無意識の前提に気づくことができれば、行動も変えられる、と考える。

この本では固定思考は悪で、成長思考が良いという考え方を取っている。 固定思考なんているのか、と最初にこれを読んだときは思ったが、相手が固定思考か成長思考か どちらを信じているんだろいうと意識して話をするようになると、結構人は変わらないという前提で 話している人は多いんだなーと今は感じている。

失敗は悪、と考えてしまうのも固定思考で、成長するなら失敗するでしょ、と考えるのが成長思考。 失敗はまずいこと、と考えてしまうのはどっちかというと自然な心の動きのような気もするので、人間はデフォルトで固定思考なのかもと思う。 仕様を最初にバシッと決めたらあとはそれを実装さえすればいい製品ができる、という考え方も固定思考の結果だと思う。

開発初期には自分たちは開発後期に比べて十分な知識がないはずなので、その時点の設計は間違っている可能性が高い、そう想定して開発することでリスクを減らせると考えるのが成長思考的だと思う。

今まで失敗したことがない人のほうが固定思考になる傾向があるらしい。

成長思考の考え方からすると、固定思考から成長思考に変わることも可能と考えるが、自分の中での気付きが得られないと、変われないので、なかなか難しいだろうなあとも思います。

人を成長させるために必要なこと

直接本に書いてあったことか覚えてないんだけど、読書会を通じて得た考え。

人が成長するには、自分のボトルネックになってる無意識の前提に気づき、自発的に自分の行動を変える必要がある。 とするなら他人を成長させるにはどうすればよいかというと、自分の考えを相手に押し付けるのではなく、相手が気づきを得ることを手伝うのが有効なはず。 そのためには相手の考えを聞き、それに共感し、事実に関してフィードバックするのが大事。 回答になることを的確に相手に伝える必要はないし、それをすると逆に気付きが得られず、行動の変化につながらないことも多い。

例えば相手の心配に思ってることなどを聞く。まずはそれについて共感する。「そっかー、それは大変だね」「それはよかったね」と言ってあげるべきだ。

それについての解答を最初に与えようとしてはいけない。まず聞き、共感する。それで相手は考えの整理が進む。 次に事実についてフィードバックする。「間違ったSQLを実行してしまったために、そのリカバリーに半日かかったね」など。 「そもそもなんで間違ったSQLであることに気づかなかったんだろう」というように、一緒に原因追求や、よりあるべきだった未来について考えてあげたりする。

その中で、ボトルネックがどこにあるかを共有できて、それが自分の行動によって改善できる、と相手が気づけば、行動は変わるかもしれない。

読書会を終えて

定期的に学習時間を作って、ゆっくりとでも無理なく学習をつづけられたのは本当に良かったと感じています。 同時に、もっとみんなに価値を感じてもらえる学習の仕組みを作っていきたいなあとも思ってます。 無理なく、面白く、という両立は難しいだろうと思いますが、継続的に実験していきたいです。

この本から学んだことを、実際のチームビルディングにも生かすことができました。調整役として最近まで参加していたプロジェクトで、各メンバーが懸念点を表明できる環境を保つことができたのですが、それにはこの本からの知見が活かせたと感じてます。

また、最後まで一緒に読書会をつづけて頂いたヌーラボの中伏木さんから、これで終わらせるのはもったいないから 何か別の本を読みませんか、という提案もいただけました。

大変嬉しい申し出だし、僕以外の誰かに価値のある場と思ってもらえたこともすごく嬉しいです。 次に何をやるかは決まってないんですが、みんなが興味を持てることをつづけられるといいなあと考えてます。

読書会の感想など