「会社に着いたら自動で出勤!?」 Android版人事労務freeeの新機能開発の裏側

人事労務freeeを使う事でペーパーレスの実現とともに効率化出来る図。手作業で必須だった転記などの作業がなくなります。
この図の勤怠の記録の部分の話をしました

Android エンジニアの「yaya」です。
2月16日(火)にて、『freee Tech Night Online #8 「会社に着いたら自動で出勤!?」開発の裏側』を開催しました。

freee Tech Nightは、freee主催のエンジニア向け技術イベントです。

今回は、AndroidエンジニアとQAエンジニアが登壇。 人事労務freeeのAndroidアプリにおいて、位置情報を活用した出退勤の打刻機能を実装しました。そのプロジェクトでの、通常のアプリ開発では味わえない面白いエピソードや苦労話を語ってくれました。

YouTubeでライブ配信をしている登壇者たち
YouTubeでライブ配信をしている登壇者たち

  • yaya:Androidエンジニア:写真右上
    • 2020年4月新卒入社。会計freeeと人事労務freeeのAndroidアプリを開発しています。ミュージカルと旅行が大好き
  • masaki (@mishizuka99):QAエンジニア:写真左上
    • 2014年2月入社。QA(品質管理)としてモバイル・スマート受発注・グロースチームを担当しています。手動テストから自動化まで幅広くやっています。
  • ラジオパーソナリティ:のぶじゃす (@noblejasper):写真右下
    • mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し2017年freee入社。入社後はエンジニア→エンジニア採用担当→エンジニアとDevBrandingを担当。しゃべりたがり。声が大きい

どうして、コロナ禍で「出退勤」機能をリリースしたの?

-「自動出退勤」はどのような機能なのでしょうか?

yaya:人事労務freeeのAndroid版に今年の1月に実装された機能です。勤務先を登録しておけば、出勤と退勤の時間が自動で打刻されるものです。

▶自動打刻の新機能はこちら
www.freee.co.jp

masaki :従業員にとってはわざわざ手動で打刻する手間が省けます。労務の管理者にとっても、打刻漏れやミスが無くなるので管理が効率化されるメリットがあります。

-でも、コロナ禍のリモートワーク全盛の中で、よく出しましたよね。。。

yayaが聞きづらい事を聞かれて苦笑いしています
yayaが聞きづらい事を聞かれて苦笑いしています

yaya:そうなんですよ(笑)。この2月時点では緊急事態宣言下になりますが、一定数の人は出勤していらっしゃいますので、意味はあると思っています!

yaya:あとは、コロナ後の投資の意味合いもありますね。いまリリースしておくことで、コロナが明けたときには、ある程度改善を重ねた状態で使えますので。

-開発の期間はどれくらいでしたか?

yaya:半年くらい掛けて開発しました。位置情報を活用するサービスは、僕としてはほぼ初めてでしたので、順調に行ったとは言いがたいですね。。

masaki:実際に動かしてみてから分かる部分も多かったので。プロトタイプを作ってからの改善の期間の方が長かったです。QAからもたくさんフィードバックしました。

テストでは「不審者」にならないように気をつけました

masakiさんが難しそうな顔をしていますが当日は楽しく話しました
masakiさんが難しそうな顔をしていますが当日は楽しく話しました

-具体的に難しかったことを教えてください。

yaya:勤務地に近づいたことを遅延なく検知することが難しいんですよ。プログラムでリクエストしたタイミングの位置情報を取得するのではないので。あとは、お昼休みで外出するときに打刻されないようにするとか(笑)。その辺りは、アプリの仕様の段階から詰めていきましたね。

masaki:QAとしては、屋外でのテストは初めてでしたので戸惑いましたね。そもそもやっていいのか、法務や労務など勤務的に問題ないかを確認することから始めました。QAチーム6人がそれぞれ端末を持って街をウロチョロしていたのですが、不審者に思われないように気をつけました(笑)。特定のエリアを出たり入ったりしていたので、周りから見ると怪しいじゃないですか。

「山」は、勤務先に設定できるのか?

-それは大変でしたね。。。なかなかそんなテストはしませんもんね。

