左から、インフォコム（株）の吉田さん、南さん、江藤さん、佐々木さん

Zabbixプレミアムパートナーであるインフォコム（株）の皆さんに、6月の「Interop Tokyo 2019」に続いてお話を伺いました。最近のユーザのニーズや傾向、サービスの販売やソリューションの提供方法など、システム運用や監視の現場の深い話が飛び交いました。

インフォコム株式会社
エンタープライズ事業本部 LAソリューション部 コ・クリエーショングループ
上級主任
吉田 和也 さま

同　エンタープライズ事業本部 LAソリューション部 コ・クリエーショングループ
上級主任
南 一明 さま

同　エンタープライズ事業本部 LAソリューション部 コ・クリエーショングループ
技師
江藤 敏之 さま

同　エンタープライズ事業本部 LAソリューション部 コ・クリエーショングループ
課長
佐々木 宏 さま

インフォコム株式会社
https://www.infocom.co.jp

求められているのは「SI仕事」ではなくて…

IIJ 福原（以下、福原）　6月の「Interop Tokyo 2019」のインタビューに続いてですが、その節はありがとうございました。あれ以降、どうですか？

インフォコム 吉田（以下、吉田）　今年のInteropの後は、Zabbixブースにご来場いただいた方に対しては、特に個別の営業はしていないんですよ。それでも、なぜか引き合いは多くて忙しいですね。Zabbixに関しては、なぜかバージョンアップに関するご相談が多くて、熱を帯びているのを感じています。今日も直前ギリギリまでいろいろ追われていました。

インフォコム 江藤（以下、江藤）　何でなのか、理由はっきりとは分からないんですよ。弊社がZabbixのプレミアムパートナーだからなのか、Interopなのか。ただ、忙しすぎるのは間違いないですね（笑）。

インフォコム 佐々木（以下、佐々木）　私たちがいうのも何ですが、Zabbixはよくできてるなと思うんですよ。オープンソースでちゃんと監視ができて、アラートも通知できる。もし、サブスクリプションにしていたら、MRTGなどの方が人気になっていたかもしれません。コストや機能、リソース、コミュニティなど、さまざまな点で人気が広がり続けているのかもしれません。

Zabbixオフィシャル日本語サイト
https://www.zabbix.com/jp/

MRTG: The Multi Router Traffic Grapher
http://www.mrtg.jp/doc/

福原　いいですね。「運用ナビ」もささやかながら、プラスの影響が出ていることを願っています。何か、お客さんのニーズの傾向はありますか？

インフォコム 南（以下、南）　「SIとしての業務」を求めているお客さんは、恐らく、半分もいないですね。

吉田　SIは自社で処理する一方、「外部としてできることの部品」を求めていらっしゃる感じはします。弊社も『ガッツリSIをやらせてください！』ではなく、アプライアンス（専用機器）や、インプリメント（実装）など、『こんな形で、御社のビジネスを支援できます』というソリューションのメニューを提示して、その中からお客さんが興味あるところを発注いただくような傾向です。

江藤　以前は『構築を全部任せてください、何でもできます！』をアピールしていたんですが、弊社が提供できるサービスの中味が分かりやすくなって、ようやくお客さんに理解され始めているのかもしれません。

南　LoadStarにしてもZabbixにしても、求められていることと、やれることをはっきりさせることで、弊社のリスクも減らせますし、何よりいいものを提供できます。

佐々木　最近、お客さんの要求レベルが下がっているような気がしませんか？SI的なアプローチを止めて、お客さんが考えたり悩んだりする必要がないソリューションを提供しなければ、理解してもらえない気がします。全部はできなくても、お客さんが欲しいところだけ、または弊社が提供できるところだけを明確にする、と。全体のプランニングまではなかなか。

福原　いいこといいますねぇ（笑）、その通りです。

吉田　「外のSIに丸投げ」という企業は少なくなっていますね。サービスをメニュー化・素材化することで、どこまでを自社で処理し、どこからを弊社にご依頼いただくのか、境界線を引いてリスクや責任を明確にすることが、お客さんのメリットにもなっています。

佐々木　例えば、とある大企業の情報系子会社の例だと、親会社との間のインターフェイスは決まっていて変えられない。変えられるのは小さなところだけで、リプレイスも何年かに一度だけ。セキュリティのために、外部システムに繋げないとか、アウトソースできない。こういう場合は、現場で受け入れられるソリューションの提案が本当に難しいです。

