チームにSlack（ゆとり）が必要な理由
強いチームになるために
私がウイングアーク に入ってこの会社のすごいなと思うところに、
- 問題が発生したときの結束力
- 対応の早さ
があります。特にお客様環境で不具合が発生したときは部門間の連携、原因調査、お客様へのご報告、不具合の修正、再リリースと怒涛のスピードです。お客様にとても真剣に向き合っているなと感じます。社員からは「問題が発生したときの対応の早さがお客様からの信頼に繋がっている」という声も聞きます。
我々ウイングアークの Core Value は次のようなものです。
Build the Trust: 相⼿の期待を超える結果を出し、信頼される。
私は、この Core Value に従い、お客様の期待をもっと超えるためには
問題そのものを出さない
ことが、重要だと思うのです。
問題を出さないようにする価値
問題が発生すると、調査・対応に注力することになります。対象プロダクトに関わったエンジニアが新しいプロジェクトに従事している場合は、「緊急の割り込み」として扱われ、少なからずプロジェクトの進捗を妨げる要因となります。
また、お客様の環境で発生した不具合の改修コストは、開発工程で発見された場合のコストに比べ数十倍とも言われています（下図参照）。
ビジネス面からみても、市場で発見された不具合の改修コストは大きな問題です。なぜなら、ご購入頂いて確定していたはずの「利益」が改修コストによってマイナスになるからです。
そのため、問題対応による信頼構築よりも、高品質で問題のない製品をお客様に利用していただくことで信頼を築きたいと思いました。
そのためのヒントがSlack（ゆとり）です。
Slack（ゆとり）とは
現代においてSlackと聞くとビジネスチャットツールを思い出す人がほとんどだとおもいます。しかし、このチャットツール誕生以前、2001年にTom DeMarcoは「Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency（邦題：ゆとりの法則）」という本を発表しています。ベテランのソフトウェアエンジニアほど、Slackと聞いてこの本を思い出すひとが多いのではないでしょうか。
冒頭でTom DeMarcoは次のようなことを書いています。
企業が現在の事業を変える必要が生じたとしよう。この変化とは、同じことをもっと速くやるのではなく、方向を変えたり、まったく新しいなにかをする必要があるということだ（中略）加速はできるが方向を変えられない組織は、アクセルはあるがハンドルのない自動車のようなものだ。短期的にはたまたま向かった方向へぐんぐん進める。長期的にみれば道路脇に突っ込む車がまた1台増えるだけだ。
つまりハンドルを手に入れるためにはSlack（ゆとり）を取り戻す必要があり、Slack（ゆとり）を上手に使える組織は変化にも強いと説いているのです。
では、貴重なSlack（ゆとり）を取り戻すにはどうすれば良いのでしょうか？
Slackを取り戻せ！
ウイングアークのプロダクトは定期的（3ヶ月〜1年毎）にバージョンアップを行いますが、こういったソフトウェアをチーム開発する場合、仕事はつぎの3つに区分出来ます。
- 機能開発: 新製品開発や保守開発
- 緊急対応: お客様Q&A対応、不具合対応、案件対応
- 予防と改善: 問題を起こりにくくするための予防施策や、品質改善やプロセス改善
皆さんはこの3つの区分のそれぞれにどのぐらいの時間を割り当てられているでしょうか？
「機能開発」は、普段の仕事生活の大半を費やしていると思います。「緊急対応」はいつ発生するか予測しにくいものの、発生してしまうと、要件が解決するまで時間を費やしてしまうと思います。こういった仕事はある意味わかりやすく、意識出来ていることと思います。
さて、皆さんの開発現場では3番目の「予防と改善」に時間を割り当てることが出来ていますか？この時間割り当て比率は、私が冒頭で書いた「問題そのものを出さない」という状態を作るための重要な要素と考えています。そして、ここに時間を割り当てるにはSlack（ゆとり）がなければなりません。
それぞれの時間割り当ては
- ［機能開発：緊急対応：予防と改善］＝［6:2:2］
が理想的です。しかし、現実は
- ［機能開発：緊急対応：予防と改善］＝［7:2:1］
- ［機能開発：緊急対応：予防と改善］＝［7:3:0］
といったプロジェクトが多そうだなと感じています。
プロジェクトへの要求は盛りだくさんで、お客様からの問い合わせもたくさんあって、そんな状況では「予防と改善」の取り組み優先順位は下がりがちです。なぜならば、緊急ではないからです。
これを有名な「アイゼンハワーボックス」とか「時間管理のマトリックス」と呼ばれるフレームワークで考えてみましょう。すると「予防と改善」は「緊急でない」が「重要」な価値ある活動と言えます。
人は「Ⅰ．必須領域」や「Ⅲ．錯覚領域」の緊急な事案ばかりしていると燃え尽き、疲れ果てます。そんな状態で「Ⅱ．価値領域」の活動に着手できません。
「７つの習慣」の Stephen Richards Coveyは、タイム・マネジメントについて次のように説いてます。
時間管理の本質は、優先事項を決め、それらを中心に計画を立て、実行することである。優先事項を決めるにはまず、自分の価値観や最大の関心事を深く探り、明確にしなければならない。その価値観と関心事をもとに短・長期の目標と計画を立て、さらにスケジュールあるいは時間配分を決める。
つまり、タイム・マネジメントの基本として「Ⅱ．価値領域」は計画しないと実現することはできないということです。
チームで無駄を排除し価値に取り組む
「Ⅱ．価値領域」に取り組むためには、まずは定期的に（強制的に）チームで立ち止まることが必要です。緊急で重要なものをたくさん抱えているチームは、
「全員で立ち止まるのは時間の無駄、その間に少しでも開発を進めたい」
と思いがちです。このマインドを変えないと「Ⅰ．必須領域」と「Ⅲ．錯覚領域」のループから抜け出すことができません。そこで、特にプロジェクトの終わりと始まりでは立ち止まりチームで現状認識をすることが大事だと思います。Slack（ゆとり）がないプロジェクトでは、1つのプロジェクトが終わると、なし崩し的に次のプロジェクトが始まりがちですが、立ち止まることでこれを回避できます。
具体的には、
- プロジェクトの終わり:
今回のプロジェクトをふりかえって、次のプロジェクトでどうにかしたい重要なことが何か、それを実現するために必要なアクションが何かを話しあいます。これが「Ⅱ．価値領域」のアクションです。 - プロジェクトの始まり:
プロジェクトの終わりで考えた「Ⅱ．価値領域」のアクションをプロジェクト計画に盛り込みます。
そうすることで、プロジェクトにSlack（ゆとり）が取り戻せます！
Slackの先に
Tom DeMarco は、Slack（ゆとり）の効用として、次のことも挙げています。
・組織が敏速になる。
・「人的資本」ともいうべき重要な人材を維持できる。
・未来に投資できるようになる。
・リスク回避ではなく、賢明なリスク選択ができるようになる。
チームにSlack（ゆとり）が出来ると対話が増えます。メンバー間の対話が増える事により相互理解が進みチーム力の向上へとつながります。
「予防と改善」に時間を割くことで製品の品質が改善され、「緊急対応」 が徐々に減ります。プロジェクト関係者も製品を利用するお客様もみんなハッピーなサイクルです。
はじめからこのような理想の形にすることは難しいですが、理想と現実を知り、そのギャップを埋める改善活動をコツコツ続けること大事なのだと思います。
最後はDwight David Eisenhowerの、この言葉で締めたいとおもいます。
「重要なことは滅多に緊急ではなく、緊急なことは滅多に重要ではない」
では、また近々お目にかかりましょう。ごきげんよう😏