yaya:あとは、Androidは端末によって挙動が異なるケースが多いので、その修正が大変でした。ただ修正するだけではダメで、実際にもう1回、街に出てテストをしてもらわなくちゃいけないんですよ。今はリモート勤務も多いので、テストに協力してくれる方に、うまく動かない端末を郵送してもらったりしていました。

masaki:そうなんですよ。さらに細かい部分の検証も必要で、「山」を会社に設定できるのか、とか、いろんなメーカーの端末でバッテリーの減り具合を検証したりとか。位置情報を扱う開発者の皆さんの気持ちが分かりました(笑)。ここまで大変なことをやってるんだ。。と。

-リリースから約1ヶ月。どれくらいのユーザーに使っていただいていますか?

yaya:まだリリースしたばかりですから、これからに期待しています(笑)。

のぶじゃす:人事労務freeeを使っていただいている管理者のみなさま、ぜひ、設定をONにしてください。とても便利ですよ!!

▶freee Tech Night 次回は3月23日に

「freee Tech Night Online #9 確定申告を乗り越えるDBパフォーマンス改善」を開催!

freee Tech Night Online #9 確定申告を乗り越えるDBパフォーマンス改善のロゴ画像
多くのエンジニアが頭を悩ませるDBパフォーマンスの話をします

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)

youtu.be

freeeアクセシビリティー・ガイドライン Ver. 202102.0を公開しました

こんにちは、freeeのアクセシビリティーおじさん中根です。久しぶりにPixelシリーズ以外のAndroid端末を入手したのですが、初期状態のホーム画面のアクセシビリティーが悪すぎて泣きそうになりました。Androidはそのあたりも含めてバリエーションが多いのが大変なところでもあり、面白いところでもあるなあと改めて感じました。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。

ホバーで表示されるコンテンツに関するガイドラインの見直し

今回の更新では、ホバーによって表示されるガイドラインと関連するチェック内容の見直しを行いました。

[SHOULD]ホバーで表示されるコンテンツ

[SHOULD]ホバーで表示されるコンテンツについて、以下のすべてを満たす。

  • ポインターを移動させることなく、ホバーで表示されたコンテンツを非表示にできる。(Escキーで消える、など)
  • ポインターを、ホバーで表示されたコンテンツ上に移動しても、コンテンツが消えない。
  • ホバー状態ではなくなった場合、ユーザーが非表示にする操作を行った場合、内容が無効になった場合にのみ、ホバーで表示されたコンテンツを非表示にする。

上記は変更前のガイドラインです。

ホバーで表示されるコンテンツがある場合に、拡大表示を利用しているユーザーのアクセスを阻害しないようにするというのが、このガイドラインの主な意図です。 詳しくは以下に挙げる参考情報を確認してください:

上記の変更前のガイドラインには、3つの条件が示されています。 このうち2番目に挙げられている条件

  • ポインターを、ホバーで表示されたコンテンツ上に移動しても、コンテンツが消えない。

については、乱暴な言い方ですが、読もうとしているコンテンツが読もうとしているその瞬間に非表示になってしまわないことを保証するためのものです。 ですから、これが満たせていない場合は、必要な情報にアクセスできない状況が発生することが考えられます。 他の2つの条件も、満たしていなければ拡大表示を利用している場合にアクセスを阻害することには変わりありませんが、この条件と比べると影響は小さそうです。

これまで、この3つの条件をまとめて優先度を[SHOULD]としてきました。 また、このガイドラインの基になっているWCAG 2.1の達成基準1.4.13も、適合レベルがAAとなっています。

しかし、上述のような理由から、すべてを[SHOULD]として扱うのは適当ではないという判断に至りました。

