こんにちは! HR本部の高田です。
今回は、SRE総合支援サービス「Sreake(スリーク)」のPM、セールス、マーケターの異職種メンバーによる座談会の後編をお届けします。
前編で無事(?)、SREの基本を理解していただけたかなと思いますが、もっともっとSREやSreakeについて知ってもらいたい!というわけで。後編では、SIerやITコンサルティングとの違いや、Sreakeの今後の展開についてお話いただきました。
*前編はこちらです
<座談会メンバー>
蔵本さん:Sreake、PM(プロジェクトマネージャー)
勝山さん:Sreake、セールス
山本さん:Sreake、マーケター
*Sreakeサービスサイト
ゴールは作ることではなく、お客さま自身が運用できるようにすること
高田:
面接でよく候補者さんから「Sreakeって、SIer(またはITコンサルティング)と何が違うんですか?」と聞かれるのですが、たしかにわかりづらいところもあるのかなと思いまして。
そこで今回は、「違い」を明らかにするべく、開発全体を見ている蔵本さんを中心にお聞きしていきたいと考えています。
さっそくですが、目的やゴールに違いはあるのでしょうか?
蔵本:
SRE総合支援は、大きな違いで言うと内製化(お客さま自身が運用したり、開発できるようにすること)をゴールにしている点かなと思います。
SRE総合支援では、新規システム・サービスの構築を担うケースや、既存システム・サービスの運用改善を行うケースがあるのですが、新規システム・サービスを構築する場合でも、リリース後にお客さま自身の手で運用ができるよう、極力、負担を減らす設計・構築をするようにしたり、お客さまの運用体制のあり方などについても、議論を行ったりしています。
また、すでに運用が始まっている既存システム・サービスの改善では、プロセス上のムダを省くなど目の前にある課題を解消し、お客さまがサービスの運用開発を行う際の信頼性・効率を高める取り組みを担います。
これを踏まえて考えてみると、
- Sreake:システムリリース後の維持保守フェーズにおける内製化や、組織体制含めて、ベストな方法をお客さまと伴奏しながら考える
- SIer:維持保守をSIerが担う前提の元、求められるシステムを提供することに主眼をおいて対応する
といった点で違いがあると思います。
高田:
目指すゴールによって、開発に対する考え方や進め方も変わってくるんですね。
蔵本:
そうですね。内製化を目指して開発しているのか、それとも開発と運用・保守は別物として考えるのかで、大きく変わると思います。
高田:
お客さまとの関係性には、何か違いがありますか?
蔵本:
発注者と受注者という関係性は、どこも同じだと思います。ただ、SRE総合支援の場合、リリース後の維持保守を勘案する関係上、一緒に進めていくという感覚が強いかもしれません。
勝山:
上下関係ではなく、フラットな感じですよね。
高田:
契約上はお客さまであっても、関係性は社内で協力し合うメンバー同士のような感覚なんですね。
スケジュールや納期の調整のしやすさは、どうですか?
蔵本:
新規のシステムやサービスを構築する場合は、決められた納期に向けて構築をしていくので、この意味ではSIerに近いと思います。既存のシステムやサービスの見直しの場合は、課題の特定をした上で、いつまでに、どうやって解決していくのかをお客さまと調整しながら進めていくので、ITコンサルティングに近いですかね。
高田:
次の質問は、まず勝山さんにお聞きしたいのですが、今はどのような形で提案をされているのですか?
勝山:
エンジニアと一緒に要件を確認して、その内容をもとに私が提案書を作成して、最後にまたエンジニアにチェックしてもらってから、お客さまに提案するという流れです。セールス単独で進めることはないですね。放っておくと、わりとなんでも「できる」と言っちゃったりするので(笑)。
蔵本:
勝山さんが突っ走るタイプかどうかは、ちょっと置いといて(笑)。実際問題として、セールスだけで見積もりをするのはむずかしいんですよね。なので、案件対応に必要となる体制をエンジニア側で検討して、提案金額をセールスがつけるという体制でやっています。ここは、SIerでもITコンサルでも一緒なのかなと。
高田:
言われてみれば、クライアントワークである以上、エンジニアの工数の見積もりを出したり、利益を考えて提案をするのは、変わらないですもんね。
最後に、もうひとつ。身につけられるスキルに違いはありますか?
蔵本:
見据えるゴールは異なるものの、どうやったらお客さま課題を解決できるのかを考え、主体的に行動していくといった意味ではSIerや、ITコンサルティングと変わらないんじゃないかな。というわけで、ソフトスキルの面ではあまり違いがないかもしれません。
違いが出るのは、どちらかというとハードスキルのほうですかね。Sreakeは基本的にクラウド技術に強みをもったエンジニア自身が実際に手を動かしながら、お客さまと協働する形になります。そのため、クラウドネイティブな最新のナレッジや経験を得るチャンスは、他よりはるかに多いと思います。
質の高いサービスを安定して提供できる体制を構築中
高田:
Sreakeは今後、事業拡大を目指すフェーズに入っていきますが、どのような取り組みをしていきたいと考えていますか?
山本:
マーケティングとして事業拡大に貢献できるところでいうと、まずはリード獲得というところが一番ですかね。とはいっても、単純に数を増やしていくだけでは、セールスが対応しきれなくなってしまいます。そうならないように、ホットなタイミングを検知して送客するなど、マーケティングツールでセールスサイドをサポートできる仕組みを作っていけたらいいなと思っています。
高田:
ホットなタイミングというところで、ナーチャリングも重要な要素になる気がしたのですが。
山本:
もちろんナーチャリングは大事なのですが、SRE構築支援のようなむずかしい領域では、セールスが最初にお客さまに当たるのもけっこう有効だったりするんですよね。少なくとも、マーケティングだけでナーチャリングが完結することはないのかなと。ここは、勝山さんと一緒になって、マーケティングやセールスでのアプローチを考えていきたいですね。
高田:
たしかに、むずかしいサービスほど相手の状況や理解度に合わせて説明する必要があるというのは、わかる気がします。
勝山さん、セールスはいかがですか?
勝山:
事業拡大という観点でいうと、第一に、セールスメンバーの拡充。加えて、すべてのセールスが同じレベルの提案ができるよう、標準化や仕組みを作っていくことが必要だと考えています。
もうひとつ、支援を受けるハードルを下げる取り組みも検討しています。新しいサービスをいきなりガッツリ使うのって不安だし、少なからず抵抗があると思うんです。そこで、支援の範囲やコストの面でミニマムなメニューを作れたらいいなと。
高田:
なるほど! 「一度、使ってみようかな」となりやすいわけですね。
ちょっと話が戻ってしまうのですが、たしか開発のところでも標準化を進めているんですよね?
蔵本:
そうですね。どのエンジニアが案件に参画しても同じレベルで高い価値を提供することを目指して、知識が属人化しないよう開発プロセスの型・ナレッジを体系化したり、育成制度の拡充をしたりなど、標準化を進めています。また、ナレッジの共有という意味では、週2〜3時間はエンジニアが集まって、技術的な知見・気づきを共有する機会も作っています。
高田:
週2〜3時間は、かなり多いですね!
蔵本:
だと思います。また、LLMを使ってみようとかって、R&D的な取り組みも、よくやっていますね。あとは、GoogleやAWSといったパートナーさんから案件を紹介してもらえるよう、認定資格の取得を推進していたりもします。資格があるほうがパートナーさんに覚えてもらいやすいですからね。
高田:
エンジニア/開発、セールス、マーケティングそれぞれが事業拡大に向けて新しい取り組みを始めていることが聞けて、とてもワクワクしてきました! 今日はありがとうございました。