【新企画】kikou ~エンジニアになるための悩みなら、エンジニアに聞こう~ vol.1
※本記事は、7300文字以上のの超大作になります。ご自身の気になる質問&回答を優先的に読むことをおすすめします
企画紹介
プログラミング学習者さんの日々モヤモヤしている悩みを、現役エンジニアの方がこれまでのキャリアのご経験を元に回答いただく、新企画です。
そんな第一回は、学習方法や選考のお話、他にも開発現場のお話やひいては中長期的なキャリアのことまで、かなり学びの多いご回答をいただきました。
ぜひ一つでもご回答をみていただき何か学びになれたら嬉しいです。
回答者紹介
Mr.T さん
Web系自社開発企業にてフリーランスエンジニアとして働いています。メインはRubyで、実務経験はPHP、Ruby、Javaなど。次世代のエンジニアさんのために、何かできればと思っています。プログラミング講師の経験あり。社内の若手エンジニアの育成経験あり。Twitterアカウント：@mr_t_free
▼Mr.T さんの執筆教材
nunulk さん
フリーランスのウェブアプリケーションエンジニアとして、近年は主にスタートアップ企業にて、サーバサイド（PHP）およびフロントエンド（JavaScript, TypeScript）のプロダクト開発をしています。開発以外にも、技術選定、設計、スクラム開発導入、テスト環境の整備など、チームにとって最適な開発プロセスを回せるよう、様々な側面からサポートする仕事をしています。 Twitterアカウント：@nunulk
▼nunulk さんの執筆教材
蝦名一真 さん
Quipper/リクルートでスタディサプリ ENGLISH の web 版および学校向け製品の開発に従事しています。前職では、JSP が標準だった web 開発現場に React を導入し、アーキテクトを担当したほかメンバー教育を実施しました。
▼蝦名一真 さんの執筆教材
※50音順(アルファベット先)
Question 1
1. 私はまだ基礎構文を学び終えた段階で、エンジニアになれるイメージが全く湧きません。このレベルで、どんな感じだったらエンジニアの適性がある、もしくは学習が順調と判断ができるでしょうか？
基礎構文を学んだ段階では、まだその構文をつかってどうやったらシステムが出来上がるのかイメージが難しいかと思います。
まずは、なにかアプリケーションを作ってみることが大事です。作っていくうちに少しずつ自信がついていくと思います。
もし、自分の中でなにか作ってみたいアプリケーションがあったら、それをつくるのが一番興味を持って進められると思います。作るための方法をあれこれ調べていくうちに実力が自然とついてきます。
プログラミングを仕事に繋げたいというのであれば、クラウドソーシングサイトのシステム開発の案件を眺めてみて、世の中どういうプログラムにニーズがあるのかわかります。世の中のニーズの中に自分も作ってみたいシステムが見つかればぜひ作ってみましょう。
こうやってドンドンアプリを作っていることが楽しくて飽きないのであれば間違いなくエンジニアの適正があります！
適性に関しては、2つあると思っていまして、1つは楽しめること、もう1つは仕組みに興味を持てること、です。何年やっていても、分からないことや出来ないことがなくなることはありませんので、そうした状況においても、なぜ上手くいかないのか、どうすれば上手くいくか、といったことを、プログラムの内部に興味を持ちながら楽しめるようになるといいんじゃないかと思います。学習の進み具合に関しては、あまり長いスパンで考えずに、毎日（毎週でもいいでしょう）1つでもいいので、分かるようになったこと、出来るようになったことがあったかどうか、確認していくといいと思います。調べながらでないと書けなかったことが、調べなくても書けるようになった、どう書けばいいかなかなか思いつかなかったことが、パッと実装方法が浮かぶようになった、といったことの積み重ねが大事かと思います。
判断できない、が正直な答えと思います。イメージが湧かないのも当然なので大丈夫です。
なぜこの段階で適正が気になったのか、ご自身に問うてみるといいと思います。おそらく、さらに学習コストを払って身にならなかったら「損」だと考えたのではないでしょうか。では「損」とはなんでしょう。もう禅問答になっていますね。でもそうやって考えていくうち、納得のいく答えに肉薄できると思います。探求してみてください。
ちなみに私は、今まで一番継続できていることが「エンジニアとして働くこと」なので、適正があったと、今となっては言えます。途中では判断できなかったと思います。学習コストを払ったのに身にならなかったのは、有機化学系の研究ですかね。丸3年どこかに消えたし良い思い出でもなかったですが、それでも私の大切な歴史ではあるので、「損」ではないですね。
Question2
2. 学習教材を何周も復習していると学習方法を批判されます。しかし、一回で全てを理解することは難しいと思います。適切な反復とはどういったものでしょうか？
基礎的なことを学ぶときに、同じ問題を何度も繰り返すのは有用だと考えています。脳に情報を定着させるためには繰り返しとテストが効率的だという研究結果があります。しかし、実務でプログラミングをする場合、同じことを2回書くことは滅多にありません。対象となるソフトウェア、一緒に働く人たち、自分自身の知識、などの要因がありますが、応用問題を解けるようになる必要があります。学習教材に書かれていることを少しアレンジしてみて、この場合はどう書けばいいだろう？と試してみるとか、まずなにを作るかを決めて、どう実装するか分からないところから始めてみるとか、そういったことを繰り返してみるといいと思います（プログラミング学習において OJT が最も効率的と言われるのは、実務においては、どう作るかということをまったく考慮されてない問題が与えられることが多々あるからなのでは、と想像します）。
何が批判対象となっているのでしょう。復習していることではなく、アウトプットが少ないことを指摘されているのかもしれません。
適切な反復とは、インプットではなくアウトプットの反復ではないでしょうか。そしてアウトプットを高い質で反復するには、アウトプット時の脳の動きをなるべく再現することだと思います。つまり、初見と2回目以降で、まるで模範解答を見たことがないかのように同じように悩む必要があるということです。模範解答の記憶は少なからずあるので、これは難しいことに思えます。「同じ教材を二度やるな」というのは、その点に関しては現実解かもしれません。2回目以降はアウトプット方法を変える（たとえば模範解答と常に別の解を探す）のであれば、同じ教材を繰り返すことも有効かと思いますが、入門教材だとそんなに回答のバリエーションある設問がなさそうな印象です。
この持論に科学的な裏付けはありませんので、ご了承ください。
Question3
3. もしこれから第一言語を習得するとしたら、どんなステップで学習していきますか？
まずは基礎的な文法や関数を書籍やインターネット上のコンテンツで学び、ある程度理解したら、自分の作りたいものを、調べながら作っていって出来ることを増やしていくようなステップで学習していくと思います。
「新しいプログラミング言語を習得するとしたら」と理解して回答します。
最近は無料でも有料でも入門教材が手に入りやすいので、そこから手をつけます。公式ドキュメントは、それが入門教材としても高評価でなければ、難しいので避けます。
教材選びは、具体的なアプリ作成まで含んでいるかを基準にします。適当なものがなければ、検索片手に（「if文 Rust」などの低レベルで）なにかアプリを作ってみます。Goを最初学んだときは、個人的に欲しかったので、とあるWebページをスクレイピングしてiCalendar形式のデータにするAPIを作りました（そのAPIは今でも使っています）。いまたとえばRustをやるなら、初代ドラクエのような、たたかうコマンドを入力したらダメージ計算をしてくれるCLIを作ると思います。GUIは難しいので・・・。
Question 4
4. もし業務未経験の面接担当だったら、ポートフォリオでどんなことを見極めますか？またそのためにどんな質問を投げかけますか？
どこを工夫したか確認したいです。あとは、やってて楽しかった点・辛かった点、もお聞きしたいです。
Question 5
5. 採用面接でアピールポイントを増やすために、簡易的なアプリケーションに追加で機能実装しています。ただ、複雑な機能を実装できることが面接で有利になるのかわかりません。ここのところって現役エンジニアの方から見たら、強みなのでしょうか？それとも業務未経験の実装物はどんぐりの背比べ的な感じなのでしょうか？
強みだと思います。業務で作るアプリケーションは複雑なものが多いので、書籍や教材で取り上げられているような単純な題材をなぞっただけでは、実務に入ったときにどのくらいできるか想像することすらできません。複雑なものを作れること、複雑なものを解きほぐして単純化できること、そうしたことがコードから読み取れるのであれば、実務に入ったときにどのくらいできるのかをある程度想像することができると思います。
複雑な機能は、ビジネスにおいて必ずしも要るものではありません。「手書き文字を判定し、内容を機械学習でカテゴリに分類し、適切な担当者に割り当てる問い合わせ分析システム」を作るビジネスもありますが、「マニュアルを整理してアルバイトを雇う」のほうが安くて早くて質も足りるということも多いためです。複雑だとメンテナンスも大変ですし。また、複雑だがどうしてもその必要があるというようなものは、現役エンジニアでもなかなか作れません（高速化のためのキャッシュとデータのリアルタイム性を両立させたり、スケールのためにpub/sub層を持ったアーキテクチャー設計をしたり。バグり散らかします。業務未経験の人ができてたら怖いです）。
私なら、読みやすいコードを書いてくれる（変数名がローマ字でもいいから情報を持ったものになっているとか、変数のスコープが異常に広くないとか、grepしたら見つかるコードになっているとか、困りそうなポイントにコメントが書いてあるとか）、解決できない問題を言語化して共有してくれる、あたりを気にします。なので、機能追加もいいですが、READMEを増強するのもいいかもしれません。私は採用面接のとき、READMEにリリースノートを含めた点を評価されました。
Question 6
6. OJTがスキル向上におすすめと言われますが、未経験だと簡単に開発現場に入れない状況です。開発現場に入れないなりにどんなことにトライしますか？
1つでもいいので、自分でアプリケーションを作り、GitHub 等でソースコードを公開するといいでしょう。よくある Twitter クローンや単純な TODO リストのような、書籍や教材で題材に取り上げられるようなものではなく、たとえばプログラミングのできない友人や家族のために作ったもの、自分自身が役に立つと思うもの、などがいいと思います。
私は未経験者を受け入れてくれる会社に入ったので、ずれた回答になるかもしれませんがご了承ください。未経験でも採用したいと思える人はどんな人だろうか、と想像して回答します。
私なら、2つ以上のサービスやアプリを作りきって公開してみます。そして友人や家族に使ってもらいます。広告も加えてみます。
小規模でも、企画からリリースまでやりきったということは、さまざまなステップを経験したということです。各ステップに精通していなくとも、「ああ、あれですね」とエンジニアとしてのコミュニケーションは成り立つことが期待できます。そして公開して使ってもらったということは、ローカルのハリボテやそもそも動かないものは脱したはずと期待できます。「未経験NG」「経験があってほしい」というのはつまり、なんらか最低限の保証がほしいなあという気持ちの問題なので、サービスを作りきった実績で不安を和らげてあげればいいのではないでしょうか。
ちなみに作るサービスやアプリは、自分の生活に特化したものにするのがおすすめです。たとえば汎用のスケジュール管理アプリはおすすめしません（だってGoogleカレンダーを使えばいいから）が、地元のギター教室のスケジュール共有アプリならアリです。同様に、日本中のおすすめ散歩スポット紹介アプリは時間がかかりすぎるのでやめて、自分の家からの散歩ルートをランダムに選んでくれるアプリを作りましょう。（もし利用に耐える汎用のものを作れるなら、それは貴重な才能なので、もはや個人でやっていけばいいのでは）
健闘を祈っています。
Question 7
7. 実務に入るためには、どんなスキル（ハード面・ソフト面の両方含む）が重要だと考えますか？できれば重要な順に3つくらいご意見をお聞きしたいです！
大きく分けると、問題解決力と問題発見力になるかと思います。問題解決力は、「なに」を「どう」作るかを考え、決める、という局面で役に立ちます。仕事でプログラミングをする場合、サービスレベルで「なに」を作るか、ということを自分で決めることは稀でしょうが、アプリケーションの内部においては「なに」を作るかを自分で決めなければなりません。プログラムを問題解決のためのツール、という捉え方をすれば（たとえば ls コマンドは「ファイルの一覧を見たい」という問題を解決し、ブラウザは「インターネット上のコンテンツを読みたい」という問題を解決します）、1つの機能の中にも解決しなければならない問題が多数内包されていますので、大きな問題を小さな問題に分解して単純化し、それらを1つずつ解決していくことは、分析・設計・実装、というプロセスであり、プログラミングそのものだと思います。問題発見力は、常に改善できるところはないか探す習慣を持ち、いまの状況を当たり前だと思わないこと、受け入れないことです。たとえば、日々の手作業を自動化できないか検討する、より効率的な書き方はないか模索する、そういったことを日常的にやることで、生産性が上がったり、ソフトウェアの保守性が上がったりするので、長期的に見れば問題発見力も大事だと思います。
「できそう？」に対して「がんばります」ではなくYES/NO/わからないで答えてくれること。つまり、質問にストレートに答えてくれること（ストレートに答えたあと、がんばってみたいと加えてくれるのは最高です）。
エラーメッセージをできるだけ読み、それでも解決できない問題を言語化して共有してくれること。エラーメッセージを読んでいる段階から「読んでいる」ことを、「こんなレベルの質問していいのか悩む・誰に質問していいのか迷う」を、共有してくれること。
読みやすいコードを書いてくれること（変数名がローマ字でもいいから情報を持ったものになっているとか、変数のスコープが異常に広くないとか、grepしたら見つかるコードになっているとか、困りそうなポイントにコメントが書いてあるとか）。
実務には多くの人が関わるので、まず関わりの窓口となるような前述の点が重要だと考えています。技術力はあとから伸ばせばいいし、究極、技術力がなくてエレガントなコードが書けなくても、人と助け合えればなんとかなるものだと思っています。
Question 8
8. エンジニアになり現場をリードしていける人材になりたいが、成長できるか不安です。ジュニアからシニアになるために、大事なことって何でしょうか？
いきなりリードエンジニアを目指すのは、大変なのでまずは目の前のことを仕事コツコツとこなすことが大事だと思います。
人をリードするには自分が自立していることが前提なので、人から依頼された仕事がしっかり出来るようになりましょう。
依頼された仕事を１つ１つしっかりこなしていくことで周りから信頼が得られて、自然とリーダーを任せられるようになるのではないでしょうか。
ジュニアとシニアの大きな違いのひとつは、自分以外の成長に寄与できるかどうかだと思います。そのためには、自分の成功体験に基づいた確固たる方法論を確立することが必要です。自分でやって上手くいったことを他のメンバーにも伝え、チーム全体にいい効果をもたらす機会が増えれば、自然とリーダー的な立場になっていくのではないでしょうか。それと同時に、過去の成功体験に縛られることなく新しい手法や価値観を柔軟に受け入れる姿勢も必要です。ソフトウェアの世界は移り変わりが激しいので、いつまでも過去の栄光にすがっている人は、先進的なチームであればあるほど良い評価を得られないです。大切なのは、色々なことを試し、効果を測定し、良い効果を得られたことを広めていく・継続していく、というプロセスを繰り返すことです。それを個人レベルではなくチームレベルで行えるようになるためには、他のメンバーの個性や志向を考慮しながら適切なやり方を調節出来るようになる必要があり、それもまた場数を踏むことで向上していくものなので、とにかくチームメンバーを巻き込みながら色々やってみましょう。
（私が知りたいです！）
最後に
以上、第一回『kikou』のご回答になります。
みなさん総じて、チームで動くためのコミュニケーション方法など、チーム開発の目線を含んだ回答が多かった気がします。独学ではなかなか気付きにくい部分があったのではないでしょうか？
これらのご質問・ご回答が学びに繋がるとうれしいです。
そしてこの企画は質問から形になっています。ぜひご参加くださいませ。質問があなたの学びに繋がることを期待しています。
次回の質問募集フォーム
この記事が気に入ったらサポートをしてみませんか？