【開発チーム座談会(前編)】エンジニア経験のあるPdM×自由な環境=開発を最高に楽しめる! | 株式会社スリーシェイク
こんにちは! スリーシェイクの鈴木です。今回は、久しぶりの座談会企画! Securify Scan(セキュリファイ スキャン)を開発しているチームのみなさんに登場していただきます。Securif...
https://www.wantedly.com/companies/3-shake/post_articles/517521
はじめまして! HR本部の高田です。
今後、Wantedlyでの広報や発信をしていきますので、以後、お見知り置きください。
Securify Scan(セキュリファイ スキャン)の開発チームメンバーによる座談会(*)に続き、今回も座談会企画。スリーシェイクの主力事業であるSRE総合支援サービス「Sreake(スリーク)」に関わるみなさんに集まっていただきました。
*Securify Scan開発チームメンバーの座談会は、以下からご覧いただけます
エンジニア約50名に加え、セールス、マーケターもジョインし、これからさらなる拡大を迎えるフェーズで、どんな意気込みを持って仕事に取り組んでいるのか。三者三様の想いや考えを、存分に語っていただきました。
<座談会メンバー>
蔵本さん:Sreake、PM(プロジェクトマネージャー)
勝山さん:Sreake、セールス
山本さん:Sreake、マーケター
*Sreakeサービスサイト
高田:
まずは、それぞれのミッションや目標について、教えていただけますか? トップバッターは蔵本さん、よろしくお願いします!
蔵本さん(以下、蔵本):
Sreake事業部としては、「インフラをエンジニアリングによってシンプルにしてイノベーションが起こりやすい世界を作る」というミッションを掲げています。エンジニアリングでシステム開発や運用を効率化することによって、イノベーションが起こりやすい世界を作っていきましょう、という意味ですね。
当然のことながら、企業が抱えている課題や効率化の方法は、千差万別です。そのため、常に「なにか改善できることはないか」を考え続けることのできる強いエンジニアが、Sreakeには揃っていると思います。
そのエンジニアを支え、パフォーマンスを発揮しやすい環境を作るのが、PMの役割です。エンジニアが価値提供に集中できるよう、お客さまとの調整作業や交渉、管理などを一手に引き受けている形になります。
高田:
あえて裏方からのサポートに徹しているんですね。
次は勝山さん、お願いできますか?
勝山さん(以下、勝山):
セールスのミッションはとてもシンプルで、事業部の売上目標を達成することです。当面は、これまで着手できていなかった既存顧客へのアプローチに注力したいと考えています。すでに取引実績があったり、関係性が築けているお客さまへのアップセル、クロスセルですね。
とはいっても、新規開拓を一切やらないというわけではありません。マーケットを広げていくには、やはり新規のお客さまを増やしていく必要がありますから。
高田:
新規開拓といえば、マーケティングの力も必要ですよね。
山本さん(以下、山本):
まさにそのとおりで、売上につながるリードの獲得が僕のミッションになります。業務としては、Webサイトやオンラインウェビナー、展示会の企画・進行をしています。
高田:
ざっくばらんな聞き方になってしまうのですが、マーケティング施策の勝ち筋みたいなものは、もう見えてきているんですか?
山本:
まだ模索しているところです。仮説ではありますが、SREを実施したいという企業はまだそこまで多くなく、ニーズが顕在化していない状態だと思っています。それはなぜか? おそらく「SREの考え方や技術を使えば自社の課題を解決できる」ことを知らないからだと思うんです。
ここをお客さま自身に自覚してもらうためには、時間をかけてSREの必要性を訴えていくしかないのかなと考えています。いわゆる啓蒙活動ですね。
もうひとつ、違いや強みをどうやって見せていくのかも、重要なポイントとして捉えています。たとえば、Sreakeが提供しているモノと、他社が提供しているモノは、同一のように見えたとしても、ぜんぜん別物だと思っていまして、この違いをわかりやすく見せるのが、むずかしいなと。
蔵本:
「違い」としては、われわれがどこをゴールとして見据えているのか?といった点と、それを達成するための技術力やケイパビリティになってくると思うんですよね。将来的な内製化を見据えて、「お客さまの組織は、こうあるべきじゃないですか?」といった組織課題のようなところまで踏み込んだ提案をすることが、「違い」になる気がします。
概略をお話しましたが、違いを伝えづらいというのは、山本さんのおっしゃるとおりだと思います。
山本:
やっぱり、模索するしかないですよね。一般的なSaaSプロダクトに関しては、The Modelを中心とした成功パターンが定着していますが、先ほど話した啓蒙するという部分も含めて、Sreakeにはこのパターンが当てはまらないと思っていて。どうやったら成果につながるのかを考えるところから始めるのは、正直むずかしいですが、それゆえにやりがいも感じています。
高田:
ここ数年で、SREという考え方は広まりつつあるものの、人に説明するとなるとむずかしいなと僕個人は思っていまして。みなさんはどうやって説明しているのか、ぜひお聞かせいただけると嬉しいです。
勝山:
知人や家族には、「Webサイトやスマホのアプリが当たり前に使えるようにするための技術的な取り組み」という感じで説明してます。
たとえば、大規模な通信障害でインターネットに接続できないとか、チケットの予約が殺到してサーバーがダウンしてしまうのは、サービスの信頼性が損なわれている状況だと言えます。こうしたことが起きないようにすることを、「信頼性を高める」と表現しているのですが…ここらへんは蔵本さんのほうが詳しいですよね?
蔵本:
ほぼ勝山さんがおっしゃった通りで、システム障害が起こらないといった点に加えて、サクサク動くといった性能面も、SREで言う「信頼性」だったりします。そもそもサービスが当たり前に使えているのは、裏でたくさんの人が動いて、実現できているものなんですよね。
高田:
お2人のお話を聞いてると、SREとは「みんなが快適にサービスを使えるようにするための取り組み」なのかなと感じたのですが。
山本:
僕も、同じような理解をしてます。
高田:
事業についてもうちょっと突っ込んで話をお聞きしたいのですが、SRE総合支援サービスでは具体的にどのような取り組みをしているのですか?
蔵本:
「これとこれをしています」と伝えるだけだとわかりづらいかと思うので、順を追って説明していきますね。
SRE (Site Reliability Engineering)って、サービスの信頼性をエンジニアリングによって高めていくという活動、実践方法なんですね。でも、信頼性だけにフォーカスするものではないのかなと思っていて。
たとえば、アマプラ(Amazon Prime Video)をいつでも見られるようにしておくのは「信頼性」なんですね。これ自体も大切ことではあるものの、同じサービス・機能を提供し続ければいいかというと、そうではない。
高田:
たしかに、機能が改善されなければ不満も出てきます。
蔵本:
そういうことです。その上、世の中的にもサブスクリプション型のサービスが増えてきて、継続的にサービスを改善・拡充していくことが求められていますよね。
となると、信頼性=安定的にサービスを提供するだけでなく、ユーザーに刺さる機能を日々、アップデートし続けるという、相反することを実践しなくてはならないわけです。要は、信頼性を維持しながらサービスのイノベーションを進めていくと。それを実現する方法のひとつとして、SREという考え方を使うんです。
高田:
こうやって聞いてると、めちゃくちゃ難易度高いですね。
今さらですが、SREって単純に自動化、効率化することではないんですよね?
蔵本:
そうですね。自動化、効率化することだけが目的ではないですが、重要な要素の一つであるのは間違いないです。
ひとつ例を挙げてみましょうか。システム変更作業をする場合、昔は、手順書に沿って、手作業で一つずつ、変更作業をやっていたんですね。でもこれだと、ヒューマンエラーが発生しやすいし、作業にものすごい時間がかかるので、頻繁に変更作業をするのはむずかしかったんです。
それが今だと、修正したプログラムを特定の場所に配置するとリリース作業まで自動でできるという仕組みを作れます。そうするとミスはほとんどなくなりますし、作業する負担も減る。さらに、リリースまでのサイクルも短くできるんです。
このように、人がやっている作業を機械化することで、信頼性とイノベーションのスピードを両立する取り組みを行うことも、SREに含まれているんですよ。
(後編に続く)
*後編はこちら