freee支社開発組織の進化

こんにちは、freee中部支社でオフィス長をやっています。山崎です。

今日はfreeeの支社開発組織を紹介したいなと思っています。

これまでfreeeの支社開発組織は関西だけでした。 しかし、freeeが関西で開発組織を立ち上げてから1年半が経ちました。

developers.freee.co.jp

から半年が経ち、中部にも開発組織が出来ました。

この半年の間にfreeeの支社開発は関西・中部にまたがって1つのプロダクトを開発している体制に進化しています。 コロナ禍の中でfreee支社開発組織の進化をお届けします。

チーム・体制

チームはここ半年でほぼ倍になりました。 昨年12月の13名から22名名までに増えました。

これまではチームで開発を進めるのに必要な職種をバランスよく揃えている状態でした。 そのおかげでチームには様々なロールのメンバーが在籍しています。

存在するロールはこんなにあります。壮観です。

  • プロダクトマネージャー
  • スクラムマスター
  • エンジニアリングマネージャー
  • UXリサーチャー
  • UXデザイナー
  • エンジニア
  • QA(Quality Assurance)
  • SRE

また今は組織拡大のためにチーム分割にトライしています。 現在はチームは3つあります。

各チームで大きく裁量を持って仕事をしており、技術調査、スケジュール調整、リリースに責任を持っています。 裁量の一つにチーム名も自分たちで決めることができます。

freee OSAKAの2チームは投票でチーム名を決めることにしました。 結果、freee OSAKAのチーム名はタコノリ、カツオブシになりました。 freee OSAKAは通称たこ焼きチームという名前で、タコノリはたこ焼きチームのアオノリっていう意味でタコノリです。

チーム名が投票で決まった様子です。

アオノリとカツオブシが並んでいるスライド
アオノリとカツオブシがチームのモチーフとすることが発表されたスライド

投票結果が表示されているスライド
投票結果で厳正に決まったことことも発表された

みそかつの名前はノリで決めました。

みそかつが皿に乗っている絵
みそかつチームのアイコン

これで晴れて支社開発組織のチームは食べ物で一貫した名前を冠することになりました。

一方でQAやロードマップの策定、SREなどは共通でプロダクト専任の方がいます。 チーム分割しつつも共通で使えるリソースは共有し、全体で開発速度を上げるための取り組みをしています。

開発しているプロダクト

支社全体でプロジェクト管理freeeを開発しています。

前回の記事では人事労務freeeの勤怠と新規プロダクトを開発していますと書いていました。

当時は明かせませんでしたが、とうとう今年の4月にプロジェクト管理freeeをリリースしました。 👏👏👏👏👏 これによって、支社開発組織で1から作るプロダクトを作ることを実現しました。

freeeのロゴの下にプロジェクト管理freeeという言葉が書かれている
プロジェクト管理freeeのアイコン

また、これまでに18個以上の追加機能をリリースしています。 頻度にすると3機能/月のペースです。

リリース情報のサイトのキャプチャ画像
リリースinfoが乗っているサイト

チームも増えたので今後もこのペース以上の速度で、upate情報のページに有る追加機能をがんがんリリースしていく予定です。

施設・開発環境

freee関西支社は大阪の京橋にオフィスがあります。

休憩スペースのカウンターの上にfreeeのロゴマークが天井から吊り下げられている
大阪支社の様子

部屋の中に机が並んでいる様子
freee社内

ミィーティングでメンバーが2mの距離を保ちながらプロジェクターで移された議事録を見ている様子
ソーシャルディスタンスを保ちながらMTGする様子

freee中部支社に開発組織が生まれました。 中部にはもともと営業部隊がいる拠点があったので、そこに開発組織も同居するようになりました。 1部屋ですがホワイトボードやディスカッションようのスペースも豊富なオフィスです。

これは中部開発組織で新機能のユーザストーリーマッピングを行っている様子です。

壁に貼り付けられた大きなホワイトボードに付箋を貼り付けている人が3人いる
ユーザストーリーマッピングをしている様子

結果としてfreeeの支社開発組織は2拠点で開発することになりました。

