初めに

こんにちは、私は IT 基盤部所属の井上と申します。IT 基盤部は、mobage をはじめとする DeNA のさまざまなサービスのインフラを横断的に担当している部署です。

私は文系・新卒・インフラ未経験で入社しました。 この記事では、入社後の約１年間で私がインフラエンジニアとしてどのように成長できたか、を振り返ってみます。 それにより、DeNA のインフラエンジニアになると、「仕事をする上で、何事に対しても丁寧に考える力が身に付く」ことをお伝えできればと思います。 また、インフラエンジニアという職種はハードルが高いと思う方もいるかもしれませんが、大切なのは、技術的な知識や経験などよりも、この「丁寧に考える力」 なので、インフラ経験の有無は心配する必要がない、ということもお伝えできればと思います。

この記事の話の流れ

成長できた点はいくつかあると思っていますが、今回はそのなかでも特に DeNA のインフラエンジニアが徹底している考え方という観点にフォーカスします。

本題に入る前にまず、IT 基盤の行動原理である「動き続けるものを作る」について簡単に触れます。

次に、私が特に成長できたと感じている具体的な 3 つの点を、実体験を交えて紹介します。

1. タスクについて考え抜く
2. ミスときちんと向き合う
3. 一度自分がやったことを、いつでも・誰でもできるようにする

最後に、IT 基盤部のカルチャーについて紹介します。それが、私が成長できた大きな理由の一つだからです。

動き続けるものを作る

IT 基盤部では、行動原理として 「動き続けるものを作る」 ことが求められます。「動き続ける」とは、「ただ動けばよい」のではなく、下記の観点を重要視するということです。

• 24 時間 365 日、安定して動き続ける
• 長期間にわたって運用し続けられる

DeNA の提供するサービスは、たくさんのお客様が、時間帯を問わず利用してくださっています。インフラの都合やミスでサービスが停止することは、あってはいけません。

また、DeNA のサービスには、10 年以上にわたって継続しているものもあります。インフラの構成や運用を考える際は、そのような長期間の運用も視野に入れておく必要があります。お客様にとってどんなに良いサービスであっても、会社にとって金銭面や運用面のコストが大きいと、長期間の継続は困難だからです。

IT 基盤部の仕事では、これらの観点が常に求められます。それが、「動き続けるものを作る」という行動原理の意味です。

自分が特に成長できた 3 つの点

私は配属後、「動き続けるものを作る」ための考え方をたくさん学んできました。なかでも自分が特に成長できたと感じているのが、下記の 3 点です。

1. タスクについて考え抜く
2. ミスときちんと向き合う
3. 一度自分がやったことを、いつでも・誰でもできるようにする

これから詳しく説明していきます。

成長できた点 1: タスクについて考え抜く

成長できた点の 1 つ目は、タスクについて考え抜く姿勢と能力です。ここでいう「考え抜く」とは、下記を実現することです。

1. 論理的に筋道が通っていること
2. QCD が最適なバランスであること

1.1 論理的に筋道が通っている

「論理的に筋道が通っている」とは、さらに分解すると、下記が満たされていることだと言えます。

• ゴールまでの見通しが立っていること
• そのゴールが適切であること

1.1.1 ゴールまでの見通しが立っている

「論理的に筋道が通っている」ためには、ゴールまでの見通しを立てることが必要です。つまり、現在地からゴールへの具体的な経路を想像できている必要があります。

ゴールまでの見通しがないと、何をすればよいかわからないため、動くことができず途方に暮れたり、あるいは行き当たりばったりの行動で時間を無駄にしたりすることになります。

私が実際に経験した例で説明しましょう。ある日、「ウェブサーバの CPU 使用率が高い」というアラートが来たので、原因の調査に取り掛かりました。

ゴールまでの見通しが立っていないと、何から調べればよいかもわからず、最初の一歩を踏み出すことさえできません。あるいは、なんとなく「アクセスログを眺めてみよう」と思いついたとしても、本当にただ眺めるだけで終わってしまい、また次に何をすればよいか途方に暮れるかもしれません。

私の例では、アクセスログを調べてみたところ、特に何もわからなかったため、苦しまぎれに、status code ごとの合計数を集計してみました。当然ながら、集計結果からも何もわかりませんでした。その後、「何のためにその調査に時間を使ったの？」と質問されて、「なんとなく」としか答えられませんでした。

今の自分だったら、下記のように行動します。

