読者です 読者をやめる 読者になる 読者になる

satococoa's blog

Web や iOS アプリを作るエンジニアの日記です

RE: どんなことを勉強すればいいですか?

ポエム

仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか?」です。 それについてちょっとポエムを書いてみようかと思います。

主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。

専門家であるという視点から

エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。

僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な知識を積み重ねるだけの非常に頼りないエンジニアになってしまうだけです。

本を読もう

そこでおすすめするのが、まずは本を読むこと。 Web で検索すれば断片的な知識はいくらでも手に入ります。 Qiita とか stackoverflow などはとても頼りになるサイトだと思いますし、ブログを熱心に書いていらっしゃる方もたくさんいるので大量の情報が手に入ると思います。 でも断片的な知識をつなぎ合わせたところでどこか必要な知識が抜けてしまったり、整合性の取れていない知識になってしまったりするとやっかいです。

言語に関わらない知識ならまずこれを読んでください。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

チーム開発でコードレビューを受けるようになると、ここに書かれている内容はもはや前提知識になります。 当たり前すぎてそのうち指摘すらしてもらえなくなるかもしれません。 僕も最近再度読み返しましたが、無意識のうちに「良いコードってこんなコードかな」って思っていることをきちんと具体例とともに言語化してくれている本なので、これを読んでおくことでコードについてのコミュニケーションがスムーズになります。

Ruby なら以下のあたりを押さえておくといいと思います。適当に Amazon のリンクを貼りますが、電子版もあったりするので適宜探してください。

初めてのRuby

初めてのRuby

初めてのRuby

ちょっと古い本になりつつありますが、他の言語の経験がある人が Ruby らしさを知るにはとても良い本。薄いのであっという間に読めますし。

プログラミング自体も初心者であるなら スタートアップRuby の方が易しくていいかも。

たのしい開発 スタートアップRuby

たのしい開発 スタートアップRuby

Ruby のコミュニティ含めた文化についても知ることができます。幸い身近にコミュニティがある場合は、この本を読んでから ⚪︎⚪︎.rb みたいなところに飛び込んでいくと、継続的にモチベーションや情報を得るきっかけが得られます。

Rails についてはまずは電車本だと思います。

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

そこから先は パーフェクトRuby (PERFECT SERIES 6)パーフェクト Ruby on RailsメタプログラミングRuby などなどたくさんの本がありますが、まずは上述のあたりから入るといいと思います。

iOS なら本ではないですがまずは Apple Developer で公開されている公式のドキュメントから始めるといいと思います。

チュートリアル Start Developing iOS Apps Today: Setup

その他のドキュメント 日本語ドキュメント - Apple Developer

特に iOS View Controller プログラミングガイド に一通り目を通しておくと、iOS 開発の勘所はなんとなくわかります。

そのあとの書籍ですが、以下がおすすめです。

UIKit徹底解説 iOSユーザーインターフェイスの開発

UIKit徹底解説 iOSユーザーインターフェイスの開発

主に View について書かれた本ではありますが、View, View Controller 周りで何ができるのかをちゃんと知ることによって、ようやく MVC を意識した設計が出来ると思いますので。

アンテナを張ろう

次におすすめするのが、新しい情報にアンテナを張ること。

ただアンテナを張るだけではなく、情報を鵜呑みにせずに自分で確かめることも必要です。 Web にある情報は特に玉石混交で、誤った知識をそのまま業務に適用してしまうのは非常にまずいことです。 また、必ずその記事の書かれた日付を確認してください。技術情報には鮮度があります。

その前提の上で鮮度の高い情報を得る方法は以下のとおり。

1. 信頼できる人をフォローする (Twitter, GitHub, はてなブックマーク)

GitHubTwitter で有名な人とか信頼できる人をフォローしておくことで、非常に鮮度の高い情報を得ることができます。 はてなブックマークの場合は、「お気に入り」っていう機能ですね。

例えば

  • ブログ書いたよー とか
  • こんなリポジトリの Watch を始めた / Star をつけた
  • ⚪︎⚪︎でハマった
  • このエントリにブックマークつけた

一度習慣にしてしまえば気になる人を見つけるたびにフォローを増やせばいいので楽ですが、まだやっていない方はこの休みのうちにガッとやっておくといいと思います。

GitHub の Star は http://starseeker.so っていうサービスを使っておくと、自分がフォローしている人がスターをつけたリポジトリが毎朝メールで配信されてくるので超絶便利です。

はてなブックマークのお気に入りは iOS 限定ではありますが HBFav2- Hatena-Bookmark Reader for iOS を使うと、自分がお気に入りに入れているユーザがブックマークした URL が随時 iPhone に配信されてくるのでこれも超絶便利です。

2. 一次情報にまず当たるクセをつける

なるべく一次情報にあたるようにするのも時間節約のコツです。 鮮度の落ちた日本語のブログエントリよりも、githubリポジトリ上にある README を読む方をまず優先するといいと思います。

3. 実践してみよう

最後にその情報を自分のものにするために手を動かすことも大事です。 書籍や Web の情報源から得た情報をきちんと自分のものにするには、ちゃんと手を動かすことだと思います。コードにして自分のリポジトリなり gist に置いてみて初めて「自分のものになった」と言えるかもしれません。

