エンジニア実務未経験の僕が、入社早々プロジェクト任されて陥った4つの罠たち

こんにちは、太田です。 一部の方々は既にご存知だと思いますが、僕が担当しておりましたプロジェクト「Team-hacker」が特定少数の人たちに公開されました。

まだまだ課題が山積しておりますが一旦の区切りでもありますので、せっかくなので今回は件名のとおり、エンジニア実務未経験の僕が入社早々プロジェクトを任されて陥った4つの罠たちについて書こうと思います。

git問題

僕みたいなエンジニア初学者の人でこんな経験をしたことはありませんか？

今まで自分だけで開発していたけど、チーム開発することになって初めてgithub flowにもとづいて、ブランチ切って開発してチェックアウトして…ってしてたらあれ？今まで書いていたプログラムが全部消えてるううううううぅぅぅぅぅぅぅぅぅぅぅぅｌ！！！！！！！！！！

はい、そうです。僕いわく「git問題」。 gitの仕組みをちゃんと理解しないでいきなりgitを使い始めたらもう大変。

今だったらあの頃の自分に対して「お前、馬鹿だなーｗ　ブランチちげーじゃねーか！」って言いたくなっちゃうんですけど、その時は本当にわからなくて社内の先輩エンジニアたちに「プログラムキエタ！プログラムキエタ！」って大騒ぎしてご迷惑をおかけしたものです…。

このおかげで、途中まで作ってたアプリを全部消して最初からやり直しましたからね。 エンジニア初学者の方が読んでいたら、次の言葉を覚えておいてください。

「git checkoutしても、プログラムは別のブランチにちゃんと残ってる」

devise問題

そう、これも激ハマりしましたよ。 devise。railsの第4うんちゃら認証ライブラリとして確固たる地位を築いているあのライブラリさんです。 そして僕がrailsでの実践的な開発で初めて使ったライブラリ。

「ライブラリってちゃんとreadme読んで使うものなのね」っていう今考えたら超絶当たり前のことを知ったのもこの時です。

もともとエンジニアになる前は、かの有名なrailsチュートリアルをやっていたわけなんですけど、railsチュートリアルは認証については自作なんですよ。

それを実践開発で、readmeをまともに読まずにgemに「devise」ってしっかり書いて、bundle installして、できたcontrollerにいきなりrailsチュートリアルの認証のアクションを書き始めたらもう大変。もう止まらないエラーの雨あられ。いくらWEB調べても全然出てこない。そりゃそうだよ…そんなことで間違えてるやつなんて滅多にいない。はい、ここにいました。

readmeはちゃんと読まなくちゃダメですね。

deploy（capistrano）問題

これも超激ハマリしたやつの1つ。 うちの特命エンジニアの釘宮がansibleを使って、すごーくいい感じにEC2にrailsアプリケーションをデプロイする方法をqiitaで書いたんですね。それが以下の記事なんですけど。

ansibleを使った事ない僕がansibleつかってawsにRails + Nginx + Unicorn 環境をセットアップをしてみた(まさかの手動あり) - Qiita

それで僕も同じことやろうとしたら、エラーが出続けまして。直しても直しても「あれ？」みたいな。徹夜してやっても結局ダメで、「こうなったら自分でやってやる！」って思って以下の記事を読みながらやっていたんですけど、「あれ？サーバーの環境構築はいいけど、これアプリのデプロイどうすんの？」ってなって。

さくらVPS契約後、最速でrails(MySQL+Apache)環境を構築する(CentOS6.2 - 2012年8月版) - Qiita

で、filezillaとかcyberduckとかのftpソフト使ってファイルをアップしようとしたんですけど、それもsshエラーが出てダメで。

それでにっちもさっちもいかなくなって、やべーーーーーってなった時に先輩エンジニアに相談したら「capistrano使えば？」みたいなまさに天の思し召し的なアレがきて。で、capistaranoであれば先輩も知ってるっていうので、いろいろ聞きながらなんとかデプロイに成功したんですよ。

え？経緯はどうでもいいから何が原因でどう解決したのかさっさと言え？ ですよね。ごめんなさい。

つまりdeployの大きな原因はsshでした。

よくある方法で、ec2使ってやるにしても、ssh接続のためにconfigファイル書くとか公開鍵と秘密鍵の違いとかっていうのは、エンジニアであれば当たり前に知ってることだと思うんですけど、そういうのもいまいちわかっていなくて。

かつcapistaranoだとクライアントとサーバーの関係もあるけど、さらにgithubとサーバーの関係もあって。そこらへんがもう頭のなかでぐちゃぐちゃで当時は全然わからなかったですね。

なのでデプロイにつまったら、まず先にconfigファイルのhostとかhostnameとか、秘密鍵がサーバーの公開鍵と合ってるのかとかそこらへんからまずは疑いましょう。

設計に関する関係者の認識ズレ

これです。これが最もヤバかったですね。Aさんが考えていたこととBさんが考えていたことが違くて、後で合わせたら「あれ？これおかしくね？」みたいな。そこで全部やり直しすることになってっていう最悪のパターン。

自社サービスだからよかったですけど、これがお客さん相手だったらアウトでしたね。いくらベンチャーだからといって設計を甘く見ちゃいけませんね。むしろベンチャーでリソースが限られているからこそ設計はしっかりやるべきだなと。

特にチーム開発であればなおさらですね。全体像についても事前にすりあわせしておく必要があるし、できれば設計の段階でピクセル単位まで落としておいた方がいいと思います。後々になって細かな遷移で違うとかってなると、本当に痛い目に合います(>_<)

まとめ（教訓）

• git checkoutしても元のブランチにちゃんとプログラムは残っています。gitは正しく使いましょう。
• ライブラリのreadmeをちゃんと読みましょう。
• deployで詰まったらまずは鍵とhostname周りを疑いましょう。
• 設計は事前にちゃんとやりましょう。

それではまた。