いいね

エンジニアがいなければ、技術的負債が麻痺する

私が話をしたことのある多くの中堅もしくは大企業はシンプルな課題を口にする。管理者は、Salesforce、NetSuite、Zendeskなどといったビジネス・アプリケーションのフィールドを廃止したいというのだ。使えないし、アクティビティも見られない。きれいにできたらどんなにいいだろう。しかし、どんなことになるか分からない。しかも以前試したときは、そのフィールドを取り去るとあるビジネスユニットのダッシュボードを壊してしまっため、彼らはそれを気にし、何も行動を起こさない。SaltoのCEOであるRami Tamir氏は、これを技術的負債の麻痺と呼んでいる。これがビジネス全体に拡大すると、深刻な問題になる。

例えば、営業チームがピックリストのオプションを変更したいが、CRMチームがそれを理解するのに四半期を要し、その間、いくつかの案件が誤ったルーティングをされるかもしれない。また、取締役会がIPOの時期だと判断したが、混乱しているNetSuiteのインスタンスをSOXに準拠させるのは間に合わないと判断するかもしれない。また、マーケティングチームがリード不足に対処するためにEメールキャンペーンを強化したいが、ビジネスアプリケーションチームがセグメントを移植するのに6カ月もかかってしまうかもしれないのだ。

このような問題は、さまざまな形で顕在化する可能性がある。私が顧客から聞いた3つの実例を考えてみよう。

ERPにNetSuiteを用いている国際的なSaaS企業がある。会計年度の最終日に、多くの重要なレポートが突然機能しなくなり、四半期を終了できなくなった。深夜になるまでチーム全員が原因究明に奔走するはめになった。実装の他の重要な部分で使用されていることを知らずに誰かが本番環境の"保存された検索"を変更したことによるものだった。

Zendeskをカスタマーサポートシステムとして使用している大手小売業の事例をあげよう。管理者が本番環境で直接トリガーの定義に小さなミスをした。そのせいで数十万人の無防備な顧客に混乱を招くようなメールが送られてしまい、Zendeskに新しいチケットがあふれかえった。

ある大手SaaS企業が、リードからオポチュニティへの転換率が大幅に低下した理由を把握できずにいた。数カ月にわたる分析の結果、あるキャンペーンで獲得したリードが、Salesforceのワークフローに問題があるため、営業担当者に割り当てられないことが判明した。そのリードは、そのまま放置されていたのだ。

これらの問題はすべて、貸借対照表が変わるほどの現実的な意味を持つ。そのビジネスの競争力を低下させる。その企業が成長し、これらの問題が深刻化すると、より小さく、より機敏な競合他社に追い抜かれ、自分たちの成長はますます遅くなる。各事業部門が独自のシステムを選択することで、迅速な対応を可能にするために行ったトレードオフが、結局はエラーやミスで首を絞めることになりかねない。それは、これらのシステムが、訓練された開発者の指導を受けずに進化していくからである。

開発者とは、60年にわたる知恵を駆使する人である

企業が成長しても業務システムを機能させ続けたいのであれば、2つの問題を克服する必要がある。1つ目は、ソフトウェア開発の世界に目を向け、DevOpsやアジャイル開発手法を実践している組織で採用されているような優れたプラクティスを参考にすることだ。

60年近く前から、ソフトウェア開発者は、今日のビジネスアプリケーション管理者と同様の問題に直面してきた。遠隔地にある多くのチームが協調して1つの高度な分散システムを構築する方法が必要である。バグがないことを確認するための品質チェックが必要である。プレプロダクション環境では、結果を出さずにテストを行うことができる。バージョン管理によって、何かが壊れたときのためにアプリケーションの多くのバージョンを維持可能にする。

もし、開発者がビジネスアプリケーションにのみ責任を持つのであれば、そのような習慣やツールを活用することになるだろう。再利用性、懸念事項の分離、回復力という観点から考えるだろう。Gitのようなツールを使って、フォーク、ブランチ、マージ、コミットを行い、多くの人が一緒に作業できるようにし、ヒューマンエラーを減らすようにする。おそらく最も重要なのは、全体を考慮することだ。

