スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

成果を守るほど、人を失うのか?― 後輩が来なくなった日、私は“責任”の定義を間違えていたと知った

あの日から私の時間は止まっている。 社会人5年目。 自分で作ってきたフレームワークを活用する金融プロジェクト。 誇らしかった。だが、現実はほぼ終電。土日も東陽町に通い、たまに早く帰れる日は飲み会で気を紛らわせた。 頑張っていた。 本当に、頑張っていた。 だが、進捗は伸びない。 やることは増え続け、スケジュールは変わらない。 毎週の顧客報告が、静かに心を削っていく。 もし自分たちが崩れたら、何十人ものベンダーが待ちぼうけになる。 一人、月に何十万円。日にすれば何万円。 その重さが、常に頭の中にあった。 守らなければならない。 成果も、契約も、信頼も。 ――そのとき、私は何を守ろうとしていたのか。 後輩も頑張っていた。 だが、少しずつ私の想定とずれていく。 声が大きくなり、態度がきつくなっていたのは、きっと私だった。 飲みに行っても仕事の話。 違う話をしようとしながら、結局は仕事を語っていた。 「少し厳しいんじゃないですか?」 周囲に言われた。 だが、私は正しいと思っていた。 やらなければならないのだから。 そして、ある日。 後輩は来なくなった。 電話をすると、 「しんどいので」と一言。 彼の仕事は私がやった。 次の日も来ない。 その次の日は来たが、昼に帰った。 上司と話し、彼の仕事を減らし、私が引き取った。 やらなくていいことは諦めた。 プロジェクトは進んだ。 彼は別プロジェクトに移った。 だが、家にいることが多いと聞いた。 「しんどくて出られない」と。 半年後。 鬱で休むことになったと知った。 構造の再定義 表面の問題 後輩のメンタル不調。 本質的ボトルネック 成果責任を“個人の背負い込み”と定義していたこと。 再定義 責任とは「抱える量」ではなく、「壊れない構造を設計する力」。 私は成果を守ろうとした。 だが、人の持続可能性を設計していなかった。 経営とは何か。 成果を出すことか。 それとも、成果を出し続けられる構造を作ることか。 あの日、私は前者しか見ていなかった。 あのとき、 「間に合わなくてもいい」と言えていたら。 「今日は帰れ」と本気で言えていたら。 「守るべきは人だ」と腹落ちしていたら。 プロジェクトは成功した。 だが、私は誇れなかった。...
最近の投稿

なぜ“優秀な後輩”との関係は壊れるのか? ――信頼を「暗黙の同調」と誤解した瞬間、組織はずれ始める

ああ、壊れているのは成果ではなく、関係性そのものだった。 社会人5年目。金融プロジェクトのど真ん中。 ほぼ毎日終電。土日も出社し、ドキュメント修正とサーバ管理。ノートPCではないから持ち帰れない。ローカルサーバには家からアクセスもできない。リモートという概念すらなかった。 後輩も、隣で必死にやっていた。 仕事は速いとは言えない。だが、やはり京大だなと思わせる理解力があった。フレームワークを一緒に咀嚼できる。ほぼ毎日一緒にご飯を食べ、同じ戦場に立つ仲間だと信じていた。 信頼していた。 理解力を認めていた。 それでも、関係は少しずつずれていった。 ずれは“能力”から始まらない 会議での受け答え。 作業スピード。 少しずつ、自分の想定と違う。 少しずつ、自分の描くスケジュール通りに進まない。 私は話さなかった。 「こうすべきだ」と思っていた。 そして、合わせてくれるはずだと信じていた。 いや、合わせるべきだと思っていた。 気づけば語気が強くなり、声も大きくなっていた。 だが、仕事は前に進まない。 考えるのではなく、悩むようになっていた。 ■ 構造の再定義 表面の問題 後輩のスピードが遅い。 自分の期待に合わない。 本質的ボトルネック 期待の“共有なき固定化”。 信頼を、暗黙の同調だと誤認していたこと。 再定義 関係性の崩れは、能力差ではない。 「期待設計」の不在である。 私は、「理解力がある=同じ判断をする」と無意識に結びつけていた。 しかし、理解できることと、優先順位を共有することは別だ。 ここで抽象化できる。 人は能力で衝突するのではない。前提で衝突する。 具体に戻る。 私は納期最優先。 彼は品質担保を重視。 どちらも正しい。だが、その優先順位を一度も言語化していなかった。 再び抽象へ。 プロジェクトが壊れる瞬間は、 “暗黙の優先順位”が可視化されないときだ。 経営への示唆 あなたの組織で、 「できるはずだ」と思っている相手に、前提を明示しているか? 成果が出ないとき、 能力を疑う前に、期待の設計を疑っているか? 私は、自分の正しさを守ろうとしていた。 だから語気が強くなった。 だが守るべきだったのは、関係性の構造だった。 考えるとは、構造を見ること。 悩むとは、...

