Digital Heroes: Guide to IT World

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

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

マジで！？中小企業診断士の試験、やばすぎる！ かつて、私も何度も挑戦し、幾度も壁にぶつかりました。試験は本当に厳しく、合格するためには何度も失敗を経験。最後に合格できたとき、思わずとんかつを頬張りながら涙を流したほどです。この苦い経験が、今の私のキャリアと人生観を大きく変えました。 試験の苦悩とその価値 中小企業診断士の試験は、全体的な構造化と論理的思考力を問われるため、ただ単に知識を詰め込むだけでは乗り越えられません。 難易度の高さ ：私自身、数回の不合格を経験しました。合格できたのは、失敗から学び、試験問題の構造を徹底的に分析した結果でした。 実例に基づく問題 ：各サービス企業の事例が盛り込まれ、実際のビジネス現場を想定した複雑な問題が多く出題されます。これにより、単なるテスト以上の実務に近い知識とスキルが求められるのです。 この試験に挑んだ経験は、単に資格を得るためのものではなく、 自分自身の論理的思考力と状況把握能力を飛躍的に伸ばす貴重なトレーニング となりました。 資格取得後の別世界―新たなキャリアの扉 資格を取得した瞬間、私は全く別の世界に足を踏み入れたことに気づきました。中小企業診断士協会や各支部に所属し、そこから仕事依頼が舞い込み、企業の経営改善に貢献する場が広がります。 コンサルティングの現場 ：実際、コンサル企業が依頼を受け、チームで対応しているのと似た構造を持ちます。しかし、中小企業を対象としているため、案件の金額は大手コンサルに比べると低いのが現実です。 キャリアとしての厳しさ ：中小企業診断士だけで生活するのは容易ではありません。しかし、ITを中心にキャリアを積む場合、取得した経験は日本企業で大きなアドバンテージとなります。 また、グローバルな視点で見ると、MBAの方が知名度は高いかもしれませんが、 日本国内においては中小企業診断士の知識と経験は絶大な価値 を持ちます。私の体験は、試験そのものが非常に難しく、現実に即した問題が出題されるからこそ、実務に役立つ力が自然と身につくということを実感させてくれました。 グローバル市場との認識の違いと今後の展望 世界では、MBAが広く認知され、グローバル企業での評価も高いですが、日本では中小企業診断士も根強い支持を受けています。 グローバルな評価 ：今後、海外でも日本の高い技術力や経営手法に対する関心...

マジで、こんなにシステムが乱立してる中、プロジェクトが上手くいくと思ってるの？ ある日、私が担当した大規模ITプロジェクトは、各部署の独自システムと連携不足で大混乱に陥りました。会議は朝・昼・夜、飲み会も含めたコミュニケーションがなければ、プロジェクトは必ず失敗します。そこで、私は 「話すこと」 の重要性に気づき、毎日の定例ミーティングや、非公式なランチ、夜の懇親会でしっかり意見交換を行うようにしました。 コミュニケーションこそ、成功の鍵！ まずはチーム内の役割を明確にし、得意分野の人にタスクを任せることが重要です。あるプロジェクトでは、社内のエンジニアと外部ベンダーの役割があいまいで、連携ミスが頻発しました。そこで、内部メンバーを最優先にし、外部は契約金額に応じたサービスとして位置付け、意思決定者への報告も頻繁に実施。これにより、情報の齟齬を防ぎ、プロジェクト全体の方向性を常に共有できるようになりました。 計画と報連相が未来を変える！ また、プロジェクト管理では、Excelで体制図やタスクの進捗、リスク管理を行い、全体の構造化を徹底しました。特に、Project Charter（プロジェクト憲章）は、迷ったときの原点。これを見返すことで、目的や優先順位が明確になり、モチベーションを保つ原動力となりました。私自身、何度も問題が発生した際には、冷静に報告・連絡・相談（報連相）を実践し、必要な場合は厳しい覚悟でチームやベンダーを外す決断も下しました。 楽しい環境作りがチームを強くする！ そして、チームの士気を高めるために、オフサイトミーティングやパーティ、特別休暇を取り入れ、全員がリフレッシュできる環境作りにも力を入れました。結果、プロジェクトは予定通り進行し、最終的に大幅なコスト削減と高い成果を実現することができました。 まとめ 話すことを最優先 ：毎日の会議や飲み会でしっかりコミュニケーション 役割の明確化 ：得意分野の人に任せ、社内とベンダーを明確に区別 計画と報連相 ：Excelで全体を整理し、Project Charterに立ち返る 楽しい環境作り ：オフサイトやパーティでチームのモチベーションアップ これらの基本を守ることで、どんな大規模プロジェクトも成功へと導くことができます。リーダーシップは、ただ命令するだけでなく、チーム全体の心理を読み、未来を共に描く...

やばい…システム乱立でカオス！ これは、多くの企業が直面しているリアルな問題です。営業部門が選んだCRM、経理部門が導入した会計システム、現場が使いやすいと判断した管理ツール…。気がつけば、各部署がバラバラにITを導入し、つながらないデータ、増え続けるコスト、複雑化する運用が企業全体の足かせになっている。 その結果？ ベンダーの言いなり！ 「このツールが便利ですよ」「最新のクラウドサービスを入れましょう！」と次々に提案されるままに導入。結局、システムが増えるばかりで、最適化されるどころか、逆に業務が複雑になってしまう…。 この状況を打破するために必要なのが、**Enterprise Architecture（EA：エンタープライズアーキテクチャ）**の考え方です。 EAとは？企業ITの"設計図" EAとは、簡単に言うと 「企業全体のITの設計図」 です。 例えば、家を建てるとき、 どこに何の部屋を作るのか？テレビは何台必要か？古い冷蔵庫はそのまま使うか？新しいものに買い替えるか？ といった全体の計画を立てますよね。 企業も同じ。 どのシステムを使い、どのデータを統合するか？ 古いシステムは廃止するのか？ 最新のテクノロジーは本当に必要なのか？ こうした戦略をしっかりと設計するのが、 EAの役割 なのです。 EAの目的は「DX」ではない！ 最近のトレンドとして「DX（デジタルトランスフォーメーション）」が叫ばれていますが、EAの目的はDXそのものではありません。企業の最終的なゴールは、 「利益を上げ、コストを下げること」 。 DXはあくまで手段であり、「最新技術を使うこと」自体が目的ではないのです。 むしろ、無駄なシステム投資を削減し、統合や最適化を進めることで 「最小のコストで最大のパフォーマンスを発揮できる企業IT」 を実現することが、EAの本質です。 EAの視点を持つエンジニアは少ない！ 残念ながら、日本企業で EAの観点を持っているエンジニアは本当に少ない のが現実です。 多くのエンジニアが、 システム単位での最適化 には目を向けるものの、 経営全体の視点でITを考える ビジネス戦略とITをつなぐ こうした視点を持っている人はほとんどいません。 だからこそ、EAを理解し、企業のために 本当に必要なITを考えられるエンジニア の価...