Ruby on Rails セミナーに参加してきた

Tech

クックパッドのCTO橋本さんによるRuby on Railsのセミナーに参加してきました。

仕事では、PHP, Java, Perlなどを使う機会はあるのですが、Rubyを触る機会がありません。最近(今更かもしれませんが)、Rubyに興味持って触り始めたこともあって参加してみました。

セミナーで話される内容が理解できないこと(例えば、RubyやRuby on Rails固有の話とか)があるかなと思ったのですが、そんなこともなく、興味深い話を聞くことができました。

どんな内容だったかは、そのうちに「クックパッド開発者ブログ」に資料がアップされるかと思います。(そういう説明は聞いてないんですが、以前の勉強会の資料がアップされているようなので、アップされるかと思います)

基本的には、以前に開催された「カカクコム＆クックパッド共催・勉強会」での資料をベースにクックパッドにおけるものづくりについて話していただきました。

技術的な話が中心ではなかったこともあって、ものづくりについてのクックパッドとしての考え方についての話はとても興味深かったです。同じWeb開発者として、共感できる部分が多くありました。そして、実際に共感しつつも、うまく実践できていないところに歯痒さを感じたりもしましたが。

個人的に印象に残った部分だけ書きます。

つくるものを決める

  • やりたい(情熱を持ってやれる)、できる(世界で一番になれる)、やるべき(もうかる)の3つをすべて満たすBESTなことにのみ集中する
  • ユーザの欲求に基づいたゴール設定をする

自分たちが作りたいものを明確にし、その作るものに対してのみ集中するという考え方は、なるほどなと思いました。よく一部の特定のユーザにしか使われなかったり、自己満足にしかなりえないような機能を作ってしまいます。ターゲットとなるユーザ(キャスト)が明確であればいいのですが、そうでない場合もあります。その場合は、一度立ち止まって、本当に自分たちが作ろうとしているものを利用するユーザは、この機能があることでどんな欲求を満たすことができるのか考える必要がありますね。本当は必要とならない機能なんていらない、作るべきじゃないんです。

最近(でもないのかな？)だと「ユーザ中心設計(UCD)」なんて言葉が流行っていましたが、それを実践しているようでした。(本格的なものではないですが)

計画する

  • スケジュール3分割の法則
  • クックパッドものづくり3原則(無言実行, 無言語化, サービスに値段を付ける)

クックパッドでは、つくるものが決まるとサービス完成までのスケジュールを設定の考え方が面白いです。設計、開発、QAの3つでスケジュールをきっちり3分割するそうです。つまりサービスの完成が3週間後だとすると、設計が1週間、開発が1週間、QAが1週間といった形で分けます。その期間を超えるような機能があった場合、不要なものを削ってベストを目指すそうです。機能を実装し、スケジュールを少し先に延ばすという選択肢を選ばれがちなのをあえてやらない。ベストを目指すことという考え方はここにもあらわれています。

またサービスに対してきちんと値段を付けるという考え方は、あっと驚かされました。自分が実装したサービスがどの程度の価値を持つのかは、きちんと意識するということは、モチベーションを維持する上でも大事ですし、企業がサービスを提供する上での考えとしても納得させられました。

最近では、無料でWebサービスを提供している企業は、数えきれないほど存在しています。そして、無料であることが当たり前になってしまいました。ユーザは、無料サービスであるだけでは使わなくなっていくと思います。「無料だから大丈夫」なんて考え方だと、今後、サービス、企業の盛業は見込めないですよね。

設計する

  • ユーザに届けるのは「機能」でなく「価値」

設計は、ドキュメントよりもソフトウェアを重視するというアジャイルのスタイルと取っているそうです。そして設計は「要件→サイトマップ→遷移→ページ詳細→DB構造」の順番で行うそうで、大枠の設計を行った上で細かい機能の設計を行う一般的な設計です。この順番には、詳細な機能設計から入ってしまうと、気付かないうちに機能にとらわれてしまい、本来ユーザに届けるべき「価値」ではなくなってしまうということを意図されているそうです。

開発する

Railsにのると言っているのは、以下の理由からだそうです。

  1. Railsに外れるとコードが読めなくなる
  2. Railsのバージョンアップに対応できない
  3. Railsに外れてしまいそうな場合でも代替案で大抵解決する

それ以外の2原則は、一般的によく言われる話ですね。あとテスト駆動開発については課題とのことでした。

質を高める

  • ユーザテストは、バグの発見よりユーザに価値を提供できているかを確認する

実は、これには驚かされました。質を高めるのは、でき上がった「プログラム」の質ではなく、ユーザに提供する「サービス」の質だったからです。本来あるべきなのは、「サービス」の質ですよね。非常に考えさせられました。

最後に

このセミナーに参加して、クックパッドさんのユーザに対してベストなサービスを提供しようとする姿勢がよく分かりました。見習うべきところだったと思います。

あわせて読みたい

既にブログで内容をアップしてくれている方もいらっしゃるようなので、内容を知りたいという方はチェックしてみるといいかと思います。(手書きベースでメモしてたんですが、あまりに汚くて整理に時間がかかりそうなので断念しました)