こんにちは！スパイラル株式会社PF戦略企画室やまざきです。

今回は「調べてみた」というより「確かめに行った」に近い話です。

SPIRAL® ver.1（以下V1）の後継となる弊社の新製品、SPIRAL PLUS（以下PLUS）、9月1日に情報が解禁されました。申し込み開始は10月1日からです。ターゲットはSIerの皆さん。でも、その準備を進めながらふと思ったんです。

うちのWebサイトや営業資料は、エンジニアの悩みに向けて言葉を選んで作っています。でも、その言葉、本当にエンジニアの人たちの実感と合っているんだろうか。「安心を標準装備」とか「漏れない・止まらない」とか、こっちが「刺さるはず」と思って選んだキーワードが、独りよがりになっていないか。それを確かめたくて、アンケートを実施することにしました。

集め方も、結構泥臭くやりました。

• 取引のないSIer企業に直接電話をかけて、協力をお願いした（もともと取引のあるパートナーには、SIerの企業自体があまり多くなかったため）
• 社内で毎日SPIRAL®の開発案件を担当しているSEのメンバーに、ヒアリングを行った
• 既存のSDPパートナーの皆さんに、アンケートへの回答をお願いした

実はこの電話、学生インターンの皆さんにお願いしました。知らない会社にいきなり電話をかけるのって、大人でも腰が引けるものだと思うんですが、みんなどんどん的確に電話をかけて、ヒアリングまでしっかりやってくれたんです。集まったデータの整理・分析まできっちりやってくれました。

こうして集まった声をもとに、Webサイトや営業資料の言葉をブラッシュアップしていった、というのが今回のアンケートの背景です。次からは、実際に出てきた声のなかで気になったものを確かめていきます。

セキュリティってニーズあるの？

「今一番の課題は？」という質問で一番多かった答えが、「機密データ基盤」でした。次点が「セキュリティ不安」。この2つだけで、回答全体の4割を占めています。

PLUSの営業資料には「金融・官公庁レベルの強固なセキュリティ」と書いてあります。エンジニアが抱えるセキュリティや機密データ基盤に対する不安を払拭できるものなのか、確かめに行くことにしました。話を聞いたのは、当社でソリューション開発を担当している武藤さんです。日々SPIRAL関連の開発案件に対応しているエンジニアです。

サーバーの冗長化や可用性の担保、個人情報を扱える基盤を一から作るのは、エンジニアにとってかなりの負担なんだそうです。24時間365日のサーバー保守やセキュリティ対策込みの構成を自前で検討するのは大変で、特に顧客に納品するような、個人情報を含むシステムほどその負担は重くなる、と話していました。

つまり、営業資料に並べているWAFやISMS準拠といった項目は、”あれば嬉しい機能一覧”ではなく、”エンジニアが自前で背負うと大変な部分を代わりに引き受けている”という話だったわけです。資料の言葉を鵜呑みにするのではなく、実際に苦労した人の言葉で裏付けが取れたのは大きいです。

見積もり後にコストが読めなくなる問題

セキュリティの次に気になったのが、お金の話です。

アンケートでコスト面の悩みを聞いたところ、「想定外の追加コストがあった」が31件、「見積もり提案の際に説明しにくい」が27件と、この2つがかなり上位に来ていました。

聞いてみると、V1でパートナー様が開発する際は「まず基本ラインで契約して、必要になったらオプションを申し込む」というケースが多く、これが「あとから発覚するコスト」の原因になりやすかったそうです。

例えば、V1のAPIリクエスト数は標準だと10回/分までで、600回/分まで使いたい場合は月5,000円のオプション料金がかかりました。独自ドメインも、本格的に対応するには「専用Webサービス」という初期40万円〜のオプションが必要でした。

PLUSの価格表を見比べてみると、この「あとから申し込みが必要になる」範囲がぐっと狭くなっています。APIリクエスト数は600回/分が最初から標準（V1では有料オプションだった水準）。独自ドメインも標準実装です。ほかにも、フィールド数の拡張（300フィールド）、ファイル型フィールドの格納容量（100MiB）、カスタムプログラムの上限（20件）、カスタムモジュールの上限（1,000件）、PDF帳票（20件設定）、郵便番号住所自動補完など、V1では課金対象だったラインが、PLUSでは最初から標準に含まれています。

トランザクションDBも、この一つです。V1では、契約レコード数までは無料で使えるものの、それを超えると「月間トランザクション数超過費用」として1件あたり0.5円の追加費用が発生していました。PLUSではこの超過費用がなくなり、自由に使えるようになっています。

トランザクションDBとは？

トランザクションDBは、登録データをトランザクションデータとして受け付け、通常DBに格納しているマスタデータに最適に反映することができるデータベースです。サポートサイトに載っていた例が分かりやすかったので、そのまま紹介します。

セミナーの申込受付をトランザクションDBで作ると、申込データが1件入るたびに、①申込者リストへの登録と、②セミナーの残席数を1つ減らす処理が、セットで自動的に実行されます。残席が0になったら、そのセミナーは一覧ページから自動的に非表示になる、という仕組みです。もし①だけ成功して②が失敗したら、残席数の管理が狂って、定員を超えて受け付けてしまうかもしれません。トランザクションDBは、こういう「一連の処理をセットで確実に行う」ことを保証してくれる機能です。

しかも、トランザクションDBに記録されたデータは変更・削除ができない仕組みになっているので、「いつ、何がどう変わったか」という証跡が自動的に残ります。何かトラブルが起きたときの原因調査や、あとから説明を求められたときの裏付けにも使えるということです。

