エンジニアがペルソナを考える意義

shm

こんにちは、ZMSの清水です。

最近は新プロダクトの企画、プリセールス業務などに従事することが多くなり、以前よりもサービスやプロダクト開発の全体像を把握する必要が出てきています。

特に0から新たなサービスを開発するにあたっては、私のような営業チーム、企画チームに近い立場のエンジニアの動き方が開発スピードや成果に与える影響は大きいように思います。

そこで今回は最近のサービス開発で得た気付きを元に、開発の効率化、成果の最大化のために私のような立場のエンジニアが意識すべきことの一つである「ペルソナ」について紹介していきます。

ペルソナとは?

皆さんは「ペルソナ」という言葉をご存じでしょうか?

営業やマーケティングを担当されている方であればビジネスの現場でも頻出するワードであるためご存じかと思いますが、エンジニアとして働いていると耳にしたことがない、深くは知らないといった方も多いかもしれません。

ペルソナとは開発するサービス、製品を利用するユーザーの想定される人物像です。

サービス開発を行う際には、要件定義や機能仕様を検討するよりもまず先んじてペルソナを明確に設定することが重要です。

なぜなら、ペルソナによってサービスに求められる機能の種類、質、好まれるUIやUXが全く異なってくるからです。

極端な例でいえば、Webサービスのデザインでベースの色を考える際に、そのターゲットが「ほぼ男性」「ほぼ女性」「大体半々」のどれなのかによって最適なデザインは変わってきますよね?

実際にサービスを利用する人の満足度を最大化するためには、開発前からペルソナをより深く、細かく設定し、それを元に開発していくことが必要不可欠です。

ペルソナとエンジニア

一般的には営業やマーケティングの部門で議論されるペルソナですが、私はこれをエンジニアも考えることに大きな意義があると考えています。

実際にZMS社内であった例をみていきましょう。

以前とあるWebサービスを開発する際に、営業チームと開発チームで意見の食い違いが続いていました。

この原因となっていたのは、ペルソナが不明確なまま要件定義・機能仕様を作り始めてしまったことでした。より正確に言えば、設定されたペルソナの情報が開発チームで正確に把握できていなかったことが原因です。

自社サービス開発でも受託開発でも、エンジニアと呼ばれる人たちのチームでは基本的にまず「要件」を求めます。

どんなことを実現したいのか、どんな風にやりたいのか、制約や特殊な条件はあるのか、などなど、こういったことをまとめて開発すべき機能を定義していくのがエンジニアチームの上流工程で求められる作業です。

しかし、いくら要件がまとまっていたとしても、エンジニアの仕事はそれを実現すればいいだけではありません。

「この機能はどんな立場の人がどんな状況で使うんだろう?」

「この画面にはたくさん機能があるけど、最もよく使われるのはなんだろう?」

こういった疑問に対してエンジニア自身がきちんとペルソナを把握したうえで思考することによって、要件に対して技術的な知見からアドバイスを行うことができ、その結果が質の高い要件や機能の策定、そしてユーザー満足度の高いサービス開発につながります。

また、エンジニアがペルソナを深く把握することのもう一つのメリットとして早期に適切な技術選択ができるということが挙げられます。

要件を実現するための技術要素の選択肢は複数あることがほとんどですが、エンジニアがここからどの技術を採用するか思考する際、ペルソナの設定によって選択すべき技術が異なってくるため、選択のミスによる社内での余計なやり取りや開発後の認識違いによる手戻りなどを軽減することができます。

以上のような理由から、上流工程はもちろん下流工程を担当するエンジニアもペルソナに対する深い理解を持つことで、開発の効率化とサービスの質の向上が達成されると私は考えています。

ペルソナがエンジニアを育てる

もう一点、エンジニアがペルソナを理解することの大きなメリットがあります。

それは、ペルソナについての意識をもって開発に臨むことで、サービスの質が高まるだけでなく、そのエンジニア自身の成長速度が加速するという点です。

ペルソナを深く理解することは、よりユーザーライクな開発を志向することと同義です。

これは開発者の「機能を実現すればなんでもよい」という思考からの脱却を促し、より最適な選択をするための調査や学習といったモチベーションを生むきっかけにもなると考えています。

また、ユーザーライクを志向するための最もいい手段は「実際にサービスを利用すること」です。

追加開発や機能拡張の際には、エンジニアが実際にユーザーとなる時間を増やすことによって課題点や改善点を見出し、その結果ペルソナの設定を修正する。そして新たなペルソナを元に開発を行い、課題解決に向けた学習を行いエンジニアが成長する。

こんなに素晴らしいサイクルはないのではないでしょうか?

ペルソナ思考の注意点

ペルソナを考える上で陥ってしまいがちなミスについて一点だけ注意喚起をしておきます。

ペルソナを深く設定することと、ユーザーの実際の意見を鵜呑みにすることは全くの別物です。

ユーザーライクな開発というと、しばしばユーザーへのヒアリングやアンケート調査などが実施され、それを開発に反映するといった動きを目にします。

これは必ずしも間違いではないと思いますが、そもそもユーザーは自分がほしいものを明確に理解していないし言語化もできません。日によって意見が変わる可能性すらあります。

真のユーザーライクな開発とはそうではなく、徹底的に作りこまれたペルソナとその視点に立って見える課題を元にして開発者自身が「これがユーザーライクだ」と考えて開発することだと私は考えています。

まとめ

ZMSのようなベンチャー企業では、チームごとの意見交換も活発で意思の疎通は非常に取りやすく、今回の記事で例に書いたような食い違いが起こることはそれほど多くはないかもしれません。

しかし、開発するサービスの規模が大きくなったり、組織が拡大して役割が縦割りになっていくと必ず齟齬が発生してきます。

そういった場合に備えるためにも、エンジニアとして働く皆さんはぜひ一度「ペルソナ」について自分なりにその必要性を考えてみてはいかがでしょうか?

コメント

タイトルとURLをコピーしました