「具体的に、どの部分が事前に合意した要求から外れているのでしょうか」
後輩への批判が続いていた会議で、私はできるだけ静かに質問しました。すると、それまで怒号が飛び交っていた会議室が、急に静かになったのです。
『Dr.STONE』第6話を見て思い出したのは、トラブルの最中に自分とチームを守ってくれた、事実の記録、戻れる場所、人とのつながりでした。
この記事を読むと、感情的な会議で何を確認すべきか、AI開発でどこに撤退ラインを置くべきか、離れた仲間との関係をどう仕組みに変えるかが分かります。トラブルを完全に避ける方法ではありませんが、崩れかけたときに何を残しておけば立て直しやすいのか、その判断材料になれば幸いです。
感情的な会議で自分と後輩を守った
怒号より先に確認したこと
新しい部署へ異動して間もない頃、私は後輩と二人で、新規機器の仕様をまとめる仕事を任されました。
仕様書は数百ページに及びます。確認しても修正箇所が出てきて、提出直前まで作業が続きました。期限日の早朝、ほかの社員が出社する前に配布を終えたときは、達成感よりも先に体の力が抜けたのを覚えています。
ところが翌日、ソフト開発部門の部長から猛烈なクレームが入りました。
「要求水準に達していない」
「この内容では作れるわけがない」
すぐに関係部門の部長を集めた会議が開かれましたが、具体的にどこが問題なのかという話より先に、仕様担当だった後輩への非難が始まりました。
後輩は反論できず、ただ耐えています。腹は立ちました。ただ、こちらまで感情的になれば、会議は誰が悪いかを争うだけの場になってしまいます。
そこで思い出したのが、仕様書を作る前に開発メンバーと行った打ち合わせでした。要求する精度や記載範囲については、事前に確認し、合意したうえで作成しています。
私は批判していた部長へ、こう尋ねました。
「この仕様の精度については、開発メンバーと事前に調整し、合意を得たうえで作成しています。具体的に、どの部分が要求から外れているのでしょうか」
強く反論したわけではありません。怒りをぶつけるのではなく、確認できる事実だけを机の上に置くような気持ちでした。
すると部長は一瞬言葉に詰まり、会議室の勢いも急に弱くなりました。
記録が責任の押しつけを止めた
どうやら、開発部門内で情報が十分に共有されていなかったようです。結局、仕様書に重大な問題があるという話にはならず、プロジェクトは予定どおり進みました。
派手な逆転ではありません。ただ、事前の合意や打ち合わせの記録がなければ、結果は違っていたかもしれません。
声が大きい人の主張が、そのまま正しいとは限りません。とはいえ、会議で真正面から「あなたは間違っています」と返すと、話がさらにこじれることもあります。
私がこうした場面で意識しているのは、相手を否定するのではなく、内容を具体的にすることです。
- どの部分が要求と違うのか
- いつ、誰と、どの条件で合意したのか
- 修正が必要なら、優先順位と期限をどうするのか
「全部だめだ」「話にならない」という言葉だけでは、修正作業には入れません。具体的な箇所が示されて、初めて仕事の話になります。
現実の職場では、記憶やその場の空気よりも、メール、議事録、決定事項、変更履歴のほうが自分たちを守ってくれます。
少し面倒でも残しておく。混乱した場面では、その地味な記録が一番頼りになることがあります。
『Dr.STONE』で千空が、混乱の中でも確認できる情報を手放さなかった姿を見て、私はあの会議を思い出しました。
感情が大きくなる場面ほど、事実へ戻る。そのための記録が、最初の備えです。
AI開発で戻れる場所の大切さを知った
修正を重ねてコードを壊した
最近は、AIと対話しながらWordPressのプラグインを作る機会が増えました。
こちらがやりたいことを伝えると、AIはすぐコードを提案してくれます。修正も速く、最初のうちは驚くほど順調です。
ここで気が緩みます。
「あと少し直せば完成する」
「この修正が終わってから保存しよう」
そんな調子でGitへのコミットやファイルの退避を後回しにしていると、急に状況が崩れます。
一つの不具合を直すと、別の機能が動かなくなる。そこを直したら、今度は管理画面が表示されない。さらに修正を重ねると、どの変更が原因なのか分からなくなってきます。
画面が真っ白になったときは、さすがに焦りました。AIへ追加の指示を出すほどコードが複雑になり、まさに、もぐらたたきです。
以前の私は、何とか今のコードを修復しようとしていました。せっかくここまで進めたのだから、戻るのはもったいない。たぶん、そんな気持ちがあったのでしょう。
ただ、壊れた状態に修正を重ねるより、正常に動いていた地点へ戻ったほうが早い場合があります。
「今の修正はいったん諦めて、動いていた版からやり直そう」
そう決めて差し戻すと、出口の見えなかった迷路から、一度外へ出たような安心感がありました。
バックアップを撤退ラインにする
バックアップというと、データが消えたときに使う保険という印象があります。
しかし、開発で何度も失敗してみると、少し違って見えてきました。
正常に動いていた状態が残っていれば、大胆な変更を試せます。失敗しても戻れるからです。
反対に、戻る場所がなければ、一つひとつの修正が怖くなります。触らないほうが安全だと思い始め、改善のスピードも落ちてしまいます。
私が今、最低限残すようにしているのは次の3つです。
- 正常動作を確認した時点のコード
- 何を変更したか分かる短い記録
- データベースや設定を変更する前の退避
本当は、細かくGitへコミットするのがよいのでしょう。ただ、作業に夢中になると忘れることもあります。
そんなときでも、「ここまでは動いていた」というファイル一式だけは残す。格好のよい運用ではないかもしれませんが、何も残さず突き進むよりは、ずっとましです。
『Dr.STONE』第6話で千空が危機から戻れたのも、結果的には小さな備えが残っていたからでした。
仕事でも、撤退ラインは失敗した人だけが使うものではありません。失敗する可能性を承知したうえで、挑戦を続けるために必要なものです。
戻れる場所があるから、前へ出られる。これが二つ目の備えです。
離れた仲間との回路を残した
会社合併後の混乱期には、別の種類のトラブルも経験しました。
当時、私のチームには3人の部下がいました。一人は次々と新しい案を出す若手で、二人は難しいプロジェクトを何度も乗り越えてきたリーダーです。
そのうち一人が、組織の都合で別部署へ異動することになりました。
長く一緒に仕事をしてきた、いわば右腕です。異動を聞いたときは、仕事の負担よりも、チームの一部を突然切り取られたような感覚のほうが強くありました。
会社が決めた人事を覆すことはできません。そこで、所属が変わっても情報のつながりだけは残そうと考え、異動したメンバーを含めた週1回のミーティングを始めました。
会議というより、状況を持ち寄る情報交換の場です。
- 新しい組織で何が起きているか
- プロジェクトへ影響しそうな変更はないか
- 別部署でうまくいった方法を使えないか
最初は、以前のチームの関係を少しでも残したいという気持ちから始めました。
ところが続けてみると、部署が分かれたこと自体が情報源になりました。同じ部署にいるだけでは見えなかった動きが、異動したメンバーを通じて早めに分かるようになったのです。
離れたことは確かに痛手でした。ただ、連絡の回路を残したことで、チームは別の形で機能し始めました。
「あの人なら分かってくれる」と思える相手がいることは、ありがたいものです。しかし、信頼しているから連絡を取らなくてもよい、とはなりません。
忙しくなれば、誰でも目の前の仕事を優先します。部署が変われば、見える情報や目標も少しずつずれていきます。
だから、つながりを残したいなら、気持ちだけでなく仕組みにしておく必要があります。
週1回が難しければ、月1回でもよいでしょう。短いチャットでも構いません。問題が起きたときだけ連絡するのではなく、何も起きていないときにも回路をつないでおく。
千空と大樹、杠のように、強い信頼だけで離れた場所でも動ければ理想です。ただ、現実の職場では、共有する時間や連絡手段を意識して残さなければ、関係は少しずつ薄れていきます。
人とのつながりを仕組みにする。これが三つ目の備えでした。
まとめ｜トラブル時に守る3つの備え
仕様書をめぐる会議、AI開発での失敗、会社合併による異動。
一見すると別々の出来事ですが、振り返ると、私が守ろうとしていたものは共通していました。
一つ目は、確認できる事実です。
誰が何を言い、何を合意したのか。感情が大きくなる場面ほど、記録が自分とチームを守ります。
二つ目は、戻れる場所です。
コードでも仕事の進め方でも、状況が悪化したときに戻れる地点があれば、無理に傷口を広げずに済みます。
三つ目は、人との回路です。
所属や場所が変わっても、連絡する仕組みが残っていれば、関係まで切れるとは限りません。
トラブルに一度も遭わない働き方は、おそらく無理でしょう。私自身、準備不足で焦ったことも、もっと早く記録しておけばよかったと後悔したことも何度もあります。
それでも、次に似た状況が起きたとき、前より少し早く立ち止まることはできます。
「何が事実なのか」
「どこまでなら戻れるのか」
「誰との連絡を切ってはいけないのか」
混乱したときほど、この三つを確認する。
千空のように完璧な判断ができるわけではありません。まあ、現実の私は画面が真っ白になってから慌ててバックアップを探すこともあります。
それでも、備えが一つ残っていれば、次の一手は選べます。
仕事で本当に必要な強さとは、何が起きても平気でいることではなく、崩れかけたときに戻る方法を持っていることなのかもしれません。
コメント