さくらのレンタルサーバのコンパネリニューアルにおけるディレクション業務

はじめに：編集部より

この記事は、2021年5月18日(火)に行われた「さくらの夕べオンライン レンタルサーバーナイト ～コントロールパネルのリニューアルはいかにして実現したか～」における発表を記事化したものです。さくらのレンタルサーバのコントロールパネル(社内では「コンパネ」と呼ばれています)をリニューアルするにあたり、プロジェクトの進行管理に携わった者の立場から、気づいたことを発表しました。

自己紹介と発表概要

谷口と申します。2016年に入社しまして、さくらでは割と新しい方です。もともとウェブディレクターをずっと20年ぐらいやってまして、事業会社とか制作会社で勤務しておりました。さくらインターネットではレンタルサーバ/ドメイン/SSL/CDNのサービス企画やディレクションを担当しているのと、ライター業も兼業しております。

本日のお品書きなんですけれども、コンパネリニューアルの歴史、コンパネという特殊な戦場に関する小ネタから、ディレクションで気をつけたポイント、それから今回のはちょっと珍しい案件なので、新旧コンパネの二重運用についてのメリットデメリットなどをご紹介させていただきたいと思います。

コンパネリニューアルの歴史

まずコンパネリニューアルの歴史です。2004年から稼動していた旧コンパネがありました。これWQHDの画面だと、こんなに余白が大きくなってしまいます。

そこで、2018年に新コンパネのベータ版っていうのをリリースしました。新旧の並行稼動を約2年ぐらい行った後、2021年の3月に旧コンパネをクローズしました。

クローズの半年前からは、強制的に新コンパネにリダイレクトするっていう対応を開始していて、クローズ時は問い合わせとかも多くなるだろうということで万全の体制で臨んでいたんですけれども、思っていたほど問い合わせが来ず、比較的無事に移行して、約15年にわたる旧コンパネの歴史に幕を閉じました。

コンパネと普通のWebサイトの違い

今回紹介するコンパネの話は、Webサイトとしてはちょっと特殊な例になりそうです。何が特殊かっていうことで、レンサバコンパネと普通のWebサイトの違いをちょっと挙げてみました。

テンプレートが異常に多い

まずテンプレートの数がアホみたいに多くてですね、普通のWebサイトでは1個のカテゴリーでテンプレートが10個あったら多いなあ、みたいになると思うんですけども、コンパネにはテンプレートが150ぐらいあります。

ターゲットとペルソナが想定しづらい

次に、ターゲットとペルソナが想定しづらいです。要はですね、個人の方から、飲食店とかやられている個人事業主の方から、Webで普通にビジネスをされている方から、普通の会社でコーポレートサイトの運用してる方まで、みたいな感じでユーザがいて、もうターゲットとかペルソナの想定が本当にしづらいサイトになっています。

歴史が長すぎて増築の繰り返し

さらに、歴史が長すぎて、元のコンパネ自体が機能追加のために違う人による増築を繰り返しています。それが15年続いているので、かなり年季の入ったWebサイトになっているという感じです。

なかなかちょっと、そんなサイト、他には思いつかないです…。

他社のコンパネはどうなっているか

参考までに他社のコンパネがどうなってるかっていうとですね、AWSとかはあまり深く考えてないのかなっていう感じでラジオボタンがバーッと並んだりしていますし、GCPとかは結構考えて作られているような気がします。

それから、割と小規模なレンサバ業者さんの場合は、独自コンパネを作ると開発が大変というのもあるんで、cPanelやPleskを利用されているところが多いかなと思います。ライセンス料がかかるんで、うちみたいに大手だとちょっと原価が高くなってしまって厳しいなっていう感じですね。なので、ペパボさんとかエックスサーバーさんとかConoHa WINGさんは自社でコンパネを提供されていて、それぞれ使いやすいとか使えないみたいな感じの評判が流れているのを日々Twitterで監視しています。

リニューアルにおけるディレクションのポイント

そんなレンサバコンパネのリニューアルにおけるディレクションのポイントということで、ディレクター視点でお話しさせていただければと思います。

稼働年数＝問題の量＝要件の量

まず、15年の稼働年数っていうのは、つまり問題の量でもあって、それが要件の量になるということですね。現行デザインの稼働年数が増えるほど、問題とか要望がどんどん増えていくと。デザイン以外にも、なにせ2004年からやってるんで、レガシーなテクノロジーがそのまま利用されていたりとか、今後ちょっとセキュリティの問題が出てきそうという不安もあります。

