エンジニア転職8ヶ月目(2019/05)のまとめ

5月はsketchを使ってのワイヤー作成、ユーザーインタビューの準備など、新しい仕事の多い月でした。
入社してから新しい事に挑戦し続けられる環境で大変だけど楽しい~


1. 社内ツール運用

新規開発に時間を使うため、社内ツールはエラー対応が中心となりリリース回数も減りました。

だからこそ、ユーザーから指摘を受けた時は早めに対応する、リリースノートを毎回slackで共有して「まだ進化してますよ!」とアピールすることを意識しています。


 
リリースされて約3ヶ月。運用も以前よりはしっかり行われ、データも集まってきました。しかし、新規プロダクトではここから受け取りたいデータもあるので、既存プロダクトの運用が正常に行われることは今後マストです。
 
5月はあまり触れなかったけど、6月以降はデータ入力など運用面の確認、新プロダクトに対応させる改修などで再び触っていく必要がありそう。


2. toBの新プロダクト開発

4月から始まった新規プロダクト開発。
GWはワイヤーフレーム作成の続きから始まりました。


sketchおもしろい

ワイヤフレーム作成のために会社でsketchのアカウントを貰いました(やったー!)


まだ雰囲気で触っている部分も多いのですが、シンボル化がとにかく楽しくて、シンボル同士を入れ子にしてパーツを作ってみました。
こうすると、一部だけ変えてAパターン、Bパターンのような差分も表現できるのが特に便利。


abstractを使えばgitみたいに状態管理が出来るのも初めて知りました。
使えるツール増えるの嬉しい〜


どの情報を見せるのか?どう見せるのか?

IA(情報設計)の本も読んでみたのですが、実際にやってみると難しさを実感。


GW前にペルソナ、ジャーニーマップを作成して、ユーザーの課題と解決策(課題を解決できる情報)の仮説を立てていたので、まずは必要な情報を画面に置いていきます。

ここでさっそく「情報をどう分類するか?」という問題が出てきました。
情報の種類、使われる時間軸などいくつかの基準で考えましたが、長期間に渡って使用することを前提としたプロダクトであること、時期によって必要な情報を明確に分けられないことから「情報の種類」で分けてみました。


しかし、その分け方だと1画面の情報が多いので、画面中では上→下の時間軸で情報を並べます。さらに時々デザイナーさんにチェックしてもらい、指摘もバンバン貰います。


近接、整列、反復、アクセントの4原則は意識して作ってたのですが、情報のまとまりの弱さ、情報と導線の繋がりの弱さを特に指摘されました。
アドバイスに従って少しボタンの位置を変えたり、カードを使うだけで、情報の意味が変わるのを感じ、デザイナーの凄さを実感しました。


 
また、ある程度ワイヤーが形になった時点でセールスチームに意見を求めて、情報の追加や絞り込みを行いました。
今回のプロダクトはBtoBなので顧客と関わるセールスの意見は外せません。仮説の時点で普段のコミュニケーションの内容に基づいて情報を絞り込めたのはとても良かったです。


セールスチームとの開発は今回が初めてですが、だからこそslackも活用してコミュニケーションを増やそうというのは意識をしています。

ワイヤーフレームの段階で何度も関わってもらえたのは、プロダクトの質の向上とチームメンバーとしての意識を強めてもらう両方の点で意味があったと思います。


 
ユーザーインタビュー準備

ここでもセールスチームの協力を得てユーザーインタビューの機会をいただきました。
 


社内でもユーザーインタビューは初めてになるので本を読んだりデザイナーからアドバイスを貰いながら質問を考えています。
また、インタビューの目的は課題と解決策の仮説検証なので、質問内容を考えつつ、その回答からどのように仮説を検証すべきかもこの段階で一緒に決めました。
 
仮説
ユーザーは○○事業において◯◯という課題を感じている
質問内容
今年度の◯◯事業の中で、困ったり面倒だと感じた体験を教えて下さい。
その際、誰がどのような手順で対応していますか?

仮説検証の方法
ユーザーが面倒に感じた体験の中に◯◯が含まれるか?
 
こんな感じで、検証したい仮説1つずつに対して質問と検証方法をセットにしたメモを作っています。
 
 
一般的なセールストークとは異なり、


- 誘導になる発言をしない(「〜だと思いませんか?」など)
- オープンクエスチョンを増やしてユーザーの発言を増やす
- ユーザーの意見、予想(未来)よりも、事実と体験した感情(過去)を重視する


など気を付けるポイントもあるので、アポや当日のアイスブレイクはセールス担当の方にお願いしますが、質問は主に私が行います。


1件だけインタビューに行ってきたのですが、思うことが色々あったので、この辺りは来月またしっかり書きたい。


3. Nuxt.js

今回のプロダクトはNuxt.jsで作る予定なので、時間を見つけては触っています。
Fluxの考え方は掴めたのですが、まだサンプルになるようなアプリしか作っていないのでmiddlewareも含めたもう少し大きなものを作ってみます。
 


また、参考用に社内でもう一つNuxtで進んでいるプロダクトがあるので少しコードも読んでみました。

レベル差が大きくてまだ全然把握できていないのですが、TypeScriptの書き方や設定周りは今回ぶつかるだろう部分なので参考になるプロダクトがあるのはありがたい...。


 
前回の開発はベース部分はすべて別の人が作っていたので何も考えずにコードを書き始められましたが、今回は設定周りや細かい部分(lintどうしようとか)を考えないといけないので、そこもちょっと不安。


まとめ

先月に引き続き、ユーザーインタビューなど新しいタイプの仕事がどんどん増えています。


挑戦できるチャンスだ!と頭ではポジティブに捉えつつも、ストレスや不安は溜まっていくので、そこを自分で上手にコントロールできるようになりたい。特に最近は仕事で感情的になることもあって反省。
 
また、今回は様々なメンバーが関わるプロダクトだからこそ、常にビジネス面・開発面など広い視点から見て、判断や調整をしていかないといけません。

例えば初回のユーザーインタビューの後、同席していたセールスの人に「インタビューとはいえ、相手の仕事の内容など基本的な質問をされると、『それくらい社内共有しておけ』と思われそうで不安」だと伝えられました。

ユーザーインタビューだから相手の言葉で伝えてもらうことに意味がある、というのはあくまで開発側の意見で、顧客の元に通って信頼関係を築いてきたセールス側の立場や意見もとても大切です。


事前に「基本的な質問をするかもしれませんが、〇〇様のお言葉でご回答をいただくことで分かる点もあるのでご了承ください」と伝えるだけで、相手や同席するセールスの気持ちも大きく変わっただろうな、と反省した点でした。
 


調整を行いつつ仕事を進めるには、相手の物事の考え方や判断基準を知る必要があり、そのためには他チームの仕事内容も更に知っていく必要がありそうです。めちゃめちゃ難しい!!

この記事が気に入ったらサポートをしてみませんか?