うわっ、役割の線引きが人を追い詰める瞬間がある~社内コンサルの立ち位置~

「支援」と「当事者」のあいだで揺れる影響範囲の設計 社会人4年目の終わりから関わっていたプロジェクトに、1年下の後輩がフレームワーク担当の社内コンサルとして加わった。 少し抜けているが、誰よりも一生懸命な人だった。終電まで一緒に残り、資料を直し、議論を重ね、同じ時間を長く過ごした。     彼の役割は明確だった。 勉強会の実施、説明資料の整備、対応方針の検討。いわば「型」を守り、横断的に整える立場だ。 一方、私は最初こそ社内コンサルとして参画したが、次第にプロジェクトをリードする立場となり、組織上もプロジェクト側へと移った。 同じ現場にいながら、立場は大きく変わっていった。 ■ Role & Responsibility は本当に機能していたか 当然、Role and Responsibility の整理は重要だった。 プロジェクトメンバーと担当側のタスク切り分けは、混乱を防ぐための前提条件だ。 しかし現実には、タスクとタスクの間に必ずグレーゾーンが生まれる。 誰がやるのか明確でない領域。 しかし放置すれば確実に遅延する領域。 私はそこを自らカバーした。 「今は前に進めることが優先だ」と判断したからだ。 彼は慎重だった。 背景にはフレームワーク担当チームからの指示があった。 夜遅くまで担当リーダーと電話し、どこまで踏み込むべきか確認していた。 翌日、プロジェクトでは私からの指示を受け、現場では彼が矢面に立つ。 彼はダブルスタンダードの中心にいた。 ■ 社内コンサルは誰の側に立つのか 経営視点で見れば、この構図は個人の問題ではない。 社内コンサルは本質的に「境界線上の存在」だ。横断機能である以上、複数の期待を同時に背負う。 だが、その期待に対して意思決定権が伴っていなければどうなるか。 役割とは肩書きではない。影響範囲と意思決定権の一致である。 彼は影響範囲だけが拡張し、意思決定権は分断されていた。 その状態でR&Rを自律的にコントロールするのは、極めて難しい。 あなたの組織ではどうだろうか。 横断機能に、意思決定の接続は設計されているか。 ■ 私が向き合うべきだった構造 今振り返れば、私がフレームワーク担当リーダーと直接対話すべきだった。 境界線の再設計を、若手に委...

支援者のはずが主役に――プロジェクトを動かした“後輩”という転機

