授業で習うプログラミングと実世界のシステムは“遠い”
鈴木健太氏：初めてプログラムを書く時って、こういうものなんじゃないかなって思っています。「n番目の三角数を求めてください」。
これは非常にシンプルで、f=1の時に1で、なにか引数を1個与えたら整数が返ってくるという、非常に正解がわかりやすいものですよね。fに2を入れたら3が返ってきて、3番目の三角数に、1と2と3を足せばいいよねとか。前の三角数を足せばシンプルに答えが出ますが、これは本当にシンプルな問題。
ですが、実際のプログラミングの難しさ、あるいは実務の難しさというのは、たぶんこの「三角数が導出できる」ということから飛んで、例えばTwitterを作るとなった時に、無限に作り方があったり、そもそも想像できないというところかなと思っています。
TwitterのUIとかは、たぶんフロントエンドが得意な人なら「ReactでUIを作れそうじゃない？」だったりすると思うし、サーバーサイドのAPIも、例えばツイートをして保存して、それをフォローしている人に表示するとか、パーツパーツのイメージはなんとなく湧くと思うんですよ。
でも、何億人もユーザーがいて、リアルタイムに検索したら返ってくる、というものを作る、かつ、そのサービスをグロースさせる必要があるとなった時に、たぶん、すごく未知のものが多いと思うんですよね。
なので、やはり授業のプログラムと実世界のシステムというのは、遠いんじゃないか？ これは僕自身も学生の時にすごく思っていたことです。
あと、なんていうのかな。やはり実際にサービスを作って世に出してみても、やはりまだまだいろいろな段階があって、そういうところがプログラミング、あるいはソフトウェアエンジニアリングの難しさなんじゃないかと思っています。
スキル磨きに必要なのは「自分のコンフォートゾーンから意識的に飛び出す」こと
とはいえ、やはりスキルを磨かないと、Twitterも作れないわけですよ。やはり（スキルを）磨いていかないと、難しいものにチャレンジすることもできない。けれど、手を動かしてもすごく上達している感じがなかなかしない。先ほどの、「この学び方でいいのかな？」ということですよ。こういうことが起きるんじゃないかなと思っています。
（コメントを見て）「オブジェクト指向概念はなんとなくわかってきたけど、実際にどこで使うの？」。うんうん。車とかで例えられてもね。はいはいはい。
教科書どおりに、じゃあ車というものを「Car」にして、抽象クラスとして乗り物というものを用意して、「ride」というのを作って、それはバイクでも扱えますね、みたいな。それはそうかもしれないけど、「じゃあ、実世界でどう使うの？」って話ですよね。そう、そのとおりだと思います。
これってやはり、「わかった」という部分よりも、「できる」という部分にならなきゃいけないと（思います）。その中でのコツとして、自分のコンフォートゾーンから抜け出す、意識的に飛び出すというのが必要だと思っています。
これは一般的な話ですが、「30年間同じ曲を同じやり方で繰り返し弾いてきたアマチュアピアニストは、確かに1万時間分の練習を積んだかもしれないが、30年前に比べてまったく上達していないはずだ」。これは『PEAK』という本に書いてあるフレーズなんですが、そのとおりだと思うんですよね。
毎日三角数を解いていたとしたら、三角数を解くのは速くなるかもしれないけれど、それしか解けないよね。もちろん、同じようなパターンの問題が解けるとは思うんですが、もっともっとレベルを上げたいと思ったら、同じ難易度の問題じゃダメなんですよね。
そのためにやはり、目的ある練習を行う必要があります。これははっきり定義された目標。「これをやるんだ」ということと、あとは集中してやること。そしてフィードバックがもらえること。これは後で話します。
それから、コンフォートゾーンから抜け出すこと。自分が快適だと思って、「これはできるわ」「これは、まあまあできますよ」というものから、やはり一歩飛び出さないといけない。そういうことが、この成人発達理論というものの領域の中で言われていることです。
図でいうと、こんな感じ。ラーニングゾーンに飛び出ていく。飛び出るために何ができるかにフォーカスを置いてトレーニングをしていく。それが大事だという話があります。
抽象的でわかりにくいと思いますが、いきなりTwitterを作るのは、たぶんみんなにとっては飛びすぎで、もちろんモックとして作るのはいいと思うんですが、それってたぶんパニックゾーンに近いです。
数億円のサービスをいきなり作ろうとしても、今学んでいることと、たぶんあまり接続していないんですよね。なので近いラーニングゾーン、適切な課題、適切な難しさに飛び込むということが大事だと思っています。
イケてるソフトウェアを書いたのにユーザーがぜんぜん来なかった
ちょっと僕自身の体験を少しだけお話しすると、大学院1年生の時にスタートアップを始めたんですね。旅行のサービスを作ったんですよ。同じ会社というか元VOYAGE GROUPのインターンに来ていた石田君に「人を誘って旅行に行けるサービスを作りたい」って言われたんですよ。
（それを聞いて）「作れるな」と思ったんです。Webアプリケーションの作り方もわかったし、デザイナーをつかまえて、あとはデータベースとWebサーバーを用意して作ればいいんでしょう、「いけるわ」と思って、「やろう」って言って、楽しそうだなと思ってやったんですよ。
やってみたんですけど、ぜんぜん人が来なくて。かっこよく「俺の考えた最高の画面」を作ったら、ぜんぜんユーザーが来なくて。「アルファ版リリース！」みたいな感じで出してみたら、一瞬だけ一覧ページを見られてすぐユーザーが帰っちゃうみたいな。ユーザーにプランを作ってほしいんだけど、ぜんぜん書いてくれないというのが起きて、「えっ？」みたいな。
「けっこうイケてるソフトウェアを書いたのに、なんで使ってくれないんだろう？」と思ったんですよね。
しかも、サービスは誰かを誘って旅行に行くというもので、ユーザーには旅行を作ってほしいのに、「近くのカフェに行きませんか？」みたいな感じになっちゃって。「いや、海外旅行とか行ってほしいのに、なんでそうなるんだろう？」みたいな。ぜんぜん意図どおりにいかなかったんですよ。
これって実体験として、ただ単にソフトウェア自体の難易度を上げていくということもそうなんだけど、きちんと使われるものをいかに考えて作るかということに対して、フィードバックがすごくあったんですよね。ユーザーは素直だから、あるままにしか使ってくれないんですよね。
（コメントを見て）あぁ、そうそう、「新しい需要かもしれない」。でも、それはすごくいい観点。だけど、お金がないんですよね、マネタイズできない。旅行でマネタイズしようとしていたから。じゃあ、カフェでトランザクションでマネタイズしようというのもあるかもしれないよね。だけど、その時はそうではなかったということですね。ただ狙いと単純に違ったという話です。
先ほども話しましたが、実際にやってみて、三角数を導出するみたいなものと、実世界のシステムはやはり遠いなというものについて、ちょっと近づけた、実世界のシステムを当時作りました。リリースしたばかりなので数百万人のユーザーがいるわけでもない、という中で作ってみたけど、同時に、その時は本当に、2、3人のチームで作っていたので、まだまだ本当のソフトウェアエンジニアリングの難しさには到達していないなと思ったんですよね。
というのが、僕自身の経験として、個人のスキルを伸ばすという観点の中にありました。
1人でやれる量には限界があるがスキルを伸ばすことは大事
1人でやれることには限界がある。たくさんのトライをしたい。サービスにたくさん機能を付けたいと思っていても、1人でやれる量にはどうしても限界がある。もちろん、いくらでも素早く作ることはできるけど、やはり限界があるなと思います。
ただ、スキルを伸ばすことで、1人あたりのスピードやクオリティを上げることは可能ですよね。スキルを伸ばすことによってやれることが広がって、トライできることが増える。これは真だと思っています。
一方で、やはりやってみて、仲間と一緒にやるということがすごくおもしろかったんですよね。歳が近いメンバーでやっていて、ビジネスメンバーもセールスメンバーも、エンジニアも、デザイナーも未知の世界にみんなで飛び込むという経験はすごくおもしろくて、「コンフォートゾーンを越える」ということは、単純に、解いたことがない、作ったことがないものを作るということもそうだし、自分だけではなくチームでそこの領域にいくというのがすごくおもしろいなと思ったんです。
このあと、チームでどういうふうに価値を届け続けるかという話をしていこうと思うのですが、そういうふうにチームでチャレンジすることが自分の成長にもつながる。コンフォートゾーンから抜け出すことにもつながる。そういうトライが、個人のスキルを伸ばすことにつながっていくんじゃないかと思っています。
というわけで、個人のスキル編はいったんここまでです。
（次回へつづく）
