Cloud Native Days Kansai 2019 (CNDK2019) に参加しました

こんにちは、人事労務freeeのアプリケーションエンジニアをしているid:tomoz6o9です。
チームたこやき(関西支社開発チーム)に所属しております。

昨年12月のfreee Developers Advent Calendarはお楽しみいただけましたでしょうか?

さて、少し前の話になりますが、 11/27-28で開催されたCloud Native Days Kansai 2019(CNDK2019)のうち、28日に開催されたConferenceにて、 弊社SREチームよりmanabusakaiid:renjikariがセッションに登壇させていただき、 また、エキシビションスペースにてfreeeブースも出展させていただきました!

グランフロント大阪のコングレコンベンションセンターにて開催された本イベントですが、同じビルにオフィスを構えているチームたこやきとしては、参加しない手はない!とはりきって、hatajoeと私の2名で東京から来たメンバーと共にスタッフとして参加させていただきました。

ブースの様子

我々のブースでは、恒例の?(Cloud Nativeとは関係ない)自作キーボードも展示しつつ、お越しいただいた皆様と交流させていただきました。

弊社がブース等を出しているとき恒例の、アンケートも実施しました。 確定申告をしたことがあるか?という質問でしたが、 結構みなさんご経験があるとのことで、まだ未経験の私としてはちょっと意外でした。 確定申告アンケート。「確定申告したことある」は31票に対して「ない」が17票

来ていただいたみなさんとは、弊社製品の話、チームたこやきの話、自作キーボードの話と幅広い話ができました。 特にキーキャップのノベルティはみなさん興味津々で見られていました。

セッション

ブーススタッフをやりつつ、セッションもいくつか聞いてきました。 セッションはどれも面白そうなものばかりで選ぶのも大変!

弊社SREチームのメンバーの発表では、Kubernetes監視・GitOpsについての登壇でした。

speakerdeck.com

f:id:tomoz6o9:20191213152243j:plain
manabusakaiのセッション

www.slideshare.net
f:id:tomoz6o9:20191213152204j:plain
renjikariのセッション

どちらもfreeeでの知見を惜しげなく披露!という感じで、普段SREチームにお世話になっている我々もなるほどと思いながら資料を見ました。

以下では私と同行していたhatajoeから、興味を持ったセッションを1つずつピックアップしてご紹介いたします。

分散システム内のプロセス間の関係性に着目したObservabilityツールの設計と実装

speakerdeck.com

マイクロサービスの浸透やクラウドの浸透に伴うオンデマンドな資源調達などによりどんどん複雑化しているシステムにおいて、未知のプロセス依存をどう把握するかという課題についての発表でした。 アイデアとしてL4レイヤで監視を行うアプローチをとり、 その実装としてtranctracerが紹介されました。 かなり実践的で、普段SRE的な仕事をしていない私でも楽しめる発表でした!

DockerやKubernetesが当然のように使われている世の中で、昨今ではサービスメッシュなどの話題も盛んですが、我々は大量にあるプロセス群とどう付き合っていけば良いのかについて、こういったモニタリングの手法についてもこのような形でどんどん多様化していくような気がします!

Production Ready Kubernetesに必要な15のこと

ここからは @hatajoe が代わってお送りします。 私がピックアップするのはこちらです。 speakerdeck.com

最近、業務で Kubernetes に関わることが多くなり、運用に関する勘所をまとめて聞くことのできた本セッションは個人的に価値の高いセッションでありました。

以下の15テーマについて語られ、40分という枠の中でひとつひとつ簡潔に勘所がまとめられており、とても印象に残っています。

  1. CI/CD
  2. Manifest Management
  3. Monitoring
  4. Initial Processing
  5. Graceful Shutdown
  6. Health Check
  7. Config Injection
  8. Maintenance / Upgrade
  9. Resource Management
  10. Scheduling
  11. Scaling
  12. Security
  13. External Traffic
  14. Tuning/Garbage Collection
  15. Stateful Application

特に、Graceful Shutdown についてや、Resource Management、Scheduling あたりは実際にハンドリングの難しい項目だと感じており、それらに対してどのようにアプローチしているかという話を聞くことができ、参考になりました。

まとめ

freee では、アプリケーションエンジニアが恐れることなくインフラストラクチャーをコードで実装できる世界が整いつつあります。 普段の業務では、その裏側を知る機会はそんなに多くないこともあって、今回のConferenceはその裏側に触れることの出来る良い機会だったと感じています。

freee ブースに足を運んで下さった参加者の皆様、ありがとうございました。 こういった機会を通じて、少しでも freee のサービスや開発に興味を持って頂けると嬉しいなと思っています。

最後に

freee では、サービスの信頼を支える SRE や、フロントからインフラまで一気通貫で開発したいアプリケーションエンジニアを募集しています。(東京も大阪も!)
カジュアルに話をするだけの機会もあるので、興味のある方は是非遊びに来てください!

jobs.freee.co.jp

プロダクトカンパニーの技術戦略