なんとなくで動き出すのではなく、まずはありそうな原因の候補をいくつか考えます。それから、候補の一つずつに対して、実際にそれが原因なのかを確かめます。例えば候補の一つとして「アクセス数の急増」を挙げたなら、「急増があったかどうかを確認する」という明確な目的を持ってアクセスログを見ます。

もしそのような急増がなかった場合でも、原因の候補が１個消えて絞られたのだから、ゴールに着実に近づいています。もしすべての候補がハズレでも、それが見通しに基づいて得られた結果なら、情報として整理されているので、新たな見通しを立て直すための材料として役に立ちます。

1.1.2 ゴールが適切である

ゴールまでの見通しが立っていても、そのゴールが不適切だと、元も子もありません。不適切とは、問題の解決策が対症療法でしかなかったり、そもそも的外れだったり、などです。

先ほどのアラート対応の例で言うと、対症療法でしかないパターンとしてよくあるのは、「目の前のアラートをとにかく止める」がゴールだと思ってしまうことです。実際は、適切なゴールは「アラートの根本原因を突き止め、解消する」のはずです。

ここでの基準は、「動き続けるものを作る」という行動原理を十分に満たせているかどうかです。根本原因を解消しないと、同じ問題が再発するかもしれません。今を凌ぐだけでは不十分なのです。

私は、「動き続けるものを作る」が身に付くまでは、任されたタスクのゴールをどこに設定すればいいのかで、いつも悩んでいました。タスクが異なればゴールも異なるので、初めて取り組むタスクのたびに、何をどうすればよいかわからなくなっていました。また、わからなくて先輩に相談するときにも、ゴールそのものを聞こうとしていたので、一向に自分で考えられるようになりませんでした。

しかし、答えを直接聞くことをやめて、「動き続けるものを作る」という原理から自分で考えるようにしてからは、適切なゴールを自分で設定できるようになってきました。

こまめに現在地を確認する

ゴールまでの見通しを立てることと、適切なゴールを設定することは、タスクの最初に１回実行して終わりではありません。タスクを進めるなかで、こまめに現在地を確認しながら、繰り返し実行する必要があります。なぜなら、見通しやゴールは、新しい情報や状況変化に応じて更新するべきだからです。また、そうでなくても、タスクを没頭して進めていると、いつの間にか当初の筋道から逸れてしまうことがよくあるからです。

ここでも、CPU アラートの例で説明します。私は下記のように進めました。

1. 原因の候補として「アクセス急増」という仮説を立てた
2. アクセス数の推移を調べた結果、たしかに急増していた
3. すでに原因は判明したのに、特に目的もなく、アクセスに占めるエラー数の推移を見た

この進め方は「こまめに現在地を確認」ができていない実例です。具体的には、2 ですでに原因を特定できたにもかかわらず、惰性で調査を続けてしまいました（さっさと対策の検討に移るべきでした）。しかも、3 の調査は、見通しに基づかない思いつきの行動でした。

厄介なのは、このような進め方でもやっている間は進んでいる気分になってしまうことです。しばらくして我に返ったときに、実際には何も進んでいなかったことに気が付くのです。

このような無駄を防ぐには、現在地がゴールへの道から外れていないかをこまめに確認する以外にありません。私は TO DO（タスクをより細かく分解した単位）を 1 個行うたびに毎回、タスク全体の筋道を見直しています。

1.2 QCD のバランスが最適であること

ここまでは、「タスクについて考え抜く」際に大事な 2 つの観点のうち、まず一つ目の「論理的に筋道が通っていること」について説明しました。ここでは、もう一つの「QCD のバランスが最適であること」について説明します。

QCD とは、Quality (品質の高さ)、Cost (費用の安さ)、Delivery (デリバリの速さ) の略です。理想的にはどの項目も高ければ高いほど良いのですが、現実的には互いにトレードオフの関係にあるため、総合的に最適なバランスを見極めることが必要です。

例えば、下記のような 2 つのシステムがあるとしましょう。

• 毎年 100 億円のコストがかかるが、何が起きても絶対に止まらないシステム
• 毎年 1 億円のコストで済むが、メンテナンスのために 1 日は止めなければならないシステム

どちらの方がバランスが良いでしょうか。それは判断基準によって変わります。さまざまなステークホルダーと話し合って、総合的に決めるべきことです。もし人命に関わるようなシステムなら、1 日も止まらないことは必須条件かもしれません。それほどクリティカルでないシステムなら、コストの節約を優先する場合もあるかもしれません。

