あのコーヒー、冷めてましたよ　〜冷めたコーヒーと、温まっていった組織の話〜

※登場人物は仮名です。

はじめに

この記事を書いているのは、中堅企業でITアウトソーシングのプロジェクトマネージャー（PM）をしている私です。

PMといえば、颯爽とプロジェクトを指揮し、ベンダーに矢継ぎ早に依頼し、経営層に的確な報告をする——そんなイメージを持っている方もいるかもしれません。少なくとも、PM打診を受けた当初の私は、漠然とそういうものだと思っていました。

もともと私はエンジニアでした。技術を武器に仕事をしてきた人間です。コードを書いたり、システムの設計をしたり、手を動かすことが仕事の中心でした。人を動かしたり、交渉したり、報告書をまとめたりすることは、正直あまり得意ではなかった。

そんな私に、ある日上司から声がかかりました。

「PM、やってみないか」

断る理由も、特にありませんでした。でも、すんなり「やります！」と言えるほどの自信もなかった。不安と期待が、ちょうど半々。そういう気持ちで引き受けたのを、今でも覚えています。

着任が決まった日の帰り道、近所のスターバックスに寄りました。普段はあまり行かないけれど、なんとなく、そういう気分だったのです。ラテを一口飲みながら、「まあ、なんとかなるだろう」と思っていました。根拠のない自信というやつです。あの頃の私は、まだそういうことが言えました。

それから数年。PMとして向き合ってきた現場は、想像以上にぐちゃぐちゃでした。ベンダーへの丸投げ、誰も知らないシステム、消えていく知識、そして大きな失敗。「PMってこういうものか」と思いながら、試行錯誤を重ねてきました。

この記事は、その試行錯誤の記録です。

きれいな成功談ではありません。恥ずかしい失敗がたくさん出てきます。「こうすればうまくいく」という正解を書いているわけでもない。ただ、同じような現場で悩んでいる誰かに、「あ、うちだけじゃないんだ」と思ってもらえたら、それだけで十分です。

あと、コーヒーが好きな方にも、ぜひ読んでいただきたい。理由は最後まで読めばわかります。

第1章：中堅企業のIT部門ってこんな世界

9月のことでした。

暦の上ではとっくに秋のはずなのに、外はまだじりじりと暑い。残暑というやつです。スーツの背中に汗をかきながら、私はその日初めて、この会社のIT部門に足を踏み入れました。

着任初日、私は完全に迷子でした。

とある中堅企業のIT部門にプロジェクトマネージャーとして赴任した朝のことです。引き継ぎ資料を受け取り、ざっと目を通してみたものの、知らない略語と知らないシステム名が並ぶばかりで、何一つ頭に入ってこない。「とりあえず何かわからないことがあれば聞いてください」と言い残して、前任者は颯爽と去っていきました。

何かって、全部ですが。。。

中堅企業のITアウトソーシングというのは、外部のベンダーに業務システムの開発・運用を委託する形態です。社内にIT専任の人材を抱えるコストを抑えながら、専門家に任せられる合理的な選択肢です。コア業務に集中したい経営陣にとっては、願ったり叶ったりの仕組みともいえますね。

ただ、その結果として何が起きているかというと、システムについて「ちゃんと知っている人」が社内にほとんどいない、という状態でした。

ファイルサーバーの奥を漁ると、手順書らしきものが出てきます。最終更新日は数年前。スクリーンショットは現在の画面と似ても似つかない旧バージョンのもので、肝心な箇所には「※詳細は島根さんに確認」と書いてありました。

島根さんって誰ですか、と隣の席の人に聞いたら、「ああ、ベンダーにいるエースの人ですね」と教えてくれました。

窓の外では、残暑の陽射しがアスファルトを照らしていました。まだ夏は終わっていない。そしてここには、誰も知らないことが、山積みになっていた。

そのとき私が感じた、あの底が抜けるような感覚。これが、この物語の出発点です。

第2章：「その人しか知らない」が発動した日

異変は、ある朝突然やってきました。

「例の担当者、来月で辞めるらしいですよ」

