島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

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

「ITエンジニアは人手不足だから、スキルが無くても問題ない」の嘘

f:id:ms2sato:20180813095119j:plain

はじめに

これと、前に私の書いたエントリについてたブコメのこれ

「未経験から技術を学んで就職するには」で一つのアプローチを整理してみました - 島までは遠い

まず、みずほに潜り込みます / そもそも業界内で人がどの位不足してるかを調べて欲しいが、結構難しいんだよね。不足してるなら何とかなるし、余ってたら無理だし。

2018/08/08 13:55
b.hatena.ne.jp

拝見してたらなんとなく出力したくなったので書きます。先のツイートにRTされている内容も様々な意見があって興味深いです。

プログラマーの仕事、そんなに簡単に見えますか?

エンジニアやプログラマーは人手不足!スキルなくても全然大丈夫

これは、ありえませんから。補足します。

エンジニアやプログラマーは人手不足!(もしも、あなたが仕事の質や直近の成長を捨てる覚悟があるのなら)スキルなくても全然大丈夫

じゃないでしょうか。もしも「スキルなくても全然大丈夫」と言っている職場があるなら、それは「その程度の仕事しかお願いする予定はないし、それでペイする事業を営んでいる」ということで、おそらくあなたが想像するような「自力で問題解決をコードでしているカッコイイプログラマー」では無い筈ですよ。最初から「問題解決をコードでできる」ということを期待されていないということです。

自力で問題解決するにはスキルが必要なんですよ。「スキルなくても大丈夫」なわけがないです。簡単だと思わないでください。

もちろん何にでも例外はありますから、稀有な環境や経営者の下、そういうことができる場合ももちろんあると思います。例えばしっかりとした育成の文化を持っていて、先輩エンジニアが鍛えてくれたりするのであればそういう可能性もあるでしょう。

そんなのは本当にごくごく一部でしかないと思って欲しいです。私の周囲の会社でもゼロレベルから受け入れて伸ばしてくれるような会社なんて殆ど無いです。それができるなら、今プログラミングの学習を補佐する業界自体が成り立たないと思いませんか?(逆に言うとこれも異常ということは後述します)。

割り切り

世の中には様々な環境で仕事している方がいらっしゃると思うので、例えば以下のような考え方であえて「誰でも」となっているところに行く人はいると思います。こういう割り切り判断も時には必要でしょう(むしろそれが救済になっているとも考えます)。ただし、先を考えることは必要だと個人的には思います。

  • 現職の環境があまりにもひどく、退避場所としてでも良いので別の職場を求めている(第一目標が現職からの退避だから)
  • 他業種からIT系の業種への転向を考えているが、例えば年齢などでかなりの不利な環境を持っている為、肩書きだけでも移行し、別途スキルアップして別の職場を目指す為(あくまでステップの一つであり、現場で学ばせてくれないことは前提で考えているから)

おそらく多くの人はこういう事に当てはまらないのではないかと考えます。

どうしてこうなった?という推察

経済などの専門家ではないですが、私や私の周囲・クライアントなどを見ていて思うことを記してみます。

企業側の事情

例えばこういう意見が出ていました。とても真っ当です。私もそう思います。ですがそうやってある程度人を育てていこうという会社に対して現実に多く起こることは

「やっと育ってこれからだと思った頃に社員は別の会社へ出て行く」

なんですね。経営としては最初は完全に赤字だったと思いますし、これからはその人が別の新しい人を育てながら次のステップに入って欲しいと思っていたりするんです。でも、その前に出て行ってしまうことも多いらしい*1です。

個人の行動としては合理的であるし、その結果社会全体では給与が上がる傾向を作れるので良いとも思えます。とは言え最初に雇った会社からすると大問題なわけです。ある程度長い間一緒に歩んでくれるなら良いけれども、これから返していってもらえそうという段階でいなくなってしまうのであれば、経営としてはかなり辛い事になります。投資が回収できないんです。

そうなると会社が「『経験の足らない人を雇って育て上げる』という事に対して臆病になる」と推察できるのでは無いでしょうか。

過去の技術者の怠慢

