島までは遠い

佐藤正志@サークルアラウンドのことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる予定。しばらくは工事中。

プログラミング言語と業界での使われ方の関係こんな感じで合ってます?【その後】

はじめに

ms2sato.circlearound.co.jp

先日こんなエントリを書いたのですが、その周辺で起きていたコミュニケーションを少しまとめておきます。

反応

Twitterなど

世の中全体で考えるとPHPが多いよというお話。元記事でも書いてますがこの感覚同感です。潰しのきく感はPHPに軍配かなぁと。「とにかく仕事にありつきたい」というスタンスならやはり良さげなのかな?ありがとうございました!

私がわからなかったLaravelについて。Railsと同じ領域で使われているという情報がありました。ありがとうございます!

mstdn.techdrive.top

node.jsの使われているところに言及してくれている貴重な意見。ちなみに

あ、ここで"大手" とはスタートアップ系大手(LinkedInとか)で、SI大手ではないです。

とのことでした。海外のブートキャンプ系がnode.jsで学ばせることが多いのはこの辺りの事情なんですかね?恐れ入ります!

コミュニティより

Developersjp

色々と活発な意見をくださったオンラインコミュニティの皆さん。概ね内容としては元文章のイメージで大丈夫だと思いました。JSについては私がシステム開発の文脈で語ってしまったのですが、

JSについては、クリエイティブが中心のところで「魅せる」ことが必要になる際、SPAバキバキだったりすることもある。

というような意見をいただきました。感謝。

元プログラミングを学び合うシェアハウスメンバー

こっちでいただいた中では、Go言語の話。

インフラ系をいじっているエンジニアにはGo言語を嗜んでいることが増え始めていて、クロスコンパイルで様々な環境で動かせることもあってツール系を作るのに多く用いられる。

というような感じでした。ありがたや。

おしまいに

「そんなんじゃねぇよ。本当はこうだろ!」 みたいな意見が出てくれるようなのをちょっぴり期待していたのですが、そこまでは行かず。ただ、どうやら全然的外れでも無さそうですね。しばらくは元記事のイメージで進めても大丈夫かもしれません。

自社のプログラマートレーニングを代表自ら暑苦しく解説してみちゃうぞ(長文注意)

f:id:ms2sato:20180716113308j:plain

はじめに

表題の通りなんですけどWEBページとかではなんとなく軽い感じがしたので、暑苦しく(重要)語ってみようかと。この暑い盛りにさらに体温上げて書いてます。

トレーニング

WEBプログラミング個別トレーニング

circlearound.co.jp

弊社が3年半前に最初に掲げたトレーニングは「WEBプログラミング個別トレーニング」でした。最初のサービスでかつ象徴的サービスです。いわゆる一般のスクールさんとの違いがこのトレーニングに込められています*1。私が持っているスクールへの反抗心の表れとも言えます。

  • 現役の先輩エンジニアがトレーナーとしてマンツーマンで担当者になる
  • 書いてもらったコードは100%先輩が全部レビューする
  • 決まったカリキュラムが無く、受講生からのヒアリングを通して作成する成果物を決める(多くはWEBサービスなど完結したもの。稀に機能の一部の場合もある)
  • 成果物への道のりをGitHubのIssueでプロットしながら進める(最初はトレーナーからIssue立てするけれども、徐々に離れて自分でIssue立てて貰う想定で誘導していく事が多いです)
  • 問題と回答の為のサービスなど「学習専用」の仕組みは用意しない。GitHubとSlackでなるべく実際の現場感を作って進める。

とにかく元々がOJTでやっていたことを再現したかったので、私が当時やっていた「作りながら学んでもらう」をなるべくそのまま移植するイメージです。「丁寧な手順書ドキュメントがあってそれを写しさえすればうまくいく」などというのは本質的な学びではありません。

実務で作るようになったら丁寧な手順書的なドキュメントなどない中で検索をし、試行をし、思考して問題を解決しなければならない。その能力を鍛えずに何を鍛えるというのか。そして、これを今、現実的にうまくやるには人の介入が必要だ

というのが私の考えです。このサービスは始めてから色々と改良を加えながら進んでいますが、基本的な方針は変わりません。そして後述する複数のサービスにそのエキスを分け与えながら進んでいます。

言語や環境を何か決めているわけではないので、相談があってやれそうなら何でもやります。例えばJavaScriptについては弊社の小笠原が得意なこともあって「デザインやコーディングをメインにしている方がJSの能力も獲得していくところ」にフォーカスした形のトレーニングを何度もやらせていただいています。これはかなり好評で、特に昨年後半は延長や再受講の依頼もあり、引っ張りだこでした。 「なんとなくjQueryのプラグインを使って訳も分からず動いていた」というところから「簡単な機能なら自分で書ける」を目標にするもので、必要ならthisやクロージャ等の知識も入れてやっています。

WEBサービスチーム開発トレーニング

circlearound.co.jp

個別トレーニングを始めて暫くして「トレーニングを受けた後の人が実際の現場に入るまで」に必要な事を埋めるサービスを考える必要に駆られました。当時も今も、弊社は現場で活躍できるようになる為の事をするのが大切な方針の一つなので、より実践的な場を作るべきと決め、WEBサービスチーム開発トレーニングを立ち上げました。その為に新たに小さな社内サービスを作成することにし、これを題材にGitHub-Flowを行ってトレーナーと一緒に作成します(場合によっては弊社の関係している業務委託の人が一緒だったりしている時期もあります)。

