リリースのあとに残る仕事。AMS(アプリケーション運用保守)を続ける理由

ソフトウェアの多くは、プロジェクトとして発注されます。開始日があり、リリース日があり、リリースが終われば閉じる予算がある。

しかし、そのソフトウェアが支える事業のほうには、どれも当てはまりません。事業は動き続け、人が増え、売るものも売り方も変わっていきます。

リリース当日には正しかったはずのシステムは、静かに、少しずつ、その会社の実態から離れていきます。

アプリケーション運用保守、一般にAMSと呼ばれる仕事は、プロジェクト計画が終わったところから始まります。

リリースはゴールではない

システムについて本当に意味のあることは、実際に人が使い始めてから現れます。

• アクセスが、誰も想定していなかった形で来る。
• 画面が、仕様書の上では筋が通っていたのに、一日に二百回操作する人には三クリック長すぎる。
• 連携先が、一年間安定していたAPIを変える。

これらは失敗ではありません。それ以前には持ちようがなかった情報が、ようやく手に入った瞬間です。

私たちのミッションが描いているのは、この輪です。理想の未来を描き、その実現に努め、そこで学んだことでまた未来を描き直す。どちらの半分にも終わりはありません。

その輪がまだ回っているかどうかは、外からでも確かめられます。

三つの問い

AMSの反対側にある状態を、名前を知らないまま抱えていることがあります。事業が依存しているシステムについて、次の三つを問いかけてみてください。

いま、誰が面倒を見ていますか。

つくった会社はまだ存在し、そして今も応えてくれますか。

最後に変更したのはいつですか。

答えが曖昧なら、そのシステムは放置されています。動いてはいます。しかし担当した開発者はもういない、制作会社は新規案件しか受けない、あるいはベンダーは二人体制でそのうち一人が辞めた。なぜその画面がそう動くのかを説明できる人が、いま社内に誰もいない。変更のたびに、費用もリスクも重く感じられる。そのシステムは壊れたのではありません。動いたまま、見捨てられたのです。

たとえばマレーシアでは、売上RM500万を超える企業の多くが、この二年で請求関連のシステムに手を入れました。LHDNの電子インボイス義務化があり、選択の余地がなかったからです。期限に向けた作業は、多くの場合すばやく終わりました。いま重要なのは、もっと静かな問いです。その連携をいま誰が見ているのか。そして制度が次に変わったとき、誰がそれを引き受けるのか。

この問いにどう答えられるかは、その会社がどう組み立てられているかでほぼ決まります。

設計・開発・運用は、ひとつの輪

私たちは、設計と開発と運用を順番に並んだ三つの工程としては動かしていません。三つはひとつの輪の中にあり、運用で分かったことが、次の設計の材料になります。

だからシステムを運用するのは、他人のコードを引き継いだ別部隊の窓口ではありません。それをつくり、つくり続けてきたチームです。

引き継ぎとは文脈が失われることであり、変更を安全にしているものの大半は、その文脈である。

AMSを、手順書をなぞるサポート機能として置いていないのも同じ理由です。システムを見る人には、その裏側にある業務の理屈が分かっている必要があります。

そして、私たちがつくっていないシステムもお引き受けするのは、同じ理由からです。放置されたシステムとは、輪を失ったシステムのことです。最初の数か月は、たしかにゆっくり進みます。読み、書き起こし、大きな変更の前に小さく安全な変更を重ねます。しかしそれを終えたとき、そのシステムには再びチームがあり、輪は閉じています。

その輪が毎月何をしているのかは、地味ですが、はっきり書いておく価値があります。

AMSが実際に担うこと

• 監視と障害対応。 お客様のお客様から報告される前に、私たちが気づきます。
• セキュリティと依存関係の更新。 緊急時ではなく、計画的に当てていきます。
• 性能改善。 当初の設計が想定していた範囲を超えて増えるデータとアクセスに合わせます。
• 小さな機能変更。 実際に使い始めてから出てくる、細かな要望に応え続けます。
• レポート。 毎月、何をして何時間かかったかを、請求書に添えてお出しします。消化したチケットの要約ではなく、実際のシステムに対する実際の作業を、時間で。
• 顔の見えるチーム。 そのシステムがなぜその形をしているのかを、すでに知っている人たち。