そういった問題とか要望とか不満の量っていうのが、すなわちリニューアルのときの要件の量というところに直結するわけですね。積年の悩み的なものも多くあって、要件がてんこ盛りになってあふれちゃってるっていう状態になっておりました。

積み重なる欲望

僕もディレクター視点でコンパネを見ると、無駄なページもたくさんあるし、統一したかったり、逆に「これが1個のページなのはどうなの？」という、分解したかったみたいなこともあります。

それで、都度UXを検討したり、ユーザーインタビューしたり、社内各所に「ここを変えていいですか？」みたいな確認をしていくとですね、まず要件の検討過程でもうすでに要件が積み重なって地獄、みたいな状態になっています。

改善＝正義になりがち

ここで問題なのは、「使いづらい部分があるんだから改善しようよ」っていう意見と、「ちょっとリソース足りないんでPhase2でいいですか？」っていう意見があると、どう考えても前者の方が圧倒的に正しいわけですね。悪いところがあったら直さなきゃいけないっていうのは当たり前で、リソースが足りないっていうのは正義に押しつぶされてしまういうケースがよくあります。

でもリソースを確認してみると…

しかし、ちょっとここで担当メンバーの人数を確認してみましょう。

ディレクター1人。これ私です。デザイナー1人。「1人かよ！」って思ったかもしれないけど1人でした。そして実装するエンジニアが3〜4人。そこそこいそうだなって思うかもしれませんが、新コンパネにはバックエンドのAPIがないので開発し直したっていうのもあるんで、決してすごく多い人数ではありません。しかも全員、他の仕事と兼務。シンプルに人が足りない状態でございました。

理想としては、各ページのUXを検討して、必要に応じて機能追加もやりたいし、各画面のユーザビリティのテストもやりたいし、使いづらくてお問い合わせの量が増えていたりする部分もあったので、そういうところを改善したいというのもありますし、できればユーザビリティのコンサルとかも入れたいなっていう欲望もあったりしました。

そこで、もし外注したらどれぐらいかかるのかな？と思って、見積もってみました。だいたい100枚ぐらいテンプレートがあって、いろんなターゲットを想定して、ユーザビリティテストをやって、全体のデザインディレクションと各ページのデザイン費を考えると、800万〜1000万円いっちゃうんじゃないかな、みたいな話になりました。うちにそんな予算はないので、シンプルに金も足りないと。

そういう状態なので、社内でやらなければいけないということになりました。

野心的すぎるプロジェクトは失敗確率が高い！

ディレクターメインで20年ぐらいIT業界で働いている私なんですけれども、「野心的すぎるプロジェクトは失敗確率が高い！」というのが、なんとなく知見というか、僕自身がいろんなプロジェクトに関わってそういうことを経験していたっていうのがあります。「野心的って何なんですか？」っていう話なんですけれども、あれもこれも要望を全部実現したい！とか、要件は決まってないんだけど締め切りは10月31日ですとか、できるだけ低コストで！とかです。
確かにそれができれば、それに越したことはないですけれども、どうしても達成するのに労働時間が必要だったりとかするので、そういった野心的な案件は、現実的に達成できそうな技術とか予算とか要件を大きく逸脱した状態というのを怪しむべきと思っています。

いつまでも終わらぬ工事を避けるために

そういった要件を盛られちゃうと、いつまでも工事が終わらないことになっちゃうんですね。幸い、さくらのレンタルサーバは自社サービスなので、何月何日までに絶対やらなきゃいけないっていうことはあまりないんですけれども、だからと言って要件を盛られて人手が増えないと開発期間の肥大を招き、ダラダラやっていていいのかということになるので、やっぱり要件の整理が必要ですねっていうのは最初に実感をしておりました。

さらに、要件って最初に整理しても、絶対に後から増えるんですね。なので、ある程度は仕方ないんですけれども、増やさない覚悟っていうのも必要だったかなと思っています。

要件の整理

実際、今回の案件でも何をやろうかって整理したんですけれども、まず使ってるテクノロジー的なもの(例えばPHPのフレームワーク)とかUIの近代化を最優先しました。機能追加とか画面構成の変更は、やりたいところはたくさんあるんですけれども、がまんして、今回はナシにさせてほしいですということにしました。それから、検証の過程で「これやばいな」っていうのもやっぱり出てくるんですけれども、緊急性の低いものは二次開発とさせていただきました。

社内からはいろいろ要望などもいただいたりしましたが、ご理解ご協力いただいた関係者に感謝をさせていただきたいです。「『やりたいこと』を『できる』に変える」という社是に従って、いろいろやらせていただいて本当にありがとうございました。

