LoginSignup
77
39

More than 5 years have passed since last update.

若手シード期スタートアップでRailsじゃなくてDjangoを採用した話

Last updated at Posted at 2016-12-01

初めまして、株式会社LOGICAの松永と申します。
新しいプロダクトを開発するにあたり、Djangoを選んだのですが、Djangoは初心者なのでぜひ皆さんの知見を知りたいと思ってアドベントカレンダーを立てました。よろしくお願いします。

弊社ではまだ技術的にユニークなことをやっているわけではないので、自身の体験を投稿することにしました。

若手シード期スタートアップでDjangoを採用した

機械学習人気の高まりと同時にPythonの認知度も高まった一方、「Python=計算用」みたいなイメージが広がっているのかなぁという印象があります。また、ウェブ系だとテックキャンプさんやProgateさんを始めとするプログラミング学習サービスでRailsがとても充実しているため、特にスタートアップではRailsをやるひとが増えていると思います(サンプル数は多くないですが)

スタートアップ、特にうちみたいな非常に若い人がfounderである会社の場合、業務経験のあるエンジニアがいないケースが多く、学習のしやすさというのは非常に重要になってくるので、日本語の情報がたくさんあるRailsやPHPのフレームワーク(詳しくない)がよく選ばれるのは自然なことなのかなと思います。

国内でもDjangoを利用しているベンチャー企業はたくさん(?)あると思いますが、若手のベンチャーではあまりないような気がします。国外では多くの有名企業が採用している中、日本ではイマイチ市民権を得てない気がします。

今回はこんな状況でなぜRailsじゃなくてDjangoを選んだのか、若手シード期のスタートアップでDjangoを選んでよかったこと悪かったことなどをまとめてみました。
※この記事ではDjangoの技術や性能、設計面等での考察は書いてません
※若手やシード期のスタートアップ限定の話になるかもしれません

とてもニッチな記事ですが良ければ最後までおつきあいください。

弊社の現状

弊社では旅行はリラックスするために行くものなのに調べることが多すぎる、特に「ホテル探し・予約がごちゃごちゃして面倒」という課題に対し、ホテル探しをシンプルにすることを目的としてホテルの横断検索サイトを開発しています。じゃらんや楽天トラベルといったものではなく、トラベルコちゃんやtrivagoと同じような比較サイトになります。

sakutabi.com

数日前にリリースしたのですが、バグ潰しと温かみのある膨大な手作業入力が全然終わってません。(比較量を少なくするため、各予約サイトで異なるプラン名や部屋名を自動的に名寄せしようと思ったのですが、ルール化できるようなものでもなかったので手作業でやります)アドベントカレンダーを書いている場合ではない

現在、空室情報を取得するクローラーと比較サイト本体の2つを別々のDjangoプロジェクトとして開発しています。会社はまだ僕1人の状況なので開発も1人で行っています。

開発開始時点での筆者のレベル

  • Pythonが1番得意
    • 会社設立前はアルバイトでPythonばかり書いていたため。1年半くらい
  • ウェブフレームワークはDjangoよりRailsが得意
  • そもそもWebアプリはちゃんと作ってリリースしたことがなかった
    • シミュレーションとか画像処理とかクローラーとか、そういうのを書くことが多かった
    • 途中まで作って潰すとか、友達と一緒に開発してもメディア側じゃなく管理画面側を担当していたりとか
  • 英語を読むのは苦ではない ← 大事

技術選定の際の要望・要件

採用をしても開発者が激増するわけではなく、しばらくは少人数なのでとにかく楽であることを重視しています。

  1. 言語やフレームワークは統一したい
  2. 管理画面がある(or すぐ作れる)
  3. 新たな学習コストはなるべく抑えたい

1つ目は頭の切り替えや学習コストの問題です。クローラー(と管理画面)をPython(Django), メディアをRailsで書くというような選択をした時にマイグレーションの定義の差分を吸収したり別にモデルファイルを書くのがダルいなぁという気持ちと、使いまわせるものは使いまわしたいなぁという気持ちがありました。使い回しうんぬんの前に、フルスタックフレームワークの二刀流は開発者1~2人の段階でやるべきではない気がします。

