はい。

自分は小林大輔と言います。

2012年にサイボウズに新卒で入社して、ずっと同じ会社で仕事をしてますね。

今は開発本部のデザインテクノロジストでチームのマネージャーをしています。

あとは、デザインテクノロジストを目指すきっかけにもなっているんですけれども、自分がそのWebアクセシビリティっていう分野に興味がありまして、 それの日本の委員会の委員とかもやっていたりします。

あとは、アクセシビティに関しては本も共著で書いてるっていうのが今の感じかなと思います！

そうですね。

元々パソコンには興味が あって、小学校の時になんかよく公民館でパソコン教室とかしてると思うんですけど、親が 「行ってみたら。」って言ってくれて、簡単なイラストを書いてみようとか、音楽を作ってみようとか、そういうところから始まって、なんかゲームを作る講座ってのが1年間でずっとあったんですよね。

言ってもプログラミングをするわけではなくて、UIでゲームを作るみたいなソフトがあって、それを使って1年間でゲームを作るみたいなことをやっていて、おもしろいなって思ったのが1つですね。

あとは、Webに近いところで言うと、中学校の時にパソコンの部活みたいなものに少し入っていて、そこで簡単なHTMLとかCSSとかはそこでちょっと勉強して、なんか自分でウェブページを作るみたいなところがきっかけですね。

そうですね。

結構、絵を書くのとかも好きだったんで、美術部とかにも入ってたんですけど。

やっぱりゲームで最初は絵から書くんですね。

キャラクターの絵とかから書いて、それを動かしてみようとかってところ入ったりしてて。

そういうところがあるので、結構今の職業に結構近いかなと思いますね。

学校のホームページをその部活が任されてましたね。

放任主義的な先生で、結構いい感じに任せてくれたんですけど、文化祭とか体育祭とかで写真を自分たちで撮って、その写真をあげて、みたいなことを全部やってた感じでしたね。

いや、なんか最初は先輩からHTMLのイロハみたいなの1時間ぐらいで教えてもらって、あとはもう本読んで、つきっきりで何か教えてもらうとかはほとんどなかったですね。

なんかウェブのデザインっておもしろいなってのはそこで思いましたね。

コードがおもしろいっていうよりも、なんかこう情報をこううまく割り付けるとか、写真をうまく掲載するとか、そういうところでおもしろみを感じていました。

いや、むしろ美術の方をずっとやってたので、絵を書いたりすることとかが多くて、パソコンはそんなにやってなかったんじゃないかなと思いますね。

そうですね。

一瞬、美術の大学に進学するみたいな話を一応考えたんですけど、なんかやんわりと親に反対されて、自分でも将来考えたらまあまあないかなみたいな感じで。

やっぱり美術とプログラミングだったら将来のことを考えたら、やっぱりプログラムかなということで、情報系の大学には行きましたね。

ただ、美術もまだ好きだったんで、そこでも美術サークルを選んだというのはあります。

そうですね、専攻もまだ今のAI全盛の時代1歩前みたいな感じでしたね。

この時はディープラーニングとかなかったんですけど、パターン認識っていう何が写真の中に何が映ってるかを当てるみたいな研究をずっとやってましたね。

今までとあまり脈絡がないかもしれないですけど、コンピューターっていうと、なんか問題があって、それに対して決まった答えが出るものみたいな感じですけど、機械学習って、結局そういうことではあるのかもしれないんですけれど、コンピューター自身が考えるみたいなところがあるじゃないですか。

なんかそこがすごい興味があったので、そこをやってみようかなって思ったのはありますね。

今はちょっとビジネスの香りがすごいしちゃうのであれですけど、単純に人間の頭脳みたいなものを考えるってどういう感じなんだろうと思って、すごいおもしろくてやった感じだったんで、そんなになんか難しいっていうよりは、なんか夢があるなと思って取り組んでいました。

そうですね、自分が卒業するぐらいに、ようやくディープラーニングが世に出るのかなぐらいのタイミングでしたね。

就職活動をしている上での観点は、やっぱりまずはWeb開発をしてる会社というところでした。

