2．技術的なツールだけを重視しすぎる
一部の企業は、「Chef」や「Puppet」「Jenkins」などを使用すればDevOpsだと考えている、とSussna氏は言う。しかし実際には、「人同士の接し方、お互いにサービスを提供する方法、情報共有のやり方を変えなければ効果はない」と同氏は語る。
それに加え、Chefのシニアソフトウェアエンジニアであり、「Effective DevOps」の共著者でもあるJennifer Davis氏は、リーダーが競合他社の使っている製品や、アクションのリストの確認ばかりを気にしていると、成果に目がいかなくなってしまう場合がある、と述べている。
「特定のテクノロジを導入することは、組織にとってメリットになる場合もあるが、無駄な作業になる場合もある」とDavis氏は言う。「ツールはDevOpsを促進するが、適切な文脈と方向付けがなければ、組織に害を与えることがある」
3．DevOpsが1つのチームの中だけで完結すると仮定する
組織が全体として、DevOpsの取り組みは1つのチームだけ、または開発や運用に関わる従業員だけが行うものであると考えていると、取り組みはうまくいかないとDavis氏は述べている。
「組織内のほかの部門の状況を理解することは、無駄な時間や、不必要な作業に費やされる手間を減らし、計画にない作業を最小限にとどめるのに役立つ」とDavis氏は言う。セキュリティ、マーケティング、法務、営業などに関わる部門はすべて、DevOpsによる変革の一部になり得ると同氏は付け加えている。これらのほかのチームも巻き込めば、契約の獲得やコンプライアンスなどの分野でも自動化を進められる可能性がある、とDavis氏は言う。
Sussna氏によれば、製品管理部門を巻き込むことも欠かせないという。「フィードバックや製品の提供、学習などに関するDevOpsのメリットを享受したい場合、これらをテクノロジレベルだけでなくビジネスレベルでも実現したいのであれば、つまり顧客が何を望み、何をしており、顧客に答えるために何を変えなければならないかを知りたいのなら、開発部門や運用部門と同じくらい、製品管理部門が重要になる。生産的な議論を行うには、開発部門と運用部門だけでなく、製品部門にも参加してもらうべきだ」とSussna氏は述べている。
4．変化の管理に失敗する
Cloud Foundryのプリンシパルテクノロジストであり、DevOpsDaysの主催者の1人でもあるBridget Kromhout氏は、DevOpsをはじめとして、どんなIT変革の技術的課題も、人的要因に比べれば大した問題ではないと述べている。「従業員が、仕事がよく理解できないものに変わったり、仕事自体がなくなったりすることを心配し始めると、表と裏の両方で変化に抵抗するようになる」と同氏は述べている。「技術のためだけに、新しい技術を追いかけるべきではない。ビジネス上の価値に基づいて、慎重に、思慮深い変更を行うべきであって、技術の名前に振り回されるのは避けるべきだ」（Kromhout氏）