これは私のようなロートル世代が引きずってきた問題なので、自分自身も当事者であるということも含めた上で記しますが、良くも悪くも「職人文化」「背中で覚えろ」のような考えが横行し続けていて、そもそも人を育てる文化が根付いていないと思います。少なくとも私が過去見てきた会社はそういう場所が大半でした。個人的には抵抗を試みたりしましたが、こういうことができたのはたまたまそれが通用する場所であった為だと思っています。

人を育てない文化は特に今始まったことでもなく、脈々と受け継がれていると言ってもいいような気がします。それではいけないのですけれども。

私の抵抗の話。 ms2sato.circlearound.co.jp

似たような事はこっちに頑張って書いています。

ms2sato.circlearound.co.jp

ブートキャンプやスクールという形式の流行り

というこれまでの流れを考えると、外部でなにか教育するという事が浮かび上がると思います。 海外では全部JavaScriptを用いて3ヶ月でムリクリプログラマーにして現場に送り込む、というようなブートキャンプ形式が一時流行ったのと、日本でそれに乗っかってスタートアップで似たようなことを「スクール」という名目で始めたのが流れでしょうか。

そして、海外でもこういう流れになっていました(2年前の記事)。

jp.techcrunch.com

多くのスクールが、100%近い卒業率と就職率を主張しているが、しかしその主張にはほとんど証拠がなく、スクールの経営実態も多くが開示されていない。

事実開示すべきだという話や、極小のケースを誇張する話が出ています。

スクールの多くが、ある一人の卒業生がY Combinatorに行ったとか、ほんの数名がGoogleに雇用されたとか、そんな一度限りの成果をマーケティングに利用している

今、日本は上記のような海外と同じような流れになっていると思います。おそらく様々なスクールはベンチマークし合った結果、誇大広告と情報商材的な売り方がもっとも売上が上がると考えたのでしょう。

お前のところはどうなんだよ

とりあえず私が誇大広告嫌いなので「xxヶ月で月給xx万円稼げる」とか出したこと無いですね。というか、そういう保証ができないスキルであり、そういう仕事だと私がよく知っているので、保証する事が胡散臭く思えるんです*2。三年半続けていますが、これまで完全初心者よりも少し経験がある人の引き合いの方が当初多かったのもあり、就活系はこれからでしょうか。

困ったのは以前よりもアフィリエイト記事っぽいのがGoogleの検索結果に上がってきて、元々マーケティング下手なうちは前にも増して目立たなくなったことですね。候補に全く挙げてもらえないっぽいです。あはは(笑い事じゃ無い)。

プログラミング トレーニング は流石に強いですが プログラミング 個別指導とかではどこ行った?って感じです。

おしまいに

本当の理想は「会社が組織の中で育てられるから、スキルがなくても問題ない」なんですけど、現実はそうなっていないんですよね。これって私は自分がやっている事業を否定しているわけですが、最終的には弊社がやっているプログラマーのトレーニングの意義が無くなる社会が真っ当だと思っています。

「育て方を、教える」も事業にしたかったりするのですが、それができるのは今の社員メンバーでは無かったりするので、経営としては単純に経営者の現場稼働を増やすだけになってしまう形は作りにくいんですよ。うちがもう少し大きくなって今のメンバーが育ったらできるのかもしれません。

*1:「らしい」と書いているのは、他人の会社の事なので「育ったから出て行く」というシンプルな理由と言い切れないからです。それは副次的な理由で「そもそも長く居続ける理由が無いような会社だった」なのかもしれません。

*2:面接などで聞かれた時に私の返答があまり歯切れが良く無いことを体験している人はいると思います。言い切るの難しいです

実力を示せるポートフォリオのWEBサービスのコードの作り方

f:id:ms2sato:20180809142937j:plain

はじめに

ms2sato.circlearound.co.jp

こんなのを先日書いたので、その続き的なエントリーです。

「『作ったものがある(最低条件)』とか言っても、何作れば良いんですか?」 的な話です。ゴールとして「出来上がった動くもののソースコードを技術者に見てもらう」切り口で書きます。 これはあくまで「私の場合」なので、異論ある人から「こういうところも見ているぞ!」みたいなツッコミとか超欲しいです。

どういうものを作れば実力が測れるのか

以下、私がRails中心に色々やっている(やらざるを得ない)為に、チョイチョイRailsぽい話になってしまったりしますが、お許しください。個人的には言語とかプラットフォームとかに関して中立な考え方です。