この試みは当初全く引き合いがなく鳴かず飛ばずでしたが(自信あったのですが...)、個別トレーニングからステップアップで上がっていくスタイルとしても用いられます。このトレーニングを介してナチュラルに弊社流の開発を学んでもらいます。シンプルなGitHub-Flowとラベル中心の開発、Issueのこなし方や質問の仕方などを実際に進めながら経験できるので、受講生と言うよりチームメンバーになってもらう雰囲気です。もちろんサービス自体は社内で毎日利用しているものなので、それなりの責任感を持って当たってもらいます(実際止まると弊社メンバーはとても困ります)。

過去このトレーニングを十分に受けた人は初期ではフリーランスとしてそのまま独立していく事ができ*2、最近ではその成果をポートフォリオの一部として転職活動を成功させている方もいます。チームでの開発経験があるかどうかは一つ大きなラインだと私は思います。

初心者向けWEBプログラミング個別トレーニング

circlearound.co.jp

「初心者向け」とあえて銘打ったのは以下の理由からです。

  • 完成するものを限定しています。簡単なBBSの作成を通して全体像を学ぶものです。
  • PHPで「初めてのサービス開発」を成功させるところをイメージしています。

「なるべく簡単にサービス開発を経験したい」という要望はトレーニング開始当初から起業志望の方やコーダーの仕事をされている方から受けることがあり、こういった層にどんなことができるかを弊社の1号社員である齋藤と相談する中で生まれたものです。齋藤が入ってきて最初の自社サービス主担当だったので、思い入れは深いサービスです。二年前くらいは引き合いが多かったのですが、その後Rails需要に押されて若干しぼんできているものではあります。

どんどん進めれば単なるオープンな掲示板をログインできるものにしたりなど改造していけるので、個人的には費用対効果の高いサービスだと思います。カリキュラム型に近い進め方を試した結果でもあります。

RubyClimbing

circlearound.co.jp

上記のような本格的なトレーニングをやっている中で、世間が変化してきたのか「将来的には職業にしたいけれど、これからやろうとしていて指針が無く辛い」という層の連絡が増えてきました。特にRailsが流行り始めた影響で「Railsで」という限定も増えてきた為、弊社がオフィスを単独で構えたのを機に小笠原に考えてもらったのがこのサービスです。

個別トレーニングを進めるのにまだ基礎の足らない人に勧めていたUdemyの動画や、新たに作った言語学習のコンテンツなどをまとめあげて「会社帰りの会社員でも駅前留学のごとく勉強できるようなもの」としてスタートしました。

もちろん個別トレーニングほどのコストをかけずにやれるように作ったので、お値段的にも格安にはしましたが「カリキュラムに沿ったドキュメントを渡して写せばいい」というようなことを許さない形で、主に小笠原が教官として週一回の訓練を担当しています。理解度の確認は人と問答を通して行う方が良いので、この形式は崩していません。

この内容をシッカリマスターするだけで、力技だとしても、自分で考えて作りたいものがある程度作っていけることを目指しました。最低でもWEB開発のポイントを抑えられるように設計しています。Railsで開発できることを目指したものではありますが、WEB開発に無くてはならない基礎知識が凝縮されて詰まっています。

今では実力が不安な場合には、個別トレーニングを受ける前にRubyClimbingの2週間無料の期間中で実力を見極め、その上でコースを選択できるようになりました。適切な段階を踏んで学習する方が効果が高くなるので、こういったステップ化は大切であったと思っています。

iOS個別トレーニング

circlearound.co.jp

WEBプログラミングの枠組みで、SwiftによるiOSアプリの指導を外部の講師にお願いしました。担当の小橋さんが超有名サービスのアプリ開発をされていた方なので実力は保証できます。また人柄もとてもよく、察してアドバイスをくれますよ。今後もWEBサービスの開発に限らずトレーニングの幅は広げたいと思っています。

ただし付け焼き刃でやるのではなく、現役でその技術を日々行使している人にトレーナーをお願いしたいですし、個別トレーニングのマインドに合致する講師をお招きしたいと思います(立候補いたらぜひ!お話聞かせてくださーい)。

トレーニング全体的な話

個別トレーニングを始めた当初は特に言語もレベル感も決めていませんでした。中・上級者の声かけでも「私が対応できるものであればなんでも対応しよう」という気持ちでいた為です。実際に市場に出した時にどんな反応が返ってくるのかを見て、行先を決めようとしていました。

3年半続けてみて、現在の市場は転職する際の支援をするのが需要として適切であるらしいという事と、弊社がスタートアップや新規事業の開発受託も行う都合上Ruby on Railsを扱う事が多いため、その成分多めに舵を切っています。

とは言え特に初学者とか就職に限定することなく、既に現場にいるけれどもスキルアップがうまくできていない場合や、より高みを目指す上での相談も受け付けています。近場に師匠的な人が見つからない人であれば誰でもお話聞いてみたいです。あまり表に出していませんが、主にお知り合いの法人さんに法人向けプランを作って提供したりもしていました*3

受講した人の話はこの辺りに入っているのでよかったら見てみてください。 circlearound.co.jp

特徴やその理由

月額モデルである理由

現在のトレーニングは全て月額モデルにしていて、終端期間を基本的には決めていないものです。その理由は下記のような考えによるものです。

  • 「早く成果を出して卒業したい」というモチベーションを作る為*4
  • 個人によって「合う、合わない」があると思うので、途中で離脱する事が容易な形にしたかった為
  • 完遂までの期間がそれぞれの人で異なるので、それに合わせるには期間を決めずに推進する事が良いと考える為
  • 先に高額を取るモデルは、経営者の私が初心を忘れれば「とりあえず入学させて諦めさせて利益最大」という邪悪なやり方になるので、それを防ぐ為

