技術にゃんこの混ぜご飯

関東某所でエンジニア・プログラマ生活を送るブログ主がチラ裏メモを放り込む場所

Progateの全レッスン制覇してみた(2018/09/15)

やりきった感_(:3」∠)_

まとまった時間が取れそうだったので、Progateの有料会員に登録して、一通りのレッスンをこなしてみました。無料で学習できる範囲はあくまでお試し程度なので、本腰を入れて取り組むなら月額 ¥980(税込)の有料会員登録が必要です。

全レッスンが終了した段階で Lv. 364 でした。プロフィール画面のレーダーチャートが綺麗です。無料会員の頃から何度か使っているので、リセットしてやり直した分も含まれているかもです。

まとめ

  • 良いと思った点
    • 超初心者がプログラミングへの触りとして使うのに最適。
    • 新しい言語を使う前に、細かい文法の違いを把握するのにもいい。
    • 実際に手を動かすので『ドキュメントを読んだだけで書けない』を防げる。
    • おすすめは『Ruby on Rails5』、実装時の順番がしっかりしている。
  • 気を付けないといけない点
    • 言語によって内容にムラがある。

詳細

学習だけに集中できる

動く環境で実際に手を動かしながら学ぶので、余計な環境構築に気を取られたり、ありがちな抜け漏れで時間を食う心配がありません。

経験者の方はよくよくご存知と思いますが、動く環境を作るのは結構大変です。cloud9なりDockerなり使えば割と簡単に作れますが、仮想環境の構築ノウハウも必要ですし、何か問題が起きた時に自分で解決できる力が必要です。

例えばRubyだとgemのインストールに失敗した場合、基本は英語のエラーメッセージで検索をかけて原因を探さなければいけません。nokogiri や mysql2 なんかは割りと有名ですね。

慣れれば大したことはありませんが、初心者がこれを解決するのは難しいと思います。なのでこの問題がなくなるだけでも、プログラミングに対するハードルはぐっと下がります。

スライドが丁寧で見やすい

にんじゃわんことひつじ仙人が会話形式で学習を進めていくので分かりやすいです。画像が多いので、まだドキュメントに免疫がない方も大丈夫です。

またスライドは『プログラムの固まりを色分けした枠で囲う』『変数内の値を具体的に書いて視覚化する』等が行われており、コードの捉え方が自然と身に付きます。

スライド検索の機能もあり、要点がまとまっているので、軽い逆引きにも使えますね。

Progateの紹介について | プログラミングの入門なら基礎から学べるProgate[プロゲート]

言語毎にムラがある

これから追加が予定されているレッスンも含め、まだまだ発展途上といった感じです。GitやGo言語はこれからレッスン追加されていくものと思われます。ちなみにGitⅠだけだと最低限のGitの使い方までで、branchやmergeなどにはまだ触れられていません。

また『Ruby on Rails5』『JavaScript』はバージョンが分かれていますが、『HTML&CSS』『PHP』ではバージョンが曖昧になっています。

フレームワークだとバージョンが1つずれるだけで記述方法がガラッと変わることもザラです。言語ではバージョンが上がって新しい書き方ができるようになると、既存の書き方もそれに合わせて変わっていきます。HTML5・CSS3はブラウザが対応していなければ動きません。

自分が今どのバージョンの書き方を学んでいるかは常に意識しておかないといけないポイントです。

追加の順番か、中の人の習熟度かは分かりませんが、レッスン内容にはムラがあります。あらかじめ分かった上でそういうものとして取り組んでいれば良いのですが、変に勘違いをしたまま進めてしまうと、後々つまずいてしまわないか少し心配です。

活用方法

用途としては以下になりそうです。

プログラミングを全くしたことがない人におすすめする

情報系以外の学科から入社してきた新入社員の方、分野外の開発者がプロジェクトに参加する時などに、高い威力を発揮すると思います。

全く触ったことのない言語に触れる前に、基本的な文法をチェックする

『+=』『%=』などの演算子はほぼ共通なのに、NULL値や配列になると言語によって方言並のバラバラ感があります。

これをしっかり確認するには良い学習サイトだと思います。

【連載】自己実現の欲求 - マズローの自己実現理論をITエンジニアで考える

はじめに

自己実現の欲求とはアイデンティティが確立した後、自分ならではのことをしたいという欲求です。ここでは『エンジニアとして自分のやりたいことをやっていたい欲求』と定義します。

あえて賛否両論となる例を書いていきます。上記のWikipediaの『誤解』に書かれている点に触れるためです。

自己実現を達成するということは自己を確立し、達成するということです。自己を確立するということは今まで不定形だったものを決まった形にするということです。その形が今いるコミュニティの型にはまらなければ、自己実現を達成したい人はコミュニティを去る可能性があります。