レベルで示していますが、数字が上がると難易度が上がるというよりも「下の方をちゃんとこなしていれば上の方も見ていく」ような感じになる気がします。

【レベル0】 とりあえず見る価値を作る

Scaffoldしただけでできるような「単純すぎるものではない」こと

色々と流派はあるかもしれませんが、単純なCRUD*1を作るのに、多くの人は作業を効率化させる為にScaffoldを利用すると思います。Railsならこれで何が起こるかとか、カスタマイズするのにどうしたら良いかある程度把握しているべきだと思います。

シンプルな掲示板を作ろうとしたりすると、ほぼScaffoldで終わってしまうようなケースがあり「あれ?これってあなたはどこをプログラミングしたの?」というようなことになりかねません。レビューする側も、コマンドいくつか叩いただけのコードでは判断できません。当然ですよね。

ちなみに、このレベルのコードでViewを綺麗に飾るだけしているケースはよくある気がします。もしもHTMLやCSSのスキルやデザインでアピールしたいなら、これもありかもしれません。ですがシステムを扱うプログラマーになりたいのであれば、これでは実力が測れないのです。

というわけで、コードのどこか(適切な場所はありますが、この後に示すようにその場所でなくても構わない場合があります)に頭を使うロジックを入れて置いてください。例えば「どこ頑張ったの?」と聞かれた時に「ここめっちゃ頑張りました!」と言えるようなのがあると良いです。

データベースを利用していること

稀に外部APIを呼び出すだけのものとかがありますが、これはDBの扱いやSQLの理解があるかどうかが見れないです。大抵のシステム開発ではMySQLやPostgreSQLなどのデータベースを扱ってシステムを作るので、この知識があるのかないのか見えないと、やりにくいです。

Scaffoldだと基本のコードがいきなり埋まってしまうので、それにプラスしている場所があると良いでしょう。例えば検索機能があって、入れた情報を絞り込んで出力できたり、LIKEの曖昧検索できたりするなどすると、少しは片鱗が見えます。

またテーブルのリレーションとして

  • 1対多
  • 多対多

などの基本的な情報のまとめかたの方法があります。これらは入れましょう。特に多対多は最初の頃よくわからないこともあるかと思いますが、何か作ればすぐに必要になることなので、やれる方が良いです。

RailsならActiveRecordを使ってアソシエーションを利用するようなコードになるはずで、こういうところのコードの扱いでも一定の実力を測ることができます。

ライブラリは利用しても良いが、骨格は自分でコードを書いていること

OSSで出ているRailsのサービスに何個か機能追加したようなものですと、そのOSSの扱い方を理解しただけなのか、Railsについての理解があるのかがわからず、現場に入りやすいかの判断がしにくい場合があります。あくまでサービスをゼロから作れるかどうかを見たいというような目的感があるので、できればrails new からスタートして作っていて欲しいです。

【レベル1】力技でもやりたい処理を自分で考えて書いているか

「美しいコードでなければ見せる価値はない」と思ってしまう人がいるかもしれませんが、それは誤りです。美しさというのは後で磨くこともできることなので、最低限で考えると美しいかどうかではありません。

大事なのは「考えてコードを書いているのか」とか「困った時に工夫できる機転がきくのか」というようなことです。

なので私の場合「全然勉強の余地はあるけれど、めちゃくちゃ考えたんだろうな」という事が伝わる際には一定の評価をします。ただし「どう考えてそうなったのか」については結構聞き込むはずです。ポイントとしては以下かな?と考えています。

  • 少なくともどこかのコピペコードの筈がない(コピペだとそれっぽいコードが多くなるので「メチャメチャ頑張って工夫」になりにくい)。
  • そのコードについて質問した時に「どう考えたのか」が論理的であるかどうか。

例えばですが「MVCとかよくわかってないです」と言って見せてくれた方のコードでViewにロジックべったりだったことがあります。ただ、聞いてみると彼はシッカリと考えていて、単純にロジックの適切な置き場所がよくわかっていないのだとわかりました。こういうケースは評価できると思います*2

【レベル2】作法に従っているか

レベル1を超えているということは、とりあえず動作を実現した動くコードがあるということになります。ただ、それだとよくありますし「家で独学修行を一年続けました」とかでも到達できる可能性は高いです(私も経験していて、とても価値があることですが自分のやり方に染まり過ぎているかもしれません)。