研究室の同期は私以外全員SIerを選んだんですけど、自分はやっぱりガリガリ書きたいなみたいな気持ちとかがあったりしましたね。

そして、やっぱり社会に役立っているものにすごい興味があって、BtoCのサービスで当時すごい全盛だったのが、DeNAとかGREEとかスマホゲームがやっぱどんどん伸びてきている時代ではあったのでうすが、ソーシャルゲームっていうよりは 世の中の役に立つっていうところを考えていきたいっていうところがあって(ソーシャルゲームが役に立っていないわけではなく)。

もうひとつは規模感ですね。

サイボウズって今は1000人超えいるんですけど、当時はまだ数100人ぐらいだったので、なんていうか、もちろんベンチャーからすれば全然大きいんですけど、ワンフロア見渡すと、「ああ、そこが人事本部で、 ここが営業で、我々開発はこの辺か」みたいな、なんか大体そんな感じで「この人はサイボウズの社員ですか？」って言ったら絶対答えられるくらいのレベルでした。

なんかそれはすごい自分が開発をする際にも、やっぱりどんな人とも話せて、率直にお仕事できるってのが良さそうだなと思ったところがありました！

kintoneが出たのが私が入社する直前ぐらいです。

だから、内定者懇親会で話題に上がっていたのをすごい覚えています。

実はなんでサイボウズかっていうのはもう1つ理由があって、研究室でサイボウズを使ってたんですよね。

当時からサイボウズOfficeという製品を使っていたところからも関心を持つきっかけになりました。

そうです。

最初にkintoneのプログラマーをやってくださいっていうことで、新人研修が終わってから配属されることにました。

みんなそうでしたね。

kintoneプログラマーが当時はやっぱり人数も少ないですし、この人がはこの領域しかやらないっていうことはそもそも多分できないですよね。

なので みんな一通りできるようになろうねっていう感じでした。

それは人によると思うんですけど、自分はできなかった方ですね。

もう今にして思うと引っぱたきたくなりますw

コーディングの力も足りてなかったし、あとはそれはそうって感じですけど、お仕事をする時の諸々の仕方もやっぱ勉強しないといけなかったので、そこは頑張らなきゃなって感じでした。

社内には元々なかったんですけど、自分でそう名乗り始めましたw

サイボウズでは入社した社員に対して、当時ユーザビリティテストやってたんです。

サイボウズって、自分たちの製品を自分たちの業務で使うので、全員が超ヘビユーザーみたいな感じで。

だから、社員からすると新鮮な気持ちがもうわからなくなってきちゃうので、新しく入った人に試してもらおうということで力を入れて取り組んでいました。

そういう理由で、別に弱視の方に試してもらうとか、そういう意図ではなかったんですけど、

自分が当時苦労して開発をした機能がありまして、「いやー、頑張ったな〜」と思って、新しく入社された弱視を持たれている方に使ってもらったんですけど、その人が言ったのが「私にはここには何が書いてあるかわからないので、勘でクリックしてます」って言われたんですよね。

それがやっぱり非常にショックで…

しかも、その人はこれからサイボウズに入社するということは、その機能を毎日使うわけですよね。
なんか自分がやってることの罪悪感というか、そんな使いづらいものを今後も強いてしまうのかっていうのが非常に考えさせられるものがあって、じゃあこのアクセシビリティっていう分野があるらしいから、 ちょっと考えていかなきゃねっていうことで考え始めたっていうのが、2014年ぐらいでした。

そうですね。

それがやっぱり現体験になっていて、そこから自分も別にいきなり名乗ったっていうよりは勉強していきつつ、社内の技術LTみたいなところで「アクセシビティっていう分野があってね」とかを発表したりとか。

あとは、当時本が出たんですね、デザイニングWebアクセシビリティっていう多分アクセシビリティに取り組んでいる人だったら大体当たる本があるんですけど、その本が出まして、それが2016年ぐらいだったのかな。

で、勉強会をじゃあやってみようってことで、何回かに分けて勉強会やっていくうちに、だんだん社内にも「アクセシビリティって大事だね」っていうところが広がっていって、2018年には製品改善とか、社内の啓発活動みたいなのが増えていくにつれて、やっぱり専門でやってみたいっていう気持ちになって。

