Digital Heroes: Guide to IT World

うわっ…人の密度でシステムの温度が上がるなんて思わなかった！ ■開発プロジェクトは“人が集まる生き物” 開発プロジェクトとは、単なる作業の集合体ではない。人が集まり、増え、そしてピークを迎える“生き物”だ。私が経験した200人を超えるプロジェクトも、最初から大規模だったわけではない。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■最初は静かに始まる 設計フェーズの最初は、わずか50人程度。要件定義の段階では、さらに少なかったはずだ。議論は深く、密度は高いが、物理的な空間にはまだ余裕がある。 しかし、設計が終わり、プログラミング開発、そしてテストへと進むにつれて状況は一変する。人は一気に増え、最も盛んな時期には200人を超える。 ■最大の問題は「人の置き場」 ここで必ず直面するのが、極めてシンプルでありながら深刻な問題だ。 ——この人たちは、どこで開発するのか？ 1年の中でこれだけ柔軟に人員が変動する。それに対応できる場所など、最初から用意されているわけではない。場所は決まっている。増えたからといって、簡単に広げられるものではない。 近くの会議室を長期で借りる案も出た。しかし、それは数十人単位の話であり、1人単位で柔軟に増減できるものではない。 ■現場で起きた“強引な最適化” 結局、他のプロジェクトに我慢してもらい、同じ開発スペースに人を押し込む形になった。それでも限界はある。 では、どうするか。 削るしかない。 削る対象はただ一つ——1人あたりのスペースだ。 部長を含め、全員のデスク幅を極限まで詰めていく。当時はデスクトップPCが標準だったが、それを横に倒し、その上にディスプレイを置くことで横幅を圧縮した。 ■1人、何センチ必要か？ その答えは、極めて現実的だった。 開発スペース：最大80センチ テストスペース：最大60センチ 実際に座ると、肘と肘が触れ合う。隣との距離はほぼゼロだ。これまで様々なプロジェクトを経験してきたが、あれほど狭い環境はなかった。 ■それでも人は増え続ける そんな極限の環境にもかかわらず、人はさらに増えていく。気づけば周囲は知らない人ばかりだ。プロジェクトの一体感というより、“流入する人波”に近い。 膝をすり合わせながら、コードを書く。テストをする。...

うわっ…こんなにも“戦い方”が違うのか!? ■システム担当者という幻想 「システム担当者」と一言で言っても、その中身は驚くほど多様だ。 プログラマーと呼ばれる人たちも同じ。 パソコン一つで作業をする職種だからといって、全員が強く押し切るタイプとは限らない。 むしろ現場に入ると、その多様性に戸惑う。 前のプロジェクトでも、リードするイメージのなかった同期が、いつの間にか全体を引っ張っていた。 役割は肩書きでは決まらない。 現場での振る舞いが、その人のポジションを作る。     ■200人プロジェクトという“圧力” 社会人6年目。 私はMAX200人を超えるプロジェクトに入った。 規模が大きくなるにつれ、プロパーのメンバーも後から増えてくる。 組織は流動的で、常に変化し続けていた。 そんな中、隣のプロジェクトで中堅として活躍していた同期が、こちらに移ってきた。 彼は構成管理担当として加わることになった。 ■怒らない男の戦い方 彼を一言で表すなら——とにかく穏やか。 もしかしたら「怒る」という感情を知らないのではないかと思うほどだ。 人の話を真摯に聞く。 そして、ゆっくりと話す。 構成管理という役割は、各チームからの要望が集中する。 時には無理難題も飛んでくる。 それでも彼は、一つ一つ丁寧に耳を傾け、ゆっくりと回答を作っていく。 当然、時間はかかる。 彼はいつも終電だった。 一度、体調を崩して来られなくなったこともあったらしい。 「リハビリ期間なんだよ」と笑いながら話していた。 それでも彼は変わらなかった。 どんな時も、人に向き合う姿勢を崩さなかった。 ■理想と現実の狭間で 正直に言えば、私は迷っていた。 彼の姿勢は、間違いなく見習うべきものだ。 だが、仕事が山積みのプロジェクトで、そのやり方は成立するのか。 スピードが求められる現場で、丁寧さは時にリスクにもなる。 私たちは、終電まで並んでパソコンを叩く日々を過ごした。 彼がいてくれて良かった。 話を聞いてくれる存在がいるだけで、抱え込まずに済んだ。 だが同時に思う。 一度来られなくなった後、リハビリと言いながら終電まで働くこの状態は、本当に正しいのか。 ■正解のない世界で この世界に、明確な正解はない。 速さで押し切る...