今日、ビジネス・アプリケーションを管理するほとんどのチームは、サイロ化している。CRMチーム、財務アプリケーションチーム、そしてSaaSを購入し管理するあらゆる種類の"開発者市民"がいて、それぞれが自分のチームの生活をより快適にしようと努力している。これらのシステムのほとんどは、独自のエコシステムとして十分な規模を持ち、多くの製品を含んでいる。また、これらのシステムは統合され、データを共有している。ソフトウェア開発の方法論や原則に精通している人たちは、この問題を今日の多くの人たちとはまったく違った見方で捉えているはずだ。800以上の製品がうまく連携する必要があるのではない。すべて1つの製品、つまり会社のオペレーティングシステムであり、新たに追加されるものは、全体の整合性のために構築・管理される必要がある。

これは最初の問題に過ぎない。2つ目はこれだ。これらのビジネスアプリケーションの多くは、開発者のような考えを持つ人が管理できるように作られていない。

つまり、ほとんどのビジネスシステムは、ユーザーの成長を念頭に置いて構築されている。インターフェイスは、エンドユーザーが物事を遂行するために構築されており、管理者がすべてを整頓するために構築されているわけではない。さらに、アプリケーションのライフサイクル開発で考えるなら、最初のステップを解決するためにしか構築されていない。

画像ソース

つまり、バージョン管理、コードベース全体の検索、複数の環境の管理、場合によってはサンドボックスから本番環境に変更をプッシュする単純な機能など、開発者が期待することを行うためのネイティブな機能が欠けている。現在では"開発"環境を提供しているところもあるが、必要なものがすべて揃っていることはほとんどない。

ありがたいことに、2つ目の問題の解決策は、1つ目の問題の解決策であると私は考えている。開発者は、必要なシステムをすべて持っていないことが多いので、仕事をこなすために必要なものを作って借りる。開発者は、Gitツールを使って構築しているものを管理しやすい塊に抽象化し、チケット管理システムを使って作業を記録し、優先順位をつけ、必要に応じて自分たちでツールを構築する。

開発者のように考えるように訓練されたビジネス・システム管理者が、このような機能を求めるようになれば、より多くのビジネス・システム・ベンダーがこのような機能を作るようになるに違いない。そうでなくても、新しく"開発者"になった人たちは、エンジニアのように、うまくいけば自分たちで作ることができるだろう。

ノーコード、ノープロブレム

先ほどの3つの実例を思い出してほしい。NetSuite、Zendesk、Salesforceで問題を抱えた企業だ。それぞれ、ノーコードのDevOpsツールや方法論を採用し、システムの周囲にガードレールを作っていた。

NetSuiteを使用している国際的なSaaS企業は、最も重要な設定にアラートを導入している。四半期を締めくくるために必要な保存された検索の条件を誰かが変更した場合、管理者はアラートを受け取る。

Zendeskを使用している大手小売業は、管理者が本番環境で直接変更を加えることを禁止している。各管理者は自分のサンドボックスで設定を作成し、それを統合のために別のサンドボックスに移し、さらにテストのために別のサンドボックスに移し、本番環境に実装する。

売上が伸び悩んでいる大手SaaS企業では、Salesforceの各組織の完全な"設計図"を提供し、それを調査して変更を加えることが可能なDevOpsツールを使用している。重要なワークフローが機能していない場合、それを発見し、テストし、数ヶ月ではなく数日で修正できる。

ノーコード開発者を育成しよう

もしビジネスアプリケーションの世界が、過去60年間のソフトウェア開発における考え方、フレームワーク、方法論を参考にすれば、技術的負債の麻痺はもっと少なくなっているだろう。営業やマーケティングチームが、運用に支障をきたすと感じることは少なくなるだろう。ビジネス・システムのせいで成長できないと感じる企業も少なくなるはずだ。

私は、システムはビジネスと同じように素早く進化し、その成長をサポートするべきだと考えている。それを実現する唯一の方法は、ノーコード開発者の増加だと思う。

関連記事:

• デベロップメント
• カルチャー&手法
• Development

あなたのメールアドレスはこちら

国を選んでください。 選択してください InfoQ.com がプライバシーポリシーに従って私の個人情報を扱うことに同意します。

We protect your privacy.