最後のひとつは、いちばん見えにくく、いちばん価値があります。今日の午後に返ってくる回答と、コードを一週間読むところから始まる回答の差だからです。

壊れたときに人がいる、という契約もあります。AMSが費用を払う相手は、そのシステムを持ち続ける価値のあるものにしておくチームです。

事業の変化に合わせて、システムを変える

新しい販売チャネル。変わる税制、統合、三倍になる繁忙期の負荷、去年は誰も考えていなかった市場への進出。

どれもまず事業の変化であり、ソフトウェアの変更はそのあとに来ます。すでにシステムを知っているチームなら、数日で吸収できます。初めてそのコードベースに向き合うチームは、その数日をどこから手をつけるかの見極めに使います。

つくったものをお客様と一緒に動かし続け、事業の変化に合わせて変えていく。

ただしこの約束は、何年経ってもまだそこにいなければ意味がありません。

「長く続く」とは、具体的に何か

「長期的」という言葉には、具体的な中身があるべきです。ですので、数字でお示しします。

今年の売上の九割は、二年以上のお付き合いがあるお客様からのものです。売上上位四社はいずれも四年以上、最も長いお客様は五年を超えています。日本の公共施設のウェブサイト群は2021年からお預かりしており、いまでは二十を超えるサイトを、ひとつの継続契約のもとで六年目に入って運用しています。そして直近十か月、私たちの仕事を支える保守費は一円も動いていません。同じ範囲のまま、毎月更新されています。そのシステムが、費用に見合い続けているからです。

私たちは意図して、案件数を数える会社ではありません。使える手は限られており、それはすでにご一緒しているお客様のものであってほしい。数量の代わりに差し出しているのは、責任です。今年も来年も、同じ名前のエンジニアがあなたのシステムを見ます。

私たちは日本の会社であり、そこから期待されるとおりの運用をします。更新は、事後ではなく事前にお知らせします。記録は、特別な対応ではなく習慣として残します。

長く関わるとは、お客様が働いている時間に連絡がつくということでもあります。

あなたの一日に合わせた、国をまたぐチーム

優秀な人も良いアイデアも、ひとつの場所にだけあるわけではありません。東京の本社に加えて、カトマンズにはエンジニアリングチームである N.D.S. Venture があり、いまは東南アジアへも広がりつつあります。

ネパール訪問の際、迎えてくれたカトマンズのチーム。

クアラルンプールに拠点があるなら、そこは私たちの働き方のちょうど中心にあたります。カトマンズは約二時間遅れ、東京は一時間先。ふつうの一日で、ご自身のタイムゾーンのまま、およそ十二時間の連続したカバーになります。東京が動き出してから、カトマンズが終えるまで。担うのは、手順書を読む交代制の当番ではなく、そのアプリケーションを知っている人間です。

一日のこれだけの時間を、人を消耗させずに支えるには、人数だけでは足りません。

AIネイティブに、それでも責任は人が持つ

私たちはAIを、運用の輪の外側ではなく内側に組み込んでいます。

• アラートの一次切り分け。人を起こす前に。
• ログの読み込み。人が読むより速く。
• 変更の下書きとレビュー。
• ドキュメントの更新。コードと歩調を合わせて。

保守を高く、遅くしていた反復作業は、これで確実に減ります。一方で、AIが引き受けないものがあります。当事者としての責任です。

すべての変更には名前のあるエンジニアがつき、作者以外のレビューを通ります。この仕事で自動化できない部分がそこであり、お客様が実際に買っているのもそこだからです。

長く続く関係が強いのはなぜか

私たちと取引のある会社の多くは、一度きりではなく継続的にご依頼くださっています。何年も関係が続いているお客様も少なくありません。いまの仕事の大半は、そうした関係から生まれています。

そこに私たちは意味を見ています。大きな単発の案件よりも、続いていく長期的な関係のほうが大切だからです。描いた理想の未来を実際に形にしていく背骨は、その関係です。探求、実践、調和。学び続け、学んだことを実践し、共に働く人たちを大切にする。それが最もよく見え、最もごまかしのきかない場所が、リリースから何年も経ったあとの時間です。

お問い合わせ: [email protected]