最初はアクセシビリティに関する業務を今までは手弁当でやってたので、あんまり勉強会の準備とかも業務時間でやってなかったんですけど、 ちゃんとやりたいっていうのとプログラマーと半々みたいな割合もだんだんずらしていって、最終的にアクセシビリティ1本でやっていくようになったのが2018年ぐらいですかね。

最初はやっぱり勉強会と、あとはやっぱり製品の改善系ですね。

製品によるんですけど、問題があるところを社外の弱視の方とか視覚障害の方とかに使ってもらったりして、問題を発見して改善するみたいなところがありました。

あとは自分たちでも検出できる問題とかたくさんあったので、その辺をやるとかですね。

そうですね。

結構うまくいったものもあれば、うまくあんまいかなかったのもありますけど、理想的にはそういうことをやりたかったっていう感じですかね。
社内ではアクセシビリティをちゃんと啓発して、それによって改善して、その成果を社外に発信してフィードバックをもらって、また啓発や改善に生かすみたいなのが当時やりたかったことでしたね。なるほど。

もうたくさん。

やっぱりエンジニアリングで解決できる領域もたくさんあったし、 やっぱりデザイン的にちょっと厳しいみたいなのもたくさん見つかったので。

課題はたくさんありましたね。

うん、そうですね。

人数は少なかったんですけど、後輩として入ってきたエンジニアがそこについてくれて、他にも兼任として入ってくれて、最終的には4人のチームで回してましたね。

なんだろう。

「会社的にこれが重要って言うためにはどうしたらいいんだろう？」っていうことをずっと悩んでるんですよ。

だから、2014年に気づいてアクセシビリティエキスパートって名乗ったのが2018年なので、4年間もモヤモヤしてるわけですよ。

その間に勉強会とかをしたり、色々な人の話を聞いたりしながら、どうしたらこの分野がこの会社にとってのミッション・パーパスに照らして大事って言えるんだろう？っていうことをずっと考えてたんですよね。

そういうのがなくて「ただ、やってみたいです！！」っていうことは多分難しい気がしますけど、どの会社でもそれはそうだと思います。

やっぱり説明責任は求められますよね。

パーパスとの例えば結びつきっていう意味で言うと、サイボウズってチームワークあふれる社会を作るっていうのがパーパスになってるんですね。

世の中にはたくさんのチームがあって、 例えば学校とか病院とか地域のサークルとか、ボランティア活動の団体とか色々あって、それぞれのチームがチームワークを発揮してより良い社会が作れることっていうのが、サイボウズのパーパスなんですよね。

で、自分は「アクセシビリティって何に対してアクセスできる能力なんだろう？」っていうのが、自分はよく社員の人に言うんですよね。

ふつうに考えると、それはサイボウズ製品とかサービスにアクセスできる能力だと思うんですけど、自分はそうじゃなくて、それは手段だと思ってるんですよね。

別にサイボウズのユーザーは製品やサービスにアクセスすることがゴールじゃないんですよ。

何かをしたくて製品やサービスにアクセスするわけじゃないですか。

で、それは何かっていうと、チームにアクセスしたい。

つまり、チームに参加したいとかチームに貢献したいとか。

自分の力をチームのために発揮したいと思うから、サイボウズの製品を使うということは、サイボウズにとってアクセシビリティっていうのは、ユーザーがチームにアクセスできる能力で、そこにはなんか障害とか高齢とかあんまり関係ないんですよね。

その人がチームに入りたいとかチームに貢献したいんですっていう人であれば、それをサポートするのが僕たちの役目っていう風に整理して伝えていった。

そういう風に考えたのは、アクセシビリティって言うと「やっぱり障害者対応でしょ」っていうイメージがすごい染みついているのもあって。

でも、それを超えられないと、それ以上の活動ができないんじゃないですか。

「なんか障害者対応は大事だよね」っていうところから先に進めないから、今みたいなことを考えて、みんなに勉強会とかでは言ってたりしましたかね。

あんまり考えなかったですね。

