なぜ私はアクセシビリティに携わっているのか

Japan Accessibility Conference vol.2にymrlさん、melonさん、abeが登壇しているときの様子
Japan Accessibility Conference vol.2ymrlさん、melonさん、abeが登壇しているときの様子。撮影: © @nobjas さん

この記事はfreee Developers Advent Calendar 2020の19日目です。こんにちは、freeeでiOSアプリ開発を担当している @RyoAbe です。 私は、普段はiOS版の会計freee人事労務freeeの機能追加や保守対応を並行しつつ、アクセシビリティ対応もやっております。

developers.freee.co.jp

developers.freee.co.jp

本記事では、そもそもなぜ私がアクセシビリティに携わることとなったのかをはじめ、freeeという組織がなぜアクセシビリティに取り組んでいるのかを、これまでの活動などを交えてお伝えできればと思います。この記事を通じて、「なんかアクセシビリティっておもしろそうな分野じゃん。興味あるなあ」なんて気持ちになる方がいたらうれしいです。

きっかけ

人事労務freeeのVoiceOver対応

2年ほど前、弊社デザイナーの magi さんから「iOS版の人事労務freeeのVoiceOver対応を進めてみないか」という相談を受けました。当時VoiceOverという言葉は聞いたことはあっても、どういった機能なのか、ましてやAPIについても私はまったく知りませんでした。調べてみるとVoiceOverはApple製品に内蔵されているスクリーンリーダーで、Appleの公式ドキュメントVoiceOver対応のQiitaの記事を読んでみると技術的にはそこまで難しくなさそうに感じました。

www.apple.com

当時の私の気持ちとしては、視覚障害の方のためにといった理由より、技術として単純に面白そうだなと軽い気持ちでチャレンジしてみた感じでした。

まずはじめにVoiceOverの操作方法を勉強しました。最初は癖あるなと思ったんですが慣れれば簡単です。その後、エンジニアが自由にテーマを決めて取り組める週1のhack dayという時間を活用して対応を進め、magiさんにも動作確認をしていただきながらリリースすることができました。そもそもiOS版人事労務freeeのUIはシンプルだったため、手を入れなくても良いところも多く、対応は比較的簡単でした。何よりそれまで長い期間の経験があったiOSアプリ開発の中で、知らない技術を触ることができてとても楽しかったです。

freee が「人事労務freee」のモバイルアプリをリリース。モバイルアプリの活用と勤怠機能の強化で、日々の勤怠入力を効率化 | プレスリリース | corp.freee.co.jp youtu.be

ただやはり情報は少なくAPIの仕様は分かっても、使い方が正しいのか分からず試行錯誤したのを覚えています。リリース後、magiさんの後押しもあったりでVoiceOver対応を通じて得た知見を記事にしたり勉強会で発表させて頂いたりしました。

speakerdeck.com

その後の活動の中で社外のアクセシビリティ関係の方とお話しした際に、勉強会で作ったスライドを「拝見しました、参考になりました」との言葉をもらうことが度々ありました。これはアクセシビリティに限った話ではないですが、特別難しい技術でなくても得た知見をライトに発信することで、初めてその分野に足を踏み入れようとされる方々の手助けにつながるんだなということに気づき、いくらでも発信してやろうという気持ちになりました。

nakaneさんとの出合い

nakaneさん、magiさん、toofuさん、oujiさん、abeの食事中の様子
nakaneさん、magiさん、toofuさん、oujiさん(現在はSmartHRさんに所属)、abeの食事中の様子

そんなこんなで私はアクセシビリティに興味が湧いてきていました。ただ、実際にVoiceOverなどのスクリーンリーダーを普段使いするような視覚障害者の方と直接接するようなことは今までなかったため、「スクリーンリーダーってどんな風に使ってるんだろ。VoiceOver対応した人事労務freeeは実際に使い物になるのだろうか」 といった疑問を抱いていました。

そんな中、magiさんからエンジニアで全盲のnakaneさんとの食事の場にお誘いいただきました。色んな話を伺いたかったので二つ返事で行くことに決めたのですが、サポート必要そうなときにしっかり動けるだろうか、何か失礼があったらどうしよう、そんな不安や緊張感もありました。

食事会で私は3つのことに気が付きました。

1つ目は、当たり前ですが注文時のメニューはnakaneさんには見えないですし、お箸やお皿の位置関係も伝えたりとサポートの必要があります。そんな当たり前のことを実体験できました。

2つ目は、nakaneさんめちゃくちゃ面白い人(かつ、後から分かるんだけどめちゃくちゃ肉とビールが好き🥩🍺)。私の勝手なイメージで、口数は少ないのではないか、それなりに話される方だとしてもジョークなどは言わないのではと勝手に想像していました。それがまったくもってそんなくとはなく、お話し上手でたくさんジョークなどもおっしゃっていました。食事の場で一番記憶に残っているnakaneさんの言葉が 「目の見える人は歳をとったら老眼になるから、大変だねー」 というブラックジョーク。笑っていいのか若干戸惑いつつも、大笑いしたのを覚えています。 「目の見えない人は世界をどう見ているのか」という本の中で 「善意のバリア」 という言葉が出てきます。

www.amazon.co.jp

これは 健常者が必要以上に気にかけすぎて勝手に作りあげてしまう障害者との間のバリア のことで、nakaneさんは私が勝手に作り上げた不安や緊張感から生まれるバリアを、ユーモラスなジョークでほぐしてくれたんだと思いました。この本を読んで、視覚障害者が見る世界や接し方の理解がぐっと深まりました。最低限のサポートは必要であれ、変に肩に力を入れずにnakaneさんという存在と自然に接すればいいのだと。 もしよかったら読んでみてください。簡単ではありますが読書感想文も書いています。

note.com

3つ目は、食事会の帰りにnakaneさんからいただいた胸に刺さる言葉になります。 「アクセシビリティはさ、誰かのためにとかじゃなくて、自分のためにって思ってやるといいと思うよ」 と。助けたい、支援したい、といった気持ちではなく、 自分のためにやる、技術として好きでやる、そんなモチベーションでやればいいんだ と気づき、とてもしっくりきました。

まさかこの後、nakaneさんが入社されるとは思いもしませんでしたw 入社されてからはとことんお世話になっていて、アクセシビリティ対応に関わる面々での集まりで活動報告や対応方針を相談させていただいたりしています。

以下の動画は会計iOSの自動で経理のVoiceOver対応をnakaneさんに動作確認をしていただいているときの様子です。

youtu.be

対応までの流れをまとめたのがこちらの記事です。 もう一歩進んだVoiceOver対応 - freee Developers Blog

あらためてアクセシビリティとは?