2つ目の管理画面についてはRailsを選んでもgemでなんとかなるので、ここはそんなに気にしてませんでした。

3つ目の学習コストですが、僕1人の状況だと勉強する=開発停止であり、ハマった時なんかも慣れてないと無駄に時間を食うので使い慣れてる言語・フレームワークを使うことは絶対条件でした。あと、フレームワークを2つ使うと学習量も増えるので1つにしようと最初から考えてました。

以上の3つの条件を考慮した結果、Djangoにしました。

Djangoを選んだ理由

シード期のスタートアップのため、作ったものをピボット等によって消す可能性も高く、創業者である私も開発に参加することが大前提のため、僕が1番書きやすいことを優先しました。

個人的な理由

その結果、圧倒的に書き慣れている言語がPythonだったため、Pythonのフレームワークで管理画面も付いているDjangoを選びました。Railsのほうが慣れていますが、熟練のRailsエンジニアというわけでもなかったので。RailsとDjangoを技術的に比較してDjangoにしたわけではありません。
クローラーはPythonで書き慣れているという理由(前職でクローラーをよく見ていた)もあります。

ついでにいうと、Pythonに統一することを決めたあと、fabricとcuisineでデプロイスクリプトを書いたのでメディアのフロントエンド以外は全部Python製です。全部Djangoにするとデプロイスクリプトも一部使いまわせて楽です。

あと、分析もPythonはライブラリが揃っていて楽です。
しばらくはゴリゴリ分析スクリプトを書くことはないですが、分析業務についてもDjangoのプロジェクトでDjangoのORMを使ってバッチなどを作成するといくらか楽になると思います。

採用面での理由

Railsエンジニアが増えたとはいいつつ、おそらく一定レベル以上のエンジニアが急激に増えたわけではないと思っています。
Djangoを触っている時点でなんちゃってエンジニアの確率が減るのでと、Djangoを採用しているスタートアップは少ないのでそれだけで目立つため、RailsエンジニアとDjangoエンジニアで採用難易度は大きく変わることはないと思いました。

ただ、これは全部中途採用前提で、大きなミスを犯しているのでそれについてはこの記事の後半で書きます。

Djangoにしてよかったこと

全部Djangoなので頭の切り替えがなくて楽、コードを使いまわせて楽、くらいです。
あとは管理画面でクローリングした結果を見られるので楽です。
フルスタックなので、大体欲しい機能は調べたら出てくるのと、documentが充実しているので調べるのも今のところ困っていません。
Django固有のメリットではない

Djangoにして困ったこと(困りそうなこと)

さて本題です(笑)
実は、今のところ技術的に困っていることはないですw
というのも、まだコード量も少なく、細かいところを詰めていく段階ではないからです。最近作ったプロジェクトなのでDjangoのバージョンを上げるといったこともなく、「あぁ、フルスタックフレームワーク便利だなぁ」という感じです。

ただ、シード期の若手スタートアップ的には微妙だなという点がいくつか出てきました。
先程書いた全部中途採用前提で、大きなミスを犯しているというのは以下の内容に含まれます。

1.インターンやアルバイトを採用しづらい(かもしれない)

採用しづらい「かもしれない」としたのは、業務経験がある人限定で探していたため、実際にDjango未経験でインターンやアルバイトを探していたわけではないからです。

若手のシード期スタートアップだと、資金的な問題と知人関係から同世代の人を採用することが多く、またハードワークと「なんでもやる」ことの重要性からアルバイトやインターンを採用することが多いかと思います。つまり、

採用時点でのスキル >>>>>> キャッチアップ速度&カルチャーフィット

となります。
その点から考えると、Djangoは初心者に優しいものでは決してない(以下詳細)ので、若手シード期のスタートアップで採用の選択肢を狭めてると思いますw

