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

9/1にリリースが決まったので、8月はエンジン全開です!

弊社は7~9月の好きな時に夏休みが取れるので、夏休みは9月のお楽しみにして、お盆も頑張りました〜

8月にやったこと

1.ロゴ決定

チームのデザイナーがプロダクトのロゴ(シンボルマークとロゴタイプ)を作ってくれました!

ロゴが出来る過程を全く知らなかったので、最初に「このプロダクトの価値はなんですか?」「このプロダクトで達成したいことは何ですか?」とデザイナーにガンガン質問をされて少し驚いたのですが、そこからすぐにプロダクトの目的やイメージに合ったラフ案が出てきて驚きました。

完成までの間には、ラフ案(2回)→形決定→色決めの各過程でデザイナーと話し合いました。

ロゴはパッと見るとただの「図形の組み合わせ」なので意見を言うのがとても難しかったです。最初はどんなコメントを求められているのかすら分からず「これは...どんな事を言えば良いんですか?」としか言えませんでした。

途中からは、複数あるロゴとプロダクトを照らし合わせた時にそれぞれどう感じたかや、自分が良いと思ったロゴを選んだ理由を言語化できたので、デザイナーとのコミュニケーションという観点でも良い練習になったと思います。

フロントエンドエンジニアとして(ロゴに限らず)目に見える形から意味を取れる力は今後UIを作る上でも必要だな〜と感じました。デザイナーの込めた文脈を読んで、コードが書けるエンジニアになりたいな。

最終的には「これぞ〇〇だ」と言えるようなプロダクトにピッタリのロゴができたと思います。個人的には、セロハンのように透け感のある青色がめちゃめちゃ好み。

2.Nuxt.js書くぞ〜(先月に引き続き)

主な機能は先月にできていたので、8月からは細かい調整や追加で必要となる機能を実装していきました

例外処理
APIを叩くアプリケーションを今回初めて作ったので、例外処理を書いたのも初めてでした。今回はVuexを使っているので、store内でエラーが起きた時とVueコンポーネント内でエラーが起きた時両方の処理が必要となります。

かなり悩んだのですが、最終的にはAPIの処理で失敗した場合はstore内のtry/catchでthrow new Errorを行い、そのままVueコンポーネントのcatchに戻してerror({ statusCode: 500 })で画面遷移... という流れにしています。

エラーページそのものはデフォルトで用意されているものをカスタマイズしただけで楽でした。

IE対応
フロントエンドエンジニアを名乗る以上は一度やっておきたかったIE対応。

今まで社内ツールしか作ってなかったので初めてでしたが、皆さんがIEを嫌がるが分かりました...。

polyfilについては今回はpolyfill.ioを使っています。polufill.ioはとても便利ですが、使用しているメソッドの種類によってはpollyfilを再度生成して入れ直す必要があり、今後別のエンジニアと作業する可能性を考えたらbabelに改修かなと思っています。

この段階ではコード量も少ないし一人で作っているのでスピード重視でpolyfill.ioにしてしまいました。

というか、IEはpolyfillよりもsvgの使用やデザイン崩れ対応が大変でした...。ネットに情報はあるので対応できますが、「え？ここ？」みたいな部分でトラブるので見落としが怖い。

3.マニュアル作成

社内ツールのときはドキュメント(esa)の共有で済みましたが、今回はtoB向けのアプリケーションということでマニュアル(紙)も必要です。

紙モノを作るのは初めてだったので、DTPができるデザイナーとスケジュール立てから一緒に行い、章立て→文章作成→割付→デザイン→印刷チェックの手順でマニュアル作成を行いました。

章立てでは、まず全体の構成を決めるためにマニュアルに必要そうな内容を項目ごとに書き出しました。

さらに項目ごとに

タイトル
小見出し（この数で大まかに文章量をイメージ）
図、写真の数
必要ページ数の見積もり
必須項目か?余裕があれば入れたい項目か?

を箇条書きにして、そこからデザイナーに割付(ページの割り振りと配置決め)をしてもらいました。

