「マネジメントなんてやりたくない」「部下やお金や人事評価なんて見たくない」—これに共感するエンジニアの方も少なくないのではないでしょうか。

話題の書籍[『マネジメントは嫌いですけど』](https://www.amazon.co.jp/%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AF%E5%AB%8C%E3%81%84%E3%81%A7%E3%81%99%E3%81%91%E3%81%A9-%E9%96%A2%E8%B0%B7-%E9%9B%85%E5%AE%8F-ebook/dp/B0DP3YZ9PV/ref=sr_1_1?adgrpid=169825428403&dib=eyJ2IjoiMSJ9.S8D2G2IuBFjBG7Oma8oBkNUYyx4Vk_xXKheqxruzSvrDAflsIsTXsT2aMhBUpHz6_clX79xd4WumP0ZJ5dhr47aik05L5QW8xegIZpeqn1Q.32yq6_hVXXmDH8dSlM7hHhkjgRZoztOyI8-9I762Zcw&dib_tag=se&gad_source=1&hvadid=720419435413&hvdev=c&hvlocphy=1009243&hvnetw=g&hvqmt=e&hvrand=18171975258697905984&hvtargid=kwd-2375687644985&hydadcr=4075_13378654&jp-ad-ap=0&keywords=%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AF%E5%AB%8C%E3%81%84%E3%81%A7%E3%81%99%E3%81%91%E3%81%A9&mcid=de97e7601ea7305b9f3780a6dc00e23b&qid=1745748651&sr=8-1)の著者である関谷雅宏氏は、マネジメントを「技術としてとらえる」という視点を提案しています。SIer(※System Integrater)のプログラマー/SEを経て、会社経営、CTO(※Chief Technology Officer)兼副社長、そして某通信会社のインフラ統括責任者まで務めた関谷氏に、エンジニアがマネージャーになる際の心構えや実践的なアプローチについて伺いました。

(※System Integrater 情報システムの企画、設計、開発、構築、運用、保守などを一括して請け負う企業)
(※Chief Technology Officer 最高技術責任者)

*■『マネジメントは嫌いですけど』*
出版社：技術評論社、著者：関谷雅宏

*■関谷 雅宏（せきや まさひろ） *
1962年生まれ。金融企業から始まり、小さなソフトハウスでプログラマーを経験。起業して15年間役員として会社を5人から200人規模まで拡大。CFOからCTO兼副社長まで経験。40歳を過ぎて某通信会社へ転職し、データベース、ミドルウェア、サーバ、OSなどインフラ全体の統括責任者を務める。現在は子会社の管理職として活動中。

## 「マネジメントに正解がある」というのは幻想

#### balloon kishi left
まず、本書のタイトルを『マネジメントは嫌いですけど』とされた経緯について教えていただけますか？

#### balloon sekiya right
このタイトルには、マネジメントに対する私の率直な思いが込められています。エンジニアとして入社した企業でマネジメント職は希望していなかったのですが、何故かマネジメントに任命されやらないとならなくなりました。どうにかして自分なりのマネジメントを実践する為に、考えついたのが**「管理」ではなく「技術」としてマネジメントをとらえ直す**ことでした。

#### balloon kishi left
マネジメントを「技術」として考えるというのは斬新な視点ですね。このアプローチはどのように生まれたのでしょうか？

#### balloon sekiya right
最初は世の中で推奨されている一般的なマネジメント手法を勉強しました。しかし、実践しようとしても、自分が望むような結果を得れるとは思えなかったのです。

#### balloon kishi left
具体的にどのような点が合わなかったのでしょうか？

#### balloon sekiya right
一般的なヒューマンマネジメントは「人で仕事をこなす」ことに焦点を当てていますが、特に**エンジニアの仕事は「技術で仕事をこなす」**ことになります。

#### balloon sekiya right
技術を身につけそれを使って問題を解決していくには「失敗する」ことや「間違う」のは当たり前のことで、そこから仮説を立て、実験し、計測し、結果を分析してまた仮説に戻るというサイクルをまわしていきます。これを行いやすくするためのマネジメントを試行錯誤していました。

#### balloon kishi left
具体的にどのような試行錯誤をされたのですか？

#### balloon sekiya right
一番技術力の高い人間に仕事をフルに当てはめることを制限したり、時間がかかったりしても、一人ではなく必ず技術力の低い人間とそれを補佐する人間のペアで対応をさせたりしました。また、仕事を早く片付けることに一番の価値を持たせず、「持続的に組織の力が高くなることに価値がある」と目的意識をかえるように試みました。

#### balloon sekiya right
仕事の成果を早く出すには技術力のある人間をフルに稼働させればいいのでしょうが、それには制限をかけましたし、そのうえで技術力の低い人間の底上げのほうへ稼働を振り分けるように仕向けました。一番大切な「仮説、実験、計測、仮説」のサイクルを実践することを教えるには、高い技術力を持つ人間とペアを組むのが一番良いからです。

#### balloon kishi left
「マネジメント」という言葉に対する一般的なとらえ方にも問題があるのでしょうか？

#### balloon sekiya right
そうですね。**「マネジメント」を「管理」と訳したことに根本的な問題がある**と思います。マネジメントをする人を日本語では「管理者」や「経営者」というようなイメージでとらえがちです。私は管理者としてのマネジメントに魅力を感じられませんでした。

#### balloon kishi left
なるほど、マネジメントに「正解がない」という考え方は救いになりますね。

#### balloon sekiya right
マネジメントに「正解がある」という思い込みが広がっている気がします。**マネジメントを行っている上司が何か言うと「上司は正解を知っていて、部下はそれを当てなければならない」と考えがちですが、上司自身も正解を知っていないことは珍しくありません。**

#### balloon sekiya right
そうなると、自分の失敗を認めることが難しくなりますし、失敗を元にしてより良いやり方を探すこともできなくなります。せっかく、エンジニアというより良い技術を探す能力のある人たちと仕事をしていくのであれば、それはもったいないことだと思いました。

## 「解決できる問題」だけ解決しようとする「解決病」とは!?

#### balloon kishi left
本書の中では「解決できる問題だけ対応して、間違いを認めない」という現象について触れられていますね。これはどういった問題なのでしょうか？

#### balloon sekiya right
私はこれを「解決病」と呼んでいます。**マネジメントを続けていると次第に消極的になり、解決しやすい小さな問題ばかりを処理するようになる現象**です。

#### balloon kishi left
なぜそのような状態に陥るのでしょうか？

#### balloon sekiya right
本質的な、難しい問題に取り組んで失敗した時に「よく挑戦した」と評価されることは少なく、「なぜできなかったのか」と責められることが多いからです。そのため「自分が解決できる問題」だけを問題として認識するようになり、本質的な問題ではなく解決できて結果を出せる問題にだけ対応するようになってしまいます。

#### balloon kishi left
その背景には組織的な問題もありそうですね。

#### balloon sekiya right
そうですね。マネジメントで行うことを「『人を動かして』『交渉力で』問題を解決するものだ」とする固定観念の影響もあります。交渉力を強くするためには「自分が正しい」という前提が必要ですから、間違いを認めることがマネジメント能力を下げる方向に働いてしまうのです。

#### balloon kishi left
「解決病」を克服する方法はありますか？

#### balloon sekiya right
私がおすすめしたいのは**「未来から逆算して考える」**ことです。これは、現在の制約条件や前提をいったん忘れて、理想的な状態から考え始める「ゼロベース思考」と呼ばれるアプローチです。

#### balloon sekiya right
例えば、24時間365日のシステム運用が必要な場合、「人間が疲れない方法」を探すのではなく、「人間が介在しないシステム」を構築するという発想の転換です。問題が根本的になくなった世界を想像し、そこから現在を見る視点で解決策を考えると、従来の「人を動かす」マネジメントでは得られない技術的な解決策が見えてきます。

## 組織成長のための「60・20・20の法則」

#### balloon kishi left
書籍の中で「アウトプット60%、技術の底上げと訓練20%、共有のための時間20%」という時間配分の考え方が非常に具体的で興味深いです。この配分について詳しく教えていただけますか？

#### balloon sekiya right
**「60・20・20」の配分はマネージャーに試してみてほしい、組織の持続的な成長と安定的なパフォーマンスを両立させるための試みです。**外部からの要求に全てのリソースを使いきるのではなく、組織の成長に必要な個人の底上げと情報の共有の時間を確保するという考え方です。同じ60%でも、個々の力と共有の仕組みが向上すれば、提供できる絶対値は自ずと上がるという狙いです。

#### balloon kishi left
全体の60%をアウトプットに使うというのは、通常より少ない印象ですね。

#### balloon sekiya right
一般的には「最大限の力でアウトプットする」という考え方が主流ですが、それでは力を消耗するだけで成長できません。**60%の力でアウトプットを安定して提供し続けることで、残りの時間を技術力向上と情報の共有に充てられるようにしました。**

#### balloon kishi left
20%を学習と底上げに使うのは相当な投資ですね。

#### balloon sekiya right
週40時間で考えると約8時間、つまり1日分の時間を学習に充てることになります。私がマネジメントを実践していた当時は、オラクルプラチナ認定資格（最上級の資格）などの高難度の資格取得も目標に掲げましたので、メンバーには負荷もあったと思います。しかし「この勉強は仕事の一部である」という位置づけを明確にしたことで、個々のエンジニアの技術力向上への取り組みが社内で正当化され、メンバーの意識も高まりました。

#### balloon kishi left
残りの20%はどのように活用されたのですか？

#### balloon sekiya right
平常時は「情報共有」のために使いました。集団で60%の力でサービスを提供し、20%を学習に使うには、個人の情報やスキルを組織全体で再利用できる仕組みが必要です。資料作成、進捗管理、分析ツール開発などに時間を割きました。また緊急時には、この20%を緊急対応に割り当てる方針でした。

#### balloon kishi left
「60・20・20」の考え方の効果はどうでしたか？

#### balloon sekiya right
長期的に見ると大きな効果がありました。個人の能力の絶対値が上がることで、60%のアウトプットで提供できるサービスの質と量も向上しました。外部の技術者の方々から褒められることもありましたし、新しいキャリアを目指して転職していった者もクラウド企業などで活躍していると聞いています。

## 進捗状況を「立体的な塗り絵」として可視化する

#### balloon kishi left
進捗管理については、「塗り絵のように面積で考える」という独自の方法を取り入れたそうですね。

#### balloon sekiya right
はい、個人的に既存の「線表」の進捗管理を補う為に行なっていました。一般的なガントチャートでは時間軸だけで進捗を管理しますが、それだけでは全体の作業の量や個々の難易度が見えません。

#### balloon kishi left
どのようなきっかけでこの方法を思いついたのですか？

#### balloon sekiya right
エンジニアのリーダーとして働いていたときに、プロジェクトの進捗について「あとどれくらい作業が残っているのか」という量的な把握が必要だったのですが、従来の線表では表現できませんでした。そこで考えたのが**「全体の仕事量を面積として捉え、完了した部分を塗り絵のように埋めていく」**という方法です。

~~『マネジメントは嫌いですけど』（技術評論社）より転載~~

#### balloon kishi left
具体的にどのようなメリットがありましたか？

#### balloon sekiya right
まず、作業全体の量の把握ができるようになりました。また、特に難易度の高い部分は「深く穴が空いている」ように表現することで、単純な面積以上の作業量があることも視覚化できます。特に技術的なプロジェクトでは、物理的に解決できない問題がボトルネックとなることがよくあります。

#### balloon kishi left
そういった技術的なボトルネックはガントチャートでは表現しづらいですね。

#### balloon sekiya right
そうなのです。例えば、ある機能の開発が「技術的に実現可能かどうか」不明な場合、ガントチャートでは単に期間を伸ばすしかありませんが、それでは問題の本質が見えません。**「塗り絵方式」では、そのような技術的な未解決部分を「深い穴」として表現し、チーム全体でその課題に集中できるようにしました。**

#### balloon sekiya right
実際にあった例では、あるデータベース処理が理論上可能でも実際には処理能力の限界を超えていた状況がありました。ガントチャートでは単に「進捗が遅れている」と表現されるだけでリソースを追加すれば対応可能なようにみえてしまっていたですが、「塗り絵方式」で「技術的に未解決の深い穴」として可視化したことで、「技術的な解決策を」探し出すことにリソースをさいて根本的な解決策を見出すことができました。

#### balloon kishi left
従来の時間軸だけの管理とはかなり違う発想ですね。

#### balloon sekiya right
**進捗のマネジメントは納期だけではなく、「期日までの仕事の量」の管理を行うことにあります。**納期は基本的に動かせないものですが、仕事の量と難易度を把握することで、「どの作業から着手すべきか」「どの作業は遅らせても良いか」「リスクの高い作業はどれか」といった判断ができるようになります。これにより「先に片付けても問題ない難易度もリスクも低い作業」を先にこなすことによって「時間の在庫」を作り出し、難しい課題に対応する余裕を作り出すことができます。

## 実践的な学びの場をつくる新時代のOJT

#### balloon kishi left
技術者の育成についても興味深い取り組みをされていますね。特に「教師を見つけて放り込む」というアプローチについて教えてください。

#### balloon sekiya right
**技術者の育成で最も効果的な第一歩は、優れた「教師」を見つけること**です。業界特有ではない世界で認知されている技術に関しては、社内で中途半端に教師を探すのではなく、実績があり複数の業界で経験豊富な技術コンサルタントなどとと契約し、教育も含めた役割を担ってもらいました。

#### balloon kishi left
従来のOJT（オン・ザ・ジョブ・トレーニング）とはどう違うのでしょうか？

#### balloon sekiya right
OJTは基本的に業界特有の技術や知識を身につけることが目的で生まれていると思います。現状の業務をトレースするだけでは広く世界で認知されるような技術の成長を望むことは難しいです。外部の優れた技術者を招き、実際の問題解決を通じて教育してもらう方法が、はるかに効果的でした。

#### balloon kishi left
具体的にはどのような取り組みが行われたのですか？

#### balloon sekiya right
技術コンサルタントと現場で問題解決に取り組む中で、報告書作成や分析作業を教わる側が担当する形式です。コンサルタントは全てを解決するのではなく、指導しながら一緒に作業します。これにより実践的な技術とアプローチ方法を学べました。

#### balloon kishi left
それを発展させた取り組みもあったそうですね。

#### balloon sekiya right
はい。経験を積んだメンバーには実際の事例をもとにした教材作成を依頼し、社内外への勉強会の開催、さらには擬似的な障害環境での訓練といった取り組みへと発展させました。特に興味深いのは「事故対応シミュレーション」です。実際の障害対応は最も学びが多いものの、事故が頻発しては困るため、コンサルタントに依頼して擬似的な障害環境を作ってもらいました。

#### balloon kishi left
教育において特に重視されていたポイントは何でしょうか？

#### balloon sekiya right
**「良い教師を探す」「学び合う環境を作る」「科学的思考を身につける」**の3点です。特に重要なのは、優れた技術者の「人間像」を自分の中にイメージできることです。座学だけでなく、実際の問題解決を通じて技術的アプローチや思考プロセスを学ぶことで、より深い技術理解と実践力が身につきます。

## マネジメントは、未来をより良くするための技術

#### balloon kishi left
最後に、エンジニアのキャリアパスについてのお考えを教えてください。

#### balloon sekiya right
**エンジニアの適切な評価や組織での位置づけに関する問題を根本的に解決するには、エンジニアの価値観を理解できる人がCFO(最高財務責任者)やCHO（人事責任者）などの経営幹部になる必要があると思います。**CTOやCEOだけでなく、予算や人事の意思決定にエンジニアの視点を反映できる人材が必要です。

#### balloon kishi left
小規模な組織と大きな組織では違いがあるのでしょうか？

#### balloon sekiya right
スタートアップではエンジニア気質のCEOが全体を統括していることも多いですが、組織が大きくなり出資者などが大きな発言権をもつようになるにつれて利益を求める傾向が主流になり、エンジニアの価値観が組織の中から消えていくことが見受けられます。エンジニアの視点を持ちつつ経営の意思決定に関われる人材が増えれば、エンジニアにとっての働きやすさも向上するでしょう。

#### balloon kishi left
関谷さんご自身は、マネジメントを通じて何を実現したいと考えていますか？

#### balloon sekiya right
**マネジメントの本質的な目的は「現実に変化を起こすこと」**だと考えています。過去は変えられませんが、未来は変えられます。現在は過去と未来の狭間にある柔らかな粘土のようなもので、遠くの未来を見据えながら現在の形を少しずつ変えていくことで、望ましい未来を作り出すための技術です。

#### balloon sekiya right
マネジメントは未来をより良くするための技術であり、それ自体も進化し続けるものだと考える人が増えてほしいと願っています。

「マネジメントなんてやりたくない」「部下やお金や人事評価なんて見たくない」というエンジニアの方も少なくないのではないでしょうか。今回は、書籍『マネジメントは嫌いですけど』の著者である関谷雅宏氏に、エンジニアがマネージャーになる際の心構えや実践的なアプローチについて伺いました。

大学卒業後、構成作家・フリーランスライターとして、幅広いメディア媒体に携わる。現在は採用関連のインタビュー記事や新卒採用パンフレットの制作に注力しながら、SaaS企業のマーケティングにも携わっている。いま一番関心があるのは、キャンプ場でワーケーションできるのかどうか。

岸 裕介

962年生まれ。金融企業から始まり、小さなソフトハウスでプログラマーを経験。起業して15年間役員として会社を5人から200人規模まで拡大。CFOからCTO兼副社長まで経験。40歳を過ぎて某通信会社へ転職し、データベース、ミドルウェア、サーバ、OSなどインフラ全体の統括責任者を務める。現在は子会社の管理職として活動中。

関谷さん

エンジニアがマネージャーになることへの心理的障壁と乗り越え方

マネジメントを「科学的アプローチ」で実践する試行錯誤の方法論

組織の持続的成長を実現する「60・20・20の法則」による時間投資戦略

「マネジメントに正解はない」。元CTOが語る”マネジメント嫌い”のエンジニアのための組織づくり実践ガイド

クラウドサービスの普及に伴い、多くの企業がAWS(Amazon Web Services)を利用したシステム構築を進めています。しかし、システム構築後の「運用」においては体系的な知識を身に着ける方法についてあまり周知されておらず、多くのエンジニアが手探りの状態で業務に取り組んでいるのが現状です。

本記事では、[『AWS運用入門 押さえておきたいAWSの基本と運用ノウハウ』](https://www.amazon.co.jp/AWS%E9%81%8B%E7%94%A8%E5%85%A5%E9%96%80-%E6%8A%BC%E3%81%95%E3%81%88%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84AWS%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%81%A8%E9%81%8B%E7%94%A8%E3%83%8E%E3%82%A6%E3%83%8F%E3%82%A6-%E4%BD%90%E7%AB%B9-%E9%99%BD%E4%B8%80/dp/4815615497)の著者である4名のAWSスペシャリストへのインタビューを通して、効率的にAWSを運用するための知識とノウハウをお届けします。

*■『AWS運用入門 押さえておきたいAWSの基本と運用ノウハウ』*
出版社：SBクリエイティブ
著者：佐竹陽一、山﨑翔平、小倉大、峯侑資
※同書の[改訂第2版](https://www.amazon.co.jp/dp/4815631085/)が2025年7月に発売になります。

## AWS運用における大きな課題は「知識の体系化」

#### balloon kishi left
AWSの運用において、どのような悩みを聞くことが多いですか？エンジニアが手探りで日々の運用を行っているという話もありますが。

#### balloon yamazaki right
手探りで運用すること自体は、必ずしも悪いことではありません。AWSをはじめとするパブリッククラウドサービスは日々サービスリリースや機能アップデートがあるので、運用手法は変化し続けています。昨日までの課題が、翌日のアップデートで解決するといったこともあります。

#### balloon yamazaki right
**本当に問題なのは、運用を任されているエンジニアの中で運用に関する知識が体系化されていないことが多い点です。**AWSは200以上のサービスがあり、それを運用に当てはめる際に「これはどの運用に関わるサービスなのか」という整理ができていないケースが多いのです。

#### balloon kishi left
なるほど、知識の体系化が難しいということですね。

#### balloon yamazaki right
たとえば、システムの情報がない状態で「AWSのアーキテクチャの改善ポイントを教えてください」と質問をされても、すぐに回答するのは難しいです。しかし、最低限の情報としてシステム構成図があれば、どこから着手するか（見るべきポイント）、どのような流れで改善を進めていくか等を見積もることができます。運用に関しても同じことが言えると思います。システム構成図のような「地図」「フレームワーク」があれば、どこから運用設計や改善に着手するのか、どのような流れで運用改善を進めていけばよいのか、といった方針や道筋を立てることができます。構成図というのは、次のようなものです。

~~『AWS運用入門 押さえておきたいAWSの基本と運用ノウハウ』より抜粋~~

#### balloon kishi left
システムについて体系化された知識がないと、改善の方向性が見えないわけですね。

#### balloon satake right
私もAWS運用の課題については、山﨑さんの意見に近いのですが、もう少し広い視点でお話しします。AWS以外のSE(System Engineer)やCI(Continuous Integration、継続的インテグレーション)と呼ばれる世界でも、設定の正解はドキュメントなどに記載されていることが多いです。例えば「Amazon EC2（Elastic Compute Cloud）※を建てるときはインスタンスタイプに気をつけましょう」というような設定情報は、AWSドキュメントを見れば分かります。

(※EC2：AWSクラウド上で仮想サーバーを提供するサービス)

#### balloon satake right
しかし、運用に関する資料を探そうとすると、なかなか見つけることができません。その背景として、日本のIT業界では、システムを納品した後の運用については、お客様に委ねられるケースが多く、その結果として十分な情報共有やサポートが継続しにくいという課題が生じやすい構造があるように思います。 **具体的にはシステム開発を担ったベンダーが納品を終えると、その後の運用はクライアントが主体となり、開発を手掛けたベンダー側が継続して運用に深く関与する機会が持ちにくくなる、といったケースが少なくないのです。**

#### balloon kishi left
それはたしかに問題ですね。構築と運用の断絶が起きているということでしょうか。

#### balloon satake right
その通りです。そうすると「どんな設定なのか」「どのようなシステム構成なのか」がわからなくなる。運用できない、あるいはいつの間にか運用されていない状態になることすらあります。そうした状態のまま数年後に問題が発生すると、関係者は緊急対応時に必要な情報も無いままに対応することとなり、混乱が起きることも少なくありません。アサインされた担当者も運用の正解がわからないため、何をすべきか判断できませんし、「見て見ぬふり」をされてしまうこともあり得るのです。

#### balloon kishi left
「AWSの運用とは何か」という基本的な理解がない状態の人も多いかもしれませんね。

#### balloon satake right
実は、そのような状況でAWS運用の「教科書」のようなものがあれば、担当者が問題を解決するときの大きな味方になると思ったことがこの本を執筆するきっかけでした。特にAWSはオンプレミスと違い一定の「癖」のようなものがあります。

#### balloon kishi left
まさに現場のニーズから生まれた書籍ということですね。

#### balloon satake right
運用において監視ツールの設定に関する技術書は数多く本屋に並んでいます。そしてAWSの本は試験対策や初期導入(CI)のものがほとんどを占めており、運用に関する本は皆無でした。運用監視の全体を俯瞰しつつAWSに注力した運用本がなかったため「AWSの運用に特化した本を出すことには一定の意義があるだろう」という結論に至りました。

## AWSのシステム運用「3分類」をそれぞれ理解する

#### balloon kishi left
**著書の中で、AWSのシステム運用を「業務運用」「基盤運用」「運用管理」の3つに分類されていますね。**

#### balloon yamazaki right
はい、この3つはどれか一つだけ押さえればいいというものではなく、それぞれをしっかり理解しておくことが大切です。

#### balloon kishi left
それぞれの運用は、どのように連携しているのでしょうか。

#### balloon yamazaki right
私はインフラを担当することが多いので基盤運用が中心になりますが、例えば運用管理という観点では、お客様側で決められたセキュリティポリシーに従った運用や設計が求められます。そのときに運用管理という観点や知識がなければ、セキュリティポリシーという観点が抜け落ちてしまい、お客様が求めるものとは違ったシステムになってしまう可能性があります。

#### balloon yamazaki right
しかし、運用管理という観点や知識があれば、「御社のセキュリティポリシーを教えていただけますか」と私たちからお客様に確認することができたり、幅広い提案や会話ができたりするので、お客様からの信頼にもつながります。

#### balloon kishi left
各分野の知識があることで、顧客とのコミュニケーションの質も上がるわけですね。

#### balloon yamazaki right
一人のエンジニアが3つの運用をすべて担当することはあまりないと思いますが、「自分は基盤運用の担当だから他は関係ない」という認識ではなく、**他の運用観点についても理解しようとする姿勢と最低限の知識があるだけでも、お客様との会話内容や自分の仕事に対する視点が変わってきます。**

#### balloon kishi left
システムのライフサイクルについても、重要なポイントがありそうですね。

#### balloon yamazaki right
本書では、システムのライフサイクルを「システム企画」「要件定義」「基本設計」「詳細設計」「開発」「テスト」「運用」の7つの段階で説明しています。そのうち「運用」は、サービス提供が終了するまでシステムを安定的に稼働させるフェーズです。

#### balloon yamazaki right
システムのライフサイクルにおいて、もっとも対応期間が長いのは「運用」であり、10年以上運用するシステムもあります。

#### balloon yamazaki right
設計構築は様々な技術を駆使するのでフォーカスされがちですが、**運用を怠るとビジネスに大きな影響が出ます。例えばECサイトが止まると、止まった時間だけ売上の機会損失が発生します。**

#### balloon kishi left
なるほど、運用はビジネスに直結する重要な要素なのですね。

#### balloon yamazaki right
例えば、Amazonの過去の事例では、1分間のダウンタイムで数百万ドルの損失が発生したと言われています。システム運用はビジネス上も非常に重要なのです。

#### balloon kishi left
そうなると、運用のことを設計段階から考えておく必要がありそうですね。 

#### balloon yamazaki right
その通りです。**構築が終わってから運用を考えるのではなく、要件定義や設計段階から運用のことも同時に考えておくべきです。**後から運用方法を変更しようとしても設計変更が必要になると、すでに稼働しているシステムを止める必要があり、改修のコストが大きくなります。そのため、運用を見据えた設計が重要です。

## AWS運用の基本となるサービスと選び方

#### balloon kishi left
運用において最低限押さえておくべきAWSサービスの知識を教えてください。

#### balloon ogura right
AWSの基本的なサービスである、ネットワークサービス、コンピューティングサービス、ストレージサービス、データベースサービス、負荷分散サービスなどをまず理解することが重要です。まずこれらの基本知識を理解した上で、他の機能に広げていくとよいでしょう。

#### balloon kishi left
具体的には、どのようなサービスが基本になるのでしょうか？

#### balloon ogura right
まず押さえておくべきなのはVPC（Virtual Private Cloud）※です。これはAWS上に作る仮想ネットワークで、この中に仮想サーバーなどのAWSリソースを作成します。次にEC2（Elastic Compute Cloud）という仮想サーバーを提供するサービス、そしてS3（Simple Storage Service）※というデータ保存のためのサービス、RDS（Relational Database Service）※というデータベースのサービスなどになります。

(※VPC：AWSクラウド内に論理的に分離された仮想ネットワーク環境を構築できるサービス)
(※S3：無制限のデータを保存・取得できるオブジェクトストレージサービス)
(※RDS：リレーショナルデータベースを簡単に設定、運用、スケーリングできるマネージドサービス)

#### balloon kishi left
AWSの初心者が特につまずきやすいポイントはありますか？

#### balloon ogura right
よくあるのは、IAM（Identity and Access Management）※ロールの理解です。初学者だと「EC2のOSにログインした認証情報を使って他のAWSサービスと連携する」と思ってしまう人がいるのですが、それとは別にAWSサービスを操作するためにIAMロールなどの認証情報が必要になります。この考え方の違いが理解できないとつまずくことが多いです。

(※IAM：AWSリソースへのアクセスを安全に管理するためのサービス。ユーザー、グループ、ロールなどを管理)

#### balloon kishi left
なるほど、認証の仕組みがオンプレミス※と違うから混乱するわけですね。他にも違いはありますか？

(※オンプレミス：サーバーやソフトウェアなどの情報システムを、自社が管理する施設（構内）内に設置し、運用する形態のこと)

#### balloon ogura right
RDSについては、オンプレミスでサーバーを管理していた人にとって感覚が違います。RDSを使うとAWSが大部分を管理してくれるので運用の負荷が下がります。本書では、オンプレミス、EC2、RDSの違いについても説明しています。

#### balloon ogura right
オンプレミスではすべてを自分で管理する必要がありますが、RDSではアプリケーションからの利用だけを管理すればいいので、バックアップやミドルウェアのパッチ※などはAWSが提供してくれます。

(※パッチ:ソフトウェアやプログラムのバグ修正や機能追加のために適用される、変更点のセットのこと)

#### balloon kishi left
AWSサービスの選び方についてはどうでしょうか？

#### balloon ogura right
選び方は要件ベースです。例えば「Webサーバーを継続的に稼働させたい」という要件があれば、ロードバランサー※を使って複数台で構成を組むことが考えられます。要件に合ったものを選んで組み合わせるのが基本です。

(※ロードバランサー（ELB）：複数のサーバーに負荷を分散させるサービス)

## 安全で効率的なアカウント運用のベストプラクティスは？

#### balloon kishi left
アカウント運用について、権限付与のパターンを教えてください。一つのアカウントに権限を付与して複数人で利用するのか、個人のアカウントを作成してそれぞれに権限を付与するのか、どちらが良いのでしょうか？

#### balloon mine right
基本的には、アカウントを共有して使うよりは、個々人のアカウントを用意することが多く、そちらが推奨されます。1つのユーザーを共有すると、誰がいつアクセスしたのかの管理や監視が難しくなります。また、権限の面でも、担当者ごとに必要な権限だけを付与するのが難しくなり、広い権限を設定せざるを得なくなります。
個人のアカウントを用意しておけば、その人に必要な権限だけを与えられるというメリットがあります。

#### balloon kishi left
なるほど、セキュリティ面からも個別アカウントが望ましいわけですね。逆に、一つのユーザーアカウントを共有したほうがいいケースはありますか？

#### balloon yamazaki right
共有利用しないのがベストです。監査準備のためのCloudTrail※というサービスがあり、AWS上の操作のログを取ることができるのですが、アカウント、AWSだとIAMユーザーを共有使用すると操作者の特定ができなくなります。例えば、トラブル発生時に「誰がこの設定を変更したのか」を追跡できず、責任の所在が不明確になります。

(※CloudTrail：AWSアカウントの操作履歴を記録・監視するサービス)

#### balloon kishi left
アカウント運用のベストプラクティスとして本書ではどのようなことを推奨していますか？

#### balloon mine right
本書では、IAMユーザーの作成から始まり、適切な権限管理、パスワードポリシーの設定など、セキュリティを確保しながら効率的に運用するための方法を解説しています。特に重要なのは「最小権限の原則」で、必要最低限の操作権限のみを付与することを推奨しています。

#### balloon mine right
ルートユーザーは全ての操作権限を持つため、通常の作業では使わず、必要最低限の操作権限に限定したIAMユーザーを作成して利用することが重要です。

#### balloon kishi left
最近のトレンドとしては、マルチアカウント運用もあるそうですね。

#### balloon yamazaki right
はい。最近のお客様は一つのAWSアカウントではなく、複数のAWSアカウントを運用しています。10個、20個、多い企業では100個以上のアカウントを運用していることもあります。

#### balloon kishi left
100個もあると管理が大変そうですね。

#### balloon yamazaki right
各アカウントにIAMユーザーを作ると、100個のIAMユーザーが必要になるので非常に面倒です。そこで、AWSアカウントに専用の「踏み台アカウント」を一つ作り、そこでIAMユーザーを一元管理します。

#### balloon yamazaki right
その踏み台アカウントから権限に応じて、各アカウントにアクセスする権限を管理すれば、アカウントごとにIAMユーザーを作る必要がなくなります。

#### balloon kishi left
「踏み台アカウント」という考え方は非常に参考になりますね。最近はさらに進化しているのでしょうか？

#### balloon yamazaki right
AWS IAM Identity Center と呼ばれるシングルサインオン※を提供する仕組みもあり、一つの場所でユーザーを作成すれば、あとはそのユーザーにどのアカウントへのアクセスを許可するかという権限管理だけで済むようになっています。

(※シングルサインオン：一度の認証で複数のサービスにアクセスできる仕組み)

#### balloon yamazaki right
また、AWS Organizations※というサービスを使うと、複数のAWSアカウントを一元管理できます。特にサービスコントロールポリシー（SCP）という機能を使うと、組織単位でアカウント内の操作を制限できるので、より効率的な管理が可能になります。

(※AWS Organizations：複数のAWSアカウントを一元管理するサービス)

## AWSのコストを最適化するポイントは?

#### balloon kishi left
最近は円安の影響でAWSの料金が上昇していると聞きます。どのような対策が効果的でしょうか。

#### balloon satake right
為替変動でコストが上昇すると「何とかしなければ」という話になりますが、コスト管理はAWS運用の一環として常時行うべきものです。

#### balloon satake right
AWSは、コスト削減のためのサービスをいろいろと提供しています。古くはReserved Instances※という予約して一括で払うことで割引を受ける機能や、その進化版であるSavings Plans※、コストを最適化するための AWS Compute Optimizer ※などがあります。最近ではCost Optimization Hub※というAWS Organizations環境下で有効活用できるサービスも登場しています。

(※Reserved Instances (RI)：AWSリソースを1年または3年の期間で予約することで割引を受けられる購入オプション)
(※Savings Plans (SP)：コミットメントベースの割引料金モデル。RIと同等の割引を受けられるがより柔軟なモデル)
(※ AWS Compute Optimizer ：コスト最適化のための推奨事項を提供するサービス)
(※ Cost Optimization Hub：AWSアカウントとリージョン全体でコスト最適化の推奨事項を統合管理するサービス)

#### balloon kishi left
コスト最適化を進める上で特に注意すべき点はありますか？

#### balloon satake right
AWSアカウントが、不要なリソースが整理されないまま放置され、簡単に「ゴミ箱」のような状態になり得ることには注意が必要です。「誰が作ったか不明で、削除するのが怖い」といった判断が積み重なることが原因です。これを防ぐためには、各AWSリソースの作成者、用途、責任者を明確に記録し、追跡可能な状態にしておくことが重要です。また、コスト最適化のためには「現場の協力と理解」が必要となるのですが、現場は現場で本来の業務もあるため、コストに関する作業の割り込みに対して、なかなか動いてくれないこともあるというのが実情です。

#### balloon kishi left
それはたしかにありそうですね。どのように対処すればよいのでしょうか？

#### balloon satake right
近年提唱されているのが「Cloud Center of Excellence（CCoE）」※という概念です。経理部門、情シス部門、アプリ部門等が一丸となってコスト管理に取り組む組織的アプローチです。トップダウンでコスト管理の重要性を示すことが効果的です。

(※Cloud Center of Excellence（CCoE）：クラウド活用を推進するために必要な人材を集約した全社横断型の組織)

#### balloon satake right
進め方としては、AWSリソースを棚卸して未使用なもの、不要なものを見つけて削除することから開始するのが良いでしょう。不要なリソースの削除はセキュリティリスクを低減させる事にも役立ちます。そして、残ったものはスペックを適正化し、常時起動が必要かどうかを判断します。さらに、常時起動が必要なものだけReserved InstancesやSavings Plansを購入して割引料金で使うという手順を紹介しています。

#### balloon kishi left
具体的な手順が示されているのは、非常に参考になりますね。実際にどれくらいのコスト削減効果が見込めますか？

#### balloon yamazaki right
私が担当しているお客様では、不要なバックアップをまとめて削除しただけで年間1,500万円のコスト削減になったケースがあります。

#### balloon kishi left
それはすごい効果ですね。削減額に驚きました。

#### balloon yamazaki right
また、リソースを削減すると管理コストも減ります。例えばIAMユーザーが100個あっても実際に使われているのが10個だけなら、不要なものを削除することで管理対象が減り、管理する側の時間的コストや運用コストも削減できます。金銭的コストだけでなく、運用負荷の軽減にもつながるのです。

多くの企業がAWS(Amazon Web Services)を利用したシステム構築を進めていますが、システム構築後の「運用」においては体系的な知識を身に着ける方法についてあまり周知されておらず、多くのエンジニアが手探りの状態で業務に取り組んでいるのが現状です。本記事では、4名のAWSスペシャリストへのインタビューを通して、効率的にAWSを運用するための知識とノウハウをお届けします。

2017年4月より株式会社サーバーワークスにてお客様のAWS環境の設計構築に従事。サーバーレスアーキテクチャや機械学習サービスなど幅広いAWS導入プロジェクト・PoCプロジェクトを経験。そのほかプリセールスやカスタマーサクセスなども担当。2022年4月より現職。カスタマーリライアビリティエンジニアとしてテクニカルサポートやドキュメントのメンテナンス、社内ツールの開発などに従事。

峯さん

データセンターネットワークの構築・運用を10年、AWS環境の運用監視に2年半従事。2018年、サーバーワークスに入社後、お客様のAWS上にシステムの構築、構築したシステムの運用、お客様からのAWSに関する質問に回答するサポート業務など幅広い業務を担当。現在は社内外の技術トレーニング講師を担当。

小倉さん

人材ベンチャー企業のエージェント事業部にて営業・キャリアアドバイザーとして従事。2019年12月より現職。50以上のAWS導入プロジェクトに参画。IT業界経験3年未満の若手エンジニアを対象にAWSが主催する「ANGEL Dojo」にてベストアーキテクチャ賞、ANGEL賞の2冠を受賞。AWSクラウドへの大規模移行プロジェクトのPMを経験。現在は中途採用および中途入社メンバー向けのトレーニング等に従事。

山﨑さん

2010年1月よりAWSを実務で利用開始。AWSを活用した社内ベンチャーの立ち上げに参画し、2012年にAWSパートナーアワードを受賞。2014年7月より現職。エンタープライズ企業のカスタマーサクセスとして長期の関係性を構築する中で、コスト最適化やマルチアカウント統制を中心に、設計から運用まで幅広く担当。

佐竹さん

AWSシステム運用における現場の課題と体系的知識の重要性

運用管理の3分類と効率的なアプローチの実践方法

コスト最適化戦略と具体的な削減手法

AWS運用の基本とノウハウ。トップエンジニアが語る現場の知恵と実践的アプローチ

プログラミングというと「コードを書く」イメージが強いですが、実務では既存コードの修正や理解に多くの時間が費やされていることをご存知でしょうか。実は、エンジニアの日常において、プログラムを「書く」ことよりも「読む」時間の方が圧倒的に長いのです。

そこで今回は、『[書くスキルも設計スキルも飛躍的に上がる！プログラムを読む技術](https://www.amazon.co.jp/%E6%9B%B8%E3%81%8F%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%82%E8%A8%AD%E8%A8%88%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%82%E9%A3%9B%E8%BA%8D%E7%9A%84%E3%81%AB%E4%B8%8A%E3%81%8C%E3%82%8B%EF%BC%81-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%82%92%E8%AA%AD%E3%82%80%E6%8A%80%E8%A1%93-%E5%B2%A9%E6%9D%BE-%E6%B4%8B/dp/4296071025)』の著者でIT企業でのエンジニア経験と自身が運営するプログラミング教室での指導を通じて「読む技術」の重要性に気づいたという岩松洋氏にインタビュー。「読めるようになれば書く力も自然と向上する」と話す岩松氏に、効率的なプログラムの読み方と、その先にある技術向上のヒントを伺いました。

*■『書くスキルも設計スキルも飛躍的に上がる！プログラムを読む技術』 *

出版社：日経BP、著者：岩松洋

*■岩松 洋 *
岡山大学工学部修士課程情報工学専攻卒。大手IT企業にてプログラマー、システムエンジニアとして経験を積み、情報処理技術者プロジェクトマネージャー資格を取得。開発チームのプロジェクトマネージャーとして官公庁のセキュリティシステム開発を担当後、起業。豊富な開発経験と要件定義のスキルを活かし、中小企業の生産性向上や業務効率改善を支援する専門コンサルタントとして活動。また、人材育成にも力を入れ、「考える社員」を育てることを目的とした企業向けの研修プログラムを提供し、講師も務める。

## エンジニアが見落としがちなコードを「読む技術」の重要性

#### balloon kishi left
まず、プログラマーにとってなぜプログラムを読む技術が必要なのかお聞かせいただけますか？

#### balloon iwamatsu right
**プログラムを書くときもシステム開発をするときも、プログラムを読む機会が本当に多い**からです。書いたプログラムのデバッグやテストは必ずありますし、他人の書いたプログラムを引き継ぐこともあります。現在はAIが書いたプログラムをもとに変更することもあるでしょう。

#### balloon iwamatsu right
私の経験でも、**プログラムを「書く」よりも「読む・修正する」時間の方が長かった**ように思います。プログラミングを仕事にする方にとっても、学ぶ方にとっても、プログラムを読む技術は本当に重要です。

#### balloon kishi left
たしかに実務では自分で一から書くよりも、既存コードを修正する機会の方が多いかもしれませんね。読む技術が高まると、書く技術も高まるとのことですが、その理由を詳しく教えていただけますか？

#### balloon iwamatsu right
**プログラムを読む際には、プログラムの設計の全体像を理解することが必要です。**一行ずつ文法的に読み取ることと、プログラム全体を設計的に読み取ることの両方が必要になります。

*【プログラムを読む手順】*
1 . プログラムの全体（設計）を読み取る
2 . プログラムを分解して各部分を読み取る
3 . プログラムの分解を続けながら、一行ずつ読み取る

*【プログラムを書く手順】*
1 . プログラムの全体を設計する
2 . 全体を分解して、各部分を設計する
3 . プログラムを一行ずつ書く

#### balloon kishi left
双方に「設計」という共通点があるのですね。

#### balloon iwamatsu right
そうなのです。両者にはまず**「設計」という点が共通**しています。プログラム全体(設計)を読めるようになると、プログラムを書くときの設計技術が上達するのです。

#### balloon iwamatsu right
バグ修正・デバック、機能追加・仕様変更、コードリファクタリング、他人のコードの引き継ぎといった場面では、**プログラム全体の流れと設計を読むことが重要**です。プログラムを修正する際に、設計をきちんと読み取らないと、思わぬバグを作り出してしまうこともあります。

#### balloon kishi left
プログラミング教室を運営されている立場から、学習者がつまづきやすいポイントはどこか教えていただけますか？

#### balloon iwamatsu right
教室で見ていると、**文法は理解しているのにまとまったプログラムになると読めない**という生徒さんが多いです。特にfor文（※特定の処理を決まった回数繰り返す命令文）やwhile文（※条件が満たされる間、処理を繰り返す命令文）といった繰り返し文や、関数に関する質問が多いです。

新しい記事