社内コンサル4年目、現場の最前線で気づいた「チームの力」の本質 うわっ、気づけば“支援者”のはずの私が、プロジェクトのど真ん中に立っていた!     ■ 社内コンサルという“安全地帯”のはずが 社会人4年目。私は社内コンサルとしてプロジェクトに入った。 本来の役割は支援だ。サーバ構築で詰まれば助言をし、新しいフレームワークの理解を促し、迷ったときには設計の指針を示す。あくまで一歩引いた立場のはずだった。 しかし現場は違った。 議論が膠着すれば意見を求められ、障害が出れば判断を委ねられ、スケジュールが揺らげば調整役を担う。気づけば“困ったときのあの人”になっていた。 支援者として入ったはずが、いつの間にかプロジェクトをリードしている。 私はもう完全に“プロジェクト側の人間”だった。 ■ 新人研修で教えた、あの後輩 私は新人研修の担当もしていた。だから下との接点は多い。 そんな中、かつて教えた新人の一人がプロジェクトに加わることになった。 京大卒。地頭は抜群。理論も強い。 だが、どこか少し抜けている。資料の詰めが甘かったり、段取りが少し不器用だったりする。 そして彼は、フレームワークチームから“新たな社内コンサル”として送り込まれてきた。 正直に言えば、私はホッとした。 孤軍奮闘していた現場に、理解者が来たと感じたからだ。 ■ 技術を超えた“対話”の時間 彼とはよく話し込んだ。 昼ご飯を一緒に食べ、設計の悩みを議論し、新しいフレームワークの仕様を確認する。夜の飲み会にも誘ったし、合コンにも連れていった。 仕事では効率が悪い部分もある。 だが彼は、常に最新情報を持ち込み、設計に新しい視点を与えてくれる存在だった。 「その実装だと、将来の拡張性が弱いかもしれません」 そんな一言が、設計の方向を変えることもある。 彼との議論を通じて、私自身のJava理解も一段と深まった。 教える側のはずが、学ばされている。 プロジェクトは技術力だけで動くのではない。 対話で動くのだ。 ■ 結束が生む“見えない推進力” プロジェクト成功の秘訣は何か。 優秀なエンジニアの数ではない。最新技術の導入でもない。 結束だ。 信頼関係があるからこそ、本音でぶつかれる。 心理的安全性があるからこそ、新しい挑戦ができる。 昼の雑談も、夜の飲み会も、無駄ではなかっ...

肝を握るのは誰だ?――プロジェクトを動かした“ハングリーな支援者”

気づけば“主役”が入れ替わっていた――プロジェクトは静かなる陣取り合戦だった! ― 足りない現場を救い続けた、中国系ベンダーの底力 ― ■ 研修講師からプラットフォーム構築へ 私は新人研修をリードした後、全社プラットフォームの構築に従事した。 標準化・共通化を掲げ、現場で再利用できる仕組みを整える仕事だ。やがてそのプラットフォームを各部門へ適用するため、社内コンサルとして現場に入ることになった。 そして最終的には、現地プロジェクトのリードを任される立場に。 理想と現実のギャップを埋める役割だった。 ■ 三つ巴の体制 そのプロジェクトは、日立と2社のベンダーでスタートした。 バッチ系を担うベンダー、Web系を担うベンダー。役割分担は明確。設計も整然としていた。 だが、実際の現場は予算も人数もギリギリ。 ちょっと人が足りない、少し想定外が出る――それだけで遅延の足音が近づく。 構築とテストのフェーズに入り、中国系のベンダーが加わった。 テスト設計は既存2社、テスト作業を中国系チームがサポートする体制だった。 ■ 宙に浮いた“英語Webページ” そんな中、誰にも振られず宙に浮いていたタスクがあった。 英語Webページの構築だ。 国内向け前提で進んでいた設計。 英語化は「あとでやろう」と先送りされ、気づけば誰の責任範囲でもなくなっていた。 そのとき、手を挙げたのが中国系のベンダーだった。 ■ 辞書を引きながら前に進む 彼らは中国人メンバーだけで構成されていた。 リーダーは日本語が完璧。メンバーは日本語を勉強中。それでも動いた。 Google翻訳の精度も今ほど高くない時代。 辞書を調べながら日本語を英語へ変換し、表現を整え、画面体裁まで調整していく。 「できますよ」と静かに言いながら、確実に形にしていく。 めちゃくちゃ助かった。 気が付けば、最初は2人だった体制が6人に増えていた。 ■ プロジェクトは陣取り合戦 プロジェクトは陣取り合戦だ。 こぼれてくるタスクを誰が拾うか。 不足をどう埋めるか。 特に彼らはハングリーだった。 急に人を増やし、柔軟に対応する。価格も抑えめ。スピードもある。 最初は「サポート役」だった。 しかし、こぼれ球を拾い続けるうちに、いつの間にか“肝”に近づいていく。 システムは仕様書...

完成間近で英語が爆発!?――プロジェクトを止める“最後の地雷”の正体