今回はユーザーがITリテラシーも低めということで、マニュアルの目的を「使い始めることができる」こととしています。

内容も対応ブラウザの確認と導入の説明をメインとしたのですが、ブラウザの説明をするにはOSバージョンの説明も必須になり、思った以上に構成を考えるのが複雑な作業となりました。

「ブラウザ」「OSバージョン」の項目はどの順序で確認したほうが分かりやすいのか?OSバージョンの確認方法は載せるべきか?など、「分かりやすさ」を求めてデザイナーや他のエンジニアも含めて、何度も話し合いをしました。

そのおかげか、リリースしてから導入に関する問い合わせは0で、Google Analyticsを見た限りでもスムーズに使い始められているようです!

4.運用準備(お問合せフォーム&トラブル対応マニュアル作成など)

リリース1ヶ月前ということで、トラブル時の対応準備も進めます。

トラブル時の問い合わせ手段にも電話・メール・問い合わせフォームと種類がありますが、今回は可能な限り問い合わせフォーム(Google form)に集約させるために作業を進めました。

Google formを使ったのは

- 作成が楽
- スプレッドシートと連携させて、シート状に問い合わせ内容を集約することで後から分析が可能
- slackとの連携も簡単

という理由です。

電話やメールではなくGoogle formに誘導するために、アプリ上の「問い合わせ」リンクはすべて問い合わせフォームに遷移させ、マニュアルを見たユーザーが問い合わせフォームのURLを手入力する可能性も考えて、短縮URLを使用しました。

Google form、スプレッドシート、slack、gmailをフル活用して、問い合わせがあった際には

→slack通知&スプレッドシートに問い合わせ内容を転記

→(社内で対応したらスプレッドシートを「対応済みに変更」)

→スプレッドシート編集時にslackで再度通知

の流れを作っています。

Google formにまとめることで、今後問い合わせ内容の分析も簡単にできそうです。

その他にも、電話やメールにCS・セールスが対応することになった時のために、対応フローをドキュメントにまとめ、マニュアルPDFや必要な情報をドキュメントで共有をしています。

ここまで書いていて思いましたが、8月はコードを書く以外の仕事も本当に多かったです。ツールの準備やドキュメント作成など、とにかくサービスを回すことを一番に考えて、必要なことをどんどん実行するのがPdMの役割だな感じました。

5.社内リリース　そして修正

開発がスケジュール通りに進んだこともあり、リリース10日ほど前に社内リリースをすることができました。

しかし、さっそくセールスチームから「表示されている数字が実際の値と違う気がする」というコメントが飛んできて焦りました。確かめたところ、ロジックの間違いに加え、正しい値が出ているものの誤解を招くUIになっていた部分を見つけることができました。

リリース直前にUIも含めた修正となったため多少バタバタとはしましたが、ユーザーにサービスのメリットをしっかりと感じてもらうために直前まで改善ができたのは良かったです。

やはり余裕を持ったスケジュールで進めることが大切ですね。

まとめ

リリース前はマニュアル作成やトラブル対応フロー作成など、普段は起こらない上に細かい作業がたくさんあります。

こういった「誰かの担当ではないけど必須の作業」を探しつつ確実に押さえていくのは地道な作業ですが、このおかげで現在まで致命的なミスはなくサービスが回っています。

私をアサインしてくれた元CTOに「サービスにとってリスクになるものを見つけて潰すのがPdM」「サービスのためなら何でもやれ」と言われましたが、私もこの考えに共感しています。

だからこそ、ドキュメント作成でもエクセルの修正でも、作業の価値を感じながら前向きに取り組んでこれました。

プロダクトがリリースされ一区切りつきましたが、ここまで頑張れたのはチームメンバーの協力と、辛い時にアドバイスをくれたり話を聞いてくれた開発メンバーのおかげです。

しかし、リリースはプロダクトにとっては終わりではなくスタートです。ここからユーザーに「このプロダクトがあって良かった」と感じてもらうためにプロダクトを成長させ続けるのがこれからの私のお仕事です。