【上流】現場リーダーの勘所– tag –
設計・サイジング・ベンダーコントロールなど、プロジェクトを動かす立場になったあなたへ。200台規模のサーバーを守る現役サービスマネージャーが、経営層を納得させる論理的な設計手法や、チームの出力を最大化するマネジメントの真髄を惜しみなく伝授します 。
-
「その観点は?」の突っ込みを防ぐ!AIを最強の設計書レビュー相手にする方法
こんにちは!『となりのインフラエンジニア』の管理人です。 設計書を書き上げたとき、みなさんはどんな気持ちになりますか?「よし、完璧だ!」と思ってレビューに臨んだのに、先輩やマネージャー、あるいは組織の上位層から「この観点、 考慮漏れてない... -
18年の結論。なぜ「丸投げ」は失敗するのか?ベンダーを最強の味方に変えるコントロールの極意
インフラエンジニアとして歩み始めて18年。数えきれないほどのプロジェクトを経験し、多くのベンダーと肩を並べて働いてきました。若手リーダーになると避けて通れないのが「ベンダーコントロール」という壁です。 「プロに任せているんだから、よしなにや... -
オンプレからクラウドへ!インフラ移行計画の教科書|PM・リーダーが押さえるべき確認観点リスト
インフラ移行プロジェクトにおいて、計画の成否を分けるのは技術力だけではありません。最も重要なのは、不測の事態を想定した「確実性」と「リスクコントロール」です。 本記事では、サービスマネージャーとして数多くの大規模現場を統括してきた視点から... -
【実録】300台のサーバが沈黙。システム障害対応の舞台裏でリーダーはどう動いたか
インフラエンジニアとしてキャリアを積む中で、避けては通れないのが「大規模システム障害」です。特に、物理レイヤの予期せぬ挙動は、時に冗長化構成という安全神話をいとも簡単に打ち砕きます。 今回は、私がかつて若手エンジニアとして経験した、「FCス... -
【プロ直伝】サーバーサイジングは「未来」で決まる。経営層を納得させる計算式と根拠
18年のキャリアで数々の「修羅場」を潜り抜けてきたインフラエンジニアのもっちです。 若手リーダー(3〜5年目)の皆さん、サーバーのスペックを決めるとき、根拠を論理的に説明できていますか?「なんとなく多めに」というサイジングは、オンプレミスなら... -
「良かれと思って」の無償対応がチームを潰す。運用リーダーが持つべき「コストとサービス全体像」の感覚
「これ、ついでにやっておいてもらえる?」 顧客や他部署からのそんな一言に、あなたは「いいですよ」と即答していませんか? かつての私はそうでした。「技術的に可能だし、喜んでもらえるなら」と、無償で対応し続けることが正義だと思っていました。し... -
障害対応で試されるリーダーシップ。技術力よりも「判断」と「責任」が重要な理由
「誰よりも技術に精通しているはずの自分が、なぜか現場を混乱させてしまう」 障害発生の報を受け、真っ先にコンソールを開き、ログを追い、ソースコードの迷宮に飛び込む。エンジニアとしてこれほど頼もしい姿はありません。しかし、ふと周りを見渡したと... -
リーダーの壁「自分でやったほうが早い」を突破する3ステップ チームの出力を最大化するマネジメント論
エンジニアとして現場を支えてきたあなたがリーダーになったとき、最初にぶつかるのが「自分でやったほうが早い」という壁です。 「メンバーに任せるより、自分が手を動かしたほうが正確だし、説明する時間も省ける」 特に10システム、200台規模のサーバを... -
「技術力」を「価値」に変えられないエンジニアの共通点 ― 評論家ではなく実業家であれ
エンジニアとしてキャリアを歩む中で、私たちは日々新しい技術を追い求めます。複雑なアーキテクチャを理解し、洗練されたコードを書く。それはプロとして当然の研鑽であり、素晴らしいことです。 しかし、現場でこんな場面に遭遇したことはないでしょうか... -
インフラエンジニアのための設計書入門【詳細設計編】〜現場で差が出る「パラメータシート」の作り方とレビューの極意〜
インフラ設計書には、大きく2つの設計書があります。ひとつは、インフラの「方針」や「骨格」を決める「基本設計書」、もうひとつは、システムの詳細なパラメータを記載する詳細設定書です。 今回は、システムの直接的な設計書であり、運用の現場では「正...
12