大阪、名古屋に丸が付けられている地図
freeeの開発拠点は大阪、名古屋の2拠点

またコロナ禍の中でチームはリモートと物理の両方をうまく使うように努力しています。

リモートではハングアウトで雑談の時間を設けたり、Remoを使って、一緒にいる雰囲気を作っています。

remo上のテーブルに5人の人が会話している様子
remo上のテーブルにめっちゃ人が集まることもある

また、週に2回までは出社できるようにしています。これはfreee全体としてはそうなっています。 これは物理で出社したほうが話が早かったり、信頼感の醸成に一役買ったりしています。 日次のミーティングも物理出社している人とリモートの人が混ざっています。

地域貢献

freeeの支社開発組織は引き続き発信する活動を応援しています。

大阪では umeda.go 主催 するメンバーがおります。

umedago.connpass.com

また名古屋では みそかつウェブ を主催するメンバーがおります。

misokatsu-web.connpass.com

各地域でのエンジニアレベルアップに貢献していきたいと思っています。 もし勉強会で見かけたら声かけてください。

freeeが支社を作る理由

そもそもfreee関西支社は「関西のエンジニア市場を盛り上げて変えていきたい」という理由で立ち上げられました。

これはfreeeの支社開発組織としてスケールした今でも変わっていません。 freee関西は関西のエンジニア市場を盛り上げて行きたいですし、freee中部は中部のエンジニア市場を盛り上げていきたい思っています。

freeeの支社で働いている人が楽しく面白い仕事をし続けることで地方のエンジニア市場を盛り上げていけるのではと思っています。

特にfreee中部開発組織では一緒に働いてくれる人を募集しています。気軽に声かけてください。

www.wantedly.com

社内向けシステムの社内アンケートをしてみたら結果が最悪だった事で多くの事を学んだ

こんにちは、freee Tech Night Online でラジオパーソナリティをしていたり採用管理システムを開発していたりする @noblejasper です。

先日「半年で採用管理システム作ったぜドヤ!」的な記事を書きました。リリース後しばらくして社内ユーザに「使い勝手どうですか?アンケート」というものを実施しました。今回はアンケートの結果やフィードバックから学んだ事を書きたいと思います。

学んだこと

今回アンケートを集め、改善を重ね、再度アンケートを集めて学んだ事はこれでした。

  • 定量化する事の大切さ
  • やることを整理して明確にしていく
  • 目的を”やる気が出るもの”に設定する
  • 積み重なれば結果は出る

どれも目新しいものはないかもしれません。私も知識として知っているものばかりでした。しかし知識ではなく経験をした事で今までよりも少し自信がついたので今回言語化してみようと思います。

最悪のアンケート結果

アンケートの1問目で「元のツールと比べて使いやすいか?」という最重要な設問を聞いてみました。

結果は最悪でした。「使いづらい(1)」から「使いやすい(3)」の3段階のアンケートで「使いづらい(1)」が36.6%の値でした。

棒グラフ。1が36.6%、2が31.7%、3が31.7%
元ツールと比べて使いやすいか?の回答分布

作ったばかりのツールなので使いやすい訳はないとわかってはいました。わかってはいましたが定量値で現実を突きつけられました。ちなみに採用に関わっている人はアンケート回答数よりはるかに多く、限定した期間で回収したアンケートです。そのため実際にはもっと多くの「使いづらい」と感じている人たちがいただろうと思っていました。

これはまずい

せっかく既存のツールから内製に移行したのに、使いづらくなってしまうのは本末転倒です。 自社のフローや理想像に向けてカスタマイズできるような理想像がドンドン遠ざかっていくような気持ちがしてきました。

「なぜ使いづらいのか」と向き合わないといけない

アンケートでは「使いづらい」と答えてくれたほぼ全ての人が一緒に「なぜ使いづらいのか」の理由も記載してくれていました。自分で作ったシステムなので読むだけで苦しさも感じました。逆に期待してくれているからフィードバックをくれているという嬉しさも感じていました。

