B2BのSaaSにおけるプロダクト開発とは
はじめに
SkillnoteVPoEの安藤です。
今回はSkillnoteの主戦場領域におけるプロダクト開発について、どのような業務フローでそれを実施し、各役割がどのようなミッションを持っているか、を記載したいと思います。
Skillnoteプロダクトの特徴
Skillnoteは製造業の現場にフォーカスしたスキルマネジメントシステムです。
ビジネスモデルは法人向けのSaaS、システム形態はHRTechに分類される業務システムとなっています。
そのため、例えばメディアサイトのような個人向けサービスと比較すると以下のような特徴があります。
リリース周期を短くできない
高いセキュリティ要件に答える必要がある
高い品質基準を満たす必要がある
リリース周期を短くできない
法人向けシステムに共通する特徴になると思いますが、「社内マニュアル」としてシステムの利用方法を整備し、その上で日々の業務を設計、運用に落とし込むということをお客様ご自身が独自に実施されていることがあります。
また、RPAツールを用いて業務の効率化・自動化を実施されていることもあります。
そのため、あまりにも早くシステムが変化してしまうと「昨日までここにあった画面がなくなっている」など、システムの目的に反して日々の業務が滞ってしまう、ということも発生してしまいます。
この点と、素早くリリースし、お客様の反応をなるべく早くもらって次の開発に活かせるクラウドサービスの利点とのバランスを鑑みて、現在は月に1回のリリースサイクルを採用しています。
高いセキュリティ要件に答える必要がある
法人向けサービスを提供されているエンジニアの方であれば「セキュリティチェック」と言えば通じるかと思います。
Skillnoteでもお客様から商談開始時点や受注後に至るまで様々なタイミングでセキュリティチェックを受けますが、システム面、組織・運用体制面でこれらの基準を満たしていく必要があります。
Skillnoteでは、体制面はISMS取得を最低限実施しており、今後もJISQ 27017やSOC2 type2レポートなどの第3者認証取得に向けて引き続き取り組んで行く必要があります。
システム面はバックアップや冗長化はもちろんのこと、目標復旧時間や平均修復時間など多種多様な項目に答えられるよう日々運用整備・データ収集を行い、さらに第3者による脆弱性診断も定期的に実施、フィードバックに対する対応も実施しています。
海外展開も踏まえると、SLA（サービス品質保証）という形で明示的にお客様と合意する必要も出てくるため、体制およびシステム共に今後もブラッシュアップし続ける必要があります。
高い品質水準を満たす必要がある
製造業では、お客様が製造する製品によっては人の命に直結するようなモノを製造していたり、モノの製造過程において働く人が危険にさらされるリスクのある業務を行っていたりします。
高い品質水準・安全水準が求められる業務の中で利用されるシステムとなるため、業務システムとは言えども同様の高い品質水準や業務管理にあたる考え方ができているかどうかが求められます。
こうしたことに答えられる開発フロー、品質管理フロー、業務フローをSkillnote社内としても整えていく必要があります。
Skillnote開発チームの役割・ミッション
今まで見てきた要求に応えていくため、開発チームでは様々な取り組みを行っており、日々改善活動も行っています。
以下では現在の業務フローと、各役割が果たすべきミッションについて解説します。
現在の業務フロー
大雑把ですが、現在の開発フローは図のようになっています。
リリース手前までの流れで、リリースフローやリリース後の振り返りフローは別途定義していますが、おおよその流れは掴んでいただけると思います。
各役割のミッション
現在の役割とミッションは以下のようになっています。
■エンジニア
1案件に1人必ず主担当としてアサインされ、ドメイン分析から機能仕様・非機能仕様策定、開発からリリースまで一通りの業務を担当。
パフォーマンステストは現状エンジニア担当です。
■デザイナー（フロントエンドエンジニア）
UIが絡む案件には必ずアサインされ、ドメイン分析と並行してデザイン・UI仕様策定、フロントコーディングを担当。
UXなどユーザビリティに関連する部分を主なミッションとしています。
■QAエンジニア
1案件に1人必ず主担当としてアサインされ、PdM仕様（PRD）のレビューやテスト設計・実施・プルリクエストのレビューを行いテスト観点漏れチェック等を担当。上流から関わりプロダクト品質を作り込む、品質をグロースさせていくことを主なミッションとしています。
また、日々発生するインシデントのとりまとめや他チームとのコミュニケーション、リリース単位での仕様説明会の開催や振り返り（不具合分析からの開発プロセス改善）なども担当しています。
■SRE・インフラエンジニア
業務フロー上は出てきていませんが、システムが止まらない、止めないための運用監視をミッションとし、営業デモ用など各種環境の管理・監視、CI/CDプロセスの改善、ボトルネックが変わっていくパフォーマンスへの対応、可視化、IaCのメンテナンスやセキュリティへの対応、エンタープライズのお客様向けのシングルテナント環境構築・整備なども担当しています。
まとめ
現状の開発フローやその背景について解説させていただきました。各役割の担当業務やミッションも記載しましたが、記載した通りキレイに分担されている訳ではなく実体は全員が兼務のフルスタックな働き方をしています。
チームの状況としては、幸いにもメンバーが充実してきてだんだんと主領域はこの役割、ということが出てきて分化が少し始まった、というのが正しい説明かと思います。
今後も引き続き各役割を中心として採用は進めていくため、ゆるやかに分化は進んでいきますが、まだまだ少人数、かつワンプロダクトということもあり専門特化ではなくフルスタックな働き方は当面継続していきます。
2〜3年後には30名、50名規模にまで開発チームが成長していくことを想定しているため、そこに向けて引き続き開発プロセス改善・役割分担の見直しなど進め、チームの分化がしやすい仕組み作りやそれに合わせたプロダクトアーキテクチャの進化、評価制度の整備も進めていきます。
具体的な各ポジションの担当業務についてもっと突っ込んで聞いてみたいなど、興味を持っていただけた方、カジュアル面談を随時受け付けていますので、是非気軽に話しにきてください！
この記事が気に入ったらサポートをしてみませんか？