丸投げ、ダメ、ゼッタイ！
中小企業のアプリ運用あるあるとそれを解決する方法

「物流で未来を」清長の物流代行サービス

——御社の事業やチーム、役割について教えてください。

戸田氏　弊社は一言でいうと物流代行会社です。特にECに関わる物流代行の会社で、ECに関わる商品を入荷して倉庫でお預かりし、管理して、それを注文があれば発送するという一連の流れをお客様に代わって行う会社です。

「ロジプレミアム」と「ロジモプロ」という2つの物流代行サービスがあります。

ロジプレミアムは、発送量や保管量が定常的に多いが故に与信が必要なお客様向けのサービスです。

一方、ロジモプロは、いわゆるひとりECと呼ばれるような個人のお客様も使えるサービスです。既存の物流代行業者が請け負えない、発送量に波があるけど対応してほしいというお客様が実はたくさんいます。サービスの歴史は長く、昔から多くの中小企業のお客様にもご利用いただいています。最近だとクラファンの運営者が利用するケースも増えています。

私はそのロジモプロ専任のシステム担当です。お客様はWebサイトでユーザー登録してサービスを利用するので、そのWebアプリケーションの開発と運用を担当しています。

チームはなく今は私ひとりです。その前は誰もいなかったので外注丸投げという状態でした。私が入社したのは2年前で、私の役割は、その外注丸投げによって発生していたいろいろな問題をクリアすることです。そのためには何でもやります。

——前職は何をされていたのですか？

戸田氏　フリーランスや正社員としてECの開発・運用エンジニアをやっていました。キャリアとしては5年以上EC系で、それ以外にもメディアサイト、SNS、ERP、アンケートシステムなどを扱ってきました。

——外注丸投げ問題について詳しく教えてください。

戸田氏　これは中小企業のアプリ運用あるあるでもあります。

1. 開発できる人はいないけど、ITで何か新しいことをやりたい。
2. 少ない予算で開発はもちろん運用も外注する。
3. 鳴かず飛ばずでサービス終了。これが1つ目の山です。
4. ユーザーを獲得できれば、サービスが軌道に乗ります。
5. システム障害が発生して運用コストが膨れ上がる。これが2つ目の山です。
6. コスト削減を目的に内製化を目指してエンジニアを採用する。

私がやらなくてはいけないことはこの2つ目の山を越えることです。

私が入る4,5年前の話ですが、弊社の場合、開発は人件費の安い海外の企業に委託していました。いわゆるオフショア開発です。もちろん、その後の運用もそこを頼るしかありません。社内には技術に明るい人がいないためです。

弊社の場合、事態を余計にややこしくしているのが、その後その会社が事業を畳み、また別の会社に運用を委託した経緯がある点です。

ちなみに、監視ツールを提供する御社は知っておいた方がいいと思うのですが、アプリの運用がはじめてのすべての中小企業は、サービスをリリースした段階で「システムを監視した方がいい」なんて微塵も考えられていません。必要性に気づいていないので。システム障害を経験した後ですら、テストをもっと事前にすればいいだけと思っています。テストをどれだけしても大勢のユーザーの動きを完璧に予測したテストは不可能だから監視が重要なわけですが、「ユーザーから直接この機能がほしいという指摘が入れば対応して、テストして、リリースすればそれでいい」としか思っていません。

——大変勉強になります。

戸田氏　こういった背景もあり、ほとんどのサービスがユーザーニーズに刺さる前に消えていくわけですが、弊社は幸い軌道に乗りました。軌道に乗るということは多くのユーザーがアプリを触るということなのでそこでメッキが剥がれます。ユーザーや社内のオペレーターから指摘されるかたちでサービスリリース当初からの初期不良があぶり出されていきます。ユーザーが増えれば障害も発生しやすくなります。

こうなると、新しい機能の開発と並行して、障害対応や再発防止策もしていかないといけません。それもすべて外注先に依頼するわけです。その外注先が開発したアプリの問題なら無料で対応してもらえることもありますが、弊社の場合はそうではないので依頼するたびにお金がかかります。

その上、システムの内部が見えていない、ソースコードの管理もできていないという状況でした。そのため、新たに不具合が発生しても、今の外注先が担当した新規開発が原因なのか、リリース当初のシステムが原因なのか全然わからない。そこに、「事前にユーザーニーズを読んで要件定義できなかったのか」という弊社側の責任論も出てきます。

そのような状況の中で、保守費用として毎月支払っているものに加えて不具合改修費用がオンされる。こうなるともう我々のような中小企業はすぐに首が回らなくなります。

——苦労の多い現場を容易に想像できました。