そこで今回の更新では、このガイドラインを以下のように優先度が異なる2つのガイドラインに分割しました。

  • [MUST] ホバーで表示されるコンテンツの拡大

    [MUST]ホバーで表示されるコンテンツについて、ポインターをホバーで表示されたコンテンツ上に移動しても、コンテンツが消えないようにすることで、そのコンテンツを拡大表示して利用することを可能にする。

  • [SHOULD] ホバーで表示されるコンテンツの非表示

    [SHOULD]ホバーで表示されるコンテンツについて、以下のすべてを満たす。

    • ポインターを移動させることなく、ホバーで表示されたコンテンツを非表示にできる。(Escキーで消える、など)
    • ホバー状態ではなくなった場合、ユーザーが非表示にする操作を行った場合、内容が無効になった場合にのみ、ホバーで表示されたコンテンツを非表示にする。

これに伴い、チェック内容についても見直し、チェックID: 0091チェックID: 0111から[MUST]の条件を分離し、新たにチェックID: 0092チェックID: 0112を追加しました。

その他の変更

他にも、意図の変更を伴わない細かい文言の変更や誤字脱字の修正をしています。

また、このブログでは更新情報を掲載しませんでしたが、1月20日に公開したVer. 202101.1では、ユーザーCSSを適用したチェックの実施方法中のCSSおよびブックマークレットの修正をしています。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

freeeアクセシビリティー・ガイドラインVer. 202101.0を公開しました

こんにちは、freeeのアクセシビリティーおじさん、中根です。今年もこのブログとアクセシビリティー・ガイドラインをよろしくお願いします。

では早速、freeeアクセシビリティー・ガイドラインVer. 202101.0の更新内容を紹介します。

参考情報の更新

と言っても、今回の更新内容は非常に少なく、参考情報を1箇所更新したのみです。(他に誤字の修正はありますが。)

具体的には、Tab/Shift+Tabキーを用いたチェックに、キーボードのみで操作できるコンテンツかどうかを確認する際に活用できるブックマークレットを追加しました。

以下にも掲載したこのブックマークレットを実行すると、マウス・ポインターが消えます。

一部では極悪なブックマークレットと呼ばれているこのブックマークレット、ぜひクリックして何が起きるか試してみてください。(もし元の状態に戻したい場合はページをリロードしてください。)

マウス・ポインターを非表示にするブックマークレット
(リンクになっていない場合は記事本体のURLからお試しください)

これを実行した上で、TabキーやShift+Tabキーでフォーカスを移動し、Enterキーを押下するという方法で目的のリンクを探し、そのリンク先に遷移することができなければ、以下のガイドラインを満たせていないと考えられます:

このような(極悪な)ブックマークレットを作ろうということになった経緯ですが、「キーボードだけで操作できる」ということが実はあまり感覚的に理解されていないのではないか、という話が出たためです。キーボード操作のみでコンテンツを利用できるかどうかということは、日常的にWebアクセシビリティーに取り組んでいる人にとってはあまりにも当たり前のことですが、これまでそういったことに触れる機会がなかった人にとっては、具体的にどういうことなのか、どうなっていれば操作可能なのかといったことが分からないかのかもしれない、そんなことを考えました。

このような、Webアクセシビリティー分野の人たちが当たり前のことのようにとらえているけれど、その他の人にとっては全く当たり前ではないようなことというのは、意外に多いのかもしれないという気がしています。これを読んでくださっている皆さんの中にも、なにか思い当たるものがある方がいらっしゃるかもしれません。(もしそういったものがあれば、ぜひ教えてください。)

今後も、ガイドラインの内容、チェックの内容を本質的に理解する上で参考にできるような情報を追加していく予定です。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

36歳にもなって、自分の学び方を学び直した話

この記事は freee Developers Advent Calendar の 25 日目の記事です。

こんにちは、横路です。 freeeで共同創業者CTOを担当していて、いまは技術戦略や共通基盤チームづくりを主にやってます。

今年は、これまで情熱と根気だけでスキルを身につけてきた1人のおじさんが、子育てなどのライフイベントを経て自分の学びの型を見直した話をします。最近そういえば新しいチャレンジ出来てないなあとか、やりたいけど全然時間がなくて…という人に勇気を届けたい。

自分の学びの型のサビに気づいたきっかけ

今年、コロナで会食が減って浮いた時間の一部を使って、ワインエキスパートの資格をとりました。

f:id:yokoji:20201225120748j:plain
ワインエキスパートの資格認定バッジ

