インタビュー

2019年05月30日
  • #DEMODAY
  • #ビジョン
  • #DIVE INTO CODE社員
  • #転職

DIVE INTO CODEの冨永修司さんに聞く! メンターとして受講生に説明する際に気をつけている3つのこととは?

Aws4 request&x amz signedheaders=host&x amz signature=8fed4c5fc203b4348103cb25afc37425083ae9aa116c024b3fab2e09762cb679

6年以上エンジニア経験のある冨永修司さんがDIVE INTO CODEのメンターになった理由やメンターとして大切にしていることについて深掘りしたインタビュー記事。メンターとして受講生に説明する際に気をつけている3つのこととはどんなことなのでしょうか?

6年以上のエンジニア経験

エンジニアとしての経験を教えてください。

もともと、情報系の学校卒業後、受託系SESの会社で、客先常駐でCOBOLに6年間携わっていました。将来を考えたときに、Javaのようなオープン言語がメジャーな世の中に変わっていくことに不安を感じました。転職をするにしても、COBOLしかないのは正直、きつい。「新しい言語やればいいの?どういうステップで学ぶべき?どういうことやったら自分は楽しいかな?」そんな風に自分に問いました。

そのときどんな軸で考えを深めていったんでしょうか?

考えることの軸は3つありました。

  1. やりたいこと
  2. できること
  3. やらなきゃいけないこと

この3つでした。

これがぶつかるところはどこなのか。もともと私はIT系で情報共有や人に教えることが好きでした。その結果、結局、たどり着いたのがBtoCのサポートセンター。人に教えることが好きだ、と言っていたら、講師をやることになりました。

技術的に別のことをやりたくなって、BtoBのテクニカルサポートでもActive Directoryの問い合わせ窓口をやりました。覚えることが多く、やりとりは基本メール。エビデンス(やりとりの証跡)を残す形にしましょう、という会社のルールがあったんですね。全く同じトラブルや問い合わせは意外とあまりなかったので、考えてローカル環境で顧客と同様の環境を作成して結果について、お伝えする仕事をしていました。そのときにメールの対応より、人に教えること自体が面白い、と思ったんですね。

そうなってから、研修担当や講師として仕事を探すようになりました。ITを活かせる研修業務を探したんですが、研修の担当者を募集している会社は意外と少なかったんです。そんなときにDIVE INTO CODEに出会いました。

Image from Gyazo

エンジニアに求められるのは「完璧より完了」

特にDIVE INTO CODEに惹かれた部分は?

最初に惹かれたのは社長(弊社、野呂)が私と近い年齢で若いこと。年齢が近いのに掲げているビジョンが大きくてすごく共感できました。Web系の言語や仕組みについては知らない部分が多かったので、興味がありました。

社長が若いことについてはどう思ったんですか?

自分と年があまり変わらないのに、会社を立ち上げて、運営している事に胸が打たれました。夢を持って活動しているところに惹かれ、そういう人の近くにいたら学べるところが多そうだと思いましたね。

実際に学べました?

Webエンジニアとして知識はもちろん、仕事の考え方・進め方・切り分け方・判断は今でも学ばせてもらっています。
私は気付くと完璧を目指してしまう傾向があり、その結果スピードが遅くなることがあるのですが、「完璧よりも完了」させる力強さみたいなことを学べました。

でも、100点を目指している性格だと、「70点」だと嫌になりそうじゃないですか?

初めて DEMODAY のディレクターをしたとき、タスクごとにスケジュールを決めて動いていました。(DEMODAYとは、DIVE INTO CODEの卒業生を中心に、実務経験1年未満の「駆け出しエンジニア」が出場応募権を得られるピッチイベント)
そのイベントには、発表者や通常の参加者以外にも、発表アプリケーションの審査員もいました。その審査員の方に「暫定でもいいからイベントの詳細が欲しい」と言われ、取り急ぎ暫定版をその方に送信したところ、すごく喜んでくださいました。
当日も緊張している私に「肩肘張らなくていいよ。リラックスしてね。」と言ってくださり、その時初めて、真の意味でザッカーバーグの言葉である「完璧よりも完了」させることの重要性を理解できた気がするんです。
そもそも自分の中での100点満点って、他人からすると、違う点数だったりもしますしね。

完璧主義とバグ

そもそも100点満点を目指すという考え方はどういうところから生まれたんですか?

エンジニアが開発してお客様にリリースするシステムは100点満点でなければなりません。これは80点や99点は認められないということです。特に金融系のシステムであれば一つのバグで新聞やニュースになります。それくらいバグを出す事は考えられない世界でした。
また、BtoB のテクニカルサポートはメールに自分の検証結果を載せたり、操作手順を明文化してしてメールで送信し、証跡を残します。こちらも間違った内容を送信してしまうと会社の信用問題になる、という仕事をしていました。だからこそ、「完璧主義」としての自分が形成されたんじゃないか、と思います。

とすると、昔は完璧主義じゃなかったんですか?

いえ、多分昔から比較的完璧主義だったと今は思っています笑
というのは、周りからは良く「真面目だよね、A型でしょ!」とか言われていました。実はO型なんですけどね・・・。

先ほどバグを出さないようにしなければ、という話があったのですが、バグを出した苦い思い出はありますか?

