18卒未経験エンジニアが先輩に鞭打たれた内容まとめてみた（本タイトル）

自己紹介

今年度の4月から某IT企業にエンジニアとして入社した自称２２歳・独身・会社員・男性（学生終わっちゃったよ...）
自分でサービスを作っていて気になる点わからない点を上司に聞きまくったり教えていただいたりしている
最近話題になっている
"東大を出てゼロからプログラミングを学び、1年後にWebサービスを作ってみた話"
に感化されたため今回まとめてみました
上のページはフリーランスとしての進路を選んだ東大生の話だったので、
私の方からは
正社員として企業に就職したエンジニア未経験「東大生（略称w）」
バージョンという事でまとめてみました

作成中のサービスとしては上の方と同じ「本」に関するもので、
「本」の力とはすごいよねから

『気づきを与えて機会を増やす』
を目的に
のあらすじや絶対値評価からの購入
というフローから別のフローあるよねっていう
大まかに言うとそんな感じのサービス作っております

大まかな内容としは、会社員だからこそ得られる「上司に教えてもらった事」になっております
3月からどんな変化があったのか、自分自身落とし込めているかの確認のためでもあるので
カロリー低めに見ていってください

上司Nさんに教えてもらったことをメインに加工を加えたまとめ

目的

始めて自分一人でサービスを作成していくにあたり、指摘された点が多かったため、
振り返りがいつでもできるよう、言われたことをまとめてみた

背景

自分のサービスをいざ作ってみようと思った時、あまりにもわからないことが多すぎて先輩に質問しまくってしまった
時には椅子に座って、時には床に座って、また時には床にへばりついて先輩から指摘を受けていた

→※自分が確認するのはもちろんのことなのですが、これからエンジニアになろうと思っている方に読んでもらいたいです

目的から考えよう

ここ重要：目的から考える
目的から考える

↑でないとやる意味ないよね
目的を達成されるためにどういうふうにやるのか、フルで必要なものは何か
機能ベースの話はしないほうがいい、というより思考の向きは「目的>>>>>>>機能」
- でないと機能を作ることが目的になってしまう」
機能ベースで考えてしまうと、ユーザーが使ってくれるかわからなかったり必要のないものまで実装してしまう
今やることにとらわれ過ぎていると方向性がぶれてしまう←目的は何さ、目的からの逆引き

その結果こうなるのかなぁという引用(借りさせていただきました)

まず2ヶ月たったところで、一通り動くものが出来たので、ツイッターで告知し、公開しました。
けれども誰も人が来ません。。実はそのころは質問するのには有料、という風にしていました。
「このアイディア誰も思い付いていないみたいだし、もしかして有料でもイケるかも！？」などと思ってはいけなかったのです。アイディアに価値はない、という厳しい現実にさらされました。
特にサイトを広める手法というのも知らなかった（今でもわかりませんが）ので、結局一度クローズしました。
1ヶ月かけて無料でも使えるようにして、少し見栄えも直して改めて公開しました。
すると、少しずつユーザーが増えてきました。ですが、まだまだユーザーは多くありません。もっとPRを頑張らねば、、という感じです。

現在のベロシチを元に
現在何時間でどのくらいの作業を行ってていて、本来との予定との差はどれだけなのかを考える
->そこを改善するためには何の課題があって、課題を改善すると本来の目標で終わるのか
ベロシチ＝速さ

積み重ねが大切

積み重ねが大切
積み重ね系はチャットは避けるべき←ブログ(qiita)とかの方がいい
積み重なるものとしてローカルのものをすべてqiitaにあげる
工数の積み重ねで考える
スプレッドシート等に時間や工数の実績を記入する

->あとあと確認してどの作業にどれだけの時間がかかったのかを確認するため

issuueから

各ユーザーストーリー(issue)単位で動くことを確認してコードレビューもOKでmasterにマージ
その上で次に進めていく
細かい粒度で作業していくこと
issueのタスク完了にチェックを入れる
章立てで訂正していく
イシューは雑多にしない
- わかりやすく小分け（タスクごと）
- 小分けしないと何をやったのかわからない

スコープ（粒度）の話

タスクごとに粒度を設定して「作業→レビュー→訂正→振り返り」のスパイラルを組む
スコープの幅をどう設定するのか考える

kpt（日報）の書き方

振り返りと改善を繰り返す
再現性のある書き方、何が学べたのか（具体的に）まとめる
本日やったことはなんでそれをやったのかわかるように記入してほしい

->振り返りのことっすよね
日報を書く理由：
後日見たときにどの部分が詰まったのか、
どこが苦手・スムーズだったのかがわかるようにするための日報
「だからどうしたなんでそうなった」全ての理由を考える

今日掲げていたものは何でそれはどうだったのか、次回からどうしていくのか
昨日より今日、今日より明日によくなっていけれるようにする段階であるので課題感に対してどのように取り組んだのかをまとめる
報告かっこかっこつけている表現の仕方（抽象的すぎ）、１つだけでもいいから具体的にする
課題感を深掘りしていくと機能に当たっていく←逆引きの話

予実の話

予実の部分の確認

->なぜ本来の予定と大幅にずれてしまったのかを把握するため
今日やったことは予定との差分を書く

実装・機能

コミットメッセージはわかりやすいように日本語で
モデルのバリデーションの存在理由派なんだと思う？
DBの制限の設定はコンソールでもできる
modelはユーザー側からDBに送ろうとした時にバリデートをかけるために存在する
反対にvercharでDBの設定を行うことで保存するものに制限をかけて運営しやすくする
プロトタイプでつかってもらいながら改善していく
コーディング規約絡みの指摘が多いので、
gemでrubocop入れるなどして仕組みで解決するようにした方がいい
https://github.com/bbatsov/rubocop
レビューと訂正を繰り返して完成に近づける

タスクごとに処理をしていく

タスク的なものだけではなく、完成に至るまでの必要な要項をまとめる
変えれないポイントを分けて、一つ一つ考える

考え方

一方向からの視点だけでじゃなくいろんな方面から見る
「別にそのやり方でなくてもいいのではないか」とか考える
課題感を深掘りしていくと機能に当たっていく←逆引きの話

サービスを作っていく上でのこうした方がいいよー的な

自分自身が把握しやすいようにDBの構想やレイアウトの見本をまとめておく
ゴールが達成されるためにマイルストーンを小分けしておいていく
→段階を踏めているか理解するため
→その時の判断基準としては今までの実績ベース
しっくりこないことに対して自分自身の意見も述べる←そこの調整は上司が乗ってくれること多いよ
使ってもらうことが遅れてしまうということはサービスの成長も遅れてしまうことにつながる

技術書読んだ方がいいよ

ひと月に技術書五冊読むとかしてみる
この本から何を学べて次回からどうしていくのかをまとめる
読んだ上で、こういったところでは詳しく載っていたがこういうところは詳しくなかったので次回これに関して深堀したいという具体に落とした振り返りを行う
体型的に学ぶのであれば本の方がいい

所感

今後自分でサービスを作っていく時は常に
「目的」、「なぜそれをやるのか」の思考を抱えながらやっていこうと思う