コネヒト開発者ブログ

コネヒト開発者ブログ

アンチフラジャイルなチームを目指して

Merry Christmas
最後のプレゼント（記事）をお届け！

はじめに

本記事はコネヒト Advent Calendar 2017の25日目、つまり、最後のエントリーになります。

メリークリスマス！そして、宮崎あおいさんご結婚おめでとうございます！サーバーサイドエンジニアの @itosho です。

ここまで続いてきたアドベントカレンダーもいよいよフィナーレということで、今日は来年の抱負というかこれからのことを書いてみたいと思います。 あんまり技術的な話は出てこないと思いますが、1mmでも誰かに刺さるといいなぁ…と願いながら書きます。

2018年版僕が考える理想のチーム

僕は昔から個人ではなくチームが成長するために何をするべきか、もしくは組織の中で各人が有機的にワークするにはどうすればいいかを考えたり、実践したりするのが好きなのですが、ここ最近、気に入っているキーワードのひとつに「アンチフラジャイル」という言葉があります。

アンチフラジャイルとは？

ご存知の方もいるかもしれませんが、最初にアンチフラジャイルという言葉の意味について簡単に説明させていただきます。

そもそも、アンチフラジャイルという言葉自体は技術用語ではなく、著書『ブラック・スワン』で有名なNassim Talebさんが考えた造語です。日本では『反脆弱性』というタイトルで書籍が出版されており、分野としては行動経済学に位置づけられているのですが、他の分野でも有効な考えとして広く注目を集めており、ソフトウェアの世界では、特にマイクロサービスやDevOpsの文脈で使われることが多いようです。

また、アンチフラジャイルを理解するためには、まず、フラジャイル・ロバスト・レジリエンスという言葉を知っておく必要があります。

フラジャイル / Fragile

フラジャイルとは、一回の大きな変化で大きな損を生み出すものとして定義されています。 例えば、杜撰な計画をしたウォーターフォール型の開発は、一度大きなトラブルがあると、大きな手戻り（＝損）が発生してしまうため、フラジャイルであると言えるでしょう。

そう言えば、Every Little Thingさんの歌にも同じタイトル（発音が違うけど）の曲があると思いますが、だいたいそんな感じです。

ロバスト / Robust

ロバストとは、フラジャイルの逆で、大きな変化を受けても、大きな損を出さないものとして定義されています。 先程の例で言うと、しっかりと計画を練られたウォーターフォール型の開発はロバストであると言えます。また、職業で言うと、サラリーマンはフラジャイルで医者はロバストに分類されるようです。 ただし、ロバストの欠点として、想定していない突発的な事態には対処出来ないことが挙げられます。

レジリエンス / Resilience

レジリエンスとは、ロバストを更に発展させた考えで、変化に強く、回復力が高いという意味を持ちます。 開発モデルで言うと、アジャイル開発はまさにレジリエンス的な考えを反映したものだと思います。 また、突発的な事態が発生しても、被害を最小限に留められるようにすることもレジリエンス的な考えで、具体的にはサーキットブレイカーの仕組みやBCP対策などがこれに当たります。

アンチフラジャイル / Antifragile

そして、お待たせしましたアンチフラジャイルの登場です。アンチフラジャイルの特徴を一言で言うと、アンチフラジャイルは変化に対して、損ではなく利益を生みます。

これまではレジリエンスなシステムであることが良いとされてきましたが、アンチフラジャイルは更にそれを推し進めたのが考えになります。 例えば、これまでは「障害をどう防ぐか」について腐心してきた方が多いと思いますが、「障害は起きる」という前提で動くのが、アンチフラジャイルの基本的な考えになります。

Netflixではいち早くこの概念を導入して、本番環境でわざと障害を起こしたり、Chaos Engineeringの原則を導入したりすることで、変化や障害に対処出来る強いシステムを作り上げることに成功にしています。

失敗から学ぶ、という表現では陳腐過ぎるとは思いますが、アンチフラジャイルは失敗を重ねることで、より強くなっていくものであり、この考え方はソフトウェア工学やアーキテクチャ論に留まらず、もっと会社や組織、チームマネジメント的な分野にも応用出来るのはではないかと僕は考えています。*1

強いチームをつくるために

例えば、チームの成長を止めない方法の一つとして、離職率を下げることが挙げられます。これは当然と言えば当然で、チームが成長するには経験や学び（ラーニング）の蓄積が必要だからです。*2