例えば以下のようなところとかでしょうか。

  • MVCに従うことを知っている。ロジックをモデルへ集めている。
  • アソシエーションを適切に使っている
  • enumやscopeを理解して利用している
  • routesをresources中心で書けている、アクションの追加などもこの作法の中でやっている(collection、member)
  • バリデーションでの失敗の処理がおざなりになっていないか(とりあえず動かそうとすると放置しがち)
  • (もう少し後でもいいか?)N+1 問題への対応

【レベル2】よく使われる外部ライブラリを使っているか

ちょっと調べると出てくるような外部ライブラリを利用できていると、よく調べていることは伝わります。Railsだとこの辺でしょうか。

  • Devise(嫌がる人もいますが、導入されているプロジェクトは多いので知っておく方がいいと思っています)
  • Carrierwave(もう使われなくなるかも)
  • Kaminari

【レベル2】自動テストを書いているか

まず、書く意志があって試みてて欲しいのはあります。RailsではRspecがほとんど使われている様子なので、Rspecで書いてください。

  • モデル
  • コントローラー or リクエスト

くらいで書いてみてて欲しい。最低モデルについて書いていてくれるとありがたい(その為にもモデルにロジックが乗る設計になっていないと難しいですが)。 「素晴らしいテスト」という考え方だと色々と難しくなってしまうと思うので、最初のうちは「意味があると思うものを書きました」くらいでも良いかも。

【レベル3】よくある仕様・画面に対応できているか

現場に入ると最初の頃ちょっと戸惑う「あるある」な仕様があります。これに適切に対応できているかですね。例えば以下のような構成の画面とか。

  • 本の紹介と他人からのレビューコメントが並ぶ画面が適切に作れているか
    • バリデーションしなければどうにかやっていることはあっても、そのあたり含めると怪しくなってくる人は結構いるようです。
  • 本の紹介のために複数の書籍のサムネイルを一つの編集画面で一緒に更新させる。サムネイルの最大数を増やすのはDBの変更をしなくてもできる。
    • これもバリデーション含めると、エラーになると入れたサムネイルが無くなったりしてしまうなどあるので、そのあたりのケア。

この項目は「一度ぶち当たって痛い目を見ると覚える」ような部分でもあるのでプラスアルファだと考えることもありますが、こういうのをシッカリ対応できているなら安心だなとも思います。成長を含めて評価するか、今のその人のできることで評価するかの違いです。

【レベル3】バッチ処理が入っている

普通に教本などをやっていてもあまり出てこないのですが、実際の開発では rails runner や Rakeタスク を使ったcron呼び出しのバッチ処理などが発生することが多いです。また、稼働中のサービスに対してDBの情報を更新かけたりもしたりするので、こういったコマンドでサービスに外から働きかける経験があると、本格的な内容理解がありそうだなと感じたりします。

ロジックの入りやすい仕様について

おそらく「ロジック入るようなのはどういうものか?」という疑問が沸いている人がいそうなので、ちょっと書いておきます。

  • ユーザーが複数の種類いて、それぞれ別の権限を持っている(管理者・コンテンツ作成者・見るだけの人など)
    • 権限判断をすべきところが出てくるので、そこで考えて分岐する必要性などが出てきます。よく実開発で必要になる考え方です。
  • 何かの集計を行なっている
    • 例えば「いいね数」のような概念があって、いいね数の数で検索結果を出したりするなど。複合的に検索できると尚良い。
  • 条件付きで見えるような画面がある
    • 例えば他で設定されたユーザーごとのパスワードを入れて、同じパスワードを入れたら見ることができる、など

今だとクラウドファンディングのサービス作ろうとしたりすると、いい感じに色々な仕様が乗ってきそうな気がしますね。ただ、実力がそこに伴っていないと意味がないので、そうでなければ無理くり目指さずにブログサービスを作るとか、掲示板でもちょっと変わったものを目指すとかでも良いのではないでしょうか。

おしまいに

これってつまり「私が実力を評価する場にいた時に見ること、あると嬉しい情報」なんです。私を攻めるならこういう感じで勝利確率が上がります(笑)