うわっ…巨大組織の心臓が、こんなに小さいなんて誰が想像できるだろうか！ ■社会人6年目、想像していた「大組織」 社会人6年目。私は、日本の金融業界の中心を支える基幹システムのプロジェクトにアサインされた。 規模は200人超。複数ベンダーが参画し、名だたる企業が並ぶ。 「これは完全に、大組織での分業戦だな」 そう思っていた。日立のプロパーも多数入り、重厚なマネジメント体制が敷かれている——はずだった。     ■びっくりするほど“小さい本体” しかし、現場に入って目にした光景は、まったく違っていた。 机の一列に並ぶ、たった6人。 部長はそこにはいないが、その席の横に、課長、主任3人、担当2人。 この6人が、すべてを回していた。 周囲には確かに人がいる。 ベンダーは4社、それぞれ平時でも20名以上。 開発ピーク時には、テスト要員も含めて200人を超える。 だが、意思決定と全体制御は、この6人に集約されていた。 「本体は、ここか…」 その瞬間、プロジェクトの構造が一気に見えた。 ■構成管理チームという“中枢神経” そんな中、私は新たに切り出された構成管理チームを任された。 理由は明確だった。Java化による構成の複雑性。 だが、すぐに気づく。 これは単なる「構成を管理する仕事」ではない。 各チームごとに開発スタイルが違う。 ビルド方法、ブランチ戦略、リリース手順——すべてがバラバラ。 つまり、必要なのは統制ではなく「調整」だった。 ■本当の仕事は“すり合わせ” 構成管理とは、コードを管理することではない。 チーム同士の前提を揃え、衝突を防ぎ、全体最適に導くこと。 4社のベンダー、それぞれの文化。 20人単位のチームが複数動く中で、わずかなズレが致命傷になる。 私は、構成を通じてそれを繋ぐ役割だった。 「ここ、どう合わせます？」 その一言が、プロジェクト全体のスピードを変える。 ■6人が200人を動かす理由 なぜ6人で回るのか。 答えはシンプルだ。 ・意思決定が速い ・構造を理解している ・全体を俯瞰できる 人数ではない。 構造と役割が、すべてを決める。 そして、その中に「調整役」が組み込まれていること。 これが、巨大プロジェクトを動かす本質だった。 ■身震いした責任と、...

うわっ、終わったはずのプロジェクトが、いまだに頭の中で続いている――。 ■プロジェクトは「長さ」で記憶に残るのか 社会人になってから、いくつものプロジェクトを回してきた。 短いものから長いものまで。 短くて2、3か月、長くて2年以上。 やはり記憶に残りやすいのは長いプロジェクトだ。 そりゃそうですよね。 時間をかけ、苦労し、乗り越えた分だけ、思い出は濃くなる。 しかし、例外もある。 短いのに、妙に強烈に残るプロジェクトがあるのだ。 ■3か月で終わった、終われなかったプロジェクト 今回のプロジェクトもそうだった。 わずか3か月で離れることになった案件。 正直、悔しかった。 「役に立ちませんでしたよ」と言われているような気がしたからだ。 もちろん、そんなことはない。 理由はシンプルで、部署間の取り決め。 最初から「いついつまで」という約束が決まっていた。 直前に一つのプロジェクトをやり遂げていた私は、 次も活躍できる自信があった。 だが現実は違った。 ■“関われるのに、踏み込めない”という制約 契約上、メインタスクには関われない。 意思決定にも深く入れない。 できることは、情報を伝えること。 補足説明をすること。 私は、できる範囲で動いた。 説明会の資料作成を手伝い、 何かあればアドバイスをする。 しかし、それ以上は踏み込めない。 目の前では、同期がメインでプロジェクトを回している。 明らかに忙しい。 助けたい。 でも、リードが取れない以上、 そのタスクをカバーすることはできなかった。 ■やり切れなかったという違和感 そして、3か月。 私はプロジェクトを離れた。 形式的には「完了」。 しかし、感覚としては「未完了」だった。 何か引っかかる終わり方。 やり切った感覚が、まったくない。 ■その後に知った“もしも”の連続 そのプロジェクトは、その後も何年か続いた。 そして、かなりドタバタしていたらしい。 作り直し。 方向転換。 混乱。 話を聞くたびに、こう思ってしまう。 あの時、もう少し踏み込んでいれば。 あの時、自分の手を動かしていれば。 何か変えられたのではないか。 もちろん、後からなら何とでも言える。 契約や役割の制約は現実だ。 それでも、この「心残り」は消えない。...