また、チームは一朝一夕には強くならないので、それを向上させるには小さな成功体験を積み重ねる必要があります。そうすることで、チーム力は徐々に強化されていきます。 加えて、各人が組織として有機的に動けるようするために開発プロセスやフローなどのルールを整備することも大切でしょう。

でも、世界は不確実だ

では、本当にそれだけで良いのでしょうか？

もちろん、離職率を下げることは会社としてとても大切なことですし、一度成功した起業家がそうではない起業家よりも次に成功する確率が高い*3というデータがあるように、成功体験を得ることは重要です。 また、組織が急速に大きくなっていくフェーズでは、大なり小なりルールを整備しないと日々の業務が破綻する可能性があります。

しかし、どうしたって、離職者を0にすることは出来ません。*4 幸いにも、現状コネヒトの離職率はかなり低い状態ですが、1年後どうなっているかは分かりません。もしかしたら、iOSエンジニアがある日突然、全員無人島に行ってしまうかもしれません。そうなって欲しくはないですが、その可能性は0ではありません。その時、これまで通り次の日から業務を続けることが出来るでしょうか？

業界にパラダイムシフトが起きて、これまでの常識が通用しなくなった時、今までの成功体験は本当に役に立つのでしょうか？ どんなにルールを整備しても、いずれルールは破られます。何故なら、ルールは破られるために存在するからです。*5 また、ルールの中に生きていると、ルール外のことが起きた時に対処出来なくなったり、ルールの外側にある変化に気付きにくくなったりしてしまう危険性もあります。

目まぐるしく変化するこの不確実な世界で闘うためには従来のレジリエンス的な考え方だけではなく、アンチフラジャイルな考え方をチームに取り入れていくことが、この先を生きのびるためのひとつの方法なのではないかと僕は思います。

僕たちはアンチフラジャイルになれるのか？

とは言え、アンチフラジャイルなチームになることは容易ではありません。 アンチフラジャイルなチームになるためには、前提としてレジリエンスなチームでなければなりませんし、そもそも、レジリエンスなチームに辿り着くにも相当な努力が必要です。

しかし、諦めたらそこで試合終了です。

少しでもアンチフラジャイルに近づくために、最近、僕が意識していることは以下の3つです。

  • 職能・職域に囚われない
  • 小さな失敗を繰り返して成長する
  • ルールなしで自走出来るようにする

言葉にしてみると、至極当たり前のことばかりかもしれませんが、いきなりスーパーマンにはなれないので、まずは自分に出来ることから地道にはじめていくしかないのかなと思っています。

今回参考にさせていただいたアンチフラジャイルの世界という記事の中にアンチフラジャイルのメタファーとして、ドラゴンボールのサイヤ人が登場するのですが、個人的に秀逸な例えだと思っていて、スーパーサイヤ人が集まったチームが出来たら…と想像するだけでわくわくします…！

繰り返しになりますが、アンチフラジャイルなチームをつくることは容易ではありません。しかし、アンチフラジャイルなチームになろうすること、少なくともその態度を示すことがアンチフラジャイルへ繋がる第一歩なのだと僕は考えています。

おわりに

ここまでお付き合いいただきありがとうございました。

長文を書き散らした挙句、結論めいたものもなく恐縮ですが、来年はここに書いたことを意識しながら、サービスをもっと大きく出来るよう、より一層頑張っていく所存でございます。 とは言え、頑張り続けるにはエネルギーが必要なので、素敵なメンバーとわいわい働くことでエネルギーをもらいながら、愉しく頑張っていければ最高ですし、その頑張った成果をまた来年のアドベントカレンダーで報告出来ればもっと最高だなと思っています。

それではよいお年を！

参考文献 / サイト

めっちゃたくさんお世話になりました。

おまけ

www.youtube.com

*1:そもそも、最初にこの概念を利用したと言われる元NetflixのAriel Tseitlinさんもアンチフラジャイルな組織というタイトルの記事を書いています。

*2:ラーニングの蓄積の重要性については、伊藤直也さんの開発組織マネジメントのコツに要点がまとめられています。

*3:DHHさんがいることで有名な37signals（現Basecamp）の書籍である『小さなチーム、大きな仕事――働き方の新スタンダード』の 「失敗から学ぶこと」は過大評価されている の章より引用

*4:出来ることと言えば、せめてネガティブな理由でなくポジティブな理由で去って行くことくらいでしょうか…。

*5:これは極論かもしれませんが、そういう側面もあるかと思います。