つまり自己実現を達成した者=自己実現者は、自己実現にとって不利益となる既存の人間関係や習慣に対して反発します。これは決して悪いことではないのですが、社会的にそれが受け入れられるかは環境によるのではないでしょうか。

自己の適正範囲とその拡張

  • 失敗例
    あるところにRubyが好きで好きでたまらないエンジニアがいた。彼はある企業に所属していたが、そこは他の言語の案件も扱っていた。彼はRuby以外の案件となると途端にサボり始め、適当にしか仕事をしなくなる。バグが多くなるといった実害はないが、見ていて気持ちの良いものではない。
  • 成功例
    あるところにRubyが好きで好きでたまらないエンジニアがいた。彼はある企業に所属していたが、とうとう我慢し切れなくなりフリーランスになった。彼は日々、Rubyの案件を捌いている。その出来は非常に良いため、業界ではちょっとした有名人だ。

Rubyのところは適当に置き換えて下さい。

失敗例ですが、もし会社に積極的にRubyでの自社開発を進める余裕があるか、積極的な営業をして案件を確保するかすれば、お互いに利益のある関係を築けた可能性はあります。

成功例ですが、もし彼がRubyが大好きなだけで実力が伴わないITエンジニアだったら、このように上手く話が運ぶことはなかったでしょう。 ITエンジニアにおける自己実現者は自分が認めた以外のことをしたがりません。

それは例のようなプログラミング言語かもしれませんし、最先端のIT技術かもしれませんし、ゲーム作りかもしれません。人それぞれです。

問題があるとすれば現在勤めている会社が、自己実現の達成を目指すITエンジニアに対して適した仕事を供給できるかです。

最先端のIT技術であればまだ何とかなりますが、ある言語や限られたプラットフォームだけに適正を見出してしまうと大変です。

ITエンジニアはまだ自己が形成される前に、より広い視野で物事を捉え、できる限り多く適正を持てるようにした方が生きやすいのではないでしょうか。まだ間に合う方は積極的に適正範囲を広げられるよう、様々な技術や仕事に触れてみてはいかがでしょうか。

もちろん広く浅くなることはデメリットになってしまいますから、上手く折り合いは付けた方がいいと思います。

自己実現と組織

ある組織に所属し秩序に従うことと、自分の好きなエンジニア生活を送ることとが、利害が一致しない場合に衝突するのは先述の通りです。

この欲求はある企業に所属し続ける以上、どうしても頭打ちになる欲求です。自分のやりたい案件が、都合よく会社に降ってくるなんてことはまずありません。やりたいこと以外もやらなければいけない時だってあります。

仕事を選べる身分にでもならない限り、組織の中ではどうしたってただのワガママです。それが我慢ならないのなら、フリーランスか社長にでもならないと厳しいのではないでしょうか。

自己超越の欲求

一般的に倫理の時間にはマズロー自己実現理論は5段階までと教えられますが、マズローはその上に『自己超越』という段階を付け足しています。

解説を読んだんですが、これはもう聖人か聖母かという人格者の域ですよね。前述の自己実現者が社会適合能力を身に付けたのか、適正のままに生きれる場所を見つけたのかは分かりませんが、残念ながら私には理解を超える概念でした。

自己超越の域に達したITエンジニアをお目にかかったことがないというのも理由の一つです。マズローは人口の2%程と考えていたようですが(仮に2%だとしても)、ITエンジニアでこれを実現できる人は果たして何人に1人なんでしょうか。

もし実在するのであれば一度、お会いしてみたいものです。もし会えたと思ったら記事を追加・更新すると思います。

おわりに

あなたは今のコミュニティで自己実現が達成できそうですか?

できそうにないとしたら順応しますか? それとも他のコミュニティを探す旅に出ますか?

【連載】承認(尊重)の欲求 - マズローの自己実現理論をITエンジニアで考える

はじめに

承認(尊重)の欲求とは自分や周りから評価されたいという欲求です。ここでは『○○ができるITエンジニアとして、所属している組織内で一目置かれている』と定義します。

この欲求には『低いレベルの尊重欲求』と『高いレベルの尊重欲求』の2種類があります。人間からITエンジニアになっても、やはり当てはまります。

肩書を持つという意味

  • 失敗例
    彼は他に適任がいないからという理由で、プロジェクトのリーダーに昇格した。彼は不服だったため、最低限の仕事だけをこなしていた。役職として権限が強く、給料も上がったが、彼を尊敬し、ついて行こうとする者は少ない。
  • 成功例
    社内で特定の技術に敏い人が認知されており、不明点がある時に聞く窓口が存在する。
    『インフラなら○○さんに聞けばいいよ』
    Railsなら□□さん、Laravelなら△△さんだね』
    本人達もそれを嫌がっていない。