理由を細かく書いてくれる人もいて、眺めていたら数が多すぎて無理なんじゃないかという気分になって憂鬱になってきました。私はしばしばこういう場面で茫然自失してしまいます。その度に考えるのは「整理すれば実は大した事ない」という事です。今回もそれにならって整理をする事で前進しました。

まずは1つ1つ何が使いづらいのかをタグ付けしていきました。全てのフィードバックをタグ付けしていった所、多くのフィードバックで共通するのは3つほどでした。

  • 他の面接官の評価が見づらい
  • 面接の評価の入力がしづらい
  • 候補者の情報が見づらい

もちろんその他のフィードバックもありましたが、明らかに複数人から指摘されている部分とそうでないものを分離する事ができました。優先度付けが出来てきました。

アンケートの結果を良くするにはどうしたらいいのか

結果を定量化し、フィードバックを整理してやることは明確になりました。しかしあまり乗り気にはなれませんでした。 「面接官の評価が見づらい」や「面接の評価の入力がしづらい」事を修正、改善するのは正直億劫でした。きっと私にとって意義や目的が小さかったのです。

今考えると実際のシステムはかなり使いづらい状態だったと思います。フィードバックを洗い出した時には「見えるし、入力できるのに!新しいシステムに慣れてないだけじゃないのか?」ぐらいに思っていました。お恥ずかしながら。

そこで上位の目的を設定しました。アンケートの結果を「使いづらい」から「使いやすい」にするという目的です。これはやる気が出ました。普段から話しをしていたり顔を合わせている仲間から定量的な結果をもらえることは私にとってとても大きなモチベーションでした。 実はこれは自分で気づいた訳ではなくチームでの目標設定をしている時に「修正後にアンケートを取って結果見てみましょう」という提案をもらった事で後から気づきました。

フィードバックをくれる環境は本当にありがたく、感謝してばかりです。この提案がなければ今でもまだモチベーションが低いままだったかもしれません。

ドラッカーの『マネジメント』に載っている三人の石切工の話や、ラダー効果というような話で知識としては知っていました。しかし実際に体験できたのはとても良い気づきと学びになりました。自分の目の前の事になると視野が狭くなってしまっていました。

1つ1つ実行していく

あとは3ヶ月後に実施する再アンケートに向けて改善を積み重ねていきました。 途中でバグもいくつか発生させてしまいましたが概ね順調に改善をリリースしていきました。

せっかくなので、リリースした中で特に好評だった機能を紹介させてください。

評価入力の自動保存機能が好評だった

面接官の評価を入力する画面はSalesforceのLightning Web コンポーネントという機能で実現しています。JavaScriptとHTMLとCSSを組み合わせてコンポーネントを作成しSalesforce内に埋め込む事が出来るものをイメージしていただけるといいと思います。今回の画面は面接官が開くページの一部分に表示されています。もちろんデモ用の画面です。

評価を入力するフォームのスクリーンショット。自動更新した表示を強調している。
面接の評価を入力すると内容を自動保存される

一般的なWebサービスでは入力中の文章が自動保存される機能は珍しいものではないと思います。しかし移行前の元ツールでも自動保存機能はありませんでした。

アンケートの回答の中で「ログアウトしてしまって入力内容が消える」や「面接中にメモを取れる欄がほしい」といったフィードバックがあった事から自動保存機能を作り随時書いてもらえる形に改善しました。実際の面接では、面接直後に別の用事や打ち合わせが入る事も少なくありません。面接中にこのフォームにメモを取って用事が終わった後に清書するような用途に対応する事が出来ました。

技術的には特別なものではないのですがSalesforce上で構築したシステムでは少しトリッキーなものなのではないでしょうか。

これ以外にも大小いくつかの改善を行いました。

ドキドキの再アンケート

絶望のアンケート結果から約3ヶ月後に再アンケートを実施しました。回答数は1度目のアンケートより少なくはなってしまいましたが、大幅な改善が出来たと感じています。

棒グラフ。1が3.1%、2が40.6%、3が56.3%
再アンケートの結果が一目瞭然で改善されていた

「使いづらい」が3.1%、「使いやすい」が56.3%でした。使いづらい」から「使いやすい」に改善出来たのではないでしょうか。