自分はこの会社にとって大事だろうって思ったのがきっかけだったので。
あんまり他の会社に行って、アクセシビリティをスキルとしてやるぞっていうことに対してあんまり興味はなかったですね。

この会社でなんとしても自分が大事だと思ってる概念をやっぱりみんなに分かってもらって、今作ってるプロダクトをもうよりアクセシブルにしていく っていうことに対して目的意識を感じてたので、転職をしてっていうのは、手段と目的が逆になっちゃうっていうか、あべこべになっちゃう気がしたので、あんまり考えなかったですね。

これはですね、結局コアになってるのはやっぱりアクセシビリティに関する考えなんですよね。

名前にはアクセシビリティって入ってないんですけど。

それは意図してそうしていて、これまでアクセシビリティを専門部署として切り出して活動してきたんですけど、開発チームがあってそれとは別にアクセシビティチームがあって、レビューを請け負ったり、助言をするみたいな関係で活動してきたわけなんですけど、アクセシビティエキスパートだった時は結構限界を感じていたんですよね。

やっぱりそういう仕事でいる限り、改善の限界があるというか、「直してください」って言っても、それはやっぱり開発チームの都合があったりとかっていうところがあったので、やっぱりこのままじゃ広がらないかもっていうところがあったし、もっと突っ込んで言うと、やっぱデザインの一部なんですねアクセシビリティって。

だから、もっとデザイナーと積極的に議論してアクセシビリティも高めるけれど、そのデザインで本来達成したいこととか、メインでターゲットとしてるユーザーのこととか、諸々を考えていいデザインを生み出していかなきゃいけないから、 やっぱりアクセシビリティだけ取り出して議論するっていうことに対して、なんか自分がすごい違和感を感じ始めたんですよね。

だから、もう1回製品に戻ろうみたいなところがあって、製品の中のデザインテクノロジストっていう職種でアクセシビリティを高めていくっていう道を探ってみようっていう風に思って今に至ったのが経緯になります。

そうですね。

結果的にアクセシビリティも取り出して議論することは簡単なんですけど、もっと製品に対してそれをいつどういう風に取り込むかみたいな作戦って結構難しいし大変なんですけど、やっぱりそれやらないと先に進めないんですよね。

問題の指摘だけしてissueだけ溜まっていくみたいになっちゃうので。

そうですね。

時間の空いた時にやろうみたいな感じに変わっちゃって。

でも、やっぱりもっとちゃんと作戦を考えていくと…

例えばある機能Aのデザインを改善するってなった時に、その機能Aの改善と一緒にアクセシビリティを入れ込んでいくとか、簡単に言うとそういう感じですよね。

そういう風にうまく作戦を立てていく必要があると思ったので、自分はデザインテクノロジストになりましたね。

いや、これは別の人が提案して。

デザインテクノロジストっていうポジションが社内で声かけがあって、自分がそのデザインテクノロジストのマネージャーになる人から声がけがあって、「ぜひやってみませんか？」っていうので、「いいと思います！」って流れで始まりました。

今もやってるんですけど、kintoneのフロントエンドの基盤を刷新するっていうプロジェクトがずっとあったんですね。

やっぱり10年以上運用されてるので、古くなっていって今の現代的なアーキテクチャーとはもう全然違うものになっていたので、それを刷新して、今の現代的な開発ができるようにしようっていうのがあったんですね。

で、今も絶賛進行中なんですけど画面を作り変えていくっていうところがありますと。

ただ、そうなった時に単に作り変えるだけじゃなくて、ユーザー体験もそれと一緒によくしていこうっていう流れがあって、ユーザー体験に責任を持つチームとして、デザインテクノロジストっていうのが作られたっていう感じですね。

だから単純にデザインのこともあるけど、アーキテクチャーのことも考えなきゃいけないていう都合があってっていうところで、両方のコミュニケーションできる人を求めていたという感じですかね。

そうですね。

他の会社だとそう言えちゃうかもしれないですけど、当時デザインテクノロジストを起案した人のなんかブログがあるので一応載せておきます。

コンセプトになるのはやっぱりコミュニケーションなんですよね。

「デザインとエンジニアの両方ができる人、以上。」では多分ダメで。