多重下請けプロジェクトで見えた、“開発ではない仕事”の正体 うわっ、リーダーってこんなに“作業”しているのか――そう思った瞬間があった。 金融機関のシステム開発プロジェクト。 社内フレームワークを適用した、約1年の開発案件だった。 Webとバッチ。 ベンダーは2社。 さらにテスト工程から、中国系ベンダーも入ってくる。 ここまでは、よくある大規模開発の話だ。 しかし構造を少し見ると、別の姿が見えてくる。     多段ベンダー構造という現実 一次受けは我々。 開発ベンダーは二次受け。 だが、その内部には三次受け、四次受けが存在していた。 つまり、 非常に多段の構造 になっている。 当然、それぞれの層に リーダー がいる。 では、この多くのリーダーたちは 何をしているのだろうか。 コードを書いているのだろうか。 実際の仕事は「調整」だった 実際には違った。 確かに半分は開発をしている。 しかし、それ以上に時間を使っていたのは 管理と調整 だった。 誰がいつ入るのか。 人数は足りるのか。 席はあるのか。 パソコンは足りているのか。 開発スキルは十分なのか。 そんな人員調整をひたすら行う。 さらに、 3カ月のテスト見積もり。 見積もり根拠の説明。 その後の交渉。 そして契約。 夜には、関係を作るための飲み会。 気づけば 開発よりも、はるかに多くの作業をしている。 見えてきた構造 ここで一つの疑問が浮かぶ。 リーダーとは 開発者なのだろうか。 それとも プロジェクトを成立させる調整役なのだろうか。 構造再定義 少し構造で整理してみたい。 表面の問題 リーダーの仕事が多すぎる。 しかし本質は違う。 本質的ボトルネック 多重下請け構造では 開発よりも 組織間調整コスト が増える。 つまり リーダーの仕事は 開発ではなく 関係の調整 になっていく。 リーダーの本当の役割 ここでリーダーを再定義すると リーダーとは 複雑な構造を動かす存在 なのだ。 異なる会社。 異なる契約。 異なる文化。 これらをつなぎ プロジェクトを前に進める。 そのため リーダーの仕事は コードを書くことではなく 制御できない要素を扱うこと ...

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

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

― 作ったプラットフォームに、人生まで巻き込まれた話 ― うわっ、気づいたら“評論家”のはずが“徹夜組”の一員になっていた！ 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 社内コンサルとしての使命 私は、自分が作ったプラットフォームを社内に浸透させるため、いわば“社内コンサル”の立場に立っていた。 使い方を説明し、思想を語り、未来の運用まで見据えた設計を求める。 さすがプラットフォーム。 検討しにくい細部、もっと先の運用フェーズで問題になる論点まで、設計段階で考えることを前提としている。 私は、それでいいと思っていた。 自分が作ったものだからこそ、その理想に疑いはなかった。 ■ しかし、現実のプロジェクトは甘くない そのプロジェクトは、人が少ない。 設計する人も足りない。 プログラミングする人も足りない。 深夜残業が常態化していた。 私は社内コンサルとして、設計レビューをし、使い方を教えていた。 だが、そもそも設計に必要な情報がない。 開発プロジェクトは情報が少ない。 顧客側も、作る人と運用する人は別。 ベンダー側も、開発担当と運用サポートは別。 だから、運用の要望や将来の課題は、設計段階ではほとんど出てこない。 それでも私は言う。 「運用まで考えましょう」と。 だんだん、言いづらくなってきた。 この状況で“コンサルです”とは。 ■ 手を出すという決断 人は少ない。 検討すべきことは多い。 となると、自分もやるしかない。 私は設計に手を出し始めた。 プログラミングにも手を出した。 研修も受けてきたし、一定の自信はある。 だから、やれる。 そう思った。 そして、ふと気づいた。 自分もしっかり深夜残業組の仲間入りをしていた。 ■ コンサルか、リーダーか コンサルは“答えを示す人”。 プロジェクトリーダーは“背負う人”。 私はどちらなのか。 でも今は、役割よりも大事なものがある。 プロジェクトを前に進めること。 理想と現実の間を埋めること。 助言だけでは、未来は作れない。 手を動かしてこそ、信頼は生まれる。 だから私は、両方やる。 考え、設計し、書き、支える。 私ならできる！明日から踏み出す