戸田氏　このような背景があって弊社もコスト削減を目的に内製化を目指したというわけです。エンジニアの採用を始めます。私が入ったのはそのタイミングです。

しかし、当然ですが簡単ではありません。それには理由があって、これを私は声を大にして言いたいのでこの場を借りて言わせていただきます。

中小企業にマッチする情報がない！

何千万、何億という資金調達に成功しているスタートアップ企業や潤沢な予算を持っている大手企業にマッチする情報はすぐに見つかります。ところが、予算の少ない中小企業にマッチする情報はまったくといっていいほどありません。

弊社はたまたま何とかなっていますが、中小企業向けに

1. このあるある話
2. 採用すべきエンジニア像
3. そのエンジニアが取るべき具体策

といった情報が出回っていればもっとみんな対策しやすくなると思います。エンジニアなら特に知りたいのは具体策だと思います。

ここまでが、ここでいう中小企業のアプリ運用あるあるです。

——これは中小企業必聴ですね。それを解決するためにどんなエンジニアを採用すればいいのでしょうか？

戸田氏　一言でいうと、「複数人や大勢のユーザーを意識して開発してきたエンジニア」です。

具体的にいうと、例えば、自社開発のto CのECサイト運用時に深夜の2時とか3時にテレビCMを打たれて死にそうになるといった経験をしてきた人です。リリースした瞬間にたった1つの不具合でサービス全体が落ちて冷や汗かきながら対応したという経験です。

私の場合、そういう経験をしてきているので「リリースしました。運用は別の人に任せます」とは絶対に言えません。使われ始めた瞬間に局所的にまずい結果が出る機能があったりするものなので、監視のグラフを見ながらCMに備えたりリリースしたりします。

あと、全体的にトラフィックが多い時にリソースを増やすということだけではなく、色々な使い方をするユーザーがいて、その中の特定のユーザーがサーバーリソースをすごく消費する使い方をするといったこともあります。こういった事実を掴んでシステム構成を調整する必要もあります。

ですので、開発要求を何でも聞けるというより、それは大前提として、使い方や使う目的が違う複数人のユーザーがいることをイメージできる人や突発的なリソース変動があった時にその調整ができる人がいいわけです。

——なるほど。

戸田氏　もっと言うと、採用すべきは「近い将来プロダクトマネジメントができる開発エンジニア」です。

ただ、重要なことは、今それができるかできないとかではなく、そもそもの姿勢として、サービスの円滑な運用や成長自体に興味を持っているかです。例えば、不具合が発生したときに犯人探しに躍起になる人ではなく、一旦、全部自分で責任を負ってシンプルにことを進めて問題の解決にいち早く向かえる人である必要があります。

今あるスキルより、そういう状況を理解する姿勢や覚悟の有無の方が重要です。

「お客さんに言われたことを開発しただけです」といった受託マインドの人はダメ。「社内システムの開発をしてきました」という人も他人に言われてはじめて対応する人が多いのでダメです。「技術力はあるので何でも作れます」だけでもダメ。

ITは事業に貢献する必要があり、社内外には様々なステークホルダーがいます。それらを踏まえて「我々エンジニアはなぜここにいるのですか？」という問いにまで深く向き合ってきた人を採用したい。

いろいろ難しいことを言いましたが、それを採用時に見分けるポイントが、「この人はどれだけ修羅場を経験してきた人なのか」です。

——説得力が半端ないです。そんなエンジニアがまずとるべき具体策も教えてください。

戸田氏　そんなエンジニアからしたら当たり前のことですが、整理すると4つです。

1. 案件管理

まず、案件管理。関係各所からの要求や発生している障害などのインシデントをリスト化して案件化します。ビジネスサイドから上がる機能要件だけではなくて、障害の再発防止やパフォーマンス改善などの非機能要件も同じ土俵に並べて優先順位をつけていくのがポイントです。

2. パフォーマンスの見える化

次が、パフォーマンスの見える化です。監視ですね。普段見えない細かい障害やパフォーマンスの劣化が大きな障害につながるのでサーバーやアプリケーションのパフォーマンスの監視は重要です。「なんかアプリが遅い」みたいな、ふわっとした話だけ言われても改善のしようがありません。例えば、ある1つのユーザーの特定の操作のタイミングだけアプリの処理が遅いなど、データに基づいた事実情報があってはじめて設計の定石に基づいた具体的な改善案を出せます。もちろん、監視の目的はパフォーマンスの改善だけではなく、サービスダウンといった大きな障害を未然に防ぐためでもあります。

3. 開発と改善

そして、アプリの作りを理解しながら、ビジネス部門が要求する新機能の開発はもちろん、パフォーマンスの改善もしていきます。私はこれまで外注していたこれらをすべて巻き取っているので、自分の給料分くらいの成果はもう出せたと思っています。

