ホエールテック株式会社 ホエールテック株式会社

  • ブログ

「いざというときは信頼してくれていい」

システムにトラブルが起きたとき、私たちは「誰のせいか」ではなく「なぜ起きたか」を考えます。

人を責めても再発は防げず、システムとしての信頼性は向上しません。責めるべきは人ではなく、仕組みなのです。

けれど、コミュニケーションにおいてはどうでしょう。「あの人の性格だから」「私のコミュ力不足だから」と、個人の問題にすり替わってしまうことはないでしょうか。

そのような場面に遭遇したとき、本当は現場に「アラート」が鳴り響いているのに、原因調査がされないまま放置されているような、そんなもどかしさを感じることがあります。

そんな折、一冊の本に出会いました。ジル・チャン著『静かな人の戦略書』です。 内向型やHSPの気質について書かれた本なのですが、読み進めるうちに「これはまさに開発現場の話ではないか?」と思うようになりました。

「情報共有のミスが致命的な事故を招く」

「誰かの善意で回っている組織はいつか破綻する」

といった、具体的でシビアな事例が並んでいたからです。

信頼は「好かれること」ではない

たとえば、NASAの宇宙飛行士たちが宇宙でのミッションに就く場合、文化や教育背景もさまざまな彼らは、言葉を介さなくても、しっかりとした関係と理解で結ばれ、強い信頼にもとづいて、短期間で任務を遂行する必要がある。

2011年、国際宇宙ステーション(ISS)のチームは、非常に難易度の高いミッションに取り組むことになった。 無重力環境において、不安定な動きでこちらへ向かってくる補給船を、機械のアームを操作して捕まえなければならないのだ。

このミッションはきわめて困難と思われた。

しかし、ミッションに就く前に互いのことを知り合う時間はほとんどなかった。 さらに興味深いことに、メンバーのなかにロシア人の司令官がいて、彼は「宇宙に女の居場所はない」と固く信じていた。

ところが、なんと彼のチームに、女性宇宙飛行士が1名配属されたのだ!

NASAのチームの訓練を担当した、ウィルダネス・トレーニング(過酷な環境での訓練)およびリーダーシップの専門家、ジョン・キャネンジーターは、お互いにつぎのような心構えで任務に当たってほしい、と強調した。

「私のことは好きじゃないかもしれないが、いざというときは信頼してくれていい」

11 日後、ともに死に直面する可能性がある宇宙飛行士たちは、全員のストレス反応を把握していた。

互いに好き嫌いはあったかもしれないが、どのような状況で、誰が先導的な役割を担えるかなど、互いに知り合うことができた。

例の生死にかかわるミッションは、ロシア人の司令官と女性宇宙飛行士が協力し合うことで成功した。 司令官はのちにつぎのように語っている。

「やがて、ケイディーがアームを動かし始めた。じつになめらかで見事な操縦で、いともたやすく狙い通りに動かした! 彼女はやってのけた」

職場において、信頼はしばしば「人間関係の良さ」や「好感度」と混同されがちです。
しかし、『静かな人の戦略書』が示す極限状態のチームの事例は、真の信頼が「好き嫌い」とは別物であることを教えてくれます。

「私のことは好きじゃないかもしれないが、いざというときは信頼してくれていい」

この言葉は、馴れ合いではないプロフェッショナルな信頼のあり方を象徴してるように思います。

本著の読者のような「静かな人」は、場を盛り上げることは得意ではないかもしれません。
しかし、状況を正確に把握し、無理な点を見逃さず、必要な情報を整理して共有するという誠実な行動を積み重ねることはできます。

「好かれる努力」ではなく、「予測可能な行動」を積み重ねること。
それが、人が自分を削ることなく、静かなままで周囲から頼られ、成果を出し続けるための、最も現実的で強固な戦略であるというのが本著の主題なのだと感じました。

こうした合意がある組織は個人の犠牲に頼ることなく、健全に仕事を前に進めることができます。ロシア人の司令官と女性宇宙飛行士が協力し合うことで成功したように。

優しさが問題解決を遠ざけることがある

『静かな人の戦略書』第8章では、協調性が高く、衝突を極端に避けようとするアリスという人物の事例が紹介されています。

アリスは金融業界でアシスタント・マネジャーを務め、「波風を立てないこと」を最優先に行動していました。

その姿勢は一見、組織にとって望ましいものに見えます。

あるとき、他部門の担当者がアリスの指示を誤解したことにより、顧客への「二重請求」という重大なミスが発生します。

関係者が集まった会議の場で、アリスは責められる担当者を不憫に思い、「自分の伝え方が不明確だったのかもしれない」と、相手をかばう発言をしてしまいます。

彼女自身は、事態を丸く収めたつもりでした。
しかしその行動は、結果として問題をさらに悪化させることになります。

会議室を出て、これで一件落着、と肩の荷を下ろしたアリスは、安堵のため息をついた。