新人講習と同時に始まった、静かな覚悟の物語 うわっ、ここで体制発表!?――思わず背筋が伸びた瞬間だった。 新人講習のリードを任されることになり、同時にチーム体制が発表された。内容を聞きながら、これは単なる役割分担ではない、と直感した。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       支える人たちが、すでに決まっていた 体制の中心には、社内でも「優秀」と評判の女性課長。その隣には男性課長がサポート役として控える。安心感のある布陣だった。 さらに、前回の技術サポートを担っていた先輩2人が、今回は「支援」という立ち位置で入る。全体として、守りは堅い。 実際に動くのは、たった2人 だが、実務を回していくのは2名だけ。 ――私と、1人の先輩。 その先輩は女性だった。女性が普通に活躍している会社なので、2人チームが女性×男性でも、正直まったく驚きはなかった。 リーダーは先輩。担当と実務は私。役割は明確だった。 一番の難題は「時間」だった やってみて分かったが、一番大変だったのは作業量ではない。時間の配分だった。 先輩は育休明け。お子さんはまだ2歳。勤務は時短で、10時から16時まで。 さらに、極度の関節症を抱えており、ひどいときは動けないこともあるという。 最初に打ち明けてくれたこと その事情を、先輩は最初に正直に話してくれた。 だからこそ、基本作業も説明も、私がやらなければならない。 ただ、その時点では「それがどういう意味を持つのか」を、正直よく分かっていなかった。 見えていなかった、自分への影響 「先輩、大変だな」 そう思ってはいた。でも、自分の作業にどれほど影響するのかまでは想像できていなかった。 やるほどに、自分が前に出る場面が増えていく。その現実に、少しずつ気づき始めた。 それでも、一緒にやる理由 それでも――先輩は、驚くほど熱意があった。 限られた時間の中でも、チームのこと、新人のことを本気で考えている。その姿勢が、はっきり伝わってきた。 「この方と一緒に、夏の最後まで乗り切るんだ」 そう腹をくくった瞬間、体制の意味が腑に落ちた。 チーム体制は、覚悟の設計だ チームの体制は、単なる配置ではない。 誰が前に立ち、誰が支え、どこで踏ん張るのか。その覚悟まで含めて設計さ...