成長できた点 1 「タスクについて考え抜く」のまとめ

以上で、「タスクについて考え抜く」際に大事な 2 つの観点を説明しました。すなわち、「論理的に筋道が通っていること」と「QCD が最適なバランスであること」です。

私は、配属当初はこれらを意識すらできていませんでしたが、現在は、粒度がさほど大きくないタスクであれば、自力で実践できるようになってきました。今後は、粒度の大きなタスクでもしっかりと実践できるようになりたいと思っています。

成長できた点 2: ミスときちんと向き合う

成長できた点の 2 つ目は、ミスにきちんと向き合うという姿勢です。ここでいう「きちんと向き合う」とは、下記を実行することです。

• 2.1 ミスをスルーしない
• 2.2 ミスを減らすために工夫をする
• 2.3 ミスによる影響を抑えるために工夫をする

インフラの仕事には、ミスをしてしまった際の影響がとても大きいという特性があります。システムの根底部分を担う仕事なので、たったひとつのミスでも、サービスが止まってしまったり、最悪、事業が継続不可能になることさえありえます。

しかし、ミスが怖いからといって、仕事をしないわけにはいきません。自動化・コスト削減など QCD の改善を進めたり、突発的なシステム障害に対して復旧・再発防止の作業をしたり、やるべきことはたくさんあります。ミスから逃げるのではなく、ミスに「きちんと向き合う」 必要があるのです。

ここから、「ミスにきちんと向き合う」について、より詳しく述べていきます。

2.1 ミスをスルーしない

配属当初、私は「自分もたまにはミスをするけど、大事なところではミスしないだろう」と思っていました。みなさんの多くも、きっと「大事なところで気をつけていれば、重大なミスはしない」と思っているのではないでしょうか。

しかし、配属後にその過信は吹き飛びました。

IT 基盤部では配属当初から、自分で考えてアウトプットする機会が多いため、ミスをしうる機会も自然と多くなります。気をつけるべき「大事なところ」が多すぎて、根性論ではどうにもならないのです。また、ミスをしても自分では「今回はたまたまだ、次は大丈夫だ」と流してしまいがちで、結果として、同じミスを何回も繰り返していました。

この繰り返しから抜け出すことができたのは、まず、ミスに対する意識が変わったからです。配属後しばらくは、先輩がハンズオンで作業に付き添ってくれるのですが、自分一人では流してしまっていたミスも、先輩は都度「危険なミスだ」と指摘してくれます。そして、「そのミスがなぜ危険なのか」を理解できるまで説明してくれます。そのため、「たいしたことではない」と思っていたミスに対しても、「同じミスは絶対に繰り返してはいけない」という認識を持てるようになりました。

2.2 ミスを減らすために工夫をする

ミスをスルーしない姿勢が身につくと、次は「ミスをどうやって減らすか」を考えるようになります。

実は、配属直後から「ミスをしやすい場面」「ミスを避けるための具体的な方法」を教わってはいたのですが、当時は「つまらないノウハウの寄せ集め」に見えていました。例えば:

• 作業時は手順書を作れ。アドリブでやるな
• コマンドは手順書からコピペしろ。ターミナル上でコマンドを直接編集するな
• コマンドを実行する前に、自分がどのサーバにいるか、こまめに確認しろ
• etc.

当時、これらのノウハウの重要性は私にとっては疑問だったため、私は自己流にこだわっていました。結果として、ミスはほとんど減りませんでした。

自己流ではミスが減らなかった原因は、「知識不足」と「根性論に頼りがちだった」ことです。つまり、作業をするときに「一見すると問題なさそうだが、経験者が見れば危ないとわかる方法」をとってしまったり、ミスの再発防止策を考えても具体性がなかったりしたからです。

そのことに気づいてから、あらためて、教えられたノウハウを徹底的に実践してみました。「徹底的に」と言っているのは、これらのノウハウは「思い出したときにやればよい」「〜回やれば効果が出る」というものではなく、常に実践し続けられていて初めて効果があるものだからです。そうして続けているうちに、気がつくと今では、ミスを指摘されることが珍しいと感じるくらい、ミスが減りました。やっぱりノウハウは偉大でした。

2.3 ミスによる影響を抑えるために工夫をする

こうして、ミスを減らすノウハウを身につけても、残念ながら、ミスを完全に避けることはできません。イレギュラーや疲労など、いろいろな要因でどうしてもミスは起こります。ミスをまったくしないのは、人間には不可能です。

そこで大切になるのが、ミスの影響を抑えるために、事前に工夫をすることです。

