新たなスキルをどう身につけるか？　CTOたちが教える、技術習得のメソッド

UI/UXを考える上で重視していること

ひらいさだあき氏（以下、ひらい）：では、UI/UXを考える上で重要視しているポイントがあれば、そこをお伺いしたいともいます。もしそのあと時間があったらエンジニアのバックグラウンドのある人たちにも聞いていきたいなと思います。

早河さんは幅広くなってしまうと思いますが、UI/UXというところで、先ほどはインタビューをされているというお話もありました。そのあたり、インタビューをどういうところでやっているのか、あるいはインタビューにはどんな人たちが参加していて、インタビューした結果、アウトプットやプロダクトにどのように活きてくるをおうかがいできればと思います。

早河優氏（以下、早河）：まず、UI/UXを考える上で重要ポイントは、使ってもらうユーザーさんにどんな気持ちになってもらいたいかを考えることです。

この画面でどういったタスクをユーザーさんが持っていて、それをこなすことでどういう気持ちになるのかを考え、ボタンの位置や色やなど、UIの強弱みたいなものを検討しています。

ひらい：いろんなインタビューあると思いますが、先にプロトタイプを使っていただいてインタビューすることは多いですか？

早河：そうですね。具体的なものができている段階だと、まさしくProttだったりとか。

ひらい：ありがとうございます（笑）。

早河：InVisionとかいろいろ使って、実際に動くものを操作してもらってユーザーインタビューをさせていただくこともあります。抽象的なものだと、「こんなアイデアがありますけど、どう思いますか？」「この機能は必要だと思いますか？」みたいなインタビューをさせていただいています。

ユーザーインタビューを何回かやってみて感じたのは、やはり自分の意図したとおりの使い方はほとんどされないということ。そして、最初に思い描いていたものはなかなか伝わらないということを実感しました。

インタビューした結果を実際にプロダクトに落とし込んでいく作業を何回も繰り返して、プロダクトを形作ることが多くなってきています。

ひらい：インタビューにはどんな職種の方々が参加されていますか？

早河：そのサービスの利用者が多いですね。

ひらい：インタビューする対象として？

早河：そうですね。もともとあるサービスのリニューアルだったり、「新しくアプリを作りたいんです」みたいなお話をいただいた際は、ロイヤリティの高いユーザーさんにインタビューさせていただくことが多いです。あとは不特定多数の人をリクルーティングしてメンバーを集めることもあります。

インタビューがプロダクトにもたらしたもの

ひらい：なるほど。インタビューする側はどんな職種の人たちが参加されるんですか？

早河：インタビューする側では、僕みたいなデザイナーもいればクライアントさんも入ります。直接インタビューするわけではありませんが、「こういったことを聞いてください」みたいな話をインタビュアーさんにお願いすることが多いです。

実際インタビューするのは、UXデザイナーといっている者がインタビューすることが多いですね。

ひらい：僕たちもインタビューしますが、インタビューする文化はここ数年で増えてきた用に思います。インタビューをしていない時代もあったんじゃないかと思います。その頃と今では、どんな変化がありますか？

早河：先ほどの話の繰り返しになってしまいますが、やはり自分が意図した使われ方はなかなか伝わっていなかったということは、インタビューしてみてはじめてわかったことですね。

インタビューをする以前は、プロダクトを出したあとになにかしらのフィードバックや「使いづらい」という要望が来て「また修正」みたいな感じでやっていたんですが、その開発のプロセス自体も変わってきています。プロトタイプで使い勝手を検証できるようになってきていることも、インタビューができる素地になっている思っています。

ひらい：ありがとうございます。

KPIが求められない環境で、あえてKPIを提示する

ひらい：続いて、菊池さんにご質問させていただきます。最近、toB向けのお仕事が増えているというお話をうかがいました。toB相手にUIやUXを考える上で重要だな思われている点があれば教えていただけますか？

菊池聡氏（以下、菊池）：ええと、なんだろうなぁ。

ひらい：やっぱりtoBとtoCだと考えることは変ったりしますか？　それとも意外と一緒だなという感じですか？

菊池：toBのほうがtoCよりKPIは緩いと思います。

ひらい：なるほど。慣れて使わざるをえなかったりするとかですか？

菊池：そうですね。バックエンドのシステムなんかだとKPIを求められないことが逆に多いですね。なので、逆にKPIを出すようにするというのが、僕のやり方です。

