こんにちは！スマートバンクでUXリサーチャーをしているHarokaです。
今回のブログでは、2023年11月に入社したエンジニアのchobishibaさんにインタビューするかたちで、エンジニアとリサーチャーの協業体制についてご紹介します！
CTOのyutaさんから、”開発の中にリサーチの工程が組み込まれていてWhyの部分を理解して開発できるのが弊社開発の強み”と評してもらったリサーチ環境。
開発の中にリサーチの工程が組み込まれていてWhyの部分を理解して開発できるのが弊社開発の強みでもあります。
— 堀井 雄太 | SmartBank CTO (@yutadayo) 2023年11月21日
> 過去のリサーチは資産であり、それらが活用できる状態であるようリサーチャーで一元管理・保守運用している https://t.co/cBNMQJT1Ds
私は、リサーチから開発にバトンを手渡すまで時間的にも・情報共有の観点でも離れていることが多いと認識しています。離れていることでネガティブな影響が出ることを極力抑えたく、リサーチ側から実装フェーズにアプローチできることはなんだろうか？と考えています。
エンジニアさんが安心して仕様検討や見積もり、開発に取り組めるよう、自分が行っているのは、徹底したドキュメント化とリサーチの場に居合わせてもらう仕掛け。ちょうど数ヶ月前にチームにジョインしてくれたchobishibaさんは、リサーチオンボーディングの一環として一ヶ月間インタビューに同席・書記を担当してもらいました。
インタビュー後に色々会話する中で、「なぜこの機能を作るのか、という点に関われるのがスマートバンクで開発できる魅力」と伺ったので、実際のところどのように感じてらっしゃるのか、お聞きしてみました！
そろそろ1ヶ月なので近況報告兼ねて入社エントリ書いてみました！毎日楽しく過ごしてます😆
— chobishiba (@chobishiba) 2023年12月13日
もっと踏み込んだものづくりがしたくてスマートバンクに入社しました｜chobishiba @chobishiba #note #入社エントリ https://t.co/f0vfY5UX0n
ここから、chobishibaさんへのインタビュー形式でお届けします！
「真のニーズ」を捉えづらいもどかしさ
ーー「なぜ作るかにこだわりたい」と思うようになったエピソードを教えていただけますか？
私が「なぜ作るかにこだわりたい」と考えるようになったのは、これまでの開発経験にあります。新卒から20年間ずっと自社のサービスではなく、お客様のサービス開発を請け負ったり支援したりする、いわゆるクライアントワーク型の働き方をしてきました。
多種多様な業界のサービスと関われたり、開発知見も溜まったり、やりがいもある一方で、やはり「中の人」ではないので関われる領域に制限があったりもしました。
その制限の1つに「なぜ作るか」がありました。
クライアントワークの場合、ある程度「⚪︎⚪︎を作って欲しい」という具体的な要望からはじまります。しかしその要望が課題の最適な解決手段とは限りません。
もちろん作る前に「なぜ作りたいか」を聞いて「真のニーズ」を探り、⚪︎⚪︎を作るのが適切かを考えるわけですが、必ずしもお客様が全てを把握し、正確に状況を共有できるわけでもないです。
また、お客様と一口に言ってもさまざまな立場の方がいらっしゃいます。「こうしてほしい」という要望があってもそれが「窓口となってる方が想像したこと」なのか「実際に使う人の観点からの意見」なのか明確にわからないことも多いです。
このため、要件定義工程での確からしさが仮定のまま検証しきれずに進んでしまったり、開発が進んでから新事実が発覚することもあります。そうした場合も、ある程度の手戻りはできますが、限度があります。
「真のニーズ」がわかったのならそれを作りたい。しかし開発が進んでしまった段階だと予算や時間も有限なので大掛かりな作り直しはできず、残されたリソースでなんとか形にするしかない。そうやってできあがったものが実際に使われる様子を見るとやっぱりどこか「本当にこれでよかったのだろうか」と不完全燃焼さが残ることもありました。
「なぜ」を知ることで、「どうやって」作るの手数が増える
こうした現場では、リサーチャーやデザイナーがエンジニアから見える範囲にいなかったり、なぜその意思決定が成されて今に至っているのかを辿る手がかりがほとんどありませんでした。
作って欲しい人が「真のニーズ」を認知できているとは限らないとわかっているからこそ、その認知から支えたい。わざわざ伝えるのも大変です。なのでこちらから情報を取りに行きたい。でも知る術がないのです。
正直なところ、「最初から知っていたら、もっと違う作りにできたのに…」と悔しい思いをしたこともありました。
エンジニアは「どうやって」を考えるのが役割の一つだと思いますが、「なぜ」を知っているかどうかで「どうやって」の手数が変わると考えます。「なぜ」を知ることで、以下のような振る舞いが可能になります。
今のシステム状態をよく知ってるので、別の解決方法の提案ができる 目指すゴールがわかるので、見落としている検討事項に気付ける 全体との整合性や影響を考慮した上で作れる
私は不整合や漏れに気がつきやすいタイプなので、そういった面を生かすためにももっと早い段階から関わりたい、いっそ「なぜ作りたいか」の場に居合わせられたら…と思うようになりました。
また、考えや背景を知っていると、自分の開発進行にポジティブな影響もあります。「なぜ」がわかっていると、都度「なぜ」と付き合わせて自分の頭で考えて進んでいけますし、手探り感もなくなり安心して取り組めます。
それぞれの専門性を持ち寄って、一緒に考える
ーースマートバンクでは、どういった点で「なぜ作るか」にアプローチできていると感じますか？
今までお話ししてきたような問題は、開発構造に起因するものが多く、自身がもっと踏み込んで開発したいという気持ちを強く持つに至りました。
スマートバンクに入社すると、リサーチャー、プロダクトマネージャー、デザイナー、エンジニアなど専門性を持ったメンバーが揃っているだけではなく、それぞれの人がお互いの専門性でカバーし合っているので手堅いものが作れることを目の当たりにしました。
上の図にあるように、それぞれのパートで重なり合う部分があり、矢印を辿ると他のフェーズと繋がっています。メインで動く職種が違えど、どの職種であってもそのフェーズに関わることができます。
スマートバンクのバリューに、「SuperOwnership」があります。越境を恐れないこと、肩書きや職種にとらわれず自身のできることはやるし、それが賞賛される文化なのです。
専門性を持つ人が多いからこそ、相手の領域に入っていくのは「失礼じゃないか」と躊躇うこともあるかと思いますが、スマートバンクの場合は、その塩梅がよく、お互いがお互いをリスペクトしながら協業しているように感じます。
それは、例えばどこかの部署が突出して権力を持っていることもなく、日々の仕事の様子をドキュメントに残す文化と合わさっているからこそ成り立っているのかもしれません。
また、ユーザーインタビューを通し、仮説検証を回して、作るものを決定しているプロセスがあるからこそ、「なぜ作るか」への納得感があるのではないかと思います。
今思うと、仮説がかならず正しいとは限らないのに、検証せずに仮説だけで走ってしまっていたなというプロジェクトが複数ありました。スマートバンクでは、「なんか違うな…」という消化不良のまま作り始めず、たとえばインタビューを追加で回す意思決定をしていたのが印象的でした。
開発期間には限りがあります。でも、「時間が来たからここまでしか調査しない」といった意思決定ではなく、開発のスコープと合わせて、体験の向上が担保され、顧客にとって良い変化をもたらせそうだ、とチームの合意を取るようになっていました。
私が入社してすぐアサインされたプロジェクトでは、インタビューに同席する、まとめ作業に参加する、定例でアップデートされるリサーチ情報をキャッチアップするなど、上記のプロセスを同期しながら見ていられました。それを踏まえて頭で考えて手を動かせるようになっているんだ、と思いました。
リサーチをエンジニア業務に取り入れる工夫
仕様検討をする際、どうしてこの仕様になったんだろう？とか、この機能はそもそもどう使われる想定なんだろう？と実際にユーザーが手に取る様子を思い浮かべながら考えます。
その時、見えるところに意思決定のドキュメントがあるので、思考の過程を辿りつつ、結論に着地した流れがわかります。仕様検討するに至った思考をインストールできるとも言えるでしょう。
また、インタビューなどユーザーの話す様子を直接聞けることにより、企画が生まれる段階から側にいられる、もしくは一端として担えるので、一緒に作っている感覚も生まれました。
インタビュープロセスにはPM、デザイナーがメインで関わっており、メインのルートの敷き方がいろんなことを考慮されているな、とよくわかります。これまではそこを想像で補うしかなかったので、ある意味エンジニアの思考リソースが削減できているように思います。
また、ユーザーコミュニケーションまわりも考慮されていて、遷移図など見えるかたちで記されているのも安心できるポイントですね。たとえばこれが遷移図ではなく、文章だけ、画面デザインだけとなると、自分の頭の中で前後を考えないといけなくなります。自分だけだと、バイアスがかかりがちなので、普段ユーザーはこういうふうに使っているよ、という情報があればあるほど考慮できることも増えます。
ーーインタビュー参加についてはどのような機会と捉えていましたか？
一つのモデルケースとして聞いていました。こんな人もいるんだ、こう使う人もいるのか、といったふうに、使い方、背景を理解することに徹しました。
自分のデータベースの中に溜めるようなイメージですね。このデータベースが、仕様検討の際に生きてきます。
インタビューの後、周りの人が質問する様子を見ていて、その質問内容が勉強になるなと思っています。インタビューに出て行動パターンをインストールする気分で聞いていて、掘り下げについては専門の方が聞いている様子から「そういう視点から見ることもできるんだな」「ここでそんな質問をしたらからこそ自分の予想とは違うことが引き出せたな」など気づきがあります。
初めのうちは、「書記」として参加するのがちょうどいいのかもしれません。書記をすると、いい意味で「こうじゃないか、ああじゃないか」を考える余裕がありません。素直に聞いていられることもあり、聞いたものを文字としてアウトプットするので記憶にも残りやすいです。
また、役割としてもらえることで同席するハードルが下がっているようにも感じます。
chobishiba さん、教えてくださりありがとうございました！
お話を聞けば聞くほど、「なぜ作るか」をリサーチャーだけではなく、多くの職種メンバーと一緒に考えることで、より価値があるものをユーザーに届けられる可能性を感じました。
私自身、リサーチで得た気づきをどのように組織に循環させていくかに頭を使っているので、chobishibaさんの知見をこれからも借りながら一緒に考えていきたいです。
一緒に「なぜ」を考えるエンジニアを募集しています！ カジュアル面談も受け付けていますので、お気軽にご応募ください！
