ビジュアルSOPマネジメントプラットフォーム「Teachme Biz」を提供するスタディストでは、この度、数年ぶりとなる大規模な機能追加を行いました。（※SOP：標準作業手順書）

作成した手順書から、研修の受講者にとって必要なものだけを選んで「コース」を作成したり、進捗管理ができたりする「トレーニング」という新機能。コロナ禍で集合研修が難しい状況のなか、リモートでの研修に役立つとして、多くの企業で活用が進んでいます。

実はこの機能、開発段階から積極的にユーザーヒアリングを行い、徹底的に使いやすさにこだわりました。また、技術的な側面では、スタディスト開発部としてはじめてマイクロサービスアーキテクチャを採用し、開発スピードの向上や技術的な挑戦も実現しています。

「使われなければ意味がない」

「ユーザーが本当に求めている機能開発を」

トレーニング機能の開発チームに話を聞きました。

手順書を「作って終わり」にしないために

ーーーまずはお二人の役割とこれまでのキャリアについて教えてください。

井上：　トレーニング機能のプロダクトマネージャーを担当しています。ユーザー様のためにどんな機能を作るのか、どういう順序で機能を追加していくのか、どうしたらもっとトレーニング機能を使ってもらえるのか、といったところを考え、推進していく役割です。定期的にユーザー様にヒアリングをさせていただき、そこで得た情報をメンバーに伝えています。

もともとエンジニアで、SES（System Engineering Service）で取引先に出向してシステム開発をしていましたが、事業会社で働きたいという想いがあり、Teachme Bizが持つ可能性に惹かれスタディストに転職をしました。転職後もエンジニアでいる予定でしたが、会社の要望と自身の適性がマッチした形で、現在はプロダクトマネージャーをしています。ビジネスが好きなこともあり、とても向いていると感じていますね。

開発部プロダクトマネジメントG　井上大輔

澤：　トレーニング機能の担当のエンジニアとして入社し、半年弱で同チームのリーダーになりました。プロダクトマネージャーである井上さんがユーザー様へのヒアリングで得た要望などを、開発側の視点で具現化していく役割です。エンジニアのスケジューリングにはじまり、チーム内で解決できそうにない課題が発生したときにはチーム外からメンバーをアサインするなど、リリースに向けた調整ごとも担っています。

前職はメーカーの営業で、エンジニアではありませんでした。職種が変わって大変なこともありますが、元々趣味でコードを書いたりしていたので、好きなことを仕事にできたという感じですね。

ーーートレーニング機能はどのような背景で生まれたのでしょうか？

井上：　Teachme Bizは現在約2,000社で活用されており、企業によっては数千点にものぼる手順書を作成しています。手順書が沢山作られていること自体はとても喜ばしいことなのですが、せっかく作っても見られていない、数が多くてどれを見ればよいのか分からない、という状況が発生することもありました。手順書を作って終わりになってしまっては意味がないので、作成したあとの「浸透させる仕組み」が必要だということに気付きました。

ユーザー様の活用状況を分析していくと、たとえば新入社員向けの手順書を配信していたり、タスク配信機能を使っていたりする企業は、活用度が高いといったことが分かってきました。使うシーンの創出、閲覧するきっかけの提供によって手順書が社内に浸透するようなのです。このことが、「複数の手順書をコースとしてまとめて配信する」というトレーニング機能の着想につながりました。手順書の浸透は、業務手順の定着、ひいてはブランド力や業務効率の向上といった経営効果にもつながると考えています。

ユーザーの協力を得て「本当に使われる機能」の開発を

ーーー今回の新機能開発は、ユーザーヒアリングを何度も行い、かなり作り込んだと聞いています。どのように開発が進んだのでしょうか？

井上：　ユーザー様にご協力いただけるとのこともあり、アジャイル開発を意識しました。アジャイル開発自体には以前から取り組んでいましたが、オープンβという形でユーザー様にご協力いただくのはスタディストとして初めての取り組みです。多いときでは月に2〜3回など高頻度でヒアリングを実施し、そこで得た情報や、いただいた要望をもとに1〜2ヶ月で開発、リリースというサイクルを回していきました。