福原　本当にそうだと思います。UOMは、開発以来いろんなアップデートを繰り返しながら、8年掛かってやっとここまで来ているんです。しかし、お客さんにとっては、古いやり方を捨てて、『8年分のエッセンスを今日の明日で導入して、システム運用を変えましょう！』というのは、どんなにUOMがよかったとしても、そりゃハードルが高いなと思うんですよ。

佐々木　ITシステムが多くなって複雑化しているのに、投資されていないですよね。大手で有名な会社ほど、社内IT人材がいない。人が元々少ないのに、さらに減らそうとしている。超一流企業ですら『プロジェクト計画を見せてください』といっても、『何もありません』とかありますよ（笑）。誰でもできると思われているのかもしれませんが、スペシャルツールなんてないんです。

福原　すごくわかります。RFP（提案依頼書）を出してもらっても、何も書かれていない（笑）。『監視する』要件だけで、見積なんて出しようがない。

プロの現場でも、キーワードは「シンプル」

福原　サービスを開発していると、どうしても『あれもできる！これもできる！』と、機能ベースで訴求したくなりますよね。それにSI業務って、見積が面倒で、高いし、どこまでやってもらえるかかわからないじゃないですか。『どこまでも、金と根性で何とかする！』、もうそんな時代じゃない気はします。
UOMも機能をどんどん開発しなければいけないんですが、そうなると複雑になってしまう。シンプルで分かりやすくするニーズは、実は僕らも感じています。実は、UOMも新しく、初期設定から全部お任せで安価に提供する「シンプルパック」というのを出そうとしているんです。メニューや料金体系もわかりやすくしました。ヒアリング段階でも、やっぱり、お客さんのウケはいいんですよ。原価的にはちょっと安すぎるような感も…（笑）。

UOMシンプルパック（2019年10月発売）
https://www.iij.ad.jp/svcsol/campaign/uom_201909.html?r=0052a

吉田　SI業務はなかなか辛いですよね。要件を調整するのにも、時間が掛かりますし。お客さんの方も忙しくて時間がないので、割り切る方が喜ばれます。ただ、『実際に受けてみたらバリバリのSI仕事だった』みたいなこともありますよ。初動の判断が難しいんですが。

福原　「毒饅頭」みたいなもんですね（笑）。でも、会社も結局は「人」次第なので、その辺りはお客さんにも寄るのでは？

吉田　そうなんですよ。その辺りは、営業の嗅覚というか。最近の案件なんですが、弊社がお客さんに、正直に『Zabbixではできません』ということでお断りしたら、逆に『そこまでZabbixのことを熟知しているんだったら、こっちを手伝ってください』と、別のソリューションで弊社のノウハウを活用して欲しいというオーダーをいただきました。

福原　『他の方法だったらできるんですよね！』ってことですか？

江藤　そうなんです。技術メンバーは正直ですからね。そのお客さまにとっては、できない理由をはっきり説明してもらったのが、初めてだったんだと思いますよ。まぁ、ありがたい評価ではありつつ、ノウハウをすべてタダで提供するわけにもいかないので、ちょっと上手く乗せられたような気もしないではなく…（笑）。ただ、ハードルを上げた分、下手なものを作れないので、これからが大変です。

福原　結局、その場凌ぎの嘘をいっても仕方ないですよね。いい加減な営業担当者が、お客さんに適当なことをいって取ってきた仕事を、技術サイドで何とかしないといけないのは辛いですし。御社はいい会社だと思いますよ。

佐々木　ありがとうございます。シンプルなアプローチは重要ですね。お客さんの業種や地方ごとの特性を理解しようとしたら、最短でも3年は掛かります。SIerさんたちと上手く付き合っていけるようにやり方を明確にしていかないと、正直しんどいですね。
社内の意思疎通もそうです。弊社も、営業と技術、マネージメントのチーム間で、ちゃんとコミュニケートできているつもりでズレていることもあります。シンプルに変えていくしかないと思います。

難しく使いたいマニアもいる！？

吉田　そんなシンプルとは逆に、マニアックな人もたまにいるんですよ。7月の横浜でのセミナーは、地場企業の方もそれなりにいらっしゃいましたが、6月の幕張のInteropにも来ていた方は、ほとんどいなかったんです。テーマは、Zabbixとコンテナ監視、パブリッククラウドだったんですが、質問がとてもマニアックで、自分が突き当たっている問題の具体的な解決方法を探していらっしゃいました。