やっと理想に向かっていける舞台に立てたのでは?

今回アンケートの結果を改善出来た事で使い勝手は問題ないものに出来たと思います。 しかし私自身はやっとスタートラインに立てた気持ちです。ここまでは「使えるようにする」フェイズだったと考えています。

これからは「未来を創る」フェイズです。freee独自のフローなどに合わせたカスタマイズや理想の採用の実現に向けた機能を開発していきたいと思っています。

フィードバックを大切にする分化

思っていたよりエモくなってしまいましたが、freeeの社内システムを開発する気持ちが少しでもイメージ出来たのであれば嬉しいです。

freeeでは今回書いたように率直な意見やフィードバックをとても大切にしています。エンジニアだけでなく採用チームやビジネスサイドもフィードバックする/される機会が多くあります。フィードバックを自ら求めにいくタイプの人になりたいと思っています。

freeeではフィードバックが大好きな仲間を募集しています。一緒に働く機会があれば私に是非フィードバックをください!

jobs.freee.co.jp

Product Management Night Tokyo hosted by freeeの開催秘話

はじめに

こんにちは、freeeでプロダクトマネージャをやっている宮田です。今回はプロダクトマネジメントに関するイベントを主催させていただきますので、そのご紹介をしたいと思います。

早速なのですが、来る9/9 18時半より「Product Management Night Tokyo hosted by freee」を開催いたします!もしご興味がある方がいらっしゃれば、ぜひConnpass上のイベントページからご登録のほど宜しくお願いします。

イベントのアイキャッチ画像。イベントタイトル、日時、参加者6名の名前と顔写真が記載されているが記載されているの写真記載されている。参加企業はfreee、Sansan、ラクスル、プレイド、スマートニュース、metroly。
今回登壇してくれる各社のプロダクトマネージャの方々

Product Management Night

Product Management Nightとは、Product Management Festivalが協賛し、世界中で著名なスタートアップやGAFAなどが運営するプロダクトマネジメントに関するミートアップです。今回、Product Management Nightとしては、日本で初のOnline Meetupとして開催にこぎつけました。Product Management Festivalはミートアップ以外にもプロダクトマネジメントに関するカンファレンス(スイスとシンガポール)や調査レポート、各種トレーニングなどを展開しています。さらに今回弊社が運営することになり、freee Tech Night(社外のエンジニア向けに開催しているミートアップ)の運営陣が全面サポートの元、運営を行うことになっております。

今回のProduct Management NightはBtoB×プロダクトマネジメントをテーマに掲げたイベントになります。DXという標語はもはや普及しきり、さらに今回のコロナ禍によりリモートワークが余儀なくされ、様々な観点で業務の効率化、クラウド化が叫ばれています。そんな中、SaaSを中心としたBtoBプロダクトの導入を急がれている方々は多いのではないでしょうか。こんなニーズを汲み取り、様々なBtoBプロダクトを通して変革を主導されている各社プロダクトマネージャの経営陣やシニアな方々にお集まりいただき、その本質を紐解くものになっております。

Product Management Festivalとの出会い

思い返すと、私がProduct Management Festivalに出会ったのは2年前でした。アメリカにおけるプロダクトマネジメントのトレンドはあまり意識しなくても情報が入ってくるのですが、アジアやヨーロッパにおける実態を捉えるのは困難でした。いろいろ調べていると、ちょうどProduct Management Festivalが新たに2018年からシンガポールでも開催が決まり、しかもGAFAやアジア圏の著名なスタートアップ(GrabやCarousellなど)を中心とした講演がずらっと並んでいました。

実際参加してみると、かなり深い論点を取り扱ったものが多かったです。例えば個々のスクラム開発ではなく、Squad開発というSpotifyが提唱しているスタイルの導入と葛藤や、CPOを中心にしたプロダクトマネジメントの組織設計、企業のフェーズの変化に対応したプロダクトに対するカルチャー作りなど抽象度の高い議論から、SaaSのプライシングや分析結果とヒューリスティックをどう読み解くかなど、深い議論までが2日間でぎゅっと詰められていました。滝のようにインプットを受けて、帰路で振り返りをしていると、アジアでの開催にも関わらず、登壇者に日本人は一人もおらず、参加者としても私一人でした。 少し残念に思っていたのですが、逆にそのおかげもあり、日本でのProduct Management Night開催にあたって、お声掛けをしていただけたのです。