同僚からのさりげない一言。「例の担当者」とは、長年うちの会社のシステムを一手に支えてきたベンダーのエース・島根さんのことでした。ベンダー歴15年、無口だけど仕事は完璧で、何か困ったことがあれば「島根さんに聞いてください」で全部解決していた。そんな島根さんが、「地元に帰ります」とだけ言い残して、去っていくというのです。

「引き継ぎはどうなりますか」と恐る恐る確認すると、「2週間でやります」という答えが返ってきました。2週間。15年かけて積み上げた知識を、2週間で。

嫌な予感は、的中しました。

新しい担当者がやってきた最初の週、さっそくトラブルが発生しました。「マニュアルを確認します」「マニュアルに記載がありませんでした」「前任者に確認してみます」「つながりませんでした」——このリレーが、わずか2日で完結しました。

知識は、人の頭の中にある。その人がいなくなったとき、知識も一緒に消える。

同じ時期、社内でも似たことが起きていました。システムに詳しかった社員が他部署へ異動になり、後任の方はITがほぼ未経験。「この画面って何ですか」という質問が毎日届くようになりました。聞かれるほうも答えられない、というのはなかなかシュールな光景でした。

ベンダーも替わり、担当者も替わり、社内の窓口も替わった。それぞれの引き継ぎは、それぞれなりにやった。でも全体として見ると、「誰も全体を知らない」という状態が静かに出来上がっていました。

これが地雷原だと気づいたのは、実際に踏んでからでした。

第3章：なぜ属人化は生まれるのか

その一：善意が積み重なって地雷になる

少し立ち止まって、考えてみたいと思います。

属人化は、悪意から生まれるものではありません。誰かが「俺だけが知っている状態にしてやろう」と画策した結果ではない。むしろ、善意と合理性の積み重ねが、じわじわと地雷を埋めていくのです。

たとえば、こういうことです。

社内で一番の古株・奈良さんがいます。「俺が全部わかってるから大丈夫」が口癖で、何か問題が起きるとさっと解決してくれる。周りからの信頼も厚く、自然と「これは奈良さんに聞けばいい」という文化ができあがっていました。奈良さんも悪い気はしない。頼られることは、やりがいでもある。何より、奈良さんは誰より会社を愛していた。

でも、奈良さんは忙しい。マニュアルを書く時間はない。頭の中では自明のことをわざわざ文章にするのは、なんとなく手間に感じる。「聞かれたら答えればいい」で回っているうちは、それで十分です。

そしてある日、奈良さんも異動になりました。

残されるのは、ファイルサーバーの奥に眠る一枚の手順書と、そこに書かれた「※詳細は奈良さんに確認」という一行だけです。

私がその一行を見つけたのは、ずっと後のことでした。奈良さんがどんな思いであの一行を書いたかはわかりません。もしかしたら「後で書き足そう」と思っていたかもしれない。でも、後でが来ないまま、奈良さんは去っていった。

知識には「見えている部分」と「見えていない部分」があります。資料に書けるのは見えている部分だけ。長年の経験から染み込んだ「なんとなくこうするもの」という感覚は、文章にしようとすると消えてしまう。これを『暗黙知』と呼びますが、まさにこの暗黙知こそが、属人化の核心にあります。

人が替わるたびに少しずつ知識が失われ、残った人たちは「なんとなく動いているから大丈夫」と信じて運用を続ける。爆弾のタイマーが、静かに刻んでいるとも知らずに。

その二：ベンダーの裏側に、もう一つの裏側があった

属人化の問題は、社内だけに潜んでいるわけではありません。

ある障害対応の最中のことでした。ベンダーへ原因調査を依頼したのに、なかなか回答が来ない。催促すると「確認中です」とだけ返ってくる。「確認って、誰に確認してるんですか」と聞いたら、しばらく間があってから、こう言われました。

「協力会社に問い合わせています」

協力会社。その言葉を聞いた瞬間、私は嫌な予感を覚えました。