ひらい：なるほど。言える範囲で大丈夫なんですが、例えばどんなものがKPIになりますか？

菊池：例えば、コールセンターなんかだと1件あたりの処理時間というものがあります。それは、例えばSalesforceなんかを使って計測ができるんですね。

1件あたりが10分だとします。その中でそれを5分にしますと。そうすると単純に半分になった場合に、中間のKPIもあればKGIに近いところもあるんですけれども、5分にしたとき、その人の処理件数が倍になりますよね。そして、オペレーターの時給が例えば1,000円だとします。そのとき、3ヶ月間でどのぐらい今までと利益が上がったのか、僕らのチームのコストをわざとぶつけます。

ひらい：なるほど。すごいおもしろいですね。

菊池：そして「得しましたよね？」というかたちで終わるのが多いですね。

ひらい：なるほど。やっぱり僕も自社プロダクトやクライアントワークをやっていると数字ってすごく大事で。すごく使いやすかったり体験がよくなっても、サービスとしてやっていく以上それなりの収益が確保できないとそのサービスは終わってしまうと思っています。なので、そこで数字とUXを合わせて考えられているのは、しっかりやられているという印象がありました。

「迷ったら出せ」

ひらい：今ちょうどKPIのお話も出てきたので、林さんにお話をお聞きしたいと思います。Emotion Tech等を最初ご紹介いただいた時に、カスタマージャーニーマップの話があったと思います。そのあたりで、サービスのお話でもぜんぜん大丈夫なんですが、Emotion Techを使ってだったりEmotion Techを作っていく上でUI/UXで重要視しているポイントはなにかありますか？

林優一氏（以下、林）：先ほどもおっしゃったとおり、出したあとに思ったように使われないことはけっこうあります。なので、僕はPMとして「迷ったら出せ」って言っているんですよ。

ひらい：おお。

林：なので、迷うんだったらとりあえず出してしまって検証したほうが速いですよね。結局、UXには解はないので、1回出してみて当てていく。最低限のユーザーヒアリングや設計はきちんとやった上での前提はありますが、とにかく1回出してしまって、そのあと改善したらいいんじゃないかと思っています。とにかく重要視しているのは、あえて言うのであればスピードですね。

ひらい：なるほど。出したあとに、それを改善していくか・やめてしまうかという判断はしいところもあると思いますがどうやって判断されているんですか？

林：Emotion Techの場合、完全にtoBのサービスで、サクセスというサポートチームがあります。アンケートを取って改善点を出すだけでなく、そのあとの改善のプロセスまでサポートしてあげるカスタマーサクセスというチームです。いわゆるコンサルティングに近いようなチームなんですが。

そこと一緒に、実際にその機能を使ってサクセスにおいてそれらはどう作用したかを、実際に当ててもらってフィードバックをもらって、そこに対してどう改善していくか、みたいなかたちなので、いわば常にインタビューし続けているような状態です。

ひらい：カスタマーサクセスをされている方は実際のクライアントさんともコミュニケーションされているんですか？

林：そうですね。カスタマーサポートはお客さんとその担当者と相対して、実際にシステムの数字見て、どこをどう改善していくべきだとか、データの見方だったりとか、そういったサポートをやっています。

ひらい：なるほど。ありがとうございます。

デザインは学習材料を作る作業

ひらい：次はaggreさんにお聞きします。今までUXデザイナーもされていて、UIデザインもされていて、エンジニアもされていて。そのなかで、UXデザイナーをされていた時に重要視していたポイントはなにかありますか？

aggre氏（以下、aggre）：基本的には、デザインをするときに自分たちは正解を知らない前提で作るので、テスト前提です。テストの材料をデザインしていくようなイメージでいます。

なので、先ほど「デザインが最近楽しくない」と言ったのは、好きなものを作るというよりも、どっちがいいのかを確かめるための材料を作っている、学習材料を作っているというだけになっているので。それは昔からあって、学習材料としてのデザインをできるように両極端なものを作ってみたりとか。

ひらい：それは林さんの「出して確かめる」というのにけっこう近しいかもしれないですね。

aggre：そうですね。もう「出そう！」という感じ。

ひらい：UXデザイナーとして「まず出して検証していく」というところを重要視されていましたが、今はエンジニアリングをされていて重要視しているポイントは変わりましたか？