面談などする上で大抵「どれくらいの期間かかりますか?」と聞かれるのですが、この質問が実は一番厳しいです。「大抵これくらい」というのはなんとか伝えることはできても、その人が本当にその期間で終えるかはわかりません。なるべく「教えたという事実」を提供するのではなく「理解獲得したという事実」を提供したいと思うのですが、簡単では無いなといつも感じます。

担当の先輩が育てるモデルである理由

私がプログラマーとしてのキャリアの中で様々な開発メンバーのOJTをこなしてきた経験をベースに以下のように考えているからです。

  • 「こいつを一人前にしたい」という意思のある人が育てていく事が重要であるから
  • 速度を上げて実力を引き上げるには、対象がまだ得ていない概念や哲学を持っている人が適切であるから
  • 「相手が何に躓いていて、どういう示唆を与えればその壁を超えるか」を考えられる人であるべきだから

だから、カリキュラムを覚えた人を即メンターにするようなモデルは行いません。それくらいハイレベルなことをトレーナー陣には要求しているし、学習も求めるし、実際それに応えてくれていると思います。そういう意味で弊社のトレーニングは格安で提供していると自負しています(「現場で普通に活躍できる能力を持つ人が、マインドを持って他者の能力アップの為に接する」というのが実際稀有であることは、現場で働いたことのある人なら容易に想像できることでしょう)。ここまでの背景を伝えることが難しいので、単なる割高なサービスであると思われるのだろうとは感じています。

もちろん企業努力として価格を下げることを考えて実行した結果が RubyClimbing などに現れています。

おしまいに

とにかく思いの丈をぶつけてみました。暑苦しくてごめんなさい。 もしもこの文章を読んでのぼせそうな程体温が上がった人がいたら、今度弊社のトレーニングについて皆さんにお伝えする場所を設けたので話し聞きにきてくださーい。

techdrive.connpass.com

*1:大きな意味では同じ領域にいるのはわかるんですが、自分としては全然違うことをやっているつもりなんですよね。カリキュラムとドキュメントを写して学ぶこととは違うことを鍛える目的なので

*2:もちろん受講生本人の努力もありますし、フリーランスは単純に技術力だけでもないので、どなたにでもやれる事だとは思っていません。

*3:どんな人が受講する予定で、何を求めているかなどヒアリングさせていただき、合致すれば進める形です

*4:実際には「卒業」という明確なラインが敷かれるのではなく、成長実感と満足により私たちが不要となることを目指しています

プログラミング言語と業界での使われ方の関係こんな感じで合ってます?私目線書いてみます。

f:id:ms2sato:20180709210030j:plain

はじめに

ちょっと前に(元の情報が見つからなかったので引用できませぬが)「スクールがRailsを教えるのはそれしか教えられないから」のような話題が出ていて、しばらくしてから、下記の内容が出てました。

この内容の出元はおそらく私だと思います。弊社のiOSメンタリングの最中に挟んだ雑談の内容が元だと思うのですが、若干ニュアンスが違うところもありそうなのと(極端に見える)「就活をしている時にこういう内容が知りたかった」と仰っていたのもあり、改めて文章にしてみます。

前提やスタンス

以下の文章は私個人が見えたり聞けたりしたものから推察しているものなので、特に統計を取ったり確約できるような情報があるものではありません。また、もしも私なんかより確からしいことを知っている方がいたら(人材系のお仕事の方とか詳しいですか?)、情報出していただけると皆にとってプラスになると思います。私もそういう情報を拝見してみたいです。まず自分の理解を出してみようと思いました。

「ここは今は違うよ」とか「実際はこうだよ」とか指摘あったらブログなりで是非いただけると嬉しいです。確からしい情報をできれば手に入れたいです。

会社作る前(7年以上前)のフリーランス時代の体験と、その後の会社を作ってからの体験の組み合わせでしかないので偏っている可能性をご理解ください。また私がシステム開発の分野で仕事をし続けているので、クリエイティブな分野やゲームの分野などについてはノータッチにしています。

言語や使われている業界などについて私目線の話

Ruby(Ruby on Rails)

言語で言うとRubyですが、WEBの開発になるとほぼRuby on Rails一択になっていると思います。なので以下Railsについて記します。

特徴として「素早く顧客に価値を提供できる」というものがあったので(最近は他のフレームワークも追いついてきていると思いますが、当初の売り文句がそうだったし、そういう歴史を重ねているはずです)、スタートアップや新規事業で用いられることが多いと思います。以前より割合が多くなった印象もあります。

そのため、最近の求職で「自社でサービスをやっている会社」という風に調べていくとRailsを利用している会社が多くヒットするのではないでしょうか。

PHP

多分大きくいくつかのタイプに別れると思います。

OSS利用の制作案件中心(Wordpressなど)

いわゆる「ホームーページを作ります」のような案件でよくWordpressのようなCMSが利用されてきた流れがあったので、それを踏襲しているものです。場合によってはECCubeなども組み合わせたりとかあったようですが、どちらにしてもOSSで提供されているものをカスタマイズして納品していく比較的小規模な受託ビジネスや、フリーランスさんの案件で傾向の多い内容だと思います。Lancersさんのようなクラウドソーシングを探ると一時期こういう案件がかなり大量にヒットしました(現在はよく知りません)。

システムとしての難しさよりも、お客様の望む見た目のサイトを作ることになるので、利用しているOSSのカスタマイズのコツやHTML/CSS側で見た目を整えることが望まれるはずです。

古くからの開発会社(Zend Framework、CakePHP2などのフレームワーク利用)