こんにちは、freee株式会社 CTO の横路です。

この記事はfreee developers Advent Calendar 2019の最終日です。

昨年のアドベントカレンダーでは新卒で入ってくる君たちへというお題で、freeeの新卒の期待値は「3年でスモールチームのCTO」であるという話をしました。今年は次のステップとして、100名を超えるような「大きなチームのCTO」になるとどんなことを考えているのか?なかでも恐らくイメージしにくい技術戦略の考え方について、freeeの事例を振り返りながら、わかりやすくお伝えしたいと思います。

技術トップの役割の全体像と技術戦略の位置づけ

プロダクトマネジメントのバイブルである「INSPIRED 第2版」に、大きなチームの技術トップの責務がよくまとまっています。

  • 組織
    • 従業員の採用とスキル向上に全力を注ぐ強力なマネジメントチームづくり
  • リーダーシップ(技術戦略)
    • 全社戦略において技術部門を代表し、企業の進路、M&A、つくる/買う/提携するに関する意思決定をサポート
  • 市場投入
    • 高品質/迅速な製品デリバリーで、競合に負けないことに責任を持つ
  • アーキテクチャ
    • 競争・成長に必要な機能性・拡張性・信頼性・セキュリティ・性能を提供できるアーキテクチャに責任を持つ
  • 製品発見
    • 技術やエンジニアリング起点で製品企画に重要な貢献をする
  • エバンジェリズム
    • 開発者、提携企業、顧客とのコミュニティでリーダーシップを発揮

これらの責務を技術系幹部で分担していくのですが、このなかで最も馴染みがないのが技術戦略ではないでしょうか。

事業が増え組織が大きくなってくると「やったほうがよいこと」「できること」が大量に出てきて、施策の優先順位が以前より分かりにくくなってきます。そこで目指すべきゴールに最短経路でたどり着くために、思い切ってやらないことを決めるのが技術戦略です。

freeeでは今年から本格的に技術戦略に取り組みはじめており、CTOがその責務を担当しています。

「何で突き抜ける会社か?」を起点に技術戦略を考える

そもそも戦略とは、あるビジョンをどんな道筋で達成すべきか?に答えるものです。何を目指すかによって戦略は大きく異なるため、事業会社の全社技術戦略はまず「何で突き抜ける会社か?」を起点に考えることが重要です。

freeeは「スモールビジネスを、世界の主役に。」という壮大なビジョンを掲げ、そのビジョンを具現化したプロダクト群を軸に事業を展開することで大きく成長してきました。freeeにとっては、いかにプロダクトビジョンを達成しながらビジネスとしても成長を続けるか?が至上命題です。freeeのようなプロダクトカンパニーにおける技術戦略とは、プロダクトとビジネスの成長をいかに技術でサポートするか?ということです。

freeeでは、以下のようにプロダクト事業ビジョン(社内では航海指針と呼んでいます)を起点に技術ビジョンや技術戦略を引いています。

f:id:yokoji:20191225123254p:plain
図1: プロダクト戦略にアラインした技術戦略

ビジョンや戦略は必ずしも明示されていないケースも多く、定期的に他部門のトップや経営幹部とコミュニケーションしながら自分なりに解釈していく必要があります。会議体の設計も重要です。

余談ですが、昨今は多くの企業が「テックカンパニー」を標榜していますが、時価総額1兆円以下の規模の企業で純粋に技術をコアな競争力にした事業で勝っているIT企業は現状ほぼないという認識です。将来ビジョンやマーケティングメッセージとして「テックカンパニー」を打ち出すのはもちろん構わないですが、技術戦略を考える上では、数年スパンではプロダクトで勝つ会社なのか?セールスで勝つ会社なのか?マーケティングで勝つ会社なのか?をクリアに認識しておくことは重要です。

プロダクトで勝つための技術仮説を立てる

次に、プロダクトで勝つための技術仮説を立てます。社内外のさまざまな情報とこれまでの経験を総合し、自分なりに確信を持てるストーリーをつくります。

例えばわたしは、「今後もプロダクトラインナップを増やすことで事業成長を狙うなら、仮説検証がとにかく速くて売れる・使われるプロダクトがどんどん出るというケイパビリティをfreeeの競争力に出来ないか?現状の開発投資比率を踏まえると、もっと基盤投資を加速させるべきではないか?」という仮説を立てて、市場からファクトを集めて確信を深めアクションに落とすというアプローチをとっています。

以下の図は、プロダクト開発のプロセスにおける、技術による付加価値の連鎖イメージです。かなり抽象的ですが、それぞれの歯車が回って正のサイクルが働けば、勝てそうなイメージが湧いてきませんか?

プロダクトカンパニーの技術バリューチェーン
図2: プロダクトカンパニーの技術バリューチェーン

仮説の詳細や背景は話すと長くなるので、興味ある方は直接ご連絡ください。ランチでもご一緒しましょう。

技術による価値連鎖を積み上げていく順番