…と思ってはいるんですけれども、こうして要件を整理して臨んだにもかかわらず、それでもやっぱりXDファイルがマントラ化してですね、デザイナーの方には大変な苦労をかけました。ありがとうございました。

ベータ版の公開とその後

こうしてベータ版の公開を迎えました。なんか僕が入社する前に2度失敗したって言われてたんですけれども、3度目の正直でやっとリリースができたという感じになっております。

ベータ版リリースのときに見送った機能は後からどんどん実装されていきました。WordPressのインストール改善とかデータベース作成機能とかです。去年(2020年)には、ついに「新機能の新コンパネのみ実装」、それまでは新機能を追加するときに新と旧の両方に実装してたんですけど、初めて新コンパネだけに実装するという事例として、「コンテンツブースト」というCDN連携機能のリリースができました。

そして2021年、ついに旧コンパネがクローズを迎えて、その移行の際も先ほどお話ししたんですけども、あまり大きなトラブルなく迎えることができて良かったかなというふうに思っています。

並行稼動のメリット・デメリット

今回の案件は、2018年から3年ぐらい、旧と新を両方、並行稼動させてたっていう珍しい案件なんですけども、実際にやってみた感想みたいなのをシェアさせていただきたいと思います。

並行稼動のメリット

まず並行稼動のメリットですね。一番大きいのは、新コンパネが動かないことがあっても、旧コンパネで操作できます。これがめちゃくちゃ大きいですよね。

次に、今回は人が足りないとかいろいろリソースの問題もあって、最低限の機能でリリースしたんですけれども、それもこれも全部、旧コンパネがあるからリリースできたっていうのはあります。

あとは、お客様目線で見ると、お試しで使ってみて、ちょっとまだ無理そうだからいいやとか、クライアントに渡しているマニュアルをコンパネのキャプチャーを取って作っていただいてる方が大勢いらっしゃるんですけれども、そのマニュアルの更新がゆっくりできるっていうメリットがあったりします。

並行稼動のデメリット

一方、コンパネ並行稼動のデメリットっていうところなんですけれども、まず新旧両方のコンパネをサポートする必要があるのが結構デメリットとして大きいですね。お客さんから「なんかメールのこの画面おかしいんですけど」みたいな問い合わせがあったときに、新旧コンパネのどっちを使ってるんですかっていうヒアリングをするだけでメール1往復かかっちゃうんで、それだけコストが増えていきます。だいたい月間25万ユーザーぐらいいて、その中からお問い合わせが結構な数くるので、その方々に対して1往復ずつ増えてしまったら、ものすごい量のコストになってしまいます。さらに、サポートするメンバーも両方の使い方に習熟しておく必要があるので、結構苦労をかけてしまったなというふうに思っています。

あとはですね、開発側のデメリットなんですけれども、一番でかいのが、機能の追加とか改修をするときに、対応範囲が倍になっちゃうんですね。なので、何かあって文言を追加しないとダメですねみたいなときに、結構どっちか忘れてたりとかあったりするんで、もしかしたら倍以上の手間になってるかもしれないですね。両方考慮しなきゃいけないんで、対応の工数がちょっとかかってしまいます。

あとはインフラのメンテナンスとかっていうのも、今回結構な範囲で改修というか新しく作っているので、メンテナンス範囲が増えたり、コンパネでエラーが出たらアラートが上がるようになってるんですけども、そのアラートの設定も倍になっちゃうんで、そういった感じでメンテナンスの範囲も増えてしまいます。

こんな感じで、並行稼動って、お客さん的には移行がゆっくりになるんですごいメリットがあるんですけれども、管理する側としては結構デメリットも無視できないぐらいありました。

リソースが潤沢であれば長期の並行稼動はおすすめしない

やってみて思ったのは、お金とリソースが潤沢にあれば、最初からめちゃくちゃ完成度の高いものをリリースして、長期にわたる並行稼動っていうのをできるだけ避ける(例えば万が一のために1ヶ月だけ動かしておくとか)、年単位での並行稼動っていうのはあまりしない方がいいのではないかなと思います。でもその一方で、最低限のリニューアルでリリースできるという利点はあるので、そこは天秤にかけてご判断いただくといいかなというふうに思いました。

ご意見ご要望はフィードバックボタンで

今はもうすでに新しいコンパネしか使えなくなっているんですけれども、ご意見ご要望がございましたら、左下の方にフィードバックというボタンがあって、Microsoft Formsを使った簡易なものなんですけれども、こちらからご意見ご要望をお送りください。日々我々チェックしておりますので、対応をしていきたいというふうに思っております。

ということで、私の方からの発表を以上とさせていただきます。ありがとうございました。