システム開発を古くから続けている会社さんだと、以前流行ったフレームワークで納品し、そのまま使い続けている場合があると思います。Zend、Cake は以前よく使われていたはずなので、これを使い続けているところは比較的安定したお客さんを抱えて保守運用などを続けているのではないかと推察します(システムが稼働し続けているのはその表れかと)。その意味でビジネスとしては安定しているかもしれませんが、流行りの仕事をやったりするのは難しいのかもしれません。

通常の転職市場だとこのあたりは結構出てくるんじゃないかと想像していますが実情どうなのか気になります。

その他(Laravel)

結構前から海外ではLaravelがよく使われるようになってきているらしいのですが、最近国内でも Laravelを推す方がよくいらっしゃる気がします。こういう方々はおそらく上記の2つのパターンとは違う業務をされている気がして(あくまで気がして)、別に分けた方が良いのではないかと思いました。Laravelでスタートアップとか増えているのでしょうか(知りたい)。

Java

サーバーサイド(J2EE)

J2EEで一緒くたにしてしまいましたが、多分概ねこのくくりでいけるんじゃないかと思っています。15年くらい前はこの界隈で技術者をしていました。例えば銀行さんみたいなカッチリ作って計算が間違うと困るような業務システムでよく使われていると思います。今でも比較的大きめの会社内のシステムはJavaで作られているのではないかと想像しています。

システムの規模感としてはかなり大きい場合が多いでしょう。

モバイル(Android)

同じJavaを使っていながらも、こちらはちょっと別口になります。サーバーサイドは重厚なシステム開発になると思いますが、モバイルアプリはよりライトに仕上げていくことが可能でしょう。最近だとKotlin が公式で認められたので新規で開発する際にJavaは減っていくのでしょうね。

Python

この界隈詳しくないのですが勉強したことをちょっぴり書いておくと、機械学習をするためのライブラリが豊富なのでその方面でよく用いられているそうです。以前はGoogleがPython推しだったのでGoogleのソリューションを使う際にSDKが早めに提供されていたなどがあったはずです(初期のGoogleAppEngineとかね。あの頃面白かった)。最近はあまりよくわかってません。ごめんなさい。

JavaScript

システム開発においてはサーバーサイド言語で出力したWEBにちょっとした演出をするくらいのイメージで、それが時代とともに変化している最中です。 単体でJSを推してくる会社やプロジェクトはおそらくSPAを進めようとしていてReactやVueなどをどんどん導入していきたいか、node.jsでのシステム開発をしているかのどちらかではないかと推察します。ただ、どちらも多くはないのではないか、というのが所感です。

以前よりはSPAを求められるケースは増え続けていると思うのですが、バキバキにやりこむレベルで必要なシステムがそうそう無いのではないかなと推察しています。結果としてJS力を求めるところはとても高いレベルを求めていて、そうでないところはさほどでもないという、中間があまり求められない存在になっている気がします。

そのほか

あんまり詳しくなくて書けなさそう。

おしまいに

私が趣味でプログラミングを学んだウン十年前と違って、今は「就職のためにプログラミングを学ぶ」みたいな方も増えてきました。そして簡単に調べようとすると声の大きい情報しか目につかず、結果的に自身の向かう方向に合致しない内容を学習してしまって遠回り(長期目線では遠回りだと私は思いませんが当事者としてそう感じるのはわからなくないです)になってしまうことがある様子です。

また、就職のためだとすると何か就職サイトでどの会社がどんな言語で人材募集しているかをリサーチしてみるのは方針を決める一つの情報になるのではないでしょうか。

この文章は少なくとも私の目線でこう考えていて、誰かに聞かれた際にこんな感じに答えていますよ、というのを纏めています。

蛇足ですが、2014年あたりに当時フリーランスだった私がちょっと生きの良い若い人たちとやったワークショップも参考になるかもしれません。この頃はそれほどRailsがワイワイしていなかったのかもしれませんね。今はスクールのおかげもあってか名前をよく見るようになったと思います。 qiita.com

謝辞

実はこの文章いきなり公開するの怖くて何人かの知り合いに見てもらって意見もらったりしました。特に活発に意見くれた Developers.jp - 優しいエンジニアのための オンラインコミュニティ の皆さんに感謝。元「プログラミングを学び合うシェアハウス」の住人もThanks!。

「教え合う」ことで将来の不安を払拭したい。衰えるその日のために。

はじめに

startup-technology.connpass.com

最近おっさん系イベント続きですが、今回はこちら。スタテクの菊本さんがオジさんのイベントやりたいーって言ってたんで「私からも演者紹介できますよ」と応援メッセージしてたら実現してくださいました。わーい。

資料は下記です。 speakerdeck.com

内容は置いておいて「年齢を経ると成長が鈍る」というのは以下のようなことで起こるんじゃないかと思っています。

  1. そもそも知っていることが増えてきたので、新たに知ることが減ってくる、新鮮味の欠如。
  2. 新たなことを学ぶ脳の活力が鈍る、能力の低下。
  3. 誤ったことをしていても指摘してくれる人が減ってくる、社会立場的な課題。

1については、成長が一気に起こる人だと結構早めにくるのではないかと思っています。私は一度伸び切った感が30前くらいであって、それからはユックリ伸び続けている(と言うよりもその時取りこぼしていたものを拾い集めていびつだったピースを埋めている感じ?)人間なので、その頃には衰えまでいかなくても危機感を感じたりしていました。

当時20代中心の若いチームの面倒を兄貴分的にみさせて戴いたりしていましたが、彼らの成長と自分の成長を比較した時にどう考えても逃げられるような感じがしなかったんですね。