DjangoはRailsと比べて初心者に分かりやすい教材が少ないうえ、日本語の情報が少ないのでプログラミング初心者には「慣れないプログラミング」に加えて「英語」という二重苦となり、全くの初心者からはじめるにはかなり敷居が高いかなと思います。(フルスタックフレームワークを全くの初心者が最初にやるべきかどうかは別として)

また、Djangoの経験者が同世代にいるかというと、ほぼいないと思いますw(僕は24歳です)そもそも、初心者エンジニアだとRailsは知っていてもDjangoの存在など知りません。Pythonすら怪しいと思います。知っていても「ディージャンゴ」って読んでると思います(ソースは僕)

世代に関係なく使用者も少ないので、気軽に質問できる人や場所が限られ、結果としてドキュメント(英語)やソースコードを読む力が相対的に重要になってきます。ただ、ドキュメントやソースコードを読むのはエンジニアなら当然なので、エンジニアになりたい人にとってはDjangoから始めれば良い習慣が身につくのでむしろ良いのかなと思っています。

いずれにせよ、Railsをはじめるよりはエネルギーが必要かなと思います

ただ、Pythonに限っては初心者が勉強しやすい良い言語だとも思っております。

2.リサーチコストが高い

1点目と一部重複してしまいますが、日本語の情報が少ないこと、(国内の)利用者が少ないこと、勉強会が少ないことからリサーチコストが高いと思います。

特に若手の技術力が高いとは限らないスタートアップでは「これ、どうやるんだろう」と悩んだときにすぐに例が見つかるのはとてもいいことです。幸い、PythonやDjangoは世界的にマイナーなわけではないのでライブラリなどは充実しています。しかし、それらを知らなかったり実装方法がわからずに悩むのはスタートアップとしてはあまり良いことではないと思います。英語なら割とすぐ見つかるので、「見つからない」というより英語が中心であることのしんどさですかね。

勉強会に関してはJavascriptのフレームワークやツール選定のような宗教戦争がなく、議論する話題もそもそも多くはないのも1つの理由かなとは思います。Pythonの思想とも関係しているかもしれませんね。

あと、勝手なイメージですが、Djangoを業務で使っている方たちはそもそもあまり勉強会に出てこないイメージがありますねw

もっとDjangoを使った開発の知見を共有する場があればいいなぁと思っているので、会社として開発力に少し余裕が出てきたらDjango(にかぎらずPythonのフレームワークで)ミートアップや勉強会もやりたいです。Djangoを採用されている企業の方にはお声がけさせていただくかもしれません。

まとめ

良いこと(?)

  • Django自体はよいフレームワーク!!
  • Pythonが割と何でもライブラリが揃っているので、少人数でやる場合には開発コストを下げられる
  • 初心者といえど、エンジニアを目指しているならRailsじゃなくてDjangoを選択すると良い習慣が身につきそう
    • ただしサポートは必須

悪いこと・懸念点

  • PythonやDjangoの敷居が高く人気がないのでアルバイトやインターンを採用しづらい(かもしれない)
    • 将来起業したくて、プロトタイプ作れるレベルの技術力でいいと言う人には絶対オススメしない
    • Pythonメインの会社自体が少ないので、採用での競合も少ないので実際は変わらないかもしれませんw
  • リサーチコストが高め
    • もっと普及するといいのに

もし開発開始時に僕以外に開発メインの人がいれば多分Rails選んでますねw Djangoを選んだのは現時点で開発者が僕1人であることとクローラーはPythonで書くのに慣れていたという個人的な条件が1番大きかったです。

いろいろ技術選定で書いてしまいましたが、そもそもスタートアップでは早く作って早くプロダクトで価値を届けることが重要なので、アレコレ深く考えるのはやめて開発頑張ります!!

P.S.
仲間も募集しておりますので少しでもご興味を持っていただけましたらご連絡ください!
https://www.facebook.com/masaru.matsunaga.9

77
39
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
77
39