だからそのあと、上司のオフィスに呼び出され、大目玉を喰らったのは、まったくの不意打ちだった。

「明らかに向こうの落ち度じゃないか! 君がやるべきことは、彼にちゃんと責任を取らせることだったんだぞ。いったい何を考えてるんだ? なぜ向こうをかばって自分が責任を取ろうとする? そんなことをやってると、君はいずれもっと深刻な窮地に陥ることになる。部署全体の責任につながることだぞ!」

アリスはショックを受けた。自分なりにうまく事を収めたつもりだったのに、まさか上司がこれほど激怒するなんて。彼女は心のなかでつぶやいた。

「ああ、ちっとも丸くなんて収まらなかった。上司の前で完全に失敗してしまった。部内のほかの人たちにだって、よく思われていないし。でも、しょうがない。笑って耐えるしかない」

二重請求は、
業務フローの欠陥を示すクリティカルなアラートになるはずでした。
しかし彼女の「配慮」によって、アラートは握りつぶされ、恒久対応は行われませんでした。

問題は単なる「コミュニケーションミス」へと矮小化されてしまったのです。

人を守るということ

この場面で、アリスを強く諭した上司は
冷淡な人物だったのでしょうか。

私はそうではないと考えています。

彼は感情に深く踏み込むのではなく、
「なぜ構造的な欠陥が見過ごされてしまったのか」
「同じ状況が繰り返されないか」
「次に誰かが同じ場所でミスをして消耗しないか」
という点を見ていたように読み取れます。

これらは感情を直接癒すものではありませんので、冷たく見えるのかもしれません。
しかしそれは、同じ痛みを二度と起こさないための判断でもあります。

私自身も過去に、何度も事を荒立てないようにと考え、ミスをした人をかばった経験があります。
アリスの事例を読んだとき、胸が締め付けられるような思いがしました。

感情への共感は、その場の緊張を和らげますが、構造に手を入れなければ、問題は形を変えて再発し、未来の誰かを傷つけることがあります。今はただ、見えないだけで。

個人の善意と、組織の責任

アリスの事例は、「個人の優しさ(相手をかばうこと)」が、ときに組織の問題解決能力を奪ってしまうことを示しています。

重要なのは、アリスが間違ったことをしようとしたわけではない、という点です。
彼女は善意に基づいて行動しました。
(だからこそ、この問題は見過ごされやすく、厄介でもあるのですが)

IT業界には「技術的負債」という言葉があります。

本来はきちんと設計・実装すべきところを、
「今回は急いでいるから」「とりあえず動いているから」と後回しにした結果、
あとから必ず保守・障害・属人化という形で利息付きで返ってくるという意味です。

問題になるのは、それが「負債である」という認識すら持たれないまま、静かに積み上がっていく場合です。

職場における「善意」も、これとよく似ています。

・誰かが無理をして肩代わりする
・波風を立てないために問題を小さく見せる
・気合と責任感で、その場を乗り切る

これらは短期的にはシステムを“動かしている”ように見えます。
しかし実態は、構造的な欠陥を覆い隠す無茶なオペレーションです。

そしてその負債は、いつか必ず別の誰かの障害対応として返ってきます。
当事者ではない人の「夜間対応」という形で。

これから私たちが目指したいこと

幸いなことに、私たちホエールテックには「事実を事実として受け止める土壌」がすでに備わっています。

障害対応の現場で「誰のせいか」ではなく「なぜ起きたか」を真っ先に問う文化。

不都合なアラートを隠さず、フラットに共有できる空気。

これらはまさに、「予測可能性としての信頼」の第一歩です。

「気合い」や「社交性」で場を凌ぐのではなく、冷静な現状把握から解決策を探るというスタンスは、すでに私たちの強みになっています。

一方で、私たちがよりよくするために意識していきたいのは、「個人の善意」に頼らない組織づくりです。

誰かが無理をして肩代わりすることで、かろうじて回っているフローが存在してはいないか。「波風を立てたくない」という配慮が、本質的なシステムの改善を遅らせてはいないか。目指すべきは、アリスのような心優しい「静かな人」が、自分の身を削ってまで周囲をかばう必要のない環境です。ミスが起きたとき、トラブルが起きたとき、仕組みの側が強く、優しくある状態。そんな「構造的な安心感」を、ホエールテックとして考え、設計していきたいです。

sinz
sinz
寄り添うプロジェクトマネージャー
開発の進捗や課題の管理、協力業者との関係構築を努めプロジェクトを推進して参ります。
オフショア開発では開発ベンダとの調整役を担当することが多いです。
要件定義などの上流工程と、テスト計画の作成やテストケースの設計、実施、結果の分析など、テストライフサイクル全体にわたる業務を担当することもあります。
大きくて強そうな古生物が好き。
採用情報
お問い合わせ