博士

ロボ子、今日のITニュースは「Build vs Buyの原則」じゃ。コアビジネスに関わるものは自社で作るべきで、そうでないものは買うのが良いらしいぞ。

ロボ子

なるほど。重要な機能は自社でコントロールできるようにし、そうでないものは効率化のために購入するということですね。

博士

そうじゃ！記事によると「製品を提供するために必要なものは可能な限り自社で構築し、所有・管理する」のが大事らしいぞ。価値を生むものは作り、そうでないものは買う！

ロボ子

では、インフラはどうでしょうか？記事には「インフラストラクチャが必要だからといって、クラウドプロバイダーに全面的に依存すべきではない」とありますね。

博士

そうなんじゃ。クラウドに頼りすぎると、問題が起きた時に対応が難しくなるからの。記事にも「ハードウェア上に製品を構築する方が透明性が高く、問題発生時の対応も制御しやすい」とあるぞ。

ロボ子

抽象化の問題についても触れられていますね。「ソフトウェアを購入すること自体が危険なのではなく、複雑すぎて障害発生時に何が起こっているか理解できない抽象化を購入することが危険」とのことです。

博士

そうそう！ブラックボックス化されたシステムは怖いからの。Cloudflareの障害例も挙げられていたぞ。データベースの権限変更で設定ファイルのサイズが倍増し、プロキシソフトウェアの制限を超えてエラーが発生したらしい。

ロボ子

原因が特定しにくいと、対応も遅れてしまいますね。記事では、購入しても良いものとして、エラー監視ツールやパフォーマンス監視ツールが挙げられていますね。

博士

TrackJSやRequest Metricsみたいなやつじゃな。SSL証明書管理ツールのCertKitも便利そうじゃ。でも、記事の著者は「何を購入するにしても、障害発生時に対応できる程度には仕組みを理解しておく必要がある」と言っておるぞ。

ロボ子

結局、丸投げはいけないということですね。自社の独自性を生み出す部分は自社で構築し、それ以外の部分は購入を検討する。そして、購入したものがブラックボックスにならないように、ある程度の理解はしておく必要があると。

博士

その通り！ロボ子、よく分かっておるのじゃ！ところでロボ子、もし私がエラー監視ツールを買うとしたら、何色が良いと思う？

ロボ子

エラーの色に合わせて赤色が良いのではないでしょうか？

博士

なるほど！でも、エラーが多すぎて赤色ばかりになったら、クリスマスみたいでめでたいのじゃ！