佐々木　UOMもZabbixも、使い始めるとユーザの方がどんどん詳しくなっていきますよね。Mackerel（マカレル）やPrometheus（プロメテウス）の話が出たり、Dockerを使っている人からコンテナ監視についてのコアな質問がありました。

Mackerel
https://mackerel.io/ja/

Prometheus
https://prometheus.io/

江藤　ただ、コンテナはサーバとして使うよりも、サービスのオブジェクトとして使う方が正しいので、本来、監視の必要はないんですけどね。

福原　いや、本当にそうなんですよ！コンテナはそれ自身で完結してくれるからいいんで、わざわざ外から見に行くのはナンセンスです。アプリケーションも作り替えなければならないのに、そこまでするコストメリットが一体どれだけあるか。コンテナのメリットは、スクラップ&ビルドなので、いちいち監視と停止を繰り返す必要はないはず。

吉田　業務上、ツールを細かく詳しくカスタマイズする必要があるのは当然ですが、プロが毎日使うツールだからこそ、シンプルなのが求められているのかもしれないですね。

企業側が、自動化を受け入れられるか？

福原　確かに、UOMは時代を先取りして自動化を進めてきました。一部には『ちょっとやり過ぎでは？』という声も無かったわけではないんですが、これから進むべき方向はこっちだろうな、と。
実は、UOMのひと世代前、15年ほど前の話ですが、弊社のサポートセンターで巨大なAccess（！）を使っていたんですよ。アラートが上がってきたら、お客さんの名前とノード名を入れると、該当する手順書を条件検索するためだけの（笑）。また、UOMを開発した当初、営業に行ったお客さんでも同じような仕組みがExcelで作られていました。提案はしたものの、結局、相見積もりで負けてしまったんですが、後でその敗因を聞くと『今さら変えられないんです…』と。
ただ、それも十分理解できるんです。先の巨大なAccessにしても、弊社で今も稼働していますし。組織の業務上、なかなかすべてを一度には変えられないですよね。
ただ、裏返せば、これがUOMで自動化するきっかけの、一つになっている面はあるかもしれません。

南　ありがちですね。自動オペレーションを謳ってシステム保守サービスを提供している会社も結構ありますが、蓋を開けてみると、システム上の制約があったり、手順書がないとダメだったり。『それをキレイに出せるんだったら、御社にわざわざ頼まないよ！』という話で、痛し痒しではあるんですが。

福原　手順書の中に、ログインするノードのアカウントとパスワードを書いておくわけにはいかないので、ExcelかAccessか紙か、別のところに保存しなければならない。また、ユーザに連絡するときの情報も同じように保存して、必要になるたびに参照する。『そんな非効率なことを、いつまで続けているんですか？』と。

江藤　日常的なトラブル対応のために、UOMの仕組みは便利だと感じてます。ただ、ソフトウェアであるLoadStarと違って、『システムを繋げることができない』という制約のために、SaaSであるUOMを受け入れられるほど、自動化が進んでいない会社がまだまだ多いのかもしれません。

LoadStar Conductorについて

福原　ところで、LoadStar Conductorって、何か面白い話になりそうなんですか？障害検知からインシデントのチケット起票まで、いろいろな監視オペレーションを一元管理できるということですが。

統合監視・インシデント対応ツール「LoadStar Conductor」 | Zabbix Enterprise
https://enterprise.zabbix.co.jp/solutions/9966

江藤　今はまだ詳しくご説明できるだけの材料がないんですが、10月頃からいろいろご紹介できると思います。かなり、機能が強化されています。アラートを俯瞰的に見られるメリットを初め、ワークフローを取り込んでインシデントを管理したり、システムごとに画面もカスタマイズできたり。

吉田　7月に横浜でセミナーを開催した時も、どうやってプリセットを管理したり、ナレッジを溜めていくかに興味を持たれている人がとても多くいらっしゃいました。LoadStar Conductorは、上がったインシデントに対する初動のオペレーションの手順が、簡単で分かりやすいと好評でした。アラートから紐付く手順書が自動的に示されると、マニュアルを探す手間も減らせて、現場の人の負担は減らせます。

江藤　UOMの「自動オペレーション」機能ほど割り切ってはいなくて、人が介在する余地を残しています。マニュアルの所在を登録しておくだけでも、同じホストやアラート種別で一覧が表示されるので、そこにメリットを感じていただける方も多いようです。ぜひ、楽しみにお待ちください！