その後、実態を調べていくうちに、構造が見えてきました。私たちが契約しているベンダーは、実際の作業の大部分を別の会社に委託していた。そしてその会社も、一部をまた別の会社に出していた。気づいたときには、発注先が3社以上連なっている状態になっていました。

つまり、私たちが「ベンダーに確認する」と思っていた相手は、実は自分では何も把握していなかった。把握していた会社は、私たちとは契約関係すらない、もっと先の誰かだったのです。

作業実態が全く見えない。誰が何をしているかわからない。何か問題が起きたとき、責任の所在を辿ろうとしても、情報が霧の中に消えていく。これは属人化というより、「構造的な不透明性」とでも呼ぶべき問題でした。

ベンダーを責める気持ちは、正直なところ、あまりありませんでした。こういう多重下請け構造は、IT業界では珍しくない。問題は、私たちがその構造を知らないまま、信頼だけで委託し続けていたことでした。「お任せします」は、時として「何も見ません」と同義になる。そのことを、このとき初めて理解しました。

その三：「それは仕様です」という魔法の言葉

もう一つ、この時期に何度も繰り返されたやりとりがあります。

システムの動作に疑問を感じてベンダーに問い合わせると、決まってこう返ってくるのです。

「それは仕様です」

最初は素直に受け入れていました。仕様なら仕方ない、そういうものなんだろう、と。でも何度も繰り返されるうちに、だんだん違和感を覚えるようになりました。「仕様です」と言われた動作が、業務上の支障になっているケースが増えてきたからです。

ある日、私は方針を変えることにしました。「仕様です」と言われたら、そのまま受け入れるのをやめる。代わりに、自分でログを確認し、過去の記録を漁り、数字で事実を積み上げてから、改めて問い合わせる。

「先日ご回答いただいた件ですが、ログを確認したところ、〇月〇日の〇時〇分に同様の事象が発生しており、その際は別の挙動をしていることが確認できました。この差異についてご説明いただけますか」

こういう問い合わせをするようになると、返ってくる回答の質が変わりました。「仕様です」の一言で終わらなくなった。時間はかかりましたが、いくつかのケースでは「仕様の誤りでした」「修正対応します」という回答を引き出すことができました。

証拠を積み上げて反論する、というのは、体力のいる作業です。でも「言われたことを信じる」だけでは、見えないものが見えないままになる。ベンダーだって人間です。確認が甘ければ、甘いなりの回答をしてくる。こちらが丁寧に事実を示せば、丁寧に向き合ってくれる。そのことを、この経験は教えてくれました。

そしてもう一つ、気づいたことがあります。

「それは仕様です」と言われ続けた期間、私は情報を持っていなかった。ログも、記録も、過去の経緯も。手元に何もなければ、反論のしようがない。属人化の問題と、この「情報を持たないまま委託する」問題は、実は根っこでつながっていました。知識が社内に残っていれば、「仕様です」と言われたときにすぐ検証できる。でも知識がなければ、言われたことを信じるしかない。

属人化は、交渉力まで奪っていくのです。

第4章：爆弾が爆発した夜

その一：ごく普通の作業のはずだった

6月のことでした。

梅雨のただ中で、外はじっとりと湿っていました。窓の外には灰色の雲が低く垂れ込め、午後になっても晴れる気配がない。そういう日に限って、オフィスの空調は妙に効きすぎていて、半袖では少し肌寒いくらいでした。

それは、ごく普通の作業のはずでした。

定期的なデータ更新の処理。手順通りに進めて、完了を確認して、その日は終わった。少なくとも、そのつもりでした。

異変に気づいたのは、しばらく経ってからのことです。「ログインできないんですけど」という連絡が、ぽつぽつと届き始めました。最初は個別のトラブルかと思っていた。パスワードの入力ミスかな、ブラウザのキャッシュかな。よくある問い合わせのトーンで、よくある対応をしようとした。

ところが、件数が増えていく。増えていく。

調べてみて、青ざめました。大量の社員IDが、消えていました。

データ更新の処理が、どこかで想定外の動きをしたらしい。「らしい」というのが、また怖い。確信を持って「これが原因です」と言える人間が、その場に誰もいなかったのです。第2章で書いた「誰も全体を知らない」状態が、最悪のタイミングで牙を剥きました。