さて、私がアクセシビリティに携わるきっかけやモチベーションについて説明したところで、改めて アクセシビリティとは何かfreeeがアクセシビリティに取り組む理由について、弊社の日本トップクラスのアクセシビリティ人材のスライドを引用しながら説明したいと思います。

アクセシビリティー とは

  • accessibility = access + ability
  • アクセス + することができる

誰もが、ほぼ同じコストで、 ほぼ同じ量の情報を得られ、 同じ目標を達成できる

出典: @ymrl. 弊社全社会議「アクセシビリティの取り組みの紹介」にて

ふむふむ。誰もが同コストで同情報を得られ同目標を達成できる。

アクセシビリティの考え方

  • 特定の誰かのためではなく、すべての人を対象にする
  • 特別な専用のものを作るのではなく、同じものを使えるようにする
  • 特定の条件での使いやすさではなく、あらゆる条件で使えることを目指す

出典: @ymrl. 弊社全社会議「アクセシビリティの取り組みの紹介」にて

ふむふむ。アクセシビリティは高齢者や障害者など特定の人のためではなく、すべての人が対象。そこにはもちろん私も含まれていて、以下のようなシーンが考えられます。

  • 腱鞘炎でマウスが持てない
  • Bluetoothイヤホンが電池切れ
  • 子どもにメガネを壊された

出典: @magi. あなたの価値を高めるWebアクセシビリティ(JAC Special Ver.). p22

一時的なトラブルは誰にでも起こりえるかと思います。このような シーン以外にも便利な使い方ができる場面もあります。

例えば、

  • iOSのVoiceOverや読み上げ機能を使って歩きながら記事や本を聴いたり
  • Macで自分が書いた文面を読み上げて誤字脱字を見つける用途で使ったり

私は読むのが遅いので、これらの使い方は本当に重宝してます。 情報へアクセスする方法が多様になると、このような使い方も可能になるんだなと感じています。

なぜfreeeはアクセシビリティに取り組むのか

つぎに、これまで長々と説明してきたアクセシビリティをなぜfreeeが取り組むのか、その理由について説明します。

  • スモールビジネスを、世界の主役に「freeeのプロダクトを使う」という文脈において障害者を減らしたい
  • freeeのアクセシビリティが向上すれば、ユーザーはビジネスに自力でアクセスできる
  • 結果、スモールビジネスの多様性は増加し、freeeは真に社会を変え得る存在となる
  • 世界の主役になれる人を1人でも多く
  • 1人が使えないことて失うユーザーは1人だけとは限らない

出典: @max. 社内アクセシビリティ研修

ふむふむ。

「アイデアやパッションやスキルがあればだれでも、ビジネスを強くできるプラットフォーム」

だれでも = あらゆる人 アクセシビリティ対応=あらゆる人が使えるようにする

出典: @yoshi. 人事労務freeeのアクセシビリティへの取組み. p14-17

このように、個人的な思いなどではなく freeeのミッションとビジョンを実現するための取り組みの1つにアクセシビリティがあります。

このことを踏まえながら、Appleの公式サイトのアクセシビリティのページを見てみましょう。(2020年11月執筆時点の内容になります)

テクノロジーは、すべての人に力をもたらす時に、最もパワフルになります。

youtu.be

家族のポートレート写真を撮る。FaceTimeで近況を伝え合う。ブラインドを上げて朝の光を取り込む。私たちは、テクノロジーの力によって実現される毎日の瞬間を、すべての人に楽しんでもらいたいと考えています。だから、すべてのApple製品が誰にでも最初から使いやすくなるように取り組んでいます。デバイスの真の価値は、どれほどパワフルかではなく、どれほど人に力をもたらすかで測られるからです。

この動画とメッセージは、自分の中にとても染み付いています。「すべての人」 がキーワードだなと思っていて、Appleはテクノロジーで誰もが真の力を発揮できるようにするためのデバイスを作っているんだなと感じました。それは我々のミッションの「アイデアやパッションやスキルがあればだれでも、ビジネスを強くできるプラットフォーム」にも通ずると思っていて、誰でもfreeeを使ってさえいれば世界の主役になれる、そんなサービスにしたいなと自分も考えています。

あと、こちらの動画もとても素敵なのでご覧いただければと思います。

youtu.be

DJでありプロデューサーでもあるPatrick Lafayette氏が、VoiceOverを使いこなし音楽制作をしたり、料理を作って家族に振る舞っているときの様子です。「自分らしく生きてる!」 って感じがしてかっこいいですよね。いつかこんな感じの「freeeを使ってビジネスを強くスマートに育てられているユーザさんの動画」そんなのが作れたらいいな。

Appleのアクセシビリティに対する力の入れ具合

ここからはアクセシビリティ全般の話からもう少し踏み込んで、iOSにおけるアクセシビリティについて詳しく説明しようと思います。

WWDC

WWDCでは年々アクセシビリティに関連したセッションが増えていたり、新しいiOSがリリースされる度にアクセシビリティ周りの機能が大きくアップデートされていたりと、Appleがアクセシビリティに力を入れていることが伺えるかと思います。(国内でもiOSDCやDroidKaigiでアクセシビリティ関連の発表を見かけることが多くなりました)

アクセシビリティ関連のWWDCのビデオでは、新しく追加されたAPIの紹介以外にも、VoiceOver対応するためのテクニックが紹介されたりします。自動で経理のVoiceOver対応の記事にも書いていますが、会計iOSの自動で経理のUIは上下に2分割していて、なおかつ上部のカードが横スクロールに応じて下部の項目が変わるという少し複雑なUIで、このUIをVoiceOver対応するのはなかなか難しくとても悩んでいました。たまたま見ていたWWDCのセッションで、同じUIでのVoiceOver対応のテクニックが紹介されていて、歓喜しました。

developer.apple.com

iOS 14

また、iOS14に新たに加わったアクセシビリティ機能の「背面タップ」は個人的にも重宝しています(Macに接続されていたAirPodsProをiPhoneに直ぐさま切り替えるショートカットを呼び出すようにしてます。iOS14で自然に切り替わる仕組みが入りましたが、うまく切り替わらないことが多々あって)

その他にも色んなアクセシビリティ関連の機能が追加されていて、「手話へのフォーカス」は、FaceTimeで複数人で手話を使って話しているときに、話し手が目立つように映し出すというものだったり、

youtu.be

iPhone 12 Pro/ Pro Max に内蔵されているLiDARセンサーを利用したリアルタイムで人との距離を測ってくれる機能があったりします。(バスなどで列に並んでいるときに便利そうですよね)

youtu.be

内部的にはAIを用いているのか詳しくは分かりませんが、アクセシビリティの機能は便利な上に、技術的にも面白そうなものが多いです!

まとめ