そんなことをポロっと当時のチームの人に話した時に「教え合えばいいじゃないですか」というシンプルだけども大事な言葉を貰って、改めて戦う意欲が湧いてきた経験があります。それからは将来私と教え合ってくれそうな人を育てていくのが生きがいの一つです。私が人の成長にコストをかけるのはその人の為だけではなくて、最終的に自分の為なんですね。

「教え合う」ために、やるべきこと

教え合いを実現させるのに大切だと思うことの一つに「私自身がふんぞり返っていてはならない」ということがあると思っています。たとえ彼らが仏心を持ってもう伸び代のたいしてない私に時間を使ってくれようと思ったとしても、こちらにそれを受け入れる態度が無ければ長くは続かないでしょう。そういうところで変なプライドを持っていると、私の望む将来の形は実現しないので、なるべくメンバーとフラットな関係を作りたいと思っています。

「経営者とか労働者とかいうことはただの役割と責任の重さの違いだけ」という形が理想です。多分弊社ではそれほど高圧的に経営側から何かを突きつけてはいないと思っています(たぶん、だといいなぁ)。私自身も現場で汗水流す一人であるから、現場がやりやすい形を私自身が考え続けている為でもあるでしょう。

何より私が会社が嫌いだった人間なので、あまり組織だった形にすると出社拒否してしまうからです(笑)

フラットとは言うものの、私のところのメンバーは皆いい人過ぎてこちらをなるべく立てるようなことをしてくれたりするのですが、その立てようとしてくれるところの下にいかに入るかが私の課題であったりもします。稀に、お互いが下に入ろうとし過ぎてわけのわからない戦いが勃発する場合もあります。

そして本当に衰える日のために

2の能力の低下は確実に訪れるでしょう。そんなことないと思うのは強がりや思い上がりだと戒めています。もちろんそう簡単に屈する気もありませんが。

今は私からメンバーへの情報の流れの方が多いとは思いますが、彼らがそれを吸収して成熟する頃には逆に私の方が教えてもらうことは増えていくのでしょう。きっと今の私が持っているものは陳腐化して古典になってしまうから、新しいものは彼らの方が詳しくなるはずです。

そうなった時には私が教わることで会社に貢献できる何かがあれば(この時どういう立場にいるかは正直わかりません。コード書いていない可能性もありますが)、皆から自然に教わって、その時の意思決定なり、実務なりに活かせるようなあり方を今から鍛えておきたいです。その為にも3の社会立場的な課題を発生させない努力が必要だと考えます。 一朝一夕にはできないと思うので、自制したりビジョンを描いていける今から少しずつ行えたら良いですね。

願わくば本当に衰える頃に、自然に教え合うありかたが作れているように。

f:id:ms2sato:20180304003900j:plain

テルと私、もしくは客員iOSトレーナー小橋先生の人となり

はじめに

弊社でこの度iOSのトレーニングを始めました。講師の小橋先生がここまでしてくださっているのに、お願いした私が何もしないわけにはいきますまい!というわけで小橋先生と私の話です。先生の人となりがわかるエントリを目指します。

出会いはプログラミングを学び合うシェアハウス

storys.jp

私とテル(小橋先生をプライベートではずっとこうで呼んでいるのでこの記事ではそれで)の出会いは「プログラミングを学び合うシェアハウス(PGHouse)」という企画のおかげでした。当時テルは文系の学生で「どこかでコーディングについては勉強したけれど色々これから」くらいな感じでした。

今も昔も彼は「ナイスガイ」と言うにふさわしい気持ちのいい性格で「何かやろうとする時にこういう人と組むとだいたいうまくいく」というような、バランスよく物事なんとかできる人という感じでした。

プログラマーという職種から想像する内向的な感じとか気難しい感じが一切ない、我々からすると新世代な感じのキャラクターですね。しかもイケメン。天は何物与えるのか。

「でも、プログラミングは楽しいっす!」

比較的日中一緒にいる時間の多かった私とテルでしたが、家のリビングに来てもお互いのコードを書いていた時間が多かった記憶があります。たまに難しい概念やハードルの高い実装がある時などに色々と会話するような感じですね。

そうしているうちに私が受託していた仕事の一部を切り出して渡したり*1して「単純に一緒に暮らしているだけ」というよりも「仕事も一緒にする」関係になっていきました。責任感があるのでちゃんとやり通すし、わからないことはポイントをまとめて質問してくれるので、安心して仕事をお願いできました。

彼の友人が頻繁にシェアハウスに遊びに来て、新しいサービスやアプリの企画を練っており、常に何かアクションして上を目指している姿勢も好ましかったです。

開発の話ばかり書いてしまいましたが、酒を飲みながら長話するような時もあって、学生ならではの進路や将来についてのイロイロなどを聞かせてもらったりもしています。そういった話の中で彼がポロっと言った「でも、プログラミングは楽しいっす!」という言葉は今でも私には大事な一言になっています。本人はもう忘れてしまっているかもしれませんが。

「コードを書くのが楽しい」ということを知っているのは実はとても大事なことなんですよね。

iOS技術の研鑽

家は一年間の企画だったので一年後解散したわけですが、彼はサイバーエージェントへ入社を決めていて、もう波に乗ったなという感じです。 その後もテルの声かけでPGHouseメンバーの飲み会が開かれたり(こういうところ本当にマメで尊敬します)などして、年に何回かは会っていました。