その二：泊まり込みの夜

泊まり込みが始まりました。

関係者が集まり、ベンダーにも連絡を入れ、状況の整理から始めます。「何が起きたか」「どこまで影響が出ているか」「どうすれば戻せるか」。この三つを並行して追いかけながら、夜が更けていきました。

窓の外では、梅雨の雨がしとしとと降り続けていました。音もなく、ただ静かに。オフィスの蛍光灯だけが白々と光る中で、キーボードを叩く音と、雨音だけが聞こえる。そういう夜でした。

そのとき黙って私の隣に来てくれたのが、同じ部署の秋田さんでした。普段は口数が少なく、自分の仕事を淡々とこなすタイプ。でもこの夜は、「一緒にやりましょう」とだけ言って、椅子を引き寄せてきた。それだけで、少し息ができた気がしました。

深夜、秋田さんがコーヒーを2つ持ってきてくれました。近くのコンビニで買ってきたらしく、紙カップに「COFFEE」とだけ書いてある、あれです。「飲んでください」と差し出されたそのカップを、私は結局飲めませんでした。

解決の見通しが立たない中での待機、というのが精神的にいちばんきつかった。何かをしている間はまだいい。でも、調査結果をただ待つだけの時間が、じわじわと心を削っていく。コーヒーが冷めていくのに気づいても、手が伸びない。梅雨の湿った空気が、じめじめと部屋に漂っている気がした。

「これ、本当に直るんですかね」と秋田さんが静かに言いました。

「直します」と私は答えました。根拠はなかったけれど、そう言うしかなかった。

その三：真夜中に気づいたこと

深夜2時を回ったころ、調査が少しずつ進んできました。原因の輪郭が見え始め、復旧の糸口らしきものが見えてきた。そのとき、私はふと手を止めて、自分がここ数時間でやってきたことを振り返りました。

ログを一つひとつ確認した。過去の類似ケースを検索した。ベンダーに対して「こういう事象が起きているが、考えられる原因は何か」と仮説を提示して問い合わせた。社内の関係部署にも連絡を入れ、影響範囲を自分たちで把握しようとした。

そこで気づきました。

私は今夜、初めて「自分達で情報を集めて考えている」と。

それまでの私は、何か問題が起きるとまずベンダーに連絡して、回答を待っていました。回答が来たら、それを信じる。判断はベンダーに委ねる。それが「プロに任せる」ということだと思っていたのです。でもこの夜、ベンダーからの回答を待ちながら、私達は自分でもログを読み、自分でも仮説を立て、自分でも検証を進めていた。

任せることと、考えることをやめることは、違う。

そんな当たり前のことが、この夜の真っ只中で、初めて腑に落ちました。後から思えば、これが私にとって一番大きな転換点でした。失敗の最中に、いちばん大切なことを教わった。皮肉だけれど、そういうことは、案外よくあるのかもしれません。

その四：3ヶ月から4ヶ月の手探り

結論から言えば、乗り越えることができました。

ただし、その夜のうちに解決したわけではありません。複数の関係者が知恵を出し合い、3ヶ月から4ヶ月という時間をかけて、影響を受けた社員IDを一つひとつ確認しながら復旧させていく地道な作業が続きました。

その間には、うまくいかない日もありました。復旧したと思ったら別の問題が出てくる。ベンダーとの認識がずれて、また最初から確認し直す。チームの疲弊が目に見えてくる。それでも少しずつ、前に進んでいきました。

「終わった」と思えたのは、長い長い手探りの末のことです。

あの夜のコンビニコーヒーは、最後まで飲めませんでした。でも翌朝、廊下の自動販売機で買った缶コーヒーを、秋田さんと二人で飲みました。ぽこん、とプルタブを開ける音が、妙に大きく響いた。缶コーヒーで、たいして美味しくもなかったけれど、あのときの味は今でも覚えています。梅雨空の下、窓から差し込む薄い朝の光の中で飲んだ、あの缶コーヒー。