まとめ

実は一度、3月にオフラインにて今回のミートアップを企画していたのですが、企画の中盤になったころ、コロナが猛威をふるい、一旦無期限延期となってしまいました。その中で弊社はいち早くリモートワークを導入し、さらにfreee Tech Nightや全社合宿など数百人規模のイベントもリモートで実施することができました。

満を持して、今回オンライン開催とすることで、参加枠の上限を設けることなく、ご興味を持ってくださった方全員にご参加しただけるようになりました。また、昨今の状況を踏まえた「BtoB×プロダクトマネジメント」という鋭いテーマをかげられ、登壇者の皆様にご協力いただけたことも不幸中の幸いかもしれません。改めて、9/9 18時半より「Product Management Night Tokyo hosted by freee」を開催しますので、ぜひ皆様奮ってご参加ください!なお、開催は基本日本語となりますw

product-management-night-tokyo.connpass.com

「オブジェクト指向UIデザイン」の輪読会をやっています

こんにちは、freeeのUXチームの id:ymrl です。去年まではエンジニアだった ので、ブログの書き出しで「デザイナーです」って書いていいのか未だにドキドキしています。

以前の記事でデザイニングWebアクセシビリティの輪読会の紹介をしました。

developers.freee.co.jp

最近では「銀の弾丸本」こと「オブジェクト指向UIデザイン——使いやすいソフトウェアの原理」の輪読会をやっているので、その紹介をします。

gihyo.jp

輪読会の様子

「デザイニングWebアクセシビリティ」のときはランチタイムに集っていましたが、リモートワーク継続中の毎週金曜の今は朝10時からGoogle Meetで集まっています。

Google Meet のキャプチャ。時刻は10:12、8人集まっている
Google Meetに集まっている様子(普段はもう少し参加者が多いです)

輪読会の進行としては、毎週十数ページずつの範囲を決めて、気になったところや議論したいところ、あるいは感想を前日までか会の最初の10分ほどでGoogle Docsに書いておいて、のこりの40〜50分で各トピックを議論していくということをしています。

盛り上がったトピック

輪読会は毎回盛り上がっているのでいろいろ紹介したいのですが、あまりに長くなるので自分が印象に残っている議論を2つ紹介します。

おじぎをするATM

ただし、いろいろな業務アプリケーションのUIを設計していると、タスク指向の操作手順である「動詞→名詞」の構文の壁をどうしても打ち破れないことがあります。不自由な操作性であることはわかっていても、モードを作らざるを得ないのです。それはたとえば次のような場合です

(中略)

  • オブジェクトが(ユーザーのメンタルモデルにおいて)意識されていない、あるいはオブジェクトがひとつだけで選択の必要がなく、アクションの引数としての入力がタスクの大部分である場合。たとえばATM。

(後略)

ソシオメディア株式会社, 上野 学,藤井 幸多,「オブジェクト指向UIデザイン——使いやすいソフトウェアの原理」,技術評論社, 2020年, p30

この話をタネに、ATMがなぜタスク指向になってしまうのかには、いろいろな理由があるのでは、という話をしました。

  • ATMで行うタスクでは振込先口座や金額(アクションの引数)を選ぶ操作が多い。そういう手続きが多いからタスクベースなんだろうか。
  • 「サイフの中からキャッシュカードを選ぶ」操作によって、ATMの外で「口座」オブジェクトを選択している。その次のアクションから始まるのでATMの画面にはタスクが並ぶ
  • コンビニのATMではキャッシュカードを入れるところから操作が始まるが、銀行のATMではタスクを選んでから通帳やキャッシュカードを入れている

そんな話をしていくなかで、「ATMのUIは実は銀行によってだいぶ異なる気がする」という話になり、 「おじぎをしてくるATMはタスク指向が強い気がする」「おじぎは人に何かをしてもらうときの表現で、つまりタスク指向のメタファーなのでは」 という珍説で飛び出しました。