aggre：あんまり変っていないです。逆にデザイナーとしてやっていた時よりもエンジニアで……。僕はフルスタックなので（笑）、スピードはすごく速くなりましたね。

リリースしたUIをどう検証するか？

ひらい：林さんと同じ質問になってしまいますが、出したあとの検証はどのようにやられていますか？

aggre：基本的にA/Bテストを使うことが多いです。なにか目標を設定しておいて、どちらが優位に立ったのかを計算して。それはもうツールを使っちゃいます。OptimizelyとかGoogle Optimizeとか、そういうのを使って計測しています。

ひらい：例えば、A/Bテストできるのってなにか比較対象があるときだと思います。単純に言ってしまうと、バナーだったら2種類出してってできるじゃないですか。ですが、例えば新しい新機能を出そうといったときってなにか過去に比較する対象がなかったりしますよね。そんなときはどんなところを重要視されますか？

aggre：そのときも、なるべくその機能が求められるかどうかを判断できる材料を作ります。ですが、場合にはよっては作らないこともあって。メールでユーザーに告知するだけだったり、送って反応を見ることもありますし。実際にWebサイトにダミーとして載せられるようなものであれば載せちゃって、「これは今テスト中です。ご協力ありがとうございました」というメッセージを出して終わり、みたいなこともやります。それで、押されたかどうかを測るみたいな。

ひらい：なるほど。確かに作る手前から確認していくこともできますもんね。ありがとうございます。

今後の人材の需要

ひらい：次の内容にいきたいと思います。次に「今後のマーケットの需要は？」というところです。今日はデザイナーやエンジニアの方がかなり多く占めていて、どちらもマーケットの需要はかなり増えてきていると思います。

今日のお話ではエンジニアがUIやUXに絡んでいく、あるいはデザイナーの方もUI/UXや、あるいはエンジニアリングに絡んでいくという需要も高くなってきていると思います。

そんななかで、例えば林さんはプロダクトマネージャーをされていたりしていますが、どういったエンジニアだったりどういったデザイナーに来て欲しい、一緒に働きたいと思われていますか？

林：うーん、そうですね。一緒に仕事をしたいかどうかでは、スキルというよりは、人柄やその都度必要なスキルによって変ってくるとは思います。

ただ、市場の需要という意味では、やっぱりマルチスキルが最近は主流というか必須になってきていると感じています。例えばデザイン＋コーディングとかデザイン＋マーケティングとか、コーディングもフロントエンド＋バックグラウンドとかアプリとか、そういったなにかプラスアルファでやっていくことがすごい多いですね。

ひらい：多少領域を超えていくようなイメージですかね？

林：そうですね。自分のキャリアの構成の仕方も「人がいないところをやる」というスタンスでずっとやっているので、「デザイナーとフロントエンドの間」みたいな、あんまり人がいないようなところとか、サーバーサイドとデザイナーの間とか、あまり人がやらないところをやっていくということです。人がいないから需要があるという。そういったところを狙っています。

ひらい：最近ではUXエンジニアとか、Takramさんがよく言っているデザインエンジニアという職種もけっこう増えてきていますしね。あとはIndeedで検索したりすると、UXエンジニアをGoogle・Microsoftが募集していたり。あとは、Androidに関するUXエンジニアとかもあったりしますね。

デザインの原則とどう向き合うか？

ひらい：例えばフェンリルさんのところでは、そういったデザインと技術を両方やるような方っていらっしゃったりするんですか？

早河：基本的には分業で、エンジニアの方はエンジニアリング、デザイナはデザインだけやるかたちで弊社はプロジェクトをやっています。

ひらい：そこは専門性を出していくかたちでやられているということなんでしょうか？

早河：そうですね。ただ、お互いの仕事にはすごく口を出します。エンジニアの方もデザインに関してすごく厳しいですし、自分も、エンジニアさんが面倒くさいということこそ意図・理由を説明してお願いしたりします。

なので、このあたりはお互いに意識し合ってやっているし、なかなか手は抜けない関係でやっています。

ひらい：今お話にあった「エンジニアがデザインに厳しい」というのは、具体的になにかエピソードはありますか？

早河：iOSだったら、アラートでどっちにキャンセルを持ってくるかあたりでけっこうもめました。

ひらい：キャンセル問題。