そしてあの夜、私は一つのことを決めました。二度と、こういう夜を迎えない組織にする。そのためにできることを、明日から始めよう、と。

第5章：チームが崩れていく

その一：じわじわと、気力が失われていく

大インシデントが終わったあと、チームに変化が起きました。

目に見えて何かが崩れた、というわけではありません。会議は続くし、日常業務も回っている。でも、何かが違う。言葉にしにくいけれど、確かに違う。

気づいたのは、ある朝のことでした。チームメンバーの一人が、以前なら自分から手を挙げていた場面で、黙って下を向いていた。「誰かやりますか」と聞いても、反応が薄い。あの人が、こんな顔をするだろうか。そう思ったとき、私はやっと状況を理解しました。

みんな、疲れていたのです。

大インシデントの3ヶ月から4ヶ月は、チーム全員にとって消耗の連続でした。通常業務をこなしながら、復旧作業を並行させる。終わりが見えない中で、それでも前を向き続ける。そのしんどさを、誰もあまり口にしなかった。口にしている余裕がなかったのかもしれないし、口にしても仕方がないと思っていたのかもしれない。

インシデントが「解決した」という瞬間、緊張の糸が切れました。やり遂げた達成感よりも先に、どっと疲れが押し寄せてきた。そういうことは、よくあります。でも私は、その反動の大きさを、正直なところ読み切れていませんでした。

モチベーションというのは、一度下がると戻すのが難しい。特に、「なぜこんなことになったのか」という根本的な疑問が解消されないままだと、なおさらです。「また同じことが起きるんじゃないか」という不安が、じわじわと前に進む力を奪っていく。

私はそのとき、復旧作業を終えたことに安堵して、チームの内側を見るのが少し遅れていました。それが、次の問題につながっていきました。

その二：誰も気づかなかった孤立

チームの中に、山口さんという社員がいました。インシデントの前から在籍していた、真面目で丁寧な仕事をする人でした。与えられたタスクは必ずこなし、品質も高い。でも、自分から発言することが少なく、会議でもどちらかというと聞き役に回ることが多かった。

インシデント対応の最中、山口さんは黙々と作業を続けていました。誰かに助けを求めることもなく、遅れが出ているわけでもなく、傍から見れば何も問題はないように見えていた。

でも実際には、山口さんは孤立していました。

インシデント対応では、自然とコミュニケーションの中心に近い人に情報が集まります。声が大きい人、反応が速い人、積極的に連絡を取りに行く人。山口さんはそのタイプではなかった。気づいたときには、山口さんだけが重要な情報を共有されていない場面が続いていました。

私が気づいたのも、偶然でした。山口さんが提出してきたレポートに、すでに解決済みの問題への対応策が書かれていた。「あ、この情報、山口さんには届いていなかったんだ」と、そのとき初めてわかりました。

直接話しかけてみると、山口さんは静かにこう言いました。

「最近、何をやっているのか、自分でもよくわからなくなってきました」

その言葉が、ずっと頭に残っています。

私はその後、山口さんとの1on1の時間を増やしました。情報が届く仕組みも見直した。でも、それが実を結ぶ前に、山口さんは別の部署への異動が決まりました。去り際に「お世話になりました」と言ってくれたけれど、私には「もっと早く気づいていれば」という悔いが残りました。

組織の問題を解決しようとしながら、目の前の一人を見逃していた。チームを守ろうとして、チームの中の誰かを守れていなかった。PMとして、これは今でも消えない反省です。

その三：雑談の中の、一言

そんな時期に、ある人と話す機会がありました。

以前の現場で一緒に仕事をしていた、顧客先の上司です。私より年下でしたが、たたき上げで昇進してきた人で、現場のことを誰より知っていた。久しぶりに連絡を取ったのは、近況報告のつもりでした。特に深い相談をするつもりもなく、軽い雑談のつもりで話していた。

そのとき、その人がさらっとこう言ったのです。

「仮説を立てるには、経験からも想起するけど、あらゆる情報を集めて総合的に成り立たせることも重要ですよ」

