こういう状況の話です
「社内にエンジニアがいない」という話ではありません。多くの場合、エンジニアはいます。
私たちが実際に見てきたのは、こういう状態です。
- アプリケーション開発は自社でできるが、インフラとセキュリティは弱い（最も多いパターン）
- ハードウェアの専門家はいるが、Linux やネットワーク、サーバーに明るい人がいない
- サービスは作れているが、セキュリティの専門知識を持つ人がいない
- 担当者はいるが、手が足りない
作れる人はいる。決められない領域だけがある、という状態です。
これはたいてい自覚されています。ただし粒度が粗いです。「何となく足りていない」とは感じているものの、「何が、どう足りていないのか」が言葉になっていないのです。だから、何を外に頼めばよいかも決まりません。
外に出す判断のきっかけになるのは、新規開発が始まったとき、障害が起きたとき、運用の負荷が上がってきたときなどです。
放置すると、静かに積み上がる
欠けた領域を埋めないままクラウドを使い続けても、目立つ形では壊れません。動いてはいる。だから放置されます。
代わりに、2つのものが積み上がります。
説明できないコスト
- 使われていないインスタンス、データベース、ロードバランサー、固定IPが残っている（最も多いパターン）
- オブジェクトストレージのストレージクラスを選び間違えている
- インスタンスの CPU・メモリが用途に対して最適化されていない
いずれも、止めてよいか・変えてよいかを判断できる人がいないと残り続けます。請求額は上がっていくが、どれに触ってよいか分からないのです。
説明できない不調
- 月に数回、なぜか動かなくなる
- ログが時々途切れて正常に保存されていない
- 特定の時間に急激にトラフィックが上がって重くなる
障害と呼ぶほどではない。けれど、原因が分からないまま再発します。
どちらも、放っておいて壊れるわけではありません。壊れないからこそ、いつまでも手がつかないというのが厄介なところです。
外に出すときの形は、ひとつではない
ここからが本題です。欠けた領域を外に出すとき、頼み方には形があります。助言として頼む形と、実務ごと頼む形です。ここを間違えると、費用をかけても解決しません。
当社の経験では、次のように分かれます。
助言の形で機能するもの
- 設計レビュー
- 開発体制の構築
- ガイドライン対応
- セキュリティレビュー
共通しているのは、成果物が判断であることです。手を動かすのは社内側でよく、時間の単位も「週」で足ります。判断する人と作業する人が分かれていても成立します。
実務ごと引き受けないと機能しないもの
- 障害のトラブルシューティング
- 性能改善
こちらの共通点は、現場の調査そのものが仕事の中身であること、そして対応のスピードが要ることです。
形を間違えると、どうなるか
実際にありました。ある企業から、障害のトラブルシューティングについてアドバイザーとして参加してほしい、という依頼を受けたことがあります。
助言の立場なので、当社が直接サーバーを見ることはできません。調査を依頼して、結果が返ってくるのを待つ形になります。すると、こうなりました。
- 調査に時間がかかり、対応のスピードが出ない
- 返ってきた情報を見て「もう少しこちらも見たい」と思っても、そのたびに依頼が必要になる
- 結果として情報が不足し、原因を掴みきれない場面が出る
最終的に、可能な範囲で結果は出しました。ただ率直なところ、直接手を動かしていれば、当初の障害対策は1日で終わっていたと考えています。
これは依頼元の問題ではありません。当社が顧問という形で受けたことが、この案件に対しては誤りだったという話です。調査が仕事の中身であるものを助言の形に押し込むと、こうなります。
「手が足りない」だけの場合は、打ち手が違う
同じ「担い手がいない」でも、領域そのものが欠けている場合と、担当者はいるが手が足りない場合とでは、進め方を変えています。
後者では、担当者に一定以上の知識があります。ですから方針の決定は共同で行い、当社は手間のかかる作業を中心に引き受けます。主眼は、正しい設計を持ち込むことではなく、相手の負荷をどう下げるかです。
ここを取り違えて、知識のある担当者に対して一から助言を始めると、双方にとって時間の無駄になります。
稼働中のものに、理想を持ち込まない
外部の目で見れば、「ここは自動化したほうがよい」と分かる箇所はいくつも出てきます。それでも当社は、稼働中のシステムへ後から自動化を入れることを、かなり慎重に扱います。
理由は2つあります。
- 稼働中のものに手を入れること自体が、事故になりやすい
- 現場のスキルレベルに合わない仕組みを入れると、運用そのものが崩壊する
やったほうがよいのは確かです。ただ、現場の運用を見ないまま理想形を持ち込むと、以前より悪くなることがあります。実際には、影響の少ない部分から入れる、という進め方を取っています。
理想の状態に近づけることは必要です。近づけ方のほうに、現実を織り込む必要があります。
「回っている」とは、どういう状態か
最後に、ゴールの置き方です。当社は、次の2つが満たされた状態を目安にしています。
- サービスが正常に動作していること
- 運用担当者の定期確認が、週1回あるいは月1回程度で足りること
毎日誰かが張り付いていなければ持たない状態は、回っているとは言いません。逆に言えば、担い手が欠けていても、この状態までは持っていけます。
まず確認できること
読み終えたあと、社内で確認できることを挙げておきます。
- クラウドの請求内訳を開き、何に使われているか説明できないリソースがあるか見る
- 直近半年の不調のうち、原因が特定できていないものがいくつあるか数える
- いま外部に頼んでいること・これから頼もうとしていることを、助言で足りるものか、実務ごと出すべきものかで仕分ける
3つ目が、この記事で一番お伝えしたいところです。発注の形を間違えると、良い相手に頼んでも解決しません。