両方のポジションに対して橋渡しをしてコミュニケーションするっていうのが本質ですね。

すごいですよね。

この人がデザインテクノロジストっていうポジションをそれこそ自分で名乗り始めて、一緒に仕事してるっていう感じですかね。

結局、アクセシビリティも多分そこでうまくいかなかったんだと思うんですね。

アクセシビティエキスパートになった時にもデザイナーとかエンジニアとか、そのチームに対してちゃんとコミュニケーション取るっていうところがやっぱり大事で、何をどう守ってほしいとか、どういうデザインだったらうまくいくみたいなのをきちんとコミュニケーションしない限り、理想の押し付けみたいになっちゃうところがあるのですごい大事なことだなと思っていますね。

今も模索中ですけど、うまくいったところで言うと、昔はデザインがあってそれをどうアクセシブルにするかっていうことを考えると、フィックスしたデザインに対して自分たちがダメ出しを入れるか、そのデザインを受け入れてエンジニアに帳尻を合わせてもらうかみたいな、その2種類しか多分選択肢がないですよ基本的には。

どっちも辛いんですよ結構。

それが今はデザイナーさんと割とフランクに議論できるし、そうしなければいけないわけなんですけど、 デザインを考えてるプロトタイプの段階で議論をして、「こういうデザインがいいんじゃないか」みたいなところを考えたりとか、そういうことができるようになったのが大きいですね！

多分周りの人が 僕に対して期待してるのってそういう部分だと思うんですけど、あんまり自分そうしたくないんですよね。

そうなると、結局アクセシビティだけ取り出して議論することになるじゃないですか。

デザインで達成したい本丸のところも議論しなきゃいけないし、その中で自分は単にアクセシビティが得意なだけっていうスタンスで議論したいんです。

なんかあんまりそこを分けて「すこやさんアクセシビティチェックお願いします」みたいのが1番嫌ですね。

なんかそうなっちゃうと結局入った意味がないというか。

デザインテクノロジストとしてやってるし、チームの中に入って活動するって決めたからにはそれ以外のところもまとめて議論していくのがやっぱ大事だと思っているので。

自分は単にアクセシビリティが得意なデザインテクノロジストですね。

1つはそれですね。

デザイナーとコミュニケーションをしながら、そのデザインに対してレビューをするとか。

あとはデザインテクノロジストの重要な仕事として、コミュニケーションのツールとしてデザインシステムを作るっていうのがあります。

議論した内容を元にデザインシステムの素材、具体的にはデザイントークンって言われてる色とか形とかの基本単位みたいなものをちゃんと整理するとか、コンポーネントを作るとか、それを実装とかFigmaでちゃんと提供するとか、そういうところをやっているっていう感じですかね。

いや、それこそ自分たちが声かけかかった段階から作り始めました。

今までは割と大変というか、デザイナーが整理する余裕がなかったので、課題意識としてずっとあったんですけど、なかなか整備されないっていう状態だったんですね。

なので、この段階でちょっとちゃんと整備していくことができた感じですね。

そういうことになりますね。

ただ、 なんかここは多分サイボウズのデザインシステムで多分1番成功したところだと思ってるんですけど、 1からデザインシステムを作るって時のイメージがふつうのデザイナーと多分全然違う気がしますね。

ふつうのデザイナーだと、まずボタンを〜色を〜カラーパレットを〜と目立つところを作ろうと考えると思うんですけど、全然そんなことやってなくって。

今あるパーツをとにかく引っこ抜いてきて、とにかくデザイナー・エンジニアが今使えるものをまず作りましょうっていうのが僕らが最初にやったことですね。

そうなんですよね。

既にもうあって1から製品を作るわけじゃないので。

大事なのはやっぱりみんなが使えてそれを元にコミュニケーションするツールにならなきゃいけないんで、絵に書いた餅にはしたくなかったんですよね。

だからそういうことを 最初やりましたね。

デザインリニューアルをするわけではなくて、1回収集してそこから改善してけばいいんで。

まずその収集するっていうとこなんで、最初は多分すごい歪だったと思います。