しばらくして何かの機会に二人で会った時に「今はこういうのに取り組んでいるんですよ」と見せてくれたサンプルが素晴らしかったです。 UIの研究サンプルのようなものだったのですが、気持ち良く操作するための演出とか「ついてきてる感」をうまく表現するのに拘っていて「おお!」と思ったのを覚えています。気持ち良いUIまで熟成させるのに、微妙な時間差とか反応を緻密に調整する作業があるということでした。

もはや「あいつすげーなー」と、ただのファンみたいになっていて、iOSやUIに関しては完全に置いていかれてしまったなぁと帰り道に思ったものです。

その後彼の手がけたアプリがAbemaTVとして世に出たと知り、もちろんすぐ使ってみて「あの試行がこういうところに生きてるのか」と感動しました。これで、完全に私は落ちてただの1ファンです(笑)

起業 & ビジネスのパートナー

そしてまたしばらくして、連絡受けたのはどうやら彼が起業することになったということでした。聞けばシェアハウスに頻繁に来ていた友人の井手氏と一緒だということで「あの頃のコンビが復活するのか」という懐かしさと「成功の約束された感」を持ったのを覚えています。

既にいくつかの企画やサービスの立ち上げをされている様子ですが、最近だとAlexaのエンジンを使った下記のアプリが世によく通ったのではないでしょうか。こういう新しい技術を即理解して何かの形にするスピードは、自分も見習わないといけないと思っています。THE BRIDGEに掲載されるとはホントに凄いです。

thebridge.jp

実は仕事でも少しずつ会社間で協力させていただく関係になっていて、例えばサーバーサイドの実装に関してのアドバイスやレビューをこちらから提供したりもしています。弊社は基本裏方商売なので、こういう応援の仕方が一番役に立てるのではないかと感じているところです。

トレーニングやりませんか?

そういう中で「これまで培ったマインドや経験をこれからの人たちに伝えていくのどうですか?」というような話を打診させていただきました。もちろん彼の技術力や経歴も素晴らしいと思っていますが、今まで書いたような彼との関係性の中から

  • 文系学生から努力しながらコードを書くことを学んでいった「積み上げていく努力」や「学習時に躓くことへの理解」
  • プログラミングが楽しいと思えて続けられているマインド
  • 仕事を簡単には投げ出さない責任感
  • なのにガチガチな性格ではなくてイイ感じに接してくれる人間力
  • 何よりも本人が後進の育成をやりたいと望んでくれていること

これらの点を加味すると、弊社のトレーナーをお願いするのに十分な力を持っていると感じているためです。「トレーニングをどのように進めると良いか」の技巧的なことは弊社内でプレ・トレーニングを実施し、既にマスターされていますので安心してお任せできます。

大変お忙しい中時間を割いていただくこともあり、本気度の高い受講生が来ていただけることを望んでいます。小橋先生に師事したいという方、いらしたら是非お声かけくださいませ。中級者以上を目指す方はもちろんのこと、初学者の方も見てくださいますよ!下記からもう少し具体的な内容をご確認いただけます。そしてお問い合わせいただけたら幸いです。

circlearound.co.jp

f:id:ms2sato:20180219215114j:plain

*1:当時はFacebookのアプリで診断とか流行ったと思うんですけど、あの手の感じの依頼が私のとこにちょいちょいあったんですね

何度も書き写すことに意味があるのか。もしくは理解の為に必要な要素について。

f:id:ms2sato:20180217003025j:plain

はじめに

こちらへのアンサー。なんだか長くなってしまう感じだったのでTwitterでは難しそうと考えて、一旦場所を変えさせてもらいました。ちなみに、この一言で私は色々な想いを巡らすことができたので、とても有難い言葉であったと先に感謝をさせてください。興味深い問いをありがとうございました。

この文脈において「理解する」とはどういうことか

まず前提として、私はプログラミングを学ぶ時に「理解する」というアプローチを重んじています。そうするとまず私の思う「理解」についてお伝えするのが最初に必要だと思いました。改めて考えた時、以下の二つの組み合わせではないかと今は結論しました。

  • 組み立てられた論理を脳に写像できている
  • 概念を合点している

特にプログラミング言語やフレームワークは人が作った道具なので、作者の思う「論理を表現しやすい構造」を持っていると考えています。つまり、少なくとも作者がある時点で考えた一定の整合性の下に成り立っているはずです(もちろん破綻している何かもあるのでしょうが、今は目をつぶってください)。

私たちが学ぶ時にすることは、この彼らが出力した論理構造を逆に入力しているのだと思えます。その結果「この道具はxxxの為に使う道具だ」とか「xxxという複雑なものを意識しない為に隠しているのだ」などと整理する事になります。逆に考えると、整理した結果は作者がそれを作成した動機に近いものとなるはずです。

「理解する」とはこの「作者が表現しようとしていた概念や、課題解決の動機や仕組みを脳に写像する」ことではないかと思われます。

無心に書き写す事によって論理を写像できるのか

私の答えは「ごく一部の人にとってはYES。その他多くの人にとってはNO」ではなかろうかと推察しています。これは統計を取ったわけではないですが、私が出会ったプログラマーの卵や、現場のプログラマーを見ていて感じた事です。

「何度も書き写す事で共通した部分に気づく」という事自体はパターンマッチングして一致している部分を感じ取る事と考えて良いと思いますが、それは上記のような「作者の意図を脳に写像する事にはならない」と、私の頭では整理されています。パターンマッチングでは浅いという表現でも通じる人がいるかもしれません。

物事の考え方に、演繹法・帰納法のようなものがありますが、理解する時に必要なのは演繹法の脳であり、帰納法の脳では無さそうだと感じています。繰り返しの果てに何かに気づく時でも、どこかで立ち止まって演繹して理解に至っているのではないでしょうか。

