ブログ

DevOps ライフ スキル: 調達プロセスの理解と管理

F5 サムネイル
F5
2020年1月23日公開

以前のブログでは、アプリケーション配信に「システム思考」アプローチを取り入れ、効率的な価値提供のために最適化された、よく調整された工場のように運用することがなぜ重要であるかについて説明しました。 そこに到達するには、依存するツールと、それらを選択および調達するプロセスを評価することが必要です。 効率性を高めるには、可能な限り再利用可能なパターンを優先し、チームや環境全体で一貫性のあるツールとプロセスを選択する必要があります。 これは、特に問題となっているツールがインフラストラクチャやセキュリティ関連であり、アプリケーション機能への影響が最小限である場合、ほとんどの人にとって理論的には理にかなっています。 しかし、このようなパターンを構築する上で、過小評価されている障壁がしばしば立ちはだかります。 ベンダーと調達のプロセス。

現在、DevOps エンジニアがクラウドネイティブ ツール、オープンソース ソリューション、または調達チームとの多大な投資ややり取りを必要としないその他の種類の安価な (または無料の) リソースを使用することは珍しくありません。 しかし、必要な効率性を高め、アプリのセキュリティとパフォーマンスを向上させるために、より充実した IT 投資を推進する必要がある場合はどうでしょうか? 

IT投資の根拠を示す

ここでは、DevOps プロフェッショナルが調達プロセスの未知の領域を進む際に留意すべき点をいくつか紹介します。

  1. 価値に焦点を当てる

    このブログを読んでいるあなたは、必要な技術的機能に重点を置くことを好み、一日中 API について話すことができ、最適化に夢中になっている可能性が高いです。 しかし、考えてみてください。多額の小切手に署名する責任がある同僚は、おそらくそんなことにはまったく関心がないはずです。 そのため、新しいツールやリソースの購入をサポートするためにできる最も重要なことは、それがもたらすビジネス価値を顧客の視点で明確に伝えることです。

    多くの場合、これは現在何が欠けているか、何が不足しているかを特定することから始まります。 新しいツールが利用可能になったという理由だけでその購入を依頼するよりも、重大な欠陥や欠点を強調し、その欠陥がどのように問題を引き起こすのか（生産を遅らせる、脆弱性を露呈させるなど）を概説し、その上でそのすべてを解決する新しいツールを提案する方が説得力ははるかに低くなります。

    注目すべき 3 つの重要な要素は、コスト、価値、リスクです。 これらについてビジネス用語で話すこと、つまり特定のソリューションが次のように特定された問題をどのように解決するかについて話すことが重要です。

    • 短期、中期、長期にわたるコスト削減
    • ビジネスの俊敏性を高め、市場投入までの時間を短縮し、新規顧客を獲得する方法
    • 規制遵守の改善、攻撃リスクの軽減、さらには競争上の露出の軽減などにより、ビジネスリスクがどのように軽減されるか

    これらすべてにおいて、それぞれを可能な限り定量化することが非常に重要です。 純粋に定性的な意見を求める人はいません。 確かなデータは重要です。

    調達部門（およびより広義には財務チーム）の同僚にとって、すべてのものにコストと価値があります。 これには、（既知の問題に直面して）何もしないことのコストと、労働者をそれらの問題への対処から解放することの価値が含まれます。 NetOps では、仕事が単調でなくなるという理由だけで日常的なタスクを排除することに価値を見出すかもしれませんが、財務チームでは、同じエンジニアが戦略的な収益創出イニシアチブに集中できるようにすることに価値を見出していることに注意してください。

    F5 のテクニカル ソリューション マネージャーである Will Marken 氏は、「自分自身を問題解決者として位置づけ、価値の提供に重点を置き、提案するソリューションを企業の目標に結び付けてください。これにより、経営陣と彼らの条件でやり取りし、彼らのニーズに応えることができることが示されます。 」と提案しています。

  2. 専門用語を知る: 設備投資とサブスクリプション

    3. チームがサブスクリプション モデルを通じてソリューションを購入することに全力を注いでいるものの、組織が多額の CapEx 支出を中心に据えており、サブスクリプション ベースで IT 投資に資金を提供するプロセスが欠如していることに気付く場合があります。 その場合は、追加の作業を行う必要があります。 設備投資予算要求（時間の経過に伴って償却される単一の大規模な購入など）に切り替える方が簡単かもしれません。 一方、サブスクリプション モデルの導入が遅れていた企業でも、サブスクリプション モデルをサポートする方法を模索し始めています。 財務部門の同僚が独自の組織プロセスの課題に取り組んでいる間、少し余分な時間を確保する必要があるかもしれません。

  3. 粘り強く

    4. 決まり文句のように聞こえるかもしれませんが、これは目的地ではなく旅そのものが重要な例の 1 つです。 大規模な購入を正当化するには、多くの場合、複数回の試行が必要になります。 実際、あなたのリクエストは、2～3 回の予算サイクルを経て焦点を絞り、その過程でサポートを集めてきた他のリクエストと競合する可能性があります。 「いいえ」と言われても諦めないでください。 代わりに、計画を立て、それが起こったらそれを受け入れ、そこから調整しながら前進してください。

    アジャイル ワークフローの他のタスクと同じように調達に取り組みます。 問題を特定し、一つずつ解決し、繰り返し、繰り返します。

  4. チャンクに分割する

    5. 大規模な予算要求の場合、プロジェクトをより理解しやすい部分に分割すると役立つことがよくあります。 これは、次の 2 つの理由で役立ちます。a) 焦点が絞られていると、もっともらしい POC (概念実証) を作成し、現実世界の価値を特定するのが容易になります。b) 担当者が小規模なリクエストを承認するのが簡単になります。

  5. チームを組む

    6. 組織内の他の人から助けを求めるのが良い考えである理由はさまざまです。 まず、直接の同僚やチーム間の同僚は、調達プロセス全般、特に F5 ソリューションの価値に精通している可能性があり、そのため、リクエストの作成 (および既知の危険の回避) を支援できます。 また、提案したソリューションが複数の部門にどのようなプラスの影響を与えるかを示すことで、認識されるリスクを軽減することもできます。 最後に、別のグループがすでに自分と同様のリクエストを試みていること（その場合はそのグループから学ぶことができます）や、同様のソリューションの実装を開始している可能性（その場合はそのグループと提携することができます）を発見することは珍しいことではありません（特に非常に大規模な組織の場合）。   

構造に関する注意

予算要求書を作成する際には、ホワイト ペーパーやデータシートなど、自分の分野のより一般的なドキュメントを作成するときに使用するのと同じ戦術の多くを活用できます。 まず、適切なテンプレートを見つけて、自分のリクエストがマネージャーが慣れている他のリクエストと同じように表示され、読み取れるかどうかを確認します。 また、プロセス全体を通じて複数の同僚に実行してもらい、意見やフィードバックを得ることも含まれます。 F5 の製品開発マネージャーである Jon Gross 氏は、「データシートやホワイト ペーパーと同様に、成功は説明や冒頭の段落にかかっていることが多い」と付け加えています。 彼は、「実際のデータ ポイントを使用して実装ロードマップを強化できる既存のリファレンス アーキテクチャとユース ケースを探す」ことを提案しています。