freeeのプロダクトはSaaSの形態で提供しており、顧客からのサブスクリプション課金によって売上が積み上がるビジネスモデルです。SaaSのセオリーやプラクティスについては米国を中心にすでに広く浸透してきており、業績や将来性をみるための指標も成熟してきています(手前味噌ですが、このあたりのキャッチアップには弊社CEOによるSaaSビジネスモデルの解説記事がおすすめです)。SaaSは初期投資のために大量の資金調達が必要なビジネスモデルであることからも、よいプロダクトを顧客に届けるだけではなく、SaaSに求められる成長を担保するための技術投資も重要になってきます。

freeeではこれまで、SaaSやリーンスタートアップのセオリーに則りざっくり以下の順番で技術投資をしてきました。 それぞれのステップは多少前後したり並走期間もありますが、概ねこの順番だと思います。

1. プロダクトマーケットフィットへの到達

まず、最低限の機能を揃えることとコア機能の価値確立にフォーカスしました。ここで金融機関の自動明細取込と自動仕訳の仕組みを磨き込んだことが、後にfreeeにとって大きな競争優位性になりました。

コア機能以外はなるべく手を抜き、基盤技術はなるべく内製せずSaaS, PaaS, OSSを使いたおす方針でした。

図2で言うと、⑦をとにかく絞り、①②④をとにかく高速に回すことにフォーカスするイメージです。

2. より大きな市場の顧客にも価値を届ける

SaaSのセオリーでは、特定の小さなセグメントでプロダクトマーケットフィットを達成したあと、新規顧客の売上規模を伸ばすために、投資を加速させながらより大きなセグメントへの価値提供を目指してプロダクトを拡張していきます。freeeではまず個人事業主向けの確定申告プロダクトからはじめて、給与計算・税務申告など周辺業務のサポートや、数百名規模の中小企業でIPOにも対応可能なようにプロダクトを進化させました。

図2で言うと、①②④を回せる規模を拡大しつつも、まだ⑦への積極投資はしないイメージです。アーキテクチャ的には、認証・課金などんの共通基盤を除いて積極的なマイクロサービス化などは行わず、各プロダクト毎にモノリスを太らせる選択をしました。

この過程でプロダクトの品質や開発スピードが著しく問題になるケースも増えてきたため、一括での負債返却や、問題を検知して暫定対応できる最低限の体制づくりをトップダウンの号令で行いました。

3. 本当に使えるプロダクトで顧客に長く価値を届ける

既存顧客からの売上の積み上げが大きくなってくると今度は、新規顧客の獲得よりもいかに既存顧客にプロダクトを使い続けてもらうか?が売上に効くようになってきます。SaaSのこの構造は、顧客が価値を感じてくれているからこそ使い続けてくれてくれるというロジックがfreeeの顧客ファーストな思想にマッチしやすく、プロダクトで顧客価値を追求すれば売上が上がる構造になっています。

これは前項の2の時期から始めたことですが、freeeではSFA・マーケティングオートメーションの導入、課金基盤の整備など、データドリブンなセールス・マーケティング・カスタマーサクセス基盤を構築しました。プロダクトの進化と並行して、どんな顧客層にどんな価値を届けるか?それはいくらなら使ってもらえるのか?どんな価値を感じた顧客がプロダクトを使い続けてくれるのか?ということを継続的に高速検証してアップデートしていくためにも技術基盤が重要です。得られた知見はプロダクトマネージャーが分析し、開発項目に落としていくイメージです。

図2で言うと、③に大きく投資するイメージです。

3. プロダクト・事業・組織のさらなる成長に向けて

主力プロダクトを中心にして屋台骨となる事業が育ってきた後は、既存事業の売上成長が一旦落ち着くリスクを想定して、さらなる安定成長のため将来の主力事業の種となるプロダクトラインナップを拡大していきます。ラインナップを増やしたときにいかにレバレッジが効くつくりにしておくか?は、戦略的に考えておくべき重要なポイントです。開発効率だけでなく、ユーザ体験や売り方にも大きく影響があるポイントです。

また、この頃になると恐らく開発組織も100名を超えてきて、主にコミュニケーションがボトルネックになって開発効率が落ちていきます。昨今のトレンド的には、DevOpsの文脈で、100名を超えても開発効率が落ちにくい、むしろ逆に上がっていくようなプラクティスがあることも分かってきています。

伸ばしたいプロダクトやコア機能の単位で、チームが独立して開発・リリース出来るケイパビリティが最もコアな競争力で、その競争力のテコを効かせるために、各独立チームが走るための高速道路や武器をつくって配る基盤投資が重要だと考えています。ここでもチームを独立させる単位は、開発効率やソフトウェアアーキテクチャの綺麗さだけではなく、売り方や組織論を考慮する必要があります。

freeeでは、プロダクト戦略や売り方の観点からマイクロサービス化するモジュールを決めたり、サービスは分けないまでもgRPCでIFを明示化してテストしいつでも分離できるように整備するような取り組み、マイクロサービス化ガイドラインや、新プロダクトが簡単に仮説検証できるフレームワークの開発などを始めています。技術的負債の返却に定常的に割くべき適正コストの肌感も分かってきたので、各チームが自律的に判断して適切な負債返却を行えるような指針も示していく予定です。

