Digital Heroes: Guide to IT World

専門を超えて、構造をつくる仕事の話 えっ!? その質問、そこに来る!? 私は、昔から自分のことを「システム屋」と呼んでいます。ところが、そう名乗ると、決まって返ってくる質問があります。 「で、システムのどの部分ですか？」 これ、ちょっと考えると不思議なんですよね。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       建築家には聞かれない、不思議な質問 例えば、建築の世界。 「建築をやっています」と言った人に対して、「どの部分ですか？」と聞くでしょうか。あまり聞かないはずです。 建築には、解体、基礎、コンクリート、左官、電気、水道など、数えきれない技術が絡みます。一級建築士や二級建築士、プロジェクトマネジメントの専門家もいれば、実際に手を動かさない人たちも含め、多くの人が関わっています。 それでも「ビルを建てています」と言えば、それで通じる。 どこか一部分だけを指しているわけではないからです。 私が歩いてきた“全般”の道 私は、プログラマーからキャリアを始めました。 次にDBを得意分野にし、ネットワークを学び、ハードやサーバ構成も勉強しました。さらに統計解析にも取り組んできたので、AIと言われても基礎技術は一応理解しているつもりです。 AWSのエンジニアと話しても、全般的な話ができます。 そして、その全般が分かった上で、PMをやってきました。 正直、それがシステム業界では「普通」だと思っていたんです。 「システム担当」って、そういう意味じゃないの？ だから「システム担当です」と答えるとき、 私はその全般知識があるものとして話していました。 さらに、全体を俯瞰してシステムポートフォリオを考える、エンタープライズ・アーキテクトの考え方も学んできました。 なので、システム関係であれば、上から下まで話せる。 「システム担当って、こんなもんだろう」と思っていたんです。 分けられると、なんだか違和感が残る ところが個人事業として話をすると、 「プログラマーですか？」 「DB担当ですか？」 「ネットワークですか？」 と聞かれます。 いやいや、それだけじゃない。 DBだけでシステムは動かないし、ネットワークがつながっても、どう使うかがなければ意味がない。 だから私は、全般なの...

プロジェクトが迷走!? そんな時、救世主となるのがEAだ！ システム開発の現場で、「仕様変更が多すぎる」「ビジネスと技術が噛み合わない」「プロジェクトが炎上している…」なんて経験、ありませんか？ その混乱の裏には、 Enterprise Architect（EA）の不在 が影響しているかもしれません。 では、大規模プロジェクトにおいて、EAはどんな役割を果たすのか？ PMとは違う、EAならではの視点 とは？ 今回は、EAの重要性を ストーリー仕立て で解説します。 🌀 混迷するプロジェクト、EAなしでは進めない!? 「システムの要件が増えすぎて、もうカオス状態です…」 プロジェクトマネージャー（PM）の田中さんは、毎日のように 増え続ける変更リクエスト に頭を抱えていました。 ビジネスサイドは「競合に負けないように、もっと機能を追加して！」 開発チームは「技術的に無理です、そんなこと急に言われても…」 このままではプロジェクトは破綻する。 そんなとき、EAである佐藤さんが立ち上がります。 「このまま進めたら失敗する。そもそも、プロジェクトのゴールは何か？」 EAは、 ビジネス、システム、業務オペレーションをつなぐブローカー 。 プロジェクトの目的を明確に意識し、全体の方向性を正すのが仕事です。 🎯 EAの役割①：ビジネスとITの架け橋となる EAがいなかった頃、ビジネスサイドは要望を次々に出し、開発チームはそれに振り回されるばかり。 しかし、佐藤さんが間に入ることで、ビジネスの意図を整理し、 「本当に必要な要件」 を抽出。 さらに、「この機能は本当に今必要なのか？」「代替案はないのか？」と議論を進め、 ビジネスとITのズレを修正していきます。 その結果、 プロジェクトはより現実的で実行可能な計画へと軌道修正 されました。 🛠 EAの役割②：全体システム構成を統括する 佐藤さんは、単なる技術屋ではありません。 プロジェクトの全体システム構成を管理し、各ソリューションアーキテクト（SA）を束ねるのも重要な役割です。 「各モジュールの連携はどうする？」 「このシステムは将来的にスケールできるか？」 個別の機能だけでなく、システム全体がスムーズに動くように設計するのがEAの腕の見せどころ。 技術的な視点とビジネスの視点を組み合わせ、 持続可能なシステム構築をリー...