1ヶ月間を振り返って人々が気づくこととは | Geppoプロダクトブログ
この記事は8月入ってすぐに書いているのですが、ちょうど蝉が一斉に鳴き始めどこへ行くにも発狂寸前のきはらかのん(@kanon1653)です。
私はカーネギーメロン大学の3年生で電子コンピューター工学を専攻しつつ、本当に美味しいタピオカドリンクを自作しようと日々奮闘しています。
とまあ自己紹介はさておき、私はこの度6月の上旬から8月の上旬まで約2ヶ月間、企業の従業員のコンディション改善ツールである「Geppo」を開発するHCTでエンジニアの卵としてインターンをしていました。
1ヶ月半ほどかけ、起案と開発の行程を踏み、無事に以下の前月振り返り機能をリリースしました。
まだ少数ですがちょこちょこ「前の回答見れるのいいね！」という声を頂いていて、大変ありがたいです…。
今回はこのような声を頂くようになったまでの過程について少しお話します。
0. 発端
Geppoは基本
・3つの設問
・1つのフリーコメント（以下フリコメ）欄
で出来ています。
3つの設問が必須項目なのに対し、フリコメ欄は任意です。
なのでやはり全体の回答率と比べてフリコメの回答率の数字は下がってしまうんですよね。
しかしフリコメは記入者のコンディションをより詳しく伝えるために用意してるという意図があり、フリコメ記入率をあげることは企業のコンディション改善の大きなヒントになります。
なのでフリコメ回答率をあげつつ、かつ回答理由を書いてもらうように促す機能を作ろう、となったわけなのです。
1. 起案
まずどのようにフリコメ回答率をあげるかを考えないといけません。
とりあえず、最初に思ったのがフリコメ欄を必須項目にするということ。
しかし、これが実に安易。
そんなことでいいのならば、1年前にとっくにこの案件は解決してるはずなのです。
というのも、Geppoは本音で答えてもらうということが一番大事なんですね。
フリコメ欄を必須項目にしてしまうと「コメントを絶対に書かないといけない」という義務感に苛まれ、本音を書けないのではないかという懸念があり、ここは任意項目のままでの仕様となりました。
＊＊＊＊＊＊＊＊＊＊
さぁ、どうしよう、となったところで、フリコメ欄には以下の説明文があるということを私は思い出します。
上記回答の理由や、経営や人事に伝えたいこと等あれば自由にご記入ください。
ここの文面を質問調にすれば答えてくれる人が増えるのでは…と思い立ち、
「今月を振り返ってみてどうでしたか？」という文面をある条件を満たした時に追加で出すことになりました。
＊＊＊＊＊＊＊＊＊＊
そんな時、あるユーザーさんの意見で「現状が改善されない限り書きたいことなんて変わらないのだからフリコメをコピペできるようにしてほしい」というのがあったことを思い出しました。
これは確かに一理あると思いました。
前回の回答が見られれば、フリコメのコピペができるようになるだけではなく、その回答と今のコンディションを比較することで一ヶ月分の振り返りをよりしやすくなりますからね。
2. 開発
以下2つの要件が決まりました。
・「今週を振り返ってみてどうでしたか？」という台詞を出す
・過去回答を見れるようにする
なので開発に移っていきます。
2.1 バックエンド開発
さて今回はバックエンドもフロントエンドもどちらも自分で進めました。
まず初対面の言語であるRubyのファイルを開いていきます。
最初は何が何だかさっぱりだったのですが、とりあえず色々なファイルを見て大体の流れを掴みます。
Rubyでの関数の書き方や、変数の使い方などをここで学んでいきます。
見様見真似でモソモソと関数を書き、わからないことがあれば助けてくださいという悲痛な声をあげ先輩方に聞きに行きます。
ある程度ロジックが固まったらテストケースをRSpecで書いていきます。
これまた書き方が独特で最初書いたspecが全部失敗した時はびっくりしました。
兎にも角にもなんとかコードを書き終わり、ほっと一息と思ったところで
「PR出してね」と言われました。人生始めてのPRです。
PR出してまもなくslack上で
「木原さんがPRを出しました。暖かく袋叩きにしてあげてください」
という謎の文面が流れてきました。
そっと閉じてPRにコメントが付くのを待ちます。
しばらくするとPRのコメント欄が埋め尽くされていました。
スクロールしてもスクロールしても最後に辿り着かないよ？バグかな？
と思いつつも最後のコメントまで目を通します。
ロジック的にはほとんど大丈夫だったようで（嬉しい）、スタイルの指摘が多かったように思えます。
やはり複数人でコードを書く場合、スタイルというのは決められたものに沿って書かないと混乱が生じますからね。
コードレビューというものをして頂いたのが人生でほとんど初めてだったので、自分のスタイルの悪い点をきちんと学ぶことができ、大変有り難かったです。
2.2 フロントエンド開発
では次にフロントエンドを触りに行きます。
HTML, CSSは小4ぐらいから触っていたり、私の入ってる学生団体のホームページを作ったりと、そこそこフロントエンド系には自信がありました。
しかし、まさかSCSSとかTypeScriptというこれまた初見のフォーマットが来るとは思いませんでした。
Google先生に色々聞いた後SCSSを触っていると、とても便利ということに気が付きました。
//css
sample {
font-size: 2rem;
}
sample__box {
font-color: red;
}
//scss
sample {
font-size: 2rem;
&__box{
font-color: red;
}
}CSSだと毎回親要素を書かないといけないのに対して
SCSSだと一回書いたらそれの子要素は&で繋げられるので
コード全体が見やすくなるな！という印象です。
TypeScriptはJavaScriptともjQueryとも微妙に色々違って、
なんで動かないの〜！！！って時が多かったです。
Google先生で色々検索してみても「それはJavaScriptなの、TypeScriptなの
どっちなの？」というサンプルコードが多く苦戦しました…。
3. デバッグ作業
コードを書き終わり、PRのコメントも消化した後、自分でもきちんと仕様通り動くか確認した上でリリースブランチにマージしたので「そんなにバグは出ないだろうな」と自信満々でした。
しかしデバッグ作業が始まってすぐ、バグチケットがあがりました。
しかもめちゃくちゃ初歩的な仕様の部分で。
「Windowsで謎の記号があります。Windowsでスクロールが表示されたままです。Windowsで…」
私は根っからのMacっ子なのでバグが起票されるまでWindowsの存在をすっかり忘れていました。
フロントエンドの先輩につきっきりでVirtualBoxの導入をお手伝いしていただき、Windows環境を構築します。
謎の文字化け案件はコード上に見えない何かが入っていたのでそれを消して解決。あれはほんとうに何だったんでしょう、前も同じバグがあったようで不思議です。スクロールの問題もSCSSを編集して解決しました。
ですが、ここでフロント泣かせのIEの登場です。
私のWebエンジニアの友達も「IEってなんで存在するんだろうね」といつも虚ろな目で話しかけてきます。IEは人を狂わせます。
Chrome, Firefox, Safari上だときちんと表示されている文字幅がIEだと総崩れになっていました。どうもフォントサイズぎりぎりでデザインをしていたのが仇になったようです。
「なんでそんなギリギリのデザインにしたんですかね？」という先輩の声が胸に染みます。以後気をつけます…。
しかしなんとか余裕をもってすべてのバグチケットに対応。
無事リリースすることが出来ました。
4. リリース後
1週間程経ったときから、フリコメ回答率をひたすら前月だったり前々月のデータを見比べる日々が続きました。
AWSのRedshift上でSQLをひたすら動かし、データをとってきて、比較して…。
インターンの残り期間が2週間程だったということもあり、完璧なデータが取れたかといえばそうではないのですが、7月分配信日10日後のフリコメ回答率は他の月よりも上回っていました。
5. すべて終わってみて
振り返ってみると「もっと早く仕上げられたのでは…」と思ってしまう自分がいます。実際開発してるときは精一杯だったんですけどね。
コードの微調整をしながら実際にデモサイトをみて、デザイン通りの動きをするか、なんて確認してるとあっという間に2〜3時間経っているという恐怖現象が起きるので。
今回はデザイン上の関係でデスクトップ上のみでの実装でしたが、
反響が良ければスマホのほうにも実装されるのかな…と、ぼんやり思っています。
私はしばらくアメリカに籠もるので、HCT開発の皆様、後は何卒、何卒宜しくお願いします。
おしまい