この記事は CARTA TECH BLOGアドベントカレンダー 12/22の記事です。
こんにちは、スプラトゥーンをする傍ら猫の下僕をしつつ、サポーターズというところエンジニアマネージャーをやっていますara_ta3です。
サポーターズ はCARTAの子会社で新卒採用支援を行っている会社です。
CARTAではフルサイクル開発を謳っており、サポーターズの開発チームでもその良さを感じながら実際にフルサイクル開発を行っています。
今回はその一例として、1on1イベントと呼ばれる、1日で最大8社の企業と面談できるイベントをここ1・2年でシステムに落とし込んで行った事例をお話できればと思います。
サポーターズ1on1イベント開発の背景
サポーターズでは主に学生の方、企業の人事担当者の方を対象とした自社開発のシステムを提供しつつも、1on1のイベントに関してはサイボウズさんのkintoneを駆使してこなしていました。
kintoneはいわゆるノーコードツールで、エンジニア以外の人でも比較的容易にプロトタイプを作って、業務に適用させることが出来るので非常に便利です。
なにかやってみたいことを小さく試しPDCAを回すという点で我々はkintoneを利用しており、今回テーマの1on1イベント以外でも非常に有意義に使わせていただいております。
参考 techblog.cartaholdings.co.jp
しかし、kintoneもそれなりに構築に知識が必要となり、業務知識(ドメイン)が属人化し、一人に集中する状況になっていました。システムの改修を行うにも一人がコストを全て背負う形にもなっており、それ自体が事業リスクなのではないかという懸念もありました。
また、3rd party pluginで提供しているような簡素なUIではなく、リッチなUIを提供したいというニーズもあったところから今回の話が始まります。
提案フェーズ
プロダクトオーナーと徹底的に議論する
まず初めに、プロダクトオーナーから
- ドメイン知識の属人化のリスク
- 改修コストを全て一人が背負うような状態
- リッチなUIがほしい
と話があがります。
ここで我々エンジニアチームは
- そもそもやる必要があるのか
- 既存のプロトタイプでも十分な価値提供ができているのではないか
- なぜこの開発を行うのか
を理解するための議論を徹底的に行います。
本質を追求し、どんな価値を提供をするか言葉にする
これがなぜかと言うと、CARTA Tech Visionに「本質志向」があり、本質を追求し課題を解決した先にどういう価値を提供できるのかを判断することが大事だと考えているからです。
なので、ビジネスに詳しい人がやりたいと言ったから開発を行うのではなく、エンジニアそれぞれが「なぜやるべきなのか」「解くべき課題とそれを解決した先の価値はなんなのか」を理解した上で開発を行います。
議論の結果、以下の点から開発は行ったほうがいいだろうという話にまとまりました。
- ドメイン知識の属人化に関して
- ドメイン知識をコードに落とし込むことで、コードと人が行うオペレーション操作が一致している状況を作り、システムの理解がある人を増やせるだろうという点。
- UIに関して
- 既存のシステムでそれなりのUIを提供しているので、そこに乗せていけば思った通りの効果は期待できるだろうという点。
恐れを生まず、本質的な議論のためにお互いにリスペクトを持つ
少し話がそれますが、この時、エンジニアがただただ「なんでそんなことやらなきゃいけないの？」と雑なコミュニケーションを取ってしまうと、ビジネスサイドを怖がらせてしまいます。
例えば、エンジニアの人々は怖いと無駄に恐れさせてしまったり、エンジニアは何を言ってもやってくれないから話しても無駄だというように感じさせてしまう可能性があります。
なので、コミュニケーションは互いにリスペクトを持った形でコミュニケーションを取る必要があることは念頭に置いておきたいです。
実装フェーズ
やると決まったなら顧客の本当に欲しかったものをしっかりと定義します。
大事なのは、今の運用をすべて捨てたとしたときにどういう形が最も良いのか(理想)を考え、現在地点とその理想の点を結んだ間にあるものを実装していくことだと私は考えています。
理想を描いて、まっすぐに向かう
今回のサポーターズの1on1での理想形としてはkintoneをやめ、サポーターズのシステムを使えば学生・企業、サポーターズ内の運用者全てが1on1面談イベントを行える状態でした。
元々の運用がkintoneの仕組みに乗っかっていたので一度kintoneから離れ、プロダクトとして本当に欲しいものを精査して作って行く必要があります。
というのも、なぜいまある運用の在り方を辿ったとき、システムや過去の経緯などの制約に依るもので、実は必要が無かったりもっとシンプルなやり方が隠れていたりします。
例えば
- 1on1面談イベント当日の面談を行う部分に関する機能
- イベント当日より前の学生による申し込みから参加に至るまでの機能
- 企業が対象学生のプロフィールを閲覧する機能
だったり様々なものが含まれていました。
次に、理想の地点が見えたなら現実的な実装を考えていきます。
価値の提供を行うには全てが揃っている必要はなく、一部の機能だけでも価値の提供が出来るはずです。
ただし関わるユーザ、ここでは学生や企業、さらにはサポーターズ内部の運用者のことも考えるべきです。ユーザへの価値、運用者の負担、実装にかかる時間などを考えて価値提供が出来る部分を模索していきます。
実際のこのときは、2022/3月頃に始まるインターン期に一部機能をリリースしようと初め考えていました。
※サポーターズの1on1面談イベントは時期が2つあり、インターン期(3月〜)と本選考期(9月〜)があります。
しかし、その実装はkintoneの機能を一部残し、その部分をユーザに使ってもらうという前提のもとでした。
その場合、kintone以外の部分で一定の価値提供が出来るとは言いつつも、複数のシステム(kintoneとサポーターズのシステム)を利用して貰う必要があり、ユーザの手間が増えてしまい総じてプラスの価値提供ができてるのか怪しいと考え、9月の本選考期まで機能提供を見送りました。
運用フェーズ / FBフェーズ
実際に実装が進んだ先ではサポーターズ内部でフィードバックサイクルを早くするべく定期的に触ってもらって目線を合わせていきました。
実際の運用者に使ってもらい、フィードバックを得る
具体的には、実戦投入までに細かくリリースを行い、実際に使ってもらうことを繰り返しました。
仕様策定のために話してるだけだと重要なことを引き出しきれないことがあります。なので、実際に使ってもらい困ってもらうことで「これも必要なんです！」と声を上げてもらいました。
最終的には実戦投入の1週間前ほどのタイミングで運用者とエンジニアでダミーの1on1イベントを実施し、最終チェックを行いました。
個々まで細かくやっていても気づけなかったエラーケースに遭遇し、本番に発覚して困ったりはしたのですが...イベント自体は成立してよかったです。
まとめ
以上がフルサイクル開発で1on1イベントを実装していった際のサポーターズ内での事例紹介でした。
個人的にはフェーズの前半が大事だと思っています。
「なぜやるのか」「ビジネス的にどうしていきたいのか」をいわゆるプロダクトオーナーと徹底的に議論し、自らの言葉で語れるまで開発を行うエンジニアが理解し開発を進めていくことでより良いプロダクトが作れるだろうと思っています。
これからもサポーターズは改善していきたい部分がたくさんありますし、していきたいにとどまらず改善していくので応援よろしくお願いします。
