One Response

  1. 池田 朋大
    池田 朋大 at |

    中の人の@mikedaです。
    理由が知りたいという意見が多いので、個人的に考えたことをコメントしておきます。
    細かい議論はいっぱい出たのですが、自分が個人的に重要だと思ったことです。
    また別の人もコメントしてくれるかもです。
    ※自分は1ヶ月前まで完全インフラ運用エンジニアだったので、意見がだいぶそっちよりになってます。

    背景は『CakePHP1.3で書かれた既存プロダクトの完全リニューアル』です。

    1.CakePHPがもうすぐ出る3で大幅アップデートされるため(find結果が配列じゃなくobjectになるなど)、再度の大幅改修が必要になるリスクがあるから

    ※他のプロダクトの、今後のアップデート計画とFW統一もふまえてです。
    ruby1.8->1.9、rails2->3のころのようなものはしばらくないと思いますが(というか祈りたいですが)、Ruby/Railsのバージョン追随もそうとう辛いです。
    ただ目の前にすごく大きな仕様変更が控えていることは、移行のモチベーションを下げる一因でした。

    2.僕も含め、ある程度の割合の開発者がRailsのほうが書きやすそうと言ってるから

    こういう意見は基本的に個人的なことであったり、主観であったりします。主に言語やFWのシンタックス、それによる現時点での個人の作業効率が主要な判断ポイントであることが多いです。今まではあまり重要視しないことが多かったです。
    たいていはそれよりも『処理系の特性、性能、業務マッチ度、あとエンジニア採用の問題』が重要な問題になるからです。
    そしてこういった現実的で複合的な要因に対する自分の感覚値では、PHPはかなり優秀な選択肢になる場合が多いと考えています。このあたりは短く書けなそうなので、また別の機会かTwitterで言及します。
    今回の特殊な事情は、処理系の性能や採用の問題をあまり考慮しなくていいということです。(処理系の特性はどちらも特に問題がない)
    現状はサーバコストはエンジニアの人件費の5%程度です。サービス特性的にここは将来的にも大きくならないでしょう。
    なので重要なのはサーバ効率よりも人効率です。採用も4月にエンジニアを1人→5人と一気に増やし、今後大きく人を増やす予定がまだありません。
    採用が大きな問題にならない場合、かつ短期間で成果を出さないといけないベンチャー企業の場合、大事なのは将来入る人の作業効率や採用効率ではなく、『今いる人の作業効率』になります。
    その場合、今いる人の意見を最大限重視するというは充分に有効な選択肢ではないかと判断しました。

    というあたりが、自分が個人的に考えたことです。
    これが正解かどうかは、最終報告は一生できないかもしれませんが、しばらくたったら中間報告は入れようと思います。

    Reply

Leave a Reply