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

こんにちは、freeeのアクセシビリティーおじさんというよりガイドラインおじさんになりつつある中根です。 相変わらずfreeeアクセシビリティー・ガイドラインと戯れる日々を過ごしています。

今回は、6月18日にリリースしたfreeeアクセシビリティー・ガイドライン Ver. 202006.0の更新内容を紹介します。

# CDNのキャッシュ更新のタイミングの関係で、ページによって旧版が表示されるかもしれませんが、その場合は時間をおいてアクセスしてみてください。

a11y-guidelines.freee.co.jp

今回は主に各ガイドラインの構成変更

これまでは、各ガイドラインの優先度と本文のリストを作って、アコーディオンでその他の情報を隠す形にしていました。 しかし、複数のガイドラインを1つのulに入れる構造はどうにも扱いづらいということもあり、またGitHub Issuesでもご指摘いただいたように、表示上も問題があるということで、この構造を見直しました。

今回の変更では、まず各ガイドラインに短い見出しを付けました。 こうすることで、個別のガイドラインを参照する場合もやりやすくなるという利点もありますし、スクリーン・リーダーで読んで行くのも楽になったと思います。

そして、ガイドライン本文とチェック内容を記述し、その他の項目をアコーディオンに入れました。 ガイドラインを使い慣れた人の場合、ガイドライン本文とチェック内容だけを確認するという使い方になるのではないかという想定に基づく変更です。

また、チェック内容については、チェック内容とチェック対象う対にして表記するようにしました。 これは、現在進めているチェック内容の改善へ向けた検討の中で、チェック対象によってチェック内容が異なる場合も少なからずありそうだという話になったことを受けてのことです。

チェック内容の変更については、次回以降のリリースで反映する予定です。

その他の変更

前述の通り、現在チェック内容の見直しを進めていますが、同時にガイドラインそのものについても見直しをしています。 これまでガイドライン策定に直接的に関わっていなかった社内の人たちからの意見も反映して、より分かりやすいものになるように改善を進めています。

現時点では、マークアップ全般ページ全体について、検討結果を反映しています。 全体的に表現を見直し、加筆していますので確認してみてください。

また、このエントリーで触れていない変更については、リリース・ノートで確認してみてください。

なお、Ver. 202005.0を紹介したエントリーで予告した、「表記揺れの解消」ですが、実はVer. 202005.1というリリースで対応済みです。

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

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

採用管理システム(ATS)を半年で社外サービスから内製システムに移行した

こんにちは、freeeでDevBrandingをやっていたり採用管理システムを開発している @noblejasper です。

今回は前回のDevBrandingの話ではなく、私の主な業務の話を書きたいと思います。 現在私は社内向けの採用管理システムの開発を行っています。昨年の9月から半年で、既存システムから新規開発した内製システムに移行出来ました。経緯や良かった事などを振り返ろうと思います。
採用など業務を改善していかないといけない場面に立ち向かっている方々の参考に少しでもなれればいいなと思います。

そもそもATS(Applicant Tracking System)とは?

まず採用管理システムとは何かを簡単に説明します。

日本語では「採用管理システム」と呼ばれる事が多いです。企業の採用活動を支援するシステムです。
採用活動ではいくつかのデータを紐付けて管理する必要があります。

  • 求人
  • 候補者
  • 面接官
  • 面接官の評価
  • 選考状況

これらのデータを用いて、採用活動を可視化し効率化や精度向上をするためのシステムです。(他社様からサービスとして提供されているものの中には、この範囲におさまらないものも多くあります。)

実際にfreeeで内製している採用管理システムのスクリーンショット
実際にfreeeで内製している採用管理システム(デモデータ)

経緯

ATS(Applicant Tracking System、採用管理システムといわれるもの)を作る事になった経緯から振り返っていきます。

① エンジニア→採用担当者→採用管理システム開発者

私は採用管理システムを開発する前は採用チームでエンジニアの採用担当者でした。
入社した当時はWebアプリケーションのエンジニアでしたが、今では採用チームにいた期間の方がfreeeでの在籍期間の中で長くなりました。

② 採用担当者xエンジニアのキャリア

リクルーターをしている間も、簡単な自動化や効率化、見える化を行っていたりしていました。 場当たり的にツギハギに解決策を作ったりしていましたが、「抜本的に解決したい」という課題感を持っていました。

とはいえ、本業はリクルーターなので改善活動に割ける時間はかなり限られたものでした。

③ 既存システムの契約更新とSalesforce開発のノウハウ