繰り返しで帰納的に獲得している場合の例

私の会社のトレーニングでこのことに近い例が過去にあったのでちょっと出してみます。最近ではRubyやRailsの基礎を学ぶ時に、まず動画教材( 無料版がCodingCastで見れます。解説の動画を全部カットしたので、ScreenCastを真似するものです。 )を提供して予習してもらうことが多くなってきました。この動画を本格的なトレーニングの前に提供したりすると、何パターンかのアプローチをしてくださいますが「時間のある時に何度も繰り返し見る」という形で行ってくださる方が一定数います。

そして、実際にトレーニングに入る際には何かを作ってもらうという事になります。通り一遍の仕様だとパターンマッチングの脳でクリアしてくれます(かなり優秀な場合も多いです。記憶力で素早く書けるんですね)。

少しずつ意地悪な*1実装をお願いすると「システムの中で何と何が繋がっているか」が問われ始めます。例えば、あるところのメソッド名や変数名をあえて変えてもらうようにお願いしたりもします。途端にエラーが出て、それがスッと解消できるかどうかというところ一つでも、理解の深さがわかります。ただ、エラーメッセージの読みが鋭い場合もあるし、概念理解で「あっちを変えるの忘れた」と気づく場合もあるので、その動機が行動からわからない場合もありますけれども。 パターンで脳に入ってしまっている人は、そういう時のエラー解消に大変時間がかかります。一箇所変えた時に、何が影響を受けるのかが整理できていないのですね。論理構造の写像がまだできていない為だと私は考えています。

パターン化されているタイプの人は多くの場合、こういうエラー対応に弱いようです。トレーニングではパターンでインプットされてしまったものを、エラー対応や実装を通じて論理構造を考えていただき、確からしい理解に辿り着いてもらおうとします。

では正しい理解をなるべく早く獲得するには

これを考えるには改めて先の列挙に戻ります。

  • 組み立てられた論理を脳に写像できている
  • 概念を合点している

前者について。コードの繋がりを理解することをしていくことですね。全てのステップを一行1行追わなくても、例えば

  1. 受け取った通信の内容はroutesに渡されてControllerとActionが判断される
  2. 判断されたControllerのActionがコールされる。
  3. 何も指定しなければaction名に対応したViewがレンダリングに使われる

というような、コードの呼ばれていく大まかな繋がりがわかるだけでもかなりのことに対応できます。

実は後者はとても難しい場合が多いです。それは使い方だけを見たとしても「それがどんな概念なのか」を昇華するにはかなりの経験や苦労を要する場合が多いからです。私自身も概念レベルまで何でもかんでも消化できているのかと問われたらNOと言わざるを得ません。ただ、この部分はたくさんの経験を要すると割り切って、既に獲得している他者からインストールされるのも近道だと思っています。実はこの辺りが先輩に教わることの価値だと思いますし、経験値を継承して大きく加速できるポイントの一つであると思います。例えばMVCという概念を考えた時、下記のようなポイントがあると思いますが、最初からこれに合点した人は物凄くセンスがあるのではないでしょうか。そして、これらはより良いコードを書くには大事ですが、そうでないならMUSTではありません。前者の時点できっと動くコードは書けているはずだからです。

  • Viewという表示を司る部分の変更が、大切なロジックの根幹であるModelへ影響する事をできるだけ防いでいる。
  • Controller/View はWEBの事を知っている層であるが、Modelはそれに依存しない。これによってModelだけをWEBのシステムではない部分でも呼び出したりすることが容易になる。

これくらいが良いのでは?

  • 一回真似してみて動くものを手に入れる。
  • 真似した内容をうまくアレンジしながら今度は自分のものを作る or 上記で出来上がったものを改造しながら理解を深める。
  • 難しいことがあったら文書のコンテンツを読んでみたり、最初に動かせたサンプルを弄ったりして確認する。
  • もしも自分でどんどん作れそうだと思ったら、立ち止まらずに進む。
    • コースに乗る必要はなくて、あとで分岐点に戻っても良いじゃないですか。ワクワクしてる時にガンガンやりましょうよ。
  • 次の壁に当たるので教材でも書籍でも人でも何かに当たって新しい情報を得る。
  • 上記を繰り返す。

真似を繰り返すのが回数という数字になって達成感を得てしまうのはソシャゲで何回もタップすると何か出てくるとか、レベルが上がるようなのと似ている感覚ではないでしょうか。本質的に得るべきものは得られてないかもしれない、と疑った方が良いです。

おしまいに

関連してすごく長く続くので一回バッサリカットしました。終わらん笑

既にかなり長くなったのでこのあたりでキーボードを打つのをやめますが、私が考えている「無心に繰り返すことにはあまり意味がない」ということの根拠とか考えをもう少し丁寧に表現してみました。

ちなみに、ツイートの方でも書いていますが、実は繰り返しが本当に必要な人が一定数存在するんですね。このケースはおそらく明文化することができないだけで、何かの形で感じ取ってやれている気がします。繰り返すことでパターンマッチングではないそれが作られるイメージ。私はこのタイプの人を理解してあげることがとても苦手だったりしています。まだまだ修行が足りませんね。

*1:とは言え実際によくありがちな事をやるわけですが

実家のPCデポの解約までの話

f:id:ms2sato:20180214000245j:plain 放っておくと記憶が風化してしまうのでとにかく書いておく。

はじまり

事の起こりは年末年始に実家に帰った時のこと。自宅のインターネットの契約が変わったことは前に伝えられていたのだけれども、相手が悪いことに気づいた。

