こんにちは。WESEEK代表の武井です。
新年度が始まり、いろんな場所で新しい試み、そして新しい顔ぶれが見られる季節になりました。WESEEK でもこの春入社した社員やインターン生たちが、今日も活発にコミュニケーションをとりながら、新しい仕事にチャレンジしています。
こちらは実は WESEEK 社花扱いの紫陽花
時として人は、慣れない仕事で失敗をすることがあります。いや、慣れていても、大なり小なり失敗は避けて通れないもの。
失敗って怖いですよね。できれば一度も失敗しないでいたいけれどそういうわけにはいかない。いつか来る、「自分が原因を作ってしまった失敗」。。
今日はそんな避けては通れない「失敗」に対する WESEEK 流の考え方を、新たな環境に身を置く人たち、それから彼らを見守る周りの人達に紹介したいと思います。
Contents
現実で起こりそうな失敗を具体的に想像してみよう
WESEEK のエントリーを読んでくれている人にはエンジニアが多いのではないかと思っているので、エンジニアが直面する失敗というものを考えてみよう。例えば以下のような失敗をしたとする。「自分が失敗の当事者だったパターン」「失敗したのが自分の部下だったパターン」で、どういう行動を取るべきか考えてみてほしい。
特に三つ目なんかは絶対体験したくない失敗だよね。。
これらが不幸にも起こってしまったとして、それに対してどういう行動をとるべきだろうか？
当事者だったらどうしよう。
何を反省すべきか、早いとこ上司やお客さんに謝罪すべきか？
あるいは部下にどうあたればいいだろうか。
注意や叱責をした方がいいだろうか？
やるべきことはまず「失敗の切り分け」
失敗が判明してすぐの時点では、上で書いたような謝罪、断罪、叱責などはまだやる必要はない。なぜなら「失敗の切り分け」が済んでないから。
反省に関しても、初期段階は飽くまでも切り分けを助ける「振り返り」的な反省をすべきで、後悔を伴う反省はまだ早い。
失敗の切り分け 実践シミュレーション
フローチャート
失敗の切り分けとは？
まずはこちらのフローチャートをご覧いただきたい。
ちなみにこれは WESEEK で特に規範としているようなものではなく、武井が自分の頭の中で処理しているフローを今回のエントリーを書くにあたって可視化しただけです。失敗へのアプローチを確立できていない人は「こういう考えの人もいるんだな」と思ってもらって、しばらく使ってみるのもいいかもしれない。
さて、このチャートを使おうとすると、さっき挙げた失敗例は情報が足りなすぎることがわかる。そう、切り分けのためには失敗の背景をもっとよく知る必要がある。逆に言えば、失敗したという事実だけで次の自分の言動を決めてはいけない。
切り分けが終わるまで頑なに罪を認めるな」ということではない。誤りを認める潔さや素直さは必要だし、切り分けは後にして顧客満足のために迅速な行動をとることも重要である。「とりあえず謝っとく」みたいなのが日本人としてコミュニケーションを円滑化するのも否定はしない。
背景・経緯の把握
失敗したら(あるいは失敗の報告を受け取ったら)、背景を知る必要がある。関係者にヒアリングを行い、経緯を追って整理してみよう。
先ほど挙げたケースが、たとえばこんなストーリーだったとしたらどうだろう。読みながらフローチャートを追って、自分なりの切り分けをしてみてほしい。
Case2. 受託開発で実装した機能を使ってみたらパフォーマンス(処理速度)が芳しくない
お客さんからいただいた機能要件である、「入力した期間で絞りこんだ時系列グラフを表示する」は無事完成し、納品日2週間前には使い勝手のレビューも終えた。ステージング環境にて、本番と同等の機器・データ量で行ったパフォーマンス試験では、レスポンスはとても高速ということもなかったが、UX 的に許容できる範囲と言うことで本番ローンチを迎えた。ところが実際ユーザーからのアクセスを受け付けてみると、絞り込み期間を最長にしたアクセスが多数発生すると、レスポンス表示まで実用には耐えられない待ち時間が発生することがわかった。データストアのスケールアウト・スケールアップを検討したが工数やランニングコストの面で不利だったため、止むなく選択可能な絞り込み期間を短くする仕様変更を決定した。
Case3. 本番環境のデータを吹き飛ばしてしまった
本番環境でサーバーからアラートが上がりレスポンス遅延が発生、ユーザーに影響が出ている事態となった。その日は祝日だったが運良く運用チームのエンジニアの一人がそれに気づき原因を探ったところ、昨日アップグレードされたアプリケーションのバグで、あるテーブルのレコード数が膨れあがるという事象が発生していた。エンジニアはマニュアル通りシステムを緊急メンテナンスモードにいれ、まずはアプリケーションを以前のバージョンにロールバックした。次いでデータベース中の対象データを削除するオペレーションを行ったが、ここでオペレーションミスにより想定外のデータまで削除されてしまった。この事象を想定したマニュアルは存在しなかった。
切り分けで生まれる感覚の考察
フローチャートに当てはめて、自分なりに考察できただろうか？
フローチャート中には「負け」という概念がある。どこが勝ち負けの分岐点だったのか？このストーリーに対する見解は細かいところでは十人十色だとは思うので、それを決めるのはむずかしい。しかしストーリーが進むに従って徐々に敗色が濃厚になってくる感覚は持ってもらえたと思う。つまり初めから負けが決まっていたわけではなく、勝ち負けを左右するチェックポイントがいくつかあり、そこをくぐって負けが込んでくる中でいわゆる「負け確」になるタイミングがどこかに存在した。
切り分けた後にやること
「負けのパターン」を分類するとしたらこんな感じだろうか。
- やる前から負けている
- 計画時点で穴がある、認識齟齬など
- 一番もったいない
- 途中で気付くのが遅すぎた
- 負けの要素になると認識していたのに、それに十分な時間を割けなかった
- リカバリーできなかったなど
- PS(プレイヤースキル)で負けた
- 十分準備をして挑んだがそれでも負けたならそれはしょうがないかもしれない
失敗の現場に関わった時は上のような切り分けを行い、その見解をチームで共有するという作業をやると良いと思う。そして、ここまできてようやくそれがポジティブなのかネガティブなのか、誰にとってよりネガティブなのか、謝罪をすべきかどうかをチーム共通の見解として持つ事が可能になってくる。
!!DANGER!! 気をつけること
ここで、僕が個人的に気をつけているポイントを紹介する。
失敗と断罪・叱責の関係
断罪と叱責の扱いについての持論を書くと、
「君のこれは失敗だったことを認識せよ」
「原因はこれで、それは君のせいだ」
このような言葉は、言う方も聞かされる方も辛いものがある。ただ上司が失敗した部下を叱責するのは教育の一貫でもあるし、それが本人の成長に繋がるなら必要なものには違いない。問題はどういうときにそれを言わなければならないか？で、失敗という結果を伴ったら必ず言わなければならないかというとそうではないと思う。たとえば本人が原因を把握し十分に反省している場合などは叱責が必要ない場合が多い。追い打ちをかけるような断罪はチームのメンタリティを悪くするので気をつけないといけない。逆に責任があるはずの人に自覚がない場合は、良薬として苦みを与えないといつまでも良くならない。
一方で「失敗はゼロにはできないのだから気にするな」という人もいるが、いつもいつもそのスタンスでいるようだと上司の責務を放棄していると思う。個人の能力が足りないことを詰るのはナンセンスだが、「今回の結果は組織にとってこれだけダメージだった」という認識は今後のためにあえて再確認しなければならないこともある。
そう考えると、「叱る」という行為はとても難しい。でも時には悪者になってでもやらないといけない時がある。
切り分けは、周りとペースを合わせよう
もう一つ気をつけていることは、「切り分けと指摘を早くやり過ぎないこと」。
あまり自慢になることではないが、僕はいろんなものの粗を探したり重箱の隅を突くのを得意とするあまり、何か失敗が起きたときにどこが負けに繋がったのかを他の人より早く探し出し、それを口に出してしまうことが多い。自分としては早く切り替え、早く改善に着手して貢献しようというマインドでやっているのだが、あまり早すぎると当事者もまだ噛み砕いていないのに「ここがだめだったんだよ」と言われて反感を持ってしまうということがある。
反省には納得感がないと次の結束に繋がらない。切り分けを急ぎすぎず、なるべく周りと歩調を合わせて咀嚼していく意識は大事にしたい。
WESEEK 代表からのメッセージ
失敗は誰にでも起こるし、運が悪いときには失敗が重なってメンタルをやられることもある。そんなときでも忘れて欲しくないことが3つある。
- 全ての失敗を「悪いもの」「忌み嫌うべきもの」だと思わないこと
- 切り分けをして、失敗に正面から向き合うこと
- 切り分けをせず結果だけを記憶していると、単に「○○さんが失敗した」「○○さんに失敗されて大変だった」という辛い思い出だけが残る
- 失敗した側は指摘してきた人のことを苦手になってしまう
- 失敗をフォローした側も失敗した人のことを嫌いになってしまうかも
- 細かく切り分けることで、失敗の中でどこを改善すればよかったのか、どれぐらい反省すべきなのかがはっきりする
失敗した人へ
多くの場合、失敗には「負け」が伴う。その事実を受け入れよう。
「これは勝ちに等しいはずなのに」とか「負けだと思いたくない」という感情は、プロとしての目を曇らせ、失敗から学べる機会を遠ざける。真摯に向き合おう。
叱る側の人へ
失敗という結果に対して怒っても響かない。過去は変えられないから。
失敗の原因をその人がどう認識しているかにフォーカスして、必要であれば怒ろう。未来は変えられる。
叱られた人へ
WESEEK は「どういうときに誰が怒るべきなのか(または怒ってはいけないのか)」を、比較的よく話し合っている組織だと思う。
叱る選択をしたその人をどうか信頼して、気付いていなかったポイントに目を向けよう。
負けに打ちのめされた人へ
「ダレル・ロイヤルの手紙」というものがある。
以下は1960年代、テキサス大のアメリカンフットボール部のコーチだったダレル・ロイヤルが、選手たちに送った手紙の全文。
親愛なるロングホーン諸君
(訳注: 「ロングホーン」は、テキサス大学アメフト部の愛称)
打ち負かされること自体は、何ら恥ずべきことではない。打ちまかされたまま、立ちあがろうともせずにいることが、恥ずべきことなのである。
ここに、数多く人生での敗北を喫しながらも、それから立ち直る勇気を持ち続けた、偉大なる男の歴史を紹介しよう。
1832年 失業
1832年 州議選に落選
1833年 事業倒産
1834年 州議会議員に当選
1835年 婚約者死亡
1836年 神経衰弱罹病
1838年 州議会議長落選
1845年 下院議員指名投票で敗北
1846年 下院議員当選
1848年 下院議員再選ならず
1849年 国土庁調査官を拒否される
1854年 上院議員落選
1856年 副大統領指名投票で敗退
1858年 上院議員、再度落選
そして1860年、アブラハム・リンカーンは、米国大統領に選出された。
諸君も三軍でシーズンを迎え、六軍に落ちることがあるかもしれない。或いは一軍で始まり、四軍で終わるかもしれない。
諸君が常に自問自答すべきことは、打ちのめされた後、自分は何をしようとしているのか、ということである。
不平をこぼし情けなく思うだけか、それとも闘志を燃やし再び立ち向かっていくのかということである。
今秋、フィールドでプレーする諸君等の誰もが、必ず一度や二度の屈辱を味あわされるだろう。
打ちのめされたことがない選手など、かつて存在したことはない。
ただ一流の選手はあらゆる努力をはらって速やかに立ち上がろうと努める。並みの選手は立ち上がるのが少しばかり遅い、
そして敗者はいつまでもグラウンドに横たわったままである。
ダレル・ロイヤル僕はこれを漫画「アイシールド21」で知ったのだが、スポーツ選手に限らず人を奮い立たせてくれるいい手紙だと思った。
時間がかかってもいい。誰かを頼ってもいい。
何度倒れても、しかし必ず立ち上がり、次のチャレンジに向かう、その意思を持つことが大事だと思う。
負けに打ちのめされた人に対して周囲がすべきこと
きっと立ち上がることを信じ、本人がその意思を持つのを待とう。
無理矢理立ち上がらせても本人のためにはならない。骨折した人を治療中に自立させるのではなく、リハビリが始まった時に松葉杖になろう。
まとめ
かく言う僕にも、人に言いたくない思い出したくもない失敗がたくさんあります。でもその度に周りの人達に助けられてきた。だから、自分の失敗を嘲笑せず一緒に残念がってくれる人、励ましてくれる人、怒ってくれる人、そういう人がいる環境はとても重要だと思っています。
「失敗を糧にして」という言葉は、言うは易く行うは難しですが、まず失敗しないと「難しかったなあ」という感想も言えません。怖がり過ぎず失敗を経験しましょう。そして無事立ち上がることができた暁にはもちろん、次は自分がその役割を担ってください。失敗を取り巻く良い環境の保全を一緒にやりましょう。
他の【代表が語る】をご覧になりたい方は、
からご覧ください。