人事労務freeeが緑色になるまで

こんにちは、id:ymrl です。最近は昼間はfreeeでエンジニアを、夜はクマサン商会で漁業をしています。

先日、これまで「給与計算freee」だった製品をリニューアルし、「人事労務freee」としてリリースしました。リニューアルに伴っていくつか機能を追加したのでそちらの紹介もしたいのですが、今回は製品のロゴやUIの色も大きく変更した話をします。

f:id:ymrl:20170802192806p:plain
人事労務freeeのロゴ

広い視野で人事労務の業務をサポートできるサービスへ

人事労務freeeの前身である給与計算freeeは、元々freeeがクラウド会計ソフトで創業した会社だったこともあって、給与額や、そこから控除される税金や保険料など、お金の計算をメインとしてスタートしました。スモールビジネスの現場で人事労務を担当する方々にとって、どんな業務が大変で、何をするとより効率的に業務をしていけるようになるかを調べたり考えたりするうちに、お金の計算にこだわらずもっと広い視野で人事労務の業務をサポートできる機能を作っていくべきだという考えに至りました。

そこでサービスの名称を「人事労務freee」に変更することになりました。

給与計算freeeのベータ版をリリースしたのは3年前の5月ですが、このときは先行するサービスである会計freeeにあったものを「給与計算」に書き換えてそのまま使っていたような感じでした。それから3年のあいだに数多くの進化を遂げてきましたが、「会計freeeと同じようなロゴとUI」という状態はずっとそのままでした。

リニューアル以前の給与計算freee

おかげさまで給与計算freeeは、この3年間で当初では想像できないほど多くの事業所に導入していただくことができました。しかしそれでも、会計freeeの知名度には遠く及ばず、なかなか「freeeは会計だけでなく、給与計算もやっている」と認識していただくことができていませんでした。そこで、今回のリニューアルを機に、会計freeeではないfreeeのもう一つのサービスとして人事労務freeeを知っていただくために、製品のロゴやUIの色合いも変更することにしました。

ロゴの色を決める

f:id:ymrl:20170803123453p:plain
検討の場にあった色たち

リニューアルにあたって、リリースに先行して3月に名称とコンセプトの発表を行う予定であったために、最初はとにかくロゴの色を優先的に決める作業が必要となりました。緑に限らずさまざまな色を検討したのですが、「会計freeeのロゴと並べたときに違和感がない ようにしつつ 会計freeeとの違いがハッキリとわかる」という条件から最終的に 緑色 が選ばれました。

f:id:ymrl:20170802195304p:plain
人事労務freeeと会計freeeのロゴ

4月には77歳の新入社員!?加藤一二三 人事労務への挑戦というサイトを公開したのですが、ここでも新しいロゴと色が使われています。

www.freee.co.jp

人事労務freeeが緑色になることから、このリニューアル作業は「緑化」と呼ばれるようになりました。

UIも緑に

サービスのUIについても、新しいロゴにあわせて違和感のないようにしたかったため、UI全体の色合いを変更しました。ロゴの緑色と調和しつつも、これまでのUIに親しんできたユーザーの方々や、会計freeeを使っていた人がこれから人事労務freeeも使い始めるという時に、使い方の面で戸惑ったりすることのないようにしなければなりません。これまでの給与計算freeeとも、freeeの他のサービスとも、地続きになっているUIデザインにする必要がありました。

リニューアル後の人事労務freee

ここでは、ロゴの色である #006939 に加えて #10B56C という少し明るい緑色も使い、それらの色を既存のUIのおもに青系の色が使用されている場所にあてはめていきました。

これらの多くは社内でサービスを横断して使用しているスタイルシートに使用されているため、ひとまずこれらを上書きする形で実現しました。freeeのサービスではほぼすべてのスタイルシートにSCSSを使用しているため、「共通のスタイルシートを @import した上で色を変えるスタイルを指定する」というやり方をとっています。