早河：その部分で「AndroidはこうだからiOSはどうだ」みたいな話になったりとか。あとは「これだけメニューがあったらハンバーガーメニューにしちゃえばいいじゃん？」みたいな感じになったりするんですけれども、「そうすると体験としてどうなの？」みたいな話をエンジニアの方から指摘されたりということはありますね。

ひらい：うちもさっきのキャンセル問題のように、iOSとかだとアラートで「この情報を削除しますか？」「はい・いいえ」とか「はい・キャンセル」とかはよくあったりすると思うんですけど、その「はい」と「キャンセル」をどっちに置くかみたいな。右側に置くのか左側にボタンを置くのかというところで、うちのグッドパッチのエンジニアも話題にしていたりしました。

そのあたりをそもそも考えていくと、けっこうHIG（Human Interface Guideline）は知っていないと難しかったりもしますよね。

早河：そうですね。HIGもそうですし、Material Design Guidelineみたいなものがあると思うので、「そこを見て出直してこい」みたいになっちゃうこともありますね。

あと、やっぱりHIGがすべて、Material Design Guidelineがすべてという感じには思いたくはないですが、最低限その部分で議論できるだけの知識は持っているべきだと思ってます。

ひらい：そうですね。今年のGoogle I/Oで、Material Designのアップデートがあって、そこのprinciple（原則）のところに「Customize」というの増えましたよね。

それで、これまでMaterial Design Guidelineって、そのままMaterial Design Guidelineっぽく作るとGoogleのアプリっぽくどんなってしまうという問題もあったりして。それをカスタマイズしてサービスの色を出してくというところが原則になると、どんどんデザイナーさんの大変さが増えていくなと感じています。

早河：そうですね。大変ですね（笑）。インタラクションもいろいろありますし、Material Designはとくにそのまま作ればある程度きれいなものができるので、それをどう差別化していくか、アートディレクションだったり、サービス、体験自体をどう形作っていくかということになってくるので、なかなか考えることが増えてきたなと感じています。

ひらい：そうですよね。ありがとうございます。

ビジュアルデザイナーとUIデザイナーの違い

ひらい：菊池さんは最初のキャリアではマーケティングをされていて、今はUXやコンサルティングもされているというお話をうかがったんですが、今後、そういったいろいろな職種をご経験されたなかで、今後需要あるのではないかと思われている職種はありますか？

菊池：職種、うーん……。

ひらい：職種だったり仕事内容だったり。

菊池：マルチスキルは重要はなってきてますが、なぜマルチスキルが重要なのかということを考えると、今みたいにスクラムをとかで組んでいるときに、隣の人とのコミュニケーション能力が重要なんですね。

実際これはドキュメントであるんですが、50人のチームメンバーがいるよりスクラムを組むほうが速かったりするのはよくあることで。リソースを確保するよりコミュニケーションがスムーズにできる9人のメンバーのほうがんベロシティが高いというのはありますね。

それはなぜか、僕らのチームで考えると、コミュニケーション能力、つまりエンジニアだと、ほかの人の仕事がわかるということ。先ほど早河さんがおっしゃったように、横に口出しできるというのはたぶんそういったことなのかなと思うんですが、そういった人材が必要かなと思います。逆に僕はいつも困るのは、HTMLとCSSのスペシャリストが減ってきてると思います。

突拍子もなくできるやつらは減ってきたなと。昔みたいにちょっと凝った感じの人は減っているので。例えばCSS3でも、今でも追いかけて勉強している人たちや、それを自由に使いこなせる人は減ってしまいました。だから、実は案件のなかで一番リプレイスが利かないのはそこです

逆にちょっと厳しい言い方をすると、ビジュアルデザイナーから肩書き変えたUIデザイナーは、ちょっと厳しいこと言うと、一番使えない。

ひらい：ビジュアルデザイナーとUIデザイナーの違いというのは、菊池さんの中ではどういった点にありますか？

菊池：一番は、なぜそれを選んだかが言えないのはダメですね。

ひらい：それは例えばボタンや情報設計というところですか？

菊池：そうですね。UIのところで、なぜそのボタンにbox-shadowを大きくつけたのかがはっきりしないとか。例えば、なぜそこのフォントサイズが大きいのか。例えばテーブルを組んだときに一番左から右にそれが並んでいる理由が言えないとか。