図2で言うと、⑤⑥⑦⑧に中長期でやりきる強い意志を持って投資を始めるイメージです。創業年数が浅く、優秀な開発チームを集められていた場合、⑤に必要なDevOps系のプラクティスの多くは既に実践できているケースも多いかもしれません。

まとめ

大きなチームの技術トップには必ず求められるが何をやっているのか分かりにくい技術戦略の考え方について、具体的にイメージしてもらいやすいようにfreeeの事例を交えながら紹介しました。課題解決を生業とするエンジニアのひとつのキャリアパスとして、これまで培った技術的センスと論理思考、情報収集力を活かして正解のない領域に仮説を立ててチャレンジするこの役割に興味を持ってもらえたら幸いです。

また、特に最近ますます増えてきたB2B SaaSスタートアップで開発部門を支えている皆さまにも、ひとつの事例として参考にしてもらえればと思います。正直に白状すると、創業時から経営に技術視点を持ち込めていたわけではありませんし、万事を戦略ストーリーに沿って進めていたわけではありません。後から振り返るとこういう構造だったよなということも多いですが、ご連絡いただければより詳細をお話しできます。

freeeは創業から7年が経ちますが、フロントエンドからインフラまでほぼすべての技術スタックが無事に一回転以上の世代交代をすることができました。freeeには運良く各技術領域に腕力と実行力を兼ね備えたエンジニアが揃っていたから、ボトムアップなアプローチで技術革新の波を乗りこなしてきましたが、次回の世代交代はボトムアップだけではうまくいかなさそうなポイントが既に見え始めています。ベストな技術選定がボトムアップかつ自律的に行われる環境を残すことで優秀なエンジニアの成長や採用を加速させつつ、現在はトップダウンの意思決定のテコを効かせるべきポイントを定義して、技術意思決定プロセスを整備しているところです。

通ってきた道だよ!という諸先輩方におかれましては、引き続きご指導ご鞭撻をよろしくお願いします。

技術戦略以外の技術トップの役割についても、Developer Blogでまた発信していこうと思っています。

開発メンバーの集合写真

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

この記事はfreee Developers Advent Calendar 2019の24日目です。こんにちは、freeeの@magi1125こと伊原です。あだ名は「アクセシビリティで一発当て太郎」です。いまはデザインリサーチチームのマネジャーをやっています。

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

developers.freee.co.jp

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

12月26日追記: 本記事にインスパイアされたとのことで、@masup9が同様の振り返り記事をまとめています。こちらもぜひご覧ください。

developers.cyberagent.co.jp

ユーザーとの出会い

今年のホットトピックとしては、アクセシビリティを必要とするfreeeユーザーと出会うことができた点が挙げられます。ふくろうアシストという屋号で視覚障害者向けのPC講師業を営む河和さんは、NVDAというスクリーンリーダーによって会計freeeを使っており、その様子を取材することができました。なおiOS版のfreeeも併用しているとのことです。

写真:ふくろうアシストへ訪問した際の記念撮影。河和さん、中根さん、RyoAbeが笑顔で写っている

実際に利用している状況のデモも行ってくださいました。なお、freeeの全盲エンジニア中根さん(@ma10)は事前にfreeeのアクセシビリティ上の課題を把握しているわけですが、河和さんもほぼ同じ課題認識であり、「そうそう、ここが厳しいんだよね」と盛り上がりを見せる一幕もありました(直さねば……!)。

www.youtube.com

同様に、スラッシュという視覚障害者向けのパソコン教室を運営している山賀さんはAndroid版の会計freeeを利用しており、実際にユーザーフィードバックも寄せてくれています。

www.youtube.com

アクセシビリティが商談にも関わる

もうひとつの象徴的な出来事は、聴覚障害がある方に対し「UDトーク」という音声認識・文字起こしアプリを使っての商談にトライしたことです。

商談にあたるスタッフが普段通りに発話で対応でき、またデモ画面を見せながら説明するにはチャットより音声認識の方がやりやすそうだというのが、その理由です。

写真:UDトークを使って音声を文字起こししつつ、リアルタイムに修正しながら商談を行っている様子

一般社団法人しかくでオンライン手話教室などを運営する伊藤さんに、商談に際しUDトークでのコミュニケーションをお願いし、実際に料金プランに関する質疑応答などを行うことができました。完全とはいえないものの、商談自体はきちんと行うことができました。

www.youtube.com

この他にも、スクリーンリーダーで利用できる人事労務ソフトを探しているという会社様や団体様からお問い合わせいただき、アクセシビリティを前提とした商談も数件ほど発生しました。

