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デザイナーのはるたんです。最近会計フリーが大幅に変わったんですが、そのあたりの話をしてくれるようです。

お楽しみに。

ストック型コストの怖さを理解して品質改善に取り組もう

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

freeeでQAエンジニアをしている石塚(@mishizuka99)です。

これまでWeb・モバイルアプリテストの自動化、品質向上のための関係者の巻き込み、手動テスト作成、テスト実行チームのマネージメントなどを7年ほどしてきました。その中で「感覚では分かっているけど伝えるのが難しかった」コストについての説明をしてみます。

(QA以外の方にも読んでいただきたいので用語や例は簡略化しています)


こんな経験はありませんか?

  • 効率を良くするための自動化施策のはずなのに、続けるほど苦しくなる(やめたいけど過去の自分を否定するのは悔しいから続けている)
  • いい施策を思いついたが人員や予算の確保のためどう関係者を説得すればいいかわからない
  • 開発者にテストをお願いされて喜んで引き受けたが、繰り返しやるテストなのでどんどん負担になってきた
  • 「いいテストの仕組みが完成しましたね!さて、次の期は何しましょうか」
    「あ、あれメンテが一生続きますよ!」
    「!?」
    みたいな会話をしたことがある

これらは継続的に積み上がっていくコスト(ここでは「ストック型コスト」と呼びます)のインパクトをイメージしきれてないために起きる問題です。


ストックとは

ビジネスで「ストック」「フロー」というと、収益モデルを指すことが多いです。

  • ストック型ビジネス → 月額・年額支払いなどで継続的に収益を上げるもの。(NetflixやSpotify、freeeもこれですね)

  • フロー型ビジネス → 売り切り型ビジネス。普通の小売など、継続課金でないもの。

ストック型は、初期の爆発力はないですが地道に規模を拡大していければとんでもないインパクトを出せるようになります。

これはコストに関しても同じことが言えます。最初は簡単だと思って始めたものが、続けていくうちにとんでもない負担となることがあるのです。


品質向上施策での例

前提

  • ここで言う「コスト」とはざっくりチームが費やす時間や費用をイメージしています
  • 「一定の成長を続けている企業」つまり社員数、ユーザー数、プロダクトが成長している前提の話です

繰り返し行う手動テストの例

「品質が悪いからユースケースを網羅した手動テストケースを作ろう!今後リリースする度にそのテストケースを回せば安心だね!」
そんなプロジェクトが始まったとします。

担当者はこう考えました。
「よし、1月にテストケースを作りきって2月に運用開始だ!そういえば3月に新機能でるからその分ちょっと3月は大変かな」 ぼんやりこんなグラフが頭に浮かびます

繰り返しやる系テストのコストの棒グラフ。縦がコストで横が期間。1月は高く、2月は低く、3月は2月より少し高くなっている

しかし拡大を続けるプロダクトに対し網羅的なテストを回し続けるとなると、実行コストはもちろんメンテナンス(仕様変更や新機能に追随するテストケースの作成)がどんどん発生します。

なので、少し引きで(長めの期間で)見るとこうなります 上記グラフの「期間」を長く見た棒グラフ。更に9本の棒が右肩上がりで追加されている

もちろん実際は直線ではなく曲線になったりデコボコしたりもするでしょう。ただ手を打たない限り増えつづけていくことに変わりありません

さらに引いて見ると、、、 繰り返しやる系テストのコストをイメージした棒グラフ。80本ほどの棒で右肩上がりのコストを表している。

これがストックの恐ろしさです!

これを踏まえると下記を考える必要があります

  • このコストの増加を少しでも抑えることはできるのか
  • 誰がこのコストを払い続けるのか
  • このコストの増え方に対してリターンがあると言い切れるのか

関係者間でこの認識が曖昧のままズルズルいくと、どんどん苦しでいった先に破綻も見えてきてしまいます。 特に四半期ごとに目標を設定する文化がある組織(freeeもそうです)では、認識のズレが起きがちになります。


自動テストはどうか

「手動テストはコストが掛かりすぎる、時代は自動だ!」と言う人もいるでしょう。

