こんにちは。
ネクスト社員の鈴木です。
僕は英語学習サービスを作り、日本人を取り巻く英語学習の問題を解決したいと、前世から考えていました。恐らくその前世でもそう思っていたと思います。
しかし、ずっとできずじまいでした・・・
今でもそうです。もはや「なにがわからないのかわからない」というのが現状です。
弊社の名前が「ネクスト」だからと言って来世も人間に転生することは保証されていません。
なので僕はこの一生を最後のチャンスだと思い、英語学習サービスを確実に作成したいと思います。
わからないことをあぶり出し、一度解決したら忘れないように、社のブログに備忘録としてこれからいろいろ記して行く所存です。
これらの備忘録が「サービスを作りたい」という志はあるけど「なにがわからないかわからない」という非エンジニアたちの助けにもなればいいなと思っています。
非エンジニアがサービスを作ることができるようになるために
さて、これは「非エンジニア」に向けた記事です。
初心者エンジニア？
我々非エンジニアからしたらベテランです。
サービスを作ろうと僕のような非エンジニアレベルへの記事を探そうとしても、ある程度の知識が前提とされたものばかり。なので、非エンジニアがサービスを作れるようになるために必要なものやアクションをまとめてみました。
作りたいものに必要な材料を知る
僕の英語学習サービスを例にします。
僕が作りたいものは単に紙の英語の問題集がデジタルになったものです。
「問題を解き終わったら答え合わせがされる」
メインの機能はこんなに単純です。
そのために僕が必要だと思った材料は、
- プログラミング言語の知識
- プログラミング言語が動くための環境構築の知識
これだけです。
しかし、先輩エンジニアのアドバイスにより、上記に加えてあと２つ、必要材料の存在が発覚しました。
新発見した必要素材は以下の２つです。
- インターネットのデータのやり取りの仕組み（後述）
- 開発工程の知識（後述）
僕は
- プログラミング言語の知識
- プログラミング言語が動くための環境構築の知識
これらの材料（知識）だけで今年（２０１８年）の２月から４ヶ月取り組んできましたが、「問題を解き終わったら答え合わせがされる」この機能すら作れずじまいでした。
なぜなら、
- インターネットのデータのやり取りの仕組み（後述）
- 開発工程の知識（後述）
これらを全く念頭におかなかったために自分でも気づかずに無謀な開発をしており、壁にぶつかって挫折していたからです。
次の章からは、
- インターネットのデータのやり取りの仕組み（後述）
- 開発工程の知識（後述）
に関してどのように体得するか考えていきます。
インターネットのデータのやり取りの仕組み
例えば僕はRubyという言語とフレームワークのRuby on Railsを使ってサービスを作成しようと思っていました。
そこで、まず言語の練習として「Progate」さんや「ドットインストール」さんを活用させていただきました。その練習として、ツイッターのようなアプリを作成するのですが、そのアプリの動きを応用するだけで、僕の作りたいアプリも作成できそうでした。
しかし、まったくうまく行かず・・・
なぜなら、それらの学習サービスでは言語の習得を念頭においており、サービスのシステム全体を作ることは範囲外だったからです。僕は言語を習得すればなんとかなるものだと思っていました。
「GET」と「POST」などのデータのやりとりの知識がなく（そもそも存在から知らないレベル）
ページ偏移がうまくいかず、
データベース設計の知識がなく、（そもそも存在から知らないレベル）
「答え合わせ機能」がうまく動かず、
僕はもう少しで冥王ハデスに来世も人間に転生させてもらうよう菓子折り持ってお願いしに行くところでした。
しかし、弊社代表の小川の助言に助けられ、現在データのやり取りを根本から知るために「WEBを支える技術」を読んだり、データベースについて知るためにネットで調べたりしています。
あなたがなにかしらサービスを作りたいと考えているなら、まずそのサービスがどのような環境で作られているのか、その環境の仕組みも理解しておくべきです。
どの宗教の神でも、人間を作る前に、大地や空気、そして海など、人間に必要な環境を作っていたように・・・
開発工程に関する知識
要件定義→設計（内部・外部）→プログラミング（製造）→テスト（単体・結合）→システムテスト→システム移行（本番環境への移行）→運用・保守
これが開発工程と呼ばれるものです。それぞれの工程をさっくりとは知っていたほうが良いと思います。
例えばあなたがプログラミングをしていて、「コードに間違いはないのに全然前に進めない!動かない！」となった場合は、前の工程の設計に問題があるかもしれません。
サービスをリリースしても、「ぜんぜん流行らない！使ってもらえない！」という場合は、そのサービスそのものの価値を左右する「要件定義」を見直す必要が濃厚です。
このように、開発工程とそれぞれの工程の役割をさっくりとでも知っていれば、なにかしらの問題が発生して行き詰まったとき、前の工程（上流工程）を疑うことができます。現状の工程に問題はないのに進めない、しかし、開発工程の知識が０であるために上流工程を疑えずお手上げになる。
「いや、さすがにそんなやついないだろ」
少なくともこの記事を書いている人がそうでした。
先輩エンジニア
非エンジニアがサービスを作るなら、先輩エンジニアが必須です。
バナナジュースにバナナが必要なレベルで必要です。
非エンジニアは往々にして「なにがわからないかわからない」ものです。
そのわからないことをあぶり出し、まず何をすべきか教えてくれるのが先輩エンジニアです。
ネットで検索できることはあなたが認知していることだけ。
あなたが認知していない部分を教えてくれるのは先輩エンジニアだけ。
手を動かすこと（そしてそのための方法）
手が動かない人は、「自分にはやる気がないんだ・・・」と落ち込みがちです。
僕もそうでした。
っていうか今でもそうです。
しかし、僕の人生を振り返ると、頑張っているときと頑張れていない時に、ある明確な違いがありました。
それは
「具体的に何をすればいいか、わかっているか、いないか」
「自分にもできるという実感を、持っているか、持っていないか」
です。
どちらが欠けても、崇高な目標は一気に
あなたの中では「無理ゲー」に変わります。
無理ゲーのために手を動かす気にはならないですよね。
「作らなければ」という使命感と、「やる気が出ない」という現状に板挟みになる気持ちは痛いほどわかります。
手を動かし、状況から脱するためにも、今までの章で紹介してきたような事柄をインプットしてみてはいかがでしょうか？
そうすれば、何をすべきか具体的な作業がわかり、具体的な作業内容がわかると、自分でもできそうな実感が生まれます。
そのために僕も勉強中です。
考えすぎないこと（完璧を求めない）
「玉ねぎの皮むきを回避しましょう」という話です。
サービスづくりには多くの工程があり、たくさんの種類の知識が必要です。
しかし、それぞれを１００％達成しようと思うと、いつまでもゴールにたどり着けません。
「６０点主義」で行きましょう。
また、記事全体を通して、知識を得ることを重要視しているような印象を与えていると思いますが、スタンスとしては「必要になったら、必要なところだけ勉強する」という、いわゆる「遅延評価学習」的なスタンスをおすすめします。
この記事は個人のサービスを作りたい方を想定しています。
会社の重大な基幹システムなどを作るわけではないので、走り出して、ぶつかったら考えるスタンスでいいと思います。
物事が進む実感を感じられるので、やる気もアップすると思いますし。
まとめ
ここまでいろいろ書いてきましたが、僕もこの記事に書いてきたことを実践しなければいけない立場です。
ここに記されているのは、僕が弊社の偉大な先輩エンジニアの方々からいただいたアドバイスを元にして、個人的に考えたプランです。
実践してみてどうなったのか、しばらく立った後にそんな記事を書くのが楽しみです。