数年利用していた既存システムの契約の更新の期限がが近づいてきており、違うサービスはどうかという検討が出てきていました。
社内にSalesforceを用いた開発のノウハウがあるプロフェッショナルなチームがいた事、満たしたい要求はSalesforce上で実現出来そうだという事で「Salesforceで開発やってみよう」という事になりました。

④ 採用管理システムの開発者に

リクルーターの経験と、エンジニアの経験をもっているということで、私が開発担当者になりました。私としても適任だと感じていたし、解決したい抜本的解決が実現出来るかもしれないとワクワクしていたのを覚えています。

今考えてみると、エンジニア→リクルーターに異動したのは「採用管理システムを作るための布石だったのではないか」という大いなる意思のようなものを感じています。(おそらくリクルーター異動時にはそこまでの意図はなかったのではないかと思っています)

おおまかな移行へのスケジュール

今回は半年で既存システムからの移行を完了出来ました。
9月に開発を開始してから2月の完全移行、3月の既存システムの廃止へのスケジュールをおおまかにまとめてみました。

  • 2019年09月 キックオフ
  • 2019年10月 段階的な移行開始
  • 2019年11月 全面接官の評価入力の移行開始
  • 2019年12月 隔週でミーティング開始(情報共有、Q&A、フィードバックが目的)
  • 2019年01月 2月完全移行に向けてラストスパート、採用情報サイトの応募フォームの開発&リリース
  • 2019年02月 3月の既存システム廃止に向けた必須機能の開発&リリース
  • 2019年03月 既存システムの廃止、データエクスポート&インポート

実際に採用チーム以外の社内のメンバーに認知され始めたのは11月の「全面接官の評価入力の移行開始」からです。既存システムから新システムへ移行していく中で、実際に面接をする面接官が評価などを入力する部分も段階的に移行していく必要がありました。

はじめに社内の選考に関わる全メンバーに説明会を3回に分けて実施しました。freeeでは選考に関わる人数が100人を越えるのでどんなフィードバックがあるかドキドキしながら実施しました。
面接、面談時の入力の方法や、候補者の情報の確認方法。社内で問い合わせする方法などを共有しました。この説明会でもらったフィードバックから出来た機能や改善があったり、説明会内で出た問題点の代替策をその場で相談できたりなど、とても有意義な会でした。

比較対象となるプロジェクトがないのですが、個人的には開発、導入、移行までスピーディーに進められたと感じています 順調に進められた大きな要因が2つありました。

① Salesforce 開発の知見があった

上述しましたが、freeeにはGYOMUハックチームという、Salesforce開発のプロフェッショナル集団がいます。 GYOMUハックチームと協力して開発を進められた事がかなりのスピードアップに繋がったのは明らかでした。

developers.freee.co.jp

  • 初期ラーニングのコストがかなり低かった
    • ちなみに私はこの開発をするまでSalesforceにはほぼ触れた事すらありませんでした
    • 開発開始から基礎部分の開発、移行開始まで1ヶ月で出来ている
    • 作りたいものに対して、インプットしておく必要のあるリファレンスを教えてもらえた
  • Salesforceにおけるバッドプラクティスやアンチパターンを指摘してもらえた

② 採用チーム一丸となって取り組めた

実際にシステムを使う採用チームのメンバーが積極的にフィードバックをくれた事も大きいです。
開発の初期段階から「ここはこういうふうに使う」とか「この情報を見る時はこの情報も一緒に見たい」などかなり多くのフィードバックをもらいました。
「採用チーム内でも採用管理システムを活用して移行しきること」をチームの四半期目標に設定してくれた事も順調に進められた大きな要因の一つだったと思います。

  • 採用チームの目標にシステムを移行しきる事を設定できた
  • 1人1人がシステムを使ってみて多くの意見をもらえた
  • 開発している自分自身が採用チームにいた
    • 不便な物事が日々見えたことで、必要な機能・不要な機能が判断しやすかった

採用ホームページの応募フォームの機能紹介

すべての機能をここで紹介することは出来ませんが、1つだけ簡単に紹介したいと思います。
freee 採用情報 の応募フォーム機能です。

画像は、募集職種一覧 → 応募したい職種をクリック → 下部の「応募する」ボタンをクリックした時の表示です。

freee 採用情報応募フォームのスクリーンショット
freee 採用情報応募フォーム

Salesforceは社内のメンバーが利用するためのサービスだと思っている方もいらっしゃるかもしれません(私はそう思っていました)が、社外に公開する情報や社外の方が入力する情報を管理する事も出来ます。