昨年に全盲エンジニアの中根さんが入社し、個人事業主として、またfreeeの従業員としてプロダクトを活用する中根さんの存在によって、アクセシビリティを必要とするユーザーが可視化されました。しかし、中に居る人が関わるのと、外にもユーザーが居るのとではまったくインパクトが違います。会社の外にもユーザーが実在するということは、それがセールス、導入支援、サポートの対象であると認識されるという点で非常に大きな影響がありました。

ユーザーにリーチするために

上記のように、いままでは製品開発上の話に留まっていたアクセシビリティの話が、実際に事業にも関わってくるという点で、さらに現実味が増してきました。

こういった状況を生んでいくために、広報にも力を入れました。もっとも大きいものとしてはフジテレビで特集されたことでしょう。中根さんを中心に約5分間に渡り、freeeのアクセシビリティへの取り組みが紹介されました。個人的には、地上波で「ウェブアクセシビリティ」という言葉が使われたのは画期的なことだと考えています。

www.fnn.jp

加えて、以下4件の記事もリリースおよび取材対応し、ここからユーザーとの出会いや商談へと繋がる結果になっています。

www.freee.co.jp

jobs.freee.co.jp

prtimes.jp

mogumogunews.com

問い合わせフォームに「アクセシビリティの問い合わせを受け付けている」ことも明言しました。

スクリーンショット:freeeのサポートデスクへのお問い合わせ画面。問い合わせの種類の選択肢に「プロダクトへのご要望(機能改善やアクセシビリティ対応など)」と記載されている

アクセシブルな製品が世間的にはまだまだ少ないなかで、それを必要とするユーザーは「言ったところで変わらない」「使えなければ他に行くだけ」とある種のあきらめをもっている可能性があります。逆に、提供側が明示的に取り組んでいることを表明すれば、アクセシビリティを必要とするユーザーが問い合わせを行う可能性が出現し、結果としてそういうユーザーが存在することを認知できると考えています。

アクセシビリティを推進するメンバーは、名刺に点字も入れました。

freeeの伊原の名刺。会社名、名前、メールアドレスの点字が入っている

点字を使用するユーザーに手渡すときに必要というだけでなく、アクセシビリティに取り組んでいることを意思表示するツールとして有効でした。晴眼者に手渡すとほぼ必ず「点字入れてるんですね」という話になり、そこからアクセシビリティの話に繋げられるという具合です。ちなみにすでに印字された名刺に対し、あとから点字を追加できます(日本点字図書館さんにお願いしています)。

開発への定着

こういった活動ができるのも、プロダクト側のアクセシビリティが少しずつ改善されているがゆえです。今年のリリースで大きかったのは、人事労務freeeにおける年末調整機能のスクリーンリーダー対応です。freee社では、中根さんが実際にこれを使って年末調整の情報提出を実施しています。

www.youtube.com

そのあたりの話は、新卒エンジニアのスポーンくんが詳しく書いてくれています。「アクセシビリティにワクワクした」良いですね!

developers.freee.co.jp

そのほか、各プロダクトで少しずつではありつつも着実にアクセシビリティへの取り組みが進んでいます。

  • 開業freee:サインアップ、ヘッダメニュー、ナビゲーション等に対し、キーボード操作やスクリーンリーダー読み上げの改善。
  • 会計freee iOS版:「自動で経理」をVoiceOverで操作可能に。料金プランなどのガイドページのアクセシビリティ改善。
  • 会計freee Android版:全体的にTalkBackでの読み上げを改善。料金プランなどのガイドページのアクセシビリティ改善。
  • 人事労務freee:従業員向け勤怠入力画面に対し、キーボード操作やスクリーンリーダー読み上げの改善。
  • 資金繰り改善ナビ:主要画面に対してアクセシビリティチェックを行い、致命的な問題点を把握。
  • 申告freee:キーボード操作およびコントラスト改善から取り組むため、現状調査を行い対策を検討。

会計freee iOS版のVoiceOver対応については、こちらの記事もご覧ください。具体的な対応方法を解説しています。

developers.freee.co.jp

なお、改善プロセスとしては以下のような形です。

  • プロダクトごとのOKRにアクセシビリティ改善を盛り込む
  • アクセシビリティチェック方法をドキュメントやハンズオンでサポート
  • 課題が見つかったらバグとしてJIRAやGithub Issueに記載
  • スプリントで改善を回していく

アクセシビリティチェックについてはドキュメントとハンズオンを組み合わせてチームで進めてもらうようにしました。

スクリーンショット:「俺のアクセシビリティチェック」と題したドキュメント。ツールやスクリーンリーダーを使ったチェック方法を記載している。

結果として、スプリントレビュー時にコンスタントにアクセシビリティ改善に関する内容が挙がってくるようになりました。

アクセシビリティ向上を社内に伝えるスライド。開業freeeのメニューのキーボード操作を可能にした旨が、スクリーンショットとともに記載されている。

こういった取り組みが形になっていった結果、開発者向けイベントで登壇するメンバーも増加しました。特に関西支社は、開発メンバーで団結して取り組んでいる印象があります。

developers.freee.co.jp