雑談の流れで出てきた言葉でした。その人は、特に何かを教えようとして言ったわけではなかったと思います。でも私には、その言葉がまっすぐに刺さりました。

当時の私は、大インシデントの後遺症のような状態で、判断の多くを経験と勘に頼っていました。「こういうときはこうする」という過去のパターンを当てはめることが、判断の基準になっていた。情報を集めることより、自分の経験を信じることの方が早いと思っていた。

でも、その一言を聞いたとき気づきました。

私が「経験から判断している」と思っていたことの多くは、実は「情報が足りないまま判断している」だったのかもしれない、と。

ベンダーに「それは仕様です」と言われたとき、なぜすぐに信じてしまったのか。丸投げの構造に、なぜ長い間気づかなかったのか。山口さんの孤立に、なぜ気づくのが遅れたのか。どれも根っこは同じでした。情報を集めることをせず、見えているものだけで判断していた。

経験は大切です。でも経験だけでは、見えない部分が増えていく。特にシステムの世界では、見えていないことの方が、見えていることより多い。だからこそ、あらゆる情報を集めて、自分で仮説を立てて、検証する。その習慣が、PMには必要だったのです。

雑談の中の、さらっとした一言。

その言葉は、私の中でしばらく静かに沈んでいきました。そしてある朝、目が覚めたとき、何かが変わっていました。

第6章：PMとして、根本から変わった

とはいえ、変わったのは一夜にしてではありません。

試して、失敗して、また試して。その繰り返しの中で、気づいたら変わっていた。むしろ地味な話です。でも後から振り返ると、確かにあの頃を境に、やり方が変わっていました。

4つのことを、変えました。

変化①：報告・説明の仕方を変えた

以前の私の報告は、こういうものでした。

「ベンダーから〇〇という回答が来ました」「現在、対応中とのことです」「来週中には解決する見込みと聞いています」

つまり、ベンダーから聞いたことをそのまま上司や経営層に伝えていた。自分の言葉が入っていない。自分の判断が入っていない。情報の「運び屋」になっていたのです。

変えたのは、「自分の見立てを必ず入れる」ことでした。

「ベンダーは来週中と言っていますが、過去の類似案件では平均2週間かかっています。今回は規模が大きいため、3週間程度を想定して動くべきと考えています」

こういう報告をするためには、自分で情報を調べなければならない。過去の記録を掘り起こし、数字を確認し、比較して、判断する。手間はかかります。でも、この「自分で判断する」という習慣が身につくと、ベンダーの回答を鵜呑みにしなくなる。「それは仕様です」と言われたときも、すぐに「では、ログで確認します」と動けるようになる。

報告の仕方を変えることは、思考の仕方を変えることでした。

変化②：メンバーへの関わり方を変えた

山口さんのことが、ずっと頭に残っていました。

山口さんの孤立に気づけなかった原因は、私が「問題のある人に目を向けていた」からだと思います。遅れが出ている人、声が大きい人、トラブルを抱えている人。そういう人には自然と目が行く。でも、静かにこなしている人のことは、「大丈夫だろう」と思って、見ていなかった。

変えたのは、「静かな人ほど、意識して話しかける」ことでした。

1on1の頻度を増やしました。特に、会議で発言が少ないメンバーとの時間を優先した。最初は「何を話せばいいかわからない」と戸惑うこともありましたが、続けているうちに、少しずつ変化が見えてきました。普段は黙っているメンバーが、1on1では思いのほかよく話してくれる。「実はこういうことが気になっていた」「あの件、自分はこう思っていた」という言葉が、二人きりの場では出てくる。

チームの状態は、声の大きい人だけを見ていても、わかりません。静かな人たちの中に、本当の空気が流れていることがある。山口さんが教えてくれたのは、そういうことでした。

変化③：ベンダーとの交渉スタイルを変えた

「それは仕様です」との戦いを経て、ベンダーとの向き合い方が変わりました。

以前は、ベンダーに「お願いする」スタイルでした。困ったことがあれば連絡して、回答を待って、対応をお願いする。関係を壊したくないという気持ちもあったし、専門家に任せるべきだという思いもあった。