コミュニティ機能で実現

Salesforceには『コミュニティ』という機能があり、社外の方が入力する情報を扱う事ができます。

この応募フォームはコミュニティ機能を用いて実現しています。 各種Validationやファイルのアップロードなども標準の機能の範囲内で構築出来ます。つまりノーコードです。

最近のATSではこういった機能は珍しいものではなく、多くのサービスで実装されているものです。
社内のシステムと直接繋がっているためデータの転記やコピー&ペーストが不要で漏れぬけしづらく、効率的に候補者の方に対応する事ができます。
また、現時点ではまだまだUIが簡素ですが、内製している事でfreeeらしいページやデザインに改善していける可能性を持っています。

採用管理システムのこれから

採用管理システムを移行する話をここまで書いてきましたが、重要なのはこれからです。

まだまだ開発したい機能や解決したい課題がたくさんあります。
freeeが今後も拡大成長を続けていく限り、採用の精度向上と効率化は更に大切になってきます。

社外サービスでは成し得なかった『freeeらしい採用管理システム』に進化していけるようにしていきたいです。
また、社内の利便性や効率だけではなく、選考を受けてくださる候補者の方々やfreeeに興味を持ってくださった方にも寄り添った形で、最高の仲間を採用しつづけられるシステムを開発していこうと思っています。

またDevelopers Blogなどで新たに開発した機能などをご紹介出来たら嬉しいなと思っています。

応募フォームの入力をお待ちしています👍🏻

freee では複数のポジションで一緒に働く仲間を募集しています。「興味あるよ」という方は是非私の開発した応募フォームから応募頂ければ嬉しいです。

jobs.freee.co.jp

2020年プロダクトチーム新卒研修をフルリモートで実施しました

会計 freee のアプリケーションエンジニアの id:him0 (@him0net) です。自分は2017年4月に freee に入っているので、4月で丸3年となりました。相変わらず自ら手を動かしてコードを書くことが好きなのですが、チームのマネジメント業務も始め、チームのパフォーマンスを出すという課題にも取り組んでいるこの頃です。

3年前、自分は新卒としてfreeeに入社しプロダクトチームに迎え入れられたわけですが、今年はプロダクトチームとして新卒たちを迎える、新卒研修の運営をおこなったので、freee のプロダクトチームの新卒研修の紹介をフルリモートでの実施という今年らしい切り口を加えて紹介したいと思います。

新卒メンバーとメンターと運営メンバーが Google Meets で顔合わせ
新卒研修 kick off

続きを読む

GitHub Actionsで静的Webサイトのリリース手順を簡略化した話

こんにちは、freeeのアクセシビリティーおじさんの中根です。

先日から紹介しているfreeeアクセシビリティー・ガイドラインですが、一般公開に当たって、リリース作業をいかに簡単にするかというところで少しがんばってみたので、今日はそのことについて紹介します。

タイトルの通り、GitHub Actionsを活用しています。

リリースに当たって必要な作業

まず、今ガイドラインの新バージョンをリリースする際の手順をまとめておきます。

  1. 検討用に社内向けに公開しているソースを、一般公開用のリポジトリーに反映
  2. リリースのタグを追加
  3. そのソースからHTMLファイルを生成
  4. そのHTMLを公開サイトにコピー (サイトはAmazon S3)
  5. そのHTMLファイルをまとめたzipファイルを作成
  6. GitHubのリリース・ページでリリースを作成
  7. 5のzipファイルを添付
  8. リリース・ノートを追加

ざっとこんな感じです。 このうち、2の実行をトリガーにして、3~7を自動化しています。

GitHub Actionsでの実装

では、以下本稿執筆時に実際に使っているGitHub Actionsの設定ファイルを見ながら説明します。

name: Publish HTML

ワークフローの名前です。 GitHub Actionsのページに表示されます。

ちょっと実体と一致しない名前になっていますが、最初は上記の4までやれれば良いと思って始めたのでこういう名前になっています。 いずれ変えます。

on:
  push:
    tags: [ "*" ]

このワークフローが実行される条件です。 ここで指定することで、特定のブランチにpushされた場合だけとか、特定のパターンにマッチするタグがpushされた場合といった条件を指定することができます。 ただ、ブランチとタグの両方を指定した条件はここでは書けないらしいです。 そういう指定をしたい場合については後述します。

jobs:
  build:
    runs-on: ubuntu-latest

ここから具体的なタスクの記述が始まります。 "build" というIDのジョブを定義していて、ubuntu-latest上で実行することを指定しています。

