誰？
僕のスペックとかは下記を読んでください。
メインフレーム5年の経験しかない金融系SEがiOSエンジニアとして転職した話
SIerからWeb企業（っぽいところ。何企業なんだ……？）に行き、2週間たちました。
まだ一人前とは言い難いですが、色々バタバタ足掻きながら、開発業務に入りました。
実務でのiOS開発未経験とはいえ、新人ではなく中途なので、即戦力として採用されているつもりで働いています。
実際は勉強しながらなので即戦力には程遠いですが、姿勢や気持ちはそんな感じです。
（とはいえチームの人はいい人だったので、転職のときイメージしていたよりも手厚いサポートを受けています）
この記事では、その中で独学ではあまり使わなかったけど現場入ったらめっちゃ必要だったことを書こうと思います。
コーディング云々というよりかは、もうちょっとハウツー的な話になると思います。
ソフトスキル面とハードスキル面でわけます。
ハードスキルに関しては完全にiOSの話になっちゃいますが、ただそんな深いところまで踏み込まないので、
他の分野の方でも役立つような気がします。
ソフトスキル
色々アカウントつくる際の権限
GithubやSlack、Apple Developer Programだけでなく、FirebaseだのCIツールだの、作らなければいけないアカウントが最初は本当に多かったです。
よほど人の出入りが激しいプロジェクトじゃない限り、この辺の運用フローが確立していないと思います。
正直それぞれのツールに詳しい人が適宜登録していく感じになりました。
Githubで、Pull Request出そうとしたらリモートリポジトリにPushできなくて、
エラーメッセージも「リポジトリが見つかりません」みたいな感じで、僕もGithub使ったチーム開発が初だったので、
環境要因なのか操作ミスなのかがわからなかったのですが、結局僕のアカウントが閲覧権限しかなかったのが問題でした。
ググり力 + 質問力
前職の金融系システムは、「自己判断するな」の文化でした。
「ちょっとでも疑問持ったら聞け」と言われて育ちました。
質問しないで自己判断する奴は事故る、と言われましたし、実際そうでした。
だから９割こうだろうな……と思うことでも、万が一のために先輩・上司に聞いて確認していました。
質問できない奴＝仕事できない奴みたいな感じでした。
ただよく言われるように、Web企業で同じスタイルでやると、「こいつ無能か……？」となってしまう気がします。
郷に入れば郷に従え、ということで、今の職場では極力自走するようにしています。
（もともとそっちのほうが得意ですし）
自走する際に最も必要になるのは、ググる力です。
単にGoogle検索するだけなら誰でもできますが、たとえば検索するワードのチョイスや、
出てきたサイトのタイトルから適切なページにいけるかとか、リテラシーの部分で差が出ます。
自走するのと自己判断で突っ走るのは違います。
自走して正解に行けるのであればチームとしては助かりますが、未経験者が自走しようとして、あらぬ方向に突っ走ってしまうことはよくあると思います。
ある程度自走したところで、適宜質問して確認するのは、Web業界でも大事だと思っています。
Webだとスピード感命なところがあるので、SIと同じ感覚で質問するとめんどくさい奴になるので、
なるべく質問は短くして、相手を拘束する時間を短くすることを意識しています。
いい感じに質問する力、というのは前職で培ったソフトスキルがほぼそのまま使えている気がします。
なるべくOpen Questionにしないことが大事ですね。
「何かパソコンが動かないんですが……」と聞かれると困りますよね。
「◯◯という操作を行ったあと、パソコンがフリーズしました」と聞かれると、少しは答えやすくなります。
もっといいと思うのは、「パソコンがフリーズした。◯◯という操作をしたのですが、これが原因ですかね？」と質問すると、
相手はYes/Noで答えられるので、一番楽かなと思います。
Face to Face or Slack
皆さん、大事な話をするときって、どうします？
営業の人なんかと話していると、「ここは大事なところなんで、メールじゃなくて対面で話せませんか？」と言われたりします。
IT業界の人間の考え方だと、対面で話したこと＝記録が残らないものなので、正直大事な話でも文章でして欲しい感覚があると思います。
さて、Web系独特の文化として、Slack中心のコミュニケーションがあると思います。
大事な話をするとき、Face to Faceでどこまでやるか、Slackでどこまでやるかは、その企業やチームの文化が結構あるので、確認した方がいいです。
「え！？ そこまでSlackでやっちゃうの？」
→「いやむしろSlackの方が後で見返せるからありがたいじゃん？」
みたいな。
前職だと、Face to Faceの確認というのは重要で、対面で話した上で議事録とって証跡を残そうね、という文化でした。
Web系だと重要な意思決定もSlackでパンパンやりとりしてる内に決定しちゃったりするので、結構面食らいます。
僕の入ったところだと、アイディアを発散させる目的の会議では対面で集まるけれど、その後の意思決定なんかは、
対面でやる意味がそんなにないので、資料送って、Slack上で確認して、OK/NG出す文化っぽいです。
ハードスキル
まず規約を確認
最初に規約を確認しました。
規約ガチガチの会社もあれば、皆自由に書いている会社もあると思うので、そこは最初に確認した方が事故らなくてすむと思います。
たとえばエウレカさんだと下記の規約に従って書いてるみたいです。
あとコードレビューの運用とか、テストの運用とか、最初に確認しときましょう。
新規開発かアップデートか
新規開発してるチームに入るか、既存のアプリのアップデートかで、やることは変わると思います。
前提として、僕は既存アプリのアップデートに入りました。
新規開発だと、コードライティング＞＞＞＞＞＞リーディングですが、
既存のアップデートだとコードライティング＜＜＜＜＜＜リーディングになります。
Xcodeのプロジェクト内検索
個人開発と商用アプリで、僕が一番違うなと思ったのがコード量です。
これはもう個人で作ったアプリとは比較にならないと思います。
アプリの持っている機能にもよるとは思いますが、普通に数万〜数十万くらいの規模のコードになります。
個人開発ではほとんど使ったことなかったんですが、Xcodeのプロジェクト内検索をめっちゃ使います。
てかこれで移動するのがデフォルトになってます。
Jump to Definitionの活用
プロジェクト内検索と合わせて、XcodeのJump to Definitionもめちゃくちゃ使います。
アプリの規模が大きいと、メソッドの定義が相当離れた場所に書いてあったりするので、Jump to Definitionにめちゃくちゃ助けられました。
⌘キー押しながら、メソッド名押すと使うことができます。
⇒このやり方だと、次に「Jump to Definition」をクリックする必要がありますが、
Commandキー+Controlキーを押しながらクリックすると、即飛ぶことに気づきました。
昔のXcodeだとCommandキー＋クリックで即Jumpだったみたいで、設定変更すればそっちにもできるとのこと。ここは好みですね。
更にさっき気づきましたが、「Caller」を押すと、メソッドを呼んでいる場所に飛べるので、そっち方向の逆引きも可能でした。
個人開発だとメソッド自分が中身書いてたので、ありがたみが全くわからなかったです。
デバッグメッセージがヒントになる
これも既存改修ならではだと思うんですが、コード読んでるだけだとイメージつかないところが、
デバッグログで出してるメッセージでわかることがあります。
ソースコードだけでなく、デバッグでコンソールに吐いてるメッセージも見るといいでしょう。
Gitの操作は慎重に
未経験エンジニアが失敗しがちなのが、Gitの操作だと思います。
僕もかなり勉強した上で現場入って使ってみて、やっとなんとかなるかなと思った感じです。
Pull Request送るまでの流れは、ミスらずできるようにしておきたいですね。
開発したコードにバグがあったとかはいいと思うんですが、リモートリポジトリ破壊しちゃうとか、
その手のミスはどうしても無能感出ちゃうので、できれば避けたいところです。
（さすがに入りたてのエンジニアにmasterブランチに権限与えないとは思うので、破壊もできないと思うものの……）
初心者が必ず困惑するところなので、Git操作の記事はQiitaにもいっぱいありますが、下記のQiita記事が個人的には好きです。
未経験がWeb系転職成功したいならgithubでissue管理して開発しよう
ホントはGitの操作って本質じゃないところなんですが、
（別にバージョン管理スペシャリストになりたいわけじゃない）
基本的な操作ができないと、その先の開発が円滑にできないので、しっかりやっておきましょう！！
おまけ
Twitterやってます。
よろしければフォローお願いします。