freeeでは、このようなプロダクトごとの個別のチューニングと、デザインシステム「Vibes」の適用による包括的な改善という両面からアクセシビリティに取り組んでいます。そのあたりの詳細はぜひid:ymrlのスライドと記事をご覧ください。

speakerdeck.com

developers.freee.co.jp

社内でもっと当たり前にするために

プロダクトをアクセシブルにするためには、そもそもアクセシビリティとはなにか、その意義はどこにあるのか、といったあたりを考え方の前提として組み込んでいくことが必要です。

その一端として、まずデザイナーのコアスキルにアクセシビリティを据えることになりました。前述のデザインシステムを運用していくという状況もあり、アクセシビリティへの理解はデザイナーとしては必要不可欠になったからです。

スクリーンショット:スキルマップ
freeeのデザイナーのスキルマップの一部。UI設計の欄に「業務要件を取り入れたUI設計を、サポートを受けつつデザインシステムおよびアクセシビリティ基準に則って行える」といった記載がある

2年ぶり2度めの、書籍「デザイニングWebアクセシビリティ」の著者(私です)による輪読会もスタートしました。

それと同時に、エンジニアやビジネス職問わず、アクセシビリティについてはfreee入社時に概念を理解してもらえるよう、新卒研修や中途入社時のダイバーシティ研修を都度実施していく体制になりました。

写真:中途入社向けの社員研修の様子。中根さんがアクセシビリティについてプレゼンテーションを行っている。

様々な利用状況を理解するため、定期的にスクリーンリーダーによるデモ会を開いたり、専門家をお呼びしての講義も実施しています。

写真:中根さんが自動で経理のデモをしている。手元のiPhoneで「自動で経理」を操作した結果が、スクリーンにミラーリングされている。
中根さんによる、会計freee iOS版の自動で経理を操作するデモの様子

写真:伊敷さんがPCに顔を近づけて画面を見ている。プロジェクターには拡大して色反転された画面がミラーリングされている。
アクセシビリティ専門家 Cocktailz 伊敷さんによる、ロービジョンにおけるPC利用状況のデモ

写真:伊賀さんによるスライドを使ったプレゼン。iOSの色の調整画面を表示している。
カラーユニバーサルデザイン専門家 CUDO 伊賀さんによるプレゼンテーション

きちんとした勉強会以外にも、気軽にアクセシビリティに触れられる場も用意しています。その一つがアクセシビリティサロンです。id:ymrlの発案により毎月の決まった時間に開催し、ただお菓子を食べながら雑談するだけの場が設けられました。生活におけるアクセシビリティの話がよく出てきて、これはこれで別の面白さがあります。

写真:小さなホワイトボードにアクセシビリティサロンの題字が書かれている。その裏にはお菓子や参加者の手が見える。

そこから派生したのが、先日記事になった「音だけで焼肉を焼く」という研究会、焼肉・イン・ザ・ダークというわけです。

developers.freee.co.jp

このように硬軟織り交ぜた形でさまざまなアプローチを行い、社内でアクセシビリティについて知っている人は少しずつ増えて来ています。しかし、それ以上のスピードでfreeeの社員が増えている印象もあります。

こういった記事を書くと「アクセシビリティへの取り組みは盤石である」という感じを受けるかもしれませんが、実際のところはあらゆる手を使ってなんとか「当たり前にアクセシビリティを考える人が多勢になる」という状況を作ろうともがいている……といった表現のほうが適切かもしれません。

今後はより研修の体制を強化していくと共に、freee アクセシビリティーガイドラインを制定し(中根さんが執筆しています)、それをプロダクト以外にも共通して適用することで、freeeのアウトプット全体がアクセシブルになるように取り組みを進めていく予定です。なお、このガイドラインは一般公開する想定です。お楽しみに。

スクリーンショット:freeeアクセシビリティーガイドラインの表紙。

業界でのムーブメント化に向けて

記事の冒頭で、アクセシビリティを必要とするユーザーに出会ったり、商談が発生したりというトピックをご紹介しました。これも、現時点では針の穴に糸を通すような確率で偶然出会うことができ、かつfreeeのアクセシビリティはまだ高くないにも関わらずなんとか使えるという高度なスキルを持つ人だったからこそ成立している話です。

今年の11月、サイトワールドという視覚障害者向け総合展示イベントにて「NVDA相談会」というセミナーに登壇しました。スクリーンリーダーの日本語化や普及を行っている方々と、B2B向けクラウドソフトを提供しているクラウドサイン、ChatWork、サイボウズ、freeeの面々が共に出演し、視覚障害当事者における就労環境の現状や、各クラウドソフトの対応状況などを意見交換するというセッションでした。

写真:NVDA相談会の会場の様子。着席する参加者と、登壇者、スクリーン。

私がこのセッションで感じたことはふたつあります。ひとつは、アクセシビリティへの取り組みを話すなら、もっと積極的に「必要とする人」のもとへ行って話さなければならない、ということです。開発者コミュニティのあいだで話題になっていても、それはユーザーには届きにくいものです。幸い、私はfreeeでユーザーリサーチを行う部署にいます。リサーチとデザインとアクセシビリティを分け隔てなく対応していくことが必須であるという思いを新たにしました。