20年超の現場で何度も見た、後回しタスクの恐怖 うわっ、動くはずのシステムが“英語”で止まるなんて誰が想像しただろう! 社会人20年以上。これまでいくつものプロジェクトに入ってきた。要件定義、設計、開発、炎上、立て直し――一通りは経験してきたつもりだ。 お客様側のプロジェクトに入ったのは、金融機関のWebシステム。私はJavaの自社フレームワークを適用する社内コンサルタントとして参画した。立場はコンサルタント。リードする責任者ではなかった。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       ■ コンサルか、リードか しかし、プロジェクト内の社員の少なさを見た瞬間、違和感を覚えた。この体制で本当に最後まで走り切れるのか。 気づけば私は一歩踏み込み、設計レビューに入り、仕様調整に入り、いつの間にかリードチームの一角にいた。 「あなたはコンサルですか?それともリードですか?」 そんな冗談交じりの会話をしたこともある。 だが、あるテーマを前にしたとき、迷いは消えた。 ここは自分がやらなければならない、と。 ■ 多くのプロジェクトでネックになるもの それが「英語化」だった。 機能、画面、メッセージ、帳票。すべてを英語にする。 日本語で作っているものを英語に置き換え、フォーマットを整え、レイアウトを確認し、画面上で正しく動くかを検証する。 やることは単純だ。 プログラムをコピーし、文言を英語にするだけ。 しかし現実は甘くない。 日本語と英語では文字の長さが違う。ボタンがはみ出す。テーブルが崩れる。メッセージが途中で切れる。一つひとつ合わせていく地道な作業だ。 ■ なぜ後回しにされるのか プロジェクトメンバーは、仕様やロジックにこだわる。 パフォーマンス改善、機能追加、バグ修正。目に見える成果に集中する。 英語化は「最後でいい」となりやすい。 しかも英語が得意な人は多くない。 結果、夏休みの宿題のように後ろへ後ろへと押しやられる。そして終盤、リソースが尽きる。誰もやらない。 リリース直前になって「あれ?英語画面が崩れている」「海外拠点で使えない」と問題になる。 私はこの光景を、何度も経験してきた。 ■ 最初に詰まった金融Webプロジェクト この金融機関のWebシステムは、私にとって最初に...

泊まれるの!?――不夜城を支える“見えないホテル”の話

金融最前線、COBOL終焉、そしてWeb革命のただ中で うわっ、ここは本当に昼と夜の境目がない街なのか!? 社会人3年目から4年目に入ろうとする頃、私は金融系企業の最前線プロジェクトにいた。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       ■金融最前線という名の不夜城 そこは長年、COBOLで基幹システムを作り込み、巨大で堅牢な仕組みを築き上げてきた世界。止まらないことが絶対条件。1秒の遅延も許されない緊張感。 しかし、時代は大きく揺れ始めていた。——時はまさにCOBOLの終焉。 ■Web時代の幕開け ホームページは「会社案内」ではなくなりつつあった。問い合わせを受け、データベースとつながり、業務そのものを動かす入口になる。 Javaの機能拡張は、その変化を強く後押ししていた。 私たちは社内で作ったJavaのWebアプリケーションフレームワーク、さらにシステム間連携アプリケーションのフレームワークを適用し、新しい金融の姿を描こうとしていた。 ■気がつけば、どっぷり 最初は「最前線で学べる」と胸を躍らせていた。 だが、気づけばプロジェクトにどっぷり。 深夜残業は当たり前。 「机で寝る?」 「終電、間に合うかな?」 そんな会話が自然に飛び交う。 ほぼ毎日、終電ダッシュ。 それでも、終電を逃す人が何人かいる。 「え?あの人たち、どこに泊まってるの?」 ■先輩が教えてくれたこと ある夜、先輩がぽつりと言った。 「会社、近くのホテルと契約してるんだよ」 何室かキープしていて、空いていれば優先的に泊まれる。会社名を伝えれば、チャージはすべて会社負担。 「急に終電逃しても、そこ行けばいい」 ——え?そんなことあるの? ■見えない“夜のインフラ” 衝撃だった。 会社は、挑戦する人を放り出していなかった。 最前線で戦う人たちを支える、見えないインフラがあったのだ。 もちろん、働き方として理想かと言われれば議論はある。だがあの時代、Web革命の渦中で、組織は本気だった。 一生懸命働く人を、きちんと守る仕組みを用意していた。 ■今、振り返って思う プロジェクトは技術だけで動かない。 人が動くから、未来が動く。 そして人を支える仕組みがあるから、挑戦は継続できる。 あの“不夜城”を支えていたのは、Javaでもフ...