名前だけ付いていても意味がありません。形から入るのは結構ですが、技術や内容が伴わなければ名前は意味を成しません。一時的には注目されるかもしれませんが、そのまま何もしないでいると、やはり肩書に取り残されてしまいます。

社会的欲求では居場所さえあれば満足できたのに対し、承認(尊重)の欲求は居場所の中でも特に価値があると認められて初めて満足できるものです。

特にインフラ系など縁の下の力持ちの方々には、正当な評価がされるような世の中になって欲しいですね。口だけでなく給与面や待遇など、行動で示すことも必要なのではないでしょうか。

資格を取得する意味

  • 失敗例
    IT業界に就職した彼は年内に資格を三つ取得するという目標を掲げた。仕事が忙しい時期もあったが、要領が良かったため何とか合格点を取ることができた。
    彼が資格を取得したと聞いて同僚は早速質問をしに行ったが、彼は試験で出てきた問題以外に答えることができなかった。
  • 成功例
    数年、IT業界に勤め実力を試したくなった彼は資格試験を受けることにした。テキストの内容は業務で培ったことも多く、彼は不足している知識を業務を通して補っていった。
    彼は資格試験に合格した。また資格に見合う能力と技術を磨くことができた。

ITエンジニアが資格を取得する意味は何でしょうか。

様々な理由が上げられますが、一つは就職活動などで客観的な指標として利用するため。そしてもうひとつは資格勉強を通して、能力や技術を身につけるためと思います。

資格は試験時に一定の知識レベルがあったことを証明してくれます。沢山の資格で履歴書を埋め尽くせるなら、これほど心強いことはないでしょう。ですがそれだけでは『低いレベルの尊重欲求』が満たされるだけです。

本当に実になる技術が身に付けられ、自分で自分自身の評価を高められれば、『高いレベルの尊重欲求』を満たすことができます。

おわりに

『○○なら任せろ!』と自信を持って言えることがありますか?

資格取得自体が目標になっていませんか? 数年前に取った資格の内容を覚えていますか?

【読んでみた】ゲームクリエイターが知るべき97のこと 2

顔文字使い回しじゃないょヾ(・ε・。)

ゲームクリエイターが知るべき97のこと』について

ゲームクリエイターが知るべき97のこと』は既読です。記事は以下です。

『他の類似サイト・書籍との違い』にも触れているので、興味のある方はこちらを先にお読み下さい。

今回、このサイト・書籍を読んで新たに気が付いた点として、ITエンジニアの方々が現状の問題を解決することに重きをおいているのに対し、ゲームクリエイターの方々は問題を提示しつつ次世代のゲームクリエイターを排出することにも目を向けている傾向がありました。これは大きな違いだと思います。

あとは海外に目を向けている点です。日本のIT業界は社内の他部署や他社との交流が絶たれていることが多く、技術的な面でも残念ながら海外より遅れていると言われています。

そこに執筆時点で既に気が付き、全体で対策を始めていたという点では、ゲーム業界の方が行動が早いですね。

雑感

など、ゲーム業界だけでなく他の業界のプログラマにも有用な記事もあります。

シリアスゲーム』という単語自体は知っていましたが、ゲームを作っている方々のエッセイを読むと、具体的に問題や課題が浮き彫りになっていて、非常に興味深かったです。

この本が出たのは2013年ですから、既に5年前ですね。現在は果たしてどのようになっているのか。

読んだ理由

単にフリーランスになって仕事を受けるだけであれば、ゲームクリエイターが知るべき云々は必要ないかもしれません。

しかし『ゲームクリエイターで有ると同時にITエンジニアでもあるという点を考えれば、このサイト・書籍からも学び取れる教訓は多のではないか』と考えたのが読んだ理由です。

更に私は制作物としてAndroidアプリを考えています。ゲームになるか便利ツールになるかは分かりませんが、これらを制作する上で有用な意見が書かれているのではないかと踏んだのも、このサイト・書籍を読んだ理由でした。

結果としてこのサイト・書籍を読んだ時間は有意義なものになりました。ここに書かれていることを知っているのといないのとでは、成果物にも大きな違いが出てくるのではないかと思われます。

未完成

一度、何かを作ろうと思ったことがある人ならば、完成させることがどれだけ立派か分かりますよね。

ゲームだったら最初の方だけ作って飽きたとか、絵だったら下書きまでで自信を失くしたとか、小説だったら途中まで書いたまま放置とか、動画だったら失踪してしまったとか。

いくつかのエッセイで触れられていますが、何かを『続ける』『完成させる』というのは、それだけで才能かもしれません。

【連載】社会的欲求 / 所属と愛の欲求 - マズローの自己実現理論をITエンジニアで考える