ひょんなことからアクセシビリティに携わるようになり2,3年経ちます。これまで10年以上エンジニアとして仕事をしてきて今までの経験を活かしながら、新しい分野にそろそろ挑戦したいなというタイミングでした。難しい技術ではないのでチャレンジはしやすい分野ではあるものの、足をつっこむととても奥深い分野だなと感じています。

アクセシビリティに携わるきっかけをくれた @magi1125 さん、レビューを通して障害当事者として生のアドバイスをくださる @ma10 さん、本当にありがとうございます。お二人がいなければこの分野に関わることはなかったと思います。

これまでは個でモバイルのアクセシビリティの活動に取り組んでいましたが、これからは個としてだけでなく、チームとしての取り組み方の検討や推進にも取り組んでいきたいなと考えております。

この記事を読んで、「なんかアクセシビリティっておもしろそうな分野じゃん。やってみたいな」なんて気持ちになる方がいたらうれしいです。DMでもなんでもお待ちしております。

明日は、弊社プロダクトのセキュリティーを日々守ってくれている Eiji さんです。お楽しみに!

2020年、freeeのアクセシビリティを振り返る

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

こんにちは、freeeの@magi1125こと伊原です。自称「アクセシビリティで一発当て太郎」です。アクセシビリティによるビジネス貢献を模索していますが、最近は「いつ当てるの?」と聞かれて悩んだりもしています。もうちょっと待って。

この記事ではタイトル通り、2020年のfreeeにおけるアクセシビリティ関連の出来事をご紹介します。なお、2019年以前の活動については「2019年、freeeのアクセシビリティを振り返る」をご覧ください。

developers.freee.co.jp

※アクセシビリティの向上とは、障害者高齢者を含めた幅広いユーザーに利用方法の選択肢を提供し、使える状況を広げる取り組みを指します。

腕力の限界と停滞

freee Developers Advent Calendar 2020の1日目「デザインシステム “Vibes” の育てかた」に、以下のような記載があったことにお気づきでしょうか。

アクセシビリティ「だけ」なら勉強すればいいですが、他の業務をやりながらアクセシビリティ「も」やるのはなかなかハードルが高くなってしまいます。そして、それでもアクションに移すことができた有志のメンバーの活動では限界がありました。

実際のところ、2020年の前半、プロダクト上でのアクセシビリティ改善は停滞していました。

当時の座組としては、私が各プロダクト開発チーム内の有志のメンバーに話を持ちかけ、現状のチェックを伴走したり、目標を立てるお手伝いをしたり、という形で進めていました。しかしこのやり方は上手くいきませんでした。