答えを言うと「リサーチをした時にインタビューで一番よく見られているのがここだから、僕は左に持っていった」とかっていうことが言えたらもう合格なんですけど、「いや、なんとなく今も前のバージョンもそうだから」とか「これに慣れているんじゃないか」とか、そういう答えが出てきたり「数字が左にあるほうがきれいだから」とか「alignがきれいに見える」って言われたら、僕の中ではアウトですね。

ひらい：なるほど、厳しい（笑）。

菊池：厳しいですよね（笑）。

ひらい：今はスクラムで開発とかをされることは多いんですか？

菊池：そうですね。クライアントさんからの評価軸として、「どのぐらいベロシティが上がっているのか」とか「どのぐらいポイントがあるのか」。常に上に上がることは当然難しいので、それがすべてではないんですが、とくにB2Bなんかでやっていると見えづらいので、それを前に出すしかプロセスの途中ではないですね。

例えば、なにがコアバリューかを見極めてそれを早く出していく。ビジネスオーナーに、ステークホルダーに対してなにが重要かというのを出さないといけない。そういったところを強く出していきますね。

ひらい：なるほど。ありがとうございます。

「デザインができるエンジニア」の定義

ひらい：aggreさんにおうかがいしたいんですけど、aggreさんの場合、マーケットの需要というか、フルスタックすぎてオンリーワンになっているような気がするんですけれども、FRAME00さんって、何名ぐらいいらっしゃったり、どういった職種の方がいらっしゃるんですか？

aggre：エンジニアは僕だけ。チームじゃないんです。CEOとCOOがいるだけなので。

ひらい：3名でやられている？

aggre：そうです。

ひらい：FRAME00さんだとその3名はどういった役割分担でお仕事されているんですか？

aggre：CEOが基本的はプロダクトマネージャーをしていて、COOはPMに近いですね。

ひらい：なるほど。それで、すべての実装だったりデザインを？

aggre：デザインと実装は僕って感じです。

ひらい：もし、人を入れるとしたらどんな人が欲しいですか？

aggre：基本的にはチームを拡大していこうと思ったときに、デザイナーがいらないわけじゃなくて、今の段階ではまだエンジニアしかいらないという段階です。デザインのできるエンジニアという要望にはなっちゃうんですけれども。

なので、僕らエンジニア側が圧倒的に「こういうデザインだよね」というガイドラインがあればそれに則ってできるので、基本的にそれで成り立つプロダクトしかやっていません。それがスケールしていくようになったら、たぶん全体の出てきたものをコードレビューするチーフデザイナーみたいなものが必要なのかなという気はしています。

ひらい：なるほど。今お話にあったデザインのできるエンジニアって、エンジニアリングができるのは普通に当たり前だと思うんですけど、デザインができるというのはどんなことができるイメージなんですか？

例えばメジャー系だったら、普通にSketchを使ってUIが作れるとかだったり。あとはインタビューの設計ができてインタビューできる、コンペティターのリサーチができるとか、いろいろあると思うんですけれども、どういった方がFRAME00さんだと欲しい方って思われたりします？

aggre：これはデザイナー・エンジニアに限らず、チーム全員でこれから作るものは合意を取っている前提で、その合意した情報設計に則ってコンポーネントに区分けして、「ここの色はこれだろうな」というのをデザインガイドラインどおりに、モックやプロトタイプがなくてもいきなりコードに入れる人が、デザインができるエンジニアなのかなと定義しています。

ひらい：例えば、僕たちの会社だと、エンジニアとデザイナーのコミュニケーションだとPrott使ってプロトタイプしてたりするんですけど、そこをすっ飛ばしてできるようなイメージですかね？

aggre：そうですね。

ひらい：なので、コーディングでプロトタイプを作っていける？

aggre：はい。

ひらい：なるほど。そういったとき、例えばコンポーネントの設計とかってけっこう難しかったり、あとWeb Componentsもいろいろやられていますよね。そういったところの設計もやっぱりやっていく必要がありますよね？

aggre：そうですね。逆にいうと、そのコンポーネントの粒度の合意形成がデザイナーとエンジニアが分かれているとやりづらいところで。エンジニアに寄せたいという気持ちはすごくあったんですよ。

ひらい：なるほど。うちも今、デザイナーとエンジニアが分かれていて。コンポーネントの設計は話し合いながら進めていますね。Reactを使ったりするときStorybookを使ったりするんですけれども。