こうした整合性の担保は、人やモノなどの基本情報（マスタデータ）と、申込やキャンセルといった行動の記録（トランザクションデータ）を分けて管理することで活きてきます。要件がどんどん複雑になっている今、この「データの整合性を保つ」という部分は、他のサービスにはあまりない強みだと開発チームは話していました。

つまり、運用を始めた後にデータ通信量などで想定外のコストが発生するリスクは、正直まだ残っています（これは別の話として引き続き注意が必要です）。ただ、開発している間に想定外のコストが発生して、納期やクライアントとの調整に響くリスクについては、最初から最低限に抑えられている、というのがエンジニア目線で見た実際のところでした。

V1になかった「スペック」、聞いてみた

武藤さんへのインタビューでは、もう一つ気になる指摘がありました。V1の非機能要件（セキュリティ設定や運用ルールなど）は、ある程度フォーマット化して他の案件にも使い回せるものの、顧客ごとに細かくカスタマイズしたい場合には、そのフォーマットでは対応しきれないことがある、という話です。

「何かいい解決方法はないのか」と気になったので、実際にPLUSを作っている開発チームに直接聞きに行くことにしました。

聞いてみると、V1の料金は「レコード（登録データ数）」＋オプションという組み立てだったのに対し、PLUSは「レコード」「通信量」「スペック」という3つの軸で決まる仕組みに変わったそうです。V1にはもともとレコードの概念しかなく、「通信量」も「スペック」も、PLUSになって新しく増えた考え方でした。

「スペック」とは、APIの拡張、分間リクエスト数、Webリクエスト数の拡張など、いわば「システムがどれだけ頑張れるか」を決める部分です。象徴的なのが、APIリクエスト数のデフォルト値が10から600に上がったという話。エンジニアが実際にAPIを「使う前提」で最初から設計を見直した結果、とのことでした。ベースがIaaS（クラウドの土台）になっているので、大規模なキャンペーンでアクセスが集中するようなケースでも、アカウントごとにスペックを引き上げてカスタマイズすれば耐えられる、という話も聞けました。

冒頭で聞いた「顧客ごとのカスタマイズがしづらい」という悩みに対しても、専用Webサービスという形でアカウントごとに性能の高いWebサーバーを用意できる選択肢があり、これも「スペック」的な発想の延長にあるものでした。

つまり、「みんな同じ環境で我慢してください」ではなく、要件が特殊な顧客案件やアクセスが跳ねる案件には、スペックという軸で個別に強くする道が用意されている、ということです。フォーマット化された標準機能では対応しきれない案件がある、という武藤さんの指摘に対して、ちゃんと逃げ道が用意されていたのは安心材料でした。

デプロイのやり方、開発チームに直接聞いてみた

武藤さんへのインタビューで、もう一つ引っかかっていたことがありました。「標準機能を使うほど、仕様変更のときの”切り戻し”コストが増える」という指摘です。開発チームに、実際どういうことなのか聞いてみました。

PLUSには、開発・ステージング・本番の3つの環境が標準で用意されています。本番環境で動いているアプリの仕様を、そのままステージング環境にコピーすることがすぐにできる仕組みになっているそうで、最新の本番仕様をステージング環境に反映した上で、そこからすぐに改修に着手できる、というのが実際のメリットでした。

それでも「組み替え自体が嫌」という人には

さらに聞くと、そもそもパーツの組み換え自体が嫌だ、というエンジニアには別の選択肢もあるそうです。アプリ本体はAWS上で独自に（スクラッチで）作ってしまって、PLUSはデータベースとしてAPI経由で使う、という組み合わせです。スクラッチ開発に魅力を感じつつも、データベースや個人情報の管理までは自前でやりたくない、というエンジニアには、これが一番手っ取り早いとのことでした。

「スクラッチは好きだけど、個人情報は預けたい」を叶える選択肢がある

これ、記事の最初のほうで見た「機密データ基盤」への不安（アンケートで最優先課題の1位でした）にも直接効いてきそうな話です。開発の自由度は自分たちで持ちつつ、一番不安な部分だけプラットフォームに預ける、という選び方ができるわけです。

まとめ

ここまで、セキュリティ・お金・カスタマイズ・デプロイと、アンケートで出てきた悩みを一つずつ確かめてきました。

アンケートで浮かび上がった悩み（機密データ基盤・セキュリティ不安・コストの見通しにくさ・カスタマイズ性）は、営業資料やWebサイトが訴求しているポイントと、かなり重なっていました。つまり、エンジニアが実際に困っていることに対して、ちゃんと言葉を当てられていた、ということだと思います。

そのうえで、現場のエンジニアや開発チームに直接確認したからこそ見えてきたものもあります。武藤さんの実体験のおかげで、セキュリティ面の価値には具体的な裏付けが取れましたし、通信量まわりのように、お客様に安心して使っていただけるような伝え方や、利用イメージを持ってもらえる仕組みづくりは、私たち自身がこれから育てていかなければいけない部分だということも分かりました。

営業資料やWebサイトの言葉は、伝えたい価値の核をちゃんと捉えられていた、というのが今回の結論です。そのうえで、実際の現場でどう活きるのか、これからも現場目線で確かめ続けていきたいと思います。

引き続き、これから育っていく部分は「やまざき調べ」で追いかけていきます。今回も読んでいただき、ありがとうございました！

こちらも読んでみてください！

SPIRAL PLUSを先行体験してみた【やまざき調べ・改vol.3】
その他、過去の記事のアーカイブはこちら→やまざき調べ・改