コンポーネントも全然揃ってないし、カラーパレットみたいなものもないんですよね。

デザインガイドらしきものもあるけど、すごい不十分で、今分かっている範囲のことしか書いてないみたいな感じです。

そこをそれこそデザイナー・エンジニアと議論しながら徐々に作り上げてるような感覚ですね。

進行中です。

でも、最初に比べたらもう全然違いますけど。

フロントエンドの刷新のプロジェクトも二人三脚で進んできてるんですけど、このデザインシステムのプロジェクトって、まず最初の限られた範囲の機能から刷新を進めていっているんですけど、だんだん範囲が広がっていくに従って、やっぱりガイドも拡充しなきゃいけなかったり、パーツも増やさなきゃいけなかったりみたいな感じなので、それと一緒に成長してるみたいな感じですね。

そうです。

デザインシステムの担当みたいな感じの位置付けではあるんですけど、どちらかというと「こういうデザインが必要になった」っていうことをデザイナーから言われたり、エンジニアが次この画面を実装するにあたってこういうものが必要そうだっていう、外からの要求ベースになることが多いですよね。

で、それに対して、「じゃあそれだったらこういうルールを整備しておかなきゃね」とか、「こういうパーツ絶対に必要になるから、このパーツちょっと考えましょうかね」みたいな感じで入ることが多いイメージですね。

そうですね。

デザインシステムはやっぱりこれだけ受け入れられたのはやっぱりそこだと思いますね。

まず使えるというか、コミュニケーションの基盤になれるものを作るっていうのが大事で、コミュニケーション無視して自分たちの理想のデザインはかくあるべきみたいなものを作っても、多分あんまり意味がないですよね。

そもそもデザインテクノロジストになった動機は、その外で「理想のアクセシビティはこうだ！だからこれをやるべきだ！」みたいなやり方に関して限界を感じて、このデザインテクノロジストに入ってきたので、それと同じ作戦で「これが理想のデザインシステムだ！みんな使え！」っていうのは多分あんまり結果変わらない気がしたんですよ。

だから、それよりはもっとデザイナー・エンジニアが何を考えているのかとか、じゃあそれに対して使えるものをどう提供すればいいか？っていうことに心を砕くっていう方が、自分はやっぱりやりたいかったので。

そうですね。

結果的に今もデザイン考えてて、アクセシビティに関してこう色々言ったりするので、今は社内の人のことを結構考えることが多くなりましたかね。

デザイナーとかエンジニアが と協力してアアセシビリティを含め、デザインを改善していくっていう時にはどうすればいいかっていうことをすごい考えてるって感じですかね。

自分のキャリアで言うと、今マネージャーを任されているので、みんなのマネージメントをして周りが気持ちよく働いて、ちゃんと理想を叶えられるようにサポートしていくっていうのが、自分のキャリア的にはそれが1番大事なところのミッションになっています。

で、自分の理想を言うと、ずっと一貫してるのかもしれないですけど、アクセシビリティだけ切り離して議論するみたいなことに対して限界を感じているし、多分その作戦では多分今後うまくいかないぞと思ってこっちに来たので、自分の遠い理想としてはアクセシビリティっていう言葉が消滅することです。

デザインの一部であって、アクセシビリティだけ取り出すっていうことに対して、 多分デザイナーさんも思うと思うんですよね。

例えばあるissueを考える時に「デザイン対応は後にしましょう」とか言われたらすごい違和感あると思うんですよね。「いや、今じゃあややってるこのプロトタイプのデザインって一体何…」とか「ユーザービリティ対応をしましょう」とかってすごい変じゃないですか。

それと同じぐらい「アクセシリティ対応しましょう」って言われた時に自分は強烈に違和感を覚えるんですけど、それと同じ気持ちにみんながなってくれたら、きっとそういうことは消えると思うんですよね。

それが当たり前のものとして認識されることが遠い自分のゴールかなとは思いますね。

ほんとですか！！

ありがとうございます。

そうですね。

じゃあ、書籍Webアプリケーションアクセシビリティについて宣伝してもらえるとありがたいです。

もしアクセシビリティについて興味がある方がいたら、ぜひお手に取っていただければと思います！