機能をどこまで作り込んでいつ出すかという判断には、常に取捨選択が発生します。MVP（Minimum Viable Product：実用最小限の製品）を意識し、まずはお客様に価値を提供できる最低限の機能でフィードバックをいただくようにすることで、作り込んだけれど使われないという事態を防ぎました。開発サイクルを回す過程で削ったものも沢山ありますし、変更した仕様も色々あります。トレーニングコースに改変が発生したときの仕様が代表的な例なのですが、当初はコースの内容が変更されても、そのコースを修了した受講者には通知が行かないようになっていました。でも、本当に全員に最新の業務標準を徹底するには、内容が変更されたらその部分を追加で受講するべきでは、という意見があり、ローンチ時には通知がいく仕様に変更しました。細かな部分やレイアウトひとつとっても、全体的にユーザー様の声が反映されたものに仕上がっています。

ーーー開発段階からユーザー様にご協力いただくことで、洗練された機能をリリースできるということですね。今回のような開発スタイルに変更したことで、苦労したことはありますか？

井上：　これまでのスタディストでは、機能概要などはビジネスサイドで決定し、開発部ではそれを具現化するという役割分担が多かったのですが、今回のプロジェクトではどのような機能を開発すべきかを検討するようになりました。それに伴い、エンジニアにもユーザー理解を深めることを求めたので、はじめは戸惑うメンバーもいましたね。でもそこはしっかりと議論を重ねることで解決できました。

開発部ウェブアプリG　澤大地

澤：　QCDS（Quality,Cost,Delivery,Service）の調整は悩ましかったです。MVPを重視するとはいっても、何でもかんでもミニマムで出して良いわけではなく、「トレーニング機能に期待していること」や「営業がターゲットとしている業種は」など、経営方針やビジネスサイドとの調整が常に必要でした。最近はエンタープライズのユーザー様も増えているので、どのくらいの規模にまで対応させるかなども検討を重ねた部分です。とはいえ、意思決定の場を設けて議論することについてメンバーがとても積極的でやりやすい雰囲気なのはありがたいです。

また、こういった議論が生まれるのはそもそもユーザー様の声を知る機会が多いからだと思っています。ただ言われたものを作るのではなく、高い当事者意識のもと、本当にユーザーのためになるものは何なのか、という考えが生まれるからこそ発生する議論なんですよね。

マイクロサービスで技術選定の自由度を向上

ーーー今回の機能追加は、Teachme Bizの中でもかなり大きなものでした。マイクロサービスアーキテクチャを採用することで、既存システムへの影響を最小限におさえることができたと聞いています。

澤：　そうでうすね。今回スタディストとして初めてマイクロサービスアーキテクチャを採用しました。

マイクロサービスアーキテクチャとは：ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種。（Wikipediaより）

既存システムとは別物として開発するので、サービスの冗長化、既存機能への影響の最小化、開発スピードの高速化といったメリットがあります。サーバーが独立しているので、例えばコードを変更しようとなった時にも、既存システムへの影響を心配せずに実施することができるので、ある程度のことはチーム内で意思決定を完結させられます。

技術選定の自由度が上がるのもマイクロサービスの大きなメリットのひとつです。既存機能のしがらみがないので、ゼロから最適なアーキテクチャを考えていけるなど、技術的なチャレンジをしやすい環境になったと思います。

ーーー開発部では、そういった技術選定に関する議論は頻繁に行われているんですか？

澤：　不定期ですが、任意のタイミングで自由にアーキテクチャレビューを設定することができます。技術選定に関する提案がある時には、資料をまとめてレビューの場を設ければ、CTOやSREグループ、技術支援グループ（各チームへ技術的アドバイスを行う開発者支援のためのグループ）と議論することが可能です。また、必要に応じて技術顧問の方に相談することもできます。

ーーーユーザーの声が届きやすく、技術的にも改善を重ねていける環境が、より良いプロダクト開発につながっていくということですね。これからも期待しています。ありがとうございました！