変えたのは、「対等に話す」スタイルです。

具体的には、問い合わせをするときに必ず「自分の仮説」を一緒に伝えるようにしました。「〇〇という事象が起きています。ログを確認したところ、△△が原因ではないかと考えています。この仮説についてご確認いただけますか」という形です。

最初は少し抵抗がありました。専門家に対して素人が仮説を出すのは、失礼ではないか、と。でもやってみると、むしろ歓迎されることが多かった。仮説があると、ベンダー側も「どこを確認すればいいか」がわかりやすい。回答の精度が上がる。「仕様です」で終わりにくくなる。

パートナーとして対等に話すことが、結果として良い関係を作ることにもなりました。お願いするだけの関係より、一緒に考える関係の方が、長続きする。当たり前のことかもしれませんが、実際にやってみて初めてわかりました。

変化④：自分が手を動かすのをやめて、任せるようにした

これが、一番難しい変化でした。

PMになりたての頃の私は、よく「自分でやった方が早い」と思っていました。メンバーに任せると時間がかかる。説明するより自分でやった方が確実だ。そういう思考が染み付いていた。

でも、この考え方には大きな問題があります。「自分でやった方が早い」は、短期的には正しいかもしれない。でも長期的には、チームが育たない。任せないから、メンバーが成長しない。成長しないから、また自分でやることになる。その繰り返しが、組織の属人化を生んでいたのです。

皮肉なことに、私自身が属人化の原因の一つだったわけです。

変えたのは、「任せると決めたら、口を出さない」ことでした。途中で不安になっても、確認したくなっても、ぐっと堪える。もちろん、本当に困ったときのサポートはする。でも「見守る」と「干渉する」は違う。その線引きを、意識するようにしました。

最初のうちは、正直なところ怖かった。うまくいかなかったらどうしよう、と。でも任せてみると、メンバーは思った以上にちゃんとやってくれる。むしろ、任されることで力を発揮する人もいた。「任せる」ということは、相手を信頼するということでもある。その当たり前のことに、ずいぶん遠回りして気づきました。

変化の先に

4つの変化を書きましたが、どれも「一夜にして変わった」わけではありません。試して、失敗して、また試して。そういう繰り返しの中で、少しずつ形になっていきました。

今でも、うまくいかないことはあります。報告が的外れだったり、メンバーへの声かけのタイミングを外したり、任せすぎてフォローが遅れたり。完璧なPMには、まだまだほど遠い。

でも一つだけ、確実に変わったことがあります。

「わからないことを、わからないままにしない」という姿勢です。以前の私は、わからないことがあると、誰かに聞くか、とりあえず様子を見るか、どちらかでした。でも今は、まず自分で情報を集めて、仮説を立てて、検証する。それがうまくいかなければ、そこで初めて誰かに聞く。

あの雑談の一言が、今の私の仕事の基本になっています。

第7章：完全には解決しない、でも1mm前進した

その一：わからないことリストから始めた

あの夜から、私はいくつかのことを始めました。

まず手をつけたのは、「わからないことリスト」を作ることでした。「何をすべきか」より先に、「何がわかっていないか」を全部書き出す。それをベンダーや関係者に一つひとつぶつけていく。答えが返ってきたら記録する。「わかりません」だったら、それも記録する。地味で、遅くて、終わりが見えない作業でした。

でも続けていると、少しずつ変化が起きてきました。

それから1年ほど経ったある日、新しく着任したベンダーの担当者・福井さんが、こんなことを言ってくれました。前の現場でドキュメントが何も整備されておらず、着任初日から途方に暮れた経験を持つ福井さんは、誰より手順書の大切さを知っている人でした。

「このリスト、めちゃくちゃ助かってます。ここはどこに聞けばいいかわかるので、前の現場と全然違う」

その言葉を聞いて、私は思わず笑いました。

着任初日、右も左もわからなくて底が抜けるような気持ちになった、あの私の顔を、福井さんがしていたのです。そして目の前の彼女は今、あの頃の私より少しだけ安心した顔をしている。それはあの夜の私たちが、一つひとつ「わかりません」を書き留めてきたからでした。

