セルフホスト型アプリケーションの購入が難しいのは、IT 部門がサーバー・ネットワーク・ストレージの費用、インストール・アップグレード・運用・サポート、AD ベースのシングルサインオン、メール、Slack、バックアップ・復旧、データのエクスポートと移行、そしてサイバーセキュリティまで責任を負わなければならないからだ
アプリケーション 1 つが侵害されるだけで会社全体の IT が危険にさらされる可能性があり、分離やゼロトラストを適用しても攻撃対象領域とセキュリティコストは増える
実際、セルフホスト型アプリケーションを買うこと自体は簡単な部分で、難しいのは事業上必要な期間、毎日安定して運用することだ。法的にデータを長期間保管しなければならない場合もある
現場の IT が求めたツールであっても、一部の技術管理はできるかもしれないが、時間がなかったり、開発者であってシステム・ネットワーク管理者ではないためにできない場合が多い
結局、会社の IT と分離されたサンドボックスを使うか、バックアップや AD のような便利機能を諦めるか、シャドー IT として自分たちで実装・維持しなければならない
だからSaaS とクラウドが成長した理由の一つは、こうしたコストを外部化できる点にあると思う
本、ライセンス、ハードウェアをペンや紙のような消耗品と見なしたようなもの。IDE のような小さなローカルソフトウェアには、概ね当てはまるかもしれない。
開発者に管理者権限を信頼して与える、または会社の IT 部門がインストールを許可できる、という前提が必要になる。
全員に小さな予算を与えるか、チーム・部門単位で管理すればよいが、会社の IT 統合が必要になった瞬間にはうまく機能しない。
公平に言えば、まだ誰も terraform apply を SAP の承認フローと統合する方法を見つけられていないからだ。
エンジニアが意思決定者になるビジネスモデルは十分に成り立つ。ただし、エンジニアが範囲外への直接的な影響なしに局所最適化できるツールに限られる。
IDE が最良の例だ。会社のエンジニアたちに、それぞれの生産性を高める個人の IDE 選択を認めても、その決定をすべて足し合わせた全体への影響は許容範囲に収まり得る。Jetbrains がそれを示している。
しかし、すべてのツールがそうではない。元記事は Redis、Terraform、AWS のように、2つ目のカテゴリに属する例を扱っている。
IDE と違い、データベース、インフラ管理、クラウドインフラでは、個人の決定が広がると問題になる。会社は異質なスタックを維持しなければならず、ベンダーはあるチームが Redis を選んだという理由だけで、意味のあるエンタープライズ契約を作ることはできない。
そのため、ある程度の標準化が必要になる。その時点では選択の影響とライセンス規模が大きくなり、エンジニアリングリードだけでなく財務も発言権を持とうとする。そうするだけの理由がある。
そして財務が入ってきた瞬間、ほとんどのエンジニアにとって難しい言語で、その選択を正当化しなければならなくなる。
私の購入権限はこんな感じだ。「この開発者ツールを買えば、開発者の時間を X 時間節約できます」と上司に言う。
ここで X がツールの価格に対して十分に大きければよい。このやり方はかなりうまくいくので頻繁に使っていたら、上司も今では懐疑的に見るようになった。
1件のコメント
Hacker News の意見
ほぼその通りだが、営業や財務の担当者にもそうした購買権限はあまりないと思う。だから皆、会社が許可したツールや無料プランを使うことになり、結局は上司に売り込まなければならない
時間を節約できる、プロジェクトをより透明にできる、裁量を減らせる、といった形で説得する必要がある
Excel がこれほど広く使われているのも、このためである可能性が高い。会社の IT 部門が許可してくれる最も強力なツールが Excel でもある
営業や財務部門で働きながら、PC に WSL をインストールする許可を取ろうとしてみれば分かる。Web アプリが人気なのも、会社の IT 部門が把握していなければブロックできないからだ
マーケティングマネージャーなら自分のカードで Basecamp を支払えるかもしれないが、セルフホスト型ツールを導入しようとすると、「コンピュータは私たちが管理し、仕事のやり方も私たちが決める」という IT ポリシーを通過しなければならず、話が大きくなる
すべての m365 ライセンスに含まれており、永続ライセンスも長い間比較的安価だった
営業チームに WSL を許可しようという話は、実際の営業担当者と働いたことがあるのかと聞きたくなる。99% の会社では、技術に明るい営業担当者でさえ、助けなしにメール添付を送るのがやっとなのに、WSL で何をするつもりなのか分からない
こうした細かな購入をすべて承認するのは手間がかかりすぎるし、確認しなければ、使われないサブスクリプションがあちこちに積み上がったり、会社にあまり役立たないものを大量に買うことになったりする
一方でマーケティング側は購買権限がかなり大きく見えたが、業務そのものがあらゆるものを買うことに関係しているからのようだ
アプリケーション 1 つが侵害されるだけで会社全体の IT が危険にさらされる可能性があり、分離やゼロトラストを適用しても攻撃対象領域とセキュリティコストは増える
実際、セルフホスト型アプリケーションを買うこと自体は簡単な部分で、難しいのは事業上必要な期間、毎日安定して運用することだ。法的にデータを長期間保管しなければならない場合もある
現場の IT が求めたツールであっても、一部の技術管理はできるかもしれないが、時間がなかったり、開発者であってシステム・ネットワーク管理者ではないためにできない場合が多い
結局、会社の IT と分離されたサンドボックスを使うか、バックアップや AD のような便利機能を諦めるか、シャドー IT として自分たちで実装・維持しなければならない
だからSaaS とクラウドが成長した理由の一つは、こうしたコストを外部化できる点にあると思う
50 ドルの本を買うために争わなければならないなら、おそらく会社選びを間違えている
ただし、ある開発者たちが Notion を内部テストしようとしてカードで非公式アカウントを作り、そこに重要な概要文書を作成してリンクを回した
それを見ようとした会社の半分が暗黙のうちにアカウントを作り、翌月 CFO に1 万ドルの請求書が届いた
開発者に購買権限を与えてはいけないという話は、たいていこういう形で始まる
多くの SaaS 企業が前払い決済や固定費の上限オプションをあまり提供しないのには理由がある。詐欺に近い
これを「開発者に購買権限がなくなる話の始まり」だとは信じがたい
例えば、ツールが分断されて一度の検索で情報を見つけられなかったり、チームごとに別のツールへ個別にログインしなければならなかったりする
会社の知的財産が入ったツールを各チームがばらばらに管理すると、SOC 準拠を目指す際にはコンプライアンス上の悪夢になる
本や学習資料を買うのは良いと思う
四半期あたり 1 億ドル以上のエンジニアリング用ハードウェア・ソフトウェア・サービス支出を決定してきた立場から見ると、開発者ツールを作るなら、まず現在の開発者たちが非常に有用だと感じ、強く支持するようにしなければならない
不透明な契約、ロックイン、データセキュリティ・プライバシー、シングルサインオン・認証統合のような拒否権項目に触れてはいけない
価格も納得できるものでなければならない。何らかの変数に線形比例する価格は、財務スプレッドシート上では筋が通らない可能性が高い。開発者ごとの月額課金は分かりやすく、全社フローティングライセンスはさらに良く、全社無制限の一括料金のほうが合う場合もある
最後の方式でも、クラウド計算・ストレージのような従量コストはそのまま転嫁できる。顧客のクラウドアカウントに直接デプロイできれば、データセキュリティ・プライバシーの問題も解決する
請求上限、使用量上限、高額な使用料を発生させる設定の制限、十分な使用量レポートといったコスト管理を提供すべきだ
うまくいけば、コミット支出を伴う複数年契約も可能だ。サービスの信頼性を維持し、大口顧客とは四半期ごとに確認して満足度と満たされていない要望を把握する必要がある
専任エンジニアやサポートのような高度なプロフェッショナルサービスも提供し、課金できる。収益性が高く、特定の顧客を獲得または維持するうえで決定的になることもある
顧客社内で製品が議論を呼ぶ可能性があり、反対者が製品導入を失敗させることもあるため、プロフェッショナルサービスが初期の統合・実装を担えば、IT の門番の介入を減らし、実際のユーザーに届けられる
顧客が自分たちで作れると強く信じている製品は、売ろうと努力しないほうがよい。その判断が間違っていたとしても、最初は勝てても結局は負ける可能性が高い
問題は構築対購入の投資対効果をいつ判断するかだ
統合コストが非常に高い製品を買うことは、実質的には作ることと同じだ。統合には開発者の時間が必要で、その時間は別の仕事や製品自体に使えたはずだ
概念実証の統合中に明らかになればよいが、その段階でも実行する開発者の時間が必要になる
会社によって異なる。以前勤めていた会社は、「仕事を楽にしてくれる本、ライセンス、さらにはハードウェアまで、必要なものはそのまま買ってよい。意思決定にかかる管理コストのほうが高いので、デフォルトは即時承認」という方針だった。
開発者たちが購入に殺到したかというと、そうではなく、方針の前と同じ程度にしか買わなかった。実際、日々の仕事はかなり楽になった。
開発者に管理者権限を信頼して与える、または会社の IT 部門がインストールを許可できる、という前提が必要になる。
全員に小さな予算を与えるか、チーム・部門単位で管理すればよいが、会社の IT 統合が必要になった瞬間にはうまく機能しない。
10年、20年放置すれば、まったく違って見えるかもしれない。ゆっくりと見えないコスト増が積み重なり、少し控えめに使う人たちが他人を浪費家に見せないために物を買わなければならない文化になることもあり得る。
コスト増を助長する微妙なメカニズムは多いので、逆方向に押し戻す仕組みが必要だと思う。まだ解決されていない問題だと見ている。
余裕のある予算上限を設けつつ、使い切れという意味ではないとはっきり伝え、年末に余った金額の一定割合を、誰もが受け入れられる良い寄付先に寄付するルールもあり得そうだ。
「本は買って構いません。ただ、その本のせいでポニーへの寄付が5ドル減ることは覚えておいてください」といった具合だ。マナティーにすると、私は Chromebook で仕事をする危険がある。
よくても無能なことが多く、管理者を数人減らして、その給与を裁量予算に回すほうがよい。お互いに得だ。
会社の注文・配送手続きを自分が知る必要がないので、これまで見た中で一番よい方式だった。
従業員だったとき、この問題に一度遭遇した。ThinkPad が欲しかったが、経営陣はひどい Dell に固執し、最終的には ThinkPad を受け取った。
それ以外では、本やツールを頼めばそのままもらえたし、高価な分離型キーボードも可能だった。
今は自営業になったので、必要なものはそのまま買っている。実際には、それほど多くは必要ない。
お金を払うほど有用な「開発者ツール」は多くなく、自分のワークフローに統合するだけの価値があるものはさらに少ない。時間がたつほど、この最後の部分がより重要になった。
ひどい Dell を渡され、壊れ、またひどい Dell を渡され、また壊れ、また Dell を渡された。
「当社は Dell としか契約していません」と言われるが、そもそも Dell と契約すべきではないのでは、と言うと沈黙が流れ、そこでようやく頭が回り始める。
Dell が壊れたときこそ人生で最高の瞬間だと気づく。新しい機材を送るまでに、購買発注と発注政治の層を通過するのに5日かかり、その5日間は厳しい会社のセキュリティポリシーのせいで何もできない。
だから5日間寝て、友人たちと連絡を取り、また人間に戻る。
Dell を愛している。ThinkPad は欲しくない。
個人用には MacBook を使っている。
以前、エンジニアリング会社の営業中心の子会社で働いていた。
初期には100ドルの昼食をごちそうするのは問題なかったが、自分のコンピュータ用の30ドルのカードは買えなかった。
逆に親会社では、5,000ドルの試験装置は簡単に買えたが、ファストフード店に連れていくには書類を3部作成しなければならなかった。
任期の終わりごろには、どちらの会社でも、その書類なしには事実上何もできなかった。
成功した開発者ツール企業の多くは、開発者ではなく上司にマーケティングして稼いでいた。技術だけでなく、さまざまな分野でそうだ。
自分の領域外の物を買おうとすると、ばかげて複雑だった。
最近は会社が「法人カードがあるから使え」と言い、イベント関連費用は EVP たちが承認してくれた。一般的ではなかったが、ときには官僚手続きを切り捨てる必要があると彼らが分かっている点は印象的だった。
次に普通の経費精算をしたら、20ドルのタクシー領収書に出発地と目的地がないという理由で経理部と争うことになりそうだ。
ソフトウェアライセンスは自分で買い、税務上処理している。そのほうが見せかけの節約を避けられる。
適切で安価なツールを見つけて自分で購入したおかげで、職場で表彰もされ、特定のプロジェクトでは代替不可能になり、昇給も受け、やりたい仕事を選べるようになった。
自分のJetbrains ライセンスが代表例だ。それなしでコードのリファクタリングをすることは想像しにくい。
会社のコスト削減が止まれば、職場内の競争相手はもっと増えるだろう。
以前の雇用主は低いマイレージ単価を支払っていたので、差額を確定申告で請求していた。
ソフトウェアについては、許容される費用かどうかの判断基準がどう適用されるのか、よく分からない。
ほとんどの会社が仕事に合った正しいソフトウェアを買ってくれないので、私もチームで最も効果的に働く人間になった。他の人たちと違い、速く効率的に処理できるからだ。
Azure、AWS、Google Cloudに載せられるなら話は変わる。
鉛筆1本でさえ承認なしには買えないが、会社のクラウドでは、何も聞かれずに数千ドルを使える。
ところが今回は、月額1,000ポンドを超える AWS サービスを選んだ。カードの請求書を受け取ったときに大きな厄介事になり、すでに翌月分の料金もかなり発生していた。
その後は、もっと厳しく統制しなければならなくなった。
ただ、エンタープライズライセンスを買えば節約分だけですぐに元が取れるので、本業ではないにせよ試してみなければというプレッシャーを感じている。
terraform applyを SAP の承認フローと統合する方法を見つけられていないからだ。エンジニアが意思決定者になるビジネスモデルは十分に成り立つ。ただし、エンジニアが範囲外への直接的な影響なしに局所最適化できるツールに限られる。
IDE が最良の例だ。会社のエンジニアたちに、それぞれの生産性を高める個人の IDE 選択を認めても、その決定をすべて足し合わせた全体への影響は許容範囲に収まり得る。Jetbrains がそれを示している。
しかし、すべてのツールがそうではない。元記事は Redis、Terraform、AWS のように、2つ目のカテゴリに属する例を扱っている。
IDE と違い、データベース、インフラ管理、クラウドインフラでは、個人の決定が広がると問題になる。会社は異質なスタックを維持しなければならず、ベンダーはあるチームが Redis を選んだという理由だけで、意味のあるエンタープライズ契約を作ることはできない。
そのため、ある程度の標準化が必要になる。その時点では選択の影響とライセンス規模が大きくなり、エンジニアリングリードだけでなく財務も発言権を持とうとする。そうするだけの理由がある。
そして財務が入ってきた瞬間、ほとんどのエンジニアにとって難しい言語で、その選択を正当化しなければならなくなる。
私の購入権限はこんな感じだ。「この開発者ツールを買えば、開発者の時間を X 時間節約できます」と上司に言う。
ここで X がツールの価格に対して十分に大きければよい。このやり方はかなりうまくいくので頻繁に使っていたら、上司も今では懐疑的に見るようになった。
価値のあるツールがないという意味ではない。あるにはあるが、ごくまれだ。