はじめに

社会的欲求 / 所属と愛の欲求は社会的欲求とも呼ばれます。ITエンジニアとして仕事をしている以上、すでに何らかの組織には所属している筈です。

ここでは『ITエンジニアが所属している組織の中で、自分の居場所を得たいという欲求』『ITエンジニアとして信頼に値する理解者を得たいという欲求』と定義します。

ITエンジニアの居場所はどこにあるのでしょうか。またITエンジニアの理解者は誰でしょうか。

役に立てない優れた技術

  • 失敗例
    彼の趣味はプログラミングであった。彼は様々な先進的な技術やテクニックを身に付けたが、会社で求められているのは古臭いレガシーな開発手法だった。
    企画書はことごとく却下され、居場所をなくした彼は会社を去っていった。
  • 成功例
    やる気のある新人が開発環境改善の企画書を作成した。やや稚拙な部分があるものの、アイデアとしては間違っていなかった。先輩は新人の着眼点を褒めた。
    メンバーは協力して推敲や実験的運用を行った。結果、手直し後の企画書は無事受理され、開発はより効率的に進められるようになった。

誰かが何かに気が付き、提案したとき、『良いものは良い、悪いものは悪い』と言える土壌は形成されているでしょうか。

役に立てないと悟った社員は居場所をなくしてしまいます。逆に役に立てると分かった社員は「私はここに居てもいいんだ」と自信を持てるようになります。

身に付けた技術が通用しないなら、努力して向上させていけばいいです。しかし不可抗力で宝の持ち腐れ状態が長く続くと、実力が発揮できずフラストレーションが溜まってしまいます。

『まずやってみる』ためにはそのための土壌が必要です。表面上取り組んでいるつもりでも、あれこれ理由を付けて実践しない、本質を理解できていないケースも多いです。

できれば成功例のような『こうしたらいい、ああしたらいい』が直ぐに理解され、受け入れられるような環境を作っていきたいですね。

尊敬できる先輩とは

  • 失敗例
    とあるコードが客先のITエンジニアから絶賛された。そのコードの価値を理解していたのは、書いた本人とその客先のITエンジニアだけであった。
    会社はプロジェクトの成功を褒め称えたが、彼本人にその評価が伝えられることも還元されることもなかった。
  • 成功例
    彼の現場には尊敬できる先輩がいた。彼は先輩にコードレビューを依頼した。
    駄目出しもされたが、何より彼が嬉しかったのは、苦労して書いた会心のコードを褒めてもらえたことである。それだけで彼はまた良いコードを書こうと思えた。

『断琴の交わり』の成り立ちを知っていますか? 書いたコードを理解してくれる誰かがいるというのは、とても幸せなことです。仕事上、友情というのは一長一短があるので、ここではあくまで『理解者』としておきましょうか。

誰かの書いたコードを理解するには、書いた本人以上に優れた技術力が求められます。また書いた本人の現在のコーディング能力やスケジュールなどの状況も考慮に入れる必要があります。

例えばスケジュールが押していて仕方なく突貫工事したコードをレビューに出すとします。この時、『納期が○○日で時間がありません』と一言添えておけば、レビューを依頼された側もレビューした人の状況を把握することができます。

コードレビューをするということは、レビューを依頼した人のことを理解するということでもあります。技術力と理解力を磨いて『尊敬できる・目標にできる先輩』になりたいものです。

上司と部下のすれちがい

ITエンジニアには『私のこの技術・長所が認められていて、ここで一緒に仕事をしていてもいいんだ』という自分を許す感覚が必要です。フリーランスであれば『私はこの業界でやっていける』という自信のようなものでしょうか。

これらは客観で測れません。あくまで自身の居場所と認識するのは本人です。なので本人が自覚しないと意味がないです。

例えば上司と部下が互いにすれ違っているケースはあるあるです。上司は『あいつにしかできない案件もある。いなくなられたら困る』 と思っていても、部下が『こんなの誰にでもできる。私はどうでもいい人材なんだ』と思ってしまっていたら悲しいです。

部下はどうして誰にでもできると思ってしまったのでしょうか。上司は何を伝えれば良いのでしょうか。

いくつかの記事を見る限り、この点を見落としがちなのではないかと考えています。というより聞いたときには、時すでに遅しというパターンが多いのかもしれません。

おわりに

自分の社内(業界内)でのITエンジニアとしての居場所を考えてみましょう。

  • 自分が役に立てていることは何か。
  • 誰かを褒めたことはあるか、誰かに褒められたことはあるか。
  • 自分にとってのITエンジニアとしての『理解者』は誰か。

就活中または組織に属していない方は、孤独や不安を感じている最中かもしれません。しかし焦らず慎重に、自分に合う会社を見つけて下さい。