普段WEBプログラミング個別トレーニングの面談でもこうやって今の実力を測らせてもらいますし、弊社の受託で一緒に仕事をするメンバーを見る場合も大抵コード見ながら話をさせてもらいます。 circlearound.co.jp

こうやって結局自社の話に繋げるのは仕様です。もし興味わいたら、明日(8月11日)、25日にトレーニングの説明会やるので来てください。

techdrive.connpass.com techdrive.connpass.com

*1:Create, Read, Update, Delete

*2:もちろん適切なところに書けばもっと評価します

「未経験からプログラミングを学んで就職するには」で一つのアプローチを整理してみました

f:id:ms2sato:20180807185426j:plain

はじめに

以前に比べて「職の為に技術を学ぶ」という方が増えたのか、弊社のWEBプログラミング個別トレーニングWEBサービスチーム開発トレーニング でもそういう要望のお問い合わせが増えてきています。私もそれに応えるべく日夜奮闘しているわけですが、そもそもどういう形で学んでいくと良いステップなのかを一度考えてみようと思いました。

正攻法

ゴールを考える

最終的にどういう状態になれればゴールたる就職に辿り着けるのでしょうか。 例えば巷でよく言われるのは「業務経験一年以上」などのような期間で区切られることであると思います。ただ、この切り口はたまごニワトリの話になってしまいますね。最初の業務経験を得たいのに、その条件が業務経験を積むことであるという命題はまともには解けないでしょう。

この「業務経験一年」を分解したいと思います。「どうしても一年で無ければならないはずはない」と多くの人は気づいている筈です。例えば以下のようないくつかの要素に分解できると思います。一年も業務ができていれば、これらが大抵備わっているだろうと予見できるために、一年という期間が使われるのでしょう。

  • ある程度作れる事を相手に証明できる。
  • 作れるだけではなくて、作るチームとマッチしたコミュニケーションが取れる はず
  • 最初から手間が膨大にかかるわけでは無い はず(実はこれが大きい会社も多いかも?)

逆に考えると「こういう要素が備わっている」と認めさせる道具が必要であるということですね。

自分の情報が見える化されていること

ゴールを分解したので、それぞれからもう少し自分の行動レベルに落としてみたいです。例えば以下のような感じでしょうか。

  • 作ったものがある(最低条件)
    • 少なくとも作った経験をアピールできる。
    • チュートリアルなど「どこかにあるものを写したものでは無い」ことが推察できること。
    • 作ったものについて、語れること。
      • コピペコピペで作ったりすると語れない。
  • 成長の過程が示されている
    • ブログなりでも良いし、Qiitaなりでもなんでも良いが、アウトプットされていて、日々の悩みや作る上で考えたことが示されている。
    • どういう課題をどのように越えてきたのかが辿れる。
    • GitHubなどのコードが存在し、日々コミットを積み重ねていることがわかる。
  • チーム活動の経験を示せる(稀有)
    • どこかの何かのチームでの活動を示せる。
      • 可能ならGitHub上でのIssueやPR、コミュニケーションが見えると良い。
    • 経験者がいて統制しているなど、チームの作法がしっかりしているとより良い。
      • 「ただ集まっています」という形はチームではないので。 GitHub-Flowで進めているなど。
    • お金が発生しているなら尚良い。

何かオリジナルで作ったものを持っていれば、その人が現在どれくらいの能力か推し量る為の道具になります。それも無しに「雇ってください」だけを押しても、別のプラスアルファがない限りは望みが薄いでしょう。

この時技術だけ見てもらいたいなら何かのサービスの真似のようなものでも構わないと思います(仕様を真似て作成するという意味)。逆に自分がサービスについて考える頭を持っているとか、ローンチして継続ユーザを獲得したサービスがあったりして、その意味でも評価して欲しいなら特異な自分なりのサービスもありでしょう。

チームに参加したのなら、PRやIssueで行なっているコミュニケーションを見てもらうと良いと思います。適切な質問ができるかとか、どういう細やかさで仕事に対応してくれるかが見せられるはずです。

どんなもの作ったら良いのか、的な話はこの辺に書きました。参考にしてください。 ms2sato.circlearound.co.jp

紹介してくれる人がいる

ある程度の信頼を獲得している人からの紹介は物事をスムーズに進める原動力です。この場合であれば、就職したい先の企業とある程度の関係性を築けている第三者の手助けを借りるのは有利な考え方だと思います。