自動テストもいろいろありますが、手動テストの代わりになるようなE2Eテスト (プログラムしたとおりにブラウザやアプリを自動操作するテスト)で考えてみます。

テスターの動きをコンピューターが代わりに自動してくれるものなので、当然「実行」のコストは大幅に減ります。それ以外にもレポートや通知などコミュニケーションのコストも減らせます。

ただ仕様変更や新機能に追随するテストケースの作成は結局発生するので、対策を打たない限りコストが積み上がっていく構造には変わりません。

自動化は自分も好きなテーマですが、ストック型の脱却にはならないことは理解しておく必要があります。


開発チームとの協力が必要な場合

品質は全社で取り組むべきテーマなので当然他チームと行う施策もあります。

たとえばQAチームが開発者に「一緒にやろうよ」と持ちかける施策はこんなものがあるでしょう

  • 自動テストをやりやすくするためのラベルを作ってもらう
  • 品質関連データが集計できるようタグを入れてもらう

ただ、このグラフのように実は開発者の負担が増え続けるケースだった場合、「こんな大変だって聞いてなかった!」となるかもしれません。 QAのコストと開発者のコストの積み上げ棒グラフ。全体は右肩上がりで、内訳は最初は同じ比率だが、期間が経つに連れて開発者の割合が増えていっている


さらに多くのチームを巻き込む場合

たとえば「社内でバグの報告するときには、QAが分析できるよう詳細な情報を書いてください」といったケースはさらに多くのチームを巻き込むことになります。

。セールス・サポート・開発・QAの4チームのコストを表している積み上げ棒グラフ。全チーム同じような割合で右肩上がりで増えている

こういったコスト負担について、全関係チームが納得感を共有できていることが大事です。


別チームからQAに依頼されるパターン

開発者から「バグが出てしまったので、こういうテストを今後毎回やってほしいです」と頼まれることもあると思います。 また、開発者から丸投げではなく、自動テストケースを作ってくれて「QAチーム忙しそうなのでテストは自分で作りました!」のような嬉しいケースもあります。 ただ、その後をQAが見ていくとなると継続的なコストを負担し続けることになってしまいます。

ストック型ビジネスがサブスクリプション「契約」に基づくように、ストック型コストの施策についても「契約」(ちょっと大げさですが)のような意識を持つことが必要です。


コストの上昇を抑えられそうか探る

コストが無条件に増え続けるのは、あくまで改善策を打たない場合です。当然対策をしていく必要があります

コストの予測を表す右肩上がりの積み上げ棒グラフ。コストが改善策により抑えられている場合の予測と、何もしない場合の差分を合わせた積み上げグラフになっている。

テスト系施策で改善例を挙げてみます

  • 情報共有の仕組みの改善
  • ノウハウの共有
  • テスト実行速度の改善 (インフラ周りの改善、冗長な実行を省く)
  • 実装速度の改善 (ツールの改善、リファクタ)

他にもいろいろありますが、ソフトからハードまで様々な対策をすることになります。そして「このコスト増加の角度だったらリターンのほうが大きい」「肌感的に改善策はたくさん出そうだから大丈夫」と言えるようになると、自信を持って施策を進めることができます。


「やってみる」が大事なのは変わらない

怖さを知る必要はありますが、考えすぎずに始めてみることも大切です(freeeにも「アウトプット→思考」という価値基準があります)。

ストック型施策のときは前述のリスクを認識しつつ「小さい範囲で始める」「期間を区切ってやる」などの考慮をしましょう。
そして、その初期段階の結果をベースに関係者に(そして自分たちに)「こんなにいいことが起こるよ」というビジョンを見せる(もしくは止めるという判断をする)ことが大事です。

まとめのチェックリスト

考慮すべきことをまとめてみます

  • 目的は何か
  • 積み重なっていくコストに見合ったリターンが会社全体にあるか
  • いつまでやるか
  • コストを下げられる見込みはあるか
  • コスト負担をするチームは納得しているか
  • どうなったら撤退するか

これらを意識することでインパクトの大きい施策を成功させて、会社にそして世の中に貢献していきたいと思っています。 みなさんも参考にしていただけたら嬉しいです。



お知らせ

明日はfreeeのセキュリティを守るlivaさんの投稿です。