その二：奈良さんの一行の続き

ファイルサーバーの整理をしていたとき、古い手順書の中に、あの「※詳細は奈良さんに確認」という一行を見つけました。

今さらどうにもならない、と思っていたその一行のすぐ隣に、誰かが書き足した形跡があったのです。小さな字で、「→福井さんに確認済み、以下に手順を追記」と。

奈良さんが書けなかった続きを、福井さんが書いてくれていました。

奈良さんがいなくなって、知識が一度途切れた。でも福井さんが拾い上げて、また繋いだ。その一行を見たとき、私はしばらくその場で動けませんでした。

知識はこうやって、人から人へと渡っていくのかもしれない。バトンのように、ときには途切れながら、それでも誰かが拾い上げて、また繋いでいく。属人化との戦いは、知識を「人の頭の中」から「みんなの場所」へ移していく、地道な引越し作業なのかもしれない、と思いました。

その三：秋田さんからのメッセージ

先日、秋田さんからメッセージが届きました。

秋田さんはあの泊まり込みの後、別の部署へ異動になっていました。異動先でこんなことを言われたというのです。「前の部署、ずいぶん整理されてきたって聞きましたよ。秋田さんたちがやってたこと、ちゃんと残ってるんですね」。

メッセージの最後には、こう書いてありました。

「あの夜、無駄じゃなかったですね。あと、あのコーヒー、冷めてましたよ」

思わず吹き出しました。秋田さんらしい。

あの夜、「直します」と言ったとき、根拠はなかった。でも今、秋田さんのメッセージを読んで、あの言葉は嘘じゃなかったと思えました。直した。ちゃんと、直した。そのことが、静かに、でも確かに嬉しかった。

その四：山口さんへの手紙

山口さんとは、異動後も時々連絡を取っています。

あるとき、山口さんからこんなメッセージが届きました。「新しい部署では、最初から1on1をやってもらえていて、すごく助かっています」と。

嬉しい反面、少し胸が痛くもありました。山口さんが今の環境で当たり前に受けているものを、以前の部署では提供できていなかった。でも同時に、思いました。山口さんは今、ちゃんと自分の場所を見つけている、と。

私が守れなかった人が、別の場所でちゃんと守られている。それは悔しさでもあるけれど、安堵でもありました。そして、山口さんへの申し訳なさが、今の私がメンバーの「静かな声」を聞こうとし続ける原動力になっています。

失敗は、消えない。でも失敗が何かを変えることは、ある。

その五：1mmが、1cmになる

属人化は、完全にはなくならないかもしれません。

人が動く限り、知識はどこかで薄まる。引き継ぎのたびに、何かが抜け落ちる。新しい人が来るたびに、また少し最初からやり直す。それは今も続いています。

でも今は、「誰も何も知らない」あの夜とは確実に違う場所に立っています。

着任初日に迷子になった私が、今は「わからないことリスト」を渡せるようになった。

「それは仕様です」と言われたとき、ログで確認できるようになった。

ベンダーの丸投げ構造に気づいたとき、契約の中身を見直すことができた。

チームの静かな人に、先に話しかけるようになった。

報告に、自分の判断を入れるようになった。

1mmの前進が、いくつも積み重なって、気づいたら1cmになっていた。

そしてその積み重ねが、次にここへ来る誰かの「安心」になる。爆弾を埋めた場所に、小さな灯りを一つずつ置いていく仕事です。地味で、遅くて、終わりが見えない。それでも、やっぱり悪くないなと、今は思えています。

着任が決まった夜、スターバックスのラテを飲みながら「まあ、なんとかなるだろう」と思っていた私。梅雨の深夜、コンビニコーヒーを飲めないまま冷ましてしまった私。翌朝、廊下の自動販売機の前で秋田さんと缶コーヒーを飲んだ私。

同じ私が、少しずつ違う私になってきた気がします。

今日も、コーヒーを飲みながら、ドキュメントを一つ書いています。

どのコーヒーかは、ご想像にお任せします。