常駐先の社内メールシステムにて、組織改正に伴う登録メールのグループ分けをする修正案件を担当しました。私が修正した部分のプログラムを本番リリースし、しばらくすると、一部の人がメールを使えなくなったという連絡を受けました。「送信したメールが届かないみたいなんだけど、どうなってるの」となってバグが発覚しました。
不幸中の幸いと言いますか、使えなくなったグループが比較的少数のグループだったので影響範囲は小さかったです。結末としては、午前中に発覚し上司や先輩に怒られながらお昼には改修出来ました。

Image from Gyazo

プロエンジニアになるためのチャンスをつかむ場

それは素晴らしいですね。冨永さんにとって野呂さんはどんな存在ですか?

スーパーマンで元気のかたまりという感じです。メンターも日々学習しています。夜中までPC を立ち上げて、slackを見ると、2時頃から野呂さんのランプは光っています。この人はいつ寝ているんだろう、と思っていました。そんな感じなのにいつもハツラツとしています。

DIVE INTO CODE の理念については?

「プロのエンジニアになるために挑戦する人が、チャンスをつかめる場をつくる」については、もともと、教える仕事がやりたいということもあったので、ぴったりでした。素質を持っている未経験の人を一定のレベルまで引き上げることはできますし、そうなった時のインパクトは非常に大きいと思うんですね。

エンジニアになる人のバックボーンはいろいろあります。経理からきました、とか、営業やってました、とかいろんなかたがいます。自分のスキルとITを組み合わせたときに、この人にとってどんな武器になるんだろう、と思っています。

最近ですと、スキルの掛け算みたいなのがあって面白いですね。

スキルの掛け算とは

スキルの掛け算の具体例ってありますか?

個人的な話になるのですが、エンジニアになろうとする前に、医者になろうとした時期がありました。テレビを見ていて、アフリカの子供達が亡くなっている映像を中学校のときに特番で見ました。世界で起きる仰天ニュースみたいなやつですね。自分は五体満足でご飯も食べられる一方で自分より若い子供たちが注射一本打てないが故に死んでしまったりする。そのときの特集がエボラウイルス病だったのですが、こういう病気の特効薬を作って、治せたらいいなと思っていました。大学受験のときには、薬の開発者になりたい、と話していましたね。

その話を先生に相談すると、「そうなると、クラスで一番にならないといけないよ。薬剤師になると、学費がかかるけど親御さんは大丈夫なのか」と先生に言われました。私は化学ができなかったんですよ。なので別の方法でアプローチを考えました。その結果、物流をうまく回せるシステムを作ることができれば、薬を届けることに貢献できるのではないのか、と思うようになりました。当時、16歳のことです。

そんな子供のころの夢と受講生さんの考えや行動が重なる瞬間があります。前回のDEMODAY6th(2019年4月開催)で、受講生さんが「薬局をGoogle Mapsで表示して、どこの薬が一番安いか、可視化するアプリ( https://www.precal.jp/ )」を作られていて、自分の思いやスキルと受講生との間で掛け算が起きたと思ったんです!

メンターに求められる3つのこと、そして夢

素敵ですね!そんな冨永さんがDIVE INTO CODEのメンターとして大切にしていることはありますか?

3つ個人的に大切にしていることはありますね。

(1)相手のやる気を無くさないようにする発言を。
相手のやる気を無くさないようにはしています。ふとした言葉で傷つけちゃうことってありますよね。そう言うつもりじゃないのに、真逆になってしまう、なんていう経験があるので、普通の言葉かもしれないけど、発言する時は一瞬ブレーキをかけるようにしています。発言に気をつけています。

(2)わかりやすい説明のために「教える角度」を変える。
全く相手が理解していないことやピンときてなさそうなところについては、図解したりして説明したりしています。教える角度を変える。図を使う、言葉で説明する、ログやソースを見せたり、それぞれの角度を変えて、説明をすることで、どこかに相手に伝わりやすいポイントが見つかったりします。

(3)答えを言い過ぎないこと。
最終的にDIVE INTO CODEを卒業した後は、自走する存在になってほしいという思いがあります。エンジニアになった時に指示を受けてやる仕事ではなく、どこに課題があるかわからない仕事に対してやり抜かないといけない。自分で考えてこないで、聞いていた人っていうのは、試用期間中に切られてしまったりします。卒業した時には自分で考えられるような人材になってほしいと思っています。だからこそ、あえて答えを言い過ぎないようにしています。

今後こんなことをやっていきたいと思っていることは?

DIVE INTO CODEの卒業生の中から医療の革命を起こす人を輩出したいですね。それこそ、これが自分の原点の夢ですから。そこにつながっていければ幸せだと思っています。

Image from Gyazo

取材者メモ

取材をしている時に気づいたのですが、冨永さんはDIVE INTO CODEのバリューを実は体現していました。

具体的には

自己成長      = 答えを言い過ぎないこと
問題解決能力を持つ = わかりやすい説明のために「教える角度」を変える。
他者貢献      = 相手のやる気を無くさないようにする発言を

という形で実はDIVE INTO CODEのバリューと冨永さんの考え方(ウェイ)が連動していたんですね。これは、すごいことだと思います。そんな素晴らしいメンターのいるDIVE INTO CODEはとても魅力的なプログラミングスクールですね!

DIVE INTO CODEのことをもっと知ってみませんか?