正直言って深く知る前はワインが特別好きというわけではなかったのですが、きっかけは、ワインが好きな知り合いが意味のわからない単語の羅列を本当に楽しそうに話している姿を見たことでした。それはまさに、エンジニアリングを学び始めたての頃に自分が憧れた光景で、懐かしくもあり、いつしか自分が失っていた知の渇望の感覚でした。

今回、ひさびさに自分が全く土地勘のない領域でゼロから体系的に知識を身につけていく過程で、自分の学び方の癖にあらためて気づき、学び方そのものに対する自分の認識をアップデートしていく必要を強く感じたので、備忘録的に残しておきます。

これまでの自分の学びの型

もともと自分は、興味のあることがあると集中的に時間をかけて打ち込むことで、独りで一気に深く学ぶタイプでした。座学は得意だが手を動かすとなると不器用で、実践から学んで身につけるのが苦手。いま思うと、観察が下手なのか、手本を見て絵を描いたり体を動かすことが昔から極端に苦手でした。

また強すぎる自尊心で、出来ない自分と向き合い他人に頼って改善することを意識的に避けてきました。それでも興味を持ったことには効率度外視で時間をかけて取り組み、夢中になってやっていたらいつの間にか出来るようになっていた。それが自分の過去の学習スタイルでした。

いつの間にかコンフォートゾーンに安住し、ゼロから学ぶ機会を失っていた

そして子供が生まれ、自分のために使える時間が減る中で、実はこれまでの自分の学びのセオリーがまったく使えない環境になっていたのですが、そもそも技術も含めて体系的に何かをゼロから学ぶこと自体がほぼなくなってしまっていました。

GREE藤本さんの受け売りですが、ある程度エンジニアリングの経験やスキルがあると、多くの技術的課題を(実際にやっていなくても)抽象的に机上で理解できるようになり、これが続くと実際に自分がやっていたときのいろんな苦労を忘れて、必要以上にものごとが簡単に思えたり、自分ならすぐできるという錯覚に陥ってしまうという現象が、まさに起こっていたという反省もありました。

「RANGE」 という本では、環境が大きく変化するような領域ではむしろ専門的な経験が成長の邪魔をするという説も語られています。そこで、自分の枠組みを外してみるという意味でも全く違う領域のゼロからの学びを取り入れてみることにしました。

短期間で新しくゼロから学ぶのは大変だった

そして土地勘のないゼロからのワイン学習ですが、まずなんといっても座学のボリュームが多い。

f:id:yokoji:20201225120811j:plain
テキストはA4サイズ x 厚さ3cm以上の鈍器

ワインの歴史、作り方から世界中のワイン産地や銘柄、ブドウ品種の特徴まで、こまかく覚えないといけません。これは時間との戦いでした。学習時間を確保して3日坊主にならない工夫をして、日々の学習を自動化する必要がありました。

f:id:yokoji:20201225120754j:plain
見開き2ページだけでもこの圧巻の情報量

いちばん難しかったのは、3日坊主にならないようにすることでした。自分の場合はたまたまワインスクールで級長を任されたので、それが真っ当にコツコツやりきるためのよい牽制になりました。

そしてテイスティングの難しさ。これは経験が如実に出るところで、もともとワインが趣味でなかった自分にとってはなかなかの鬼門でした。外観、香り、味を決まったフォーマットで表現していくのですが、はっきりいって経験値がなさすぎて、どれがどの香りのことを言っているのかよくわからない。プロの表現を聞いて、自分の五感とマッピングしていく作業が必要でした。他人との感覚のズレを認識し、よくずれるところを重点的に繰り返し練習しました。

f:id:yokoji:20201225121631p:plain
テイスティングの用語選択用紙はこんなかんじ

そして今回手に入れた、新しい学びの型

振り返ってみると、今回の一連の学習プロセスで気づいた学びの型(新たな知識体系を効率よく自分にインストールするためのポイント)は、以下のようなことでした。

まず学ぶ目的を言語化する

  • 今回は、ワインエキスパートの資格を半年で取るという明確なゴールがあった