1つのワークフローの中には、複数のジョブを記述できます。 複数のジョブがある場合は、基本的には並列に実行されるということですが、今回の場合はそういう込み入ったことは必要ないので、単一ジョブの中に順番にstepを記述していきます。

    steps:
    - name: Extract Branch/Tag Names
      run: |
        echo "::set-env name=NAME::${GITHUB_REF#refs/*/}"
        echo "::set-env name=BRANCH::${GITHUB_REF#refs/heads/}"
        echo "::set-env name=TAG::${GITHUB_REF#refs/tags/}"

最初のステップでは、ブランチ名やタグを環境変数に保存しています。 同じジョブ中であれば、先のステップで設定した環境変数を後のステップ中で参照することができます。

ここで設定した環境変数の値をチェックすることで、以後のステップについて特定のタグやブランチのときだけ実行するようにする、といったことが可能になります。

具体的には、

if: startsWith({{ env.BRANCH }}, "master")

のような感じで指定します。

    - uses: actions/checkout@v2

一般に公開されているactionを使用して、実行環境にリポジトリーをチェックアウトしています。

    - uses: actions/setup-python@v1
      with:
        python-version: '3.7.x'

Python 3.7.xを使うことを指定しています。

    - uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-1

awscliを実行するために必要な認証手順です。

${{ secrets.AWS_ACCESS_KEY_ID }}${{ secrets.AWS_SECRET_ACCESS_KEY }} はそれぞれ、リポジトリーのSettingsの中のSecretsの画面で登録している値と置き換えられます。 Secretsを活用することて、公にできない認証情報を埋め込むことができます。

    - name: Install the Latest pip
      run: python -m pip install --upgrade pip

    - name: Install required modules
      run: python -m pip install -r requirements.txt

最新のpipをインストールして、必要なモジュールをインストールしています。 ここまでで環境設定は完了です。

run: で、シェル・コマンドを指定して実行させることができます。 Ubuntuの場合は、bashが使われます。

    - name: Build HTML with Sphinx
      run: make html

    - name: Publish to S3
      env:
        AWS_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
      run: aws s3 sync build/html/ s3://${AWS_BUCKET}/ --quiet

SphinxでHTMLファイルを生成して、amazon S3のファイルをawscliで更新しています。

    - name: Prepare the HTML Archive
      run: |
        mv ./build/html ./freee-a11y-guidelines-${TAG}
        zip -r ${GITHUB_WORKSPACE}/freee-a11y-guidelines-${TAG}-html.zip ./freee-a11y-guidelines-${TAG}

リリースに添付するために、生成したHTMLファイルをzipファイルにまとめています。

    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ github.ref }}
        release_name: Ver. ${{ github.ref }}
        body: |
          Release note here
        draft: true
        prerelease: false

GitHub上で公開するリリースのドラフトを作成します。 リリース名はタグから自動的に付けられます。

リリース本文 (というかbody) には、固定で"Release note here"と入れています。 本当は、リポジトリー中の更新情報から当該リリースの情報を入れ込みたかったのですが、固定でない複数行のテキストを入れる方法がどうにも分からず断念しました。

ちなみに、このステップには id の指定がありますが、この次のステップの中でこのステップの実行結果を参照するために必要なものです。

    - name: Upload Release Artifact
      id: upload_artifact
      uses: actions/upload-release-asset@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        asset_path: ${{ github.workspace }}/freee-a11y-guidelines-${{ env.TAG }}-html.zip
        asset_name: freee-a11y-guidelines-${{ env.TAG }}-html.zip
        asset_content_type: application/zip

前のステップで作ったリリースに、作っておいたzipファイルを添付しています。

実際のリリース時の作業

ということで、このワークフロー導入後は、リリース時の作業はこうなりました:

  1. 検討用に社内向けに公開しているソースを、一般公開用のリポジトリーに反映
  2. リリースのタグを追加
  3. リリース・ノートを追加してリリースを公開

zipを作ったりファイルをアップロードしたりという部分は、ぼんやりしているとミスが混入しやすい部分だと思うので、この部分を自動化できたのは実に良かったと感じます。 リリース作業が面倒だから、という理由でリリース頻度が下がるというようなことも起こらないですし。 (他の理由で頻度が下がることはもちろんあるでしょうけど。)

フィードバック歓迎です

手探りで使ってみたGitHub Actionsのワークフローの改善案、そしてなによりガイドラインの改善案などありましたら、GitHubリポジトリーのIssuesやPull Requestsからお知らせください。