4. 協力会社への委託の再開

これら全部を管理できるようになって初めてプロダクトマネジメントもできるようになるので、改めて外部の協力会社を探し、委託を開始します。弊社は今まさにこれに着手し始めたところです。委託する際のゴールや仕様を明確にし、事業がわかっているエンジニアと技術がわかっているエンジニアを使い分けるのがポイントと考えています。

——案件管理はどうやっているのでしょうか？

戸田氏　実際に私が使っているのはkintoneとGoogle Workspace、Slack、GitHubです。SlackとGitHubは無料の範囲で活用しています。

監視ツールからのアプリやサーバーの異常値の通知をSlackで受けて、必要に応じてkintoneにインシデントとして記録します。

GitHubを経由してAWSに修正したコードをリリースして、Google Workspaceにサーバーやアプリの構成のドキュメントを残し、リリースによってドキュメントの修正が必要であれば対応します。

1人エンジニアでもこれをする理由は、変更の経緯も含めて残しておくことで今後協力していただけるエンジニアにどのような歴史的変遷を経てこのようなシステム構成になったのかを説明できるからです。

——パフォーマンスの見える化は？

戸田氏　少し前までDatadogを使っていたのですが、今はSite24x7を使っています。やっていることは主に3つです。この3つは必要最低限の基本中の基本と考えています。

1. URL外形監視

一つ目は、URL外形監視です。ユーザー視点の監視をすることで、万が一のサイトダウンもユーザーより早く把握できるようになります。

2. RUM

二つ目は、RUM（リアルユーザーモニタリング）です。実際のユーザーが体感しているブラウザの応答時間の監視です。私が目指したのはまず2000ミリ秒です。

ちなみに、API監視でAPIの処理速度も見ています。こちらはまず1000ミリ秒を目指しました。

RUMもAPI監視も、この目標ではまだまだ遅すぎるのですが、まずは異常に遅い箇所から潰していく必要があるためこのくらいから始めます。これをクリアしたら最終的にはさらにその半分を目指します。

社内システムの感覚で開発しているエンジニアのアプリは、開発環境で快適に動作していたとしても、本番環境の大量のデータがある場所で動くことを想定できていないことが多いためRUMで見ると2000ミリ秒を超えることが少なくありません。

そういった箇所を見つけてはソースコードを見直してパフォーマンスを改善するという作業を繰り返します。これに関連してAPM（アプリケーションパフォーマンス管理）機能も私は使っています。

3. サーバー監視

三つ目が、サーバーのダウンとリソースの監視です。リソースと言っているのはCPU、メモリ、ディスクの使用率です。しきい値をあててそれを超えた時とダウンした時に通知を受け取るようにしています。しきい値はいずれも「60%で注意、90%で警告」としています。サーバーが1台死んでも、2台目以降が玉突きで死なないようにするにはこのぐらいというのが基準です。

実は私が入社した直後のまだ何も引き継ぎができていない時期にサービスがダウンしたことがありました。その時は「ログが溢れてディスク使用率が100%を超えていた」と外注先から報告があったのですが、こういうことを未然に防止していきます。

——ツールを途中で替えた背景を教えてください。

戸田氏　先ほど話した通り、スタートアップ向けの情報はたくさんあります。そこで一番聞くのがDatadogです。それを知ってこれはよさそうだなと、他に選択肢もあまりなかったので、入社して少し経った頃に会社に申請して導入しました。

それから一年経たない内に、たまたまAPM機能の利用料金が値上がりしました。このままいくと月1万円も予算オーバーになるので「それはマズい」と替わりになるツールを必死になって探しました。

物流企業は特にコストに敏感です。業界的に2024年問題や大手の物流会社も発送料を上げるという話がある中で「システム運用費上げてもらえませんか？」とはとても言えません。

そこに出てきたのがSite24x7です。替える前と同じことを予算内でできているので助かっています。

それから、Site24x7が中小企業にマッチする一番のポイントが従量課金制ではないという点です。

中小企業はどこも弊社と同じようにコストに敏感だと思います。担当者は皆、ある月に突然請求金額が高くなる可能性のあるツールは怖いため避けたいと考えます。

ましてや、熟知する前の初めてのツールの導入です。従量課金制だと何が起こるか読み切れません。ちょっと試しに使ってみたら追加費用が発生していたということもあるのでうかつには試せないという心境になっています。

その点、Site24x7は安心です。画面上で設定できる機能は追加費用の対象ではないわけなので、いろいろな機能を試すこともできます。

——ありがとうございます。最後に読者の皆様に一言お願いします。

戸田氏　丸投げ、ダメ、ゼッタイ！これですね。