/* button.scss */
@import 'common_components/button'; /* サービス共通のスタイルが指定されているファイル。青い。*/
.button { /* 上記のファイルの内容を上書きして緑にする */
  background: #006939;
  border-color: #006939;
}
.button:hover {
  background: lighten(#006939, 10%);
  border-color: lighten(#006939, 10%);
}

SCSSファイルの構造を工夫すれば、スタイルの上書きをすることなく、CSSのビルド時に指定したカラーパレットを使うようにすることもできそうな気もしますが、今回は開発スピードを重視してこの方法をとっています。

ドッグフーディングする

これまでの長い間、「freeeのサービスは青っぽい画面」というのが常識だと思って開発をしてきたわけですが、そのおかげで大きく色を変えるのは開発者としては勇気が必要でした。ある日突然UIの色が変わって、そのことで使用感に大きな影響がでてしまうのは避けたい気持ちがありました。

また、製品のヘルプページに掲載しているスクリーンショットを変更する準備をしたり、セールス活動やマーケティング活動に使用する資料を作るためにも、社内にリニューアル後の状態のプレビューを展開しておいたほうが良いだろう、と考えました。

そこで、せっかく自社の給与計算もfreeeのサービスでドッグフーディングしていることを利用して、社内の全従業員の目を使ってあたらしいUIに問題がないかを確認してもらうことにしました。

f:id:ymrl:20170802201547p:plain
人事労務freeeの給与明細画面。freeeの従業員は毎月ここで給与明細を確認できます。

確認も普段の操作と同じやり方でできるよう、社内の従業員がログインしたときだけ新しいUIが表示されるようにしていました。普通ならば別のURLを用意してそちらにアクセスしてくださいとお願いをしたりするところだとは思うのですが、確認のために身構える必要があるよりも、普段と同じように気軽に見てもらえるほうが社内の協力を得やすいだろうというのが理由です。

せっかくならこのプレビューの公開を楽しいイベントにしてしまおうということで、社内プレビュー公開の目標日を 給料日の前日 として、新しくリニューアルした画面で給与明細を確認してみよう というキャンペーンにしてみました。当日はメールやSlackで呼びかけて、とにかく新しいUIに触れてみましょうというアピールをしました。

f:id:ymrl:20170802192538p:plain
Slackで宣伝する様子

おおきく色が変わったこと対してブーイングがないか心配でしたが、やってみた結果としてはとても好評で、社内で最も多く寄せられた意見は「目に優しそう」でした。

おわりに

そういうわけで、今回のリニューアルでいろいろなところの色を変えた話をご紹介しました。これまで青系の色で作るものだと思いこんでいたサービスのUIを、いきなり別の色にしてしまうというのは新しい試みで、先述したSCSSファイルの構造以外にも、webpackのcss-loaderによるスタイルシート入りの共通コンポーネントではどうするべきなのかなど、いろいろな課題が残っています。これらの課題も少しずつ解決していこうと思っています。

freeeでは色彩やCSSやSplatoonに造詣の深いエンジニア・デザイナーを募集しています。興味のある方はよろしくお願いします。

jobs.freee.co.jp

新卒プロダクトマネージャーが苦労した3つのポイント

こんにちは、タケノコプロダクトマネージャー*1のktaroです。

先日、「freeeのPMチームと語る、本当に泥臭い現場でのプロダクトマネジメント談話会」というイベントを開催しました。私を含む弊社の3名のプロダクトマネージャー(以下「PM」)(執行役員PM、エンジニア兼務PM、若手PM)が、PMのリアルな苦悩とその乗り越え方について共有させて頂きました。今回は、その中で若手PMの私がお話しした、非常にチャレンジングな体験についてご紹介させて頂きます。

突然ですが、下記の自己紹介スライド*2にてびっくりされるような事実が1点ありますが、お気づきでしょうか?

f:id:noraemon10:20170726173910p:plain

正解は、入社1.5ヶ月目の新卒*3がPMに就任していることです。PMというロールは、その担当するプロダクトにおいて最大の責任を持つロールであり、PMの実力がプロダクトの生死を左右すると言っても過言ではありません。そんなロールに新卒を就かせるという決断を、よく弊社はしたなと自分でも思いますが、実際にチャレンジングながらも非常に有益な体験をすることができました。

丸裸でエベレストを登るようなもの

まず、なぜチャレンジングであったかというと、下記3つの能力についてゼロスタートであったからと言えます:

  • ベーススキル:会議ファシリテーション力、資料作成力、プレゼンテーション力、プロジェクトマネジメント力等
  • ドメイン理解:プロダクトが解決する課題の分野に関する深い理解。弊社の場合は中小企業のバックオフィス業務
  • PMスキル:ビジョンや戦略を作る力や、人を動かす力等

この状態でPM業をやるということは、登山初心者が丸裸でエベレストを登るようなものです。この人が当然ながら最速でエベレストを登ることができないように、ベストなプロダクト戦略を導き出すことは非常に困難です。

突然訪れた機会

そして、なぜこのような機会を得たかというと、下記3つの条件が偶然にも重なったためです:

  • 前任の方が起業し、freeeを卒業したため、空きポストができた
  • プロダクトがまだインキュベーションフェーズにあり、事業としての価値は限定的であった
  • 弊社内にプロダクトマネージャーはまだ少なく、今後増員するにあたり、育成の知見を溜める必要があった

以前からPM職に強い興味があった私にとっては、この上ないチャンスでした。

四半期開発プラン作りで四苦八苦

実際に、どれだけチャレンジングであったかを具体的なタスクを例に、上述のゼロスタート3点セットに沿って(赤裸々に)ご説明します。それは、次の四半期の開発プランを作るというタスクです。つまり、今どういったユーザーさんのどの課題を解くべきかを決め、社内の意思決定者が納得できるストーリーを作り上げ、それに沿って具体的に開発する機能と順序を3ヶ月分決めるというタスクです。

まず、このタスクを遂行する上で、ベーススキルがゼロであったために下記の様な単純な失敗をしました:

  • 関数の対象セルがズレていて開発工数の計算を間違う
  • 資料がごちゃごちゃしていて見にくい
  • 議論のファシリテーションが出来なく、真剣に心配される
  • 大人数を呼んだミーティングでグダグダしてリソースを無駄にする
  • スケジュールやタスク管理ができておらず、締め切りを過ぎてしまう

次に、ドメインの理解がゼロであったために、下記の様なことが分からず苦労しました:

  • 労務管理(給与計算freeeが対象とする分野)って何!?何が大変なの!?
  • みんな労務管理をどうやってるの?給与計算freeeを使うと何が違うの?
  • 複数の給与締日支払日設定って何で必要なの?
  • 今、給与計算freeeでは何ができて、何ができないの?
  • 労務手続きってどんなのがあるの?

そして最後に、PMスキルがゼロであったために、下記の様なことが分からず苦労しました:

  • 皆が納得するストーリーってどうやって作るの?
  • 優先度ってどうやって決めるの?AとBの機能で、どっちの方が優先度高いの?
  • 事業的にインパクトが大きいのはどのストーリー?
  • 市場は今どんな状況なの?競合の動向は?

結果として、四苦八苦しながら、いろいろの方に助けられながら、何とか開発プランを作ることができました。そして、一度この課題を乗り越えたからこそ、今の自分であれば、より短期間でより優れたものを作れる自信があります。その理由は次にご説明します。

ロールモデル登場

6ヶ月間エベレストを登り続けた後、担当プロダクトの事業的な重要性が急速にあがりました(参考プレスリリース:freee がHR事業の軸となる新サービス「人事労務 freee」を発表。人事労務に関する業務をクラウド上一気通貫で対応しHRtechを推進)。そういったこともあり、よりシニアなPMがアサインされ、私はそのPMと一緒に働くことになりました。

実は、一緒に働き始めた最初の3ヶ月間が、自分自身が最も成長できた期間であったと思います。なぜなら、そのPMは、自分が四苦八苦していたPM業の理想的な熟し方を体現していたからです。自分にとっては答え合わせのように、そのPMと自分とのギャップを目の当たりにし、自分が目指すべき姿を理解することができました。すなわち、エベレストを登頂できる人が一体どの様な人なのかを理解していないまま登るのと、具体的なイメージを持って登るのとでは、圧倒的に成長スピードが違うということではないでしょうか。一度頂上を見ずに、最初からアシスタントとして働いていたら、同じような成長は遂げられなかったと思います。

最後に

非常にチャレンジングな機会を頂いた中で、目指すべき姿を正確に理解できたことが一番の収穫であったと言えます。やはり新卒はずっと下から見上げることが多いので、中々頂上のイメージが付きづらいです。そのため、新卒には少しの間でも頂上を体験させ、合わせてロールモデルを見せてあげることで、圧倒的に早く成長するのではないでしょうか。PMに限らず、新卒を育成する機会がある方は、ぜひ試してみてください。

freeeでは大きな山にチャレンジするPMを募集しています。若手からベテランの方まで、幅広く仲間を探しておりますので、ご興味あればぜひご連絡ください(こちらより)。

*1:タケノコプロダクトマネージャー:プロダクトマネージャー(以下「PM」)の下で修行を行う者。一般的には、アシスタントPMやアソシエイトPMとも呼ぶ。筍のように早く、強く、しなやかに成長する期待の意味が込められている。

*2:イベントで使用したスライド資料は、かなり攻めた内容や表現になっておりますので(”泥臭さ”を重視したため)、公開は控えさせていただきます。

*3:実は正確には出戻り第二新卒です。freeeでインターンを経験した後、新卒で外資システム系企業に入社し、半年でfreeeに戻ってきた経緯があります。ただし、PMとはかけ離れた仕事内容でした。

Azure Machine Learningが便利なことを布教したい

おはようございます。 スモールビジネスAIラボ 研究員のKenji Usuiです。

クラウド機械学習流行りですね。かく言う私も最近使い始めたらその便利さにハマってしまいました。
ここではメインで使っているAzure Machine Learning(以下Azure ML)の良さについて語っていきます。

Azure Machine Learningのここがよい

私がメインで使っているクラウド機械学習ツールはAzure MLです。なぜAzure MLを選んだかというとザックリ次の3点が大きな理由になります。

  1. GUIが使いやすい and わかりやすい
  2. 簡単にWebサービスとしてデプロイできる
  3. SQLやPythonも使える

それぞれ詳細を説明していきます。

1. GUIが使いやすい and わかりやすい

モデル構築は試行錯誤の繰り返しなのでサクサク変えていけると楽です。
その点ではGUIは非常に便利でAzure MLはGUI上でユニットを変えるだけで処理を変更することができます。後で見返してもわかりやすいのも良いですね。加えてテスト結果を可視化してくれます。これが見やすくてカッコイイのでそのままドキュメントに使えます。
便利ですね。 f:id:Grahamian:20170726145935p:plain

2. 簡単にWebサービスとしてデプロイできる

Azure MLは学習したモデルを5分でwebサービス化できます。しかもスケーラブル。
学習のために設計した状態からほぼ自動でwebサービスへ変換することができます。
f:id:Grahamian:20170726154043p:plain 学習器を使うためにコードを書く必要もありません。普通だとwebサービス化やその保守に手間がかかってしまいますが、これを圧倒的に短縮できます。
呼び出しもREST APIなので簡便でJSONを渡すかcsvを渡してバッチ処理できます。
便利ですね。

3. SQLやPythonも使える

前処理をちまちまと変更しながらテストしたいことは多々あると思うのですが、これもクラウドで完結できます。
Azure MLはデータをSQLで抽出したりPythonで簡単な処理を追加したりできます。またPythonのライブラリとしてAnacondaが用意されています。これを使って大概の処理はできるためローカルと変わらない処理をクラウド上で完結することができます。地味ですがこの機能のおかげて痒いとこに手が届きます。
便利ですね。

Azure Machine Learningのここが気になる

機械学習アルゴリズム自体を変更できない自由度の低さは悪い点かもしれません。
f:id:Grahamian:20170726151407p:plain
↑こんな感じにAzure ML上ではパラメータチューニングはできますがアルゴリズムの変更はできません。Neural Networkもhidden layerの数やnodeの数を変更することはできますが複雑な変更はできません。「既存のアルゴリズムを改修したい!」「新しい論文のアルゴリズムを実装したい!」というのはほぼ無理です。
これはAzure MLがコモディティ化した技術を簡単に扱えるようにするツールなので方向性が違うのだろうな、と思います。Deep Learningをガッツリ活用するならAzure MLではなくコードを書いてスクラッチするか、用途に合うものが有るならばGoogleの学習済みAPIを使うのが良いと思います。
加えてUIがモッサリすることがちょっと気になりました。そのため前処理のテストなど「処理は軽いけどトライ&エラーが多い」みたいなケースはローカルで処理するほうが早いことがあります。

Azure Machine Learningはいいぞ

Azure MLを用いることで多くのビジネス課題の解決やプロダクトへの応用が手軽かつ高速に行えます。
最先端の機械学習技術を用いたプロダクトには向きませんが、多くのビジネス課題やデータ分類にはAzure ML上のアルゴリズムで十分です。機械学習のコモディティ化がよく話題になりますがAzure MLはそれを具現化したツールだと感じます。
エンジニアリングで効率化のためにツールを活用しているように、AIラボでは機械学習の場面でも最新のツールをガンガン活用していきます!

GYOMU Hackers Night vol.2をセールスフォース・ドットコム様のオフィスで開催しました

どうも、こんにちは。freeeでGYOMUハックという社内の業務改善系エンジニアをしている廣野です。

4月にfreeeとビズリーチさんで協力して、業務改善系エンジニアを集めたGYOMU Hackers Guildというコミュニティーを立ち上げました。経緯としては、社内に閉じがちになってしまう社内向けシステムを触るエンジニアが、同じような悩みを抱えているのではないかと考え、それを相談して、さらなる高みに行けるような集まりができればいいなと考えたことがきっかけでした。

そして先日、セールスフォース・ドットコム様のオフィスをお借りして、GYOMU Hackers Night vol.2を開催したので、その様子を紹介します。

peatix.com

Lightning Talk

LTは株式会社LIFULL・藤原裕也さんとランサーズ株式会社・土屋雅彰さんに発表していただきました。 LIFULL藤原さんは、Salesforceと業務システムを連携した業務改善の事例、ランサーズ土屋さんはコミュニケーションツールとSalesforceを連携したコミュニケーションの改善の事例を発表してくださいました。 とても参考になる内容でした!

f:id:mirygoaround:20170627201344p:plain

発表資料については、GYOMU Hackers GuildのFacebookページで公開されているのでぜひご覧ください。

パネルトーク

vol1のときは、テーブルトークがメインでしたが、今回は趣向を変えてコミュニケーションをテーマにしてビジネスチーム側、エンジニアチーム側にわかれてのパネルトークを行いました。

ファシリテーターはコードキャンプ株式会社・矢野目佳太さん(写真一番右)、 ビジネスチーム側パネリストは株式会社ビズリーチ・白石剛爾さん、freee株式会社・坪井亜美、エンジニアチーム側パネリストは株式会社ビズリーチ・田中聡さん、freee株式会社・廣野美里、でした。(写真の左から名前順) f:id:mirygoaround:20170627141846p:plain

パネルトークではビジネスチーム側とエンジニアチーム側の感じ方の違いと歩み寄り方について、盛り上がりました。

ここが変だよエンジニアチーム

1.要件の持ち込み

坪井:エンジニアとビジネスサイドでは時間間隔が違う。ビジネスサイドでは明日から効果測定したいのに数週間かかると言われてしまう。そのスピード感では次の施策が決められない。

白石:エンジニアからそもそもそんなことはできないと言われることもある。ビジネスサイドの説明が足りていないのは自覚しているが、汲み取って欲しい。

坪井:ビジネスサイドで内容を6割くらい考えて持っていっても、エンジニアから要件がわからないと撥ねられる。

田中:エンジニアとしては、依頼されたその数字が見えることでどうなるのかが分からない。可視化した先が知りたい。

廣野:エンジニアサイドからするとシステム要件よりも何をやりたいのか言って欲しい。毎回依頼が来るたびにビジネスサイドにヒアリングすることになる。

坪井:スピード感が大事だからと、ビジネスサイドでやりたいことでできることを全部やってたら、Salesforceが散らかってしまった。

廣野:そして余計に闇が広がるんだよね……笑。

2.ビジネスサイドとのコミュニケーション

廣野:ビジネスサイドからの依頼はJIRAで来るが、文字のコミュニケーションが辛い。依頼をもらった時点で対面でのコミュニケーションをしに行く。

田中:自分も同様。文字では相手の感情が分からない

3.エンジニアからの歩み寄り

田中:エンジニア的にスピード感が必要だと感じたら、PDCAサイクルを回すために一旦要件の曖昧さは度外視する。 →実装/運用後にビジネスサイドからフィードバックをもらい、目的がずれていないことを確認している。

4.具体性が分からない要件への対応について

白石:相談という形で、一旦エンジニアサイドに話を聞いている。話を聞いてくれ、対応案を出してくれるので助かっている。

廣野:エンジニアとしても要件がふわっとしているなら、具体的な依頼ではなく相談なのだと伝えてくれると嬉しい。

田中:エンジニアもビジネスサイドの情報を常に収集し、先にビジネスサイドに働きかけるようにしている。

ここが変だよビジネスチーム

1.施策の実行について

廣野:ビジネスサイドは短期間にたくさんの施策が実施されては無くなっていくのでそのスピードについていくのが大変。それに、それぞれのステークホルダーが分からない。

坪井:数が多すぎて、ビジネスサイドもよく分かっていない。

廣野:組織全体として、うまいやり方をするために体制から考える必要もあると思う。

コミュニケーションをより良くするために……

白石:ビジネスサイドとしてはコミュニケーションとリソースの調整が大事。役割とスケジュールをはっきりさせる。分からないことは積極的にコミュニケーションを取って溝を解消していく。

坪井:エンジニアに完璧を求めすぎない。ビジネスサイドもSalesforceが使えることが一種の営業スキルだという想いで自ら学ぶことも怠らない。

廣野:ビジネスサイドから相談が来た場合は、他にも同様の件で困っている人がいるのではないかと意識しながらフォローに入る。

田中:使うのはあくまでもビジネスサイドのメンバー。使っているビジネスサイドの業務フローや各場面での使われ方を知っておく。

ー結論ー:ビジネスサイドとエンジニアサイドがそれぞれ歩み寄ることが大事!!

Q&A

Q:YES/NOしか答えてくれないエンジニアにはどうコミュニケ―ションを取れば良いか?

A:廣野:かつてリソース面で対応ができなかった場面があった。自分はYES/NOだけでは答えないよう心がけている。なんでNOなのか、なんでYESなのかの理由もセットで聞くと良いのではないか。

  田中:ミスを恐れて、確実に対応できるものでないとYESと言いづらいのかもしれない。その方の上司も巻き込んでコミュニケーションを図ることが良いかもしれない。

こんなかんじで、かなり盛り上がったパネルトークとなりました。

テーブルトーク

そのままの流れでコミュニケーションをテーマにしたテーブルトークを実施。ものすごく盛り上がっていて、真剣に話されていました。同じ悩みを抱える方は多いみたいでした。

次回

次回のGYOMU Hackers Night vol.3は8/23にビズリーチさんのオフィスで行います! ご興味のある方はぜひご参加ください!!!

詳細はGYOMU Hackers GuildのFacebookページにてご連絡いたします。