理想と現在地を可視化し、できない自分と徹底的に向き合う

  • 自分よりよいものさしを持っている人に、腹落ちするまでフィードバックをもらえる環境が大事
  • 一問一答テストの点数など定量的なフィードバックはわかりやすいが、テイスティングのように定性的なフィードバックのほうが重要な場面も多い

無理なく学び続けられる環境をつくり、学習を自動化する

  • 自分が続けられる方法はなにか?退路を断つ?誰かに伴走してもらう?

小さな成長実感をこまめに得られるようにマイルストンを置く

  • 成長実感がなくても学び続けられるほど心は強くない

仕事で意識してるはずのことを、プライベートでは意識できてなかった

いま言ったような学びの型って、仕事に当てはめると全部当たり前じゃないか!いつもやってるじゃないか!というかんじですが、プライベートでなにかを学ぶときにここまで意識することって意外とないんじゃないかと思います。少なくともわたしはこれまでなかった気がします。

また、ワインスクールの級長業を通じて、この学びの目的や環境を1人1人カスタマイズするのがいかに大変かも痛感しました(スクールは開発チームと違い、キャリアもビジョンもライフスタイルも全くバラバラなのだ)。 結局のところ、各々が自分の学ぶ環境について自分で考えて自分の舵をとらないと、効果的な学びのサイクルは回らないのです。

山本五十六が「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」と言うのも、この学びのエンジンを積んでいる人が圧倒的に少ないからではないかと思います。具体的なスキル習得のために誰かがこのフルコースを回すサポートをしてあげることもときに必要ですが、それよりも学びのエンジンを積み自分の舵を自分でとるためのメタな学びこそ、できるかぎり若いうちに身につけたいスキルのひとつだなといまは思っています。

3年後の個人的な人生目標とfreeeでの働き方をアラインさせるチャレンジ

この点に関して言うと、freeeでは最近グロースビジョンという取り組みを始めていて、個々人が3年後の人生ビジョンを自ら立て、そこから逆算してfreeeでこの半年間に何に取り組むかをマネージャとすり合わせる機会を設けています。これの意図はまさに、目標設定のスキルを高めて自律的な成長を促し、自分で自分の舵をとれるようになることです。freeeではメンバーの成長が会社の成長を支えるという信念があるから、各人が3年後にfreeeにいるかいないかに関わらず、そこに大きく投資しています。freeeでは新卒に3年でCTOになれと伝えているが、この学びのエンジンはマストだと思っています。

卓越への憧れと科学的アプローチ

また余談ですが、言語化しきれない定性的なゴールを追いかけて高みを目指す人たちが、どうやったら再現性をもって学び卓越の境地に到達できるのか?は、ライフワークとして今後も追いかけたい興味深いサブテーマだと思いました。エンジニアの文脈でいうと、3年もやれば多くの人はチームでWeb開発を出来るようになる中で、例えばfreeeのように100万人以上が使うサービスのコアアーキテクチャを考える場面では、トップエンジニアと働いていると明らかに技術的なセンスの差を感じる瞬間があります。なぜ見えている世界が違うのか?どうすれば一歩抜けた世界が見られるようになるのか?freeeで働いているエンジニアたちには、その世界を再現性を持って見られるようにしたいと思います。

前掲の 「RANGE」 では、まずさまざまな領域の課題に広く取り組んでから自分にフィットした領域を見つけて専門特化していくのが、卓越する鍵だと述べられています。また、「超一流になるのは才能か努力か?」という本では、卓越した技能を持つ専門家による「心的イメージ」をいかに理解して他人に伝え、再現性を持ってマスターしてもらうか?という方法論について、科学的なアプローチで挑んでいます。来年からfreeeでは、研究室制度と銘打って師弟スタイルのエンジニア育成施策にもチャレンジする予定なので、そこでいろいろトライしてみようと思っています。

おわりに

今回は、ひさしぶりにゼロから体系的な学習をしたついでに、自分の学び方をアップデートした話をしました。CTOとして技術的な意思決定の精度を高めるため、そしてfreeeをトップエンジニア輩出企業にするために、今後も学びの型をブラッシュアップしていく所存です。