ATMのUIは気になるので調べてみたいのですが、いろんな銀行のATMを使う機会が(普段の生活がキャッシュレスだったりステイホームだったりなこともあって)なかなか作れず、まだ検証できていません。

抽象度の高い・低い道具

「オブジェクト指向UIデザイン」の中では「りんご皮むき機」と「果物ナイフ」を例にあげ、前者はりんごの皮をむく機能を手厚くサポートするがそれ以外の用途には使えない抽象度の低い道具、後者はりんごの皮をむく機能へのサポートは弱いが様々なことに使える抽象度の高い道具としています。そして、抽象度の高い道具をモードレスであり良いデザインとしています。

良いデザインとは、ユーザーに合わせたものではなく、ユーザーが自らを合わせられるものなのです。箸やバイオリンや自転車などの優れた道具は、人に合わせたというより、人が自らをどこまでも合わせていけるようにデザインされています。自分が気に入って使っている道具を思い浮かべてください。それはあなたの要求に細かく合わせて作られたのではなく、おそらくあなたの方が、 そのデザインに合わせて要求や行動を変えたのです。

抽象度の高い道具は、それ自体が決まった使い方を強要していないという意味で、モードレスです。同様に、抽象度の低い道具はモーダルです。そしてモードレスな道具は、それを使うユーザー自身の変化によって意味性を高めるという意味で、人と道具の相互発展をポジティプな方向に促すのです。これが、モーダルなタスク指向のデザインではなく、モードレスなオプジェクト指向のデザインを行うことの意義です。

ソシオメディア株式会社, 上野 学,藤井 幸多,「オブジェクト指向UIデザイン——使いやすいソフトウェアの原理」,技術評論社, 2020年, p50-51

抽象度の高い低いについて、自分たちの身のまわりにあるものはどんなものがあるのか、ということも考えてみました。

  • Photoshopのフィルタは抽象度が低く、ブラシは抽象度が高い
  • Photoshop Elements のような入門用ソフトは抽象度が低く、プロ用のPhotoshopは抽象度が高い
  • キッチン用品や食器で抽象度の低い道具=何かのタスクに特化した道具はいろいろと考えられる
    • エッグスタンドという茹で卵を立てるためだけの食器
    • 炊飯器は(いろいろ作れるけど)基本的には米を炊くためだけの道具

特にキッチン用品や食器には抽象度が低いものから高いものまでいろいろとあるよね、という話になりました。そして、抽象度の低いキッチン用品や食器を買いたくなる理由の話などもしていきました。

  • エッグスタンドや炊飯器は、茹で卵や白米を毎日食べる人は専用の道具を買うのではないか
  • りんごの皮むきをナイフでやるのはコツがあって難しいので専用の道具が生まれるのではないか
  • キッチンは広さの制約があるので、よく使う道具や代替の難しいものを優先的に置きたいのではないか

というふうに、キッチン用品や食器の場合にはタスクの難易度や頻度によって抽象度の低い道具が使われるのではないか、という仮説が立ちました。

私たちが作っているソフトウェアに置き換えて考えると、Excelでもできる業務でも、やはり難しかったり頻度が高かったりする会計ソフトや人事労務ソフトのような専用のソフトウェアが欲しくなってきます。そしてその中でもまた、難しいタスクについてはタスクベースなUIも必要になるのではないか、という見方をすることができます。

輪読会のこれから

7月にはじめた輪読会ですが、いよいよ後半戦のワークアウトに入ろうとしています。せっかくの輪読会なので、ワークアウトも各自がデザインを作ったものを見せあうかたちでやろうということになっています。ふだんデザイナー間で、同じ目的のデザインを作って見せあうということをあまりする機会がないので、これからが楽しみです。

freeeのUXチームではこの輪読会以外でも、引き続き社内での輪読会やワークショップのような取り組みを続けていこうとしています。UXチームに興味のある方は、ぜひ採用情報なども見てもらえると嬉しいなぁと思います

www.wantedly.com www.wantedly.com www.wantedly.com jobs.freee.co.jp