リーダーシップに国境はない？違いの中に見つけたヒントとは 「わあ…なんでこんなに、みんなスマートなの⁉」 これは、私が初めてグローバルなチームの会議に出たときの率直な感想です。 言葉だけでなく、立ち居振る舞い、場の読み方、ユーモアの入れ方まで、国際舞台のビジネスマナーがにじみ出ていて圧倒されました。 グローバル企業に勤めて数年、いろんな国籍の同僚と仕事をするなかで、ふと気づくことがあります。 それは――**日本人リーダー、少なくない？**ということ。 もちろん能力がないわけではない。むしろ、技術力や勤勉さ、プロ意識は抜群です。 でも、なぜかグローバルの“前線”に立っているのは、アメリカ、ヨーロッパ、インドなど他国の同僚が多い印象です。 「この人、どこの出身なんだろう？」の正体 面白いのは、彼らの出身国を正確に把握できていないことが多いということ。 なぜなら、育った場所や文化背景が複雑な人が多いんです。 「生まれは〇〇、育ちは××、学生時代は△△、今は□□に住んでる」なんてのはよくある話。 でも、そうした多国籍・多文化のシャワーを浴びてきたからこそ、“違い”に敏感でありながら、“共通点”を見つけるのが上手いんです。 違いを超えるリーダーシップ たとえば、飲み会で出てきたちょっとクセのある料理に対しても、彼らは決して嫌な顔をしない。 宗教的な理由で食べられない食材がある人も、さりげなくメニューを調整して場を壊さないようにする。 気候やトイレ、交通の不便さ、どれも文句ひとつ言わずに対応してしまう。 そう、 文化の違いを前面に出さず、でも決して無視せず、静かに尊重する ――これが彼らの強さなんです。 文化に「依らない」軸を持つ 多国籍メンバーを率いるリーダーたちは、文化に過度に頼らず、 文化に依存しない共通のゴール を持っています。 「みんな違って、だから面白い。でも、目的は一緒」 その軸があるから、会話が曖昧にならず、行動がブレず、信頼されるのだと思います。 特に、アメリカやヨーロッパ出身のリーダーは、州や国の違いを乗り越える経験が多いようです。 でも、アジアだって同じはず。たくさんの国や文化に囲まれていて、私たち日本人も十分“異文化耐性”を育てられるはずなんです。 私たちだってできる。 言葉や文化が違っても、人の気持ちを...

PDPDになってません？ そんな衝撃の一言から、私の視界が一気にクリアになった。 あれだけ毎年“PDCAを意識して仕事をしています”と言っていた自分が、実は大事な“C”をすっ飛ばしていたなんて――。 そもそもPDCAって？ Plan（計画） Do（実行） Check（評 価） Action（改善） この流れで物事を回していく「PDCAサイクル」は、ビジネスの基本。学生時代に初めて教わり、社会人になってからも常識のように使ってきました。 毎年、年初には目標を立て、業務をこなしながら、年末には振り返る。 「よし、今年もPDCAを回せた！」と、達成感すら感じていたのです。 事件はネットワーキングの場で起きた そんな自分に、ある日、ネットワーキングイベントで出会った方がこんな質問を投げかけてきました。 「PDCAの“C”、ちゃんとできてます？」 反射的に「はい」と答えかけたその瞬間、頭が真っ白に。 “チェック”って、何をどうやってやってるんだっけ？ 実はやってなかった“Check”の実態 思い返すと、自分の「チェック」はほぼ感覚的なものでした。 たしかに「去年よりマシ」「お客さんに怒られなかったからOK」など、なんとなくのフィードバックはしていたつもり。 でも、それって本当に“評価”だったのか？ 数字で見た？誰かと話した？フィードバックを受けた？ そのどれもが曖昧で、心の中に「評価なんてしてないかもしれない」という不安が広がった瞬間でした。 「壁打ち」という魔法の時間 そんなタイミングで、偶然参加したのが「すごい壁打ち」という本の著者が主催するセミナー。 壁打ちとは、アイデアや悩みを誰かにぶつけてみて、思考を整理するための対話。 Planしたこと、Doでやってきたこと、今Doしていること。 それらを人に話し、返ってくる何気ない一言が、自分では気づかなかった「Check」になったのです。 PDPDに陥る人が多い理由 一人で仕事をしている人ほど、PDCAの“C”を抜かしがちです。 振り返っているつもりでも、それは“自分都合の解釈”にすぎないことが多い。 だからこそ、「誰かに話してフィードバックをもらう」というシンプルな行動が、サイクルをきちんと回す鍵になるのです。 さっそく実践！「壁打ちCheck」のすすめ 試しに、身近な人や普段関わらない他部署の人でも...