もうひとつは、「もしかしてfreeeだけがアクセシブルになっても、世界は変わりにくいのではないか?」ということです。freeeを利用するためには、ある程度高度なスクリーンリーダーの使いこなしを要求されます。しかしながら、このイベント以前に視覚障害当事者や障害者団体にインタビューをした感じからすると、そのスキルにはかなりのバラつきがあるのが実情でした。

そもそも、ユーザーがそういった学びを得る状況を作るには、クラウドソフトを使いこなせるようになるコストを払う分のリターンがあると、就労環境を整備する会社側・団体側や、ユーザーにもそのことを理解してもらわねばなりません。それは会計や人事労務という領域を扱うfreeeだけでは、コストパフォーマンスが合わないはずです。

今回いっしょに登壇したクラウドソフトベンダーはもとより、スクリーンリーダーなどの支援技術ベンダーも含め、各社が協調(ないし競争)して、就労環境の改善に取り組んでいかなければ、と私は考えました。逆に言えば、そういったムーブメントが起こせれば、自身が開業したり、新たな雇用を創出したりといった社会参加への取り組みがより促進できるはずなのです。

俺たちの戦いはこれからだ

中根さんはよく「たとえ僕がfreeeを辞めたとしても、当たり前に取り組みが継続されるようになっていなければならない」と話しています。旗振りが変わっても活動が維持されるようにならなければ、ビジネスとして成立したとは言えません。

来年春、freeeには全盲エンジニアの野澤くんという、強力な仲間が参加してくれます。いまはインターン中ですが、すでに会計freeeのアクセシビリティ改善のPRをバンバン出してくれています。将来が非常に楽しみです。

joshi-spa.jp

careerhack.en-japan.com

このこともきっかけの一つとして、freeeでのアクセシビリティへの取り組みは進捗するでしょう。ただ、前述のような就労環境の改善、雇用の創出といった大きな夢に向かっていくには、さらなる圧倒的なムーブメント化が必要です。では一体どうすれば?

思えばfreeeは、特に気にすることがなかったけれども、中根さんにとってはアクセシブルな就労環境だったわけです。それはクラウドソフトを活用し、紙が一切ない職場だったからです。そのことは特に中根さんのためというわけではなく、社員全員にとってそのほうがいいから、そうなっていたのです(詳しくは昨年の記事を参照)。

そのように、うまくソフトウェア同士の組み合わせの妙を見出し、全体のメリットと整合を取っていくことで、アクセシブルな就労環境への道は近づいていくのではないか?私はそんな風に考えています。ウェブアクセシビリティは Essential for Some, Useful for All のはずだから。

君もやってみないか

freeeのミッションである 「スモールビジネスを、世界の主役に。」を実現するために、私たちの戦いは続きます。そして、それをより促進するための仲間を、私たちは募集しています。

www.wantedly.com

jobs.jobvite.com

まずは年明けの freee Tech Night に遊びにきてください。

freee-tech-night.connpass.com

そのほか、割とコンスタントにアクセシビリティ関連のイベントを主催したり、外のイベントに登壇したりしています(今年は、アクセシビリティ関連のイベントにfreee全体で18件ほど登壇したようでした)。見つけたらぜひお気軽にお声がけください。

明日は最終日!CTOの@yokojiです。

CEOが開発合宿で6年半ぶりにコードを書いてみた

freeeのCEOの佐々木大輔です。この記事は freee Developers Advent Calendar 2019の23日目です。

家で子供と遊ぶ筆者。娘を肩の上に担いでいる。
家で子供と遊ぶ筆者

今年は、freeeの恒例行事である開発合宿に初参加してきた(詳しい様子は12日の@_kemuridamaの記事をどうぞ)。freeeのリリース直後までは僕も独学でRails勉強し、微力ながらガンガン開発していた。この機会に再び開発をやりたいと思っていて、開発合宿には毎回行きたいと思っていたものの、タイミング合わずいけずにいたのですが、ついに参加することができた。

実はこの開発合宿の日(10/31)は freee の上場承認日のちょうど一週間前の日ということもあり、証券会社との交渉や上場承認後のロードショー(上場時に機関投資家等に向け事業内容などを説明するツアー)準備のための予備日として空けておいてね、と言われていた日でもあった。なんとか何も入らず開発合宿いけるとよいなぁと思っていたが、無事念願が叶ったのだ。

前日は、出張で福岡に行っていたので、早朝の飛行機で福岡から羽田に行き、羽田から今年の開発合宿の地、三浦海岸に向かった。素晴らしい秋晴れで、宿舎に向かうつもりが、ついつい海岸まで引き寄せられ、浜辺までたどり着いてしまったものの、なんとか軌道修正して宿舎に到着。

合宿会場近くの浜辺の写真