調べると二年前からPCデポに乗り換えてしまっていたらしい。以前この会社には注意するように伝えていたのだけれども、まさかそうなっていたとは。親父はPCに詳しかったりはしないけれど、営業職でずっと過ごしてきたので契約や商売には敏感だし、そういうことは無いだろうと思っていたがそうもいかなかったようだ。契約内容など諸々確認すると、なるほど噂通りの対応をする会社であるとわかった。

さすがに年明け一日二日に連絡してもどうかと思ったので、その間に家にあった資料を全部写真に収めたり、世間の動向を調べたり(以前あれだけ叩かれたのに、まだほぼ変わらずに営業しているっぽいので、面の皮の厚いことだと思ったが)して、色々と備えた。

ゴールを決める

まず、両親にはどういう形が良いかを相談して合わせた。これが私のゴールになる。

  • 家にインターネットは不要
    • 近所のインターネットカフェで資料を作って印刷している(たまにしか必要ないので、ずいぶん前からこの運用とのこと。今では店に慣れて顔馴染みなのでその方が楽だということだった)。
  • 電話も元の通り使えれば良い
  • 一瞬でもテレビが見れない状態になるのは嫌(テレビ大好き母談)

下準備

まず考えたのが、以前のプロバイダに全戻しするということ。その為に以前のプロバイダのサポートへ電話した。そこでわかったことが下記、驚愕の事実である。

  • NTTの光回線とプロバイダを分けずに、一緒になっている契約をしている場合、解約すると電話番号が変わってしまう。
  • 番号を変えない為には一度アナログ回線に戻し、光が必要ならさらにそこから再契約しないといけない。
  • 今はそれしか方法がないらしい。

結構な人が今って一緒にしているのではなかろうか。安いから乗り換えるだろうがそういうデメリットがあるらしい。

ただ、冷静になって考えると、実家にはインターネットも不要なのだし、そもそも光回線など不要では?という考え方があると気づいた。もしも必要になったらWimaxなどを導入すれば全く問題ないことは以前確認済みの地域でもある。

作戦

というわけで以下のように進めることを決定し、両親とも打ち合わせた。

  • テレビは先に光回線から外してアンテナ繋ぎかえの工事をする。
  • 電話回線はその後アナログに戻す。光から脱却。
  • インターネットは無くなるので全て綺麗さっぱり解約。特に次を決めることもしない。

過去に全て戻る気がするが、顧客たる両親の幸せを考えるとこれが一番良い考え方だと至った。

というわけでテレビは早速両親に手配させ、アンテナつなぎ変えをさせる。どうやら電気屋によると最近こういうケースが多いらしい。 なんとなくわかる。若い人が出て行くタイプの都市なので、残された老人には光回線など不要なのだろう。本当はこの時点で電話回線のアナログかもしてしまいたかったのだが、PCデポ側からやらないとダメだとわかり、全てを決めに行くしかないと至った。

繋がらない電話

そういった諸々の準備をしてから本丸のPCデポへ電話。 1回目は繋がって、色々と顛末を伝えると、別の部署から電話があると言う。それを待つことにしたが、平日の昼間にかけてしまったので返電を取ることができなかった。それから暫く音信不通だったので、こちらからまたタイミングを見てかけたところ、同様に電話を待てとのこと。その日11時までオフィスで待機していたが電話は来なかった。

その次の日朝にかかってきても、仕事の最中で電話を取ることはできず、結果その晩に再度かかってきた。

電話での話し合い

おそらくこういうトラブル的なことに対応する担当の方なのだろう。控えめな口調でこちらを伺うように話す人だった。こちらも特に感情をこめることはなく、静かに趣旨を確認して進める。

最初は通り一遍の解約料金を計算され提示されたが「エスカレーションされているはずの内容についてはどう考えるのか?」という形でこちらの主張を伝えた。

  • 父は新しく買ったPCが家のインターネットに接続できなかったので相談に行っただけだった。そして、自分の家にネットワークがあることくらいは話せる程度に父はわかっているはず。
  • PCデポ側にインターネットを任せるように言われてそれに従った。
  • 家には一台しかPCが無いのに、3台サポートする契約をさせられた。
  • iPadはいらないと言ったのに「とにかく持って帰ってくれ」と言われて持たされた(結局一度箱は開けたが、すぐ閉じた様子)。

こちらとしては「不当に高い契約を誘導されて契約させられている」という点を主張。また、私も電話口の担当者も当事者では無いため「確からしい落とし所を一緒に探る」という形で合意を作った。彼も私も当事者への説明義務があるものの、一方的に自身の主張を通せる立場では無いのだ。

そして落とし所を以下のように決めた。

  • サポートサービスの解約料金は一台分の契約のものと同額にする
  • そのほかの解約料は全て無料とする。

訪問

電話のあとE-mailのやり取りで訪問の予約を取った。必要な返却物を準備して店舗へ行く。最初に電話の内容がエスカレーションされていないと思われることはあったが、その旨伝えると確認されたらしく全て滞りなく済んだ。電話に関してだけはNTT経由で連絡が来るとのことで両親が対応することにした。

先日それも済んだ旨が伝わってきたので全てことなきを得たと思う。

おしまいに

私は彼らのサービス自体がひどくまずいとは思っていません。ただし解約料金については別ですし、契約のやり方が顧客に寄り添っていないのはよろしくないと感じています。また、自身が応援していない企業のサービスを使うのは、結果的に加担していることと同じだと思っているので、今後も応援したくない会社のサービスは使わないようにしていきたいです。

極論応援されない会社はなくなった方が良いのです。自社がちゃんと顧客から(たとえ全ての方からではなくても)愛していただけるように頑張ろうと改めて思った次第です。