なので、ぜひ試してみてブログなり GitHub なりにコードを載せてみて欲しいと思います。

チーム開発という視点から

チーム開発においては、会社で使っているコミュニケーションツールに慣れておくことも大事だと思います。 例えば Git / GitHub を普段から使って、その機能に慣れておくこととか。

今までコードレビューを受けられる環境にいなかった人は、「人に読んでもらう」ことを前提としたコーディングを心がける必要があります。

なかなかこれは意識してやるようにしないと身につかないのですが、コミットの粒度とかコミットログの書き方、コード内のコメントとか関数名、変数名などあらゆるところに読む人の目を意識する必要があります。 詳しくは前述のリーダブルコードで。

あとは仕事の優先順位のつけ方にも考慮が必要です。 タスクが複数あるときにどのタスクから手をつければいいのか。 それは状況によって違ってきますが概ね以下のようなことを考えるといいと思います。(そして困ったらチームメイトにすぐ相談することも大事)

  • このタスクを {始めること or 終わらせないこと} によって誰かの仕事を止めてしまわないか?
  • 技術的なリスクや検証が必要な項目が含まれるタスクの場合、早めにやっておかないとその他のタスクに影響を及ぼしてしまうのでは?
  • 作ろうとしている製品にとって、このタスクの優先度はどのくらいなのか?(実装に時間はかかるけどなくてはならない機能だったら、すぐ終わるなくてもいい機能より先に実装した方がいいのでは?)
  • ユーザにとって自分がこれから行うタスクはどんな影響を与えるのか。

ちょっと抽象的な感じになってしまったし、普段無意識で行っていることを網羅はできていないと思うのでちょっと頼りないですが、参考にしていただけると幸いです。

社会人としての視点から

ここから先はさらにポエム度が高まってしまうのですが、要は「一緒に仕事してて楽しい」って思われる人になりたいな!ってことです。 普段から僕も気をつけていることではありますが、日常の中でついつい雑になりがちな部分なので気をつけたいです。 Team Geek ―Googleのギークたちはいかにしてチームを作るのか の HRT: 謙虚 (Humility), 尊敬 (Respect), 信頼 (Trust) も参考になると思います。

同僚として敬意を払う

「親しき中にも礼儀あり」です。 必要以上に踏み込み過ぎず、かといってよそよそしくなりすぎず、同僚としての適度な距離感を取れるといいと思います。

また意見の相違がある場合は意見についての厳しいやりとりは必要ですが、人格の否定をしてはいけません。

「あの人、全然システムのことわかってないからな」って諦めてしまうのはまずいです。 (ついつい自分が詳しい分野については上から目線になっちゃったりもしますが...。)

そうではなく、ちゃんと相手に教えるべきことを教えていない、または相手にとってわからないことを聞いてもらえる関係を築けていない自分になっていることを反省すべきです。 そして逆に自分が知らないことをたくさんその相手は知っているはずです。お互いの知らないことをきちんと質問しあえる、そしてその上で意見を交わせるようになりたいですね。

不平・不満と付き合う

仕事をしていると、大小さまざまな不平・不満が出てきます。 全てが自分の思い通りに進むわけではないので当然だと思います。

その不平・不満をどのように解決しますか? SNSで愚痴ったりしていると何の解決にもならないし、偶然同僚がそれを見かけると非常に嫌な気分になると思います。 同僚じゃなくても、大抵そういう愚痴って見かけるたびに見る人の心を重くするものです。

確かにその愚痴は正論で「正しい」ことかもしれませんが、それを声高に唱えて周りに威圧感を与えることは必ずしも正しい方法だとは思いません。 解決すべき問題なら解決策を考え自ら動く、もしくは解決できる権限を持つ人に相談をする、など前向きな態度で挑むことが必要だと思います。

とはいえ、愚痴ってすっきりする程度のものごとも多いので、それはそれで人に見えないところでこっそりお酒の肴にでもしながら楽しい時間に変えてしまえればいいと思います。結構そういうのも僕は好きです。

人を頼る

人を頼ることってなんとなく自分のダメさを認めてしまうことだったり、人に迷惑をかけてしまうことだったりしそうでなかなか勇気が要るものです。 でも全てを自分一人でこなそうとするとタスクの量か質の問題で必ずどこかで限界がきます。だからチームで仕事をしているんだと思います。

チームメイトにはそれぞれ強み・弱みがあります。自分一人で閉じてしまって、個々がブラックボックスになってしまうのはもったいないと思います。 常に気軽に相談ができる状態にチームを保ち続けられるといいですよね。

そのためにはあまり関係なく思えるかもしれませんが、普段から雑談したり、ご飯を一緒に食べたり、くだらない話をチャットでやりとりしたりして心理的な距離を近めておけるといいなと思います。

そして、いざとなったらきちんと頼る。そして自分もどこか一部でいいから誰かに頼ってもらえる。そうなりたいです。

まとめ

途中から論点がズレてまとまりが無くなった感じもしますが、何かの参考になれば幸いです。 僕がこういう気持ちで仕事をしているっていうことだけ伝われば十分なのかもしれません。。という自分のためのポエムでした。