例えば、100 台のウェブサーバ上の設定ファイルに変更を加えたいとします。すべてのサーバに対して一気に作業をすると、もし変更内容にミスがあった場合、すべてのサーバが影響を受け、サービスが止まってしまうかもしれません。一方、まずは 1 台だけに変更を加えて、しばらく様子を見るようにすれば、もし変更内容にミスがあっても、影響は 1 台で済みます。このように、あえて一手間かけることで、ミスによる影響を格段に小さくできます。

ちなみにこの例は、先述の QCD のバランスの例にもなっています。ここでは、Delivery（作業の速さ）をすこし犠牲にして、Quality（安定性）を大きく高めている、ということです。

IT 基盤部では、このようなノウハウもまとめられています。配属当初の私にとっては、それらもやはり「つまらないもの」に見えていたのですが、先輩方から指摘を受けたり、先輩の作業の様子を見て解説を聞いたりするうちに、大切さがわかってきました。

成長できた点 3: 一度自分がやったことを、いつでも・誰でもできるようにする

成長できた点の 3 つ目（最後）は、「一度自分がやったことを、いつでも・誰でもできるようにする」という考え方です。これは、オペレーションの品質を組織として維持・担保するために必要なことです。

システムは 24 時間 365 日、かつ長期間にわたって運用されるので、一度実施した作業を、将来、再度実施する必要が出てくるかもしれません。実施するのが自分であっても他の人であっても、同じように高い品質を実現できなければいけません。

そのための手段のうち、特に自分が身についたと感じるのは、手順書の作り方です。以下に、悪い手順書と良い手順書の例を出してみます。

A (悪い手順書)

B (良い手順書)

B の方が良い理由は、下記のような観点を押さえているからです。ただ「手順書を作る」といっても、品質を担保するためには、このようないろいろな工夫が求められるのです。

• 具体的。誰が実行しても、同じ結果が得られる。判断に迷わない
• 安全性への配慮。事前・事後の確認が手順に含まれている。切り戻しの方法が明記されている
• 読みやすさ。読者がミスをしにくいよう、外観やレイアウトが工夫されている

手順書を書いた際は、先輩にレビューしてもらうことができます。改善するべき点があれば、その理由も含めて、丁寧なフィードバックをもらえます。このように「書いて・直して」を繰り返したおかげで、良い手順書の書き方が身についてきました。

基盤部のカルチャーについて

以上、自分が特に成長できたと感じている 3 点について説明してきました。このように私が成長できたのは、IT 基盤部のカルチャーのおかげが大きいと考えています。そこで最後に、そのカルチャーについて紹介します。

• アウトプットとフィードバックの機会が多い
• そのフィードバックの品質が高い
• 改善を周囲がサポートしてくれる

IT 基盤部では、配属直後から、ある程度の裁量を持てるタスクを任されます。そのため、自分でたくさん考えて、たくさんアウトプットすることになります。そのアウトプットに対して、周囲からたくさんのフィードバックがもらえます。

また、そのフィードバックはとても丁寧です。一見たいしたことのないように見えるミスでも、都度きちんと指摘し、なぜ・どのように改善するべきか理解できるよう、しっかり説明してくれます。

IT 基盤部のメンバーがこのように厳しい目を持っているのは、先述のとおり、インフラの仕事では小さなミスも大事故に繋がりかねないため、自他に求める基準が高いからです。基準に達していない振る舞いを見逃さないのです。

そして、IT 基盤部のメンバーは、ただ厳しいだけでなく、改善できるまで徹底的につきあってくれます。これは、何にでも「自分ごと」として取り組む、すなわち、誰かの課題はチームの課題、チームの課題は自分の課題でもあると考える、そのような人ばかりだからです。

僕は未経験かつ飲み込みが悪いため、何度も同じ指摘を受けてしまったり、指摘を正確に理解するために時間がかかったりしていました。そのくせ私は、当初、自分のやり方にこだわっていたため、成長があまりできない時期が続きました。しかし、周囲の方は高い熱量でずっと付き合ってくれました。相談や指導に数時間以上かけてもらったことも、何回もありました。そのおかげで、自分でも想像できなかったくらい成長できたのだと思います。

全体のまとめ

基盤部に配属されたことで、文系・未経験でも、インフラエンジニアとして成長できています。

成長しやすい環境があり、実際に自分も成長できそう！と思ってもらえたら嬉しいです。

お読みいただき、ありがとうございました。