ただし、紹介してくれる間の人があなたのことを第一に考える人かどうかは、吟味の余地があります。例えば有料職業紹介で繋がっているような場合には、会社のKPIとして「何名会社に送り込むことができたのか」という条件が課されている場合があり(企業活動なら当然あると思います)、その数字を稼ぐために利用されるケースがあります。つまり、紹介された先があなたにとってマッチする会社であるかがわからない可能性があります。

とは言え世の中自分の有利だけを考える人ばかりでは無いのと、この後の割り切りの話も含めてバランスになるだろうとは思います。

あなたの希望を優先して考えてくれているかどうかは一つの切り口です。そもそもの実力が届いていない場合には、紹介者もレベルの高い会社を紹介できない場合があり、希望のランクを下げざるを得ないケースはあるでしょう。

紹介者に出会うには?

この点も気になるポイントかもしれません。

  • イベントなどの場所で出会う(勉強会の懇親会とかどうでしょう)
  • Twitterやオンラインのコミュニティ(の人も最近はいそうなので)
  • 転職エージェントなどを頼む
  • 技術を学んだ場所で行なっている紹介を頼む

個人的にはイベントなどでオフラインの繋がりができていると強いなぁと思います。勉強会自体に尻込みする人もいてしまう様子ですが、少し人数多めのセミナー型の勉強会なら基本的には大人しく座って入れば他人に迷惑をかけることはありません。懇親会では会話する必要が出てくるとは思うのですが、まだ始めたばかりだということを言ったとして酷い扱いをされることはそうそうないと思います。

割り切る必要性

  • 「あなたにマッチする会社は世界のどこかにはあるかもしれない」
  • 「あなたがそれを見つけられるとは限らない」
  • 「見つけられないなら無いのと同じ」

イメージとして賃貸の物件探しと似ていると思います。あっちを立てればこっちは立たずのはずで、全てがパーフェクトにはなかなかできない。「要望が増えれば、可能性は減る」ということかと。例えば下記のようなことでしょうか。何を求めるかを絞った方が良いと思います。

  • 給与が高いか
  • 丁寧なフォローがあるか
  • 腕のいい先輩エンジニアに師事できるか
  • 残業が少ないか
  • 福利厚生が充実しているか
  • リモートワークできるか

オプション

これまでは自分の技術をなるべく認めてもらう切り口で考えていたのですが、それとは違うものだったり、上記を踏まえた上でプラスアルファになりそうなことを少し考えてみました。

前職などの経験値を持って入社はするが「将来技術職になる」ということを明言し、それを会社に配慮してもらう。

会社としては、他のことで貢献してもらえるのであれば、雇いやすくなるはずです。なので、最初は前職の能力などを考慮してもらい、徐々に技術職に近づく方法。 「これが口約束にならないか」とか「実際に転向できるのが何年後なのか」とか不確定な要素はあります。

社長など権力のある人に気に入られて、ルートを手に入れる。

誰かしら社内で気に入ってくれている人がいればやりやすいですし、最高権力者が買ってくれるなら相当やりやすいでしょう。ただ、こういう方法はやれる人を選びますし、周囲からの反感など、ちょっぴり心配なところもありますね。

[PR] 弊社の場合

WEBプログラミング個別トレーニング からの WEBサービスチーム開発トレーニング という最近多い流れだと、個別トレーニングで自分のサービスを何か作り、チーム開発に参加してチームでの経験を積む、みたいな流れになりますね。 多くはありませんが私から知っている会社さんを紹介して*1、チーム開発のリポジトリを見てもらったりもしますよ。 そうやってなるべくお互いのミスマッチが減らせると良いなと思います。

今後、もっとミスマッチを減らせる方法も追加していく予定です*2。その為には引き続き色々とやっていく必要がありそうです。

*1:募集中です!

*2:試しにやっていることはチョイチョイありますが、正式にコミットするまでなかなか至っていないことがあったりします

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

はじめに

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!。

後日談

公開後の話などこちらに書いたので参考にしてください。

ms2sato.circlearound.co.jp

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

はじめに

startup-technology.connpass.com

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

資料は下記です。 speakerdeck.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:ms2sato:20180304003900j:plain