そのあたりだと、デザイナーさんにとってはほぼ同じ見た目だったりするけど、エンジニアにとっては機能がそもそも違うから、コンポーネントを分けたいということがあったり。そういったことは、確かに1人でできるとすごくスピードが速くなったりしそうですよね。ありがとうございます。

スキル習得のポイント

ひらい：では、最後のテーマにいきたいと思います。「新たなスキルの習得を行うときのポイントは？」というところです。最初にみなさんのキャリアをお話を聞かせていただいて、転換期というところだったり「どうやって覚えていったんですか？」ということも聞いていきましたが、もうちょっと深くおうかがいしたいなと思っています。

実際に登壇者のみなさんがどうやってスキルを習得していったのか、あるいはそういった経験をしていくうえで、なにか共通点やポイントがあると思います。

そこで早河さんにおうかがいしたいんですが、最初はFlashやActionScriptをやられていて、そのあとWebデザインをやられていて、今はネイティブアプリのデザインもされていると思いますが、それぞれのスキルやデザインの知識、テクニックを習得する上で、なにか共通するものはありますか？

早河：やはり、先ほどのお話にもあったとおり、UIの模写はどのタイミングでもやっていました。あとはできる人に習うのが一番手っ取り早いと思っているので、そういった会社に就職するだとか、そういった職種の方が集まる勉強会なりに参加してみるというのはやってきました。

ひらい：例えばフェンリルさんに入るとしても、当然ある程度の経験や知識がないと、「UIは作ったことないけど、やりたいです」だけじゃ入れないと思うんですよね。

早河：はい。

ひらい：そのあたりは、なにかキャッチアップされていましたか？

「実際にやってみる」の効果

早河：実は端折ってしまいましたが、Web制作会社を辞めて、1年ぐらいアプリを作っていました。アプリを作れるエンジニアの方と一緒にアプリ作って「こういうアプリ作れます」みたいな感じで就職活動をしていました。

ひらい：すごいですね。

早河：なので、実際にやってみるということは、経験として一番手っ取り早かったなと思います。

ひらい：なるほど。1年間どうやって暮らさせてきたんですか？

早河：それはまぁ細々と。霞を食うような生活をして。

（一同笑）

ひらい：なるほど（笑）。その時はどんなアプリを作られたんですか？

早河：その時は、Bluetooth通信で4台までつないで早押しクイズができるというもの。Yahoo Quiz APIみたいなものが当時あって、それを使ったアプリを作ってました。Mashup Awardsとかに出したんですけど、鳴かず飛ばずで終わって。

ひらい：（笑）。

早河：なんですけど、個人的にはすごいおもしろいものができたなと思っています。

ひらい：その時はエンジニアの方と2人でやられていたんですか？

早河：そうですね。エンジニアとプランナー、僕でやっていました。

ひらい：なるほど。最初はネイティブアプリのデザインというのは、実際アプリを作りながら学ばれたところもあると思うんですけれども、どういったところからキャッチアップを始めたんですか？

早河：作っていたのがゲームだったので、わりと自由に作っていましたが、その過程でアセットの作り方とか、基本的な部分を覚えていきました。

おもしろそうだと思ったら、まずはやってみる

ひらい：ありがとうございます。林さんも同じ無職期間を経てキャリアアップをされていったと思うんですが、これまでSIerに入って、そのあとWeb系の仕事をやって、フロントエンドになって、VPoEになっていくというところで、けっこういろいろなスキルを習得されていったと思います。そのなかで共通点はありましたか？

林：そうですね、自分も「やってみる」が一番だと思っています。「なんかおもしろそうだな」と思ったらとりあえずやってみるという。

今のメインはWebなので、Webの技術なら、別にお金を払わなくても試そうと思えばだいたいものは無料で試せるじゃないですか。なので試せばいいと思っています。やってみて触ってみて、これに自分として投資する。要は勉強というのは時間投資なので、投資する価値がそもそもあるのかないのかを自分でやって判断しないと、いくら人から言われたって自分がそこを信じられなければ続きません。なので、まずはきちんと1回自分で触ってみることが大事かなと。

ひらい：その上で、その先までやっていくか、これはやめて違うところにフォーカスするかみたいなことを考えられるということですか？