着いたはよいが、ここで問題発生。開発合宿で何をやるか、全く決めていなかった。なにかできそうなことないか聞くと、ちょっとしたリファクタをやってはどうかという話。Railsだけで済むので、これならできそう。とはいえ、2013年3月にfreeeをリリースした後からほぼfreeeのコードベースを見るのは初めてで、事前に予習とかしておこうかなと思っていたが、結局できないでいた状況だったので、とても不安でもあった。

会議室のいちばん後ろの席でPCを操作する筆者
開発合宿でコードを書く筆者

いただいたお題はとあるコードをservice layerに移す、というお題。「え? service layerって何?」とも思ったが、ウェブ上のドキュメントみたり、ディレクトリ構成からなんとなく雰囲気を推察して、とりあえずやってみることに。rails console とか、ローカルでの動作確認の仕方とか、ほぼほぼ忘れていたけれど、意外とカラダが覚えている部分(Control + Cとか)もあって面白かった。そのあたりを思い出すとエンジンがかかってきて、昼飯の時間が惜しく感じた。程なく、タスク完了。GitHub 上の Organization からも外されていたので、一つ前の僕からのプルリクは2013年5月21日。実に6年5ヶ月ぶりのプルリクを投入。

すると、freeeエンジニアからの暖かい、辻斬りならぬ辻レビューが殺到!これは、ある意味お祭り騒ぎ的で、さすが開発合宿。ごもっともな、コメントに対応して、再度コミット。小さなリファクタであるものの、ものすごい達成感。

Pull Request一覧画面のスクリーンショット。2つのPull Requestにそれぞれ34件と24件のコメントがついている
CEOのPull Requestにはたくさんのコメントがついた

こりゃなんでもできるのではないか、という錯覚に陥り始めたので、もっと本格的なタスクを所望すると、ちょうどよいのがある、ということで、freeeの「支払依頼」という機能の一覧画面に日付によるソート機能を追加することに。

こんなの余裕かな、と最初は思ったものの、マイクロサービスをまたいだリクエストが絡むところでもあり、思ったよりも苦戦(当然、リリース当初のfreeeにはマイクロサービスはなかった)。エンジニアの諸先輩方に、たまにお世話になりつつ、いろいろやってとりあえずバックエンドはしっかり動いている状態になったときには、もはや深夜0時前。一区切り着いてしまったせいで眠気に襲われたので、コンビニでレッドブルを大量に購入して、皆に差し入れつつ、そういえば、7年前にTechCrunch Tokyoのスタートアップバトルでライブデモする直前には、その準備で徹夜しつづけ、しまいにはユンケルのレッドブル割りとか飲んでたなーというほろ苦い(実際に苦い)思い出を思い出したりした。

2012年11月、はじめて本番環境で動作したfreeeを表示したPCのモニターを撮影した写真
2012年11月、はじめて本番環境で動作したfreee

そこから先は、手探りでフロントエンド頑張って、ついに「できたっ!」という瞬間が訪れたのが午前2時半。いやー、自分のつくったものが動いているということの喜びを思い出し、感無量。そういえば、freeeをリリースして以降、コードを書かなくなり、「コード書いてたころは楽しかったな」と思うこともしばしばあったが、「そうそう、この楽しさだ」というのを強烈に思い出すことができ、ある種6年半分のリフレッシュをすることができてしまった。

後日談として、このプルリクは見事にQAを通らず、修正が求められたが、僕はそのまま海外投資家ロードショーにでかけてしまっていて、開発環境のはいったPCを返却してしまっていたので、僕には修正するすべがないため、him0くんに最後面倒を見てもらったことについては、猛烈な感謝をしている。

また、さらに興味深い後日談もある。

freeeは、SOC1 Type2 保証という監査を監査法人より受けている。上場企業の会計システムを開発運営するに相応しい開発・運用プロセスを回せているということを保証する監査だ。

僕のプルリクはサンプリングされ、監査対象となり、監査法人の方にレビューいただいたそうだ。

そこで、監査法人の方が
「エッ、社長も開発するんですか!?」
「実際にこのコード書いてるんですか?誰かに書かせてるとかじゃないんですか?」
「めちゃくちゃレビューで言われてますね……」
と、社長がコードを書いてプルリクを送っていること、それが従業員に手厳しくレビューされ修正点を指摘されていることに驚くという面白が発生したそうだ。

ある意味、CEOであろうとも、フラットにメンバーからレビューや牽制を受け、物事を進めているということが明確に理解されたとのことで、いい機会であった。

freeeは、先週より上場してパブリックカンパニーとなり、序章から第1章に幕を移し、なお一層スピード感を高めて、世の中に価値を届けていく。その転換点の中で、このように改めて、自分たちの製品がどのようにつくられ、どのように動いているのかと集中的に向き合い、そして freee を最初に開発したときの原点とも言える喜び、すなわち「動く喜び」を味わうことができたことは、原点に耐えるタイミングとしてもベストだったと思う。

また、来年も参加したいと強く思ってます。

明日はミスター・アクセシビリティこと @magi1125 です