これにはいくつかの要因があります。

  • そもそもWebアクセシビリティは難しい(Webアクセシビリティ難しすぎる問題
  • 既存プロダクトの改善はいろんな制約があり、対応箇所が限られる
  • あと付けで開発チームの目標に入れても、他の目標との共存が難しい
  • チーム内で自主的に始まっていないので、旗振り役の動き依存になりやすい

今になってわかることは、アクセシビリティが「外からきた、あと付けの、特別なもの」であるうちは、一定以上は改善が進行しない、ということでした。

さらに私自身、デザインリサーチの仕事が増えつつあり、継続的なフォローが難しくなっていました。2年ほど有志で集まって開いていた「アクセシビリティやっていき会議」はいったん解散し、それぞれの持ち場に戻ることになります。

新製品に組み込まれていたアクセシビリティ

こういった状況がある中でも、デザインシステムチームよって、デザインシステムVibesの拡充、アクセシビリティーガイドラインの執筆、チェックリストの作成は粛々と進行していきました。また、ガイドラインの内容をデザイナーに共有したり、チェックリストを使ったチェックをQAチームに試してもらったりと、普及への取り組みも行っていました。

やがて春になり、freee アクセシビリティー・ガイドラインが公開されました(ガイドラインの狙いについては当ブログの記事をご覧ください)。

developers.freee.co.jp

そして夏を迎え、このブログがバージョンアップお知らせコーナーとなりつつある中で、ひとつの知らせが飛び込んできました。新規プロダクトであるプロジェクト管理freeeにおいて、アクセシビリティの担保を前提として開発が進んでいるらしい、という情報でした。事実、外部のデザイン会社であるコンセントさんにチェックしてもらったところ(この企画については後述します)、一定レベルまでアクセシブルな状態になっていたのです。

また、もうひとつの新規プロダクトであるfreeeスマート受発注でも、アクセシビリティを前提とした開発が進んでいました。ある日、社内SNSに「Lighthouse(アクセシビリティチェックツール)で100点になりました!」という投稿が上がってきたのです。

これにはデザインシステムチーム一同が驚きました。どちらも「以前に軽く頭出しはしていて、チェックは試してくれているのかな……」ぐらいに思っていたからです。まさかそんなにがっつりコミットしているとは予想しておらず、何が起きたんだ?という気持ちで秋を迎えた私たちは、それぞれの開発チームを質問攻めにしました。

アクセシビリティの『発動条件』

ふたつのプロジェクトのメンバーにヒアリングを繰り返す中で、両者に共通した、アクセシビリティ担保がチーム内で実施されるための『発動条件』が見えてきました。それは以下です。

  1. プロダクトやチームが小規模である
    • これにより意思統一がしやすい状況がある
  2. アクセシビリティの知見を持つメンバーが1〜2人存在する
    • 課題に対して相談できるメンバーが少数でも存在していると改善に繋がる
  3. デザインシステムを前提として開発している
    • Vibes、アクセシビリティーガイドライン、チェックリストがこれに相当する
  4. 高品質を目指す合意があり、その基準のひとつにアクセシビリティを位置づけている
    • セキュリティやパフォーマンスなどの様々な側面で品質を高く出そうとしている。その中で、アクセシビリティを単独ではなく他の品質基準と同列として明示している
  5. 品質観点のチケットを出すサイクルがあり、アクセシビリティのチケットも他と同様に扱う
    • デザイナーやQAがチケットを上げるサイクルが明示されている。そして品質という観点では同一で扱うべきものとしてアクセシビリティでも優先度を下げていない
  6. ユーザビリティテストの実施サイクルがあり、支援技術によるテストもその一環で行う
    • 専門家評価だけでなく、ユーザーによる評価も実施する。通常の利用状況におけるテストと同様に、スクリーンリーダー等を使った評価も行う
  7. チケットは必ず実施判断を行う運用になっている
    • 2スプリント以内に必ず完了するか、『やらない』の判断をしてチケットを閉じている

上記を眺めていて感じるのは、「アクセシビリティを特別視せず、満たすべき品質の一部と捉えている」ということです。あくまで高品質なプロダクトを最速で出していこうとする流れや、そのためのプロセスをブラさずに維持し続けるという努力が先で、その中にアクセシビリティ「も」組み込まれている、といった見方が適切なのだろうと感じました。

Google スプレッドシートのスクリーンショット
プロジェクト管理freeeのプロジェクトから生まれた「GoToMarket運用テンプレート」のスプレッドシート。新規プロダクトを出すまでにやることが全てリストアップされている。この中にはアクセシビリティチェックが当然のこととして据えられている。

とはいえ、その状況のなかでアクセシビリティが取り扱われるためには、やはりこれまでのアクセシビリティやっていきの普及活動も必要だったし、その実現を後押しするツールとしてのデザインシステムも必要だったということです。あの人がいたからできた、Vibesがあったからできた。そういった声もヒアリングの中ではたびたび出ていました。

やっていこうという人がいて、やっていくためのツールがあり、それらがチーム内での品質への合意として結実したときに、プロダクト開発にアクセシビリティは織り込まれるということがわかったのです。

意外な発見が続出

その他にも、従来はアンチパターンと思われていたことを覆すような、さまざまなことが発見されました。いくつか代表的なところをピックアップしてみます。

Lighthouseはわかりやすくモチベーションが上がる

これまでは、機械チェックに対してはどちらかというと慎重な姿勢を持っていました。課題指摘の網羅性が低く、しかし大量にエラーが出る恐れがあり、さらにその結果をどう直していいかわからずに混乱する恐れもあると考えていたからです。

しかし、スマート受発注の開発チームがアクセシビリティに取り組んでいるということを知れたのは、Lighthouseという機械チェックツールで100点を取ったよという投稿が社内SNSで流れてきたからでした。やはり100点のバッジはうれしいものですし、アクセシビリティにあまり詳しくない人からしても「そういう観点があるんだ」「品質を高くやっていこうとしているんだ」というのが伝わり、応援の声が集まります。

Lighthouseのスクリーンショット
Lighthouseによるアクセシビリティスコアが100点になっている様子

機械チェックが全てではないということを分かった上であれば、モチベーションを作る・維持していくツールとして活用していける道筋があるんだなと気づきました(このあたり詳細は当ブログの記事をご覧ください)。

developers.freee.co.jp

チケットを出すフェーズはQA段階でもデザイン段階でもどちらでもイケる

これまでは、開発が一段落してQAに入った段階でアクセシビリティのチケットが大量に出てくるのは開発者の心理的負担が大きいのでは?と想像し、プロセス的にはアンチパターンだと推定していました。

しかし、プロジェクト管理freeeの開発現場では、実際にQAからアクセシビリティ系のチケットがドバっと届いても、特に大きな問題にはならなかったそうです。曰く「もともと品質としての合意があり、そのチケットが来ることが予想できていれば問題ない」とのこと。

また、スマート受発注の開発チーム内では、デザイナーが実装をチェックしてアクセシビリティに関するチケットを出していました。これも同様に「Shota Dayという取り組みの中でUI品質を上げていくという合意があったので、アクセシビリティはその一環として対応していた」とのこと。

つまり真にアンチパターンなのは「特定の人だけがチーム内で合意を得ずにアクセシビリティの指摘を行っていること」だったのです。そしてこれがチケットの滞留を生む原因にもなります。逆にチーム内で合意があれば、フェーズを問わず指摘は歓迎されるのでした(もちろん、問題が大きくなる前に改善するという点では、なるべくシフトレフト=企画やデザイン段階で改善することが望ましいです)。

QA的には、アクセシビリティチェックはリソース上の負担になっていない

これまでは、QAチームにチェックしてもらうのは単純に作業が追加になって、負担が大きくなるのでは?と漠然と思っていました。

しかし、実際にチェックを行ってみたQA担当によれば、アクセシビリティチェックは通常のQA工程に比べてむしろ負担が少ないという意見でした。その理由は「テスト設計が要らないから」というものです。ガイドラインとチェックリストさえあれば、それを元にチェックをしていくだけなので隙間にシュッと入れられるし、むしろ楽だと言うのです。QAのプロフェッショナリズムと底力を見せつけられる一幕でした。

アクセシビリティは切り出しやすいフィーチャーである

これまでは、もちろん「アクセシビリティは取り組みが難しい課題である」と考えていました。しかし、上記のQA担当の話から考えるに、理解するための難易度は一定レベルあったとしても、わかってしまえば切り出して解決することはむしろやりやすいテーマなのだと知りました。

この「ガイドラインとチェックリストがあれば手がつけられる」という切り出しやすさは、別方面でも活用されました。そのひとつが、インターンの開発テーマとしてアクセシビリティ改善を実施してもらうというものです。2週間という限られた期間のなかでも、読みこなせるガイドラインと共に、適切なサポートとフィードバックがあれば、実際にプロダクトの品質を高めることに貢献できるのです(詳しくは当ブログの記事をご覧ください)。 developers.freee.co.jp

この特性をもとに、つい最近もプロジェクト管理freeeの開発チーム内では「アクセシビリティDay」という試みが実施されました。既存チケットのうち解決難易度が低いものから高いものに並んでいて、何をどうしたら良いかを相談しながら3時間一本勝負で改善を試みるというものです。謎解きのようなゲーム性もあり、とても盛り上がったようです(次回は「両手骨折でプロダクトを使おう」というテーマになる模様です)。

社内SNSのスクリーンショット
アクセシビリティDayの開催報告を社内SNSに流している様子

「プロダクトと歩調を合わせてヘルプページも」という話が進む

これまでは、ヘルプページの改善も停滞していました。以前に一度改善しようという動きがあったものの、そのまま着手するきっかけを持てずに時が経過していたのです。freeeのリリースサイクルは早く、それに追従すべく日々原稿がアップされ、内容も更新されていきます。そんな中で、アクセシビリティだけに的を絞って手を入れるのが難しいのは、ヘルプページにしても同じだったのです。

しかし、プロダクトと目標を同じくするなら、話は別です。スマート受発注のリリース準備を進めるなかで、ヘルプページ作成チームにも「プロダクトがアクセシブルになるので、ヘルプもそれに準じたい」という話を持ちかけました。こちらも背景が明確であることからスムーズに進み、原稿レベルの段階から取り組みを進めることができました。

Google ドキュメントのスクリーンショット
「ヘルプページ原稿 アクセシビリティ対応」のドキュメント。altの書き方などを解説している。

はじめから合意があれば進めやすいという点は、ここでも明らかになったのです。また、実際に作業を進めてもらうなかで、チェックリストのフィルタや並び順などにもフィードバックをもらうことができました。

チェックリストをフォームから呼び出せるようにすると捗る

これはちょっと裏方の話です。デザインシステムチームではアクセシビリティチェックリストが使いやすくなるように改善を細かく行っており、常に最新版を使ってもらうためにフォームからチェックリストを生成出来るようにしました。

Google Formのスクリーンショット
アクセシビリティのチェックリストを生成するためのGoogle Form。対象のプロダクト、ページタイトル、URL、チェックを実施するチームの略称を記載する欄がある。

これは、チェックリストを提供するデザインシステムチーム側としても、ちょっとした革命だったと言えます。チェックされている現場がどこなのか把握してアクティブサポートができるし、社内でのチェックの実施状況が数値としてカウントできるようになりました。実施されたチェックをあとから振り返ってフィードバックループにも役立てられます。

Google スプレッドシートのスクリーンショット
生成されたチェックリストの一覧。どのプロダクトの誰が何の画面をチェックしているのかが、チェックリスト提供側から見える。

もし同じような取り組みをはじめるかたがいたら、おすすめしたい手法です。

他社と一緒に進めると強力な後押しになる

もうひとつ大きくご紹介したい取り組みがあります。それは「他社と一緒に進める」というものです。プロジェクト管理freeeは、受託制作会社をターゲットユーザーのひとつとして開発してきました。そのターゲットにあたる人なら誰でも使えるようにすべきだと考えた結果、受託制作をビジネスとして実施しつつ、インクルーシブデザインチームを擁しているコンセントさんにレビューいただくのが最適だと考えたのです。その取組の詳細はこちらの記事をご覧ください。

www.concentinc.jp

結果としてこのコラボレーションは大きな成果を得ることができました。「アクセシビリティの視点」と「実際のターゲットとしてのユーザーの視点」の両方から見たフィードバックが得られるのは非常に貴重であり、開発チームとしても深い納得が得られるものでした。また、ターゲットユーザーに近い会社とのやりとりは、開発チームとしては「高めた品質が届く先」が可視化されていく体験でもあります。これは改善サイクルを回していくモチベーションをより高めることに繋がりました。

なお、個人的には、自分が元いた受託デザイン業界と、今いるSaaS業界がアクセシビリティ案件によってつながるきっかけを作れたことは、ひとつの喜びだったりします。ビジネスとしてアクセシビリティに取り組む会社がつながっていくことで、そこに取り組む意義が明文化され、世の中が変わっていくスピードをより加速できたらいいなと感じました。

デザインシステムと共に、再び「既存」に切り込む

新規プロダクト開発においてアクセシビリティを織り込む方法は明らかになりました。このナレッジを活かして、私たちは既存プロダクトのアクセシビリティ改善に再びチャレンジしていこうというフェーズにいます。

やっていこうという人がいて、やっていくためのツールがあり、それらがチーム内での品質への合意として結実したときに、プロダクト開発にアクセシビリティは織り込まれる

これを既存プロダクトにおいても再現していくことが、これからの取組みとなります。

そのためのカギは、やはりデザインシステムVibesです。Vibesはアクセシブルなコンポーネントとして実装されています。そして同時に、フロントエンドの共通化による開発生産性の向上が見込めるため、各プロダクト開発チームからの歓迎ムードもあります。アクセシブルになるものを、導入したいと言われる状況があるのです。というか、Vibesはそれを狙って作られています(詳しくはブログ記事をご覧ください)。

developers.freee.co.jp

しかし、各プロダクトにVibesを適用していくときに「とにかく入れるんだ」という形で進めてしまっては、やはり品質への合意がおろそかになり、アクセシビリティ的にも不本意な展開になってしまいます。Vibesをただ適用するだけでは(もとよりは改善される可能性はあるものの)狙ったアクセシビリティは発揮されませんし、正しく使われなければアクセシビリティ以外の品質も下がってしまい、導入の意義が薄れてしまいます。

Vibes適用を実施する際に、まず各プロダクトの開発チーム内にアクセシビリティを理解する人が存在する状態を作っていく。そして「Vibesがもたらす品質のひとつ」としてのアクセシビリティ担保をチーム内で合意していく。これができれば、新規プロダクトと同じ構図が実現され、ガイドラインとチェックリストが活用され、改善が実施されていくはずなのです。

期待の星、モバイルアプリ

アクセシビリティ改善のプロセス化の目処が立っていくなかで、次の期待の星と目されているのが、モバイルアプリです。

これまでも、freeeのモバイルアプリはアクセシビリティの改善を試みてきました。

corp.freee.co.jp developers.freee.co.jp

こうした改善を重ねてきたエンジニアがいるモバイルチームは、アクセシビリティ改善の必要条件である「プロダクトの開発チーム内にアクセシビリティを理解する人が存在する」をすでに満たしています。

そして、モバイルアプリの立ち位置をあらためて整理したところ、これは本腰をいれてアクセシブルにするべきなんじゃないか?というチームの合意を得ることもできました。その理由は以下です。

  • モバイルアプリユーザーには、アクセシビリティを必要としている絶対数が多そう
    • 経費精算・勤怠打刻・給与明細確認といった従業員側が使う機能の割合が多いため
  • アクセシビリティを必要とするユーザーに評価してもらいやすそう
    • アクセシビリティチェックに応じてくれそうな実ユーザーが何名か存在するため
  • Webと比較して、実装とチェックがやりやすそう
    • ブラウザやスクリーンリーダーの違いがなく、OS・スクリーンリーダー・アプリが垂直統合されているため
  • やり切るまでの道筋が見えやすそう
    • Web版に比べて機能がコアに絞られており、かつ先に取り組みが進んでいる部分があるため

こういった話が出る中で、モバイルチーム内からは、品質としてクリアするというだけでなく、「誰にどこまでのことを提供する、何人に使ってもらえるようにする」といった攻めたゴール、野心的なゴールを設定してもいいのでは?という声まで挙がりました。ユーザーの課題を直接的に解決していくというプロダクト開発の目標と、アクセシビリティがもたらす「利用できる状況を増やす」という効果を、天秤に掛けるのではなく掛け算として考えるフェーズに突入したのです。

折しも、2021年3月1日からは障害者の法定雇用率が引き上げになります。企業に所属する従業員がアクセシビリティを必要とするケースは今後も増えていくでしょう。SDGsへの取り組みが企業の評価軸に加わっていく動きもあります。このようなインクルージョン、ダイバーシティといった時代の流れ、空気の移り変わりも影響しているのかもしれません。

このようにして、アクセシビリティ推進の三要素のうち、「理解がある人の参加」と「品質としての合意」が実現できました。残る要素は「ツール」です。モバイル向けデザインシステムに対するアクセシビリティ面での調整や、ネイティブアプリを前提としたガイドラインおよびチェックリストの準備といった取り組みを進めていこうと話して、一昨日のミーティングを終えました。これからの動きが楽しみです。

来年もお楽しみに!

アクセシビリティ推進の三要素は、それなりに確度が高い仮説な気はしています。しかし、それ適用できる範囲に限りがあるかは、まだわかりません。新規プロダクトではゼロベースでやり方を考えられますが、既存プロダクトではさまざまな前提や制約があります。さらに、Webとネイティブアプリではまた違った角度の問題が起きるかもしれません。

いろいろ一筋縄では行かないかもしれませんが、freeeのミッションである 「スモールビジネスを、世界の主役に。」を実現するために、私たちの戦いは続きます。

最後にすこし宣伝です。WEB+DB PRESS Vol.116にて、freeeのアクセシビリティへの取り組みを30ページほどの特集記事としてご紹介しています。ぜひご覧ください。 gihyo.jp

そして、手を貸してもいいぞという方、いらっしゃいましたらぜひご連絡ください。 jobs.freee.co.jp

明日はミスターモバイルアクセシビリティ、abeちゃん(@RyoAbe)です。

会計freeeのホーム画面をフルリニューアルした話

アイキャッチ画像(会計freeeのホーム画面をフルリニューアルした話)

この記事はfreee Developers Advent Calender 2020の17日目の記事です。

こんにちは、freeeのプロダクトデザインチームで会計freeeのデザインをしたり、リサーチをしているはるたん(@hrtnde)です。

今日は構想から1年半かけて会計freeeのホーム画面をフルリニューアルした裏側を全て公開します!!!

新旧ホーム画面の比較画像
新旧ホーム画面

会計freeeの提供から約7年、日々freeeは機能アップデートを重ねプロダクトを進化させてきた一方、ホーム画面については大きな変更を行っていませんでした。

そんなfreeeのホーム画面を大きく刷新、ついにフルリニューアル後のβ版提供も終了し、会計freeeの法人・個人アカウントのユーザー*1が新しいホーム画面を利用していただいております!(👏👏👏)

リニューアルの概要については、freeeのリリースノートに載っているので、そちらをご確認ください。

www.freee.co.jp

はじまり

ホーム画面はリリースしてから主要機能の大きな変更がなかったため、freeeのユーザーセグメントの変化に対応できなくなっていました。例えば、従業員数が100人を越す会社の経理担当者も起業したばかりの1人経営者にも同じ画面を提供していたため、情報が全く整理されておらず、経理経験のない経営者にいきなり専門用語で圧倒するなんてことも。。。

主要な機能はあまり変化がない一方で、会計freee内のさまざまな画面への導線やユーザーへのメッセージは追加されていくという悲惨な状況。

2019年6月、会計freeeを担当するデザイナー陣のミーティングで、ホーム画面をリニューアルしようということになり、本プロジェクトがついに幕を開けます。

デスクリサーチでホーム画面の課題を整理

プロジェクトが始まった当時の事を振り返ると、リニューアル後のイメージが持てず、暗中模索しているような状態。僕自身、入社してからずっと社外から会社の経理業務に関わる「税理士さん」向けの機能開発に関わっていたこともあり、社内で経理業務をする「経理担当者」や、数字を確認する「経営者」への理解が薄かったのも要因の一つだと思います。

まず初めにやったことは、社内SNSで会計freeeのホーム画面に関するフィードバックを全従業員から集めることです。

freeeのホーム画面に関するフィードバックを集めている写真

募集をかけてすぐに、様々な職種・部署の人からたくさんの意見をもらいました。例えば、「特定の機能の導線を目立たせたい」「何をすればいいか分からない」「特定ユーザーを想定した固定的なホーム画面の提供はもうムリ」「お気に入りメニューの登録みたいな形でカスタマイズできるようになると嬉しい」などなど。部署が違えば意見も違うため、改善案の方向性が中々定まりません。

次に経営者、経理担当者がどうやってfreeeを使うかを理解するため、経理業務や経営者が日常的に行う業務フローを整理。合わせて経理業務に関する本を読んだり、ブログを読んだり、時には経営に関する本を読み込みながら少しずつ理解を深めていきました。

経営者の業務を整理したシート、業務別にfreeeのホーム画面どの機能と関連するかが書かれている
経営者の業務を整理したシート

業務の理解が深まるに連れて、ホーム画面としてどうあるべきかまでは見えていなかったものの、どんな機能があれば経営者の業務が楽になりそうか?という仮説が見えてきました。

改善案の方向性が何となく見えてきた段階でfreeeの経営陣(CEO&COO)へ、freeeのホーム画面を改善したいという相談を行うことにします。(直接経営陣に提案するのは始めての機会だったので、最初はめちゃくちゃ緊張した記憶がありますw)

相談の結果、「経理担当者」や「経営者」など全ユーザーセグメント向けの画面を一気に変更すると検討工数も開発工数も膨らんでプロジェクトが進まないのでは?という話はあったものの、ホーム画面を改修していくことには全面的に賛成。

詳細は割愛しますが、「経営者」に絞って検討を進めていくことが決まり、プロジェクトが本格的に始動しました!

30人以上の経営者に話を聞き、作って壊すを繰り返す

初期のコンセプト案に関して、CEOからのフィードバックはあったものの、実際にそれが良いかどうかはユーザーに聞いてみないと分からないよねという結論になり、ユーザーインタビューを行うことにしました。

1回目のインタビュー

1回目のインタビューで使用したプロトタイプ
1回目のインタビューで使用したプロトタイプ

ちなみにこれが初期のプロトタイプ。最終的な形と比べると機能モリモリでしたが、それが初回のインタビューとしては良い効果に繋がりました。

というのも、新ホーム画面をそのまま公開するためのインタビューというよりは、「経営者としてホーム画面で重要な情報は何か?」を明らかにすることが最重要。話を引き出すためのプロトタイプとして利用するには、実は機能モリモリの方がやりやすかったです。

インタビューでは、「経営者にとってホーム画面で重要な情報」を明らかにするための質問事項を設計しました。

インタビューで質問する事項を整理した図(説明は後述する)

まず、「新ホーム画面」と「今までのホーム画面」に関するフィードバック、そしてその理由を伺うことで、その人にとって何が重要な情報かを明らかにします。

とはいえ、その人のバックグラウンドを理解しないままが発言を鵜呑みにしても、最終的にホーム画面にとって重要かどうかの判断は難しいため、インタビューの前段にその人のストーリーを理解するために『会社の「これまで」と「これから」を記入してもらう質問シート』を用意しました。

会社の「これまで」と「これから」を記入してもらう質問シート(説明は後述する)

このシートを使って、インタビュイーのストーリーを聞き出します。起業した経緯、そしてそれまでの変化、どんな経営的な判断を行ってきたのか、そしてその時にfreeeはどんな存在だったのか?を紙に書いてもらいます。書きながら感情の変化とかを書いてもらったお陰で、過去の話も具体的な体験とともに語ってくれました。

たくさんの経営者に話を聞く中で、freeeのお陰で救われたという経営者もいました。僕たちが作っているプロダクトが彼ら、彼女らの人生に大きな影響を与えているんだなと感じ、責任の重さを感じつつも、体が熱くなるほど嬉しくなった事を思い出します。

freeeの新旧ホーム画面を印刷したシートにペンで円バツが書いてある様子
freeeの新旧ホーム画面を印刷したシート

新ホーム画面や今までのホーム画面に関するフィードバックを集めるために、それぞれ印刷した紙を渡して、必要そうな機能に丸、使わない機能にはバツを。そして、丸やバツにした理由を聞くことで、どんな情報を重要としているかを理解していきました。

印刷した紙を渡したことで、経営者の中には自分でこういう機能が良いんだよねーと言いながら、紙にアイデアを書いてもらうことでプロトタイプを一緒にデザインしていく場面も何度かありました。

1回目のインタビューが終わり、インタビュー結果や経営者の方のアイデアを元にプロトタイプを修正することにします。

2回目のインタビュー

2回目のインタビューで使用したプロトタイプ
2回目のインタビューで使用したプロトタイプ

特にユーザーからのフィードバックが多かったものを修正し、自信満々で2回目のユーザーインタビューを行いました。 2回目のインタビューも1回目とインタビューと同じように、質問シートを使ってターゲットの属性を把握した後、プロトタイプを見せて反応を見てみるインタビュー。

ところが、ものの見事に僕らの自信は打ち砕かれてしまう。

2回目のユーザーインタビューで得た気付きは2点。1つめは、「freeeを使いこなしている経営者の方は、今回のプロトタイプで得られるメリットが少ないということ」、2つ目は「freee使い始めの人にとってはホーム画面だけでは改善の意図が伝わっていないということ」でした。

3回目のインタビュー

3回目のインタビューで使用したプロトタイプ
3回目のインタビューで使用したプロトタイプ

3回目に作ったプロトタイプは初めて使う人でも使いやすいホームに振り切ってみることにします。

1、2回目と同じようなインタビューを行った結果、このプロトタイプは、どうやって操作するかわかりやすい反面、慣れてきた時に鬱陶しいとのこと。

ただ、僕たちが届けたい想いは今までのプロトタイプに比べて伝わっていたように感じます。改善すべきポイントはたくさんあったものの、ホーム画面としてどうあるべきかが3回の改善を繰り返したことでようやく見えてきました。

コンセプトを固める

インタビューを改めて振り返ると、経営者の数だけいろんなストーリーがありました。起業した想いもバラバラだし、今やっている業務も職種や業種が同じであったとしても全然違う。

ただ、実際に経営者にあったからこそ、そんな経営者の想いをサポートしたいという気持ちは強まっていました。

freeeのビジョンは「アイデアやパッションがあればだれでも、ビジネスを強く育てるプラットフォーム」と掲げているが、経営スタイルはスモールビジネスの数だけ多種多様。

どんな経営スタイルであっても、freeeとしてスモールビジネスを支えていきたいし、支えることができるということを伝えられる、活用してもらえるホーム画面に育てていきたい。

この想いがfreeeのホーム画面のリニューアルの軸になったことで一気にリニューアル案の方向性が固まっていきます。

リリースまでの道のり

ホーム画面のリニューアルは影響範囲がかなり大きいため、いきなり全面展開することはせずにβ版をリリースし、アンケートでフィードバックを集めつつ致命的な課題がないかを見ながら丁寧に進めていきました。

アンケートもプロダクトマネージャーと全て目を通し、Twitterでの反応も見つつ本番リニューアルに向けて追加対応すべきことがないかを議論。細かいUIの修正も含めて、8~9個近くの要望に対応してリニューアル版をリリースしました。

対応した要望一覧はこちら

このプロジェクトの学び

1年半近くの長期プロジェクトを終え、その中でも特に大事だと感じた学びを紹介します。

「どんなに要件が曖昧なプロジェクトであっても、自分たちが届けたい想いを大事にする」

ホーム画面という誰もが使う画面の大規模リニューアルをした後はいろんな意見があると思います。UIを変えただけでも変化を嫌う人は多くいると思います。ただ、すべての要望を叶えることは難しい。だからこそ、自分たちが届けたい想いをまず明確にして、その視点から要望に真摯に向き合うことで、やるべきことに集中でき、リリースした後の評価もしやすいと思います。

「大きなリニューアルをするときは検証しやすい範囲でやるのが大事」

ユーザーインタビューでは、インタビュイーが細かい機能変更やレイアウトの変更に気を取られてしまい、コンセプトが正しく評価できない場面がありました。その学びを活かし、今回のリニューアルでは、コンセプトに関わらない機能は見た目の変更に留めてリリース。その結果、リリース後も大きなトラブルなく落ち着いております。(今のところ)

最後に

freeeに入社して以来、最も長期的且つ、大規模なプロジェクトがひと段落してほっとしているところですが、今回のリニューアルはfreeeのミッション達成に向けた第一ステップに過ぎません。これから一緒にfreeeのプロダクトを育てていけるデザイナーを絶賛募集しております。

jobs.freee.co.jp

明日はアクセシビリティで一発当て太郎こと、magiさんです。お楽しみに!

*1:OEMアカウント・アドバイザーアカウントは2020年12月21日以降新ホーム画面が適用される予定です

プロダクトコードの静的解析にhorusecを入れた話

この記事はfreee アドベントカレンダー16日目です。

みなさんこんにちは。PSIRTというチームでエンジニアをしているlivaです。PSIRTという聞き慣れない単語ですが「Product Security Incident Response Team」の略で、文字通りプロダクトのセキュリティにフォーカスしたチームです。元はCSIRT(Computer Security Incident Response Team)でまとめてやっていたんですが、今年の夏頃から分かれて動いています。業務内容は今までと何一つ変わっておらず、AWS触ったりGCP触ったりプロダクトチームへセキュリティ関係のことで首突っ込んだりとプロダクトのセキュリティに関することは色々やっています。


さて、今回の話題はタイトル通り「プロダクトコードの静的解析」についてです。 今まで各プロダクトごとにツールが運用されていたりいなかったりで「統一されたなにか」はありませんでした。課題感としては入社してからずっとあったので、PSIRTになったタイミングで統一したものを導入することを決めました。ここではその話をしたいと思います。

1. 持っていた課題感

以前から「プロダクトコードに存在する脆弱性を把握できていない」という課題がありました。出来上がったコードを動作させて脆弱性を探し出す一般的な脆弱性診断の仕組みは整備されていて、リリース前後や定期診断にて脆弱性を検出することはできていました。

しかし、この運用の場合、プロダクトが実際に動作してからチェックされるために、ある程度出来上がった状態で診断を行います。ここで脆弱性が出ると手戻りが大きくなり却ってコストが膨らむことになります。また、仮に根本的な設計変更が必要な脆弱性が検出された場合、リリースが遅れることにもなってしまいます。会社としてもチームとしてもあまりいいとは言えません。またSQLインジェクションやクロスサイトスクリプティング等、コードの書き方次第で発生してしまうことが多い脆弱性は「コードを書いた時点で検出されることが理想」と考えていました。

2. 静的解析とは

コードを動作させずにテストしていく手法です。コードを動かすことがないため、CLI上で動かしやすいです。また、IDEに仕込むタイプのものも数多く存在しているので、コードを書いてる最中にリアルタイムでテストが走り、修正することができます。

Rubyだとrubocop、JavaScriptだとESLintが該当します。各言語に存在するLinterのようなものがイメージしやすいと思います。この記事で話すようなセキュリティツールとしては、RubyのBrakeman、Goのgosecなど、こちらも各言語ごとにツールが存在しています。有償ツールも現在は相当数存在していて、特に海外企業が力を入れているような印象があります。いくつか調査しましたが記事の内容から逸れていくのでここでは割愛します。

ちなみに、こういったセキュリティの静的解析を行うことをSAST(Static Application Security Testing)と呼ぶことがあります。重要用語ではないですが、一単語として覚えていてもらえればなにかのときに役立つかも知れません。

3. 導入することのメリット

いくつかあると思いますが、最大のメリットは「開発工程で見つけることで手戻り工数やコストが減らせる」ことです。最近話題の「Shift Left」という考え方になります。後工程でやっていたことを前工程でやるようにして手戻りを減らし、工数やコストを削減することです。手戻りや後からの差し込み対応を減らすことで開発チーム全体の開発速度向上を見込めます。「チームの生産性向上」というのがいいんでしょうか。抽象的な言葉なのであまり好きではないですが、そういった効果が見込めます。

4. freeeでの導入計画

freeeでは導入するツールを全体で共通化したかったため、選定条件をいくつか出しました。

  1. 主要プロダクト・サービスで使用している言語に対応している
  2. 検出箇所のハイライト機能がある
  3. GitHubにあるプライベートリポジトリに対してスキャンが可能
  4. スキャン対象外リストの作成が可能
  5. ダッシュボード機能がある
  6. 会計フリーをスキャンしても落ちない
  7. CI対応

まず1ですが、弊社の主要プロダクト・サービスはそれぞれで言語が分かれているため、全ての言語に対応しているツールを探す必要があります。「SAST tool」で検索するといくつかでてくるのですが、網羅しているものがなく、これと言ったものをさがすためにかなり苦労しました。

2,3,4は「検出されたけどどこで?」「プライベートリポジトリ対応してないの?」「スキャン対象外リスト作れなかったら過剰検知の対応どうするの?」等の問題が多発するため、セキュリティツール選定においては重要事項です。

5は開発者全体が見れるように共有を行いたかった意図があります。スキャン結果は外部公開するものではないですが、社内に対しては情報統制する必要性はありません。開発者が全体の傾向やどういう対応がされているかの情報を共有できることで出てくるメリットの方が多いと思います。

6は弊社では最重要事項でした。弊社のメインプロダクトである会計フリーで回らなければ価値がないくらいです(当社基準)。しかしリポジトリが巨大すぎて、スキャンを実行すると(ローカルでもEC2上でも)リソースが逼迫して落ちていく事象が発生しました。過去にも有償ツールならさすがに大丈夫だろうと試したところ、2週間経ってもスキャンが終わらないこともありました。「こんな巨大なのを回し切るツールあるのか…?」と思っていましたが、探せばあるものですね。

7は当初からPull Requestで実行するCIジョブの一つとして回す予定があったため条件に追加しています。

以上の条件の他スキャン速度等も含めて検討し評価を実施しました。その中で選んだのはhorusecという海外ツールでした。

5. 具体的にどう入れたか

horusec導入にあたりいくつかフェーズを切りました。

  1. horusec dashboardを立てる
  2. 1次リリースプロダクトのスキャンを実施し脆弱性を洗い出す
  3. horusecの設定を埋め込む
  4. CIジョブとして登録する

1の工程が1ヶ月程度かかりました。公式の構成をそっくりそのままAWS上に構築し、以下の図のようなdashboardを社内限定で公開するようにしています。

f:id:LIVA:20201214143001p:plain
Dashboardイメージ図

全体の構成としては以下の図のようになります。

f:id:LIVA:20201214134041p:plain
freeeでのhorusec構成図

2の工程はすでに何かしらのツールがCIに組み込まれているプロダクトをいくつか選びました。既存脆弱性の修正にかかる工数が少ない(ハズ)というのが一番の理由です。なにもないところにいきなり入れると何が起きるかわかりませんからね。大事です。 手元でhorusecを回し、脆弱性をリストアップした後「これは無視してもOK」「これは修正しよう」というようなトリアージ作業を検出項目に対して行っていきます。同時にhorusecの設定ファイルを作成し、その中にリスクを許容する脆弱性の登録やスキャン対象外ディレクトリの登録等を行っていきます。(3の工程)

4でCIジョブとして登録し、無事スキャンが回り始めたらリリース完了となります。

ここまでを1次リリースとして現在最終段階を進めています。年末までに10プロダクトで稼働する予定です。

6. 諸々余談

ツール導入にあたって社内で「こんなことするよ」って情報を出していたんですが、特に反発はありませんでした。大体セキュリティって言うのは面倒なことが増えるので多少反発あると思ったんですが、そういった声は一切なかったので助かってます。もしかしたら見てないのかもだけどそれは気にしないことにします。

horusecのドキュメントの大枠はポルトガル語で書かれていました。一応公式ページには英語も用意されていますが、GitHub上で細かいところを追い始めると逃げられず、当初は四苦八苦してました。2週間程度翻訳しながら読んでると意外と読めるようになるもので、後半はあまり翻訳を入れることがなくなりました。英語に続きポルトガル語も読めるようになって変なところで成長を感じます。

システム周りの話でいうと、horusecは複数のサービスを立ち上げる必要があり、その相互依存が割と面倒でした。ユーザー管理下で作成することを意図していないのか、ドキュメントが存在しなかったのもあり、トライアンドエラーを繰り返して手探りで構築していました。大体は環境変数や設定ファイルに沿って素直に動作してくれるので、その定義さえ間違えなければOKという状態の作りでした。最近出てきたセキュリティスキャン系のOSSでも扱いやすい存在ですね。


freeeではエンジニアを募集中です。セキュリティに対して一家言ある方、巨大プロダクトのセキュリティに携わりたい方、一緒にやりましょう。 jobs.freee.co.jp

明日はUXデザイナーのはるたんです。最近会計フリーが大幅に変わったんですが、そのあたりの話をしてくれるようです。

お楽しみに。