林：そうですね。自分が「あっ、よさそう！」と思えば続けるし、イマイチだなと思った瞬間にその時点でパッツリ勉強をやめちゃうタイプなので、もうなにもやらない。

ひらい：「これはもうおしまい」みたいな。

林：「これはたぶん未来はない」って信じてやらないと（笑）。

ひらい：ちなみに、未来がないって思ったなにかって教えていただけますか？（笑）。

林：そうですね……言っていいのかな？

ひらい：言えないやつ（笑）。

林：過去にやろうと思ってすぐやめたのは、Ember.jsという難しげなフレームワークがあって、とあるブログで「型もあって完璧だよ」って書いてあったのでやってみたんですが、あれは3日ぐらいでやめました、

ひらい：早い（笑）。

林：無理でしたね。

あえて独学を選んだ理由

ひらい：aggreさんにもおうかがいしたいんですが、aggreさんは独習で乗り越えてきたとは思うんですが、独習以外を試さなかった理由はなんですか？　もうとにかく独習してやってみるのが近道だと昔から思っていたとか？

aggre：参考になるかわかりませんが、僕の場合、明確に自分が作りたいものが先にあったので、それを実現する手段を知りたかった。なので、そのプロセスに教育というプロセスを挟んでいない。早く作りたかったので、必要なことを早く勉強したかった。

ひらい：必要なことだけまず勉強して、そこを使いながら広げていくみたいな感じですか？

aggre：そうですね。

ひらい：なるほど。でも、最初だとどこが必要な知識なのかスキルなのか、けっこうわからないのでは？

aggre：基本的に、WebでUIをぐるぐる動かすならJavaScriptで、装飾はCSSで、CSSとJSの正しい切り分け方とか、そういうことは知っておかないといけませんが、CSSとJSの厳密な責務はあとからでもいいと思うので、それぞれなにができるのかがわかっていればいいのかなという気はします。

ひらい：なるほど。ありがとうございます。

スキルを学ぶときは「なぜ？」を考える

ひらい：最後に菊池さんにもおうかがいします。菊池さんは林さんと似ているかもしれないと思ったんですが、計画的にスキルを積み重ねていらっしゃったのかなという気がしています。あるいは「こういったスキルを身につけようと思って勉強する」という計画性みたいなものがあるかなと思ったんですけど。

そのあたり、スキルを習得するときに気をつけていたことや、「このように自分は考えてスキルを積み重ねた」みたいなことはありますか？

菊池：まず最初に、僕も無職の期間がありました。

ひらい：今日は、無職が多いですね（笑）。

菊池：僕はその当時、そんな細々じゃなくて、彼女からお金もらうというダメな生活をしてたことがあります。

（会場笑）

菊池：会社で寝泊まりするという、そんな時期がありましたね。

それはさておき、計画的だったかどうかわからないんですけど。計画的だったかなぁ。どうだったかな（笑）。……そうですね、HTML/CSSに関しては、前の仕事が在庫抱える仕事だったので「在庫抱えない仕事なんだろうな？」って考えてITにいっただけなので、計画性はありませんでした。

ひらい：そうだったんですね。

菊池：UXも言われて「じゃあやろうか」みたいな感じでした。ただ、スキルを習得するときになにをもとにするかというと、勉強するときは必ず「なぜ？」というのはよく考えます。なぜ必要なのかを考えたり、僕は歴史が好きなので、歴史を必ずよく見返す。例えば今のReactとかを見ても、Reactって1996年にも同じようなものがあったんですね。

当時は難しすぎておじゃんになったんですが、今はみんなのスキルが上がったのでぜんぜん使えていますが、そういったものはよく勉強していました。勉強するときに、それがなぜ必要なのかとか、そのほかのチョイスとなにが違うのかということはよく見ます。

Web Componentsについても、実は僕も注目していて。今はReactとかVueがありますが、フレームワークは、Emberもそうかもしれませんが、どこまで続くかいつも綱渡りなので、そこは最後ブラウザに吸収されるというか、ブラウザが実装するものが勝つというのはあります。だからWeb技術を選ぶ上で、ブラウザが取って代わってしまうものは、僕は基本的に勉強しません。

ひらい：なるほど。ありがとうございます。質疑の時間がなくなってしまいまして、申し訳ありません。今日はどうもありがとうございました。

（会場拍手）