DX推進の最大の壁、それは"人"だった！💥 「DXなんて意味あるのか？」 「俺たちはこのやり方でやってきたんだ！」 こんなセリフ、聞いたことありませんか？ DXを進めようとすると、50代・60代の上司や経営陣から反対意見が出て、プロジェクトが進まない…そんな経験をしたことがある人も多いでしょう。 でもちょっと待ってください。本当に彼らは「老害」なのでしょうか？ 実は、彼らこそ 「日本のDX第一世代」 なのです！ 📌実は彼らもDXを経験してきた！？ 今の50代・60代の方々は、これまで数多くの技術革新を乗り越えてきました。 ✔ FAXの導入 ：手書き書類からFAXへの移行 ✔ 電話のコードレス化 ：固定電話から携帯電話へ ✔ Windowsの導入とアップデート ：DOSからWindows95、XP、7、10へ ✔ クラウド化 ：オンプレミスサーバーからAWSやAzureへの移行 これらの変化は、当時の彼らにとって 「DX」そのもの だったのです。 彼らの「やりたくない」という気持ちは、 「過去に経験した苦労」や「失敗の記憶」 に基づいている場合が多いのです。 🛑「老害」と決めつけるな！経験を味方につけよう 「どうせまた無駄に終わるんじゃないのか？」 「昔やったけど、うまくいかなかったぞ」 こんな発言が出たら、 チャンス！ 彼らは単なる反対派ではなく、実は 「貴重なアドバイザー」 になり得るのです。 彼らの経験には、 失敗、成功、後悔、反省 などが詰まっています。その意見を無視せず、むしろ積極的に取り入れることで、より成功しやすいDXが可能になります。 例えば、こんな風に聞いてみましょう。 🗣「当時はどういう課題があったんですか？」 🗣「その失敗を活かして、今回うまく進める方法はありますか？」 敬意を持って話を聞き、対話をすることで、彼らの 「俺たちの時代とは違うな」 という納得感を引き出せます。 👥20代でもDXに反対する！？「冷めた目」の正体とは DXに懐疑的なのは、50代・60代だけではありません。 実は、20代・30代の中にも「DXに興味がない」「今のままでいい」という人がいる のです。 彼らは、DXの本質を理解していないだけかもしれません。 DXとは単...

 やばい！初めてのプロジェクト管理で、もうキャリア崩壊かと思った…！ 私が初めてPM（プロジェクトマネージャー）を任されたとき、経験者が「できるよ、簡単だ！」と言っていたにもかかわらず、実際は数々の落とし穴にぶつかりました。ここでは、私自身が体験した【3つの失敗】とその回避策をストーリー仕立てでご紹介します。 ① 締め切り設定を怠るな！ 経験者の「できるよ、簡単だ！」という言葉に甘え、 締め切りを設定せず に進めた結果、プロジェクトはどんどん遅延。 「もっと余裕があるから大丈夫」と言ってしまった自分を悔やみました。 教訓： 必ず具体的な締め切りを設定し、進捗を定期的にチェックすることが成功への鍵です。 ② 状況把握と計画の甘さに注意！ 「状況を完璧に把握できないから計画は無理…」と諦めるのは、単なる 責任回避 です。 実際、私のプロジェクトでは、初期段階で情報を十分に集めず、曖昧な目標で始めたため、途中で迷走しました。 解決策： 分からない部分があっても、最低限の目標計画は立て、疑問点は徹底して質問しましょう。声が大きい人に惑わされず、冷静に事実を確認する姿勢が大切です。 ③ 自分で理解し、完遂する覚悟を持て！ 「僕は初めてだから、周りに経験者がいるから大丈夫！」と楽観視した結果、責任を他人に丸投げしてしまったのが失敗の原因でした。 失敗から、 自分自身で問題を理解し、解決策を考え、成果を出す 覚悟が必要だと痛感。 また、プロジェクト途中でスケジュールを延ばすのは最終手段。 計画通りに進める ためには、状況変化に柔軟に対応しつつも、スケジュールを最優先に守ることが不可欠です。 まとめ：PM初心者は基本に忠実に、そして自信を持て！ 締め切り設定を徹底 ：計画は具体的な期限があってこそ実行可能。 状況把握は重要 ：不明点があれば、どんどん質問し、明確な目標を立てよう。 自分の力で完遂する覚悟 ：経験者に頼りすぎず、自らの理解を深め、成果を出す。 スケジュール厳守 ：延長は最終手段。予定通り進むことが成功の鍵！ これらの教訓を胸に、PM初心者でも確実にプロジェクトを成功に導けるはずです。失敗は成長の糧。今すぐ、この基本を実践して、あなたのキャリアを飛躍させましょう！